AI 리서치2026년 8월 29일5분 읽기

앤드류 응 스탠포드 교수가 공개한 AI 엔지니어링 스킬맵

에이전트가 자의적으로 고른 트레이드 오프를 검수할 능력이 있는지 판단하라!

TY KIM

Swiss School of Management - AI 박사

이 글을 읽으면 얻는 것 — 우리 조직의 AI 프로젝트가 왜 데모에서 멈춰 있는지 다섯 축으로 진단하는 절차, 코딩 에이전트에게 트레이드오프를 강제로 드러내게 만드는 프롬프트 2종, 착수 인터뷰용 체크리스트.

대상 독자 — 사내 AI 도입을 맡은 실무 리더, PoC를 운영으로 넘기지 못하고 있는 팀, AI 교육을 설계하는 담당자. 예상 소요시간 — 읽기 12분, 5단계 진단 실행 25분.

기준일 — 2026년 8월 29일. 원문 출처는 Andrew Ng, "AI Engineering Skills Map: Software engineering fundamentals" (DeepLearning.AI / X, 2026년 8월).

1. 팩트체크: 앤드류 응이 실제로 쓴 것

8월 14일에 AI 엔지니어링 4대 스킬을 공개했고, 8월 21일에 첫 번째 가지를, 그 다음으로 두 번째 가지인 소프트웨어 엔지니어링 기초를 다섯 갈래로 펼쳤다.

풀스택 애플리케이션 구축
데이터 관리
시스템 아키텍처 설계
시스템의 보안과 신뢰성 확보
프로덕션 스케일링과 운영

이 지도는 1만 건이 넘는 채용 공고 분석, 수십 건의 구조화된 전문가·채용담당자 인터뷰, 설문을 종합해 만들어졌다. 개인 의견이 아니라 시장이 지금 무엇에 돈을 쓰는지의 측정치다.

응이 이 항목에 붙인 논거는 한 문장으로 압축된다. 기초를 모르는 사람이 바이브 코딩을 하면 간단한 앱은 만들 수 있지만, 에이전트가 대신 나쁜 트레이드오프를 고른다. 개발자가 그런 트레이드오프가 존재한다는 사실 자체를 몰랐기 때문에 에이전트를 자기 상황에 맞게 조종하지 못한 것이다.

그가 나열한 트레이드오프 축은 일곱 개다. 레이턴시, 가용성, 일관성, 신뢰성, 유지보수성, 단순성, 비용.

여기서 유지보수성과 단순성이 목록에 있다는 점을 짚고 싶다. 앞의 다섯 개는 시스템 성능 지표지만, 뒤의 두 개는 조직이 감당할 수 있느냐의 문제다. 담당자가 퇴사한 뒤에도 남은 사람이 손댈 수 있는가. 이건 기술 결정처럼 보이지만 실은 인력 계획이다.

2. So What: 다섯 항목이 각각 무엇을 요구하는가

풀스택. 응은 AI 애플리케이션을 만들 때 AI 코어가 결국 더 넓은 소프트웨어 애플리케이션을 통해 표현되며, 그 껍데기를 직접 만들거나 형태를 잡아야 한다고 썼다. 에이전트 덕분에 프론트엔드 개발자나 모바일 개발자가 풀스택 역할로 넓어질 수 있게 됐지만, 스택이 실제로 어떻게 돌아가는지는 알아야 한다는 것이다. 그가 든 요소는 UI 컴포넌트, 캐싱, 페이지 렌더링, API 선택과 설계, 인증, 상태·세션 관리, 비동기 처리, 데이터 영속성, 테스트, 보안, 접근성이다.

데이터. 다섯 개 중 가장 중요한 논거가 여기 있다. 응은 데이터가 소프트웨어가 올라앉는 토대이면서 상대적으로 바꾸기 어렵다고 전제한다. 에이전트가 마이그레이션을 도와줘도 그렇다는 단서까지 붙였다.

그다음 문장이 핵심이다. AI 시스템은 자기 입력 컨텍스트를 데이터 소스에서 가져오기 때문에, 데이터 아키텍처를 잘못 고르면 AI는 자기가 무엇을 모르는지조차 모른다. 그래서 맥락을 아는 숙련된 사람의 개입이 필요하다.

이 문장이 국내 RAG 프로젝트 실패의 절반을 설명한다. 답변이 틀린 게 아니라, 애초에 검색 범위에 들어오지 않은 문서가 있는데 시스템도 사용자도 그 사실을 모른다. 모델을 바꿔도 해결되지 않는 종류의 실패다.

아키텍처. 응이 강조한 것은 올바른 아키텍처가 움직이는 표적이라는 점이다. 빠른 프로토타입에 맞는 단순한 구조는 첫 프로덕션 시스템에 맞지 않고, 그것도 규모가 커지면 또 바뀐다. 사용자가 몇 명인지, 레이턴시가 얼마나 중요한지, 비용이 얼마나 중요한지를 알아야 플랫폼, 프론트-백 경계, 시스템 분해, 상태 배치, 모놀리스 대 마이크로서비스를 정할 수 있다.

