[서비스기획/PM] 홈페이지를 오픈하며 해결했던 문제들 (feat2. 개발이슈 편, API연동 개발 이슈, 알림톡 개발 이슈, 솔루션 적용 ,개발서버와 운영서버)

---

저번 포스팅에 이어 홈페이지를 오픈하며 해결했던 개발 이슈에 대해 다뤄보겠다. 

[서비스기획/PM] 홈페이지를 오픈하며 해결했던 문제들 (feat1. 클라우드 및 인프라 환경 설정 편 )

이전 포스팅 그리고 클라우드 이전에 따른 문제들이 궁금하다고 하면, 위의 게시글을 참고해보면 좋겠다.

클라우드 및 인프라쪽 이슈는 개발이슈만큼이나 중요했다. 그 이유는 네트워크 오류로 인해 사용자들이 접근 자체가 불가능하거나, 연결 불안정으로 인한 접속문제는 서비스 장애를 도래하고, 보안이슈는 개인정보와 직결된 문제이기 때문이다.

 

어떤 상황이었냐면..

 

API 연동을 개발하며 겪은 문제들

  (1) 문자수신 연동 문제

 

문자 수신연동은 어떤 상황에 필요할까?

: 민원처리, 접수 프로그램 등 간편접수에 많이 사용되는 방식이다. 

예를들면, 112에 긴급 신고 문자를 보낸다던지, 음악방송 중 순위 선별을 위한 문자 수신 등 여러가지 상황에 사용된다.

문자 수신 연동 개발이 필요한 case

 

처음에는, 
고객사측에 관리자 화면 접수> MMS에 문자수신 개발 진행해주세요~ 라고 요청을 하셔서 기능을 파악하는데 어려움을 겪었다. 😥😥 사용자가 접수한 문자는 수신업체의 게시판을 통해 확인 할 수 있는데, 수신 게시판에 쌓인 데이터를 우리 서비스의 DB,관리자 화면에 저장하기 위해 API 연동을 해야한다.    

사용자가 접수한 문자를 통해 얻을 수 있는 데이터는 아래와 같다.
발송 전화번호, 내용 data, 첨부파일 data, 발송일시 

 

 

문자접수 API 수신 연동 프로세스

 

대략적으로 그려본 문자접수 API 수신 연동 프로세스이다. 

문자수신에 데이터가 들어오지 않은 경우 등 예외 케이스는 작성되지 않았기에 감안하고 봐야한다.

 

 

문자수신에서 겪었던 연동 문제는 해당 프로세스를 파악하는게 핵심이었다. 문자 업체들은 계약 하고, 계정생성 해주고 가이드 하나 던져주고 알아서 하라는 식.....

🙋‍♀️  해당 문제를 해결하면서,

데이터를 연동받을(응답받을) 빈 페이지가 생성되어야 함을 알수 있었다. API 연동으로 원하는 위치(관리자 화면)에 데이터가 바로 생성되는 줄 알았다......... API로 연동받은 데이터를 저장하고, 활용하여, 데이터를 추가 하는 것까지 개발에서 진행하는 과업임을 이해할 수 있었다. 

 

 

---

  (2)  알림톡 발신 문제

알림톡 발송 연동시에 겪은 문제상황

 

 

요구사항 : 사용자가 접수프로그램에서 접수완료 시점에 접수한 내용이 정상 접수되었다는 내용과, 마케팅 수신 동의에 대한 처리 결과를 카카오톡 알림톡 발송

 

 

PM인 내가 진행해야 했던 과업 List

① 클라우드 업체에 8443 포트로 Outbound 통신 가능하도록 오픈 요청 

→ 외부로 나가는 8443 포트의 Outbound 통신은 전체개방되도록 설정완료

 

② 우리 웹서버의 공인 IP 주소 (이중화된 서버이므로 총2개)를 확인하여, 알림톡 발송업체에 발송방화벽 오픈 요청 

→ 문제는 ...... 개발서버 IP주소, 그러니까 로컬 IP주소를 등록해달라고 했던 것이다. 

운영서버의  공인 IP 주소(실서버 IP주소)가 등록되어있지 않아서, 운영에서 테스트 하는 경우 작동이 안되었던 것이다.

 

③ 알림톡 템플릿 정리 및 등록 

→ 알림톡은 관리자 화면에서 템플릿 등록후 승인과정을 거치고 나서야 개발이 가능하다. 알림톡은 두가지 종류가 있는데, 정보성 메시지는 '주문, 결제내역, 배송메세지'에 해당하고 광고성 메시지는 '전송자가 경제적 이득을 취할 목적을 가지고 전송하는 메시지' 이다.

