AI-Native Teams: 기존 개발팀을 AI 중심 팀으로 바꾸는 People·Projects·Platforms·Processes

AI를 쓰는 팀과 AI에 맞춰 설계한 팀은 다릅니다. Andrew Ng은 그 차이를 사람·과제·기반·일하는 방식 네 가지로 나눕니다. 그중 가장 크게 바뀌는 것은 병목의 자리입니다. 구현이 싸진 만큼 무엇을 만들지 정하는 일이 느려졌으니, 맥락과 권한을 가진 작은 팀에 결정을 맡기고 큰 위험 세 가지만 막으라는 것이 결론입니다.

요약

Andrew Ng은 2026년 10월 23일 The Batch 376호 편지에서, 여러 엔지니어링 리더와 나눈 대화를 바탕으로 팀을 AI에 능숙하게 만드는 틀을 내놓았습니다. 틀은 People(사람), Projects(과제), Platforms(기반), Processes(일하는 방식) 네 가지입니다. 출발점은 AI-native team(AI 네이티브 팀)이라는 목표입니다. 새로 꾸리는 2~3명 팀은 처음부터 AI 네이티브인 사람만으로 짤 수 있지만, 대기업은 이미 있는 팀을 옮겨 가야 합니다. 그래서 Ng은 도구를 나눠 주는 데서 멈추지 말고 팀의 설계 자체를 바꾸라고 권합니다.

네 기둥을 묶는 논리는 병목의 이동입니다. 분명한 명세가 있으면 소프트웨어를 만드는 비용이 크게 내려갔습니다. 그러자 무엇을 만들지 정하는 일처럼 구현 바깥의 일이 가장 느린 단계가 됐습니다. Ng의 팀에서는 엔지니어가 제품 결정에 참여하고, 때로는 마케팅과 디자인에도 손을 댑니다. 무엇을 만들어야 하는지 알거나 알아낼 수 있는 숙련된 팀은, 그렇게 하도록 허락만 받으면 일을 빨리 끝낸다는 것이 Ng의 관찰입니다. 아래에서는 네 기둥이 각각 어떻게 작동하는지 풀고, 에이전트용 기반을 실제로 깔 때 정할 설정과 6주 실행 계획을 덧붙였습니다.

핵심 메커니즘

AI-Native Team: AI를 쓰는 팀이 아니라 AI에 맞춰 설계한 팀

무엇인가. AI의 강점을 쓰고 AI가 만드는 병목을 피하도록 처음부터 짠 팀입니다. 기존 팀이 AI 도구를 덧붙여 쓰는 상태와 구분됩니다.

어떻게 작동하나. 기존 팀은 조직도와 업무 흐름을 그대로 두고 개인이 도구를 고릅니다. 이러면 일부 작업은 빨라지지만 팀 전체의 처리 속도는 가장 느린 단계에 묶입니다. AI 네이티브 팀은 거꾸로 갑니다. 어디가 빨라지고 어디가 새로 막히는지를 먼저 보고, 사람의 역할과 기반, 결정 권한을 그 지도에 맞춰 다시 배치합니다.

작은 예시(가상). 사내 정산 시스템을 맡은 6명 팀이 있다고 합시다. 코딩 에이전트를 나눠 준 뒤 구현은 빨라졌는데, 기획 회의와 현업 확인을 기다리는 시간은 그대로입니다. AI 네이티브로 바꾼다는 것은 이 기다림을 줄이도록 결정권과 현업 접점을 팀 안으로 들이는 일입니다.

People: 리더가 직접 만들어 보고, 실험할 시간과 예산을 준다

무엇인가. 팀원 한 사람 한 사람이 AI 엔지니어링에 능숙해지도록 돕는 기둥입니다. 실험할 공간과 예산을 주고, 성장을 장려하는 문화를 만듭니다.