PoC를 그대로 운영으로 밀어 올리려다 실패하는 팀은 이 지점을 놓친 것이다. 프로토타입 구조가 잘못된 게 아니라, 프로토타입 단계에서 옳았던 구조를 다음 단계에서 갈아야 한다는 걸 계획에 넣지 않은 것이다.

보안과 신뢰성. 테스트 전략(유닛과 통합의 비율, 프레임워크, 커버리지 수준), 실패를 전제로 한 설계, 우아한 성능 저하, 장애의 폭발 반경 최소화. 그리고 응은 'shift left'를 언급하며 많은 개발자가 이제 부분적으로 보안 엔지니어가 되고 있다고 썼다. AI 도구로 취약점 스캔, 의존성 공급망 점검, 클라우드 설정 검사를 할 수 있게 됐지만, 잘하려면 여전히 보안 지식이 필요하다는 단서도 함께 달았다.

운영. SDLC 실행, 배포 환경 구성, 릴리스 전략, CI/CD, IaaS 이해. 운영 단계에서는 관측성 도구, 알림, 인시던트 관리. 스케일링에서는 실제 부하 파악, 서버 확장, 로드밸런싱, 샤딩·인덱싱·복제. 그리고 버전 관리, 코드 리뷰, 의존성 유지보수, 기술부채 관리다.

응의 결론은 무엇이 죽고 무엇이 남는지를 구분한다. 코딩 문법 암기 같은 일부 지식은 실제로 폐기되고 있다. 그 위에서, 소프트웨어가 어떻게 돌아가는지 깊이 이해하는 개발자가 이해 없이 바이브 코딩하는 사람을 크게 앞선다.

3. 내 업무에 적용 원칙 5단계

진행 중인 AI 프로젝트가 하나라도 있는 팀을 전제로 한다.

1단계. 대상 고르기

입력: 현재 진행 중이거나 멈춰 있는 AI 프로젝트 1개
행동: 데모까지 갔지만 운영에 못 올라간 것을 우선 고른다
기대 결과: 프로젝트 이름과 현재 단계(프로토타입/파일럿/운영)를 한 줄로 적을 수 있다

2단계. 다섯 축 공란 찾기

입력: 1장의 다섯 항목
행동: 각 항목마다 담당자 이름을 적는다. 이름이 안 나오는 칸에 표시한다
기대 결과: 이름이 비는 칸이 몇 개인지 센다. 3개 이상이면 기술 문제가 아니라 조직 설계 문제 단계다

3단계. 데이터 사각지대 점검

입력: RAG나 검색이 붙은 시스템의 인덱싱 대상 목록
행동: "지금 인덱스에 안 들어간 문서를 사용자가 물으면 시스템이 뭐라고 답하는가"를 실제로 5회 테스트한다
기대 결과: 모른다고 답하면 통과. 그럴듯하게 지어내면 응이 말한 사각지대가 실재하는 것이다

4단계. 트레이드오프 선언서 만들기

입력: 일곱 개 축(레이턴시·가용성·일관성·신뢰성·유지보수성·단순성·비용)
행동: 이 프로젝트에서 지킬 것 2개, 포기할 것 2개를 골라 문서에 적는다
기대 결과: 포기 항목을 못 고르면 아직 요구사항이 정의되지 않은 것이다. 전부 지키겠다는 답은 답이 아니다

5단계. 아키텍처 재검토 시점 못 박기

입력: 4단계 문서
행동: 현재 구조를 언제 갈아엎을지 조건을 적는다. 시점이 아니라 조건으로 쓴다(동시 사용자 N명 도달, 문서 수 N건 초과 등)
기대 결과: 조건 2개 이상이 문서에 남는다

4. 복사해서 쓰는 프롬프트

기본형 — 에이전트가 고른 트레이드오프를 드러내게 하기

방금 작성한 코드에 대해 아래를 표로 정리해줘.

1. 레이턴시, 가용성, 일관성, 신뢰성, 유지보수성, 단순성, 비용
   이 일곱 축에서 네가 내린 선택을 각각 한 줄로 적어줘.
2. 각 선택에서 무엇을 얻고 무엇을 잃었는지 함께 적어줘.
3. 내가 [지킬 항목]을 우선한다면, 위 선택 중 무엇을 바꿔야 하는지 알려줘.

코드는 아직 수정하지 마. 표만 먼저 보여줘.

[지킬 항목] — 4단계에서 고른 축. 예: 유지보수성, 비용

고급형 — 다섯 축 진단 리포트 뽑기

역할: 너는 프로덕션 시스템 아키텍처 리뷰어다.

