클로드 코드 쓰다가 결국 ‘이 도구’로 갈아탄 이유 - 당근 하조은님 인터뷰

📺 원본 영상: 클로드 코드 쓰다가 결국 ‘이 도구’로 갈아탄 이유 (당근 하조은님)
🎙️ 채널: 빌더 조쉬 Builder Josh
📅 정리 일자: 2026-02-21
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.


개요

이 인터뷰는 빌더 조쉬(Builder Josh) 채널의 “하우아이(How I AI)” 팟캐스트에서 당근(Karrot) 모임팀 리드 하조은님을 초청해 진행한 대화다. 카피라이터를 꿈꾸던 문과생에서 프론트엔드 엔지니어, 그리고 현재는 제품팀 리드로 이어지는 독특한 커리어 여정이 첫 번째 이야기를 이루고, 이어서 클로드 코드(Claude Code)에서 컨덕터(Conductor)라는 도구로 AI 코딩 환경을 전환하게 된 이유, 당근 내부의 독자적인 AI 도구 생태계, 그리고 AI 시대에 개발자가 갖춰야 할 핵심 역량에 대한 통찰이 차례로 펼쳐진다.


문과생에서 프로덕트 리드까지 - 하조은의 커리어 여정

하조은님의 커리어는 흔히 접하는 개발자의 길과는 사뭇 다른 궤적을 그린다. 원래 카피라이터를 꿈꾸며 언론학과 경영학을 전공했던 그는, 대학 시절 창업경진대회에 두 차례 참가하면서 결정적인 전환점을 맞이한다. 당시 팀에는 번번이 개발자가 없었고, 하조은님은 “그냥 내가 조금 배우면 되지 않을까”라는 생각으로 독학을 시작했다. 처음에는 창업의 보조 수단으로 시작했던 코딩이 어느 순간 그 자체로 깊이 있는 재미를 지닌 일임을 깨달으면서, 결국 개발자의 길을 본업으로 택하게 됐다.

이후 마플(Mapl), 뱅크샐러드(Banksalad)를 거쳐 당근에 합류한 배경에는 ‘사회적 문제 해결’이라는 일관된 가치관이 자리 잡고 있다. 비영리 단체에 관심이 많았던 그는 영리를 추구하면서도 사회적 가치와 방향이 맞닿아 있는 회사들을 찾아왔다. 마플에서는 크리에이터 이코노미(Creator Economy)를, 뱅크샐러드에서는 금융 정보의 비대칭 문제를 다루며 이 철학을 실천했다. 당근으로의 합류에는 더욱 개인적인 계기가 있었는데, 동생이 당근 모임 서비스를 통해 마음이 맞는 사람을 만나 결혼까지 이르게 된 것이다. 청년 고독 문제와 지역 커뮤니티의 힘을 몸소 목격한 그는, 당근이 이 문제를 해결할 수 있는 플랫폼이라는 확신을 갖고 입사를 결정했다.

당근에서 약 3년간 프론트엔드 엔지니어로 재직하던 하조은님은 인터뷰 시점 약 6개월 전부터 모임팀의 제품팀 리드로 역할을 전환했다. 뱅크샐러드에서 한 차례 매니저를 경험했지만 “개발이 너무 좋아서” 당근에 올 때는 다시는 매니저를 하지 않겠다고 다짐했던 그였다. 그럼에도 리드 역할을 수락한 이유는 두 가지다. 하나는 장기간 한 회사에 몸담으며 쌓인 신뢰와 크레딧을 바탕으로 이제는 IC(Individual Contributor)를 넘어선 더 큰 임팩트를 낼 수 있겠다는 판단이었고, 다른 하나는 AI의 발전이었다. 예전에는 자신 없었던 데이터 분석이나 전략적 의사결정 영역에서도 AI의 도움을 충분히 받을 수 있게 됐다는 확신이 새로운 도전에 대한 두려움을 크게 덜어준 것이다.


당근 모임 서비스 - 동네 사람들이 연결되는 공간

당근은 창업 초기부터 “커뮤니티가 되어야 한다”는 창업자들의 비전을 품고 있었다. 중고거래 플랫폼으로 대중에게 알려졌지만, 커뮤니티 탭은 처음부터 존재했고 경영진은 하이퍼로컬(hyper-local) 커뮤니티의 가능성을 믿으며 꾸준히 투자해왔다. 현재 당근의 커뮤니티 기능은 동네 생활, 모임, 카페, 아파트의 네 가지 형태로 운영된다.

