AI 네이티브 엔지니어링 조직 운영하기

🏷️ 정보

원본: Running an AI-native engineering org — Fiona Fung, Director of Engineering for Claude Code

아래는 강연 트랜스크립트를 한국어로 옮긴 글이다. 자연스러운 흐름을 위해 일부 구어체 표현을 다듬었다.

인사

0:03 · [음악] 여러분, 제 목소리 잘 들리나요?

0:11 · 좋아요. 이거 정말 Claude Code 홍보 같은 건 아닌데요, 사진 한 장 찍어도 될까요? Boris랑 Jared가 2시 세션을 했길래 여기는 텅 비어 있을 거라고 정말 생각했거든요. "그 세션 끝나고 여기로 올 사람이 있을 리 없지"라고 생각했어요.

0:25 · 와, 진짜.

0:28 · [환호성] 고마워요, 여러분. 약속할게요, 저랑 Boris는 평소에 셀카만 찍고 다니는 사이 아니에요.

0:33 · [웃음] 오후 인사드려요, 참석해 주셔서 감사합니다. 저는 Fiona Fung이고, Claude Code와 Cowie의 엔지니어링 및 프로덕트 조직을 이끌고 있습니다. Boris, Cat과 아주 가깝게 일하고 있고요. Anthropic 이전에는 Meta와 Microsoft에서 팀을 이끌고 키워왔습니다.

0:52 · 오늘 발표의 전체 어젠다는 이렇습니다. 핵심은 Claude Code와 Cowie가 성장하고 팀을 키워가는 과정에서 제가 배운 교훈들이에요. 흥미로운 건, Meta나 Microsoft 시절을 떠올려 봐도 — 심지어 Anthropic에서조차도 — 비슷한 교훈들이라는 점이에요. 재밌는 게, 이 슬라이드 덱을 한 달 전쯤 만들었는데 그 사이에도 내용을 바꿔야 했어요. 예를 들면 처음 만들 때만 해도 'routines'라는 게 없었고, 그런 작업 방식 자체가 저에게도 새로웠거든요.

다섯 가지 테마

1:24 · 오늘은 제가 관찰한 다섯 가지 테마를 다루려고 합니다. 첫 번째는 병목이 이동했다는 것.

1:33 · 병목이 이동하면, Claude Code 팀 안에서 우리는 어떤 팀 규범을 다시 써야 했는가?

1:40 · 그리고 그 규범들을 어떻게 롤아웃했는지, 어떤 신호를 보면서 "방향이 맞다"고 판단하는지 공유하려 합니다. 항상 중요한 건, 이 방식이 여전히 우리에게 도움이 되는지를 계속 묻는 것이에요. 마지막으로는 저 자신도 아직 답을 찾고 있는 몇 가지 질문, 그리고 여러분이 자신의 팀에서 시도해 볼 만한 제안으로 마무리하겠습니다.

1. 병목이 이동했다

2:11 · 첫 번째 섹션, The Shift. 앞으로 자주 반복할 부제가 있어요. "이전에 잘 통했던 것이 더 이상 통하지 않을 수 있다." Anthropic, Meta, Microsoft 어디에서든 저를 가장 든든하게 받쳐줬던 근육은 항상 성장 마인드셋이었어요. 특히 요즘처럼 변화 속도가 미친 듯이 빠를 때는 더 그렇죠.

2:38 · 작년에 라이브 코딩을 처음 시작했을 때만 해도 모델이 "왜 여기에 상수를 박지? 좋은 엔지니어링 관행이 아닌데"라는 식의 버그를 만들곤 했어요. 지금은 훨씬 더 유능해졌고요. 그게 제가 보는 흥미로운 변화예요. 병목이 이동했을 때, 그 병목 주변의 모든 것을 어떻게 적응시킬 것인가.

3:03 · 여러분도 느끼시겠지만, 수년간 **엔지니어링 대역폭(bandwidth)**이 가장 비싼 자원이었어요. 코딩 처리량이 비쌌죠. 소프트웨어를 출시하는 모든 프로세스 — 안녕하세요, 어서 오세요. 저쪽에 빈 의자 있어요. 예약 표시는 떼셔도 돼요. 아무도 안 앉았어요.

