Career PR

백엔드 개발자 한정수, OO의 ‘주문 플랫폼’ 고도화에 합류 — 장바구니에서 주문 확정까지 더 빠르고, 더 안전하게

백엔드 개발자 한정수가 OO 주문개발팀에 합류한다. 주문팀에 합류한 목적은 고객이 주문 버튼을 눌렀을 때 실패하지 않고, 기다림을 최소화하도록 만드는 데 이바지하는 것이다.

주문팀은 하루 30만 건, 분당 최대 1.5만 건의 트래픽과 50억 건이 넘는 데이터를 다루며, 회사 성장의 핵심 엔진 역할을 수행한다. 팀의 비전은 세계에서 가장 강력하고 유연한 주문 플랫폼 구축이다. 복잡한 정책 충돌을 하나의 시스템으로 수렴해 새로운 비즈니스 모델을 상상하고 즉시 구현할 수 있는 속도를 확보하는 데 주력한다.

한정수는 인사와 회계 ERP를 다루며 다양한 경험을 쌓았다. 먼저, 메일이 중복 발송된 장애에 대해 재발률 0%로 핸들링했고, API를 통한 자동화로 작업 시간을 60% 이상 줄인 경험이 있다. 한정수는 이러한 방식으로 주문에서도 주문 정보는 먼저 저장한 뒤 같은 요청은 한 번만 처리하고, 진행 상태는 바로 확인할 수 있게 만들겠다는 계획을 밝혔다.

“고객님 입장에서는 주문이 제대로 접수됐는지와 주문의 여정이 언제 끝나는지가 전부입니다. 그래서 주문이 발생하면 먼저 저장한 뒤 중복 없이 한 번만 처리되도록하고, 바로 주문이 완료됐다는 결과를 보여 드릴 것입니다.” - 한정수

입사 후 90일 동안은 세 가지에 집중할 계획이다. 첫째, 중복에 대한 방지를 표준화할 예정이다. 같은 내용의 요청에는 고유번호를 붙여 하나만 저장되게 한다. 연달아 누르거나 순단 현상 후 다시 보내져도 이미 처리됐다는 결과를 돌려주는 방식을 적용할 것이다. 둘째, 주문서의 핵심 정보를 바로 저장하여 응답을 만들고, 알림 등의 작업은 우선순위에 따라 줄 세워(Queue) 처리한다. 이렇게 하면 피크 시간대에도 느려지지 않는 기반을 만들 수 있다. 셋째, 로그를 통한 모니터링으로 사후 검증에 대비한다.

이에 따라, 중복 주문 비율 감소, 주문 처리 시간 감소, 장애 복구 시간 감소 등의 기대 효과를 볼 것이다.

FAQ

Q1. 고객에게 주는 가치는 무엇인가요?

고객 입장에선 주문이 실패하지 않고, 빨리 끝나고, 혜택이 제대로 적용되는 것입니다.

장바구니에서 주문 버튼을 누른 순간부터 여러 검사가 동시에 일어나 쿠폰, 재고, 본인확인 등의 상황에서 충돌이 나기 쉽습니다. 재고·결제 가능 여부 등 동시에 꼭 필요한 검사만 먼저 하고, 나머지는 뒤에서 처리합니다. 즉, 바로 안 해도 되는 일은 메모해 두었다가 줄 세워(Queue) 처리하는 방식입니다.

쿠폰/프로모션/한도처럼 규칙이 많은 건 한 곳(정책 엔진) 에서만 계산하게 만들어 앞뒤가 다르게 나오지 않게 합니다. 예시로는, 같은 쿠폰을 두 번 적용하려 하면 “이미 적용된 혜택입니다”라고 안내하고, 고객이 무엇을 하면 되는지 다시 시도/다른 수단 선택 등의 버튼으로도 보여줍니다.

이에 대한 정확한 측정을 하고 싶다면, 주문 성공률 / 장바구니에서 주문까지의 전환율 / 정책 충돌률 / 혜택 불일치 등의 고객센터 문의(VoC) 등이 있습니다.

Q2. 왜 정수님이 적임자인가요?

동시성 문제를 해결해 본 경험으로, 주문에도 빠르게 적응할 자신 있습니다.

주문은 사용자가 버튼을 연달아 누르거나 네트워크가 끊겼다가 재시도되면 같은 주문이 여러 번 생기는 일이 흔합니다. 이에 대한 방안으로 세 가지를 들 수 있습니다.

첫째, 같은 내용의 요청에는 고유 번호를 붙이고, DB를 활용해 Unique Key로 한 번만 저장합니다. 둘째, 요청이 실패했을 때는 기다리는 시간을 점점 늘리고, 그 사이에 랜덤하게 다시 요청하면 서버의 과부하를 더 잘 막을 수 있습니다. 그리고 서버가 곧바로 결과를 내지 못 한다면, 상태를 확인할 주소를 줘서 같은 요청을 또 보내지 않고 결과만 확인하게 하면 됩니다. 셋째, 로그를 통한 모니터링으로 이슈 발생 후 원인 파악에 대비합니다.

Q3. 왜 주문 정보를 먼저 저장하겠다고 하셨나요?

실패나 지연을 줄이고, 즉시 화면에서 끝내지 않아도 되는 일들을 나중에 해도 주문은 사라지지 않기 때문입니다.

