AI와 200만 줄의 코드를 작성하며 깨달은 것들

저는 25년 경력의 소프트웨어 아키텍트로, 현재 스타트업에서 CTO로 재직 중입니다. 그리고 지난 몇 달간, AI와 단둘이서 200만 줄이 넘는 코드를 짰습니다. 수십 개의 서비스, 여러 개의 AI 에이전트, 여러 개의 모바일 앱까지, 단 몇 시간 만에 서비스가 올라가고, 하룻밤 사이에 API가 생겨났습니다. 코드 리뷰를 하면 구조가 그럴듯했고, 모든 점검을 통과했습니다. 누가 봐도 “제품 출시 준비 완료”처럼 보였죠.

그런데 막상 돌려보니, 단 5분도 자율적으로 작동하지 못했습니다. 여기서 ‘작동한다’는 건 데모가 한 번 돌아간다는 뜻이 아닙니다. 사람이 지켜보지 않아도, 예외와 재시도와 동시 요청 속에서, 의도한 일을 끝까지 같은 결과로 해내는 것이죠. 그게 제가 말하는 ‘작동’입니다. 반대로 ‘껍데기’는 시연에서는 완벽하지만, 그 조건이 조금만 어긋나면 무너지는 결과물이 됐고요.

AI의 속도는 진짜였습니다. 하지만 엔지니어링은 아니었습니다. 이번 글은 ‘AI로 빠르게 만든 결과물이 왜 껍데기가 되는지’, 그리고 ‘AI에게 무엇을 다르게 줘야, 그 껍데기가 진짜가 되는지’에 대한 현장 기록입니다. 제품을 만드는 사람, 그리고 ‘AI를 도입하면 생산성이 오른다’는 말을 믿고, 의사결정을 내려야 하는 분들을 위해 썼습니다.

미리 요점만 콕 집어보면?

• AI에게 ‘무엇을(what)’과 ‘어떻게(how)’만 주면, 그럴듯하지만 작동하지 않는 코드가 나옵니다. 빠진 변수는 ‘왜(why)’입니다.
• 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로 코딩해 보신 분들은 잘 아실 겁니다. 저는 이런 결과물을 ‘이쁜 장난감’이라고 부르기도 합니다. 요새 흔히 얘기하는 바이브 코딩으로 나오는 제품들이 대부분 이런 모습입니다. 데모는 그럴듯한데, 프로덕션에 배포하면 제대로 동작하지 않거나, 버그가 쏟아지는 그런 제품들이죠.

추상적인 이야기로 들릴 수 있으니, 실제 경험 하나를 들려드리겠습니다. 저는 코딩 AI인 클로드 코드(Claude Code)에게 제 작업 환경을 설명하면서, 한 가지 맥락을 덧붙였습니다. “나는 팀이 아니라 혼자 일한다”고요. 단순한 상황 설명 한 줄이었죠.

저는 보통 클로드 코드 터미널을 네다섯 개씩 띄워놓고 병렬로 작업합니다. 처음엔 작업 공간 구조를 여러 저장소로 나눈 멀티 레포로 구성했었는데요. 한 번은 동시에 너무 많은 작업을 벌이다 git이 꼬여버렸습니다. 그래서 클로드 코드에게 한 달 치 작업 히스토리와 git 이력을 분석해 제 개발 패턴을 찾아보게 했죠. 그런데 제 개발 습관을 너무 잘 짚어내서 놀랐습니다.

그 분석을 토대로 클로드 코드는 한 가지를 역제안했습니다. 혼자서도 여러 작업을 병렬로 굴릴 수 있도록, 하나의 저장소를 여러 작업 공간으로 동시에 펼치는 구조(git worktree)로 가자는 것이었죠. 제가 ‘1인 솔로 개발’이라는 맥락을 명시했기에 나온 제안이었습니다. 그냥 “코드를 짜라”고 했다면 나오지 않았을, 제 작업 방식에 꼭 맞는 구조였죠. (덧붙이자면, 여러분도 한 달쯤 개발한 뒤 AI에게 자신의 행동 패턴을 분석시켜 보길 권합니다. 꽤 놀라운 결과가 나올 겁니다.)

그 덕에 저는 터미널 여러 개를 큰 충돌 없이 동시에 띄워 놓고, 각 화면에서 서로 다른 작업을 나란히 진행하게 됐습니다. 혼자라는 제약을 병렬성으로 상쇄하는 셈이었죠. (물론 대가도 있었습니다. 동시에 돌리던 세션들이 같은 작업 공간을 건드리며 충돌해 하루치 작업이 꼬인 적도 있었고, 그 사고 이후 “작업 공간 하나당 작업 줄기 하나”라는 규칙을 못 박았습니다.)