그 중에서도 하조은님이 담당하는 모임 서비스는 독특한 성격을 지닌다. 동네 생활 탭이 지역 주민 누구나 글을 올리고 소비할 수 있는 오픈 커뮤니티라면, 모임은 특정 관심사를 가진 사람들이 프라이빗하게 모여 실제 오프라인에서 만나는 것을 목적으로 하는 폐쇄형 커뮤니티다. 배드민턴, 러닝, 감자튀김 먹기 모임 등 다양한 취향의 모임이 존재하는데, 최근에는 성인들끼리 어릴 적 즐기던 경찰과 도둑 게임을 실제 공원에서 진행하는 모임이 큰 인기를 끌고 있다고 한다. 서울 올림픽 공원을 넘어 부산 온천천, 전국 각지의 공원으로 확산되고 있다는 사실은 디지털 플랫폼이 만들어내는 오프라인 연결의 힘을 잘 보여준다.


클로드 코드에서 컨덕터로 - 에이전트 중심 개발의 진화

컨덕터(Conductor)가 바꾼 개발 방식

하조은님이 인터뷰에서 가장 구체적으로 소개한 도구는 컨덕터(Conductor)다. 클로드 코드(Claude Code)를 메인 AI 코딩 엔진으로 사용하면서도, 이제는 IDE를 거의 열지 않는다고 밝혔다. 컨덕터라는 도구가 기존 개발 방식의 패러다임 자체를 바꾸기 때문이다.

💡 [영상 참조] 강연자는 이 부분에서 컨덕터의 인터페이스를 화면으로 보여주며 설명합니다. 상세 내용은 원본 영상을 확인하세요.

컨덕터가 기존 IDE 기반 AI 도구와 근본적으로 다른 점은 화면 구성의 주인공이 바뀐다는 것이다. 기존 개발 환경에서는 코드 에디터가 화면 중앙을 차지하고 AI 에이전트는 오른쪽 패널에 부속처럼 존재했다. 개발자는 코드를 보며 AI와 대화하는 방식이었다. 반면 컨덕터에서는 에이전트가 메인이고 코드는 필요할 때 열어보는 보조 수단이 된다. 개발자는 코드를 직접 수정하는 대신 에이전트가 작성한 코드에 코멘트를 남기는 방식으로 소통한다.

하조은님은 이 경험을 “옆에 개발자를 앉혀두고 대화하면서 내가 원하는 걸 만들어 달라고 하는 것”에 비유했다. “이런 기능을 만들어 주실 수 있어요?”라고 요청하면 AI가 구현해오고, “이렇게요?”라고 확인을 받으면 “아니요, 이렇게요”라고 수정을 요청하는 식의 순수한 대화 인터페이스가 구현된 것이다. 멀티 세션을 통해 여러 작업을 병렬로 진행할 수 있다는 점도 강점이다. 이 덕분에 하조은님은 제품팀 리드로서 회의, 데이터 분석, 디자이너 협업을 진행하는 동안 AI가 별도로 개발 작업을 처리하고, 돌아왔을 때는 준비된 결과물을 확인한 뒤 Pull Request를 올리는 방식으로 일할 수 있게 됐다.

호스트인 빌더 조쉬는 컨덕터를 처음 들었을 때 오픈소스 코딩 도구(OpenCode 계열)와 비슷한 개념이 아닌가 생각했다고 언급했다. 하조은님은 커서(Cursor)나 다른 AI 코딩 도구들도 멀티 에이전트 세션 방식으로 발전하는 추세이지만, 컨덕터는 이미 에이전트 중심 개발이라는 방향에서 한 발 앞서 있다고 평가했다.

모델 선택 철학: Claude Opus로 충분하다