3:23 · [웃음] 이쪽에도 있어요. 계속할게요. 우리가 했던 모든 일 — 워터폴이든 애자일이든 — 그게 다 엔지니어링 대역폭이 비쌌기 때문이에요.

잠시 옆길로: 우리는 늘 적응해왔다

3:39 · 우리 산업은 늘 적응해왔어요. 타임머신을 타고 2000년대로 가봅시다. 제가 커리어를 시작한 때였고, Visual Studio에서 일하면서 Visual Studio 2005를 출시했어요.

3:56 · 그 시절엔 소프트웨어를 CD-ROM으로 출시했어요. 그 전엔 플로피 디스크였고요. VS 2005는 정말 빡빡한 데드라인이 있었어요. 제조 공장에 보내서 CD를 찍고, 박스에 담아 매장으로 보내야 했거든요. 온라인으로 소프트웨어를 배포할 수 있게 되면서 출시 방식 자체가 바뀌었죠. 지금 우리가 보고 있는 변화도 비슷해요. 엔지니어링 대역폭이 더 이상 비싼 자원이 아니다.

4:27 · Claude Code 팀에서 코딩은 더 이상 느린 부분이 아닙니다. 처리량도 정말, 정말 많이 늘었어요. "더 많이 만들 수 있어 좋다"가 아니라, 생성되는 양 자체가 완전히 달라졌다는 거예요.

새로운 병목들

4:51 · 병목이 코딩과 타이핑이라는 행위 자체에서 옮겨가면, 다른 영역으로 이동합니다. 예전엔 "리팩토링할 시간 어떻게 빼지?"가 큰 고민이었잖아요. 그건 더 이상 병목이 아니에요. 지금의 새로운 병목은 검증(verification), 리뷰, 크로스펑셔널 파트너, 보안입니다.

5:27 · 코딩이 더 이상 병목이 아니고 더 많은 코드를 만들어내니까, 새로운 질문이 생겨요. "이 코드가 맞나? 누가 리뷰하지?" 다른 엔지니어링 리더들에게 가장 많이 받는 질문이 바로 **"AI가 만들어내는 양을 사람이 어떻게 따라가요?"**예요.

5:47 · 흥미롭게도 유지보수도 마찬가지입니다. 코드 생성이 쉬워졌으니, 그 코드를 유지하는 비용도 같이 생각해야 해요.

조용히 작동을 멈추는 프로세스들

5:59 · 이 표현이 좋아요. "조용히 작동을 멈춘다(quietly stops working)." 보통 우리는 어떤 이유로 프로세스를 도입해요. 하지만 시간이 지나도 프로세스가 스스로 죽는 일은 거의 없어요. 우리는 그냥 계속 덧붙이기만 하죠. 한 팀에서는 SLA가 너무 많아서 — P0 버그 SLA, 하이프라이 서브 리뷰 SLA 등등 — 결국 엔지니어들이 어떤 SLA가 더 중요한지 우선순위를 정해야 할 정도였어요.

6:37 · 그때도 "이걸 좀 정리(defrag)해야 한다"고 생각했는데, 지금은 더더욱 그래요. 이전엔 잘 통했지만 이제는 통하지 않는 것들:

2. 우리가 다시 쓴 팀 규범

7:39 · Claude Code 팀에서 다시 쓴 규범들을 공유할게요.

플래닝: JIT로

8:32 · 플래닝은 훨씬 덜 해요. 타이밍도 중요한데, 저는 이걸 JIT(Just-In-Time) 플래닝이라고 불러요. JIT 컴파일링처럼요. 처음 합류했을 때 "6개월 로드맵 있어야 하지 않나요?"라고 물었고, 실제로 만들었어요. 3개월 정도는 꽤 괜찮았는데, 연말이 지나고 돌아와 보니 너무 많은 게 바뀌어 있더라고요. 6개월 로드맵은 너무 길다고 결론 내렸어요. 적정한 양을, 적정한 시점에.

기술 토론: 코드가 이긴다

9:05 · 기술 토론에서는 코드가 이깁니다.

