AI와 협업하는 조직으로의 여정

제품 조직에서 AI와 함께 일하는 방식을 어떻게 바꿔왔는지 정리한 발표입니다.

2025년, AI 에이전트를 사용(Use)하기 시작하면서 코드 생산량은 빠르게 늘었고 직군의 경계가 흐려졌습니다. 그러나 우리는 더 빨라졌는데 더 정신없이 일하고 있었습니다. 개인의 속도가 곧 조직의 생산성으로 이어지지는 않았습니다.

제너러티비티(Generativity) 관점을 빌려, 사용을 넘어 에이전트를 만들고 운용(Build) 하기 시작한 시도를 다룹니다. 범용 에이전트는 우리의 제품도, 기준도, 일하는 흐름도 모르기 때문에 조직의 맥락을 자산으로 설계해야 했습니다.

지금 시점에서 사람은 판단/검증 기준 설계로 올라가고, 에이전트는 구현/초안/테스트/검증을 더 많이 맡고, 조직은 그 둘이 함께 일할 수 있도록 컨텍스트/워크플로우라는 기반을 제공하는 것을 AI 네이티브라고 정의하기로 했습니다.

같은 질문 앞에 서 계신 분들께 참고가 되기를 바랍니다.

Transcript

1. "*৬
   ഈসೞח
   ઑ૒ਵ۽੄
   ৈ੿ ׼Ӕ݃௄
   ழޭפ౭प੉
   "*৬
   ೣԋ
   ੌೞח
   ߑधਸ
   ߄Լৡ
   ӝ۾ !BSBXO !BSBXO   ߅ਊӂ
