AI agent가 못 보는 건 코드가 아니라 그 코드 바깥입니다

AI 때문에 개발자가 사라진다는 말을 요즘 정말 자주 듣습니다.

재미있는 건 이 말을 개발을 잘 모르는 사람이 아니라 AI를 매일 쓰는 개발자들이 더 많이 한다는 점입니다. 매일 눈앞에서 AI가 자기 대신 코드를 뽑아내는 걸 보고 있으면 흔들릴 수밖에 없습니다. 예전에는 "주니어 업무부터 줄어들겠지" 정도였는데 이제는 시니어도 안전하지 않다는 쪽으로 얘기가 넘어갔습니다.

얼마 전에 지인 한 명이 진지하게 커리어 전환을 고민한다고 했습니다. 30년 넘게 코딩한 사람입니다. 자기가 일주일 붙들 일을 AI가 몇 시간 안에 대충 형태를 만들어내는 걸 보면서 묻더군요.

"내가 지금 쌓고 있는 숙련이 3년 뒤에도 값이 있을까?"

반대로 다른 한 명은 AI를 거의 안 쓰는 팀원들을 보면서 완전히 다른 불안을 말합니다.

"저 사람들은 지금 뭘 준비하고 있는 거지?"

같은 시기에 정반대 방향의 공포가 동시에 생기고 있는 셈입니다. 둘 다 이해는 갑니다.

그런데 저는 이 불안의 출발점 자체가 조금 틀렸다고 보고 있습니다. 개발자가 없어지는 게 아니라 "개발자"라는 말이 가리키는 대상이 바뀌는 중입니다. 이 변화가 너무 빠르고 거칠게 오니까 사람들이 제일 쉬운 문장으로 번역해버립니다. "개발자 없어지는 거 아냐?"

실제로는 조금 다릅니다. 구현만 하던 개발자의 자리가 줄어드는 것이고, 무엇을 만들어야 하는지 정의하고 무엇을 버려야 하는지 판단하는 개발자의 자리가 다시 커지고 있습니다.

앞의 지인 질문으로 돌아가면, 저는 그때 제대로 답을 못 했습니다. 값이 있다고 말하기도 없다고 말하기도 애매했습니다. 30년 코딩한 사람의 숙련이 전부 같은 종류가 아니기 때문입니다.

같은 30년 안에 서로 다른 두 가지가 섞여 있습니다. 하나는 "이 언어로 이 구조를 이렇게 만든다" 쪽이고, 다른 하나는 "이 요구를 이대로 받으면 반년 뒤에 여기가 터진다" 쪽입니다. 앞쪽은 값이 빠르게 떨어지고 있습니다. 뒤쪽은 오히려 지금이 제일 비쌉니다. 문제는 본인도 자기 숙련이 어느 쪽에 몰려 있는지 잘 모른다는 점입니다. 둘 다 "코딩 경력"이라는 한 단어로 불려왔으니까요.

그래서 저는 그 질문을 조금 바꿔서 다시 물어보는 게 낫다고 봤습니다. 3년 뒤에도 값이 있느냐가 아니라, 지금 내가 회의에서 제일 자주 하는 말이 "그거 어떻게 만들죠"인지 "그거 만들면 이런 게 걸릴 텐데요"인지. 후자를 자주 하는 사람이면 불안해할 이유가 별로 없다고 봅니다.

"구현자에서 설계자로"라는 말로는 조금 모자랍니다

작년에 사내 발표를 준비하면서 이 주제를 한 번 정리한 적이 있습니다. 겉으로는 복잡한 크로스플랫폼 데스크톱 앱을 리팩토링하면서 겪은 경험담이었는데, 사실 진짜 하고 싶었던 얘기는 그게 아니었습니다. AI를 잘 쓰는 팁이 아니라, AI를 쓰다 보니 제가 하는 일의 무게중심이 어디로 옮겨가고 있는지가 더 중요했습니다. 그때 만든 자료가 반년 뒤에 어떻게 읽혔는지는 따로 한 번 적어둔 적이 있습니다.

그때 적어둔 문장 하나를 지금 다시 봐도 여전히 정확합니다.

개발자의 무게중심이 구현자에서 설계자로 다시 이동하고 있다.

여기서 중요한 단어는 "다시"입니다.

