마켓컬리 해커톤 회고
결론부터 말하면 팀명 "물아일체"로 기획 1명, 안드로이드 1명, 백엔드 2명(팀장 포함)이 참여해 총 156팀 중 12팀 이내 결선 진출로 마무리했다.
1. 해커톤을 왜 참여했나?
처음 해커톤에 참여한다는 소식을 주변에 알렸을 때, 회사에서 개발을 하고 있으면서 왜 굳이 해커톤에 나가냐는 질문을 가장 많이 받았다.
개발에 대한 흥미는 원래 높은 편이다. 다만 단순히 즐거운 것보다는 잘 만들고 싶은 욕심이 더 컸다. 참여를 결심한 이유는 크게 세 가지였다.
- 회사에서 개발하면서 나는 지금 잘하고 있는 걸까?
- 지금 담당하는 도메인이 아닌 새로운 도메인에서는 어떻게 접근해야 할까?
- 회사 밖에서 나는 어느 정도 평가받을 수 있을까?
이런 의문을 품고 있던 차에 우연히 마켓컬리에서 주관하는 해커톤 소식을 보게 됐다. 현업자가 참여할 수 있는 해커톤 자체가 그리 많지 않았다.
2. 주제 선정
마켓컬리가 제시한 미션은 네 가지였다. 그중 두 가지는 머신러닝이 필요해 보였고, 한 가지는 너무 추상적으로 느껴져서 남은 한 가지를 선택했다.
물류 처리에 있어 사람이 개입되면서 발생하게 되는 다양한 오류에 대한 해결 방안을 제안해주세요.
물류를 전혀 모르는 상태였기 때문에 잘 해낼 수 있을지 시작부터 막막했다. 하지만 접해보지 못한 도메인에서 오히려 빛날 수 있지 않을까 하는 기대감도 컸다.
3. 휴먼 에러를 잡아라!
우리는 실시간 통신을 이용해 피킹과 DAS 과정에서 발생할 수 있는 휴먼 에러를 잡는 것을 목표로 삼았다.
마켓컬리의 물류 처리 과정을 조사해보니 피킹 → DAS → 패킹 → 배송, 이렇게 네 단계를 거쳐 상품이 배송된다는 걸 알 수 있었다. 마켓컬리 작업자들을 대상으로 설문조사를 진행한 결과, 실수가 가장 많이 발생하는 구간은 피킹과 DAS였다.
4. 실시간 통신에 대한 개발적 고민
우리가 실시간 통신을 어떤 방식으로 구현했고, 그 과정에서 어떤 고민을 했는지 남겨본다.
실시간 통신에는 어떤 방법이 있을까?
실시간 통신을 구현하는 방법은 크게 두 가지다.
- 지속적으로 Request를 보내는 Polling 방식
- 양방향 연결 채널을 구성하는 WebSocket 방식
같은 구역에서 일하는 여러 작업자가 서로 실시간으로 통신할 수 있어야 했기 때문에, 계속 Request를 날리는 Polling보다는 서버 부하가 낮고 양방향 통신이 가능한 WebSocket이 적합하다고 판단했다.
또한 특정 구역의 작업자들이 모두 같은 데이터를 받아 처리한다는 특성상, pub/sub 구조로 되어 있는 STOMP를 활용했다.
서버가 늘어나면 어쩌지?
동일 업무 시간대에 많은 작업자가 몰릴 수밖에 없어서, 서버 한 대로 모든 요청을 처리하기에는 무리가 있다고 판단했다.
그런데 서버가 여러 대로 늘어나면 문제가 생긴다. 소켓이 연결된 서버는 양방향 통신이 가능하지만, 다른 서버로 들어온 메시지는 전달받지 못한다. 서버 간 데이터 공유가 필요했고, 그래서 Redis Pub/Sub를 활용했다.
5. 마치며
처음에는 단순히 참여하는 것에 의미를 두었다. 그런데 예선 통과, 본선 통과를 거치면서 점점 욕심이 생겨 우승까지 노려봤지만, 아쉽게도 결선 진출에서 마무리됐다.
5일이라는 기간이 다른 해커톤에 비해 길게 느껴질 수도 있지만, 막상 하나의 서비스를 만들기에는 짧은 시간이었다. 그 짧은 시간 동안 최대한 많은 걸 구현하면서도 매 순간 최선의 선택을 하고 싶어 고민을 거듭하며 개발했지만, 돌아보니 부족한 부분이 많은 코드였다.
아쉬움도 많이 남았지만, 그만큼 한층 더 성장할 수 있는 기회였다.