컨텍스트
- 서비스: [서비스 한 줄 설명]
- 현재 단계: [프로토타입 / 파일럿 / 운영]
- 예상 동시 사용자: [숫자]
- 유지보수 인력: [숫자]명, 배경은 [예: 비개발 직군 2명]
- 지킬 것: [축 2개] / 포기할 것: [축 2개]

작업
아래 다섯 축으로 현재 설계를 진단해줘.
(1) 풀스택 구성 (2) 데이터 관리 (3) 시스템 아키텍처
(4) 보안·신뢰성 (5) 운영·스케일링

제약
- 축마다 [현재 상태 / 위험 / 다음 단계에서 깨질 지점] 3개 항목으로 쓴다.
- 근거가 코드나 내 설명에 없으면 "확인 불가"라고 적고 추측하지 않는다.
- 개선안은 축당 1개만. 여러 개 나열하지 않는다.
- 마지막에 "지금 손대지 않아도 되는 것" 목록을 따로 준다.

출력 형식: 마크다운 표 5개 + 마지막 목록 1개

[서비스 한 줄 설명] — 예: 사내 인사규정 질의응답 챗봇
[유지보수 인력] — 이 칸을 정직하게 쓰는 것이 이 프롬프트의 핵심이다. 인력이 적으면 에이전트가 단순성 쪽으로 설계를 당겨준다
[축 2개] — 예: 지킬 것 유지보수성, 비용 / 포기할 것 레이턴시, 단순성

5. 프롬프트 개선 팁 3가지

팁 1. 제약조건에 인력을 넣는다. 대부분의 사람이 성능 요구사항만 적는다. 유지보수 인력 수와 배경을 넣으면 에이전트가 고르는 스택이 실제로 바뀐다. 응이 트레이드오프 목록에 유지보수성과 단순성을 넣은 이유가 이것이다.

팁 2. "확인 불가"를 허용한다. 근거가 없으면 추측하지 말고 확인 불가로 적으라는 한 줄이 진단 리포트의 신뢰도를 결정한다. 이 줄이 없으면 에이전트는 빈칸을 그럴듯하게 채운다.

팁 3. 나쁜 프롬프트와 개선 프롬프트를 비교해 본다.

구분 내용 나쁜 예 이 코드 리뷰해줘. 문제점 알려줘. 왜 나쁜가 판단 기준이 없어서 일반론이 돌아온다. 어떤 축에서 봐야 하는지, 무엇을 포기해도 되는지 에이전트가 모른다 개선 예 동시 사용자 50명, 유지보수 인력 1명(비개발 직군) 기준으로 이 코드를 검토해줘. 유지보수성과 비용을 우선하고 레이턴시는 포기한다. 이 기준에서 문제가 되는 지점만 3개 짚어줘. 나머지는 언급하지 마.

6. 흔한 실패 2가지

실패 A. 진단이 전부 "잘 되고 있다"로 나온다

증상: 다섯 축 리포트가 대체로 긍정적으로 나온다
원인: 컨텍스트에 규모와 인력을 안 넣었다. 사용자 5명 기준으로는 거의 모든 설계가 통과한다
교정: 예상 동시 사용자와 유지보수 인력을 반드시 숫자로 넣는다. 목표 규모가 아니라 6개월 뒤 현실적 숫자로 쓴다

실패 B. 개선안이 20개 쏟아져 아무것도 못 한다

증상: 리포트는 훌륭한데 실행이 안 된다
원인: 개선안 개수를 제한하지 않았다
교정: 축당 1개로 제한하고, "지금 손대지 않아도 되는 것" 목록을 함께 요구한다. 안 해도 되는 일을 확정하는 것이 할 일을 정하는 것보다 진도를 빠르게 한다

7. 결과 확인 체크리스트

[ ] 다섯 축 각각에 담당자 이름이 적혀 있다
[ ] 인덱스 밖 질문 테스트 5회에서 시스템이 모른다고 답했다
[ ] 포기할 트레이드오프 축 2개가 문서에 적혀 있다
[ ] 아키텍처를 갈아야 하는 조건이 숫자로 2개 이상 적혀 있다
[ ] 이번 주에 손대지 않을 항목 목록이 있다

8. 한계

이 지도는 채용 공고에서 출발했다. 미래 예측이 아니라 지금 기업이 무엇에 돈을 쓰는지의 측정치다. 정확한 대신 후행한다. 응 본인도 AI가 변하는 대로 갱신하겠다고 밝혔다.

그리고 다섯 항목 중 데이터 관리가 국내 기업의 첫 번째 병목이라는 판단은 제 현장 경험이지 응의 주장이 아니다. 조직에 따라 아키텍처나 운영이 먼저 걸릴 수 있다. 2단계 공란 찾기를 먼저 하고 판단하시면 된다.

지금 진행 중인 AI 프로젝트 하나를 골라 3단계 데이터 사각지대 점검부터 하시길 권한다. 5분이면 되고, 결과가 나쁘면 나머지 네 축은 아직 볼 필요가 없다.

#Agentic Engineering