원래 개발자는 요구사항을 이해하고 구조를 정하고 구현하고 테스트하고 운영까지 책임지는 사람이었습니다. 90년대나 2000년대 초반만 해도 "개발자"라는 말 안에 설계가 당연히 들어 있었습니다. 그런데 어느 순간부터 역할이 쪼개졌습니다. 프레임워크는 풍부해지고 오픈소스는 넘쳐나고 구현 속도가 경쟁력이 됐습니다. 그 과정에서 개발자는 점점 "코드를 빨리 치는 사람"으로 축소됐고, 설계는 아키텍트나 테크 리드 같은 별도 역할로 밀려났습니다.

AI는 바로 이 축소된 정의를 깨고 있습니다. 구현이라는 가장 눈에 띄는 일을 AI가 가져가니까, 역설적으로 개발자라는 직군의 원형이 다시 드러납니다. 요구사항을 해석하고 경계를 정의하고 판단을 내리는 사람. 그게 원래 개발자였는데 한동안 우리는 구현자만 개발자라고 불러왔던 셈입니다.

80%까지는 정말 잘 됩니다

이 얘기를 너무 추상적으로 하고 싶지는 않습니다.

제 경험으로 말하면 vibe coding은 처음 80%까지는 정말 잘 됩니다. 요구사항 몇 줄 던지면 그럴듯한 코드가 나옵니다. 화면도 뜨고 기본 동작도 맞고 컴파일도 됩니다. 이 구간에서는 황당할 정도로 빠릅니다. "이제 작은 프로젝트는 며칠이면 끝나겠는데?"라는 착각이 들 정도입니다. 저도 그랬습니다.

그런데 남은 20%에서 분위기가 완전히 바뀝니다.

버그 하나가 터집니다. 프롬프트를 조금 바꿔봅니다. AI가 강한 확신으로 원인을 지목합니다. 그대로 고칩니다. 다른 곳이 깨집니다. 그걸 고칩니다. 처음 문제랑 연결된 구조가 또 어긋납니다. 비슷한 코드가 하나 더 생깁니다. 한 시간쯤 지나면 처음에 뭘 고치려고 했는지 감각이 흐려집니다.

이게 정말 자주 생깁니다.

어느 날은 단순한 UI 버그 하나를 세 시간 넘게 붙들고 있었습니다. AI가 제안한 수정안을 넣으니 다른 렌더링 로직이 무너졌고, 그걸 고치니 상태 관리가 엉켰고, 상태를 다시 맞추니 처음 문제였던 UI가 또 이상해졌습니다. 그때 좀 웃겼습니다. 그냥 처음부터 제가 직접 디버깅했으면 30분이면 끝났을 버그였으니까요.

이런 순간이 몇 번 쌓이고 나서야 하나가 보이기 시작했습니다.

AI는 지금 눈앞의 코드 조각은 꽤 잘 봅니다. 그런데 그 조각이 속한 시스템의 숨은 전제에는 쉽게 눈이 멉니다.

이 상태값은 언제 초기화되는지, 이 이벤트는 어느 타이밍에 발생하는지, 이 렌더링은 어떤 사이클에서 트리거되는지, 이 캐시가 언제 폐기되어야 하는지. 이런 전제는 코드 몇 줄 안에 안 담겨 있습니다. 시스템 전체에 퍼져 있고 가끔은 사람 머릿속에만 있습니다.

그래서 AI는 한 곳을 고칠 때 그 전제를 암묵적으로 들고 있던 다른 곳을 조용히 망가뜨립니다. 프롬프트를 더 정교하게 써도 여기서 벗어나기 어렵습니다. 전제를 구조로 밖에 꺼내놓지 않으면 AI는 계속 같은 함정에 빠집니다.

이 단계에서 사람들은 보통 "프롬프트를 더 잘 써야 하나 보다"라고 생각합니다. 저도 한동안 그랬습니다. 그런데 오래 안 갔습니다. 프롬프트를 아무리 공들여도 장기 구조와 일관성과 책임 경계 문제는 계속 반복됐습니다.

질문 자체를 바꿔야 했습니다. "AI한테서 원하는 답을 어떻게 끌어낼까"가 아니라 "AI가 사람의 말투에 흔들리지 않고 미리 정의된 기준을 계속 따르게 하려면 무엇이 필요한가". 거기서부터 얘기가 달라졌습니다.