9:11 · 합류 직후 코드베이스를 익히려고 리팩토링을 하고 싶었어요. Boris와 어느 방향으로 갈지 건강한 기술 토론을 했고, 저는 옛날 도구를 꺼낼 뻔했어요 — 회의실로 가서 화이트보드에 그리자고 말이죠. 그러다 멈췄어요. "잠깐. 지금은 우리가 논의한 모든 옵션을 그냥 만들어보면 되잖아." 3개의 PR을 만들었어요.

9:36 · 멋진 부분은, 기술 토론에서 저는 API 구현뿐만 아니라 그 API를 호출하는 모든 호출자에게 미치는 영향도 중요하다고 생각했어요. Claude가 세 가지 버전을 만들어주니, 구현뿐 아니라 동료 코드에 미치는 영향까지 함께 토론할 수 있었어요. 이게 정말 핵심적인 변화예요.

10:13 · 다만 주의할 점. 빌드가 싸진다고 해서 "마지막에 체크인한 사람이 이기는" 문화가 되면 절대 안 됩니다. "내가 새벽 3시에 PR을 올리고, 마지막에 한 마디 하려고 routine 걸어놓고 자야지" — 이건 절대 금지. 그래서 열린 기술 토론을 할 수 있는 팀 문화와 좋은 정렬 메커니즘이 더더욱 중요해져요.

디자인 독을 줄이고, 검증을 두 배로

10:41 · 코드 직전의 디자인 독 작성 의례를 줄였어요. 어떤 팀, 어떤 시나리오에서는 디자인 독이 여전히 중요해요. 비동기 논의가 필요할 때 특히요. 하지만 Claude Code에서는 문서 대신 PR로 이야기해요. "아이디어 있어? 프로토타입 만들어 봐"가 우리의 공식이에요. 제품 리뷰도 거의 안 해요. 풍경이 너무 빨리 바뀌니까요. 프로토타입을 만들고, 내부 직원(ants)들이 써보고, 여러분에게 출시해서 피드백을 받는다.

11:30 · 줄인 만큼 두 배로 늘린 건 **검증(verification)**입니다. 처리량이 다르고 새로운 고장 방식이 생기니까요. 어떻게 스케일할까? 저는 shift-left라고 불러요. 옛날엔 코드를 내고 나서 제가 버그를 먼저 찾기를 바랐죠. 지금은 더 좋은 게 있어요 — 자동화로 더 일찍, 소스에 가까이서 잡아내는 것.

11:58 · 역할이 흐려진 점도 흥미로워요. 디자이너 친구가 코드를 체크인했을 때 자기가 뭔가 깨지 않았다고 더 확신할 수 있으면 좋겠어요. 저도 한번은 resume 버그를 고친 다음 날 Boris 스레드에서 "버그 발견" 멘션을 보고 가슴이 철렁한 적이 있어요. 그런 경험 있으시죠? 그래서 역할에 상관없이 자기 변경에 대한 더 높은 확신을 모두에게 주는 게 중요해요.

"이거 누가 바꿨어?"의 진짜 질문

12:38 · 거의 모든 PR이 Claude의 도움을 받고 있으니, "누가 바꿨어?"는 좀 이상한 질문이 됐어요. 더 유용한 건 그 질문을 더블클릭해 보는 거예요. 옛날에 우리가 "누가 바꿨어?"라고 물었을 때 진짜 묻고 싶었던 건 뭐였죠?

그 더블클릭 질문이 무엇이든, 자동화할 수 있는 방법이 있는지 생각해 보세요. 한 달 전만 해도 제 아침 루틴은 desktop Claude를 켜고 고객 피드백 채널을 요약시키는 거였어요. 지금은 그냥 routine이에요. 그래서 코드 오너십은 모호해졌지만, 그 대신 "진짜 묻고 싶었던 게 뭐냐"를 묻고 Claude로 해결하세요.

코드 리뷰: 신뢰하되 검증하라

13:53 · 오늘 아침 키노트에서 Kat이 말한 것처럼, 우리는 Claude 코드 리뷰를 적극 활용합니다. 흥미로운 건 Claude를 어디까지 믿고, 어디부터 사람을 원하는가입니다.

Claude에게 맡기는 것: - 스타일링, 린트 - PR 피드백 응답 - 일부 버그 탐지와 수정 (커밋 전에) - 테스트 추가 - PR 베이비시팅