다양한 AI 모델을 역할별로 분리해 사용하는 오케스트레이션 전략, 즉 기획은 Codex(OpenAI), 개발은 Claude Code, 디자인은 Gemini와 같이 역할을 분배하는 방식에 대해 하조은님은 철학적으로는 동의하면서도 현재 자신의 상황에서는 굳이 필요하지 않다고 밝혔다. 개발이 현재 주 업무가 아니기 때문에 토큰 소비량이 많지 않고, 회사에서 지원하는 요금제 덕분에 비용 효율보다 사용 편의성을 우선할 수 있다. 무엇보다 Claude Opus만으로도 대부분의 작업을 충분히 잘 처리한다는 것이 그의 판단이다. 다만 개인 프로젝트에서는 각 모델의 강점을 살린 오케스트레이션을 더 적극적으로 시도해볼 의향이 있다고 덧붙였다.


당근의 AI 도구 생태계 - 내부에서 직접 구축한 에이전트들

카비(KAVI) - 슬랙 기반 통합 에이전트

당근이 내부적으로 운영하는 AI 도구 중 가장 인상적인 사례는 카비(KAVI)다. 카비는 슬랙봇(Slackbot)으로서 슬랙의 대화 컨텍스트, GitHub 레포지토리, 그리고 노션(Notion) 문서 세 가지를 모두 인덱싱하고 있다. 이 세 가지를 종합하면 당근 내부의 거의 모든 컨텍스트를 파악할 수 있기 때문에, 카비는 사실상 회사 전체의 지식을 담은 통합 에이전트 역할을 수행한다.

실제 활용 워크플로우는 다음과 같다. 유저가 버그를 슬랙으로 신고하면, 해당 메시지 스레드에서 카비를 호출해 “이분이 이런 문제가 있다고 하는데, 원인을 찾아줘”라고 요청한다. 그러면 카비가 코드베이스와 정책 문서를 뒤져 원인을 규명하고, “정책상 이게 맞아요” 혹은 “코드에서 정책과 다른 로직을 발견했어요”라는 형태로 답변한다. 문제가 확인되면 “수정해서 PR 올려”라는 지시로 다음 단계가 시작되는데, 이 모든 과정을 운영 매니저, 디자이너, PM 등 개발자가 아닌 직군이 수행할 수 있다는 점이 핵심이다. 카비가 생성한 Pull Request에 대해 개발자는 코드 리뷰, 승인, 그리고 배포만 담당하면 된다. 개발 전문 지식 없이도 버그 발굴에서 코드 수정 PR 생성까지의 전체 파이프라인을 구동할 수 있는 환경이 조직 내에 갖춰진 것이다.

VOC 플레이그라운드, 프롬프트 스튜디오, 캐럿챗

전사 레벨에서는 유저의 목소리(VOC, Voice of Customer)를 수집하고 분석하는 ‘VOC 플레이그라운드’가 운영된다. 유저들의 활동 스타일과 요구사항을 취합해 정책 수립이나 제품 개선에 반영하는 용도다. 내부 업무 전반에 걸친 아이디어 발굴과 기획에는 캐럿챗(CarrotChat)이라는 ChatGPT 유사 도구가 쓰인다.

팀 레벨에서는 ‘프롬프트 스튜디오(Prompt Studio)‘가 주목할 만하다. 이 도구는 사용자의 자연어 입력을 JSON 형태로 변환하는 역할을 한다. 예를 들어 당근 모임의 일정 생성 기능에서는 유저가 일정을 만들기 전에 해당 요청이 LLM을 거쳐 처리된다. 모임의 성격과 모임장의 과거 활동 패턴을 분석해 “이런 일정을 만들어보시는 건 어떨까요?”라며 맞춤형 제안을 다섯 가지 제공하고, 글쓰기 문체와 선호 장소까지 반영한 초안을 자동으로 작성해주는 방식이다.

또 다른 사례로는 모임장들을 위한 연말 감사 편지 자동 생성이 있다. 수많은 모임장에게 개인화된 편지를 일일이 작성할 수 없는 상황에서, 당근의 말투와 톤앤매너가 담긴 프롬프트 템플릿에 각 모임장의 활동 데이터를 결합해 “당근스러운” 편지를 자동 생성했다. 그 결과 모임장들이 소셜 미디어에 편지를 공유할 만큼 큰 호응을 얻었다. 서비스를 운영하는 입장에서 핵심 파트너인 모임장들과의 관계를 AI가 도와서 깊게 만든 셈이다.

디자이너도 PR을 올리는 세상

