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

오랫동안 엔지니어링 인력은 애플리케이션 개발에서 가장 비용이 많이 드는 자원이었습니다. 워터폴에서 애자일에 이르기까지, 소프트웨어 기획과 출시를 둘러싼 모든 프로세스는 바로 이 비용을 줄이기 위해 설계된 것이었습니다.

저는 2000년대 초 Visual Studio 팀에서 커리어를 시작했습니다. 당시에는 제조 마감일이 정해진 CD-ROM으로 소프트웨어를 출시했습니다. 온라인 배포가 가능해지면서 점점 더 빠른 주기로 업데이트를 내보내기 시작했고, 이제는 소프트웨어를 작성하는 데 드는 시간과 인력을 중심으로 또 한 번 일하는 방식이 바뀌고 있습니다.

Claude Code 팀에서는 코드 작성, 테스트 작성, 리팩토링이 더 이상 우리의 발목을 잡는 일이 거의 없습니다. 하지만 에이전트 코딩이 직접 코드를 타이핑할 필요를 없애준다고 해서 병목이 사라진 건 아닙니다. 이제는 검증, 코드 리뷰, 보안이 그 자리를 대신하고 있습니다.

이제 누구나 코드를 빠르게 대량으로 생성할 수 있게 됐지만, 그만큼 새로운 질문들도 생겨납니다. 이 코드가 정확한가? 유지보수는 어떻게 할 것인가? 그리고 동료 엔지니어링 리더들이 가장 많이 묻는 질문 중 하나가 바로 이것입니다. "코드 리뷰를 사람이 어떻게 따라가고 있나요?"

소리 없이 작동을 멈춘 프로세스들

모든 프로세스는 이유가 있어서 만들어집니다. 격차를 메우거나 무언가를 더 잘 작동하게 하기 위해서죠. 그런데 그 격차가 사라지고 프로세스가 낡은 것이 되어도, 스스로 없어지는 경우는 드뭅니다. Claude Code 팀이 에이전트 코딩을 기본 업무 방식으로 삼기 시작하면서, 기존 프로세스 상당수가 제 기능을 잃었습니다. 어떤 규범을 어떤 이유로 다시 썼는지 소개합니다.

기획: 적시(just-in-time) 로드맵으로의 전환

기존의 관행은 코딩에 드는 비용이 컸기 때문에 사전 기획에 훨씬 많은 시간을 쏟는 것이었습니다. 제가 Claude Code 팀에 처음 합류했을 때 꽤 완성도 높은 6개월 로드맵을 작성했는데, Claude Code 덕분에 너무 많은 것이 바뀌어 3개월도 지나지 않아 이미 낡은 문서가 되어버렸습니다.

엔지니어링의 속도와 처리량 자체가 달라진 만큼, 스프린트를 계획하는 방식도 바뀌었습니다. 저는 이를 JIT(Just-In-Time) 기획이라고 부릅니다. JIT 컴파일처럼, 적절한 시점에 딱 필요한 만큼만 하는 것입니다. 우리의 기획 방식은 설계 문서 중심에서 PR이나 프로토타입을 통한 논의 중심으로 바뀌었습니다. 이 분야는 빠르게 움직이기 때문에 제품 검토에 많은 시간을 들이지 않습니다. 지금 우리의 프로세스는 이렇습니다. 프로토타입을 만들고, 내부 사용자를 많이 참여시키고, 그들의 피드백에 바로 반응하는 것입니다.

컨텍스트 수집: 작성자가 아니라 Claude에게 물어보기

엔지니어가 코드를 직접 작성하던 시절에는 대부분의 질문에 답을 얻는 첫 번째 단계가 코드를 작성한 사람을 찾는 것이었습니다. 이제는 모든 PR에 Claude가 관여하기 때문에, "이 변경을 누가 했나요?"라는 질문만으로는 충분하지 않습니다. 우리의 새로운 방식은 한 단계 더 깊이 들어가는 것입니다. 실제로 무엇을 알아야 하는가를 먼저 따지는 것이죠. 예를 들어, 회귀를 유발한 사람을 찾고 있는 건가요? 고객 질문에 답할 전문가가 필요한 건가요? 아니면 어떤 결정의 배경이 궁금한 건가요? 그 질문을 Claude에게 물어보고, Claude가 더 많은 데이터와 컨텍스트를 바탕으로 직접 답할 수 있는지 먼저 확인합니다.

