당근 테크 밋업 후기

10월 7일 코엑스에서 열린 당근 테크 밋업 서버 트랙에 참여했다. 세션의 중간중간 많은 네트워킹 테이블이 있었지만, 수강 신청에 실패했다… 하지만 세미나만으로도 엄청난 동기부여를 받았고, 인사이트를 얻어갈 수 있는 값진 경험이었다. 학생이라 뭘 알아들을까? 싶었는데 다들 프레젠테이션을 너무 잘하셔서 전달하고자 하는 바가 잘 와닿았던 것 같다.

 

1. 당근 알바 초기 엔지니어링 전략 (박용진 연사님)

초기 제품 생산성을 위한 전략과 고민에 대해 말씀해주셨다.

초기 제품 개발 단계에서 가장 중요한 목표는 사용자에게 빠르게 가치를 전달하는 것. 이를 위해 이벤트 기반 데이터 분석 서비스를 적극 활용했다고 설명하셨다. Amplitude와 Mixpanel과 같은 도구를 사용해 데이터 분석의 효율성을 높였고, 덕분에 데이터 분석 엔지니어링 비용을 줄일 수 있었다고 한다.

특히 인상 깊었던 부분은 효율적인 에러 대응이었다. 컨텍스트 스위칭 비용을 최소화하는 전략으로 에러가 발생했을 때 즉각적으로 대응하기보다는, 모니터링을 통해 에러 발생 빈도와 핵심 기능에 미치는 영향을 확인하는 것이 우선이었다. 그러고 나서 하던 작업을 마치고 난 뒤 에러에 대응했다는 것이 충격적이었다. 보통 에러가 발생하면 즉각 대응하는 데 급급하다고 생각했기 때문이다.

또한 클라이언트와의 협업에서 GraphQL을 도입해 클라이언트가 능동적으로 데이터를 가져올 수 있도록 한 것도 매우 흥미로웠다. 데이터를 어떻게 주고 받을 것인지에 대해서는 서버-클라이언트 간 이해관계 충돌이 가장 많이 발생하는 부분이라고 생각한다. 클라이언트에게 데이터를 가져오는 것에 대한 책임을 맡기고, 이를 통해 서버-클라 간 논의 비용을 크게 줄일 수 있었다고 한다.

 

2. 우리 동네 어디까지 좁아지는 거에요? (손진 연사님)

사람마다 생각하는 동네의 범위가 다르다는 것을 반영하여 동네의 경계 범위를 지정하려는 기술적인 도전과 그 과정이 흥미로웠다. 사용자의 활동 반경을 고려하겠다는 유저 친화적인 마인드가 녹아들어 있다고 느꼈다.

Google S2, Uber H3와 같은 격자 기술만으로는 사람들이 인식하는 경계, 컨텍스트를 나누기 힘들다고 판단하여 자연경계 데이터와 Voronoi Diagram과 같은 수학 공식 등을 이용하여 여러 시행착오를 겪어 알고리즘을 개발하게 되었다고 하는데 대단하신 것 같다.

한편으론 지도에서 공간의 경계를 나누는 AI 기술이 많이 있는 것 같은데 이를 활용하지 않은 이유가 궁금했다.

 

3. 당근 채팅 시스템은 어떻게 만들까? (권영훈 연사님, 김기연 연사님)

채팅 메시지 전달과 채팅 메시지 저장으로 나눠서 발표하셨고, 당근 채팅 시스템이 어떻게 돌아가고 있는지에 대해 알 수 있었다.

메시지 전달과 푸시 알림에 대해서 온라인/오프라인, 일대일/그룹, 서버 스펙 등 다양한 케이스를 고려해서 상황에 따라 효율적인 방식과 해결방안을 공유해주셨다.

요새 가장 관심 있는 비동기 메시지 큐와 pub/sub, producer/consumer 패턴 사용을 통해 효율성, 확장성, 신뢰성을 다 가진 당근 채팅 시스템… 개인적으로 제일 이해하기 빡셌다.

채팅 메시지 저장을 위해 초기에는 하나의 RDB를 사용해 채팅 데이터를 처리했지만, 트래픽 증가로 인한 스케일 업의 한계를 겪게 되면서 채팅 DB를 메인 DB와 분리하고 샤딩을 도입했다고 한다. AWS DynamoDB를 사용해 확장성과 성능을 확보했으며, chat_id와 user_id를 파티션 키로 설정해 데이터 분배를 최적화했다고 한다. 또한, Go 언어의 고루틴과 카프카를 활용한 비동기 처리로 API 응답성을 크게 향상시켰다. 이러한 기술 적용을 통해 트래픽으로 인한 DB 장애가 거의 사라졌다는 점이 인상 깊었다. Go의 고루틴? Go 언어에도 관심이 가기 시작했다,,,

 

4. 멈춰버린 세계: 네트워크 통신 불가를 해결하기 위한 여정(feat. istio) (김성중 연사님, 정명길 연사님)

