'요즘 당근 AI 개발'을 읽고 - 개발/비개발 직군의 AI 활용

요즘 당근 AI 개발 - 당근 팀 지음

몇 달 전, 교보빌딩 지하 서점에서 베스트 셀러에 '요즘 당근 AI 개발'이 있는 걸 봤다.

 

혹시 서울대 도서관에도 있으려나? 하는 생각이 들어 어제 검색해봤는데, 마침 1권이 남아있었다.

반납 기한이 다가오는 책도 있어서, 겸사겸사 도서관에 방문하기로 했다.

 

요즘 당근 AI 개발

 

실물로 만난 책은 생각보다 두께가 얇아서 가볍게 읽을 수 있을 것 같았다.

빌려서 집에 가려던 마음을 돌려서 열람실 구석에 자리잡고 앉았다.

가볍게 40분 만에 읽을 수 있었다.

 

'AI 개발'이라는 제목을 봤을 땐 '엔지니어들이 AI를 활용하는 법'을 전문적으로 다룬 책일 것이라고 생각했다.

그런데, 비개발직군의 분량이 꽤 많아서 놀랐다.

'당근의 전 직군은 AI를 이렇게 쓰고 있어요'라는 홍보를 위한 책처럼 보였다.

 

비개발직군의 좌충우돌 바이브코딩 시나리오가 나오고,

중간중간 감초처럼 엔지니어들의 AI 활용 시나리오가 배치되어 있었다.

개발자인 내 입장에서는 마치 적절한 단짠단짠 배합같아서 후루룩 잘 읽혔다.

---

Part1 - AI 활용의 첫 걸음

OM(Operation Manager)과 PM(Product Manager)의 글이었다.

 

보통 회사 내부에서 쓰이는 Admin 시스템은 실무에 나가는 제품만큼 높은 퀄리티를 요구하지 않는다.

그래서 기존에는 단기 인턴을 채용해서 가볍게 구축하는 식으로 운영해왔던 것 같다.

내가 대학생 시절 만났던 대다수의 대기업 인턴 공고들이 그런 느낌이었다.

 

이제 AI가 발전해서 그 인턴들의 자리를 대체할 수 있게 된 느낌이 들었다.

간단한 입력 폼 UI 만들고 API 붙이는 정도는 렌더링 사이클이나 fetch 정합성이 크게 필요하지 않으니,

전문적인 개발자 없이도 바이브 코딩으로 PM이 직접 만들 수 있게 된 것이다.

 

사실 어떻게 보면 아이디어만 있으면 즉각 코드로 구현해서 MVP로 실테스트를 할 수 있는 환경이 된 것이다.

단순히 '이럴 것이다'라고 추측하고, 가장 나은 안을 골라서 개발팀에게 전달하는 과정을 생략하고,

기획->구현->시장테스트를 거친 후 살아남은 제품만 개발팀이 디벨롭하는 효율적인 과정이 된 걸수도 있다.

 

좋은 방향이다. (주니어 입장에서 좀 묘하게 들리긴 하지만...ㅎㅎ)

---

이 챕터에서 당근 팀이 AB 테스트로 제품을 디벨롭하는 과정을 볼 수 있어서 좋았다.

 

LLM을 붙여서 판매한 중고 상품이 판매자에게 '추억이 담긴 편지'를 쓰게 했다.

 

단순히 '판매자 후기 작성' 알림을 보낸 대조군과

'후기를 작성하고 편지를 잠금해제' 알림을 보낸 실험군을 비교하는 과정이 담겨있었다.

 

'판매자가 후기를 작성하는 과정'이 귀찮게 느껴지지 않고 흥미롭게 느껴질 수 있도록,

'후기를 쓰면 잠금이 풀린다'라는 아이디어에 도달해 기존 대비 알림 클릭율을 2배 이상 증진시키고, 후기 작성률도 대폭 늘렸다.

 

B2C 프로덕트를 만들면서 수많은 AB test를 했고,

살아남는 프로덕트와 가차없이 버려지는 프로덕트를 수없이 마주했다.

테스트 결과를 보며 복잡미묘한 감정을 느끼곤 했는데,

당근처럼 큰 회사도 실험들을 반복하며 희노애락을 느끼고 있구나하는 생각이 들었다.

 

---

Part2 - AI 기반 운영 자동화 및 시스템 연동기