법적인 가이드라인으로 인해, 카카오 내에서 자체적인 템플릿 검수를 진행한다. 

(※ 참고로 알림톡 발송 기획시 참고하면 좋을 내용은 여기에서 확인할 수 있다. )

 

 

 

---

 

그래서 문제가 뭐였는데? (feat. 함정)

Access to XMLHttpRequest at 'https://xxxxxxxxxxapi.carxx.com:사용포트번호/v3/발송타입/고객사id/발송타입' from origin 'https://www.발송도메인명.or.kr' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

 

모든 환경 세팅은 끝났는데, 개발쪽에서 문제가 생겼다고 한다. CORS 정책은 뭐지?

개발 마감 일정은 정해져있는데 개발자가 머리를 부여잡고 힘들어 하고 있으니, 도움이 될까 싶어 CORS 정책에 대해 알아보았다.

 

CORS(교차 출처 리소스 공유) : 리소스를 주고받으려는 두 출처가 서로 다른 경우에 발생하는 오류
브라우저가 자신이 보낸 요청 및 서버로부터 받은 응답의 데이터가 CORS 정책을 지키는지 검사하여 안전한 요청인지 검증하는 것이다.

 

 

 

✅ 어떤 경우에 cors 오류를 만날까? 출처가 다른 경우 (URL의 프로토콜, 도메인, 포트번호 중 1가지라도 다른경우)

    💭 웹의 발달에 따라 클라이언트에서 외부 API를 직접 호출하는 방식이 당연해지기 시작해지면서, CORS 정책이 나타났다. 보통의 클라이언트, API 호출 도메인이 다르기 때문에 출처가 다르더라도 요청과 응답을 주고받을 수 있도록 서버에 리소스 호출이 허용된 출처를 명시하여 해결할 수 있다. 

출처와 도메인 url 분석하기

 

✅ 어떻게 cors 오류를 해결할 수 있을까? 서로 다른 출처에 리소스 공유, 응답을 허용할 수 있도록 설정해야 한다.

   💭 서버에서 Access-Control-Allow-Orign  응답헤더 세팅

   💭 프록시 서버 사용

 

 

 

---

 

 

그래서 문제가 뭐였는데? (feat. 진짜문제)

개발자는 서버에서 Access-Control-Allow-Orign 응답헤더를 *로 설정해도 동일한 오류에서 벗어나지 못했다고 했다.

진짜 문제는 뭐였을까?
요청 메세지를 요청할 때 [ ](대괄호) 안에 메시지를 포함시켜 보내야 했다.
알림톡 업체에서 응답 시 대괄호가 없어 되돌아온 에러였다.   

 

다른 API를 개발할 때 대괄호를 포함하여 값을 보내지 않아도 발송에 문제가 없었다고 한다.

당연하다고 생각했던 부분에서 발생했던 문제였지만, 꽤나 오랜 시간 고민하고 고생했던 문제였다.

 

 

---

 

발송은 되는데 .. 데이터 타입 불일치로 발송 안되는 문제

알림톡은 승인받은 템플릿의 내용과 동일하게 요청 데이터를 보내야 정상발송된다. 우리가 설정한 변수는 이름과 선택동의사항 여부, 접수일자였다.

 

테스트 진행해보면서 접수는 정상으로 인입되지만, 응답에러 화면을 통해 요청 데이터가 템플릿 내용과 일치하지 않는다는 것을 확인할 수 있었다.

응답 에러 화면

 

이름 → name, 선택동의사항 → true/false, 접수일자 → YYYY-MM-DD

사용자가 접수 시 입력한 값을 변수에 저장하여 알림톡 발송 요청이 진행되어야 한다. 어떤 부분이 틀렸을까 하고 오류코드를 살피는데, yyyy.mm.dd.hh.mm.ss 형태로 저장되고 있었다. 시간과 분, 초 까지 요청하니 템플릿 내용과 동일하지 않다는 오류가 뜰 수 밖에.

 

 

 

 

 

🙋‍♀️ 아무튼 이 모든 문제를 해결하고 나서야 알림톡 테스트를 정상적으로 마치게 되었다.

알림톡 개발 참 어렵구나.. 조건도 정말 많구나 싶었다. 

과거의 내가 알림톡 기획을 ' A 시점에 B 사용자에게 C내용을 알림톡을 발송한다.' 로 정의했다면, 현재는 알림톡 템플릿에 대한 규제와 API 호출 및 요청 등 다양한 배경지식을 쌓음으로써, 개발자와 원활한 소통을 빠르게 진행할 수 있지 않을까 하는 기대를 가진다.

 

 

---

 

 

개발서버와 운영서버에서 테스트했을때 발생한 문제

 

 💭 개발서버 / 스테이징 서버/ 운영 서버 

