요기요 채널링 서비스 런칭 회고를 읽고 나서

요기요 채널링 서비스, 생각보다 훨씬 복잡하고 멋지다!

예전에는 그냥 카카오톡이나 G마켓 같은 데서 요기요로 주문이 되는 게 무슨 “딥 링크” 정도로 시스템이 돌아가는 줄 알았다. 그런데 실제로 이걸 위해 “채널링 서비스”라는 별도 마이크로서비스 레이어가 존재하고, 그걸 위해 API Gateway 패턴부터 파트너별 기능 제어, 캐싱/장애 관리까지 신경 쓴다는 걸 보니, 확실히 스케일 있는 기업의 백엔드 아키텍처는 차원이 다르다고 느꼈다.

API Gateway 패턴과 기능 분리의 중요성

API Gateway를 단순 라우팅 정도로만 생각하기 쉬운데, 이 글에서처럼 “보안+인증+파트너별 기능 제어+캐싱+장애 관리”까지 담당한다는 점이 인상적이었다. 특히, 파트너 요구사항이 다 다르니까 내부 MS(마이크로서비스)엔 최대한 영향 주지 않고, 중간에 이 채널링 서비스가 ‘외부와 내부의 방화벽’ 같은 느낌으로 맞춤형 인터페이스를 만들어주는 게 진짜 좋은 전략 같았다. 만약 파트너별로 내부 코드를 계속 손봤다면 유지보수 난이도가 급격히 올라갔을 것 같다. 이는 직장을 다닌 7년동안 겪었지만, 대부분 후자에 속했기 때문에 코드의 복잡성이 올라가고 유지보수성은 현저히 떨어질 수 밖에 없었다. 어떻게보면 당연할 수 있겠지만, 만약 내가 담당자였다면 저런 아이디어를 떠올렸을까싶다.

유연한 기능 관리가 현실적으로 얼마나 필요할까?

‘커스텀화된 기능 제어’가 왜 중요한지 실제 예시를 보니까 확 체감이 됐다. 파트너사별로 결제 방식이 다르고, 어떤 곳은 쿠폰을 허용해야 하고 어떤 곳은 안 해야 하는 현실... 나는 첫 직장이었던 PG사에서 결제관련 개발을 했다. 그렇기때문에 이런 것들이 진짜 자주 마주치는 요구사항이라는 걸 알기에, 적절한 추상화 레이어를 서비스 기획 단계에서부터 꼭 고려해야 한다는 걸 다시 한번 되새김질 할 수 있었다. 당시에 나도 외부 업체랑 데이터 연동할 일 있었는데, 그땐 이런 식 기능 스위치 설계 없이 하드코딩하다가 나중에 진짜 후회했던 기억이 난다.

패키지 구조 설계

패키지 구조에 엄청 공들이고, 온보딩 난이도를 낮추는 데 큰 효과를 봤다는 점이 공감이 갔다. 많은 개발자가 협업할수록 오히려 개발 속도가 느려진다는 “맨먼스 미신” 얘기가 생각났다. 나도 클래스는 쉽게 이해해도, 패키지/모듈 구조가 엉망이면 남의 코드 들어가 봤을 때 진짜 한숨이 절로 나온다. 가독성과 결합도/응집도 측면에서 미리 생각해두는 게 역시 필수 같다.

아쉬운 점과 궁금한 점

• 장애 대응 전략에서 Redis 캐시랑 Kill Switch 얘기가 있었는데, 장애가 길어질 때 파트너도 불편하지 않을까? SLA는 어떻게 맞추는지 궁금하다. 파트너와 커뮤니케이션 채널이나 정책은 어떻게 구축했을까?
• 정산이나 회계 처리가 여러 결제수단으로 복잡해질 때, Data Consistency나 트랜잭션 관리 측면에서 어떤 노하우가 있는지 궁금하다. 언급이 적어서 아쉬웠다. 좀 더 자세하게 기술되어있었으면...ㅠ
• 파트너별 커스텀 기능 요구가 점점 많아지면, 코드가 `if-else hell`로 가지 않을지, 확장 가능한 설계 방식에 대한 추가 고민이 어떻게 이뤄졌는지도 궁금하다.
  • 최근 현업에서 비슷한 요구사항에 대해서 개발할 때 `if-else hell`로 빠지지 않기 위해 전략패턴을 사용했는데, 꼭 이게 답은 아니더라..더 좋은 방법이 있다면 배우고싶다.

참고 문헌

• 요기요 채널링 서비스 런칭 회고