제품 운영 업무는 크게 두 가지로 나뉜다.

 

첫째, 유지보수 작업(KTLO, Keep The Lights On)

둘째, 신기능 개발

 

이 제품을 성장시키려면 신기능을 개발해서 새로운 룸을 찾아야 하는데,

그럴 때마다 KTLO 업무가 밀려들면 참 난처한 상황이 된다.

 

기능 개발에 시간을 쓰고 싶은데 운영 업무에 자꾸 시간을 뺏겨서

신기능 개발 퀄이 낮아지는 기분이 들 때마다 좀... 그렇다.

 

이런 업무들을 자동화하면 할수록, 제품 성장에 더 리소스를 쓸 수 있다.

 

당근 비개발직군분들은 VoC나 앱 리뷰에 대한 자동 분류 처리를 하는 시스템을 만들었다.

 

당근 개발직군분들은 온콜 업무(VoC 대응으로 보임)를 처리하기 위한 MCP를 만들었다.

내부 데이터를 외부 LLM 모델이 직접 읽게 하는 건 보안 이슈가 있어서,

gRPC를 사용해 접근/변경 가능한 데이터 경계를 설정했다고 한다.

 

전반적으로 LLM을 사용해 업무를 자동화하되, 내부 데이터 유출을 막을 수 있는 방안을 많이 고민하는 듯 보였다.

 

이슈 대응을 위해 여러 MCP를 소개했는데, Sentry/GitHub/DataDog MCP를 사용하고 있다고 했다.

 

나도 Sentry MCP로 에러 파악을 유용하게 하고 있는데, 글에서 소개되니 반가웠다.