로컬서버	개발서버	스테이징 서버	운영서버
개발자들이 처음으로 실행시키는 서버  ( http://local:8080 등)	개발자들의 개인 개발환경이 아닌 1개의 통합된 환경으로 테스트를 할 수 있는 서버	테스트 서버로 불리며, 운영 서버 환경과 거의 100%로 비슷할 정도로 환경을 맞춘 다음, 운영 서버에서 사용되는 데이터를 가지고 운영서버에 반영하기 전에 테스트를 거치는 서버	실제 운영되는 서버 환경

 

서버 환경과 구성에 따른 테스트 진행 가능여부, 애플리케이션 설정 등으로 생긴 문제들을 기록하고자 한다.

개발서버 환경에서 N번의 테스트를 거친 뒤(완벽한 줄 알았던), 운영서버 반영 하며 발생했던 문제들은 상상 이상으로 많았다.

 

 

  (1)  innorix 솔루션 적용 문제 

innorix 솔루션
사용자들이 웹 기반 시스템에서 대용량 파일을 고속으로 업로드, 다운로드 할 수 있도록 하는 파일 전송 솔루션

 

접수 프로그램 절차중 innorix 솔루션을 이용하여 파일을 업로드 하는 과정이 있었는데, 솔루션을 설치했음에도 테스트가 안되는 문제가 있었다. 확인해보니 솔루션이 웹사이트 도메인과 연결되어있어, 운영서버에서만 테스트가 가능했다.

 

 

 

---

 

  (2)  첨부파일 표출이 안되는 문제

개발서버에서 모든 테스트를 완벽히 마치고 운영서버에 반영하고 테스트를 해보니, 배너관리, 팝업관리, 이벤트 썸네일 등 첨부파일이 들어간 부분이 모두 보이지 않는 문제가 있었다.

◻ 사용자 파일 업로드 → 접수 및 신청 완료 → 파일 리사이징 → NAS 스토리지에 저장 → 리사이징된 파일을 해당 화면에 표출 

◼ 관리자 파일 업로드 → 파일 리사이징 → NAS 스토리지에 저장 → 리사이징된 파일을 해당 화면에 표출 

 

첨부파일 표출 안되는 이유

 

 

해당 문제가 어떤 문제인지 확인해보니, 파일 리사이징 단계를 거치지 않아서 파일이 저장되지 않는 문제였다.

확인해 본 결과, 개발서버의 php에 '리사이징을 위한 라이브러리'가 설치되어있어 정상적으로 작동했지만,

운영서버에서  php 설치 시 해당 라이브러리를 포함하여 설치하지 않아서 생긴 문제였다. 

 

 

그럼 라이브러리만 설치하자!

개발 애플리케이션 내에 '리사이징 라이브러리'를 설치하려고 했더니, 아파치 환경이 버그 및 패치 지원이 끝난 예전 버전이었기에 설치에 오류가 생겼다. 그래서 클라우드 업체에서 새로운 테스트 서버 올려주시고, 아파치 버전을 2.xx버전으로 업그레이드 후에 라이브러리를 포함한 애플리케이션 설치로 해당 문제를 해결 할 수 있었다.

 

 

 

🙋‍♀️  해당 문제를 해결하면서,

애플리케이션 버전 업그레이드와 DB, NAS, WEB, 개발언어 등 버전 관리는 어떻게 진행하는지 궁금했다.

필자의 경우, 이전 업체가 구축한 환경을 유지해야 했기에 현재 지원되는 버전과 격차가 크게 벌어져있었다.

개발 환경을 변경하게 되면 소스 오류를 고치는 시간과 비용으로 구 버전을 고집했지만,

언젠가 버전관리나 형상관리를 어떻게 하는지 파악해볼 수 있는 큰 시스템을 접해볼 수 있었음 좋겠다고 생각했다.

 

 

 

---

 

  (3)  QR접수 테스트가 안되는 문제

메인화면 디자인을 개편하면서, QR코드 이미지를 생성해달라는 요청이 있었다. QR코드는 실제 운영 서버의 URL로 생성되었기 때문에, 개발서버에서 QR코드 접속 테스트를 진행할 때 오픈 이전의 서버로의 접근이 불가능 했다.

 

→ 개발서버에서는 QR 접수가 불가능하다. 운영서버의 도메인으로 QR코드가 생성되었고, 운영서버가 오픈되지 않았기 때문이다.

 

 

 

 

↓함께 보면 좋은 글↓

[서비스기획/PM] 홈페이지를 오픈하며 해결했던 문제들 (feat1. 클라우드 및 인프라 환경 설정 편 )