여전히 사람이 필요한 곳: - 법무 리뷰 — 항상 법무 파트너를 끌어들여요. - 위험 감수성 — 신뢰 경계와 보안 민감 코드는 전문가에게. - 프로덕트 감각과 취향 — 재미있는 일화 하나. 시즌별로 Claude를 꾸미는 걸 좋아하는데, 작년 연말에 터미널 안의 Claude를 눈사람으로 만들고 싶었어요. 그때 Claude는 ASCII 아트를 잘 못했고요. 디자이너 파트너에게 리뷰를 부탁했더니 "Mr. Peanut 캐릭터로 만들어 놨네"라고 하더라고요. 결국 더 단순하게 — 얼음빛 파랑에 눈송이 정도로 — 갔어요. 프로덕트 감각은 여전히 사람의 영역입니다.

팀 구성: 두 가지 프로파일

15:47 · Claude Code에서 제가 무겁게 보는 엔지니어 프로파일은 두 가지예요.

  1. 프로덕트 감각이 있는 창의적 빌더 — 호기심 많고, "여기 문제가 있어, 풀어보자"라고 말하는 드리머. 사용자에게 즐거운 경험을 주기 위해 반복적으로 다듬는 사람.
  2. 깊은 시스템 전문성 — 처음 합류했을 때 우리 팀은 프로덕트 제너럴리스트와 창의적 인력은 많았지만 분산 시스템 전문가가 부족했어요. Claude Code Remote처럼 "어디서나 Claude를 돌리는" 인프라를 만들려면 이런 전문성이 꼭 필요해요.

16:27 · 반대로 제가 덜 중요시하는 건 순수한 처리량입니다. 모델 덕분에 모두가 훨씬 효율적이거든요.

크로스펑셔널 갭

16:45 · 한번은 설문 응답 방식을 업데이트하고 싶었는데 전담 콘텐츠 디자이너가 없었어요. 저는 엔지니어라 글쓰기가 형편없거든요. 짧고 명확하게 쓰는 게 어려워요. 설문이 터미널을 채우면 안 되니까요. 옛날 같으면 "콘텐츠 디자이너 누구랑 협업할 수 있지?"였을 텐데, 지금은 Claude가 그 역할을 훌륭하게 보강해 줘요.

17:16 · 반대로 우리 PM은 코드를 많이 써요. 비전통적 코더가 더 많은 엔지니어링을 할 수 있고, 엔지니어가 콘텐츠/디자인 영역으로 더 깊이 들어갈 수 있는 시대예요.

매운맛: 조직 형태(Org Shape)

17:55 · 매운맛 주제입니다. 합류 직후 리크루터들이 익숙한 공식("IC 10명에 매니저 1명, 그다음 네스팅")을 쓰려고 하더라고요. 저는 최대한 스크래피하게 가자고 했어요.

좋은 프로덕트를 만들기 위해 늘 저를 도와준 건 헤비, 헤비, 헤비 도그푸딩이에요. Visual Studio든 Facebook Marketplace든 AR/VR이든 Claude든 — 제품을 매일 직접 써야 해요. 한동안은 리더가 코드에 손을 못 댔지만 요즘은 다시 코드 안에 있을 수 있어요. 코드 안에 들어갈 수 없을 땐, 자기 제품을 매일매일 사용하는 데 시간을 쓰세요.

18:39 · 그래서 Claude Code의 모든 매니저가 IC로 시작하길 원했어요. 팀에서 신뢰를 얻고, 효과적인 엔지니어가 되는 법을 배우라고요.

18:51 · 그리고 조직을 최대한 플랫하게 만들었어요. 리크루터들은 걱정했어요. "매니저를 IC로 시작시키면 아무도 안 하려 들 거예요." 저는 "그게 Claude Code 팀의 도그푸딩이고, 관심 없으면 일찍 헤어지는 게 서로에게 좋다"고 했어요.

19:13 · 솔직히 Meta에 있을 땐 매년 PR 한 개라도 해보려 했지만 내부 도구가 늘 바뀌어서 쫓아가기 힘들었어요. 지금은 git 명령어도 외울 필요가 없어요. 그냥 Claude에게 물어보면 돼요.