더 흥미로운 건 그 다음이었습니다. 혼자 개발하면 git이 사치처럼 느껴질 때가 있습니다. 되돌릴 일도, 협업할 사람도 없으니 커밋 메시지를 대충 쓰고 싶어지죠. 하지만 이력을 꼬박꼬박 남겨둔 게 뜻밖의 보상으로 돌아왔습니다. 나중에 클로드 코드가 어떤 코드를 고칠 때, git 이력을 뒤져 “이 부분이 과거에 왜 이렇게 바뀌었는지”를 읽고 그 맥락에 맞게 판단하기 시작한 겁니다. 제가 남긴 커밋 이력이 일종의 설계 결정 기록(ADR, Architecture Decision Record)처럼 작동한 거죠. 사람에게 코드 리뷰를 받을 수 없는 1인 개발에서, 과거의 내 결정이 담긴 커밋 이력은 AI에게 또 하나의 ‘왜’가 되어주었습니다.

핵심은 이겁니다. “혼자 일한다”는 맥락 한 줄, 그리고 그 맥락이 쌓인 커밋 이력이 없었다면, AI는 그저 코드만 뱉었을 겁니다. 맥락을 주자, AI는 내가 일하는 방식 자체를 다시 설계하고, 내 과거 판단까지 읽어내기 시작했습니다.

규칙을 늘릴수록 AI는 멍청해졌다

처음 개발할 때는 가장 상식적인 개발 가이드만 내렸습니다. 규칙을 늘렸죠. “이렇게 해라, 저렇게 하지 마라, 이 패턴을 따라라.”

절반은 맞았습니다. 헛소리는 줄었거든요. 그런데 예상 못 한 일이 벌어졌습니다. 규칙을 잔뜩 걸어둔 영역에서, AI가 다른 곳에선 우아하게 풀던 문제를 갑자기 풀지 못하기 시작한 겁니다. 규칙이 거의 없던 영역에서는 제가 생각지도 못한 방식으로 멋지게 해결하던 그 AI가요.

이유를 깨닫는 데는 시간이 좀 걸렸습니다. AI의 ‘환각’과 ‘창의성’은 같은 뿌리에서 나옵니다. 내가 생각 못 한 구조를 제안하는 능력과 그럴듯하지만 작동 안 하는 코드를 쏟아내는 성향은 정확히 같은 생성 메커니즘의 양면이죠. 그래서 규칙으로 출력 공간을 좁히면 헛소리가 나올 자리도 막히지만, 좋은 아이디어가 나올 자리도 똑같이 막힙니다. 규칙은 대칭적이라, 한쪽만 골라 누를 수가 없거든요.

제가 규칙으로 만든 것은 헛소리는 안 하지만 똑똑하지도 않은, 그냥 빠른 코딩 기계였습니다. 환각을 잡으려다 AI와 일할 이유 자체를 죽인 셈이죠.

모델이 아니라 맥락을 바꾸다

돌파구는 엉뚱한 데서 나왔습니다. 규칙을 더 거는 대신, ‘왜’를 담은 문서를 한 편 써서 AI의 작업 컨텍스트에 상시 물려둔 겁니다. 요즘 많이들 쓰는 규칙 파일과 형식은 비슷하지만, 담는 내용이 달랐습니다. ‘이렇게 짜라’는 코딩 컨벤션이 아니라, 코드는 한 줄도 없이 오직 판단 기준만 담았습니다. “이 영역에서 ‘작동한다’는 것은 무엇을 의미하는가”, “무엇을 절대 해서는 안 되는가” 같은 것들이요.

결과는 분명했습니다. 같은 모델, 같은 코드베이스, 같은 개발자였는데 결과물의 품질이 달라졌습니다. 파인튜닝도, 모델 업그레이드도 없었습니다. 가중치(weight)는 단 하나도 바뀌지 않았죠. 바뀐 건 오직 추론 시점(inference time)에 모델이 참조하는 컨텍스트뿐이었습니다. 일종의 소프트 파인튜닝이었던 셈입니다. 학습 파이프라인 없이 즉시 적용되고, 컨텍스트를 빼면 효과도 사라지고, 영역마다 다른 문서를 끼울 수 있는 거죠.

핵심은 이겁니다. 규칙이 “헛소리하지 마”라고 출력을 제약하는 것이라면, ‘왜’는 “네가 만든 게 진짜인지 이렇게 판단해 봐”라고 분별의 기준을 쥐여주는 것이었습니다. 전자는 창의성까지 빼앗지만, 후자는 창의성을 남겨둔 채 분별력만 더합니다.