어떻게 작동하나. Ng이 특히 강조하는 대상은 리더 자신입니다. 리더가 계속 손을 움직여 자기 프로젝트를 만들어 봐야 한다고 봅니다. 코딩 에이전트 덕분에 리더가 다시 만들기 시작하는 문턱이 낮아졌습니다. 직접 해 본 경험은 기술 결정과 사업 결정 모두의 판단력을 높입니다. Ng은 이를 자전거 타기에 빗댑니다. 책으로는 배울 수 없고 타 봐야 압니다.

언제 쓰나. AI 과제의 일정이나 인력 규모를 리더가 정해야 하는데 감이 없을 때 가장 먼저 씁니다. 리더가 직접 만들어 보지 않으면 에이전트가 무엇을 잘하고 어디서 막히는지 보고서로만 알게 됩니다.

Projects: 아래서 올라온 아이디어에 위에서 힘을 싣고, 성장 과제를 섞는다

무엇인가. 어떤 AI 과제를 할지 고르는 기둥입니다. 현장에서 올라오는 bottom-up(상향식) 혁신은 중요합니다. 하지만 그중 소수 과제를 top-down(하향식)으로 밀어줘야 규모를 키우고 사업 효과를 보여 줄 수 있습니다.

어떻게 작동하나. 현장 아이디어는 많이, 작게 시작합니다. 리더는 그중 유망한 몇 개를 골라 자원과 후원을 붙입니다. 이때 AI를 다른 부서보다 잘 아는 엔지니어링 리더가 과제 선정에 참여해야 합니다. 과제 목록은 효율과 비용 절감만으로 채우지 않습니다. 새 제품, 사용자를 새롭게 돕는 방식 같은 성장 과제를 함께 넣습니다.

Platforms: 에이전트가 맥락을 얻고 행동할 수 있게 여는 기반

무엇인가. 에이전트가 일을 잘하도록 돕는 인프라입니다. 개발자가 에이전트에 관련 맥락을 주고 행동하게 할 수 있도록 데이터와 도구를 정리합니다. 무엇이 필요한지는 조직마다 다릅니다.

어떻게 작동하나. Ng이 든 예는 두 갈래입니다. 맥락을 읽게 하는 쪽은 보안·거버넌스를 지키며 저장소를 에이전트에게 보이게 하고, 설계 결정과 지원 티켓에 접근하게 하고, 데이터를 agent-ready(에이전트가 바로 쓸 수 있는 상태)로 만드는 일입니다. 행동하게 하는 쪽은 에이전트용 내부 도구, AI 코드 리뷰 도구, 에이전트가 디버그·배포하도록 돕는 CI(지속적 통합) 파이프라인, 에이전트가 돌아갈 샌드박스나 전용 머신, 재사용 가능한 agent skills(에이전트용 작업 요령 묶음)를 정리해 공유하는 방법입니다. 실행 환경을 두고 Ng은 『a lot of Mac minis』라는 표현도 씁니다.

언제 쓰나. 어떤 회사에서는 첫 단계가 훨씬 앞에 있습니다. 개발자가 손으로만 코딩하지 않고 에이전트를 쓰도록 CIO를 설득하는 일부터 해야 합니다.

Processes: 새 병목에 맞춘 고맥락·고권한 팀

무엇인가. AI가 만든 새 병목에 맞춰 업무 흐름을 다시 짜는 기둥입니다.

어떻게 작동하나. 명세대로 만드는 일이 싸지면 무엇을 만들지 정하는 일이 막힙니다. Ng은 high-context, high-empowerment team(맥락이 많고 권한이 큰 팀)을 만들라고 권합니다. 팀이 행동에 필요한 정보와 권한을 함께 갖게 하는 것입니다. 안전장치는 가볍게 두되 큰 위험 세 가지만 막습니다. 기밀 데이터 유출, 대형 장애, 데이터 손실입니다.

아직 풀리지 않은 부분. 개인과 팀 사이의 조정은 여전히 어렵습니다. Ng은 관행이 아직 만들어지는 중이라고 보면서, 서로 다른 팀의 에이전트가 정보를 공유하게 하는 방향을 유망하다고 꼽습니다.