2. ߅ਊӂBQQMZ
   \
   
   
   PSHBOJ[BUJPO
   
   ׼Ӕ݃௄
   
   
   SPMF
   
   ূ૑פয݂
   ݒפ੷
   !
   ழޭפ౭प
   
   
   JT5BMLBUJWF
   
   USVF
   
   
   EFGBVMU1MBZCBDL4QFFE
   
   
   ^
3. ੉ਓ р ࣗా۝਷ 4֙ زউ ড 4ߓ ழ઎׮
4. ׮਺ ݾ಴ খীࢲ ࢤӟ ૕ޙ 기존과 같이 일해서는 어려울 수 있다고 생각한다. 이 목표를 사람만으로 계속 감당할 수 있을까? 작년의 성장을 기반으로 더 큰 목표를 세웠다.
5. AIח ࢜ بҳо ইפۄ ੌ੄ ҳઑܳ ׮द ޚѱ ೮׮ 그래서 이후 변화는 도구 사용보다 일의 구조 변화가 중요했다. 더 큰 목표 앞에서, 무엇을 도입할지가 아니라 어떻게 일할지를 다시 묻게 됐다.
6. о஖ח ௏٘ܳ ٜ݅ ٸо ইפۄ ੹׳ೡ ٸ ࢤӟ׮
7. AI द؀, য়൤۰ ؊ ઺ਃ೧૑ח Ѫ ઁಿ਍৔
   ҙܻ੗
   ؘ੉ఠ
   ࠙ࢳо ઁಿ
   ٣੗੉ց ઁಿ
   ূ૑פয ݽفীѱ 문제 정의와 상황 판단 사용자 경험과 흐름, 맥락 설계 구조와 품질을 판단하는 능력 좋은 결과와 나쁜 결과를 구별하는 눈
8. ׼Ӕ਷ য়ۖزউ ੋҕ૑מ ӝࣿਸ ࢎਊ೧৳׮ 오늘 언급되는 여러 AI 에이전트는 이 기반 위에서 만들어졌다. LLM 이후에도 빠르게 움직이며, 전사적으로 AI를 적극 활용하는 시도가 이어졌다. 당근은 LLM 이전부터 머신러닝과 딥러닝을 제품과 시스템에 써왔다.
9. 1݅km ࢚ҕীࢲ ׼Ӕ੄ AI ೒ۖಬਸ Ҽযࠁ੗ ठۑীࢲ पઁ ௏٘ ޙࢲ ਍৔ ݓۅী ࠢয ߄۽ ੌೞח प೯ഋ ী੉੹౟׮ ৈ۞ بҳ৬ ܖ೐ܳ ઑ೤೧ ؊ ࠂ੟ೠ ী੉੹౟ ൒ܴਸ ҳࢿೞח ਕ௼೒۽਋ ੗زച ೒ۖಬ੉׮ ೐܁೐౟৬ ী੉੹౟ܳ ௏٘ হ੉ ٜ݅Ҋ ಣоೞҊ ߓನೞח ೒ۖಬ੉׮ LLM Router Karby Kamp Prompt Studio ݽٚ ݽ؛ ഐ୹ਸ ೞա੄ ҙޙਵ۽ ా೤ೞҊ ઺ঔীࢲ ҙܻೞח दझమ੉׮ 🤖      MCP SERVICES ೐܁೐౟৬ ী੉੹౟ܳ ௏٘ হ੉ ٜ݅Ҋ ಣоೞҊ ߓನೞח ೒ۖಬ੉׮
10. 6TF
    "*
    "HFOUT "*
    ী੉੹౟ܳ
    ॳݶࢲ
    ߥয૓
    ੌٜ
11. ҳഅ੄ ӏ஗੉ ׳ۄ઎׮ 개발자의 시간 배분이 바뀌었다 : 직접 작성하는 시간보다, AI가 만든 변경을 읽고 검토하고 판단하는 시간이 더 길어졌다 직무 경계가 넓어졌다 : 프론트엔드와 백엔드를 넘나드는 작업 시도가 현실적인 선택지가 되기 시작했다 코드 생산량이 폭발적으로 늘었다 : 작고 예측 가능한 구현부터 AI에게 맡기기 시작했다
12. ҳഅ݅੉ ইפۄ ઱߸ সޖب ߄Շӝ द੘೮׮ ܻ࠭
    ੗زച ಿ૕
    ѱ੉౟ ݓۅ
    ఐ࢝ CodeRabbit, Claude Code GitHub Action 같은 도구로 먼저 검토 부담을 줄이려 했다 Claude Code hooks와 리뷰 결과 체크 로 최소 기준을 시스템이 먼저 확인하게 만들기 시작했다 Karby 같은 코딩 에이전트와 분석 에이 전트를 슬랙에서 호출해 맥락을 바로 찾 기 시작했다
13. AI ী੉੹౟ח ূ૑פয݅੄ بҳо ইפ঻׮ ࠄসਸ
    ؊
    զ஠܂ѱ
    ݅٘ח
    ߑध दझమ
    ߸҃ী
    ૒੽
    ଵৈೞח
    ߑध 제품 또는 운영 관리자 등 논테크 직군 이 생성형 AI를 이용해 데이터를 더 깊이 분석하고, 제품 전략이나 운영 정책 초 안을 더 날카롭게 다듬기 시작했다 Claude Code hooks와 리뷰 결과 체크 로 최소 기준을 시스템이 먼저 확인하게 만들기 시작했다
14. " " "*ח
    ੌೞח
    ߑध݅੉
    ইפۄ
    ޙઁ
    ؀਽੄
    ൒ܴب
    ߄Բӝ
    द੘೮׮
15. ߸ചח ࠙ݺ೮૑݅, ੉ ߸ചܳ х׼ೞҊ ੓ਸө?
16. ૒ޖ/ҵ੄ ҃҅о ൒۰૑ݴ, ଼੐ ҳઑب ড೧઎׮ 하지만 누가 어떤 기준으로 책임질지는 더 중요해졌다. 누구나 시도할 수 있게 됐다.
17. э਷ بҳܳ о઎૑݅, э਷ ߸ചо ੌযա૓ ঋও׮ "써보세요"만으로는 격차가 벌어지고, 시간이 지날수록 그 격차는 커진다. 차이는 개인 재능보다, 누가 먼저 시도했고, 워크플로우를 바꿨는지에 가까웠다. 같은 시기, 같은 도구가 있었지만 팀마다 변화의 속도와 깊이는 달랐다.
18. " " ਋ܻח
    ؊
    ࡈۄ઎૑݅
    ؊
    ੿नহ੉
    ੌೞҊ
    ੓׮
19. " " ੉
    ࣘبח
    ࢤ࢑ࢿੌө
20. ਋ܻо թӝҊ ੓ח Ѫ਷ ަө? 좋은 문서, 기준, 테스트, 워크플로우가 조직의 생산성 생성력을 만든다. 다음 사람도, 다음 AI 에이전트도 더 잘 일할 수 있어야 한다. 지금 빨라지는 것만으로는 충분하지 않다.
21. ߸ചח ࡈۄ઎૑݅, ਋ܻ੄ दр਷ ৈ੹൤ ࠗ઒೮׮ 개인 생산성의 상승만으로는 조직 전체의 전달 흐름이 바뀌지 않았다. 사람이 모든 하위 루프의 검토를 떠안으면 새 병목이 생겼다. AI가 만든 결과물은 완성품보다 제안에 가깝다.
22. ࢎۈҗ ী੉੹౟ח ࢲ۽ ׮ܲ ൒ܴਸ ݐইঠ ೠ׮ ৵
    ੉Ѧ
    ݅٘חо যڌѱ
    ߈ࠂೡ
    Ѫੋо ޖ঺ਸ
    ҅ࣘ
    Ҋச
    Ѫੋо 문제 정의와 최종 판단은 사람이 맡는다 구현, 초안, 테스트, 점검은 에이전트가 더 많이 맡는다 사람은 결과물 하나하나보다 기준과 워크플로우를 계속 고친다
23. #VJME
    "*
    "HFOUT "*
    ী੉੹౟ܳ
    ٜ݅Ҋ
    ઑ૒ী
    ղ੤ചೞݴ
    ߥয૓
    ੌٜ
24. ߧਊ ী੉੹౟ח ਋ܻܳ ݽܲ׮ ਋ܻ
    ઁಿਸ
    ݽܲ׮ ਋ܻ
    ӝળਸ
    ݽܲ׮ ਋ܻ
    ൒ܴਸ
    ݽܲ׮ 동네생활, 모임, 카페, 아파트 같은 우리 도메인 맥락과 지표를 모른다 리뷰 기준, 배포 게이트, 테스트 규칙 같은 일하는 방식을 모른다 문제를 어떻게 정의하고, 이후 어떻게 해 결하는지 그 과정과 흐름을 모른다
25. ࢎۈب ী੉੹౟ب ݽفо ࢎਊ ೡ ࣻ ੓যঠ ೠ׮ `Build AI Agents`의 핵심은 만드는 것이 아니라 공유하고 정착시키는 것이다. 공유된 기준은 사람과 에이전트가 함께 반복해서 재사용할 수 있다. 개인이 발견한 좋은 방식은 스킬과 플러그인으로 바꿔야 가치가 생긴다.
26. زदী ੘স ൒ܴਸ ࢸ҅ೞӝ द੘೮׮ ਕ௼೒۽਋
    ޘӝ ী੉੹౟
    ഈ۱җ
    ೟ण
    ܖ೐ ੹׳
    ૒੹ө૑
    ੗زച 에이전트 스킬로 따로 놀던 단계를 하나의 흐름으로 묶으려 했다 4개 전문 리뷰 에이전트가 서로 다른 관점으로 보게 하려 했다 QA 시트, 테스트 코드 생성, 실행까지 파이프라인 안으로 편입하기 시작했다
27. " " ೨ब਷
    ؊
    ݆਷
    ௏٘о
    ইפ׮
28. ՘ө૑ ੉য૑ח ੹׳ ൒ܴ੉ ؊ ઺ਃೞ׮ 연결된 작업 흐름이 있어야 속도가 가치 전달로 이어진다. 단일 작업을 자동화만으로는 병목이 사라지지 않는다.
29. ੉ ݽٚ Ѫਸ ୊਺ࠗఠ ੜ ٜ݅૑ח ޅ೮׮ 이 과정은 결국 시스템을 만들어가는 행위와 별반 다르지 않았다. 만들고, 부수고, 고치며 점진적으로 다시 만들고 있다. 마켓플레이스 구조, 스킬 설계 등 어느 것도 처음부터 완벽하지 않았다.
30. 8IFSF
    8FsSF
    )FBEFE ߈֙
    খب
    ੿ഛ൤
    ৘ஏೡ
    ࣻ
    হח
    द؀
    
    ૑Әө૑੄
    दبܳ
    যڃ
    ҙ੼ਵ۽
    ޘযࠅ
    ࣻ
    ੓ਸө