(관련 글: MCP로 개발 생산성 3배 올리는 법: https://developer-dreamer.tistory.com/216)

 

Sentry에서 단순히 '이 코드 부분이 문제에요' 하고 알려줄 때보다,

해당 레포에 연결된 AI chat에 Sentry 이슈 url을 붙여넣고 MCP로 분석하는 게 레거시 맥락 파악에 도움이 됐다.

 

---

Part3 - LLM을 이용한 개발기

중고거래 물품의 시세 지표를 만드는 스토리가 흥미로웠다.

 

당근 내부에서는 빅쿼리를 사용하는데,

자연어로 분석하고 싶은 내용을 입력하면 알아서 쿼리를 짜서 조회/분석하고 결과를 출력해준다.

(우리 회사도 비슷한 툴인 Databricks를 PoC 중인데, 내가 쿼리를 몰라도 궁금한 부분을 보고 싶을 때 뽑을 수 있어서 좋다.)

 

이 빅쿼리를 사용해 중고 거래글에서 뽑은 시세 조회 데이터를 전처리한 후, 그 내용만 MySQL에 옮겨서 저장했다고 한다.

사용자에게 시세를 바로 서빙하기 위해서는 시세 데이터를 빅쿼리보다 MySQL에 놓는 게 낫다는 판단을 한 것 같다.

 

그리고, 시세 통계와 함께 해당 상품에 대한 실제 게시글도 같이 두는게 ux적으로 낫다는 판단을 했는데

이 관련 게시글을 찾는 과정도 쉽지 않은 것 같았다.

 

MLE가 없다면 파인튜닝을 하기 어려워서 '유사한 게시글'을 뱉는 게 어려우니...

게시글 내의 키워드를 뽑아서, 무관한 단어가 있으면 감점, 핵심 단어가 있으면 득점 형태로 구현했다고 한다.

 

제품의 한영 표기 차이와 대소문자 차이를 보완하는 로직, 동의어 처리 등도 했다고 하는데,

엔지니어분은 이걸 한 문장으로 퉁쳤지만...

나는 자꾸만 이 뒷면의 눈물로 얼룩진 노력이 고봉밥으로 쌓여있는 게 보였다...

 

사실상 AI 모델 없이 로직 만으로 최대한 최적화된 추천 로직을 만든 것이니...ㅠㅠ

---

PM분이 만든 또다른 추천 기능이 있는데,

어떤 물건을 살지 고민될 때 AI 채팅 기능을 사용해 도움을 주는 것이었다.

 

예시 중 하나가 '3살 조카가 좋아할 만한 장난감 추천해줘'였다.

 

여기에서 기획자의 센스가 보였던 엣지 케이스가 있었다.

LLM이 답하기 어려운 질문에 어떻게 반응할지 궁금했고, 예시로 던져본 질문이

'다음 달 주식 시장은 어떻게 될까?'였다.

LLM은 '주식 시장 변동성에 지쳤나요?' 하면서 스트레스 해소 물품을 추천했다.

 

난 이 한 문장이 PM의 유연한 사고를 보여주는 대목처럼 보였다.

주어진 기능의 input과 output에 몰입하는 엔지니어와 다르게 좀 말랑말랑한 것 같다고 해야하나...

---

AI 플랫폼과 AI 에이전트 개발기

이 챕터에서 가장 기억에 남는 건

'AI로 맥락에 맞는 UI를 제공한다'라는 개념이었다.

 

사용자가 원하는 것을 AI로 파악해서, UI 요소를 동적으로 조합해 보여주는 것이다.

이를 '생성형 UI'라고 한다.

 

사용자의 input을 분석해 의도를 파악하고,

미리 선언된 UI 컴포넌트 중 필요한 것만 조합해서 UI를 그려낸다.

 

보통 서비스에 붙인 챗봇은 질문을 입력하면 정해진 답변을 뱉어내는 느낌이 강했다.

사실 개인적으로 이런 건 FAQ를 찾아서 읽는 거랑 크게 다르지 않다고 생각하고,

그래서 상담사와 직접 연결할 수 있을 때까지 버튼을 누르는 것에 귀찮음을 느꼈다.

 

하지만, 이 아이디어는 AI 에이전트가 단순히 '답변'을 하는 것을 넘어

'동적으로 상황에 맞는 액션을 적절히 취하도록' 만든 것이다.

 

이 글은 1부/2부로 나뉘어 있을 정도로 분량이 길었고, 부록 B까지 있었다.

그런데, 읽는 내내 흥미진진해서 이 글이 왜 마지막으로 배치됐는지 알 것 같았다.

 

나도 이런 프로덕트를 만들어보고 싶다, 하는 생각이 자연스럽게 드는 글이었다.

 

---

결론

읽다보니 어떤 패턴이 보였다.

 

비개발직군들이 바이브코딩으로 만들어내는 결과물은 '만든다'보다 '쓴다'가 더 중요했다.

(당연하다. 개발자가 아닌 사람들이 리소스를 써서 코딩을 하는 이유는 진짜 너무 필요해서이다.)

 

개발직군은 이 문제를 해결하기 위해 어떤 툴이 '어떻게' 쓰였는지를 설명했다.

(당연하다. 엔지니어는 원래 설계를 업으로 하는 사람이니까.)

 

AI는 PoC는 정말 기가 막히게 말아준다.

중요한 건 그걸 유지보수하는 시점부터 말을 잘 안듣기 시작한다는 건데...

지금 당근의 AI 사이클이 어디까지 왔는지 궁금하다.

내부에서 그 PoC 이후 단계에 터지는 버그들을 어떻게 잡았을까?

 

이 책의 1쇄 발행 시점은 25년 10월 10일.

이로부터 지금 5개월 정도가 지났다.

지금은 또 어떤 모습이 되었을지 궁금하다.

---

책을 다 읽고나니 도서관 폐장 시간이 되었다.

독후감은 집에 가서 정리할 심산이었기에 대출을 해서 책을 들고 나왔다.

 

서울대 중앙도서관에서 나오는 길에 바라본 풍경

 

슬슬 봄이 오고 있는지, 해가 길어졌다.

5시가 되어도 환했다.

 

도서관에서 계단을 걸어내려오면 코너를 꺾었을 때 바로 보이는 정류장에서 버스를 타면 집에 갈 수 있다.

그런데, 어째서인지 오늘 버스에 사람이 너무 많아서 탈 수 없었다.

개강파워인가..?

 

결국 조금 더 걸어내려가서 행정관 입구에서 버스를 타려고 했는데,

네이버 지도에서 3분 뒤 도착이라고 뜨던 버스가 귀신같이 사라져버렸다.

 

 

결국 한참을 더 걸어내려가 서울대 정문까지 내려왔다.

20분 넘게 걸은 것 같다.

 

봄이 다가오는데 여전히 가을 같은 분위기를 낸다.

산이라 그런가...

 

책도 읽고 산책도 하고, 좋은 게 좋은거지~

그런 생각이 들었다.

 

작성: 2026.03.21 23:01