한 번에 재고 확인, 쿠폰 계산, 알림 발송까지 다 하려고 하면 응답이 늦어지고 실패할 확률이 늘어납니다. 반대로, “누가, 무엇을, 얼마에 주문했는지” 정도만 저장해 둔다면, 고객은 바로 “주문 접수됨”을 볼 수 있습니다. 그 후 나머지는 순서대로 처리해도 괜찮습니다.

Q4. 같은 요청을 한 번만 처리한다는 건 구체적으로 어떻게 하나요?

요청 ID를 고유번호로 받았는데 이미 처리된 요청일 때면, 그 결과만 다시 돌려줍니다. 연달아 누르거나 통신이 끊겼다가 다시 보내질 수 있습니다. 그래서 같은 요청에는 같은 고유번호를 붙이고, DB에 이 번호로 저장된 주문이 있는지를 확인합니다. 저장된 주문이 있다면 있으면 새로 만들지 않고 그 주문을 보여줍니다. 필요하면 몇 초 단위로 묶어서 연속 요청을 흡수할 수도 있습니다.

Q5. 대규모 트래픽에서 주문의 핵심 정보를 바로 저장하고, 나머지 일은 여러 인스턴스로 뒤에서 처리하는 구조가 왜 유리한가요?

핵심 정보만 빨리 끝내고, 나머지는 나눠서 처리할 수 있기 때문입니다. 핵심 정보를 먼저 저장하면 각 요청이 DB에 머무는 시간이 짧아집니다. 알림이나 정리 같은 부가 작업은 대기줄(Queue)에 넣어 여러 서버가 분업으로 처리합니다. 조회는 읽기 전용 경로로 빼서 저장과 부딪히지 않게 합니다.

Q6. 쿠폰/조건이 복잡하면 화면과 서버 결과가 달라지지 않나요?

규칙을 한곳에 모아 계산하게 만들어 항상 같은 결과가 나오게 합니다. 우선순위와 겹치는 조건을 표로 정리하고, 서버의 한 모듈에서만 계산합니다. 화면은 그 결과를 그대로 보여주므로, 앞뒤가 다르게 나오는 일을 막을 수 있습니다. 위험한 변경은 일부 사용자에게 먼저 적용해 확인합니다.

Q7. 고객은 주문이 제대로 접수됐는지 바로 확인할 수 있나요?

네. 상태 확인 주소나 주문 상세 화면을 함께 제공해 반복 클릭 없이 진행 상태를 볼 수 있게 합니다. 서버가 바쁠 때에도 고객은 접수됨 -> 처리 중 -> 완료 단계까지와 예상 시간을 확인할 수 있어 불안이 줄어듭니다.

Q8. 로그로 모니터링은 뭘 보겠다는 건가요?

실패 이유에 이름표를 통신 문제, 한도 초과, 재고 없음 등으로 붙인다면 원인을 바로 찾을 수 있습니다. 대시보드를 통해 주문 성공률, 중복 비율, 처리 시간을 확인합니다. 만약, 이상이 생기면 어느 구간에서, 어떤 이유로 늘어났는지 바로 확인해 조치합니다.

Q9. 입사 후 90일을 “중복 방지 → 빠른 저장 → 모니터링” 순서로 잡은 이유가 있나요?

바로 체감되는 문제부터 줄이고, 그다음 빠른 저장을 통해 동시성을 방어합니다. 그 뒤에 모니터링 대시보드 등을 만들려고 했습니다. 중복 이슈는 고객과 운영자 모두에게 가장 치명적입니다. 그다음은 저장에 대한 응답 속도, 마지막은 모니터링 체계를 만들어 지속적인 변화를 가능하게 하는 순서의 우선순위로 이루어집니다.

Q10. “중복 발송 재발 방지”, “자동화로 업무 시간 60% 절감” 같은 과거 성과가 주문과 어떤 연관이 있을까요?

중복을 막고 반복을 줄이는 원리가 동일합니다. 메일 중복을 멈춘 방식은 주문에서도 같은 요청은 한 번만 처리하는 것과 비슷합니다. 그리고 반복 업무를 줄인 경험은 주문 운영자 화면에서도 사람 손이 덜 가게 설계하는 데 이바지할 수 있습니다.

Q11. 사람들이 한꺼번에 몰리는 세일에서 시스템이 버틸 수 있나요?

여러 인스턴스가 나눠서 처리하고, 읽기와 쓰기를 분리하면 버틸 수 있습니다. 핵심 정보만 빠르게 저장하고, 나머지는 대기줄로 넘겨 병렬로 처리합니다. 주문 조회는 읽기 전용 경로로 분리해 저장 작업을 방해하지 않게 합니다.

Q12. 실패했을 때는 어떻게 복구하나요?

상태를 즉시 보여주고, 다시 시도해도 중복이 생기지 않게 설계합니다. 요청이 실패하면 상태 화면에서 재시도 안내를 주고, 같은 고유번호로 다시 시도해도 주문이 더 생기지 않게 합니다. 운영자는 운영 대시보드에서 원인과 조치 방법을 확인해 바로 대응합니다.

Q13. 팀과의 협업은 어떻게 하실 건가요?

주문이 어떻게 흘러가는지 시퀀스 다이어그램을 통해 명확하게 이해하도록 하고, 테스트 시나리오로 정보 격차를 줄이겠습니다. 주문 흐름과 규칙을 UML로 공유하고, 대표 예시를 테스트 케이스와 항목(입력, 기대 결과, 오류 메시지, 모니터링 포인트), 합격 기준(DoD) 등으로 만들어 개발과 QA, CS가 오해 없이 이야기를 나눌 수 있게 합니다.