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

출처: Anthropic 블로그 Running an AI-native engineering org.
조직 전체가 Claude Code를 기본 도구로 쓰기 시작하면, 효율을 위해 만들었던 기존 프로세스가 오히려 발목을 잡는다. 코드를 쓰는 비용이 사라졌기 때문에 병목이 작성에서 검증·리뷰·보안으로 옮겨간다.
- 따라서 도구만 도입하는 게 아니라 계획·역할·조직 구조를 다시 설계해야 한다.
관통하는 원칙 하나: “이 프로세스가 아직도 필요한가, 자동화할 수 있는가?” 를 모든 절차에 물어라. 필요해서 만든 절차라도 조건이 바뀌면 저절로 사라지지 않으므로, 의도적으로 걷어내야 한다.

더는 작동하지 않는 프로세스들

계획: 장기 로드맵 → 점-시간(just-in-time) 계획.
- 코딩이 비쌌던 시절엔 6개월 로드맵이 합리적이었다. 이제는 그 계획이 3개월이면 낡는다.
- 대신 프로토타입 → 내부 사용자에게 배포 → 피드백 반영 사이클을 짧게 돈다.
맥락 수집: “누가 만들었나” → “실제로 뭘 알아야 하나”.
- 예전엔 코드 저자를 찾아 물었지만, 이제는 Claude에게 코드베이스를 직접 묻는다.
- 자동화 예: 매일 아침 Claude가 고객 피드백을 요약하게 설정.
코드 리뷰: 신뢰하되 검증한다.
- Claude가 맡는 것: 스타일, 린팅, 버그 포착, 테스트 추가.
- 사람이 맡는 것: 법적 검토, 보안, 제품 감각이 필요한 판단.
- 이 경계는 고정이 아니다. 모델이 좋아질수록 사람이 지켜야 할 지점도 계속 옮겨간다.
팀 구성: 역할의 경계 해체.
- 엔지니어=코딩, PM=계획, 디자이너=디자인이라는 고정 분업이 흐려진다. PM이 코드를 짜고, 엔지니어가 콘텐츠·디자인을 만진다.
- 채용 기준이 바뀐다. 중요해진 것: ① 제품 감각을 가진 창의적 빌더 ② 시스템을 깊게 아는 전문가. 약해진 것: 단순 처리량(그건 모델이 한다).

핵심 팀에 강제하는 조건(필수):
- 철저한 도그푸딩: 모든 구성원이 Claude Code·Claude Cowork를 실제로 쓴다.
- 최대한 평탄한 조직: 매니저도 IC(개별 기여자)로 시작해 직접 손을 댄다.
- 비효율 제거 권한 부여: 구성원이 불필요한 절차를 스스로 폐지할 명시적 권한을 갖는다.
유연성 영역(각 소규모 pod가 자율 결정):
- Claude로 분류·트리아지하는 방식, 스탠드업·계획 회의 형태, 어떤 워크플로우부터 “Claude화"할지 우선순위.