반응형
- 일시: 2026년 7월 7일(화)
- 장소: HAESO 해소 (서울 성동구 성수이로24길 31)
- 주최: Devchat
Why We Gather
김경환 (네이버), 김상기 (SK텔레콤), 이동현 (카카오페이)
진행: 황국화
Q. 지금까지 가졌던 데브챗 모임 중 가장 기억에 남는 모임은?
이동현 (카카오페이)
- 장소로는 엘타워가 가장 먼저 떠오름 - 롯데 이커머스 후원으로 열린 모임
- 전망 좋은 곳에서 일하는 기분에 대한 생각, 분위기가 좋았던 기억
- 최근에는 배민(우아한형제들)에서 함께한 모임도 기억에 남음
- 장소보다 기억에 남는 자리는 내부 팀장들이 모여 발표했던 시간
- 서로 다른 회사에서 일하며 얻은 좋은 점과 고충을 나누며 공감대를 형성
김상기 (SK텔레콤)
- 2023년 데브챗 모임 시작 이후 매달 스터디 형태로 진행하다가, 그해 12월 연 데브챗 컨퍼런스가 가장 기억에 남음
- 2024년에는 데브챗 멤버들과 함께 책을 집필 - 코드 너머, 회사보다 오래 남을 개발자 (한빛미디어, 2025년 출간)
김경환 (네이버)
- 2023년 1월 팀 리더를 맡게 되면서 개발 문화/조직 문화에 대한 관심으로 데브챗 스터디에 참여
- 첫 세션은 온라인(Zoom)으로 진행, 다소 낯설었지만 그때 받은 영향력 덕분에 지금까지 애정을 갖고 참여 중
Q. AI 시대에 오프라인 모임/커뮤니티가 갖는 힘은 무엇인가?
김상기 (SK텔레콤)
- "여러분은 오늘 왜 오셨나요?"
- 사람을 만나면 상대에게 먼저 관심을 갖는 습관은 과거 코칭 활동에서 비롯됨
이동현 (카카오페이)
- 연결의 소중함 - AI와 연결하는 것보다 사람과 연결하는 게 중요해서 이 모임이 더 소중하게 느껴짐
- 데브렐은 원래 개발자와의 연결을 다루는 일이었는데, AI 시대에는 비개발자도 개발자와 같은 역할을 할 수 있게 되면서 개발자/비개발자 구분 없이 "만드는 사람들"과 연결되는 게 중요해짐
- 비슷한 고민을 하는 사람들끼리 연결돼 생각을 확장해 나갈 수 있는 기회라는 점에서 오프라인 모임이 소중함
김경환 (네이버)
- 커뮤니티에 모이는 가장 큰 힘은 관계에서 오는 동기
- 각자의 고민을 나누다 공통점을 찾고, 관계가 점점 따뜻해지면서 커뮤니티의 온기로 나타남
- 데브렐이라는 주제를 벗어나 실제 회사 업무, 살아가는 이야기까지 나누게 되는 점이 좋음
Q. 회사에서 진행 중인 AX와 데브렐은 어떤 관계인가?
김상기 (SK텔레콤)
- AX는 결국 AI를 잘 이해하게 만드는 일 - AI를 다루는 데 가장 능숙한 건 개발자
- 비개발자가 개발자들이 쓰는 용어를 익히게 만드는 것이 관건 - 그래야 AI에게 원하는 걸 제대로 시킬 수 있음
- 본인이 속한 전사 HR 조직은 대부분 비개발자
- Claude, GPT 등 AI 도구를 쓰다 개발자 용어에 막히면 그걸 잘 아는 개발자와 연결해주는 역할을 함
- 데브렐이 개발자 간 관계를 만들던 일을, AX 시대에는 비개발자를 개발자로 연결/성장시키는 일로 확장해서 하고 있음 - 결과적으로 AX 팀은 데브렐과 협업할 수밖에 없는 구조
- 본인도 AX 팀에 합류했고, 전사/사업부별로 AX 조직이 계속 늘어나는 추세
Q. 데브챗 모임에서 나눈 이야기가 실무에 도움이 된 적이 있는가?
이동현 (카카오페이)
- 모임마다 기록을 남겨 참석자들에게 공유하고, 사내에도 별도로 기록해 둠
- 특정 사례를 콕 집어 말하긴 어렵지만, 쌓인 이야기들이 업무 어딘가에 반영되는 느낌을 받음
- 다른 회사의 이벤트/행사 기획 사례를 들으며 "언젠가 써먹어야지" 하고 아이디어를 얻은 경우가 많음
Q. 데브챗을 가장 잘 설명하는 키워드는 "집단지성"과 "심리적 안정감" 중 무엇인가?
김경환 (네이버)
- 앞서 말한 "온기"와 이어지는 맥락
- 심리적 안정감 쪽이 더 잘 맞는 표현
- 안정감 있는 관계 안에서 집단지성도 좋은 형태로 나온다고 생각
이동현 (카카오페이)
- 둘 중 하나를 고르고 싶지 않음, 둘 다 중요
- 훌륭한 발표자를 섭외해 이야기를 듣고, 이후 네트워킹으로 서로 회사 사례를 비교하며 아이디어를 나누는 과정에서 집단지성을 느낌
- 회사 안에는 데브렐 역할을 하는 사람이 몇 없어 고민을 나눌 곳이 마땅치 않은데, 데브챗에 오면 다양한 연차/직무/회사의 사람들이 모여 있어 여러 아이디어가 촉발됨
김상기 (SK텔레콤)
- 집단지성은 AI 때문에 오히려 약해지고 있다고 생각
- 심리적 안정감은 프라이빗 모임이기 때문에 가능
- 회사 안에서 못할 이야기도 나눌 수 있고, 밖에서 있었던 일이라 발설 부담이 없음
- 데브챗에서 얻는 정보는 AI나 책에서는 구할 수 없는 정보라 집단지성 역시 유효 - 결국 둘 다에 해당
Build Mode, AX in Reality - AI Native 개발문화 정착을 위한 기술리더들의 고군분투기
박성우 (한국디지털에셋), 박용권 (당근마켓), 서동민 (두들린)
진행: 강상윤 (야놀자)
Q. AI를 도입하면서 계획과 실제가 달랐던 점, 겪었던 시행착오는?
서동민 (두들린)
- 올해 초부터 본격 도입, 그 전에도 GPT-4o 즈음부터 조직 내에서 조금씩 실험
- 세상이 변하는 속도를 빠르게 못 따라간 것이 가장 후회되는 지점
- 처음 만든 건 단순 요약 기능이었는데, 당시엔 "이것도 잘 못한다"며 AI를 부정적으로 봤음
- 지금 보면 AI를 보는 눈높이 자체를 너무 낮게, 제한적으로 잡았던 것이 아쉬움
박성우 (한국디지털에셋)
- AI로 인한 변화를 미리 예상하려 하지 않음
- "바이브"라는 말이 처음엔 유치하다고 생각했다가, 어느 순간부터 이 시대의 흐름을 가장 잘 표현하는 단어라고 느낌
- 그래서 바이브에 몸을 맡기고 바이브를 타는 게 가장 편했음
박용권 (당근마켓)
- 작년 2월 클로드 코드 출시 이전부터 AI와 일함, 이후로는 에이전트와 함께 일하는 게 일상화된 지 1년 반 이상
- 기대와 달랐던 점은 "생각보다 그렇게 빨라지지 않았다"는 것
- 무언가를 만드는 행위 자체는 압도적으로 줄었지만, 문제를 발견하고 검증 가능한 해결책으로 바꾸는 사고 과정, 디자인 영역은 아직 AI가 크게 못 함
Q. AI를 잘 쓰는 엔지니어들의 특징이나 패턴은?
박용권 (당근마켓)
- 한계를 스스로 정해두지 않고 "될 때까지" 끝까지 시켜보는 사람이 잘 씀
- 최근엔 출근해서 미팅/계획을 짜고 퇴근 전 AI에게 작업을 맡긴 뒤, 다음 날 아침 결과물을 확인하는 식으로 거의 24시간 활용하는 구성원도 있음
박성우 (한국디지털에셋)
- 한계를 두지 않는 사람, 업무 영역 경계에 얽매이지 않는 사람이 좋은 성과를 냄(개발자인데 디자인에도 관심, 백엔드인데 프론트도 시도 등)
- 다만 빠르고 과감한 초기 성과 이후에는 결국 책임감과 기본기가 탄탄한 사람이 진짜 의미 있는 제품을 만듦
서동민 (두들린)
- 테크(개발자)와 No테크(비개발 직군)를 나눠서 설명
- 개발자 쪽에서는 모호한 요구사항을 구체적 목표와 작은 테스트 단위로 쪼개고, 각 단위가 어떤 결과물에 도달해야 완성인지 정의하는 능력
- 추상적인 것을 구체적/정량적 표현으로 바꾸는 "문제 구체화 능력"이 뛰어난 사람일수록 AI 결과물이 의도한 것과 일치
- 비개발 직군 쪽에서는 결국 시도하는 능력
- 전사적으로 "전부 다 AI로 만들어보시라"고 독려 중인데, "이거 만들 수 있나요?"라고 물으러 오면 일단 AI에게 직접 시켜보고 안 되면 그때 다시 오시라고 안내
- 그렇게 하면 대부분 결과물이 나옴
- 한번 도전해보고 안 되면 왜 안 되는지 파악하면서 끊임없이 도전하는 사람이 성과를 냄
강상윤 (야놀자, 진행)
- 하나 덧붙이면, 회사에서 AX 프로젝트를 많이 해본 경험상 AI를 활용하지 않던 시대에도 지금도 공통적으로 잘하는 엔지니어의 특징은 직군과 스택을 넘어 공유를 잘하는 사람
- 이런 사람이 항상 회사에서 더 많은 가치를 만들어냄
Q. AI 시대, 연차(주니어/시니어/팀장급)별로 어떤 방향으로 성장하면 좋은가?
서동민 (두들린) - 주니어 대상
- 예전엔 책이나 강의로 먼저 공부한 뒤 회사 문제에 적용했다면, 이제는 책/강의 없이 회사에서 가장 어려운 문제부터 풀어보라고 제안
- 풀다가 모르는 게 나오면 AI에게 계속 물어보면서 새로운 개념을 확장해 나가는 방식으로 자연스럽게 성장 가능
박용권 (당근마켓) - 시니어 대상
- "짬(연차)으로 밀어붙이는 시니어"는 이제 의미가 없음
- 1, 2년 전 본인이 작성한 코드 퀄리티를 지금은 2, 3년 차 엔지니어도 쉽게 재현
- 코드 레벨보다 앞으로 "어떤 방향으로 뾰족하게 성장할지"에 초점을 맞춰야 함
- 프로덕트 엔지니어냐 플랫폼 엔지니어냐 등 일하는 영역에 따라 AI 시대에 기대받는 전문성이 조금씩 다름
- 최근 인상적이었던 것은 오픈AI 코덱스 팀이 엔지니어에게 기대하는 역량으로 "프로덕트 취향(product taste)"을 정확하게 짚은 것
- 이 시대에 어떤 문제를 해결해야 할지, 어떤 취향을 담아 고객에게 전달해야 우리 제품을 쓰게 할지 고민할 수밖에 없는 시대(토스도 2, 3년 전에 했던 말이고, 꽤 많은 조직이 해온 이야기지만 지금 와서 훨씬 중요해짐)
- (진행자의 "목적 조직을 어떻게 리드하는가" 추가 질문에) 특정 목적 조직 외에도 여러 조직을 겸하고 있음. 제품 리뷰/기술 리뷰/운영 이슈 등 방향을 정하는 흐름으로 조직을 리드하며, 예전엔 테크 직군과 주로 대화했다면 최근엔 기술과 AI를 함께 논의하는 경우가 늘어남
박성우 (한국디지털에셋) - 팀장급 대상
- 본인 팀은 팀원 전원이 팀장급 개발자(농담 반 진담 반)
- AI로 개인이 감당할 수 있는 업무 범위가 크게 넓어지면서 기존의 "팀" 개념 자체가 달라짐
- "한 명 한 명이 팀으로 일해야 한다"는 이야기를 팀에 하고 있음
- 제품 방향 고민이나 커뮤니케이션 범위, 기술적 의사결정의 폭과 속도가 모두 넓고 빨라져, 기존처럼 팀 리드가 조언/코칭/리뷰를 해주기엔 속도가 따라가지 못하는 상황
- "나는 도대체 뭘 하는 사람인지" 회의감이 든 적도 있음
- 결국 개개인이 넓어진 범위에서 일할 수 있는 방향과 환경을 더 치열하게 고민해야 하는데, 팀원들이 그 속도에 지쳐가고 있진 않을까 걱정되는 시기
Q. AI 시대에도 변하지 않는 개발자의 핵심 역량은?
박용권 (당근마켓)
- 20년 내내 말해온 것 - 오늘의 나보다 내일의 나를 조금이라도 더 나아지게 하려는 태도. 그 성장 포인트를 끊임없이 찾아가며 노력하는 마음가짐은 AI 시대에도 동일
박성우 (한국디지털에셋)
- 책임감
- "마침표를 찍을 줄 아는 사람"이 가장 같이 일하고 싶은 사람. AI로 속도는 빨라져도 일을 완수하는 책임은 결국 그 사람의 몫
서동민 (두들린)
- 설계 - 코드를 짜는 행위 자체는 AI가 하지만, 무엇을 어디부터 어디까지 만들지, 다른 코드에 어떤 영향을 미칠지, 어떤 방향성으로 만들지 정의하는 것은 아직 AI가 못 하는 사람의 영역
- 그래서 "내가 이걸 어떻게 만들 것인가"를 설명하는 능력이 점점 더 중요해질 것
Q. 내일부터 회사에서 딱 한 가지를 바꿀 수 있다면?
박성우 (한국디지털에셋)
- 보안 특성상 운영 환경까지는 AI를 활용하지 못하고 있는 게 아쉬움 - 운영 환경 데이터 활용 방법을 고민 중
서동민 (두들린)
- 소스 관리, 제안(PR)/리뷰, 디자인 협업 등 기존 개발 프로세스를 AI 시대에 맞게 아예 무(無)에서부터 새로 만들고 싶음
- 지금의 프로세스는 사람 중심으로 짜여 있어 AI를 잘 쓰기엔 맞지 않는다고 봄
- AWS의 AI DLC 프레임워크를 예로 들며, 직군별로 인원수를 다투던 시대는 끝났고 PM/엔지니어/디자이너 정도의 최소 구성으로도 충분히 만들 수 있는 시대라고 봄
AI DLC (AI Development Life Cycle): AWS가 제시하는, AI 활용을 전제로 재설계한 소프트웨어 개발 생명주기 프레임워크.
Inside Silicon Valley's Build Mode - Notion COO와 나누는 제품, 팀, 일하는 방식
Akshay Kothari(Notion 공동창업자 겸 COO)
진행: 이상아 (쿠팡)
Q. 노션 COO이기 전에, 실리콘밸리의 파운더이자 오퍼레이터로서 자기소개를 한다면?
- 인도에서 자라 미국에서 학사/석사를 마친 뒤, 스탠포드를 나오자마자 Pulse라는 회사를 창업
- 2013년 LinkedIn에 인수돼 약 5년 재직
- 2018년 노션에 여덟 번째 직원으로 합류해 다양한 역할을 거쳤고, 현재는 프로덕트/디자인/스토리텔링/브랜드를 맡고 있음
Q. 노션의 오리지널 비전 중 AI 때문에 바뀐 것은?
- 원래 비전은 소프트웨어 제작의 민주화
- 2천만 명의 개발자만 소프트웨어를 만들고 나머지는 쓰기만 해야 하는 구조를 바꾸고 싶었음
- 레고 블록에서 영감
- 동일한 블록으로 누구나 자신이 원하는 걸 조립할 수 있듯, 문서(docs) -> 데이터베이스 -> 자동화 -> 에이전트 순으로 "소프트웨어 블록"을 확장해 옴
- AI 이전엔 사용자가 블록을 직접 조립해야 했다면, 이제는 원하는 언어로 말하면 AI가 대신 블록을 조립해줌
- 이걸 malleable software라고 부름
Malleable Software (말랑말랑한 소프트웨어): 플라스틱처럼 사용자가 자유롭게 변형/커스터마이징할 수 있는 소프트웨어라는 의미.
Q. 지난 1년간 노션의 의사결정과 가정은 어떻게 바뀌었나?
- 3, 4개월 전 출시한 개발자 플랫폼이 가장 큰 변화
- 1년 전 노션은 MCP/제대로 된 API/워커/액션이 없는 폐쇄적 플랫폼이었음
- AI는 컨텍스트가 많을수록 좋아진다는 판단 아래, 노션을 "AI를 강제하는 폐쇄형"에서 "어떤 AI든 자유롭게 붙일 수 있는 완전 개방형"으로 전환
- 노션 자체는 기록의 시스템(system of record) 역할
Q. 여러 툴(슬랙/클로드/코덱스 등)을 오가며 일하는 개발자에게 노션은 어떻게 쓰이나?
- 개발자 플랫폼의 3가지 핵심 기능
- 임의의 데이터 소스 연결
- 특정 액션의 코드화
- 다른 에이전트를 노션 위로 불러오기
- 사내 소프트웨어 엔지니어링 팀은 노션을 하나의 "공장"처럼 사용 - 칸반 보드로 작업을 시각화하고, 클로드가 계획을 짜고 코덱스가 코드를 작성하고 또 다른 에이전트가 검수/배포하는 식
- 이 오케스트레이션 방식은 엔지니어링뿐 아니라 세일즈/마케팅 등 워크플로가 있는 모든 영역에 적용 가능
- 일부 고객은 노션 팀 자신보다도 이 방식을 더 잘 활용하고 있음
Q. 파운더 겸 오퍼레이터로서, 빠르게 변하는 AI 앞에서 전략을 어떻게 조정하나?
AI-필드 (AI-pilled): 실리콘밸리에서 쓰이는 표현으로, AI라는 새 기술의 힘을 의심 없이 받아들이고 적극 활용하는 사람을 가리킴.
- 예전엔 6개월 단위로 헤드카운트 계획과 제품 로드맵을 세웠는데, 이제는 사실상 실시간(just-in-time) 운영
- 매달 새 모델이 나오기 때문에 미리 계획하기 어려움
- 내부적으로 "모델과 싸울 수 없다, 강물이 흐르는 방향에 올라타야 한다"는 표현을 씀
- 로드맵도 향후 4-6주 정도만 구체적으로 그림
- 세 가지 축으로 방향을 유지
- 코어(문서/데이터베이스 등 시스템 오브 레코드)
- 에이전트 운영체제(에이전트/플랫폼웨어)
- 노션 링(문제 해결형 패키징 솔루션)
- 인원 수 기준 예산 대신 달러 기준 예산으로 전환
- 투자 결정도 실시간으로 이뤄짐
- 연례 컨퍼런스를 폐지하고 3개월마다 온라인으로 큰 런칭을 진행
- 물리적 행사는 준비에 6-9개월이 걸려 빠른 변화에 대응하기 어려움
Q. IC는 에이전트를 매니징하고 매니저도 IC 역량이 필요해지는 시대, 하이퍼포밍 팀은 어떻게 구성/운영돼야 하는가?
IC (Individual Contributor): 매니저 직책 없이 실무로 기여하는 개인 기여자.
- 아직 확실한 답은 없지만, 하나의 거대 팀보다 작은 팀 여러 개가 더 많은 프로젝트를 맡는 방향을 지향
- 코딩 에이전트를 제대로 다루는 2, 3명이면 상당한 힘을 낼 수 있음
- 실제로 노션의 개발자 플랫폼 전체를 12명 미만의 인원이 만듦(피자 두 판 팀 원칙)
- 기존 인력이 에이전트를 충분히 활용하도록 스킬업시키거나, 이미 익숙한 사람을 새로 채용해야 함
- 노션도 처음엔 소수의 AI-필드 직원에서 시작해, 지금은 전 직원이 AI 기반으로 사고하는 수준까지 확산됨
Q. (청중 질문) AI로 인한 "생산성 향상"이 실제 제품/서비스 생산성에 미치는 영향을 어떻게 측정하나?
Data Scout: 노션 사내에서 만든 커스텀 에이전트. 노션의 컨텍스트, MCP로 연결된 스노우플레이크(Snowflake) 데이터, 컴퓨터 사용 권한을 갖춰 데이터 사이언티스트가 하던 쿼리 작업을 누구나 할 수 있게 해줌.
- 노션의 초점은 개인이 아니라 "팀" 단위
- 한 사람이 만든 커스텀 에이전트를 회사 전체가 쓸 수 있다는 점이 핵심 힘
- 사례: 사내 엔지니어 한 명이 만든 "Data Scout" 에이전트를 하룻밤 사이 전사에 공유
- 이후 전 직원이 사실상 개인 데이터 사이언티스트를 갖게 됨
- 쿼리 1회당 3-4달러 비용에도 그만한 가치가 있다고 판단
- 데이터 사이언티스트 채용은 계속하지만, 역할이 "개별 쿼리 수행"에서 "시스템을 유지/고도화하는 역할"로 바뀜
Developer Reality Check - 개발자들은 진짜로 어떻게 생각할까?
김수빈 (당근마켓), 강현구 (센드버드), 성한영 (우아한형제들)
진행: 김만수 (센드버드)
Q. AI 사용 전후로 개발자로서의 하루가 많이 바뀌었다고 느끼는가?
성한영 (우아한형제들)
- 개발과 매니징을 병행하는데, AI를 쓴 뒤 처리할 수 있는 일의 양 자체가 늘어 요구받는 것도 많아짐
- 하루 업무가 여러 갈래의 짧은 단위로 잘게 쪼개질 만큼 달라짐
강현구 (센드버드)
- 목적에 다다르기 위한 행위(방법)는 많이 바뀌었지만, "무언가를 만든다"는 목적 자체는 그렇게 바뀌지 않음
- AI 시대가 되면서 오히려 일이 많아지고 결국 해야 할 야근은 여전히 해야 해서, 하루가 크게 바뀌진 않았다고 봄
김수빈 (당근마켓)
- 원래도 팀에서 운영하는 개발자 플랫폼/서비스 제품이 많아, AI 도입 이전부터 여러 제품을 오가며 컨텍스트 스위칭하는 운영 업무가 많았음
- AI가 이런 작업을 가속화하긴 했지만, 체감하는 컨텍스트 스위칭이나 개발량 자체는 이전과 비슷한 수준
강현구 (센드버드) - 자체 툴 제작 사례
- 슈퍼셋, 시냅스처럼 여러 터미널을 통합해 작업하는 툴이 나왔을 때도 "병렬로 일하는 게 정말 효율적인가" 의문이 있었음
- 직접 필요에 맞는 도구를 만들어보니 "도구가 없어서 그렇게 일을 못 했던 것"임을 깨달았고, 이후 일하는 방식이 많이 바뀜
성한영 (우아한형제들) - 매니저 관점
- 툴링을 직접 만드는 팀원을 볼 때, 문제 해결이 아니라 "도구를 위한 도구"를 만드는 자아실현으로 빠지는 경우를 경계함
- 그 경우가 아니라면 직접 도구를 잘 만드는 것 자체는 팀에 도움이 된다고 봄
Q. AI가 만든 결과물에 대한 신뢰도가 높은가?
강현구 (센드버드)
- 모델이 점점 좋아지면서 맡길 수 있는 일의 수준이 계속 올라가는 중
- 앞으로 더 좋아질 거라는 예측 아래 "지금 믿지 않고 쓰면 나중엔 믿을 수 있을까" 싶어 신뢰하려는 입장
- 다만 지금 당장 결과물이 늘 만족스러운 건 아니어서, 어떻게 지시해야 더 잘 쓸 수 있을지에 관심을 두는 편
김수빈 (당근마켓)
- AI 신뢰도와 리스크는 저울질이 필요
- 본인이 개발하는 사내 플랫폼은 잘못된 결과물이 배포되면 인터페이스 롤백이 어려운 경우가 있어 한 번 더 검증하는 습관을 유지
- 코딩은 99% 이상 AI 에이전트로 생성하지만, 로컬/스테이징/운영 등 여러 검증 레이어를 리스크 수준에 따라 다르게 쌓아서 신뢰도를 관리
- 예: 로컬 시뮬레이션, 스테이징 배포 후 시뮬레이션, 운영 환경 성능 테스트, 다양한 에이전트를 통한 코드 리뷰 등
성한영 (우아한형제들)
- 사내 AX 도구를 직접 개발하는 입장이라, AI에게 일을 시켰을 때 원하지 않는 방향으로 나오는 경우를 계속 마주하며 개선 포인트를 찾게 됨
- 다만 목표는 신뢰도가 높은 상태를 만드는 것
Q. 신뢰도를 높이기 위한 가드레일이나 팁이 있는가?
강현구 (센드버드)
- 원하는 결과가 나오도록 인풋(지시사항)을 최대한 구체적으로 명시
- SDK 개발 특성상 특정 부분 수정 시 사이드 이펙트 발생 여부가 중요한데, 에이전트 10개 정도를 병렬로 띄워 사이드 이펙트를 체크하고 재현율이 높은 것들을 추려 추적 - 대부분의 경우 문제 지점이 높은 확률로 드러남
Q. AI 도입 후 컨텍스트 스위칭이 늘었다고 느끼는가?
성한영 (우아한형제들)
- 코드를 손으로 직접 치지 않게 되면서 물리적으로 확보되는 시간이 늘어, "이것도 해보고 싶고 저것도 해보고 싶은" 일이 많아짐
- 그 결과 컨텍스트 스위칭도 자연히 늘어남
김수빈 (당근마켓)
- 컨텍스트 스위칭의 "종류"가 달라졌을 뿐, 종합적으로는 오히려 줄어든 느낌
- 예전엔 개발자 요청이나 이슈를 그때그때 바로 처리해야 했다면, 지금은 에이전트가 미리 처리하거나 빠르게 대응하는 경우가 늘어, 단순 업무에 쓰는 시간은 줄고 플랫폼 고도화/재설계처럼 깊은 고민이 필요한 일에 더 오래 집중하는 쪽으로 바뀜
Q. 노트 테이킹과 업무(태스크) 관리는 어떻게 하는가?
성한영 (우아한형제들)
- 매니저로서 우선순위 관리가 어려운 자리인데, 주간 단위로 클로드 등 AI 자동화를 활용해 컨텍스트를 정리
- 팀원이 업무 내용을 글로 잘 정리해서 공유해줄수록(컨텍스트가 풍부할수록) 더 잘 이해하고 해결할 수 있는데, 컨텍스트 정보가 적은 팀원의 업무는 파악하는 데 더 고민이 필요
강현구 (센드버드)
- 매니저가 아니라 개인 업무 자체는 AI 이후로도 크게 달라지지 않음 - 기존처럼 티켓 기반으로 생성/관리
- 부가적으로 들어오는 업무는 슬랙 "나에게 메시지 보내기"로 간단히 기록
- 슬랙에 클로드를 연동해두면 바로 실행하거나 컨플루언스 문서 업데이트까지 가능해 편리
김수빈 (당근마켓)
- 메신저는 슬랙, 문서화는 노션, 티켓/이슈 관리는
리니어(원문 "미디어", 정확한 툴명 확인 필요)를 사용 - 슬랙/구두로 논의된 업무가 노션에 정리되고, 그 주/그 달에 실행하기로 확정된 것은 이슈로 등록
- 이슈 하나가 에이전트 하나가 실행하는 작업 단위가 됨
- 필요하면 서브 이슈를 만들어 서브 에이전트에게 맡기고, 에이전트가 작업한 로그를 다시 이슈 코멘트로 남기는 방식
Q. IDE 없이 터미널(클로드 코드 등)만으로 작업이 가능한가?
강현구 (센드버드)
- IDE는 거의 열지 않게 됨
- 회사에서 지원하던 커서도 비용이 아까워 정리하려는 중
- 최근엔 "에이전틱 IDE"로 불리는 컴포저/슈퍼셋/오르카 같은 도구로 터미널 기반 작업을 하면서, 필요할 때만 간단히 코드를 보는 정도
김수빈 (당근마켓)
- IDE 사용 비중은 업무의 약 10% 정도
- 코드 리뷰나 직접 검증이 필요할 때, 터미널에서 눈으로 코드를 따라가기 어려운 부분을 IDE로 파악하는 용도로만 사용
Q. 회사에서 AI 도구를 얼마나 지원해주는가?
성한영 (우아한형제들)
- 클로드를 전사에 지원 중이며 전 직원이 사용
- 개발자들의 활용 속도가 매우 빠름
김수빈 (당근마켓)
- 개발자와 비개발자가 동일하게 지원받고, 원하는 것을 지원해주는 정책
- 사내에서 효용이 검증된 도구(앤트로픽 클로드, GPT/코덱스, 커서) 중 예산에 맞게 선택
- 클로드 맥스만 쓰거나, GPT와 코덱스를 반반 쓰거나, 코덱스 200달러 플랜을 쓰는 식
- 서비스에 사용하는 LLM API는 특별한 제한 없이 원하는 모델을 사용
강현구 (센드버드)
- 대부분의 툴을 지원하는 방향
- 클로드 코드는 팀 플랜이 열리자마자 전사 제공, 코덱스도 성능이 좋아진 이후 지원 시작
- 비용 측면에서 너무 비싸지지 않게 효율적으로 지원할 방법을 계속 고민 중
Q. AI를 잘 쓰는 개발자가 일도 잘한다고 느끼는가?
성한영 (우아한형제들)
- 반대라고 생각
- AI를 잘 써서 일을 잘한다기보다, 일을 잘하는 사람이 AI를 잘 가르치고 다루는 경우가 많음
- 결국 AI가 만든 코드 중 무엇을 채택할지는 사람이 정하는 것
- 이 도구를 어떻게 잘 다룰지 깊게 고민하고 접근하는 사람 자체가 희소하고, 그 고민이 이 시대에 가치 있는 것
강현구 (센드버드)
- 어느 쪽이라고 답해도 차이가 없을 것 같아 고민했는데, 시간이 지날수록 AI를 잘 쓰는 개발자가 고민도 잘한다고 느낌
- 결국 일을 잘하는 사람이 AI도 잘 쓴다는 쪽으로 둘 다 해당
김수빈 (당근마켓)
- AI를 잘 쓰는 것은 일을 잘하기 위한 여러 조건 중 하나일 뿐, AI를 잘 써도 일을 못 할 수 있다고 봄
- AI를 다루는 능력 자체는 점점 평준화되고 있다고 느낌
- 원래 일을 잘하던 사람에게 AI는 "날개를 달아주는 것"일 뿐
- AI를 위한 도구, 에이전틱 워크플로를 만드는 일 자체에 매몰되는 것을 경계