Claude Code 팀에서는 어떤 질문이든 "이것을 자동화할 방법이 있을까?"라는 질문을 함께 던지는 것이 원칙입니다. 예를 들어, 매일 아침 Claude가 고객 피드백 채널을 요약해 주는 작업은 제가 커피를 마시며 손수 하던 루틴에서, 이제는 백그라운드에서 자동으로 돌아가는 작업이 되었습니다.

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

우리는 코드 리뷰를 적극적으로 활용합니다. 스타일과 린팅, PR 피드백 요청, 전체 커밋 전 버그 발견 및 수정, 테스트 추가는 모두 Claude가 담당합니다. 사람이 반드시 개입해야 하는 영역은 전문적 판단이 필요한 부분입니다.

새로운 원칙은 중요한 곳에서만 사람이 리뷰하는 것입니다. 법적 검토가 필요할 때는 반드시 법무 파트너가 리스크 판단에 참여해야 합니다. 신뢰 경계와 보안 민감 코드에는 해당 도메인 전문가가 필요하고, 제품 감각과 방향성에는 PM과 디자이너가 함께해야 합니다.

다만, 이 균형은 지속적으로 재검토해야 합니다. 모델이 발전할수록 신뢰와 검증의 적절한 비율은 계속 달라질 것이고, 오늘 사람이 필요한 영역이 다음 모델에서는 달라질 수 있습니다.

팀 구성: 경계가 흐려지는 역할

Claude와 AI는 팀 전반의 역할을 재편하고 있습니다. 우리 팀 PM들이 코딩을 많이 하게 된 것도 그 중 하나인데, 보기 좋은 변화입니다. Claude 덕분에 기존에는 개발자가 아니었던 사람들이 엔지니어링 작업을 더 많이 할 수 있게 됐고, 엔지니어들은 콘텐츠나 디자인처럼 전통적으로 기술 영역이 아니었던 일도 맡게 됐습니다.

Claude Code 엔지니어링 팀에서 제가 특히 중요하게 보는 인재 유형은 두 가지입니다. 하나는 제품 감각을 갖춘 창의적인 빌더입니다. 문제를 해결하는 제품을 만드는 것에 깊은 호기심과 열정을 가진 사람들입니다. 다른 하나는 시스템 분야의 깊은 전문성을 갖춘 엔지니어입니다. 예를 들어, 제가 팀에 합류했을 때 시스템 배경을 가진 전문가가 부족하다는 것을 파악했고, 웹용 Claude Code를 구축하고 Claude를 어디서든 실행할 수 있도록 하려면 그런 전문성이 반드시 필요했습니다.

반면, 단순한 처리량은 제가 덜 중요하게 여기는 기준입니다. 그건 모델이 처리합니다. 더 중요한 질문은 어디에 여전히 사람의 전문성이 필요한가이고, 저는 거기에 집중합니다.

새로운 규범을 어떻게 도입했는가

규범이 변화하는 과정에서, 일부는 팀 원칙으로 명시해 의무화했고, 나머지는 소규모 서브팀(pod)이 자율적으로 결정하도록 했습니다. Claude Code 핵심 팀에는 반드시 지켜야 하는 비협상적 원칙들이 있습니다.