비유하자면 규칙은 드레스 코드입니다. “파란 셔츠를 입어라.” 나쁜 선택도 창의적인 선택도 똑같이 사라집니다. 반면 ‘왜’는 안목입니다. “네 옷차림은 고객에게 신뢰감을 줘야 한다.” 목적에 맞기만 하면 참신한 선택이 살아남죠. 그 뒤로 AI는 여전히 새로운 구조를 제안했지만, 아무것도 처리하지 않는 껍데기 처리기는 더 이상 만들지 않았습니다. ‘왜’가 “아무것도 안 함”을 눈에 보이는 실패로 만들어줬으니까요.

이것의 의미는 더 좋은 모델을 기다릴 필요가 없다는 겁니다. 필요한 건 더 좋은 맥락이고, 그 맥락의 핵심은 ‘왜’입니다. 그리고 ‘왜’는 도구를 새로 사거나, 예산을 더 태운다고 생기지 않습니다. 그 도메인을 깊이 아는 사람의 머릿속에서 나오죠.

구체적으로 어떤 ‘왜’를 적었는지 하나만 예로 들어보겠습니다. 제 철학 문서에는 이런 원칙이 있습니다. “혼자 운영하는 시스템은, 팀이 운영하는 시스템보다 더 엄격해야 한다.”

얼핏 반대처럼 들립니다. 1인 솔로 개발이니 적당히, 간단하게 가야 할 것 같죠. 하지만 팀에는 사람으로 이뤄진 안전망이 있습니다. 동료가 코드 리뷰에서 잘못된 설정값을 잡아내고, 누군가 배포 전에 스테이징에서 한 번 더 확인하고, 새벽에 프로세스가 폭주하면 온콜 담당자가 달려갑니다. 혼자라면 이 그물망이 통째로 없습니다. 잘못된 환경 변수를 잡아줄 리뷰어도, 무한 루프에 빠진 워커를 새벽에 조치해 줄 사람도 없죠.

그래서 저는 문서에 못 박았습니다. 사람이 메워주던 자리를 시스템이 대신 메우도록, 가드레일은 더 촘촘하게, 킬스위치는 모든 장기 실행 작업에 빠짐없이, 배포에는 반드시 롤백 레시피를 미리 붙였죠. 줄여야 하는 건 시스템의 엄격함이 아니라, ‘여러 명이 일할 때만 필요한 의식(ceremony)’, 멀티 환경 승인 체인이나 스프린트 의례 같은 것들이었습니다. 이런 판단들이 코드 한 줄 없는 문서에 쌓였고, AI는 그 ‘왜’를 읽고 나서야 비로소 무엇이 진짜 위험인지 알아보기 시작했습니다.

세 가지 힘의 줄다리기: CHP(Creative-Hallucination-Principles)

이쯤에서 제가 겪은 걸 한 장의 그림으로 정리해 보겠습니다. AI와 일하다 보면 세 가지 힘이 늘 맞물려 움직입니다. 첫째는 창의성(Creative)입니다. 제가 생각지도 못한 구조나 해법을 내놓는 힘이죠. 둘째는 환각(Hallucination)입니다. 그럴듯하지만 작동하지 않는 결과물을 내놓는 성향이고요. 셋째는 원칙(Principles)입니다. 규칙과 가이드로 출력을 묶는 제약입니다. 저는 이 셋의 줄다리기를 머리글자를 따 CHP라고 부릅니다.

핵심은, 이 세 가지를 동시에 다 가질 수 없다는 겁니다. 설계를 좀 해보신 분들은 트레이드오프(tradeoff)라는 단어를 많이 들어 보셨을 겁니다. 개발하다 보면 어느 한쪽을 택하고, 다른 한쪽을 포기해야 하는 일이 늘 생기죠. 창의성을 풀어주면 환각이 같이 따라옵니다. 앞서 말했듯 둘은 같은 뿌리에서 나오니까요. 그렇다고 원칙으로 꽉 묶으면 이번엔 환각과 함께 창의성까지 죽습니다. 규칙은 대칭적이라 한쪽만 누를 수 없거든요. 결국 한쪽을 당기면 다른 쪽이 끌려오는, 삼각형의 줄다리기인 셈입니다.