쿠버네티스 환경에서 Redis와 데이터베이스의 연결 문제로 발생한 에러들을 해결하기 위한 과정과 시도한 방법들, 회고에 대해 말씀해주셨다. JVM에서 ZGC 적용, API Performance Optimization, 요청 받는 서버 분리 등등, SQL Query Optimization에 대한 꿀팁도 얻었다. 적절한 connection timeout 시간을 설정하는 것도 중요하다고 했다. Istio의 Sidecar 패턴을 활용해 마이크로서비스 간 통신을 제어했지만, Istio proxy의 CPU throttle 문제로 인해 추가적인 트러블슈팅이 필요했고, 이를 해결하기 위해 CPU limit을 제거하고, 지속적인 시스템 메트릭 모니터링을 통해 예측 가능한 동작을 보장하려는 노력이 인상 깊었다. 끝없이 이어지는 개선 과정에서의 레슨런이 많은 배움을 주었다는데, 역시 잘 기록하고 회고해야 한다.

 

5. 지역 기반으로 중고거래 검색을 샤딩하라 (임문규 연사님)

당근의 지역 기반 특성을 활용하여 자체적인 샤딩 알고리즘 구현했다는 것이 인상 깊었다. 검색에 elasticsearch를 사용했고, 샤딩을 하는 방법들, 기존 샤딩의 단점, hot/cold architecture 등 여러가지 시도들을 소개해주셨지만, 근본적인 해결책은 지역기반 샤딩 구축이었다고 한다. 결과로써 lactency를 줄이고 인프라 비용을 감소시켰는데, 이러한 과정에서 발생할 수 있는 trade-off까지 세심하게 고려한 점에서 15년차 개발자의 노련함을 느꼈다.

 

6. 빠르게 변하는 운영 도메인에서 살아남는 코드 만들기 (윤준혁 연사님)

운영 개발팀은 내부 admin 관련 기능들을 개발한다거나 처리 자동화를 한다. 빠르게 대응하려면 확장성과 설정 가능성이 필요하다. 확장성과 설정 가능성의 정의를 ChatGPT에 물어봤다고 하셔서 웃음을 자아내기도 했는데, 그 설명이 명쾌했다.

확장성은 기능을 추가/수정할 때 최소한의 변경과 최소한의 사이드 이펙트로 대응하는 능력

설정 가능성은 코드 수정 없이 외부 설정을 통해 관리할 수 있는 능력

이러한 특성은 필수적이진 않지만 변화가 빠른 환경에서 큰 장점이 될 수밖에 없을 것 같다. 코드의 지저분한 분기문을 없애고, 메타 프로그래밍을 활용해 동적으로 동작하는 코드를 보여주셨는데, 신박했다.

또한, 코드의 주석을 활용해 개발자들이 작업 중 자연스럽게 약속을 공유할 수 있도록 한 꿀팁도 유익했다. 문서 대신 주석을 통해 정보를 공유하면 직관적으로 코드 짤 때 sync가 더 편할 것 같다고 생각했다. 주석을 더 열심히 달자.

 

7. 당근의 회원 시스템을 마이크로서비스로 분리하기 (김기혁 연사님)

초기에는 모놀리식 아키텍처를 사용했던 당근이 서비스의 급속한 확장으로 인해 여러 도전 과제에 직면하게 되었고, 하나의 서비스에서 발생한 장애가 전체 시스템에 영향을 미치면서 시스템의 불안정성이 커졌다. 그래서 회원 시스템을 마이크로 서비스로 분리하는 결정을 내렸다고 하는데, 흠… 요즘 Auth와 User 서비스 관련해서 고민이 많았는데, 그런 부분을 긁어주는 내용은 아니었다. 근데, 네이밍을 Identity로 한 것을 보고 이거다 싶었다.

특히, 모놀리스 회원 서비스를 신규 회원 서비스로 전환하는 과정에서 Istio proxy와 Sidecar 패턴을 활용하여 클라이언트 업데이트 없이 마이크로서비스로 분리한 점이 인상적이었다. 시간 날 때 공부해봐야 겠다.

DB 데이터, API 응답 동기화까지 하고, 최종적으로 모놀리스 회원 시스템을 폐기했다고 한다. 신규 시스템으로 완전히 전환하는 데 성공한 이 과정에 대한 이야기를 들으면서 변화하는 환경에 빠르게 대응하고 진화할 수 있는 능력을 잘 보여주었다고 생각한다.

 

 

 

테크 밋업 직후 머릿속에 구름처럼 둥둥 떠다니는 세미나 내용들을 정리하기 위해 복기하며 글로 작성해보았다. 배운 것들, 얻은 꿀팁 및 인사이트를 프로젝트에 녹여내기 위한 첫 걸음을 뗐다.

처음 이 테크 밋업을 신청할 때, “당근 개발자들의 생각이 궁금합니다.” 한 줄 적었는데 운이 좋게도 당첨되어서 좋은 경험을 할 수 있었다. 정말 유익했고, 이러한 테크 밋업/세미나/컨퍼런스가 자주 열렸으면 좋겠다.