당근에서는 디자이너들이 AI 코딩 도구를 활용해 직접 Pull Request를 생성하는 워크플로우가 자리 잡고 있다. 피그마(Figma) 디자인 스펙과 실제 구현 사이의 간극을 확인하고 싶을 때, 디자이너가 직접 AI 에이전트에게 “이 컴포넌트의 픽셀 수치가 맞는지 확인해줘”, “디자인 토큰이 올바르게 적용됐는지 봐줘”라고 질의할 수 있다. 문제가 발견되면 내부 에이전트를 통해 직접 PR을 생성하기도 한다. 예전에는 피그마 데브 모드로 스펙을 전달해도 100% 동일하게 구현되기 어려웠던 프론트엔드 정밀도 문제가, 이제는 디자이너가 직접 코드 레벨에서 검증하고 수정하는 방식으로 해소되고 있다.


당근의 AI 트랜스포메이션 - 쇼앤텔에서 전사 문화로

당근의 AI 전환 과정은 탑다운(Top-down)과 바텀업(Bottom-up)이 자연스럽게 결합된 사례로서 주목할 만하다.

초기에는 개발자들이 흥미 위주로 AI를 가지고 놀던 단계였다. 이후 경영진 레벨에서 “AI First로 가야 한다”는 메시지가 명확하게 전달되면서 분위기가 조성됐다. 이를 실천적으로 뒷받침한 것이 매주 화요일 전사 미팅 시간에 운영한 ‘AI 쇼앤텔(Show & Tell)’ 프로그램이었다. 각 팀이 AI를 활용해 이룬 성과를 자랑하는 시간으로, 별도의 화려한 발표 자료 없이 노션 페이지에 정리한 사례를 그대로 공유하는 방식이었다. 발표를 보고 나면 다른 팀들이 “우리도 저거 해보자”, “왜 우리는 저게 없지?”라며 자연스럽게 자극받아 시도하게 됐다. 이 과정을 약 세 달 반복하자 AI를 업무에 기본적으로 고려하는 것이 당근의 체질이 됐다.

그 이후부터는 바텀업으로 전환됐다. 구성원들이 직접 “클로드 코드가 좋다”, “커서(Cursor)가 효율적이다”라는 식으로 도구를 소개하면, 기술 의사결정자들이 검토해 엔터프라이즈 라이선스로 도입하는 방식이 자리를 잡았다. 연말 성과 정리 에이전트처럼 구성원이 개인적인 불편함을 해소하기 위해 즉흥적으로 만든 도구들이 전사로 퍼지는 사례도 생겨났다. 슬랙과 Jira 기록을 에이전트가 자동으로 취합해 1년 성과를 정리해주고, “이 사람이 올해 가장 많이 쓴 단어”나 “가장 많이 호출한 동료” 같은 재미있는 인사이트를 곁들여주는 도구가 그 예다.

보안을 설계의 출발점으로

당근이 내부 AI 도구를 직접 구축하는 가장 큰 이유 중 하나는 보안이다. 수백만 명의 유저 데이터와 코드베이스가 외부 서비스에 노출되는 리스크를 막기 위해, 프롬프트 스튜디오, 캐럿챗, 에이전트 관리 도구인 캠프(Camp) 등 주요 도구들을 모두 자체 보안 환경 안에 구축했다. 하조은님은 “편리함도 중요하지만, 빈틈없이 보안을 갖춘 뒤에 그 편리함을 누려야 진정한 의미가 있다”는 입장을 강조했다. 이 철학은 당근의 DNA인 ‘메이커(Maker) 문화’와도 맞닿아 있다. 시장에 마땅한 도구가 없으면 직접 만든다는 빌더 정신이 AI 전환 과정에서도 그대로 발휘되고 있는 것이다.


AI 시대 개발자의 역량 - 공감과 책임

채용의 기준이 바뀌었다

하조은님은 AI의 등장으로 엔지니어로서의 전문 지식에서는 AI가 인간을 압도하는 시대가 왔다고 단언한다. 그렇다면 같은 수준의 AI 활용 능력과 기술 지식을 가진 사람들 사이에서 채용의 변별력은 무엇이 될까. 그가 제시하는 답은 “문제에 대한 공감 능력”이다.