31. ਋ܻо ೞҊ ੓ח Ѫٜ 사람과 AI 에이전트가 함께 일하는 흐름을 설계한다. 반복해서 쓸 수 있는 방식을 발굴하고, 조직에 일의 기반으로 만든다. AI 활용을 개인의 재량에만 맡기지 않는다.
32. AI ֎੉౭࠳ۆ ޖ঺ੋо? "*ܳ
    ੹ઁ۽
    ੌೞח
    ߑधਸ
    ࢸ҅ೞח
    Ѫ 조직은 컨텍스트, 기준, 게이트, 워크플로우라는 일의 기반을 준비한다. 에이전트는 구현, 초안, 테스트, 점검을 더 많이 맡는다. 사람은 판단, 리뷰, 기준 설계에 더 집중한다.
33. ҕਬ оמೞҊ न܉غח ੌ੄ ӝ߈੉ ઑ૒ ੹୓ܳ ߄Դ׮ AI는 좋은 방식만 확산시키는 것이 아니라, 나쁜 방식도 그대로 증폭시킨다. 재사용 가능한 일의 기반은 조직 전체로 빠르게 퍼진다. AI 에이전트가 만들어내는 결과는 개인의 숙련보다 조직의 일의 기반에 더 좌우된다. 그래서 일부의 뛰어난 활용보다, 조직 전체의 기본기를 높이는 쪽이 더 중요해진다.
34. ਋ܻо ҃҅ೞח Ѫ 시스템 없이 AI 의존만 키우는 것 AI 활용 격차를 개인의 태도 문제로 돌리는 것 코드 양을 곧바로 생산성으로 읽는 것 속도만 높이고 지속 가능성을 잃는 것
35. " " ੌױ
    ࠗ٭ഃࠊঠ
    ೠ׮
36. References 👤 OpenAI, Building an AI Native Engineering Team 👤 Drew Hoskins, The Product Minded Engineer 👤 Birgitta Bockeler, Context Engineering for Coding Agents 👤 Kief Morris, Humans and Agents in Software Engineering Loops 👤 Birgitta Bockeler, Harness Engineering
37. ՘