통념과 다른 주장

저자가 든 사례

Ng의 팀: 엔지니어가 제품 결정까지 맡는다

• 상황: 명세가 분명한 구현은 에이전트로 훨씬 싸졌고, 무엇을 만들지 정하는 일이 느린 단계로 남았습니다.
• 한 일: 엔지니어가 제품 관리 결정에 참여하고, 때로는 마케팅과 디자인에도 관여합니다.
• 결과: 무엇을 만들지 알거나 알아낼 수 있는 숙련된 팀은 허락만 받으면 빨리 끝낸다고 Ng은 말합니다. 구체적인 수치나 기간은 원문에서 밝히지 않았습니다.
• 연결: Processes 기둥, 그리고 병목 이동의 사례입니다.

일부 기업: CIO 설득이 첫 단계인 곳

• 상황: 개발자가 아직 에이전트 없이 손으로만 코딩하는 회사가 있습니다.
• 한 일: Ng은 이런 곳의 첫 단계로 개발자의 에이전트 사용을 CIO에게 허락받는 일을 듭니다.
• 결과: 원문에서 밝히지 않음. 특정 회사 이름도 없습니다.
• 연결: Platforms 기둥의 출발점입니다.

기술 디테일: 에이전트가 일할 수 있는 기반을 깔려면

저장소와 문서를 열 때는(Platforms) 범위·형식·기록 세 가지를 먼저 정합니다. 저장소는 팀 단위로 범위를 나눈 읽기 전용 토큰으로 열고, 쓰기는 브랜치 생성과 PR까지만 허용합니다. 설계 결정은 ADR(Architecture Decision Record, 결정 하나를 문서 하나로 남기는 기록) 폴더에 Markdown으로 모으고, 각 문서 머리에 status(proposed·accepted·superseded), date, owner를 둡니다. 지원 티켓은 주 1회 내보내되 이름·연락처를 마스킹하고 ticket_id, product_area, symptom, resolution, created_at 다섯 필드로 고정합니다. 에이전트가 MCP(Model Context Protocol, 에이전트가 외부 도구·데이터에 접근하는 표준 규약) 서버로 이 자료를 읽게 하면 접근 로그가 한곳에 남습니다.

agent-ready data를 만들려면(Platforms) 사람이 읽는 표가 아니라 에이전트가 조회할 수 있는 정의를 붙입니다. 테이블마다 한 줄 설명, 열마다 단위와 허용값, 자주 묻는 질문 5~10개와 정답 쿼리를 함께 둡니다. 에이전트가 같은 질문에 3회 답하게 해 결과가 달라지는 비율을 재고, 다른 결과가 나온 질문은 정의를 보강합니다.

세 가지 위험을 막는 가드레일은(Processes) 플랫폼 단계에 넣습니다. 사람이 매번 승인하면 고권한 팀의 속도가 사라지므로, 규칙으로 걸러 낼 것은 실행 경로에서 자동으로 막습니다. 아래는 가상 예시입니다.

위험	막는 장치	사람 승인
기밀 데이터 유출	샌드박스 외부망 차단, 기밀 등급 데이터는 복제·마스킹본만	등급 예외 요청 시
대형 장애	운영 반영은 CI 통과 + 단계적 배포, 자동 롤백 조건 설정	운영 반영 전 1회
데이터 손실	운영 DB 쓰기 권한 없음, 삭제 명령 정책에서 차단, 일일 백업 확인	마이그레이션 시

에이전트용 CI와 코드 리뷰는(Platforms) 사람이 아니라 에이전트가 읽는 출력을 냅니다. 빌드 실패 로그를 JSON으로 요약해 step, error_type, file, line, last_passing_commit을 남기면 에이전트가 스스로 디버그를 시작할 수 있습니다. AI 코드 리뷰는 사람 리뷰를 대신하지 않고 앞에 세웁니다. 보안·테스트 누락 같은 점검 항목을 정해 두고, 리뷰 의견마다 severity(block·warn·info)를 달아 block만 병합을 막게 합니다.

