Haskell로 마트 장보기를 자동화한 개발자 — 리버스 엔지니어링으로 만든 CLI 쇼핑 도구

터미널에서 장을 본다고요?

개발자들 사이에서 "삽질의 끝판왕"이라고 불릴 만한 프로젝트가 하나 등장했어요. 독일의 대형 마트 체인인 REWE의 API를 리버스 엔지니어링해서, 터미널 명령어 한 줄로 장보기를 할 수 있는 CLI 도구를 만든 건데요. 이름은 korb(독일어로 "바구니"라는 뜻)이고, 언어는 놀랍게도 Haskell이에요.

"그냥 앱으로 주문하면 되지 않나?"라고 생각하실 수 있는데, 이 프로젝트가 재밌는 건 단순히 결과물 때문이 아니라 그 과정에서 드러나는 기술적 접근 방식 때문이에요.

리버스 엔지니어링이 뭐냐면

먼저 리버스 엔지니어링이 뭔지 짚고 넘어갈게요. 이게 뭐냐면, 공식적으로 문서화되지 않은 시스템의 동작 방식을 역으로 분석해서 알아내는 것이에요. 마치 완성된 요리를 먹어보고 레시피를 추측하는 것과 비슷하달까요.

REWE는 공식 API를 외부에 공개하지 않아요. 그런데 REWE 모바일 앱이나 웹사이트는 당연히 내부 API를 호출하고 있겠죠? 개발자가 한 일은 이 앱이 서버와 주고받는 HTTP 요청을 분석해서, 같은 방식으로 요청을 보내는 CLI 도구를 만든 거예요.

구체적으로는 브라우저의 개발자 도구나 네트워크 프록시(Burp Suite, mitmproxy 같은 도구)를 사용해서 앱이 어떤 엔드포인트에, 어떤 헤더와 바디로 요청을 보내는지 하나하나 파악했을 거예요. 인증 토큰은 어떻게 발급받는지, 상품 검색은 어떤 파라미터를 쓰는지, 장바구니에 담는 건 어떤 API를 호출하는지 — 이런 것들을 전부 역추적한 거죠.

왜 하필 Haskell인가

korb의 또 다른 흥미로운 점은 Haskell로 작성됐다는 거예요. Haskell은 함수형 프로그래밍 언어인데, 실무에서 흔히 쓰이는 언어는 아니에요. Python이나 Go로 만들면 훨씬 빠르게 만들 수 있었을 텐데, 왜 Haskell이었을까요?

Haskell의 강력한 타입 시스템은 API 응답을 파싱할 때 꽤 유용해요. API에서 돌아오는 JSON 구조를 타입으로 정의해두면, 응답 형태가 바뀌었을 때 컴파일 시점에 바로 잡아낼 수 있거든요. 리버스 엔지니어링된 API는 공식 문서가 없으니 언제든 바뀔 수 있는데, 이런 환경에서 타입 안전성이 오히려 방어막이 되는 셈이에요.

프로젝트 구조를 보면 Haskell의 Servant 같은 라이브러리를 활용해서 API 클라이언트를 타입 레벨에서 정의하고, Aeson으로 JSON 파싱을 처리하는 전형적인 Haskell 웹 클라이언트 패턴을 따르고 있어요.

이런 프로젝트가 주는 교훈

사실 이 도구 자체를 실무에서 쓸 일은 거의 없어요. 독일 REWE 마트를 이용하는 한국 개발자가 얼마나 되겠어요. 하지만 이 프로젝트에서 배울 점은 꽤 많아요.

첫째, 리버스 엔지니어링 실습으로 아주 좋아요. 공식 API가 없는 서비스의 동작을 분석하는 건 보안 분야에서도, 크롤링이나 자동화에서도 핵심 스킬이에요. 국내 서비스 중에도 공식 API는 없지만 내부적으로 REST API를 쓰는 곳이 많잖아요. 비슷한 접근법을 적용할 수 있는 상황은 생각보다 자주 만나게 돼요.

둘째, "내가 쓸 도구를 직접 만든다"는 마인드셋이에요. 개발자의 가장 큰 장점 중 하나가 자기 문제를 코드로 해결할 수 있다는 거잖아요. 장보기가 귀찮으면 장보기 도구를 만들어버리는 이 태도가 사이드 프로젝트의 정수라고 할 수 있죠.

셋째, 비주류 언어의 실전 활용 사례예요. Haskell을 공부하고 있지만 "이걸로 뭘 만들지?"라고 고민하는 분들에게, 이런 실용적인(?) 프로젝트가 좋은 참고가 될 수 있어요. 함수형 프로그래밍의 장점이 어디서 빛나는지 실제 코드로 확인할 수 있거든요.

법적으로 괜찮은 건가?

리버스 엔지니어링 프로젝트를 볼 때마다 나오는 질문이 있어요. "이거 합법인가요?" 답은 "경우에 따라 다르다"예요.

대부분의 서비스 약관(Terms of Service)에는 리버스 엔지니어링을 금지하는 조항이 있어요. 하지만 개인적인 용도로 자기 계정에서 자동화를 하는 것과, 이를 상업적으로 활용하거나 대규모로 데이터를 수집하는 것은 다르게 취급되는 경우가 많아요. EU에서는 상호운용성을 위한 리버스 엔지니어링을 법적으로 보호하는 조항도 있고요.

한국에서도 비슷한 맥락에서, 개인 자동화 프로젝트로 만드는 건 대체로 문제가 되지 않지만, 서비스에 과도한 부하를 주거나 데이터를 무단 수집하면 문제가 될 수 있어요. 이 부분은 항상 주의하면서 진행해야 해요.