• 자사 제품을 끊임없이 dogfooding하라: 크로스펑셔널 파트너를 포함한 Claude Code 팀 전원이 Claude Code(그리고 Claude Cowork)를 사용합니다. 우리는 항상 Claude를 활용해 업무를 더 빠르고 효율적으로 처리할 방법을 찾고 있습니다.
• 팀 구조는 최대한 평평하게 유지하라. 제가 Claude Code에 합류했을 때, 모든 매니저가 먼저 IC(개인 기여자)로 시작해서 실제로 제품을 출시해 보며 팀 내 효과적인 엔지니어가 되는 법을 배우고, Anthropic에서 엔지니어로 일한다는 것이 어떤 것인지 직접 경험해야 한다고 생각했습니다. Claude Code와 Claude Cowork에는 하나의 팀 미션이 있습니다. 매니저들은 팀의 민첩성을 유지하면서 pod 단위의 작업을 지원하여, 사람들이 일이 있는 곳으로 자유롭게 이동할 수 있도록 합니다.
• 더 이상 작동하지 않는 프로세스는 주저 없이 없애라: 마지막으로, 우리는 지금 하는 방식이 왜 맞는지를 끊임없이 의심합니다. 더 이상 납득이 되지 않는 것이 있다면, 팀원 누구든 명시적으로 기존 프로세스에 문제를 제기하고 폐기할 권한을 갖습니다.

그러나 이 몇 가지 원칙 안에서, 각 pod는 상당한 자율권을 가집니다. 트리아지에 Claude를 어떻게 활용할지, 기획 루틴이나 스탠드업을 어떻게 운영할지, 어떤 워크플로우를 먼저 'Claude화'할지는 각 pod가 직접 결정합니다.

새로운 프로세스가 자리잡고 있는지 확인하는 법

변화를 도입할 때 모든 엔지니어링 리더가 지금 당장 추적하기 시작해야 할 세 가지 지표가 있습니다.

• 온보딩 적응 시간 단축: 엔지니어, 디자이너, PM이 실질적인 기여를 시작하기까지 얼마나 걸리나요? 우리 팀에서는 1년 전보다 훨씬 빨라졌고, 엔지니어들은 이제 첫 번째 주에 실제 코드를 출시합니다.
• PR 사이클 타임 단축: 이 지표는 파고들어 볼 만한 흥미로운 지표입니다. 파이프라인의 어디가 확장에 어려움을 겪고 있는지 파악하는 데 도움이 됩니다. 코드 생성량이 크게 늘어나면서 빌드 시스템과 CI(지속적 통합)가 따라가지 못하는 경우가 생길 수 있습니다.
• Claude 지원 커밋 비율 증가: 우리 팀에서는 기본적으로 모든 커밋이 Claude의 도움을 받습니다. 지난 4개월간 Claude 비지원 커밋은 거의 본 기억이 없습니다.

세 번째 지표와 관련해, 처리량을 성공과 혼동하지 않도록 주의해야 합니다. 처리량은 하나의 지표일 뿐이고, 진짜 지표는 해결하려는 문제를 실제로 얼마나 잘 해결하고 있느냐입니다. 올바른 방향 설정이 뒷받침된다면, 높은 처리량은 문제를 더 빠르게 해결하는 데 기여할 수 있습니다.

시작하는 법

마지막으로 한 가지를 드린다면, 가장 시끄러운 워크플로우부터 선택하세요. 가장 비용이 많이 드는 것, 팀원들이 부담스러워하거나 피하고 싶어 하는 것이면 됩니다. 그리고 스스로에게 물어보세요. 이 프로세스가 아직 제 역할을 하고 있는가? 그렇다면, 자동화할 수 있는가?

예전에 한 팀에서 비용이 많이 드는 주간 리뷰를 한 적이 있었습니다. 많은 사람이 회의실에 모이는 자리였죠. 그런데 보면, 자기 차례가 와서 상태를 보고할 때만 잠깐 고개를 들고, 말이 끝나면 다시 노트북 화면으로 돌아가는 식이었습니다. 저는 간단한 질문 하나를 던졌습니다. "우리가 왜 이 회의를 하고 있죠? 시간 낭비가 심한 것 같은데요." 그 한마디로 모두가 깨달았습니다. 이 회의가 필요 없다는 것을. 결국 그 회의는 폐지됐습니다.

자, 스스로에게 물어보세요. 지금 당신의 엔지니어링 워크플로우에서 자동화하거나 아예 없애버릴 수 있는 것이 하나라도 있지 않나요?

‍