새로운 진실의 원천

19:52 · 지식 공유에서, 새로운 **진실의 원천(source of truth)**은 무엇인가?

19:56 · 우리 팀에서는 코드가 진실의 원천이에요. 고객 문의를 받을 때 그냥 desktop Claude + 로컬 레포지토리만 있으면 많은 답을 할 수 있어요. "문서가 코드와 동기화되어 있나"라는 옛 골칫거리도 줄어들었어요. 단, 자기 팀에 맞는 걸 하세요. 좋은 스펙이 있다면 레포에 체크인해 두고, Claude에게 "내 코드 실행이 스펙과 일치하는지 확인해 줘"라고 시키세요.

3. 어떻게 롤아웃했나

20:40 · 팀 규범으로 **꼭 정렬해야 할 것(must-do)**과, 각 파드(pod)가 알아서 결정할 것을 어떻게 나눌까가 핵심이었어요.

꼭 맞춰야 할 것 (Claude Code 팀의 핵심 원칙)

성장 마인드셋을 적용해서, 몇 달에 한 번씩 "이게 여전히 의도한 효과를 내고 있나?"를 점검합니다.

파드에게 맡길 것

각 팀이 높은 자율성으로 결정하는 것: - 트리아지 방식, Claude 활용도 - 플래닝 의례, 스탠드업 - 온콜 - 어떤 워크플로우부터 Claudify할지

"이걸 자동화하라"고 명령하지 않아요. 제안과 학습은 공유하되, 팀이 다루는 문제 영역에 맞춰 결정하게 합니다.

줌아웃: 제가 가장 우선시한 세 가지

  1. 팀을 최대한 플랫하게. 매니저는 파드를 풀어주고, 한 팀 한 미션. 파드마다 미션을 따로 세우면 방향 전환할 때마다 비용이 커요.
  2. 가능한 모든 걸 Claudify. 더 어려운 일에 시간을 쓰기 위해서.
  3. 프로세스 정리. 쌓이게 두지 말고, 놓아줄 것을 정하세요.

4. 실제로 효과가 있나?

24:05 · 정확한 숫자는 공개 못 하지만, 변화가 잘 가고 있는지 볼 만한 세 가지 일반 지표가 있어요.

25:24 · 다만 커밋 수 너머의 최종 목표도 잊지 마세요. 헤드라인에 "X%의 코드가 AI 생성"이라는 기사들이 많지만, 처리량은 좋은 거지 목표는 아니에요. 우리는 품질과 안정성을 함께 보고 있어요.

5. 스스로의 노력을 감사(audit)하라

25:51 · 마지막 섹션. 솔직히 저도 아직 답을 못 찾은 질문들이 있어요.

하나만 가져가신다면

26:52 · 여러분의 가장 시끄러운 워크플로우(noisiest workflow) 하나를 고르세요. 가장 비싸거나, 본인이 부담스러워하거나, 팀이 기대 안 하는 것. 그리고 물어보세요. "이게 아직 그 목적을 다하고 있나?"

재미있는 일화. 어떤 팀에 있을 때 매주 50명이 큰 방에 모이는 비싼 리뷰가 있었어요. 가서 보면 다들 노트북만 보고 있다가, 자기 순서가 되면 고개 들어 상태 보고하고 다시 내려가요. 어느 날 그냥 물었어요. "우리 왜 이걸 하고 있는 거죠?" 모두가 "맞네, 왜 하지?" 하고는 취소했어요. 그래서 늘 묻는 게 중요해요.

여러분도 가져갈 한 가지 워크플로우를 골라서 — 자동화할 수 있는지, 아니면 애초의 목적을 아직 다하고 있는지 점검해 보시면 어떨까요.

마무리

27:56 · 발표 끝났습니다. 감사합니다.

28:00 · [박수] 고마워요.

28:03 · 다시 한번 와주셔서 정말 감사해요. 정말 텅 빈 방일 거라고 생각했거든요. 오늘과 내일 근처에 있을 거니까, 질문이나 더 이야기하고 싶은 분은 편하게 인사해 주세요.

28:19 · 감사합니다.