그렇다고 남은 20% 전부가 사람 몫이라고 말하면 그것도 과장입니다. 제가 세 시간 붙들었던 그 UI 버그도, 나중에 구조를 정리하고 나서 같은 종류의 문제를 다시 만났을 때는 AI가 먼저 원인을 짚었습니다. 달라진 건 모델이 아니라 제가 준 조건이었습니다. 상태의 출처를 한 곳으로 모으고 그 규칙을 문서에 적어두니, 같은 모델이 같은 질문에서 다른 답을 냈습니다.

그래서 정확히 말하면 20%가 사람 몫인 게 아니라, 20%를 AI가 다룰 수 있는 형태로 만드는 일이 사람 몫입니다. 이 차이가 별로 안 커 보이는데 실제로는 방향이 반대입니다. 앞쪽으로 이해하면 사람은 AI가 못 하는 일을 계속 찾아다녀야 합니다. 뒤쪽으로 이해하면 사람은 AI가 할 수 있는 범위를 계속 넓히는 일을 합니다. 저는 뒤쪽이 훨씬 오래 가는 자리라고 보고 있습니다.

제일 크게 깨진 건 마지막이었습니다

이걸 선명하게 만들어 준 건 리팩토링 작업 몇 번이었는데, 순서대로 말하면 오히려 흐릿해집니다. 제일 크게 깨진 마지막부터 얘기하는 게 낫겠습니다.

Rust와 C++와 Electron과 React와 Node.js가 한 덩어리로 얽힌 데스크톱 앱이 있었습니다. 앞선 방식이 잘 통했으니 이번에도 되겠거니 하고 들어갔는데, 중간에 손을 놨습니다. 중단이라고 적어두긴 했지만 실패라고 부르는 게 맞습니다.

무너지는 방식이 특이했습니다. 핵심 상태값 하나를 손댔더니 React가 들고 있는 값과 Electron 메인 프로세스가 캐싱해둔 값과 Rust 코어 안의 인스턴스가 조금씩 다른 방향으로 벌어지기 시작했습니다. 며칠 지나니까 어느 쪽이 원본이고 어느 쪽이 복제본인지 감각이 없어졌습니다. 상태 관리를 정리해달라고 부탁할수록 구조는 더 두꺼워졌습니다. 각 레이어에서 AI가 내놓은 개선안은 하나하나 다 말이 됐는데, 그 개선안들이 서로를 무효로 만들었습니다.

증상은 React에서 보이는데 원인은 IPC 메시지가 변형되는 자리에 있었고, 그 아래에는 FFI 경계가 암묵적으로 깔고 있는 전제가 있었고, 더 밑에는 Rust 코어가 내린 판단이 있었습니다. 층마다 따로 보면 답은 늘 그럴듯했습니다. 그런데 층을 관통하는 정합성은 아무도 안 붙잡고 있었습니다.

그때 인정해야 했던 게 좀 아팠습니다. 저는 이 구조를 머릿속에서 한 장으로 못 그렸습니다. 못 그리니까 AI에게 줄 기준도 못 만들었습니다. 설계가 아예 없었던 게 아니라 설계가 얕았던 겁니다.

여기서 거슬러 올라가면 앞선 세 번이 왜 그렇게 갔는지도 같이 보입니다.

맨 처음엔 정말 아무 준비 없이 "코드 재설계 해줘" 한 줄로 시작했습니다. 초반은 멀쩡했습니다. 구조도 그럴듯하고 설명도 번듯했는데 중반부터 속도가 뚝 떨어졌습니다. 그때는 모델 한계라고 결론 냈습니다. 지금 보면 기준점이 없었던 거였습니다. 매 턴마다 답은 나왔지만 그 답들 사이에 일관성이 없었고, 맞출 기준이 없으니 AI는 그때그때의 최적해만 내놓았습니다.

두 번째엔 문서를 먼저 만들어놓고 들어갔습니다. 이번엔 되겠지 싶었는데 또 틀렸습니다. 버그가 날 때마다 큰 구조 변경 제안이 올라왔고, 비슷한 유틸이 두 번 세 번 새로 생겼습니다. 그러니까 문서를 만든 것과 설계를 한 것은 다른 일입니다. 문서는 결과물이 될 수 있지만 설계는 그 결과물이 흔들리지 않게 계속 검증하고 보정하는 쪽입니다.

세 번째엔 여러 AI를 동시에 붙여 교차 검증을 시켰고, 그제야 기능이 끝까지 붙었습니다. 결제까지 들어간 앱이 나왔으니 성공은 성공입니다. 다만 병목이 어디였는지는 그때도 분명했습니다. 모델이 아니라 제 설계의 깊이였습니다.

