안녕하세요, 구독자님. 프로덕트를 만들며 생각이 점점 많아지고 있는 hubert입니다.
요즘은 AI와 대화하며 작은 기능을 직접 만들어보는 일이 많아졌습니다. 그런데 개발팀에서는 어떤 변화가 일어나고 있을까요? AI가 코드를 작성한다면, 개발자는 어디에 더 많은 시간을 쓰게 될까요?
이 궁금증으로 How I AI에 소개된 Notion, Stripe, Intercom의 사례를 살펴봤습니다. 세 회사는 같은 도구를 쓰는 법보다, AI와 함께 일하는 방식을 어떻게 바꿀지에 집중하고 있었습니다.
1. Notion : 코드보다 명세를 먼저
Notion의 엔지니어 Ryan Nystrom은 아이디어를 음성으로 설명하고, AI가 이를 개발 명세로 정리하도록 합니다. 명세는 코드 저장소에 함께 보관하고, Codex가 이를 읽어 구현과 검증을 진행합니다. 기능을 바꿀 때도 명세부터 수정합니다.
내부 시스템 ‘Boxy’에서는 Notion 댓글로 Codex를 호출할 수도 있습니다. Ryan은 약 20분 뒤 구현 내용과 화면 캡처가 담긴 PR을 받은 사례를 소개했습니다. PR은 코드 변경을 검토하고 반영하기 위한 요청입니다.
제게 흥미로웠던 건 속도보다 AI가 참고할 기준을 남겨둔다는 점이었습니다. 대화로 흘려보낸 요구사항과 달리, 명세는 무엇을 만들기로 했는지 확인하고 결과와 비교할 수 있는 기록이 됩니다.
구현이 빨라질수록, 처음에 무엇을 만들기로 했는지 더 분명해야 합니다.
PM의 PRD도 비슷하겠죠. 문서를 길게 쓰기보다, 빠진 조건과 서로 다르게 해석할 부분을 개발자와 먼저 확인하는 일이 중요해 보였습니다.
출처: Ryan Nystrom 인터뷰 · 2026.05.11
2. Stripe : Slack에서 개발 작업으로
Stripe의 ‘Minions’는 Slack의 논의를 개발 작업으로 이어주는 사내 AI 에이전트입니다. 인터뷰에서는 이모지 반응으로 작업을 시작하는 모습을, 공식 개발 블로그에서는 Slack 앱을 호출해 요청하는 방식을 소개합니다.
Slack 대화에서 Minion에게 작업을 요청하는 예시. 이미지 출처: Stripe 개발 블로그
에이전트는 준비된 개발 환경에서 코드를 수정하고 테스트한 뒤, 사람이 검토할 PR을 만듭니다. 엔지니어는 별도 화면에서 어떤 작업이 진행됐는지 확인할 수 있습니다.
Minion의 판단과 작업 내역을 확인하는 화면. 이미지 출처: Stripe 개발 블로그
Stripe가 강조하는 기반은 사람이 쓰던 개발 도구와 환경입니다. 문서, 테스트, 개발 절차가 정리돼 있었기에 AI도 그 안에서 일할 수 있었습니다. AI가 코드를 잘 쓰는 것만으로 완성된 과정은 아니었던 셈입니다.
2026년 2월 공식 후속 글에서는 Minions가 작성하고 사람이 검토한 PR이 주당 1,300건 이상 병합된다고 설명합니다. 이는 기능 1,300개가 출시됐다는 뜻은 아닙니다. 저는 숫자보다 요청부터 검토까지 이어지는 경로를 마련했다는 점에 주목했습니다.
출처: Steve Kaliski 인터뷰 · 2026.03.25
함께 읽기: Stripe 공식 개발 블로그 Part 2 · 2026.02.19
3. Intercom : 개인의 요령을 팀의 기준으로
Intercom의 Brian Scanlan은 약 9개월 동안 R&D 인력 1인당 병합된 PR 수가 두 배 수준으로 늘었다고 설명했습니다. 다만 PR 수는 개발 활동을 보는 지표이며, 고객 가치나 제품 품질이 두 배가 됐다는 뜻으로 읽을 수는 없습니다.
눈에 들어온 건 성과를 관리하는 방법이었습니다. Intercom은 Claude Code의 사용과 결과를 살펴보고, 팀의 개발 규칙을 재사용 가능한 ‘스킬’로 정리했습니다. PR을 만들 때 변경 이유와 내용을 설명하는 절차도 여기에 포함됩니다.
누군가 AI를 잘 쓰는 방법을 알아냈다면, 그 경험을 개인의 프롬프트로만 남겨두지 않는 것입니다. 동료도 같은 기준으로 작업하도록 만들고, 실제 사용 데이터를 보며 개선합니다.
PM 업무에서도 비슷한 일이 있습니다. 같은 지표를 물어도 조회 기준과 필터가 다르면 답이 달라집니다. 질문을 잘하는 사람을 늘리는 것과 함께, 팀이 공유할 기준을 만드는 일이 필요하겠다는 생각이 들었습니다.
출처: Brian Scanlan 인터뷰 · 2026.04.20
세 회사의 차이를 한눈에 보면
Notion은 ‘무엇을 만들지’, Stripe는 ‘어떻게 실행할지’, Intercom은 ‘어떻게 함께 개선할지’에 초점을 맞췄습니다.
세 회사의 방식은 다르지만 공통점은 분명했습니다. AI를 도입하는 데서 끝내지 않고, 사람이 요청하고 결과를 확인하는 과정까지 함께 설계했다는 점입니다.
4. 그렇다면 PM은 무엇을 준비할까요?
저는 결제 오류코드를 통일하는 업무에서 개발자에게 이런 질문을 받은 적이 있습니다.
“다른 플랫폼에서도 이 코드를 사용하고 있지 않을까요?” 확인해보니 일부 코드는 다른 시스템의 화면 이동과 다음 동작을 결정하고 있었습니다.
AI로 로그를 분석하고 요구사항을 정리했지만, 다른 시스템의 동작은 담당 개발자와 확인해야 했습니다. 이 경험을 떠올리면, AI에게 일을 맡기기 전에 함께 정할 것이 세 가지 있습니다.
첫째, 변경하지 말아야 할 범위
무엇을 만들지뿐 아니라 어떤 동작을 유지해야 하는지도 정리합니다.
여러 시스템이 연결돼 있다면 영향받는 담당자와 먼저 확인해야 합니다.
둘째, 완료했다고 판단할 조건
코드가 작성됐다는 것과 일이 끝났다는 것은 다릅니다.
어떤 테스트를 통과하고, 어떤 결과를 확인해야 하는지 개발자와 합의합니다.
셋째, 문제가 생겼을 때 확인하고 되돌릴 방법
변경 이력과 영향을 확인할 수 있는지, 문제가 생기면 이전 상태로 돌아갈 수 있는지 살펴봅니다.
AI가 구현해도 운영의 책임은 조직에 남기 때문입니다.
새로운 일이라기보다 기존에 중요했던 기준을 AI와의 협업에도 적용하는 일에 가깝습니다.
구현이 빨라진 만큼, 이 논의를 나중으로 미루기 어려워진 것이겠죠.
마무리하며
세 사례를 보며 개발자의 역할이 코드를 작성하는 데서, AI가 만든 결과를 판단하고 팀의 기준에 맞게 반영하는 일로 넓어지고 있다고 느꼈습니다. PM도 요구사항을 전달하는 것에서 더 나아가, 사람이든 AI든 같은 뜻으로 이해할 수 있는 기준을 만들어야 할 것 같습니다.
우리 팀에서 바로 시작한다면 거창한 에이전트보다, 다음 기능의 ‘변경 범위’와 ‘완료 조건’을 함께 정리해보는 건 어떨까요?
여러분의 팀은 AI에게 어디까지 맡기고, 어떤 부분을 직접 확인하고 있나요?
📚 참고한 콘텐츠
Notion — Spec-driven development
Stripe — How Stripe built minions
Intercom — How Intercom 2x’d their engineering velocity
Stripe 개발 블로그 — Minions Part 1 (화면 이미지 출처)
How I AI의 Claire Vo 인터뷰와 Stripe 공식 글을 바탕으로 정리했습니다. 수치는 각 자료가 공개된 시점의 기업 설명이며 동일 조건의 비교 결과는 아닙니다. 업무 경험과 해석은 필자 개인의 생각입니다.
📮 다음 호 예고
[41호] 반복 질문은 팀의 자산이다
"지난주에 뭐 바뀌었어요?", "이 지표 기준이 뭐예요?" 팀 서포트 채널에는 오늘도 어제와 비슷한 질문이 올라옵니다. 답은 이미 문서 어딘가에 있는데, 결국 답하는 사람은 늘 그 기능을 가장 잘 아는 한두 명이죠. 최근 Slack과 Notion이 팀 단위로 AI 스킬을 공유하는 기능을 잇달아 내놓으면서, AI 스킬이 개인 도구에서 팀의 자산으로 바뀌고 있어요. 다음 호에서는 우리 팀의 질문에 맞는 방법을 고르는 법과, 그 방법을 잘 운영하는 요령을 함께 살펴볼게요.
✉️ 다음 호가 궁금하신 분들은 아래 [구독하기] 버튼을 눌러주세요.
의견을 남겨주세요