{
  "step": "integration-test",
  "error_type": "assertion",
  "file": "billing/settle.py",
  "line": 212,
  "last_passing_commit": "a1b2c3d",
  "hint": "통화 반올림 규칙 변경 이후 실패"
}

skills를 공유하려면(Platforms) 한 사람이 쌓은 요령을 파일로 바꾸는 규칙을 둡니다. 같은 지시를 세 번 넘게 쓰면 skill 후보로 봅니다. skill은 폴더 하나에 SKILL.md(언제 쓰나, 절차, 예시, 끝난 뒤 확인할 것)를 넣고, 리뷰를 거쳐 공유 저장소에 올립니다. 담당자와 버전을 적고, 사용 횟수와 실패율을 월 1회 봅니다. 3개월 동안 안 쓰인 skill은 보관함으로 옮깁니다.

팀 사이 조정을 에이전트 정보 공유로 돕는다면(Processes) 공통 변경 로그부터 만듭니다. 각 팀 에이전트가 작업을 마칠 때 team, change, affected_api, decision_ref를 공통 스키마로 남기게 합니다. 다른 팀 에이전트는 작업 전에 이 로그를 조회해, 자기 변경과 겹치는 API가 있으면 경고를 띄웁니다. Ng도 이 영역의 관행은 아직 만들어지는 중이라고 보니, 처음에는 두 팀 사이에서만 시험합니다.

현업 실행 디테일: 누가, 언제, 무엇을

역할	담당	6주 동안 하는 일
스폰서	CTO 또는 개발 총괄 임원	리더 실습 직접 참여, 성장 과제 1개 후원, 파일럿 팀 권한 승인
엔지니어링 리더	팀장 2~3명	내부 도구 1개 직접 제작, 과제 후보 선정 참여
플랫폼 담당	플랫폼·DevOps 엔지니어 1~2명	저장소 권한, 샌드박스, 에이전트용 CI, skills 저장소
보안·데이터	보안 담당 1명, 데이터 담당 1명	기밀 등급 정의, 마스킹, 세 가지 위험 가드레일
파일럿 팀	엔지니어 3~5명 + 현업 담당 1명	제품 결정 권한을 받아 과제 하나 출시
제품	PM 1명	결정 권한 위임 범위 합의, 판정 지표 관리

시작 전 준비물. 코딩 에이전트 사용 허가(사내 규정 개정 포함), 리더 실습용 예산과 주 4시간가량의 시간, 열어 줄 저장소 목록과 기밀 등급표, 최근 분기 지원 티켓, 지금 진행 중인 AI 과제 목록(비용 절감·성장으로 나눠 표시)을 챙깁니다.

주차	할 일	산출물
1주	리더별로 에이전트로 내부 도구 1개 만들기	시연 영상, 막힌 지점 메모
2주	과제 후보 수집, 저장소 권한 설정	후보 목록, 접근 정책
3주	과제 3개 선정(성장 과제 1개 이상), 샌드박스와 가드레일 시험	과제 정의서, 가드레일 점검표
4주	skills 저장소 개설, 파일럿 팀 출범	skill 5개, 팀 권한 문서
5주	파일럿 팀이 결정·구현·출시	출시본, 결정 기록
6주	판정 회의	확대 여부와 다음 팀

리더와 팀에 던질 질문.

1. 최근 한 달 동안 가장 오래 기다린 단계는 구현인가, 결정인가?
2. 에이전트가 못 읽어서 사람이 대신 찾아 준 자료는 무엇인가?
3. 지금 AI 과제 가운데 매출이나 사용자 수를 늘리는 과제는 몇 개인가?
4. 파일럿 팀이 누구 승인 없이 정할 수 있는 것은 어디까지인가?
5. 기밀 유출·대형 장애·데이터 손실 중 지금 가장 막기 어려운 것은 무엇인가?