그래서 마지막 실패가 남긴 교훈이 제일 비쌌습니다. AI는 설계가 얕다는 사실을 알려주지 않습니다. 층마다 성실하게 그럴듯한 답을 냅니다. 그 답들이 서로 부딪힌다는 건 전체를 붙잡고 있는 사람만 느낍니다. 그 사람이 없으면 모순은 조용히 코드에 쌓였다가 어느 날 운영에서 터집니다.

문서가 부족한 게 아니라 문서를 운영하지 못한 게 문제였습니다

이 실패 뒤에 남은 건 "문서를 더 써야겠다" 같은 결론이 아니었습니다. 오히려 그 반대에 가까웠습니다.

문서는 이미 있었습니다. 문제는 그 문서가 기준으로 운영되지 않았다는 점이었습니다.

AI는 대화가 새로 시작될 때마다 문서를 읽는 것처럼 보입니다. 그런데 실제로는 표면만 훑고 자기가 지금 생성하기 편한 쪽으로 흘러가는 경우가 많습니다. 문서가 있다는 사실만으로는 기준이 고정되지 않습니다.

그래서 그 뒤에 바뀐 건 문서 자체보다 문서를 운영하는 방식이었습니다. docs는 판단과 맥락을 고정하는 기준선이 되고, 엔지니어링 핸드북은 공통 판단의 출발점이 되고, 설계 문서와 구현 가이드와 경계 문서가 서로를 연결하고, 디버깅 런북은 운영 단계에서 다시 설계를 되짚는 장치가 됐습니다.

이 구성의 핵심은 문서가 산출물이 아니라는 데 있습니다. 문서는 판단 기준을 운영하는 도구입니다.

물론 이 운영에 품이 안 든다고 말하면 거짓말입니다. 기준선을 계속 맞추는 일은 재미도 별로 없고, 급할 때 제일 먼저 건너뛰게 되는 작업입니다. 저도 마감이 붙으면 문서를 안 고치고 코드부터 만졌고, 그렇게 두 주만 지나면 문서와 코드가 서로 다른 얘기를 하기 시작했습니다. 그 상태에서 AI에게 문서를 읽히면 낡은 기준을 아주 성실하게 따릅니다. 그래서 이 일에서 제일 중요한 건 문서를 잘 쓰는 능력이 아니라, 어긋난 걸 알아차렸을 때 코드가 아니라 문서를 먼저 고치는 쪽을 선택하는 습관이었습니다.

여러 AI를 교차 검증하려면 결국 모두가 한 기준선을 참조해야 합니다. 기준선이 흐려지면 검증은 불가능해집니다. 복수의 AI를 돌려보면서 가장 자주 본 장면도 그거였습니다. AI끼리 의견이 엇갈리는 지점은 대체로 AI의 오류라기보다 제 설계의 빈틈이었습니다. 그 충돌 지점을 다시 문서에 반영하고 다시 돌리고 또 충돌나는 부분을 수정하는 식으로 가야 했습니다.

이 사이클을 몇 번 돌리고 나서야 체감한 변화가 있습니다. 일관성이 생겼습니다. 변수 이름이 수렴하고, 채널 이름이 정리되고, 도메인 규칙이 흔들리지 않고, 중복 유틸과 유사 코드가 눈에 띄게 줄었습니다.

그리고 제일 인상적이었던 건 실패 신호가 코드보다 문서에서 먼저 보이기 시작했다는 점입니다. 문서 단계에서 모순을 잡아내면 구현 단계에서의 삽질 루프가 줄어듭니다. 설계는 제가 했지만 결과물은 AI가 만들었다는 얘기를 예전에 한 번 썼는데, 그 글에서 설계라고 불렀던 게 정확히 이 운영입니다. 그림을 그리는 일이 아니라 그림이 흔들리지 않게 붙잡고 있는 일입니다.

AI는 장르는 아는데 회사는 모릅니다

여기까지 오면 자연스럽게 다음 질문이 나옵니다. 그럼 그 기준선에는 뭘 적어야 하나요.

이걸 설명하는 데 제일 좋은 예가 도메인입니다.

주식 거래 앱을 만들어달라고 하면 요즘 모델은 꽤 괜찮은 결과를 냅니다. 종목 검색, 주문, 체결, 잔고. 기능 구성 자체는 정확합니다. 이건 어렵지 않습니다. 이미 세상에 있는 패턴이니까요. 여기까지만 보면 "AI가 도메인을 이해한다"는 말이 맞습니다.

