1년 전, 혼자서 일주일 안에 프로덕션 앱을 완성하는 건 불가능했다. 지금은 가능하다. 그런데 그 이유가 '더 좋은 프롬프트를 쓰게 됐기 때문'은 아니다. dev.to에 올라온 한 엔지니어의 12개월 실전 회고는 이 지점에서 시작한다. 6개의 프로덕션 앱을 혼자 출시한 경험담이지만, 핵심 메시지는 도구 자랑이 아니다. 오히려 반대다—AI 도구를 잘못 쓰면 0.5배 속도로 달린다는 경고에 가깝다.
프롬프트 엔지니어링이라는 착각
대부분의 개발자가 AI 코딩 도구를 처음 접할 때 하는 실수가 있다. AI를 '더 똑똑한 검색엔진'으로 취급하는 것이다. 막연한 질문을 던지고, 나온 코드를 붙여 넣고, 반복한다. 결과는 예상대로 엉망이다. 구현의 80%까지는 가는데, 나머지 20%에서 전체가 무너진다. AI가 내가 실제로 뭘 만들고 있는지 전혀 모르기 때문이다. 이 문제를 '더 잘 묻는 법'으로 해결하려 하면 늪에 빠진다.
전환점은 생각보다 단순한 인식 변화였다. AI를 코드 생성기가 아니라 제대로 브리핑해야 하는 주니어 엔지니어로 대하기 시작한 것이다. 브리핑의 순서는 요구사항 → 컨텍스트 → 코드. 당연하게 들리지만, 실제로 채팅창을 열면 대부분 바로 "함수 짜줘"로 시작한다. 그래서 결과물이 코드베이스와 동떨어지고, 아키텍처와 맞지 않고, 의도와 어긋난다. 해결책은 프롬프트 기술이 아니라 컨텍스트 엔지니어링이다. 매 세션마다 아키텍처 결정, 데이터 모델, 네이밍 컨벤션, 제약 조건을 담은 컨텍스트 파일을 붙여 넣는 습관 하나가, 어떤 프롬프트 기교보다 강력했다.
다크 코드: 속도의 이면에 쌓이는 부채
그런데 컨텍스트를 잘 설계하고 코드를 빠르게 생성해냈다고 해서 끝이 아니다. 여기서 두 번째 문제가 등장한다. dev.to의 또 다른 글이 이를 '다크 코드(Dark Code)' 문제로 명명했다. 개념 자체는 간단하다—어떤 인간도 작성하지 않았고, 읽지 않았으며, 리뷰하지 않은 코드 라인. AI 에이전트는 코드를 빠르게 생성한다. 하지만 인간의 이해 속도는 여전히 인간 속도로 작동한다.
실제 사례가 이를 잘 보여준다. 배우 Milla Jovovich가 AI 에이전트로 개발한 LLM 메모리 관리 시스템 MemPalace를 오픈소스로 공개했는데, 리뷰어가 코드를 실제로 들여다봤더니 에이전트가 "이 기능이 있다"고 설명한 것들이 실제로는 구현되지 않은 경우가 나왔다. AI는 자신감 있게 기능 존재를 주장했지만, 코드는 그것을 하고 있지 않았다. 배포 압박이 높고 리뷰 시간이 부족할수록 이런 다크 코드는 조용히 쌓인다. 그리고 프로덕션에서 터진다.
이것이 앞서 언급한 Resume Generator 아키텍처가 흥미로운 이유다. 이 프로젝트는 AI가 잘하는 것(언어 변환)과 못하는 것(사실 유지)을 명확히 분리해서 설계됐다. LLM은 YAML 프로필을 변환할 수는 있지만 내용을 추가할 수 없도록 시스템 프롬프트로 제약했고, 출력 후에는 규칙 기반 검증 레이어가 모든 클레임을 원본 YAML과 대조한다. 환각이 감지되면 출력 자체를 거부한다. AI 생성 코드의 신뢰 문제를 코드 레벨의 아키텍처로 풀어낸 셈이다.
원격 에이전트: 자리를 떠나도 일이 돌아가는 워크플로우
한편, 워크플로우의 물리적 제약을 허무는 시도도 등장하고 있다. 오픈소스 프로젝트 Happy는 Claude Code와 Codex를 모바일(iOS/Android)과 웹에서 원격 제어할 수 있는 CLI 래퍼다. 로컬에서 happy claude 명령으로 AI 세션을 시작하면 스마트폰에서 이어서 조작할 수 있다. 에이전트가 권한 요청이나 오류를 발생시키면 푸시 알림으로 즉시 확인하고 승인하거나 중단할 수 있다. 엔드투엔드 암호화가 적용되어 있어 회사 코드가 평문으로 서버를 경유하지 않는다는 점도 실무 도입 장벽을 낮춘다.
이 도구가 의미 있는 이유는 단순한 편의 기능 때문이 아니다. 다크 코드 문제와 연결해서 보면 더 명확해진다. 에이전트가 자율적으로 코드를 생성하는 시간 동안 인간이 완전히 루프 밖으로 빠지는 게 문제인데, 모바일 원격 제어는 적어도 에이전트가 중요한 분기점에서 인간을 개입시키는 구조를 유지할 수 있게 해준다. 에이전트를 무인으로 돌리는 게 아니라, 비동기로 감독하는 패턴이다.
시사점: AI-First 팀이 실제로 설계해야 할 것
세 가지 현장을 겹쳐보면 공통된 설계 원칙이 보인다.
첫째, 컨텍스트는 인프라다. 좋은 프롬프트는 일회성이지만, 잘 설계된 컨텍스트 파일은 팀 자산이다. 아키텍처 결정, 제약 조건, 네이밍 컨벤션을 문서화해서 매 세션에 주입하는 것은 개인 습관이 아니라 팀 워크플로우로 표준화해야 한다.
둘째, AI 생성 코드에는 검증 레이어가 필요하다. 코드 리뷰 없이 AI 출력을 그대로 머지하는 것은 기술 부채가 아니라 신뢰 부채를 쌓는 것이다. Resume Generator의 검증 레이어처럼, AI가 만든 결과물을 사전에 정의한 규칙으로 걸러내는 구조를 파이프라인에 내장해야 한다.
셋째, 에이전트 감독은 동기가 아니어도 된다. 데스크톱 앞에 붙어서 에이전트를 지켜보는 건 비효율적이다. 하지만 루프 밖으로 완전히 빠져나가는 것도 위험하다. 비동기 알림 기반 감독 구조가 현실적인 중간 지점이다.
전망: 속도와 품질 거버넌스는 별개가 아니다
"AI가 10배 빠르게 만들어준다"는 말은 반만 맞다. 정확히는 명확한 스펙 → 올바른 컨텍스트 → 반복적 구현 → 리뷰 → 반복이라는 사이클이 갖춰졌을 때 10배가 가능하다. 스펙도 없이, 컨텍스트도 없이, 리뷰도 없이 AI를 켜두는 것은 다크 코드를 생산하는 공장을 돌리는 것과 같다.
AI-First 팀이 진짜 경쟁력을 갖추려면 '얼마나 빨리 코드를 뽑느냐'가 아니라 '얼마나 신뢰할 수 있는 코드를 지속적으로 만드느냐'를 기준으로 워크플로우를 설계해야 한다. 컨텍스트 엔지니어링, 검증 레이어, 비동기 감독 구조—이 세 가지는 도구의 문제가 아니라 팀 설계의 문제다. 그리고 그 설계는 여전히 인간의 몫이다.