요즘IT 원문 학습 문서 · 2026-07-16
‘무엇’과 ‘어떻게’를 넘어, AI가 운영 가능한 결과를 가려내게 만드는 ‘왜’의 역할을 빠르게 배우고 검증합니다.
학습 가이드
AI의 탐색 능력을 규칙으로 질식시키지 않으면서, 데모만 그럴듯한 ‘에이전트 시어터’를 운영에서 견디는 시스템으로 바꾸려면 어떤 ‘왜’와 검증 기준을 컨텍스트에 넣어야 하는가?
멘탈 모델
AI는 주어진 맥락에서 후보를 고속으로 생성한다. what/how는 결과의 모양을, why는 후보를 버릴 기준을 정하며 운영 검증은 그 기준이 실제 실행 경로에서도 통하는지 확인한다.
가이드와 Executive Summary로 주장과 적용 기준 파악
실패 사례, git worktree·ADR 사례, CHP의 한계까지 확인
Executive Summary
이 글의 중심 주장은 명세인 무엇(what)과 구현법인 어떻게(how)만으로는 AI가 빠르고 그럴듯한 껍데기를 대량 생산하기 쉽고, 실제 운영 조건에서 무엇이 성공이고 실패인지 설명하는 왜(why)가 있어야 스스로 결과를 분별할 수 있다는 것이다. 아래 내용은 저자의 현장 경험, 비유, 일반화, 외부 전망을 서로 구분해 원문의 모든 주요 논지를 재배치한 것이다.
C
종합 신뢰도 C. 가트너 전망과 신뢰성 설계 조언은 대체로 정확하지만, 환각과 창의성을 동일한 메커니즘으로 보고 ‘왜’를 유일한 우회로로 제시하는 핵심 인과는 통제된 근거가 부족하거나 공개 연구와 배치된다.
핵심 질문
AI가 낸 결과를 더 많이 통제할 것이 아니라, 그 결과가 실제로 작동하는지 AI 스스로 가려내게 하려면 무엇을 제공해야 하는가?
저자의 답
출력 규칙을 더 쌓는 대신, 도메인의 목적·실패 비용·금지선·성공 기준을 설명하는 ‘왜’를 추론 시점의 맥락으로 제공해야 한다.
결정 경계
창의성과 원칙의 비율은 고정값이 아니다. 실패가 눈에 잘 보이고 롤백이 싼 영역과 신뢰성·규격 준수가 생명인 영역은 서로 다른 설정이 필요하다.
출발점
반전과 정의
따라서 이 글은 AI의 속도 자체를 부정하지 않는다. 속도는 진짜였지만 그것만으로 엔지니어링이 되지는 않았다는 현장 기록이며, 제품 제작자와 “AI를 도입하면 생산성이 오른다”는 전제 아래 의사결정해야 하는 사람을 대상으로 한다.
첫 번째 작업 사진은 맥북에 터미널 4~5개, 맥 미니에 약 2개를 띄워 병렬로 일하는 저자의 클로드 작업 환경을 보여준다. 이는 작업량과 방식의 맥락을 제시하는 사례 사진이지, 품질 주장을 독립적으로 입증하는 자료는 아니다.
※ 오해 차단 — 글의 비판 대상은 “AI가 빠르다”는 명제가 아니라, 빠르게 만들어진 구조와 데모를 운영 가능한 제품으로 간주하는 판단이다.
외부 전망을 끌어온 대목
저자는 가트너가 2025년에 “2027년 말까지 기업 에이전트 AI 프로젝트의 40% 이상이 폐기될 것”이라고 전망했고, 이유로 비용 증가·불분명한 비즈니스 가치·부족한 위험 통제를 들었다고 소개한다.
agent washing과의 연결
같은 발표에서 실질적 자율 기능이 없는 챗봇이나 자동화 도구를 ‘에이전트’로 재포장하는 관행을 ‘agent washing’이라 불렀다고 설명한다. 저자는 이를 자신의 ‘에이전트 시어터’와 같은 현상, 즉 그럴듯한 외형과 빈 내부로 본다.
저자의 귀인
실패 원인을 모델의 무능보다 AI를 배치하는 사람의 잘못된 결정에 둔다. 자신의 무대 세트 역시 AI 자체의 실패가 아니라, 자신이 AI에게 결정에 필요한 무언가를 빼먹은 결과였다고 해석한다.
What
무엇을 만들 것인가. 기능과 명세를 지정한다.
How
어떤 패턴·규칙·방법으로 만들 것인가. 구현의 외형과 절차를 지정한다.
Why
왜 부분 실패를 견뎌야 하고, 왜 중단 뒤 재개돼야 하며, 왜 특정 지점에서 과부하를 차단해야 하는가. 완성도를 겉모습이 아니라 실제 결과로 판정하게 한다.
이 사례의 결론은 맥락 한 줄과 누적된 결정 기록이 없으면 AI는 코드만 내놓지만, 둘이 있으면 개발자의 작업 구조를 재설계하고 과거 판단까지 참조하는 조력자가 될 수 있다는 것이다.
개입
추가 규칙 대신 ‘왜’를 설명하는 철학 문서를 만들어 작업 컨텍스트에 늘 연결했다. 형식은 규칙 파일과 닮았지만 코딩 컨벤션이나 코드는 없고, “이 영역에서 작동한다는 뜻은 무엇인가”, “절대로 해서는 안 될 것은 무엇인가” 같은 판단 기준만 담았다.
통제된 조건이라고 제시한 것
같은 모델·코드베이스·개발자를 유지했고 파인튜닝, 모델 업그레이드, 가중치 변경은 없었다. 달라진 것은 추론 시점(inference time)에 참조하는 컨텍스트뿐인데 결과물 품질이 달라졌다고 저자는 보고한다.
‘소프트 파인튜닝’이라는 비유
학습 파이프라인 없이 곧바로 적용되고, 컨텍스트를 빼면 효과도 사라지며, 영역마다 다른 문서를 끼울 수 있다는 점에서 일종의 소프트 파인튜닝으로 부른다.
✗ 규칙: “헛소리하지 마”라며 가능한 출력을 줄인다. ○ ‘왜’: “네 결과가 진짜인지 이 기준으로 판단하라”며 분별 기준을 준다.
Creative
개발자가 예상하지 못한 구조나 해법을 제안하는 힘.
Hallucination
그럴듯해 보이지만 실제로는 작동하지 않는 결과를 만드는 성향.
Principles
규칙과 가이드로 출력 범위를 묶는 제약. 저자는 세 힘의 머리글자를 따 CHP라 부른다.
창의성 쪽
프론트엔드·UX처럼 시각적 혁신이 중요하고 실패가 즉시 보이며 롤백 비용이 싼 영역은 창의성을 크게 허용한다.
원칙 쪽
메시지 브로커·데이터 파이프라인·인프라처럼 신뢰성이 핵심인 영역은 원칙을 강하게 적용한다. 메시지 브로커의 창의성은 장애가 되고, 통신 프로토콜에서는 규격 위반이 된다는 설명이다.
가장 어려운 중간
에이전트는 자율적으로 판단하면서도 엄격한 운영 경계를 넘어서는 안 되므로 가장 까다로운 중간 영역에 속한다.
저자에게 1인 AI 개발의 실제 병목은 코딩이나 시스템 설계 자체가 아니라 이 다이얼을 여러 영역에서 계속 다시 맞추는 판단 노동이었다. 아침에는 프론트엔드에 “더 과감하게”, 점심에는 프로토콜 핸들러에 “한 바이트도 규격을 벗어나지 마”, 오후에는 에이전트에 “창의적으로 풀되 안전 경계는 넘지 마”라고 서로 다른 기준을 적용해야 했다.
이 노동은 AI가 유능해질수록 줄지 않고 오히려 늘 수 있다는 역설도 제시한다. 더 똑똑한 AI가 더 많은 그럴듯한 선택지를 내놓으면 사람이 그것을 가려내는 데 더 섬세한 판단이 필요하기 때문이다. 세 번째 사진은 클로드 코워크로 QA 테스트 에이전트를 만들어 테스트를 자동화한 사례다.
개인 경험으로 제시된 항목
200만 줄, 수십 개 서비스, 여러 에이전트·앱, 5분 미만 자율 실행, 운영 검증 통과 0건, 컨텍스트 변경 뒤 품질 향상, git worktree·ADR 활용 효과는 모두 저자의 자기보고다.
외부 검증 가능한 항목
가트너의 2025년 발표, 2027년 말까지 40% 이상 폐기 전망, 비용·가치·위험 통제라는 원인, ‘agent washing’ 용례는 외부 원문과 대조할 수 있는 주장이다.
저자의 이론·일반화
환각과 창의성이 같은 생성 뿌리라는 설명, 규칙의 대칭성, ‘왜’가 유일한 우회로라는 표현, 바이브 코딩 제품 다수의 취약성, 더 유능한 AI가 판단 노동을 늘린다는 주장은 글의 해석 모델이다.
글은 동일 모델·코드베이스·개발자라는 비교 조건을 말하지만, 품질 지표·표본·대조군·재현 절차는 제시하지 않는다. 따라서 ‘왜’의 효과는 보편 법칙으로 확정된 결론이라기보다 저자의 실무 가설과 경험적 방법론으로 읽어야 한다. 동시에 저자 스스로도 단일 처방을 부정한다. 실패의 가시성, 롤백 비용, 신뢰성, 규격 준수, 자율성 요구에 따라 적용 강도를 다시 조절해야 한다.
구조 범례: ◆ 긴장·트레이드오프 · ※ 오해 차단 · ✗/○ 실패 경로와 대안. 원문의 주장·사례·수치·조건·반대급부를 삭제하지 않고 논리 관계에 따라 재배치했다.
가트너의 취소 전망·에이전트 워싱 정의와 재시도·멱등성 같은 분산 시스템 조언은 정확하다. 그러나 글의 중심축인 “환각과 창의성은 같은 메커니즘이고 규칙은 둘을 대칭적으로 억제하며, ‘왜’라는 맥락만이 이를 풀 수 있다”는 인과 사슬은 직접 검증되지 않았고 일부는 공개 연구와 배치된다. 200만 줄, 수십 개 에이전트, 전부 운영 실패 같은 수치는 개인 경험담으로서 독립 검증 자료가 없다.
정합성 한줄평: 경험담의 문제 → 원인 → 처방 흐름은 선명하지만, “환각=창의성”에서 “‘왜’만 주면 둘을 분리할 수 있다”로 넘어가는 핵심 인과 점프에는 통제 실험이 없다.
판정 기준: 2026년 7월 16일 현재 공개된 1차 자료와 연구를 기준으로, 예측은 예측으로, 개인 경험과 규범적 조언은 검증 불가능한 의견으로 분리했다.
개인 경험 고지: 저자가 직접 겪었다고 쓴 코드량·개발 속도·에이전트 실패·Claude Code 대화 결과는 “저자 보고”로만 확인된다. 아래 판정은 이를 독립 검증된 사실과 명시적으로 구분한다.
주장: 저자는 25년 경력의 아키텍트·CTO이며, 몇 달 동안 AI와 200만 줄이 넘는 코드를 작성했고 수십 개의 서비스·에이전트·앱을 만들었지만 모든 에이전트가 운영에서 실패해 5분도 버티지 못했다.
원문에 제시된 자기 보고다. 저장소, 언어별 코드 산정 기준, 실행 로그, 실패 판정 기준, 서비스 목록이 공개되지 않아 경력·코드량·전패 기록을 독립적으로 확인할 수 없다. 거짓이라는 뜻이 아니라 검증 가능한 근거가 없다는 판정이다.
출처: 요즘IT 평가 대상 원문
주장: AI가 개발 속도를 실제로 크게 높이며, 몇 시간 만에 서비스를 만들고 밤사이 API를 추가할 수 있다.
AI 코딩 도구의 생산성 향상은 관찰되지만 효과가 보편적이거나 늘 큰 것은 아니다. 23개 연구 메타분석은 중간 정도의 긍정 효과(Hedges' g=0.33)를 보고하면서도 환경별 이질성이 크고 오픈소스·기업 환경에서는 효과가 작다고 밝혔다. 반대로 익숙한 대형 오픈소스 저장소의 숙련 개발자 16명을 대상으로 한 2025년 무작위 실험에서는 AI 사용군이 19% 느렸다. 원문의 구체적 “몇 시간·밤사이” 성과는 공개 작업 기록이 없어 독립 검증할 수 없다.
근거: 2026 생산성 메타분석, METR 무작위 실험, 요즘IT 원문
주장: AI가 만든 코드는 겉보기에는 그럴듯하고 컴파일도 되지만 실제 기능·보안·운영 조건에서는 실패할 수 있다.
실재하는 위험이다. 코드 LLM의 존재하지 않는 패키지 생성과 코드 에이전트의 저장소 단위 성능 저하는 대규모 평가에서 관찰됐다. 다만 이 연구들은 모든 AI 코드가 겉모습만 맞거나 운영에서 실패한다는 뜻은 아니며, 모델·과제·도구·검증 절차에 따라 성공률이 크게 달라진다.
주장: 바이브 코딩으로 만든 제품은 대부분 데모에서는 작동해도 운영에 들어가면 실패하거나 버그가 난다.
“대부분”을 판정하려면 바이브 코딩 제품 모집단, 실패·버그의 정의, 운영 기간과 비교군이 필요하지만 글에는 없다. 저장소 벤치마크는 에이전트의 한계를 보여줄 뿐 실제 제품 전체의 실패율을 추정하는 대표 표본이 아니다.
주장: 가트너는 2027년 말까지 에이전틱 AI 프로젝트의 40% 이상이 비용 상승, 불명확한 비즈니스 가치, 불충분한 위험 통제 때문에 취소될 것으로 전망했다.
수치, 시점, 세 가지 이유가 가트너의 2025년 6월 25일 공식 발표와 일치한다. 단, 이는 당시 진행 중인 프로젝트의 관측된 실패율이 아니라 향후 취소에 관한 전망이다.
근거: Gartner 공식 발표
주장: 가트너는 기존 AI 비서·RPA·챗봇을 실질적 에이전틱 기능 없이 재포장하는 현상을 “에이전트 워싱”이라고 불렀다.
가트너 공식 발표의 정의에 부합한다. 발표는 많은 공급업체가 기존 제품을 에이전트로 재브랜딩한다고 지적하고, 실질적 에이전틱 기능이 없는 경우를 “agent washing”이라고 설명한다.
근거: Gartner 공식 발표
주장: 글에서 말하는 “에이전트 시어터”는 가트너의 “에이전트 워싱”과 같은 현상이다.
둘 다 겉모습만 에이전트처럼 보인다는 비판을 공유한다. 그러나 가트너의 용어는 주로 공급업체의 마케팅·재브랜딩을 가리키고, 글의 “에이전트 시어터”는 실제 구현물이 장기 운영·자율 의사결정에 실패하는 상태까지 포함한다. 관련은 있지만 동일한 정의는 아니다.
근거: Gartner 공식 정의, 요즘IT 원문
주장: 가트너가 말한 실패의 핵심은 모델의 능력 부족이 아니라 인간이 나쁜 결정을 내린다는 점이다.
가트너 발표를 그렇게 단정할 수 없다. 발표는 비용·가치·위험 통제와 과대광고를 지적하는 동시에, 현재 모델이 복잡한 목표를 달성하거나 미묘한 지시를 따를 성숙도와 행위성을 갖추지 못했다고 명시한다. 인간의 판단만으로 원인을 환원한 원문의 해석은 출처와 충돌한다.
근거: Gartner 공식 발표
주장: AI에게 “무엇”과 “어떻게”만 주고 “왜”를 주지 않으면, 겉보기만 맞고 실제로는 작동하지 않는 코드를 만들게 된다.
설계 의도와 제약의 이유가 예외 처리·상충 요구사항 판단에 도움을 줄 가능성은 크지만, 원문은 “왜”의 유무만 통제한 재현 실험을 제시하지 않는다. 실제 저장소의 에이전트 컨텍스트 파일을 평가한 2026년 연구에서도 지침은 잘 따랐지만 성공률은 전반적으로 유의하게 개선되지 않았고 추론 비용은 평균 20% 넘게 늘었다. 이 결과가 “왜” 문서만을 따로 시험한 것은 아니므로 주장을 거짓으로 확정할 수도, 보편 법칙으로 확인할 수도 없다.
근거: AGENTS.md 평가 연구, 요즘IT 원문
주장: 분산 시스템에서 재시도는 부분 실패와 중복 실행을 만들 수 있으므로, 결제 같은 부작용이 있는 작업은 멱등성·의도 식별·중복 방지가 필요하다.
확립된 신뢰성 설계 원칙이다. AWS는 네트워크 실패 뒤 재시도가 중복 자원 생성 같은 부작용을 낳을 수 있어 멱등 API와 호출자 의도 식별이 필요하다고 설명하고, Azure도 일시적 장애의 재시도에는 멱등성과 회로 차단·백오프를 함께 고려하라고 권고한다.
주장: 컴파일·정적 검사·코드 리뷰를 통과했다는 사실만으로 분산 시스템의 실제 운영 신뢰성을 보장할 수 없고, 장애·부하·동시성·복구 경로를 따로 검증해야 한다.
확립된 운영 원칙이다. Google SRE는 단위·통합 시험과 별개로 설정, 용량, 의존 서비스 장애, 복구 절차를 다루는 생산 환경 시험이 필요하다고 설명한다. Azure 지침도 재시도 정책을 높은 부하와 동시 요청에서 시험하고, 백오프·회로 차단·관찰 가능성을 함께 설계하라고 권고한다. 다만 원문의 개별 서비스가 실제로 모든 검사를 통과했다는 부분은 저자 보고라 별도 검증되지 않는다.
주장: Git worktree가 병렬 작업의 충돌을 줄이고, Git 커밋 기록이 ADR처럼 AI에게 과거 판단의 맥락을 제공해 같은 문제를 반복하지 않게 한다.
worktree가 한 저장소에서 여러 브랜치를 동시에 체크아웃하게 한다는 설명은 정확하다. 좋은 커밋 메시지가 판단 이력을 보존할 수도 있다. 다만 ADR은 선택지·요구사항·결정 이유를 의도적으로 기록하는 문서라서 일반 커밋 로그와 자동으로 같아지지 않으며, Claude가 해당 이력 때문에 해법을 찾아냈다는 개인 사례는 재현 자료가 없다.
주장: 환각과 창의성은 “정확히 같은 생성 메커니즘”에서 나오며, 둘은 사실상 같은 현상의 두 이름이다.
그렇게 확립된 과학적 결론은 없다. OpenAI의 환각 연구 해설은 다음 토큰 예측, 데이터의 불완전성, 모르는 문제에서도 추측을 보상하는 평가 구조 등을 원인으로 든다. 환각과 창의성을 하나의 동일한 메커니즘으로 정의하지 않는다. 또한 완화법마다 창의성에 미치는 방향이 다르다는 실험 결과는 두 현상을 동일시한 명제의 예측과 맞지 않는다.
주장: 규칙·금지 목록·더 엄격한 프롬프트는 환각과 창의성을 대칭적으로 억제하며, 환각만 선택적으로 줄이는 것은 불가능하다.
“어떤 규칙이든 항상 대칭 억제한다”는 보편 명제는 실험 결과와 충돌한다. CoVe는 환각을 줄이면서 발산적 창의성을 높였고, RAG는 창의성 영향이 작았으며, DoLa는 창의성을 낮췄다. 코드 패키지 환각 연구도 코드 품질을 유지하면서 환각을 유의하게 줄이는 완화법을 보고했다. 개입 종류에 따라 결과가 달라 선택적 개선은 가능하다.
주장: 모델과 가중치를 바꾸지 않고 자연어로 “왜”라는 맥락을 추가했더니 코드 품질이 완전히 달라졌다.
텍스트 지시·예시가 가중치 업데이트 없이 모델 행동을 바꾸는 인컨텍스트 러닝은 잘 알려진 현상이다. 따라서 같은 모델도 맥락에 따라 다른 출력을 낼 수 있다는 일반 원리는 사실이다. 다만 저자의 품질 변화는 동일 과제·무작위성·평가자·성공 지표를 통제한 실험이 아니므로, 변화의 크기와 원인이 오직 “왜”였는지는 확인할 수 없다.
주장: 자연어 “왜” 문서를 모델에 제공하는 것은 모델을 다시 학습하지 않는 “소프트 파인튜닝”이다.
행동을 맥락으로 조정한다는 비유로는 이해할 수 있지만 기술 용어로는 부정확하다. soft prompt tuning은 역전파로 학습되는 연속 임베딩 파라미터를 입력 앞에 붙이는 방법이다. 사람이 작성한 자연어 문서를 컨텍스트에 넣는 것은 보통 인컨텍스트 러닝 또는 프롬프팅이며, 학습되는 프롬프트 파라미터가 없다.
근거: Prompt Tuning 연구, GPT-3 연구
주장: 필요한 것은 더 좋은 모델이 아니라 더 좋은 맥락이며, 충분한 “왜”가 모델 개선을 대신한다.
좋은 예시와 관련 맥락이 성능을 높일 수 있다는 부분은 사실이다. 그러나 인컨텍스트 러닝은 엄선한 예시를 써도 instruction fine-tuning보다 낮은 성능을 보일 수 있고, 긴 컨텍스트에서는 관련 정보의 위치에 따라 무문서 기준보다 성능이 낮아지기도 한다. 맥락과 모델 능력은 대체재가 아니라 함께 작용하는 요인이다.
주장: “왜”라는 맥락은 환각을 줄이면서 창의성은 보존하는 선택적 제어 장치다.
직접 검증한 통제 연구가 제시되지 않았다. Chain-of-Verification처럼 초안에서 검증 질문을 만들고 독립 답변 뒤 수정하는 구조화된 절차는 환각을 줄였고, 별도 연구에서는 CoVe가 발산적 창의성을 높였다. 그러나 이는 단순히 설계 이유 문서를 추가하는 개입과 같지 않다. “왜”만의 선택적 효과는 가능성일 뿐 입증된 사실이 아니다.
주장: “왜”를 알면 AI가 스스로 결과를 평가해 환각을 걸러낸다.
모델에게 명시적인 검증 질문과 독립 답변 단계를 주면 오류를 줄일 수 있다는 근거는 있다. 그러나 외부 피드백 없이 “스스로 고쳐라”라고 하는 내재적 자기수정은 오류를 고치지 못하거나 오히려 성능을 낮추기도 했다. 설계 이유를 제공하는 것만으로 신뢰할 만한 자기평가가 자동 발생한다는 일반화는 과도하다.
주장: 혼자 운영하는 시스템은 팀이 운영하는 시스템보다 반드시 더 엄격해야 하고, 프런트엔드에서는 AI 창의성을 풀어주되 브로커·프로토콜·인프라에서는 엄격히 막아야 한다.
위험이 큰 부작용 경로에 멱등성·회로 차단·롤백 같은 강한 통제를 두자는 조언은 건전한 실무 휴리스틱이다. 하지만 필요한 통제 수준은 인원수나 기술 계층 이름보다 손실 규모, 복구 가능성, 규제, 관찰 가능성에 좌우된다. “혼자라서 반드시 더 엄격”하거나 “프런트엔드는 자유”라는 부분은 보편적으로 검증 가능한 사실이 아니라 저자의 규범적 설계 의견이다.
주장: 일관성·환각 억제·성능과 창의성을 동시에 얻을 수 없다는 “CHP 제약”이 존재하며, “왜”가 유일한 허점이다.
저자가 만든 개념을 증명된 제약처럼 제시했지만 정식 정의·측정법·증명이 없다. 더구나 환각을 줄이면서 창의성을 높인 CoVe, 창의성 변화가 거의 없었던 RAG, 코드 품질을 유지한 패키지 환각 완화 등 “왜” 문서 이외의 반례가 있다. 모든 세부 지표를 한 번에 최적화할 수 있다는 뜻은 아니지만, “왜만이 유일한 허점”이라는 배타적 명제는 성립하지 않는다.
주장: AI가 더 똑똑해질수록 인간이 해야 할 판단 노동은 반드시 늘어난다.
특정 고위험 업무에서는 검토·책임·예외 판단이 늘 수 있지만, 모델 능력과 인간 판단 노동 사이의 필연적 단조 증가를 직접 측정한 근거는 원문에 없다. Google 엔지니어 무작위 실험은 AI 사용 시 복잡한 작업 시간이 약 21% 단축됐고, 3개 기업 4,867명 개발자를 합친 현장 실험은 완료 과제가 26.08% 증가했다고 보고했다. 다만 두 연구 모두 “판단 노동”을 별도 지표로 직접 측정하지 않았으므로 이 주장을 반증하지도 않는다. 현재로서는 설득력 있는 실무 가설이지 확립된 법칙은 아니다.
주장: AI는 주어진 맥락을 그대로 비추는 거울이며, 맥락의 모순·모호함을 증폭한다.
모델 출력이 지시·예시·관련 정보의 내용과 위치에 민감하다는 점은 실증됐다. 모순되거나 나쁜 맥락이 성능을 해칠 수 있다는 실무적 비유도 유용하다. 그러나 AI가 맥락을 “그대로” 반영하거나 언제나 모호함을 증폭한다는 것은 측정 가능한 보편 법칙이 아니다. 모델의 사전학습, 추론 방식, 정보 위치가 함께 결과를 결정한다.
원본 · 한국어 의미 보존 재구성
저는 소프트웨어 아키텍트로 25년을 일했고, 현재는 한 스타트업의 CTO를 맡고 있습니다. 최근 몇 달 동안에는 AI와 둘이서 200만 줄이 넘는 코드를 작성했습니다. 그사이 수십 개 서비스와 여러 AI 에이전트, 여러 모바일 앱을 만들었고, 서비스 하나가 불과 몇 시간 만에 올라가거나 API가 하룻밤 사이 완성되기도 했습니다. 코드 리뷰에서 본 구조는 제법 탄탄했고 모든 점검도 통과했으니, 누구라도 “이제 출시해도 되겠다”고 생각할 모습이었습니다.
하지만 실제로 실행해 보니 결과물은 5분조차 자율적으로 돌아가지 못했습니다. 제가 말하는 ‘작동’은 데모가 한 번 성공하는 상태가 아닙니다. 사람이 계속 지켜보지 않아도 예외, 재시도, 동시 요청을 견디면서 의도한 일을 끝까지 수행하고 매번 같은 결과를 내야 합니다. 이것이 진짜 작동입니다. 반대로 ‘껍데기’는 시연할 때는 흠잡을 데 없어 보여도 전제 조건이 조금만 달라지면 주저앉는 결과물입니다.
AI가 보여준 속도는 분명 진짜였습니다. 그러나 그것을 곧바로 엔지니어링이라고 부를 수는 없었습니다. 이 글은 AI로 서둘러 만든 결과가 왜 빈 껍질이 되는지, 그리고 그 껍질을 실제 제품으로 바꾸려면 AI에 무엇을 다르게 제공해야 하는지를 기록한 현장 보고입니다. 제품을 만드는 사람뿐 아니라 “AI를 도입하면 생산성이 높아진다”는 말을 바탕으로 결정을 내려야 하는 사람을 위해 썼습니다.
미리 요점만 콕 집어보면?
처음 몇 달 동안 저는 AI를 그저 ‘코딩 기계’처럼 다뤘습니다. 만들 대상인 명세와 구현 방법인 패턴·규칙을 건네면 AI는 놀라운 속도로 코드를 생산했습니다. 생산성 수치만 놓고 보면 꿈같은 결과였지만, 정작 그 지표가 사실을 감추고 있었습니다.
어느 날 지금까지 만든 AI 에이전트를 하나씩 다시 살펴봤습니다. 결과는 충격적이었습니다. 운영 검증을 통과한 에이전트가 단 하나도 없었습니다. 겉 인터페이스는 정상인데 내부가 비어 있다는 공통 증상이 있었습니다. 쓰기 측(write-side)은 wiring이 끝난 듯 보였지만 읽기 측(read-side)은 멈춰 있었습니다.
이벤트를 발행해도 이를 구독해 처리할 핸들러는 한 번도 작동하지 않았고, 상태 머신에는 어떤 입력으로도 도달할 수 없는 전이(transition)가 들어 있었습니다. 컴파일은 되고 구조 역시 그럴듯한데 런타임에서는 아무 일도 벌어지지 않는 코드였습니다. 제 플랫폼은 비동기 분산 시스템을 핵심으로 삼고 있어 이런 결함이 더욱 두드러졌습니다.
집으로 비유하면 스위치는 모두 설치했지만 어느 스위치에도 전선을 잇지 않은 상태였습니다. 도면상 완공됐고 준공 검사도 지났는데, 스위치를 눌러도 불 하나 켜지지 않는 집입니다. 저는 이런 것을 ‘에이전트 시어터(agent theater)’라고 부릅니다. 무대 정면에서는 완벽한 건물처럼 보이지만 뒤편은 합판으로 받친 가짜 세트인 셈입니다.
더 눈여겨볼 점은 이것이 제 개인 문제에 그치지 않는다는 사실입니다. 시장 조사기관 가트너(Gartner)는 2025년 발표에서 2027년 말까지 기업의 에이전트 AI 프로젝트 가운데 40% 이상이 폐기될 것으로 내다봤습니다. 비용이 불어나고, 비즈니스 가치가 선명하지 않으며, 위험 통제가 부족하다는 점을 원인으로 제시했습니다. 그 발표에는 ‘agent washing(에이전트 워싱)’이라는 말도 등장합니다. 실제 자율 기능이 없는 기존 챗봇이나 자동화 도구를 ‘에이전트’로 다시 포장하는 행위를 뜻합니다.
제가 현장에서 ‘에이전트 시어터’라고 이름 붙인 현상과 가트너가 시장에서 ‘agent washing’이라 부른 현상은 사실상 같았습니다. 외형은 설득력 있지만 안은 비어 있습니다. 여기서 중요한 점이 있습니다. 가트너가 실패 원인으로 지목한 것은 ‘AI 모델의 무능’이 아니었습니다. AI를 배치하는 사람이 잘못 판단한 결과였습니다. 이는 제 경험과도 정확히 맞아떨어졌습니다. 몇 달 동안 만든 무대 세트는 AI가 실패해서가 아니라, 제가 AI에 꼭 필요한 무엇인가를 주지 않았기 때문에 생겼습니다.
그 빠진 것이 무엇인지 오래 고민했고, 마침내 뜻밖에 간단한 결론에 도달했습니다.
제가 AI에 제공한 것은 두 종류뿐이었습니다. 첫째는 무엇을(what) 만들지, 둘째는 어떻게(how) 만들지였습니다. 이 두 가지만 받으면 AI는 문법상 완벽하고 구조도 제법 설득력 있지만 기능은 비어 있는 코드를 만들어냅니다.
없었던 것은 왜(why)였습니다. 이 기능이 왜 부분 실패를 버텨야 하는지, 처리 도중 끊긴 뒤 왜 다시 시작할 수 있어야 하는지, 이 위치에서 왜 과부하를 차단해야 하는지를 알려주지 않았습니다. 이런 이유가 빠지면 AI는 완성도의 실체가 아니라 완성돼 보이는 겉모습을 목표로 달립니다.
엔지니어라면 익숙한 상황일 겁니다. 신입에게 “결제 화면을 만들어 달라”고만 하면 화면은 나와도 엣지 케이스에서 쉽게 무너집니다. “결제 실패 뒤 재시도하는 흐름이므로, 네트워크가 중간에 끊겨 동일 요청이 두 번 와도 실제 결제는 한 번만 일어나야 한다”는 이유까지 말해야 합니다. 곧 멱등성(idempotency)이 왜 필요한지 이해해야 비로소 진짜 기능이 됩니다. AI도 다르지 않았습니다. 다만 신입보다 백 배 빠른 속도로, 백 배나 많은 그럴듯한 껍데기를 만들 뿐이었습니다.
AI로 코딩해 본 사람이라면 이런 결과를 잘 알 겁니다. 저는 때로 이를 ‘이쁜 장난감’이라고 부릅니다. 요즘 흔히 말하는 바이브 코딩으로 만든 제품도 대개 이 모습을 띱니다. 데모에서는 멀쩡해 보이지만 프로덕션에 내놓으면 제대로 움직이지 않거나 버그가 한꺼번에 터집니다.
설명이 너무 추상적으로 들릴 수 있으니 실제 사례를 하나 들겠습니다. 코딩 AI인 클로드 코드(Claude Code)에 제 작업 환경을 알려주면서 짧은 맥락을 하나 보탰습니다. “나는 팀이 아니라 혼자 일한다”는 한 문장이었습니다.
저는 보통 클로드 코드 터미널 네다섯 개를 열어 병렬로 일합니다. 처음에는 작업 공간을 여러 저장소로 나누는 멀티 레포 구조를 썼습니다. 그런데 어느 날 지나치게 많은 작업을 한꺼번에 벌이다 git이 엉켰습니다. 그래서 클로드 코드에 지난 한 달의 작업 기록과 git 이력을 분석해 제 개발 패턴을 찾아달라고 했습니다. AI가 제 습관을 너무 정확히 찾아내 놀랐습니다.
분석을 마친 클로드 코드는 오히려 제게 한 가지 방식을 제안했습니다. 혼자서도 여러 일을 병렬로 처리하도록 하나의 저장소를 복수의 작업 공간으로 동시에 펼치는 git worktree 구조를 쓰자는 제안이었습니다. ‘1인 솔로 개발’이라는 조건을 명시했기 때문에 가능한 답이었습니다. 그저 “코드를 작성하라”고만 했다면 나오지 않았을, 제 일하는 방식에 맞춘 구조였습니다. 덧붙여, 독자 여러분도 한 달 정도 개발한 다음 AI에 자신의 행동 패턴을 분석시켜 보기를 권합니다. 꽤 놀라운 결과를 볼 수 있을 겁니다.
그 제안 덕분에 여러 터미널을 큰 충돌 없이 함께 띄우고, 화면마다 서로 다른 작업을 나란히 진행할 수 있었습니다. 혼자라는 한계를 병렬 처리로 메운 것입니다. 물론 비용도 치렀습니다. 동시에 실행한 세션들이 동일한 작업 공간을 만져 충돌했고, 하루 동안 한 작업이 엉킨 적도 있습니다. 그 사고 뒤에는 “작업 공간 하나에는 작업 줄기 하나만 둔다”는 규칙을 명시했습니다.
그 다음에 일어난 일은 더 흥미로웠습니다. 혼자 개발할 때는 git이 과한 도구처럼 느껴지곤 합니다. 함께 일할 사람도 없고 되돌릴 일도 적으니 커밋 메시지를 대충 적고 싶어집니다. 그러나 이력을 성실하게 남긴 일이 예상 밖의 보상으로 이어졌습니다. 나중에 클로드 코드가 코드를 수정할 때 git 이력에서 “과거에 이 부분을 왜 이렇게 바꿨는가”를 찾아 읽고, 그 배경에 맞춰 판단하기 시작했습니다. 제 커밋 이력이 ADR(Architecture Decision Record), 즉 설계 결정 기록처럼 기능한 것입니다. 사람에게 코드 리뷰를 받을 수 없는 1인 개발 환경에서 과거의 선택을 담은 커밋은 AI에 또 하나의 ‘왜’를 제공했습니다.
요지는 분명합니다. “혼자 일한다”는 짧은 맥락과 그 배경이 누적된 커밋 이력이 없었다면 AI는 코드만 계속 내놓았을 겁니다. 맥락을 건네자 AI는 제가 일하는 구조를 다시 설계했고, 과거에 내린 판단까지 읽어내기 시작했습니다.
개발 초기에는 가장 상식적으로 보이는 지침부터 적용했습니다. “이 방식으로 하라”, “저렇게 하지 말라”, “이 패턴을 따르라”는 규칙을 계속 보탰습니다.
이 처방은 절반만 맞았습니다. 헛소리는 실제로 줄었습니다. 그러나 예상 밖의 부작용이 생겼습니다. 규칙을 많이 건 영역에서는 AI가 다른 곳에서 매끄럽게 해결하던 문제조차 갑자기 풀지 못했습니다. 규칙이 거의 없는 영역에서는 제가 상상하지 못한 멋진 방법을 내던 바로 그 AI였습니다.
그 이유를 알아차리기까지 시간이 필요했습니다. AI의 ‘환각’과 ‘창의성’은 뿌리가 같습니다. 제가 떠올리지 못한 구조를 제시하는 능력과, 그럴듯한데 실행되지 않는 코드를 쏟아내는 성향은 동일한 생성 메커니즘이 가진 두 얼굴입니다. 그러므로 규칙으로 출력 가능 공간을 줄이면 헛소리의 자리만 닫히는 것이 아니라 좋은 아이디어가 나올 자리도 똑같이 닫힙니다. 규칙은 대칭적으로 작동하므로 한쪽만 골라 억제할 수 없습니다.
결국 규칙으로 만든 것은 헛소리는 하지 않지만 그렇다고 영리하지도 않은, 단지 속도만 빠른 코딩 기계였습니다. 환각을 없애려다가 AI와 협업할 이유까지 함께 없앤 셈입니다.
돌파구는 뜻밖의 방향에서 나타났습니다. 규칙을 더 추가하지 않고, ‘왜’를 설명한 문서 하나를 작성해 AI의 작업 컨텍스트에 항상 연결했습니다. 요즘 널리 쓰이는 규칙 파일과 겉 형식은 비슷했지만 내용은 달랐습니다. ‘이런 식으로 코딩하라’는 컨벤션도, 코드 한 줄도 넣지 않았습니다. 오직 “이 영역에서 ‘작동한다’는 말은 어떤 상태를 뜻하는가”, “무슨 일은 절대로 허용하면 안 되는가” 같은 판단 기준만 적었습니다.
변화는 뚜렷했습니다. 모델, 코드베이스, 개발자는 모두 같은데 결과의 품질이 달라졌습니다. 파인튜닝을 하지 않았고 모델을 업그레이드하지도 않았으며, 가중치(weight)는 하나도 변하지 않았습니다. 달라진 것은 추론 시점(inference time)에 모델이 참고하는 컨텍스트뿐이었습니다. 그래서 일종의 소프트 파인튜닝이라고 볼 수 있었습니다. 별도 학습 파이프라인 없이 바로 적용할 수 있고, 컨텍스트를 제거하면 효과도 없어지며, 영역에 맞춰 서로 다른 문서를 연결할 수 있었습니다.
차이는 이렇습니다. 규칙은 “헛소리하지 말라”면서 출력 범위를 제한하지만, ‘왜’는 “네가 만든 결과가 진짜인지 이 기준으로 판단하라”며 분별 도구를 건넵니다. 첫 방식은 창의성까지 빼앗지만, 두 번째 방식은 창의성은 남기면서 판단 능력을 더합니다.
옷에 빗대면 규칙은 드레스 코드입니다. “파란 셔츠를 입어라”라고 정하면 나쁜 선택과 창의적인 선택이 똑같이 사라집니다. 반면 ‘왜’는 안목에 가깝습니다. “고객이 신뢰할 수 있는 옷차림이어야 한다”는 목적을 주면, 그 목적에 부합하는 참신한 선택은 살아남습니다. 이후에도 AI는 새 구조를 계속 제안했지만 아무 작업도 하지 않는 빈 처리기는 더 만들지 않았습니다. ‘왜’가 “아무것도 처리하지 않음”을 분명하게 드러나는 실패로 정의했기 때문입니다.
이는 더 나은 모델이 나올 때까지 기다릴 필요가 없다는 뜻입니다. 더 좋은 맥락이 필요하고, 그 중심에는 ‘왜’가 있습니다. 또한 그 이유는 새 도구를 구입하거나 예산을 더 쓴다고 저절로 생기지 않습니다. 해당 도메인을 깊이 이해한 사람의 머릿속에서 나옵니다.
제가 문서에 어떤 ‘왜’를 넣었는지 한 가지 예를 들겠습니다. 철학 문서에는 이런 원칙이 적혀 있습니다. “혼자 운영하는 시스템은 팀이 운영하는 시스템보다 더 엄격해야 한다.”
처음 들으면 정반대가 맞는 듯합니다. 1인 개발이라면 적당히 단순하게 만들어도 될 것 같습니다. 그러나 팀에는 사람으로 된 안전망이 있습니다. 동료가 코드 리뷰에서 잘못된 설정을 발견하고, 누군가가 배포 전에 스테이징에서 다시 확인하며, 한밤중 프로세스가 폭주하면 온콜 담당자가 달려옵니다. 혼자 일하면 이 그물망 전체가 사라집니다. 틀린 환경 변수를 찾아줄 리뷰어도, 무한 루프에 빠진 워커를 새벽에 멈춰줄 사람도 없습니다.
그래서 문서에 대응 원칙을 분명히 적었습니다. 인간이 채우던 자리를 시스템이 메우도록 가드레일은 더 촘촘히 만들고, 오래 실행되는 모든 작업에는 반드시 킬스위치를 넣으며, 배포 전에는 롤백 절차를 준비하게 했습니다. 축소해야 할 것은 시스템의 엄격함이 아니었습니다. 여러 사람이 함께 일할 때만 필요한 의식(ceremony), 이를테면 여러 환경을 거치는 승인 체인이나 스프린트 의례를 줄여야 했습니다. 이런 판단이 코드가 전혀 없는 문서에 차곡차곡 쌓였고, AI는 그 ‘왜’를 읽은 뒤에야 실제 위험이 무엇인지 가려내기 시작했습니다.
지금까지의 경험을 하나의 그림으로 묶어보겠습니다. AI와 협업할 때는 세 가지 힘이 언제나 함께 움직입니다. 첫째, 창의성(Creative)은 제가 예상하지 못한 구조나 해결책을 내놓는 힘입니다. 둘째, 환각(Hallucination)은 설득력 있어 보이지만 실제로 작동하지 않는 결과를 만드는 성향입니다. 셋째, 원칙(Principles)은 규칙과 지침으로 출력 범위를 제한하는 힘입니다. 저는 세 단어의 첫 글자를 따서 이 줄다리기를 CHP라고 부릅니다.
중요한 사실은 세 가지를 한꺼번에 모두 얻을 수 없다는 점입니다. 설계 경험이 있다면 트레이드오프(tradeoff)가 익숙할 겁니다. 개발 과정에서는 한쪽을 선택하는 대신 다른 쪽을 포기해야 하는 일이 늘 생깁니다. 창의성을 자유롭게 두면 같은 뿌리를 가진 환각도 따라옵니다. 반대로 원칙으로 강하게 묶으면 환각뿐 아니라 창의성까지 약해집니다. 규칙이 대칭적으로 작동해 한쪽만 억누를 수 없기 때문입니다. 어느 한쪽을 당기면 다른 힘도 함께 움직이는 삼각형의 줄다리기입니다.
제가 발견한 ‘왜’는 이 삼각형을 빠져나가는 유일한 우회로였습니다. 원칙처럼 환각을 억제하면서도 창의성을 손대지 않는 길입니다. 결과를 금지하는 대신 판단 기준을 주기 때문에 가능합니다. 다만 이 길을 써도 창의성과 원칙 사이의 알맞은 지점은 만드는 대상에 따라 달라집니다. 그러므로 CHP는 한 번 정해두는 고정 설정이 아니라 영역마다 새로 맞춰야 하는 ‘다이얼’입니다.
그렇다면 실제로 다이얼을 어떻게 조정해야 할까요? 모든 영역에 ‘왜’를 무조건 많이 주거나, 어디에서나 창의성을 같은 수준으로 허용하는 방식은 해답이 아닙니다. 제가 얻은 답은 제품과 영역마다 창의성과 원칙의 균형을 따로 정해야 한다는 것입니다.
프론트엔드나 UX처럼 시각적 혁신이 중요하고, 실패하더라도 곧바로 눈에 띄며 되돌리는 비용이 낮은 곳에서는 다이얼을 창의성 쪽으로 크게 돌립니다. 반대로 메시지 브로커, 데이터 파이프라인, 인프라처럼 신뢰성이 핵심인 곳은 원칙 쪽으로 끝까지 돌립니다. 메시지 브로커에서 창의적인 일탈은 곧 장애입니다. 통신 프로토콜을 구현할 때는 더 분명해서, 창의적 일탈이 바로 규격 위반이 됩니다. 가장 어려운 곳은 그 사이입니다. 스스로 판단하면서도 엄격한 운영 한계를 지켜야 하는 영역이며, 에이전트가 여기에 해당합니다.
여기서 저는 또 하나를 깨달았습니다. 혼자 AI와 일할 때 진짜 병목은 코드 작성도 시스템 설계도 아니었습니다. 모든 영역에서 이 다이얼을 동시에 관리하고, 상황이 바뀔 때마다 다시 맞추는 일이 병목이었습니다. 아침에는 프론트엔드를 보며 “좀 더 과감해져라”고 하고, 점심에는 프로토콜 핸들러에 “규격에서 한 바이트도 벗어나지 말라”고 하며, 오후에는 에이전트 로직에 “창의적으로 해결하되 안전 경계는 넘지 말라”고 해야 했습니다. 서로 다른 모드를 오가며 머릿속 설정을 계속 바꾸는 일이 실제 노동이었습니다.
역설적으로 AI의 능력이 좋아질수록 이 노동은 줄기는커녕 늘어납니다. 유능한 AI는 설득력 있는 선택지를 더 많이 제시하고, 그중 올바른 것을 골라내려면 인간에게 한층 정밀한 판단이 요구되기 때문입니다.
돌이켜보면 처음에는 질문부터 잘못했습니다. 저는 “AI가 헛소리를 덜 하게 하려면 어떻게 해야 할까”라고 물었습니다. 실제로 물어야 했던 것은 “AI가 헛소리와 좋은 발상을 스스로 구별하게 하려면 어떻게 해야 할까”였습니다. 규칙으로 AI의 입을 막으면 두 종류 모두 사라집니다. 판단의 근거인 ‘왜’를 건네면 그제야 AI는 자신의 결과를 스스로 평가하기 시작합니다. 창의성은 보존하면서 허상만 걸러내는 방법은 규칙을 더하는 것이 아니라 ‘왜’를 더 선명하게 만드는 데 있었습니다.
이 경험은 AI와 협업하는 방식에 대한 제 생각을 바꿨습니다. AI는 자신이 받은 맥락을 거울처럼 반사합니다. 제가 또렷한 ‘왜’를 제공하면 그 선명함을 보여주고, 모호하게 남겨두면 모호함을 그대로 키워 되돌려줍니다. 몇 달 동안 만든 무대 세트는 AI가 제 의도를 구현하지 못한 결과가 아니었습니다. 검증하지 않은 제 생각을 오히려 완벽할 만큼 충실하게 구현한 결과였습니다.
그래서 AI 도입을 검토하는 사람들에게 이렇게 말하고 싶습니다. 더 나은 모델이나 더 큰 예산을 먼저 생각하기 전에 다음 질문에 답할 수 있는지 확인해야 합니다. 나는 왜 이것을 만드는가, 이 선택은 왜 옳은가, 이 실패는 왜 허용할 수 없는가. 가트너가 프로젝트의 40%가 폐기될 것으로 본 이유, 그리고 실패의 출발점을 모델이 아니라 사람의 결정에서 찾은 이유도 여기에 있습니다.
이 ‘왜’에 답할 수 있다면 AI는 놀라운 능력을 지닌 동료가 됩니다. 답할 수 없다면 속도는 빠르고 외형은 훌륭하지만 안이 빈 무대 세트를 짓게 됩니다. 결국 코딩 기계가 놓는 함정은 AI 자체의 한계가 아니라는 점을 이 글을 통해 다시 전하고 싶었습니다.
원본 링크·인용
원문에서 기사 내용에 속한 링크는 카테고리와 저자 프로필 두 곳이며, 완역 본문의 같은 의미 위치에 모두 보존했습니다. 아래 목록은 원문과 팩트체크에 실제로 사용한 자료를 다시 찾기 위한 보조 인덱스입니다.
기타
원문 언어: 한국어. 번역을 새로 만들지 않고 제목·문단·수치·예시·이미지·링크 위치를 유지한 의미 보존 재구성으로 편집했습니다.
검증 범위: 가트너 전망, Git 기능, ADR·컨텍스트 관련 개념은 외부 자료와 대조했습니다. 200만 줄·5분·운영 검증 0건·품질 향상 등은 공개 로그나 실험 자료가 없어 저자 자기보고로 구분했습니다.
캡처: 2026-07-16, 접근 제한 없음. 로그인·광고·댓글 UI 링크 세 건은 기사 내용이 아니어서 완역 범위에서 제외했고, 제외 사유는 로컬 링크 영수증에 보존했습니다.
이미지: 기사 본문 사진 세 장을 원문 위치에 유지하고 단일 HTML 안에 포함했습니다. 각 캡션은 원문이 밝힌 대로 모두 작가 제공 자료입니다.