그런데 질문을 바꾸면 바로 깨집니다. "키움증권처럼 만들어줘."

이 순간부터 AI는 모릅니다. 키움증권이 어려운 이유는 기술이 아니라 규칙이기 때문입니다. 신용거래에서 담보를 어디까지 유지해야 하는지, 반대매매가 어떤 조건에서 발동하는지, 어떤 종목에 어떤 거래 제한이 붙는지, 위탁 수수료가 계좌 종류마다 어떻게 갈리는지, 시스템 장애나 시장 급변 상황에서 주문을 어떻게 제한하는지. 이건 주식 앱 기능이 아니라 금융 규제와 내부 정책과 운영 경험이 합쳐진 결과입니다.

게다가 이런 규칙에는 거의 항상 예외가 붙습니다. 반대매매 대상인데 결제가 지연된 계좌는 빼준다든지, 특정 사유로 거래가 정지된 종목은 계산에서 제외한다든지. 그 예외가 왜 생겼는지는 대개 몇 년 전 사고 하나에서 왔습니다. AI는 그 사고를 모릅니다. 그리고 이 조건 하나 틀리면 실제로 돈이 움직입니다.

AI는 여기서 둘 중 하나를 합니다. 가장 일반적인 금융 로직을 가져오거나, 그럴듯하게 지어냅니다. 둘 다 틀릴 가능성이 높습니다.

이걸 키움 사례로만 보면 특수해 보이는데 전혀 아닙니다. 모든 회사가 자기만의 비공개 도메인을 갖고 있습니다.

쿠팡을 보면 더 명확합니다. AI는 이커머스를 압니다. 상품, 장바구니, 결제, 배송. 그런데 쿠팡의 실체는 이게 아닙니다. 어떤 상품을 어떤 물류센터에 미리 깔아둘지, 재고를 언제 어느 방향으로 옮길지, 반품 요청이 들어왔을 때 자동 승인과 수동 검토를 무엇으로 가를지, 배송이 늦었을 때 보상 기준을 어디에 둘지. 이건 코드 문제가 아니라 운영 정책입니다.

당근은 더 재밌습니다. "중고거래 앱 만들어줘"는 AI가 잘합니다. 글 쓰고, 사진 올리고, 채팅하고, 거래 완료 누르고. 그런데 "당근처럼"이라고 하는 순간 얘기가 달라집니다. 동네 인증을 어느 반경까지 인정할지, 인증이 언제 풀리는지, 매너온도가 어떤 행동에 어느 방향으로 얼마나 움직이는지, 끌올을 어떤 주기로 허용할지, 사기 의심 계정을 어떤 신호 조합으로 잡아낼지, 동네생활 글이 어디까지 퍼질지. 이 규칙들이 곧 당근이라는 서비스 자체입니다. 기능 목록은 흉내 낼 수 있어도 이 규칙 없이는 그냥 다른 앱입니다.

네이버도 그렇습니다. 검색 화면은 누구나 만듭니다. 그런데 스마트스토어 정산이 언제 나가고 어떤 조건에서 보류되는지, 카페 등급이 무엇으로 올라가는지, 지역 업체가 어떤 순서로 노출되는지, 쇼핑 결과에서 광고와 일반 결과를 어떻게 섞는지는 밖에서 알 수 없습니다. 특히 랭킹 쪽은 성격이 좀 다릅니다. 공개하면 바로 어뷰징이 들어오기 때문에 공개할 수 없는 종류의 규칙입니다.

카카오 쪽도 마찬가지입니다. 메신저를 만드는 건 어렵지 않습니다. 그런데 알림톡과 친구톡을 어떤 조건에서 보낼 수 있는지, 채널 메시지 발송에 어떤 제한이 걸리는지, 선물하기에서 환불이 언제까지 가능하고 유효기간이 지난 건 어떻게 처리되는지, 오픈채팅 신고가 어떤 흐름으로 처리되는지. 여기에 결제와 정산이 얽히면 규칙은 더 촘촘해집니다. 그리고 그 촘촘함의 대부분은 약관 페이지가 아니라 사내 위키와 담당자 머릿속에 있습니다.