스타트업은 결국 특정 문제가 해결된 미래를 향해 달려가는 조직이다. 그 여정에 동승할 사람을 뽑을 때 가장 중요한 것은, 그 문제에 진심으로 공감하고 같이 해결하고 싶어 하는 마음이 있느냐는 것이다. 아무리 AI를 잘 다뤄도 “개발자가 돈을 많이 준다니까 시작했다”는 사람보다, “그 문제 저도 재밌어 보여요, 저도 해결해보고 싶어요”라고 말할 수 있는 사람을 더 뽑고 싶을 것이라는 논리다. 이 공감 능력은 과거에는 시니어나 매니저 레벨에서나 기대하던 역량이었는데, 이제는 신입 1년차에게도 이를 요구하는 시대가 됐다는 것이 하조은님의 진단이다.

코딩 허들은 낮아졌지만, 기대 수준은 높아졌다

AI 덕분에 3년차, 5년차 수준의 코딩 역량은 하루아침에 갖출 수 있게 됐다. 그러나 이는 역설적으로 그 다음 단계의 역량을 더 빨리, 더 일찍부터 갖춰야 한다는 압박으로 작용한다. 프론트엔드만 잘하던 개발자는 이제 백엔드와 DevOps도 어느 정도 알아야 하고, 배포 자동화도 능숙하게 처리할 수 있어야 하며, 제품에 대한 이해와 데이터 분석 능력까지 갖춰야 한다. 이를 포괄하는 용어로 최근 주목받고 있는 것이 바로 ‘프로덕트 엔지니어(Product Engineer)‘다. 기획자 수준의 제품 인사이트, 매니저 수준의 커뮤니케이션 역량, 그리고 풀스택 개발 능력을 동시에 갖춘 말 그대로의 미니 파운더(Mini Founder)를 업계가 요구하기 시작한 것이다. 하조은님은 이를 “말도 안 되게 어려워진 것”이라고 표현하면서도, 변화에 빠르게 기민하게 대응해온 개발자들이 이 변화에서도 살아남을 것이라는 낙관적인 전망을 더했다.

오너십과 책임 - 인간이 존재해야 하는 이유

AI가 코드를 빠르게 많이 짜줄수록, 그 코드에 대해 책임지는 사람의 중요성은 오히려 커진다. 하조은님은 이것이 AI 시대에 인간 개발자가 존재해야 하는 핵심 이유라고 말한다. 디자이너도 AI를 이용해 코드를 짤 수 있게 됐지만, 그 코드가 실제 유저에게 안정적으로 서비스되도록 끝까지 책임지는 것은 다른 차원의 일이다. 장애가 생겼을 때 달려와서 해결하고, AI가 만들어낸 코드의 품질과 안전성을 보증하는 오너십(Ownership)을 갖는 사람이 조직에는 여전히 반드시 필요하다. “제가 맡아보겠습니다”라고 먼저 나설 수 있는 사람의 가치가 줄어드는 것이 아니라 오히려 더 빛나는 시대가 온 것이다.


마무리 - 즐기다 보면 답이 나온다

하조은님은 AI 시대를 두려워하는 개발자들에게 이렇게 말한다. 두려움은 당연하고 자신도 그런 사람 중 하나라고 솔직히 인정하면서도, 개발자는 누구보다 AI를 쉽게, 즐겁게 다룰 수 있는 위치에 있다는 점을 강조한다. 과거에는 엄두도 내지 못했던 프로젝트에 AI와 함께 서슴없이 뛰어들 수 있게 됐고, 그 과정 자체가 기회이자 즐거움이자 놀이라는 것이다. 앞으로 그 역할을 무엇이라 부를지는 아직 정해지지 않았지만, 어떤 형태로든 가치 있는 활동으로 인정받는 날이 계속 올 것이라는 낙관적인 전망을 남겼다. 빌더 조쉬의 표현처럼, 그 미래의 이름은 어쩌면 “빌더(Builder)“일지도 모른다.


📚 출처 및 참고

구분내용
원본 영상클로드 코드 쓰다가 결국 ‘이 도구’로 갈아탄 이유 (당근 하조은님)
채널빌더 조쉬 Builder Josh
리포트 작성2026-02-21
작성 방식YouTube 영상 STT 변환 후 에디팅

💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.