진행 판정 기준(가상 예시). 리더 전원이 실습을 마쳤고, 과제 목록에 성장 과제가 하나 이상 있고, 파일럿 팀의 아이디어에서 출시까지 걸린 기간이 이전 같은 규모 과제보다 짧고, 6주 동안 세 가지 위험 사고가 0건이면 다음 팀으로 넓힙니다. 하나라도 못 채우면 그 기둥만 2주 더 돌립니다.

AX 적용 제언. 고객사에 이 틀을 옮길 때는 순서가 중요합니다. 많은 회사가 도구 배포(People의 일부)와 비용 절감 과제(Projects의 절반)에서 멈춥니다. 먼저 경영진과 개발 리더가 직접 만들어 보게 하고 에이전트 사용을 공식 허용합니다. 다음으로 맥락과 샌드박스를 깔고, 그 위에서 성장 과제 하나를 임원이 후원하게 합니다. 마지막에 파일럿 팀에 제품 결정 권한을 줍니다. 기반 없이 권한부터 주면 에이전트가 쓸 맥락이 없고, 권한 없이 기반만 깔면 빨라진 구현이 결정 대기열에 다시 묶입니다.

원문 사례

항목	내용
발표처	The Batch 376호(DeepLearning.AI, 2026.10.23), Andrew Ng의 편지
대상 독자	팀을 AI에 능숙하게 만들려는 엔지니어링 리더
목표	AI를 쓰는 기존 팀이 아니라 AI 네이티브 팀. 새 2~3명 팀은 처음부터 가능, 대기업은 기존 팀 전환
People	개인 역량 개발, 실험 공간·예산, 성장 문화, 리더의 직접 빌드(자전거 비유)
Projects	bottom-up 혁신 + 소수 과제의 top-down 후원, 엔지니어링 리더의 과제 선정 참여, 성장 과제 포함
Platforms	저장소 공개(보안·거버넌스), 설계 결정·지원 티켓 접근, agent-ready data, 에이전트용 내부 도구, AI 코드 리뷰, 에이전트용 CI, 샌드박스·전용 머신, 재사용 skills. 일부 기업은 CIO 설득이 첫 단계
Processes	새 병목에 맞춘 재설계, 엔지니어의 제품 결정 참여, 고맥락·고권한 팀, 기밀 유출·대형 장애·데이터 손실 방지
열린 과제	개인·팀 간 조정. 팀별 에이전트의 정보 공유가 유망한 방향
수치	팀 규모 2~3명 외에는 없음

핵심 개념

coding agent(코딩 에이전트)

명세를 받아 코드를 쓰고 실행·수정까지 하는 AI. 리더가 다시 직접 만들기 시작하는 문턱을 낮춘 도구.

agent skills

특정 작업을 하는 절차와 예시를 파일로 묶어 에이전트가 필요할 때 불러 쓰게 한 것. 팀이 공유하면 개인의 요령이 조직 자산이 된다.

sandbox(샌드박스)

운영 시스템과 분리돼 에이전트가 코드를 실행해도 밖에 영향을 주지 않는 실행 환경.

CI pipeline

코드 변경마다 빌드·테스트·배포를 자동으로 돌리는 흐름. 에이전트가 결과를 읽고 스스로 고칠 수 있게 만드는 것이 이 글의 관점.

내 메모

TODO: 내 생각 추가

원문: Andrew Ng, The Batch 376호 편지(DeepLearning.AI, 2026.10.23). 요약·메커니즘·통념과 다른 주장·사례·원문 사례 표는 편지의 내용을 AX Review가 다시 정리했습니다. 기술·현업 디테일, 권한·가드레일 표, JSON 예시, 6주 일정과 판정 기준, 적용 순서, 인포그래픽은 새로 작성했으며 숫자는 가상 예시입니다. ADR과 MCP 설명은 일반적으로 알려진 정의를 따랐습니다. 원문 전체는 The Batch에서 볼 수 있습니다.