이 다섯 회사를 늘어놓고 보니 공통점이 하나 보입니다. 밖에서 보이는 건 전부 기능이고, 실제로 그 서비스를 그 서비스로 만드는 건 전부 판단 기준이라는 점입니다. 기능은 공개되어 있어서 학습 데이터에 들어갔고, 판단 기준은 공개된 적이 없어서 들어가지 않았습니다. 흥미로운 건 회사 안에 있는 사람들도 그 기준을 전부 알지는 못한다는 점입니다. 자기가 맡은 영역의 예외만 알고, 옆 팀 규칙은 필요할 때 물어봅니다. 그러니 이걸 "회사의 지식"이라고 부르는 것도 조금 부정확합니다. 여러 사람 머릿속에 흩어진 조각이고, 그 조각끼리 가끔 어긋나 있습니다.

그러니까 AI는 장르는 압니다. 회사는 모릅니다.

이건 모델이 좋아진다고 풀리는 문제가 아닙니다

여기서 제가 중요하게 보는 구분이 하나 있습니다.

흔히 "AI가 도메인을 모른다"고 말하는데, 정확히는 AI가 못 배운 게 아니라 그 정보가 세상에 없는 것입니다. 학습 데이터에 들어간 적이 없고, 앞으로도 들어갈 계획이 없습니다. 랭킹 규칙처럼 공개하는 순간 무력해지는 종류는 아예 영구히 밖으로 안 나옵니다.

이 구분이 왜 중요하냐면, 모델 성능 곡선과 이 문제가 무관하다는 뜻이기 때문입니다. 파라미터가 열 배가 되어도, 컨텍스트가 백만 토큰이 되어도, 없는 정보는 여전히 없습니다. 모델이 좋아지면 좋아질수록 오히려 더 그럴듯하게 지어낼 뿐입니다.

생각해보면 신입이 입사해서 처음 석 달 동안 배우는 게 정확히 이겁니다. 언어도 프레임워크도 아닙니다. "우리 회사에서는 이 경우에 이렇게 한다"는 것, 그리고 "저건 예전에 사고 나서 저렇게 된 거다"라는 것. 그 석 달이 AI에게는 없습니다. 세션이 시작될 때마다 입사 첫날입니다.

이 얘기를 하면 거의 항상 같은 반론이 옵니다. 그럼 사내 문서를 전부 넣어주면 되는 거 아니냐고. RAG로 위키를 붙이고 이슈 트래커를 붙이고 슬랙 로그까지 붙이면 그 석 달을 압축할 수 있지 않냐는 얘기입니다.

일리가 있고 방향도 맞습니다. 다만 해보면 넣는 게 문제가 아니라는 걸 금방 알게 됩니다. 사내 문서를 다 넣으면 서로 어긋나는 문서가 같이 들어갑니다. 2년 전 정책과 작년 정책과 지난달에 붙은 예외가 한 인덱스 안에 나란히 앉아 있습니다. 사람은 이 셋을 보면 최신 것을 고르거나 "이거 누가 알까" 하고 찾아갑니다. AI는 셋 중 검색 점수가 제일 높은 걸 고릅니다. 그 점수는 그 문서가 지금 맞는지와 아무 상관이 없습니다.

그러니까 문서를 넣는 일과 어떤 문서가 지금 유효한지 정하는 일은 별개입니다. 뒤쪽을 안 하면 넣을수록 더 일관성 있게 틀립니다. 그리고 뒤쪽을 할 수 있는 사람은 여전히 그 도메인을 아는 사람입니다. 검색 파이프라인이 그 판단을 대신해주지 않습니다.

여기서 한 가지가 더 걸립니다. 이런 규칙은 문서로 옮겨놔도 금방 낡습니다. 정책이 분기마다 바뀌고, 예외가 새로 붙고, 담당자가 옮겨가면서 왜 그랬는지가 같이 사라집니다. 사내 위키를 열어보면 마지막 수정일이 2년 전인 문서가 꼭 있습니다. 사람은 그 문서를 읽고도 "이건 지금 안 맞을 텐데" 하고 옆자리에 물어봅니다. AI는 그 문서를 그대로 믿습니다. 그리고 그 위에 아주 일관성 있게 틀린 코드를 쌓습니다.

그러니까 도메인을 밖으로 꺼내놓는 일은 한 번 하고 끝나는 작업이 아닙니다. 앞에서 문서를 운영한다고 했던 게 이 얘기입니다. 적어두는 것보다 적어둔 게 지금도 맞는지 계속 확인하는 쪽이 훨씬 품이 많이 들고, 그 품을 들일 수 있는 사람이 사실상 그 시스템을 아는 사람입니다.

