PoCs

모든 AI 엔지니어링 기술은 같은 비결정성을 두르는 일이다

Andrew Ng 의 AI 엔지니어링 스킬 맵(구인공고 1만+ 건과 수십 건의 인터뷰 기반)은 네 기술을 듭니다 — AI 앱 빌드·배포, 소프트웨어 엔지니어링 기본기, 코딩 에이전트 사용, 빌드 형성(shaping the build). 이 목록의 렌즈로 읽으면 넷은 한 일로 수렴합니다 — 비결정적 핵심 둘레에 결정적 틀(명세·평가·검증기·명명된 트레이드오프)을 두르기. Ng 스스로 말합니다 — AI 앱을 다르게 만드는 단 하나는 예측 불가능한 출력이고, 첫 번째 기술은 그것이 예측 가능하게 행동하도록 만드는 규율입니다. 에이전트가 *제작*을 싸게 만들수록, 살아남는 기술은 그 틀입니다.

아직 만들지 않았습니다

이 페이지는 카드에 적힌 내용을 펼쳐 보여줄 뿐입니다 — 돌아가는 코드도, 열어볼 데모도 아직 없습니다. 무엇을 왜 만들려는지가 아래에 있습니다.

어떻게 보나

아직 범위 미정 — 빌드가 아니라 네 기술에 대한 자기 점검입니다. 실제 프로젝트에서 먼저 비결정성이 실제로 어디 사는지(모델 출력, 에이전트 행동) 짚고, 그 둘레의 결정적 틀을 목록화합니다. (1) 모델 행동을 재고 조종하는 평가 / 오류 분석 루프 — 진짜 평가 세트가 있는가, 아니면 감인가? (2) *이름 붙일 수 있는* 소프트웨어 트레이드오프 — 비용·규모·신뢰성·속도·보안 — 을 에이전트 조종에 쓰고 있는가, 아니면 에이전트가 당신 대신 조용히 고르고 있는가. (3) 에이전트가 스스로 루프를 닫도록 건네는 검증기, 그리고 함정에 대한 가드레일(에이전트가 프로덕션 DB 에 닿는 것). (4) 명세 — 건네받은 디자인 구현이 아니라 *무엇을* 만들지에 당신 판단이 들어가는가. 산출물: 각 기술마다 구체적 산출물 하나(평가 세트, 한 장짜리 트레이드오프 문서, 검증기 스크립트, 명세), 그리고 넷 중 셋이 같은 메타 기술 — 비결정적 부분을 통치 가능하게 만들기 — 이라는 정직한 관찰. 출처: Andrew Ng(DeepLearning.AI), X, 2026-08-15 — 이 기술들을 가르치는 게 사업인 사람의 큐레이티드 프레임워크; 유용하되 옹호로 읽을 것.

기술 노트

각 항목이 실제로 무엇을 보여주고 어떻게 동작하는지 — 위 카드보다 자세한 기술 설명입니다.

모든 AI 엔지니어링 기술은 같은 비결정성을 두르는 일이다준비 중