제가 찾은 ‘왜’는 이 삼각형에서 유일한 우회로였습니다. 원칙처럼 환각은 누르되, 창의성은 건드리지 않는 길. 출력을 막는 대신 분별의 기준을 주기 때문에 가능한 일이었죠. 그런데 이 우회로를 쓰더라도, 창의성과 원칙의 적절한 균형점은 무엇을 만드느냐에 따라 달라집니다. 그래서 CHP는 하나의 고정된 설정이 아니라, 영역마다 다시 맞추는 ‘다이얼’이 됩니다.

다이얼은 영역마다 다르게

그렇다면 이 다이얼을 실제로 어떻게 돌릴까요? 모든 영역에 ‘왜’만 잔뜩 주거나, 모든 영역에 창의성을 똑같이 풀어주는 게 정답은 아닙니다. 제가 찾은 답은, 창의성과 원칙의 균형을 만드는 제품마다 다르게 맞춰야 한다는 것이죠.

프론트엔드나 UX처럼 시각적 혁신이 중요하고 실패해도, 즉시 눈에 보이며 롤백이 싼 영역은 창의성 쪽으로 다이얼을 한껏 돌립니다. 반대로 메시지 브로커나 데이터 파이프라인, 인프라처럼 신뢰성이 생명인 영역은 원칙 쪽으로 끝까지 돌리죠. 메시지 브로커에서의 창의성은 그냥 장애니까요. 통신 프로토콜을 구현하는 영역이라면 더합니다. 거기서의 창의성은 곧 규격 위반이거든요. 가장 까다로운 건 그 중간, 자율적으로 판단하되 엄격한 운영 경계 안에 머물러야 하는 영역입니다. 에이전트가 바로 여기에 속하죠.

그리고 여기서 깨달았습니다. 혼자서 AI와 일하는 사람의 진짜 병목은 코드를 짜는 것도, 시스템을 설계하는 것도 아니었습니다. 이 다이얼을 모든 영역에서 동시에, 매번 다시 맞추는 일이었죠. 아침엔 프론트엔드를 보며 “더 과감하게”, 점심엔 프로토콜 핸들러를 보며, “한 바이트도 규격에서 벗어나지 마”, 오후엔 에이전트 로직을 보며 “창의적으로 풀되 안전 경계는 넘지 마”. 이 사이를 오가며 머릿속 다이얼을 매번 다시 세팅하는 게 진짜 노동이었습니다.

역설적이게도 이 노동은 AI가 똑똑해질수록 줄지 않고 늘어납니다. 유능한 AI일수록 더 그럴듯한 선택지를 더 많이 쏟아내고, 그걸 분별하려면 더 정교한 판단이 필요하니까요.

마치며: AI는 거울이다

돌이켜보면 처음의 제 실수는 질문이 틀린 데 있었습니다. 저는 “어떻게 AI가 헛소리를 덜 하게 만들까”를 물었죠. 진짜 질문은 “어떻게 AI가 헛소리와 좋은 아이디어를 스스로 구분하게 할까”였어야 했습니다. 규칙으로 입을 막으면 둘 다 사라집니다. ‘왜’라는 판단 근거를 쥐여주면, AI는 비로소 자기 결과물을 스스로 평가하기 시작합니다. 창의성은 살리고 헛것만 걸러내는 길은 더 많은 규칙이 아니라, 더 분명한 ‘왜’에 있었습니다.

이 경험은 AI와 일하는 방식에 대한 제 생각을 바꿔놓았는데요. AI는 자신에게 주어진 맥락을 거울처럼 비춥니다. 제가 명확한 ‘왜’를 주면 그 명확함을 비추고, 모호한 채로 두면 그 모호함을 그대로 증폭해 비춥니다. 몇 달간의 무대 세트는 AI가 제 의도를 구현하는 데 실패한 게 아니라, 검증되지 않은 제 생각을 완벽한 충실도로 구현해 낸 결과였습니다.

그래서 AI 도입을 고민하는 분들께 드리고 싶은 말은 더 좋은 모델이나, 더 많은 예산을 먼저 떠올리기 전에 이 질문에 답할 수 있는지 보라는 겁니다. 나는 이것을 왜 만드는가, 이 결정이 왜 옳은가, 이 실패가 왜 용납될 수 없는가. 가트너가 40%의 프로젝트가 폐기될 거라 본 이유, 그리고 그 실패가 모델이 아니라 사람의 결정에서 온다고 본 이유가 바로 여기에 있거든요.

이 ‘왜’에 답할 수 있다면 AI는 놀라운 역량의 파트너가 됩니다. 답하지 못하면, 빠르고 그럴듯하지만 텅 빈 무대 세트를 짓게 되죠. 결국 코딩 기계의 함정은 AI의 한계가 아니란 사실을, 이번 글을 통해 한 번 더 전하고 싶었습니다.

©️요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.