그들은 5 레이어를 사용합니다. 나는 2 레이어를 사용합니다. 내가 제로 코드를 쓰는 이유는 이렇습니다.
Source: Dev.to
지난 주에 @rohit4verse가 2026년에 100× 엔지니어와 “vibe coders”를 구분하는 내용에 대한 스레드를 올렸습니다. 그의 핵심 주장은 명확합니다: 중요한 것은 ownership – 실행하기 전에 계획하고, 모든 것을 검증하며, 지속적인 컨텍스트를 구축하고, AI 출력 결과를 무조건 신뢰하지 않는 것입니다. 전적으로 동의합니다.
나의 관점 – 자동차 ECU 개발에서
전혀 다른 분야인 자동차 엔진‑제어 시스템 설계에서 같은 결론에 도달했습니다. 저는 15 년 동안 오토바이 ECU(트랙션 컨트롤, 퀵‑시프트 시스템, 스로틀 컨트롤)를 개발해 왔습니다 — “빠르게 움직이고 부수라”는 것이 실제로 라이더에게 부상을 초래할 수 있는 영역이죠. Agile? 들어본 적은 있지만, 그 단어는 우리 개발 프로세스에 한 번도 등장하지 않았습니다.
그 다른 출발점이 저를 극도로 단순한 스택으로 이끌었습니다.
Rohit’s “2026 Top Workflow” (5‑Layer Stack)
| Layer | Role | Tool(s) |
|---|---|---|
| AI‑first IDE | 인라인 코드 편집 | Cursor, Windsurf |
| Terminal coding agent | 코드 생성, 빌드, 디버깅 | Claude Code, Gemini CLI |
| Background agents | 병렬 PR 처리, 대규모 코드베이스 지원 | Codex, Jules, Devin |
| Chat models | 대화형 지원 | Claude, ChatGPT, Gemini |
| AI code‑review tools | 자동 리뷰, 제안 | Codium, Copilot Workspace |
코드를 작성하는 엔지니어에게는 다섯 레이어 모두 의미가 있습니다. 강력한 설정이죠.
내 스택 (2‑계층 스택)
| 계층 | 역할 | 도구 |
|---|---|---|
| Design AI | 명세, 아키텍처, 인수인계 문서 | Claude.ai / ChatGPT / Gemini |
| Implementation AI | 코드 작성, 빌드, 디버깅 | Claude Code (terminal) |
인간은 검증 게이트 역할을 하며 두 AI 사이에 위치해 모든 인수인계를 검토하고 결과를 확인합니다.
내가 다른 세 계층을 필요로 하지 않는 이유
- AI‑first IDE – 나는 코드를 인라인으로 편집하지 않는다. Design AI는 구조화된 지시 문서를 작성하고, Implementation AI가 이를 실행한다. IDE가 필요 없다.
- Background agents – 대규모 코드베이스에서 병렬 PR 처리를 위해 유용하다. 내 작업 흐름은 순차적이고 신중하며, 각 단계가 다음 단계가 시작되기 전에 검증된다.
- AI code‑review tools – 내 프로토콜은 이미 모든 인수인계 지점에 검증을 포함하고 있다. 인간이 검토 계층이다.
Rohit의 기사에서는 100배 엔지니어링이 “덜 하는 것”에 관한 것이라고 했다. 나는 이를 문자 그대로 받아들여 ‘작업’을 코드 한 줄도 작성하지 않음으로 줄였다.
Failure Modes I’ve Observed
| Failure Mode | Description |
|---|---|
| Context Evaporation | 대화가 길어지거나 세션이 재설정되면, 축적된 설계 결정과 컨텍스트가 조용히 사라집니다. AI는 이전에 내린 아키텍처 선택과 모순되는 제안을 하기 시작하는데, 이는 반항 때문이 아니라 기억 상실 때문입니다. “우리가 이미 결정한 것을 왜 다시 물어보는 거죠?” |
| Shallow Fix Swamp | AI가 근본 원인을 이해하지 못하고 증상만을 임시방편으로 고칩니다. 각 수정이 다음 실패의 전제조건을 만들고, “고쳤는데 이제 다른 것이 고장났어요.” 라는 끝없는 루프가 반복됩니다. |
| Completion Fraud | AI가 실제 검증 없이 자신 있게 “완료되었습니다!” 라고 보고합니다. 고의로 거짓말을 하는 것이 아니라, 현실과 자신의 작업을 검증할 메커니즘이 없기 때문입니다. 이것이 가장 위험한데, 감지하기 가장 어렵기 때문입니다. 독립적으로 확인하지 않으면 진실은 훨씬 뒤에, 이후 변경 사항들의 층 아래에 묻혀 나타납니다. |
Architecture vs. Stage‑Set Analogy
Architecture – 디자이너는 구조 엔지니어와 건설 팀이 따르는 정밀한 설계도를 만든다. 설계가 잘못되면 건물이 무너지고 사람들에게 피해가 발생한다. 명확한 흐름이 있다: specification → verification → accountability.
Stage sets – 제작자는 관객 입장에서 설득력 있게 보이기만 하면 된다. 구조적 요구사항은 최소이며, 문제가 생기면 다음 공연 전에 다시 만든다. 속도와 시각적 임팩트가 내구성보다 중요하다.
나는 웹 개발 세계 대부분이 stage‑set model에 더 가깝게 진화했다고 본다 – 이는 비판이 아니다. 이는 합리적인 최적화이다: 1초 지연이 안전 위험이 아니라 사용자 경험상의 불편일 때, build‑measure‑learn 사이클이 완벽히 맞으며, 이를 통해 놀라운 혁신이 이루어졌다.
AI가 방정식을 바꾸는 이유
AI가 몇 분 안에 수천 줄의 코드를 생성할 수 있게 되면 코드 작성 비용은 거의 제로에 가깝게 됩니다. 그러나 잘못된 코드의 비용은 그대로이거나 더 악화됩니다. 왜냐하면 대량의 코드 속에서 오류를 찾기가 더 어려워지기 때문입니다. 갑자기 가장 중요한 역량은 작성 속도가 아니라 명세 정확성과 검증 규율이 됩니다.
이러한 역량은 안전‑중요 산업이 수십 년에 걸쳐 다듬어 온 바로 그 기술입니다. AI는 이 “느리고 구식” 접근 방식을 스타트업의 속도로 구현하게 해 주는 강력한 날개가 됩니다.
다음에 다룰 내용
다음 기사에서 이 주제를 더 깊이 파고들겠습니다 – 자동차 V‑model development가 AI‑지원 워크플로와 어떻게 직접 연결되는지. 기대해 주세요.
Rohit의 스레드는 100× 엔지니어가 항상 “덜 하는 것”에 관한 것이었으며, AI는 그 “덜함”을 더욱 강력하게 만들고 있다고 결론짓습니다.
보너스 기사: 두‑계층 AI 프로토콜
올바른 시스템을 구축하면 더 작아집니다.
나는 이를 더 나아가서 말하고 싶다: 궁극적인 **“덜”**은 코드를 전혀 작성하지 않는 것이다.
플랫폼 의미의 “노코드”가 아니다. 내가 말하는 것은: 사양을 소유하고, 검증을 소유하고, 아키텍처를 소유한다 — 그리고 모든 구현을 구조화된 인수 문서를 통해 AI에 위임한다, 마치 건축가가 설계도를 통해 건설을 위임하는 방식처럼.
이것이 내가 ExitWatcher를 만든 방법이다 — Android 경험이 전혀 없는데도 4일 만에 만든 Android 앱. Kotlin을 배우는 것이 아니라, 정확한 사양을 작성하고 모든 결과물을 검증함으로써 가능했다.
이를 가능하게 하는 프로토콜 — 두‑계층 AI 프로토콜 — 이 바로 이 기사 시리즈의 주제다. 안전‑중요 엔지니어링 원칙이 AI 코딩을 얼마나 크게 신뢰할 수 있게 만드는지에 관심이 있다면, 심층 분석이 곧 공개될 것이다.
전체 시리즈 읽기
- Article 1: 4일 만에 Android 앱을 경험 없이 만들었습니다
- Article 2: 프로토콜은 잔해에서 탄생했다