그래서 누군가는 알려줘야 합니다. 그리고 알려줄 수 있는 사람은 생각보다 적습니다. 도메인을 이해하고, 코드로 옮길 수 있고, 그걸 다시 구조화해서 설명할 수 있어야 합니다.

여기서 오해하기 쉬운 게 하나 있습니다. 이 말이 "한 회사에 오래 붙어 있어야 값이 생긴다"는 뜻으로 읽히면 곤란합니다. 제가 보기엔 오히려 반대에 가깝습니다.

한 회사의 비공개 규칙만 아는 사람은 그 회사 밖에서 값이 급격히 떨어집니다. 옮기면 처음부터 다시 쌓아야 합니다. 값이 남는 건 규칙 자체가 아니라 규칙이 어디에 숨어 있는지 찾아내는 감각입니다. 새 회사에 가서 "이 도메인에서 진짜 어려운 건 여기겠구나"를 첫 주에 짚어내는 사람과, 시키는 걸 다 한 다음에 왜 이렇게 되어 있는지 묻는 사람은 석 달 뒤에 전혀 다른 자리에 있습니다.

그리고 그 감각은 한 회사에서만 쌓이지도 않습니다. 오히려 여러 도메인을 건너본 사람이 더 빨리 짚습니다. 금융에서 예외 조건에 한 번 물려본 사람은 커머스에 와서도 반품 정책 쪽을 먼저 열어봅니다. 도메인은 달라도 어려운 곳의 모양이 닮아 있기 때문입니다. 그래서 저는 이걸 근속의 문제가 아니라 관찰 습관의 문제로 보고 있습니다.

요구가 아니라 제약을 줘야 안정적으로 움직입니다

사람끼리 일할 때는 암묵적 합의가 통합니다. "이건 이렇게 처리하는 게 맞지", "이 경우엔 예외야". 이게 AI랑 일하면 다 깨집니다. 그래서 기준을 밖으로 꺼내야 합니다.

결제 도메인이라면 이런 식입니다. 모든 결제는 멱등해야 하고, 실패 후 재시도할 때는 같은 트랜잭션 아이디를 쓰고, 외부 결제사가 실패하면 정해진 횟수만큼 재시도한 뒤 대체 경로로 넘기고, 특정 고객 그룹은 수동 승인을 거친다. 이게 없으면 AI는 매번 다른 선택을 합니다. 있으면 매번 같은 선택을 합니다.

같은 얘기를 요청 쪽에서 보면 이렇게 갈립니다. "이거 쿠팡처럼 만들어줘"는 요구입니다. "재고는 지역 우선으로 배치하고, VIP 고객은 항상 우선 배송하고, 반품은 조건 세 가지를 다 충족할 때만 자동 승인한다"는 제약입니다. AI는 요구보다 제약에서 훨씬 안정적으로 움직입니다.

여기에 좀 불편한 순환이 하나 있습니다. 제약을 쓰려면 이미 그 제약을 알고 있어야 합니다.

결제가 멱등해야 한다는 걸 아는 사람은 멱등하지 않아서 한 번 터져본 사람입니다. 반품 자동 승인 조건을 세 가지로 적을 수 있는 사람은 그 조건이 두 개였을 때 뚫린 걸 본 사람입니다. 그러니 "AI에게 제약을 주면 된다"는 말은 방법을 알려주는 문장이 아니라, 이미 아는 사람만 쓸 수 있는 도구라는 뜻에 더 가깝습니다.

그럼 아직 모르는 사람은 어떻게 하냐가 남습니다. 저는 이 대목에서 AI가 오히려 도움이 된다고 보는데, 답을 받는 쪽이 아니라 반례를 받는 쪽으로 씁니다. "이 조건으로 반품 자동 승인을 하면 어떤 경우에 뚫리나"라고 물으면 꽤 쓸 만한 목록이 나옵니다. 그중 우리한테 실제로 해당하는 게 뭔지는 다시 사람이 골라야 하지만, 고를 목록을 손에 쥐는 것과 백지에서 시작하는 것은 다릅니다.

그런데 여기서 한 발 더 들어가면 "정답을 정의하는 사람"이라는 표현도 조금 모자랍니다. 현실에서는 정답이 하나인 경우가 거의 없습니다. 대부분은 여러 개의 덜 나쁜 선택지 중에서 어떤 제약을 덜 깨는 쪽을 고르는 일에 가깝습니다. 비즈니스 정합성, 기술 부채, 보안과 법무 리스크, 운영 가능성, 조직이 지금 감당할 수 있는 복잡도를 동시에 봐야 합니다.

