모캠 History - ThirdParty Api Server 제작기

시작하기 전에

해당 블로그에 작성되는 글은 주인장의 지극히 주관적인 생각이 다수이며, 대부분의 지식은 구글링을 통해 얻고 있기 때문에 옳지 않은 정보가 있습니다.

잘못된 부분이나 수정해야 하는 부분이 있다면 과감히 덧글을 남겨주세요! 모르는게 많은 새싹입니다.

 

 

오늘의 주제

오늘의 주제는 북딜 서비스 마이그레이션을 진행하면서 함께 사용하고 있던 서드파티를 위한 API Server를 처음 제작했던 이야기와 과정에 대해서 적어보려 합니다. 다른 분이 작성한 코드를 해독하고 그것에 맞게 나만의 코드를 다시 제작하는 일이 처음 실무를 접하는 저에게는 쉽지 않은 일이었어요. 어떻게 작업을 진행했고 어떤 결과물이 나왔는지 코드를 되돌아보면서 과거를 추억하고 반성하는 시간을 갖도록 하겠습니다 :(

 

 

구조를 파악하자

우선 첫번째로 해야 했던 일은 메인 서버에서 서드파티를 위해 어떤 정보를 보내주는지 외부 서비스와 서드파티는 어떤 구조를 갖고 있는지 파악하는 일을 가장 우선시했어요.

 

북딜 서비스의 전체적인 구조는 아래와 같아요.

북딜 서버 인프라 구조

 

그중에서도 이 부분! 에 대한 작업을 맡아서 작업을 진행하게 되었어요

서드파티 작동 과정

메인 API server로부터 요청이 오는 형식은 다음과 같았습니다.

1. RowData를 통해 메인 서버로부터 데이터가 넘어온다.

2. 넘어오는 데이터(발신자, 수신자, 내용 등...)는 Base64를 통해 인코딩 되어있습니다.

그다음 제가 해야 할 일에 대해서 생각해봤습니다. 저는 2개의 어플리케이션을 따로 작동시킬 수 있도록 코드를 작동하였는데, 혹시 나 저의 못미더운 코드가 나중에 문제를 일으켜서 두개의 서비스 모두 이용할 수 없는 불상사를 막기 위해서 디렉터리를 분리하고 어플리케이션 또한 분리하여 작업을 시작하였습니다.

1. 인코딩 되어 있는 데이터를 디코딩을 하고 utf8 형태로 변환해 줍니다.

2. 디코딩된 데이터를 DB에 저장할 수 있는 형태로 포맷팅을 진행합니다.

* 여기서 생각보다 각 외부 서비스의 Agent Program(Batch성 프로그램)이 읽어 들일 수 있는 형태에 맞춰서 DB Schema를 정의해 줘야 했어요. 컬럼수가 생각보다 너무 많아서 정말~ 많이 헷갈렸습니다.

3. 외부 서비스에 대하여(총 2개) 각각 Agent Program을 매뉴얼에 맞게 설치해주는 작업

4. 작업 결과를 요청을 준 메인 서버가 받을 수 있는 형태로 포메팅하여 응답

5. 마지막으로 서비스가 잘 작동하는지 테스트!

 

사실 지금 생각하면 크게 어려움이 없던 작업 같은데 그때는 그게 왜 이렇게 부담스럽고 어려웠던 건지 우습네요 ㅎㅎ
메시지 발송에 관련해서는 사실 이용자의 개인 신상이나 발송 건당 비용이 발생하기 때문에 겁이 많이 났던 거 같아요.
창피함을 통해 경험을 공유하고자 여기에 코드를 업로드해놓았습니다. (진짜 창피하다......)

지금은 쓰지 않는 코드에요! 무려 2년전에 작성되었던 코드이고, 코드가 삭제되기 전까지 신기하게도 오류한번 발생하지 않았지만 코드를 다시 살펴보며 반성해야겠다는 점들이 있었다.

 

반성할 점

1. 전체적인 코드내의 규칙이 없다. (네이밍, 들여쓰기 등등..)

2. 프로덕션 코드였음에도 불구하고 주석이 많이 남아있었다.

3. static 파일 및 상수에 대한 처리를 좀 더 깔끔하게 디렉터리로 관리했으면 좋았을 것 같다.

4. 로깅이 뭐 거의 없다... :(