목적: **Ng 자신의 프레이밍이 관통선을 주고, 그것이 네 항목 목록보다 날카롭습니다.** 그는 AI 애플리케이션이 전통 소프트웨어와 정확히 한 가지로 다르다고 말합니다 — 예측 불가능한 출력 — 그리고 첫 번째 기술이 통계 기법(평가, 오류 분석)으로 그것을 예측 가능하게 만드는 것이라고 합니다. 이건 넷 중 하나가 아니라 나머지 셋이 얹혀 있는 축입니다. 소프트웨어 기본기가 중요한 이유는 트레이드오프를 알아야 비결정적 에이전트를 정밀한 언어로 조종할 수 있어서입니다. 코딩 에이전트 사용은 그 한계를 관리하고 검증기를 줘서 루프를 닫게 하는 것입니다. 각각은 *비결정적 엔진 둘레에 결정적 틀을 두르는* 방법입니다 — 이 목록이 계속 도달하는 지점: `a-boolean-hides-a-state-machine`(한 번 잘 됐다고 증명 아님), `agent-ask-not-write`(결정적 실행자가 비결정적 제안자를 게이트), `simulate-before-sign`(돌이킬 수 없는 행동 전 검증). **경제적 독법은 다시 `the-interface-premium-collapses` 입니다 — 에이전트가 제작을 싸게 만들수록, 가치는 에이전트가 소환 못 하는 것으로 이동합니다 — 들어가는 명세와 나오는 것을 판정하는 평가.** "빌드 형성(shaping the build)"은 Ng 가 그 이동을 직접 이름 붙인 것입니다: 엔지니어는 픽셀 단위 디자인을 받아 구현하기를 멈추고 명세에 무엇이 들어갈지를 정하기 시작합니다 — `demonstration-is-not-a-specification` 과 `three-thousand-lanterns-nobody-asked-for`(에이전트가 명세의 빈틈을 채우므로, 명세가 통제 표면). 그리고 "트레이드오프를 모른 채 하는 vibe coding"은 명확히 진술된 고장 유형입니다 — 에이전트는 당신이 이해하든 말든 트레이드오프를 하므로, SE 지식이 그것을 *보고 조종*하게 합니다 — `architecture-is-accepted-failure`, 볼 수 없는 고장을 알고 받아들일 수는 없으니까요. **그래서 지도의 정직한 압축이 지도보다 값집니다.** 네 기술 중 셋 — 평가·검증기·트레이드오프 문해력 — 은 한 메타 기술입니다: 비결정적 과정을 감사·통치 가능하게 만들기. 넷째, 빌드 형성은 제작 자체가 자동화된 뒤 인간 판단이 옮겨가는 자리입니다. 이것은 이 목록의 최근 클러스터 전체와 같은 결론입니다 — 검토·검증 가능한 *틀*이 단위이지 산출물이 아니다. 지도는 우선순위를 돕고, 압축은 당신이 실제로 배우는 것을 말합니다: 네 가지가 아니라, 비결정성을 두르는 법과 명세를 소유하는 법. 관련: `the-interface-premium-collapses`, `agent-ask-not-write`, `a-boolean-hides-a-state-machine`, `demonstration-is-not-a-specification`, `architecture-is-accepted-failure`, `simulate-before-sign`.

동작 방식: ### 지도 ``` AI Engineering ├─ AI 앱 빌드·배포 ├─ 소프트웨어 엔지니어링 기본기 ├─ 코딩 에이전트 사용 └─ 빌드 형성 ``` 뿌리 하나, 자식 넷 — 그리고 아래 독법은 자식 넷 중 셋이 같은 축(비결정성)에 매달려 있고, 넷째는 인간 판단이 옮겨가는 자리라는 것. ### 네 기술, 그리고 각각이 두르는 비결정성 | Ng 의 기술 | 무엇을 두르나 | | --- | --- | | AI 앱 빌드·배포 | 모델 출력 — 평가/오류분석이 예측 가능하게 | | SW 엔지니어링 기본기 | 트레이드오프 — 에이전트에 조종당하지 않고 조종 | | 코딩 에이전트 사용 | 에이전트의 한계 — 검증기가 안전히 루프를 닫게 | | 빌드 형성 | *무엇을* 만들지 — 구현이 싸진 뒤의 명세 | ### 넷 중 셋은 한 메타 기술 | 기술 | 결정적 틀 | 구체적 산출물 | | --- | --- | --- | | 평가 / 오류 분석 | 출력을 재고 조종 | 평가 세트 | | 트레이드오프 문해력 | 내려지는 선택을 봄 | 한 장짜리 트레이드오프 문서 | | 검증기 | 에이전트가 자가 점검 | 검증기 스크립트 | | **빌드 형성** | **인간 판단이 옮겨가는 자리** | **명세** | ### 그 아래의 이동 | 에이전트가 싸게 만드는 것 | 가치가 옮겨가는 곳 | | --- | --- | | 구현 작성 | 들어가는 명세 | | 산출물 생산 | 나오는 것을 판정하는 평가/검증기 | | "어떻게 만들지" | "무엇을 만들지, 그리고 어떻게 확인할지" | ### 관련 카드 `the-interface-premium-collapses`(에이전트가 빌드를 범용화; 가치는 소환 못 하는 것), `agent-ask-not-write`(비결정적 에이전트 둘레의 결정적 틀), `a-boolean-hides-a-state-machine`(한 번 잘 됐다고 증명 아님), `demonstration-is-not-a-specification`·`three-thousand-lanterns-nobody-asked-for`(명세가 통제 표면), `architecture-is-accepted-failure`(볼 수 없는 트레이드오프는 받아들일 수 없음), `simulate-before-sign`(제작 + 검증).