AI는 후보안을 정말 잘 만듭니다. 그런데 그 후보들 중에서 우리에게 맞는 답이 뭔지는 조직의 기억 안에서만 결정됩니다.

예를 하나 들어보겠습니다. AI가 어떤 모듈을 더 깔끔하게 리팩토링할 수 있다고 제안합니다. 기술적으로는 맞는 말입니다. 구조는 좋아지고 코드도 예뻐집니다. 그런데 저는 압니다. 이 모듈을 유지하는 팀은 지금 다른 마일스톤에 묶여 있고, 이번 분기에 구조를 크게 바꾸면 다음 달 배포에서 다른 팀과 충돌이 생기고, 게다가 이 영역은 내년 초에 통째로 다시 바뀔 가능성이 높습니다. 그러면 지금 리팩토링은 기술적으로 맞아도 조직적으로는 틀린 답입니다.

비슷한 상황은 훨씬 더 자주 있습니다. AI가 API 응답 구조를 더 깔끔하게 정리하자고 합니다. 예쁩니다. 맞는 말입니다. 그런데 이 API를 쓰는 외부 파트너 세 곳 중 한 곳은 파서를 3년째 안 건드리고 있습니다. 필드 이름 하나 바꾸면 거기가 먼저 터집니다. 이 정보는 코드에도 없고 문서에도 없습니다. 조직 안에서 오래 일한 사람이 머릿속에만 들고 있습니다.

그리고 바로 그 사람이 "안 됩니다"라고 말할 수 있어야 시스템이 지켜집니다.

문서에 없는 규칙을 기억하는 사람

모든 시스템에는 문서화되지 않은 규칙이 있습니다. 이 데이터는 이 경로로만 이동해야 한다, 이 흐름은 절대 깨면 안 된다, 이 기능은 빠르게 만드는 것보다 나중에 설명할 수 있는 게 더 중요하다, 이 사용자 경험은 건드리면 안 된다.

이런 것들은 대개 문서에 없습니다. 그리고 AI는 바로 이 지점에서 자주 그럴듯하게 틀립니다. 틀린 티도 잘 안 납니다. 코드는 돌아가고 테스트는 통과하니까요.

그래서 앞으로 남는 개발자는 추상적인 감독관 같은 이미지보다 시스템의 암묵적 규칙을 기억하고 지키는 사람에 더 가깝다고 보고 있습니다. 보안, 운영 안정성, 사용자 신뢰, 조직 안에서 오래전에 맺어진 약속 같은 게 다 여기 들어갑니다.

이 역할은 겉으로 보기엔 덜 화려합니다. 그런데 AI가 강해질수록 더 중요해집니다. AI는 표면적 정합성을 아주 빨리 맞추기 때문입니다. 그럴수록 암묵적 규칙을 붙잡는 사람이 없으면 시스템은 더 조용하게, 더 깊게 틀어집니다.

다만 이 대목은 저도 아직 정리가 안 된 부분이 있습니다. 암묵적 규칙을 기억하는 사람이 중요하다는 말은, 뒤집으면 그 사람이 병목이라는 말도 됩니다. 회사 입장에서는 한 사람 머릿속에만 있는 규칙이 그냥 리스크입니다. 그래서 그걸 꺼내서 문서로 만들라고 요구하는 게 맞습니다. 그런데 다 꺼내고 나면 그 사람의 대체 불가능성도 같이 줄어듭니다.

저는 이게 실제로 딜레마라고 보고 있습니다. 꺼내놓지 않으면 조직이 위험하고, 꺼내놓으면 본인 자리가 위험해 보입니다. 지금까지 본 건 이 둘이 생각만큼 대칭이 아니라는 쪽입니다. 규칙을 꺼내서 적어놓은 사람은 그 다음에 그 규칙이 낡았는지 판단하는 자리로 옮겨갑니다. 적어놓은 문장은 복제되는데 그 문장이 지금도 맞는지 아는 감각은 복제가 안 되기 때문입니다. 다만 이건 제 경우에 그랬다는 것이고, 조직이 그 판단 자리를 인정해주는지는 회사마다 다를 겁니다.

vibe coding이 80%에서 멈추는 게 아닙니다. 80%까지는 원래 남의 것으로도 됩니다. 남은 20%가 우리 것이고, 그 20%가 아직 사람 쪽에만 있습니다.