AI 리팩토링은 왜 80%에서 멈추나?

네 번째 프로젝트에서 적용을 중단했다. 원인은 AI의 한계가 아니라 내가 인지한 설계 깊이였다.

시작은 단순한 궁금증이었다. 리팩토링을 AI에게 맡기면 얼마나 빨라지는지 보고 싶었다. 학습 관리 시스템 하나를 열어놓고 "코드 재설계 해줘" 한 줄로 시작했다. 초반 80%까지는 진짜 빨랐다. 요구사항 몇 줄에 그럴듯한 코드가 나오고, 빌드가 통과하고, 화면이 떴다. 남은 20%에 들어서자 확신이 한쪽으로만 몰렸다. AI는 원인을 지목하면서 점점 확신이 세졌고, 나는 내가 뭘 시켰는지에 대한 확신을 잃었다.

이 글에 나오는 프로젝트 중 뒤쪽 두 개는 회사 일이라 이름과 도메인 필드, 내부 명령어를 전부 뺐다. 구조가 어떤 층으로 쌓여 있었고 어디서 무너졌는지만 쓴다.

남은 20%에서 확신이 한쪽으로만 몰렸다

수정 단계에 들어가고 나서는 같은 자리를 계속 돌았다.

이슈가 하나 뜬다. 프롬프트를 바꿔서 다시 시킨다. 안 풀린다. AI는 원인을 하나 지목하는데, 그 지목이 틀렸다. 틀렸는데 문장은 아주 단호하다. 나는 그 단호함에 한 번 끌려간다. 시킨 대로 고친다. 그러면 다른 데가 깨진다. 깨진 데를 고치라고 하면 처음 고쳤던 데가 다시 돌아온다.

틀린 지목에는 특징이 있었다. 원인을 하나 짚어주는데, 근거를 물으면 근거를 대는 대신 다른 원인을 짚는다. 그러면서 앞의 지목을 취소한다는 말은 안 한다. 두 번째 지목도 첫 번째만큼 단호하다. 나중에 셋을 나란히 놓고 보면 서로 양립할 수 없는 진단인데, 대화 흐름 안에서는 그게 안 보인다. 각각이 그 순간의 질문에는 잘 맞는 답이었기 때문이다.

이 루프에서 제일 지치는 건 진전이 없다는 게 아니라 진전이 있는지 없는지 판단할 기준이 나한테 없다는 쪽이었다. 코드가 늘어나는 건 보이는데, 그 코드가 원래 내가 그리려던 구조에 가까워지는 중인지 멀어지는 중인지 말할 수가 없었다. 비슷한 유틸 함수가 두 군데 세 군데 생겨나는데도 그게 문제인지 아닌지 판단할 근거가 없었다. 그냥 "좀 지저분해졌네" 정도의 감각뿐이었다.

그래서 프롬프트에 공을 들였다. 역할을 부여하고, 제약을 붙이고, 예시를 넣고, 출력 형식을 정하고. 다들 그렇게 한다. 나도 그렇게 했다.

효과는 있었다. 단기 맥락에서는 확실히 좋아졌다. 한 턴 안에서 원하는 답을 끌어내는 확률은 올라갔다. 그런데 장기 구조와 일관성, 책임 경계 쪽으로 가면 프롬프트가 붙잡아주는 게 거의 없었다. 세션이 길어지면 앞에서 합의한 게 슬금슬금 흐려지고, 새 세션을 열면 처음부터 다시였다.

여기서 질문을 바꿨다. AI로부터 원하는 답을 끌어내는 방향이 아니라, AI가 내 표현에 휘둘리지 않고 미리 정의된 기준을 유지하게 만드는 방향으로. 그때는 이게 얼마나 큰 방향 전환인지 몰랐다. 그냥 프롬프트 기법 하나를 더 배운 정도로 생각했다.

문서를 만들었다고 설계한 게 아니었다

두 번째 시도에서는 문서부터 만들었다. 저장소에 docs/ 디렉터리를 파고, 아키텍처 개요와 모듈 설명과 데이터 흐름을 정리했다. 이번엔 기준이 있으니 다르겠지 싶었다.

초반 인상은 좋았다. AI가 문서를 읽고 대답하는 게 눈에 보였다. 모듈 이름을 정확히 부르고, 흐름 방향을 언급했다.

그런데 버그를 하나 물고 들어가자마자 이상해졌다. 버그마다 AI가 큰 구조 변경을 제안했다. 서비스 레이어를 하나 더 두자, 이 훅을 분리하자, 상태 관리 방식을 바꾸자. 제안 하나하나는 나쁘지 않았다. 문제는 그게 매번 다른 방향이었다는 것이다. 어제는 A로 쪼개자고 했다가 오늘은 B로 합치자고 한다. 둘 다 문서에는 위배되지 않는다. 문서에 그 층위의 얘기가 아예 없었으니까.

유틸과 훅도 계속 중복됐다. 같은 일을 하는 함수가 두 군데 생기고, 며칠 뒤에 세 번째가 생겼다. 문서에 "이 모듈이 무엇을 하는가"는 적혀 있었지만 "이 모듈이 무엇을 하지 않는가"는 없었다. 책임의 바깥 경계가 비어 있으면 AI는 그 빈자리를 자기 판단으로 채운다. 그리고 채울 때마다 다르게 채운다.

이 지점에서 알게 된 게 있다. 내가 만든 문서는 산출물이었지 기준선이 아니었다. 코드를 쓰고 나서 "우리 이렇게 만들었습니다"를 적어둔 결과 보고서였다. 기준선은 반대 방향이다. 코드보다 먼저 존재하면서, 코드가 그 문장을 위반했는지 아닌지를 판정할 수 있어야 기준선이다.

문서를 만드는 행위 자체는 설계가 아니었다. 설계는 기준을 세우고, 그 기준이 흔들리지 않는지 계속 검증하고 보정하는 과정이었다. 그리고 그 기준은 코드가 생기기 전에 있어야 했다.

성공했는데 나 없이는 재현이 안 됐다

세 번째는 방식을 또 바꿨다. AI를 하나만 쓰지 않고 여러 개를 동시에 붙였다. 학습 데이터가 다르면 보는 각도도 다를 테니, 같은 설계안을 여러 모델에 물어보고 답이 갈리는 자리를 찾아보자는 생각이었다.

이건 됐다. 결제 흐름까지 포함해서 실제로 동작하는 기능을 완성했다. AI가 내 의도를 반영하는 정확도도 눈에 띄게 올라갔다. 답이 갈리는 자리가 나오면 거기가 대체로 내가 대충 넘어간 자리였다. 모델끼리의 불일치를 오류로 보지 않고 설계에 빈틈이 있다는 신호로 읽기 시작한 게 이때다.

기분이 좋았다. 방법을 찾았다고 생각했다.

그런데 이걸 다른 사람에게 넘기려는 순간 걸렸다. 같은 문서, 같은 모델 조합, 같은 프롬프트를 줘도 같은 결과가 안 나왔다. 차이는 도메인 이해였다. 모델 셋이 서로 다른 답을 내놨을 때 어느 쪽이 이 도메인에서 말이 되는지를 고르는 판단이 전부 내 머릿속에 있었다. 문서에는 그 판단의 결과만 있고 판단의 근거는 없었다.

내 머릿속에 있던 게 뭐였는지 나중에 짚어봤다. 대단한 지식은 아니었다. 이 값은 예외가 나면 조용히 넘어가면 안 되고 사용자에게 보여야 한다든가, 이 항목은 순서가 바뀌면 사람 눈에는 티가 안 나지만 뒤에서 집계가 틀어진다든가, 이 흐름은 두 번 호출돼도 결과가 같아야 한다든가 하는 것들이다. 전부 몇 년 동안 이 도메인을 만지면서 몸에 붙은 감각이라 문서에 적을 생각을 못 했다. 적을 생각을 못 한 이유는 당연해서다. 당연한 건 안 적는다.

그런데 모델에게는 당연하지 않다. 모델은 코드를 읽고 그 코드가 하는 일을 정확히 요약해준다. 그 코드가 해서는 안 되는 일은 코드에 안 적혀 있으니 읽어낼 방법이 없다. 세 모델이 서로 다른 답을 내놓았을 때 내가 한 일은 그 당연한 것들을 기준으로 하나를 고르는 일이었고, 그 기준은 어디에도 없었다.

성공은 했는데 체계는 아니었다. 병목이 설계자 한 사람이라는 건, 그 사람이 자리를 비우면 같은 방법이 같은 결과를 못 낸다는 뜻이다. 재현이 안 되면 그건 방법이 아니라 재주다.

네 번째에서 적용을 중단했다

앞에서 성공했으니 이번엔 범위를 크게 잡았다. 크로스플랫폼 데스크톱 애플리케이션 하나를 통째로 리팩토링하는 일이었다.

구조가 그전 것들과 급이 달랐다. UI 계층은 스크립트 언어로, 코어 로직은 시스템 언어로 짜여 있고, 그 사이에 프로세스 경계가 있었다. 화면에서 출발한 요청이 렌더러를 지나 프로세스 간 메시지로 변환되고, 메인 프로세스를 거쳐 언어 경계를 넘어 네이티브 코어까지 내려간다. 그리고 결과가 그 길을 거꾸로 올라온다. 여기에 플랫폼별 분기까지 얹혀 있었다.

증상은 항상 UI에서 먼저 보였다. 화면에 이상한 값이 뜬다. 거기서부터 아래로 내려가면서 원인을 찾아야 하는데, 각 층마다 AI에게 물어보면 각 층에서는 다 말이 되는 답이 나왔다. 렌더러 쪽 코드를 보여주면 렌더러 관점에서 타당한 진단을 한다. 메시지 규약을 보여주면 그 규약 안에서 타당한 진단을 한다. 코어 코드를 보여주면 또 거기서 타당하다.

문제는 어느 한 층의 오류가 아니었다. 각 층의 판단을 하나로 묶는 설계가 없다는 것이었다.

경계에서 무슨 일이 벌어지는지를 뒤늦게 알았다. 값이 층을 넘어갈 때마다 형식이 한 번씩 바뀐다. 넘어간 쪽은 그 형식을 전제로 삼고 자기 로직을 짠다. 그런데 그 전제는 코드 어디에도 적혀 있지 않다. 넘겨준 쪽 코드를 읽으면 "이렇게 보낸다"만 있고, 받는 쪽 코드를 읽으면 "이렇게 온다고 치고 쓴다"만 있다. 둘이 어긋나도 컴파일은 통과한다. 경계를 넘는 순간 타입 정보가 한 번 뭉개지기 때문이다.

그러니 한쪽만 보여주고 진단을 시키면 AI는 그쪽의 전제를 그대로 믿는다. 믿을 수밖에 없다. 반대쪽 전제가 어디에도 안 적혀 있으니까. 나는 층마다 따로 물어보면서 사실은 매번 반쪽짜리 맥락만 넘기고 있었다.

그래서 문서를 더 썼다. 그런데 다중 언어와 프로세스 경계가 얽힌 구간에서는 AI가 문서와 코드를 대조하는 방식이 얕았다. 이름이 맞고 타입 이름이 맞으면 일관성이 있다고 판정했다. 실제로 그 값이 경계를 넘어갈 때 어떻게 변환되는지, 소유권이 어디로 넘어가는지, 예외가 어느 쪽에서 잡히는지는 문서에도 없고 코드에서도 확인하지 않았다. 겉보기 일관성만 맞춰졌다.

이 감각은 AI가 쓴 브라우저 300만 줄을 열어봤을 때 다시 만났다. 파일 수와 줄 수는 압도적인데 테스트가 컴파일조차 되지 않던 그 상태와, 문서와 코드의 이름만 맞아 있던 이 상태는 같은 종류의 실패다. 표면은 정합한데 표면 아래에서 계약이 지켜지지 않는다.

설계 문서와 실제 동작이 충돌하기 시작했고, 얕은 설계 위에 구현이 쌓이니 모순이 아래로 갈수록 커졌다. 진행할수록 정리되는 게 아니라 진행할수록 벌어졌다.

결국 적용을 중단했다.

한동안 원인을 AI 쪽에서 찾았다. 컨텍스트가 짧아서, 모델이 시스템 레벨에 약해서, 언어 경계를 못 봐서. 다 그럴듯했다. 그런데 하나씩 짚어보니 내가 AI에게 준 문서에 그 층위의 기준이 애초에 없었다. 경계를 넘어가는 값의 계약을 내가 문장으로 못 쓰고 있었다.

AI의 한계가 아니라 내가 인지한 설계 깊이가 부족했다. 이 문장을 인정하는 데 시간이 좀 걸렸다.

AI는 설계를 줄여주지 않는다

네 번의 시도를 늘어놓고 보니 공통점이 하나 보였다. 순서가 전부 같았다.

요구사항을 정제하지 않은 채로 시작한다. 구현을 먼저 생성한다. 나온 결과를 보고 리뷰한다. 실행하다가 문제를 인지한다. 사후에 패치한다.

원래 배운 순서는 이게 아니었다. 요구사항을 분석하고, 경계와 책임을 고정하는 설계를 하고, 구현은 그 위에서 조립하고, 테스트로 확인한다. 사전에 막는 쪽이다.

AI를 쓰기 시작하면서 나는 앞의 두 단계를 통째로 건너뛰고 있었다. 건너뛴 이유는 AI가 빨라서다. 요구사항을 정리하는 데 걸리는 시간보다 일단 시켜보고 결과를 보는 게 빨랐다. 실제로 80%까지는 그게 맞았다.

AI는 단기 목표에 최적화된다. 지금 이 요청을 만족시키는 방향으로 움직이고, 그 과정에서 범위 밖을 건드리는 데 거리낌이 없다. 그러니 경계를 누가 잡아주지 않으면 계속 밖으로 나간다.

문제는 코드가 아니었다. 설계를 미룬 채 시작한 결과가 만든 사후 대응 루프였다. AI는 설계를 줄여주지 않는다. 우리가 설계를 건너뛰고 있을 뿐이다.

기준선을 문서로 고정했다

그래서 체계를 만들기 시작했다. 처음부터 완성된 문서를 쓴 게 아니라, 빈틈이 나올 때마다 그 자리를 문장으로 메우는 방식으로 굴렸다. 여러 모델에게 같은 설계안을 물어서 답이 갈리는 지점을 찾고, 그 지점을 해소하는 문장을 문서에 박고, 그다음에 구현으로 내려가는 사이클이다.

기준 문서는 네 종류로 정리됐다.

전체 레이어 구조와 데이터 흐름 방향, 외부 의존성을 담는 아키텍처 개요가 하나다. 여기서 흐름은 단방향으로 못 박았다. 역방향 참조는 금지다.

모듈마다 책임과 책임 바깥을 같이 적는 문서가 둘째다. "이 모듈이 하는 것"만 적으면 두 번째 시도의 실패가 그대로 반복된다. 하지 않는 것을 같은 무게로 적어야 AI가 빈자리를 자기 판단으로 채우지 않는다.

셋째가 불변 조건 목록이다. 코드 어디에서나 항상 참이어야 하는 조건인데, 위반하면 버그가 아니라 설계가 무너진 것으로 판정한다. 이걸 세 계층으로 나눴다. 프로젝트 전체에서 참인 전역 조건, 모듈 경계 안에서 참인 모듈 조건, 입출력 계약에 해당하는 인터페이스 조건. 예를 들어 "코어 모듈은 특정 런타임에 묶이는 바인딩을 임포트하지 않는다"는 전역 조건이고, "화면 계층은 저장소를 직접 호출하지 않는다"는 모듈 조건이고, "경계를 넘는 바이트 값은 어댑터에서만 변환한다"는 인터페이스 조건이다. 각각에 번호를 붙여서 프롬프트와 리뷰에서 번호로 부른다.

넷째가 결정 기록이다. 구조를 바꾼 결정마다 한 장을 쓰는데, 무엇을 골랐는지보다 무엇을 기각했고 왜 기각했는지가 본문이다. 여러 모델이 내놓은 대안 목록이 여기 쌓인다. 이게 없으면 같은 대안이 석 달 뒤에 다시 올라오고, 그때는 왜 안 했는지를 아무도 기억 못 한다. 영향 범위에 어떤 불변 조건이 바뀌는지를 반드시 적게 했고, 그게 비면 등록을 안 받는다.

네 문서가 하나의 기준으로 묶여야 하는 이유는 검증 때문이다. 같은 정보가 두 문서에 있으면 둘이 어긋나는 순간부터 같은 질문에 다른 답이 나온다. 모델을 여러 개 붙여서 교차 검증하는 방식은 기준이 하나일 때만 성립한다. 기준이 갈라져 있으면 교차 검증이 아니라 그냥 서로 다른 이야기를 듣는 것이다.

검증을 어디까지 자동화할 수 있는지도 층마다 달랐다. 코어 쪽은 CI 스크립트로 완전 자동화가 됐다. 바인딩 의존성이 들어왔는지, 금지한 바이트 타입을 쓰는지, 이벤트 경계에 구현체가 섞였는지를 기계가 본다. 통과 못 하면 병합이 막힌다. 타입 계층은 순환 의존성과 임포트 방향 정도가 린트 규칙으로 잡히니 부분 자동화다. 프로세스 경계와 화면 계층은 지금도 수동이다. 리뷰 체크리스트로 본다.

자동화가 안 되는 영역을 자동화된 척하지 않는 게 중요했다. 자동으로 잡힌다고 믿는 순간 아무도 안 본다.

여기에 하나를 더 붙였다. 코드 생성을 멈추고 문서를 먼저 보라는 신호 목록이다. 같은 유틸 함수가 두 군데 이상에서 다시 정의되면 모듈 책임이 무너지는 중이다. 모듈끼리 직접 참조하는 게 늘면 계층 조건이 이미 깨지기 시작한 것이다. 버그를 잡을 때마다 구조를 바꾸자는 제안이 돌아오면 기준 문서가 모델에게 전달되지 않고 있다는 뜻이다. 여러 모델에게 물었을 때 같은 자리에서 계속 답이 갈리면 그 영역의 불변 조건이 아직 없는 것이다. 문서와 실제 동작이 충돌하면 문서가 다시 산출물 취급을 받고 있는 것이고, 그때는 코드를 문서에 맞추는 쪽으로 되돌린다. 이 중 셋이 동시에 뜨면 그날 구현은 접는다.

이 중에서는 문서와 실제 동작이 충돌하는 신호에 제일 자주 걸린다. 문서를 기준선으로 선언해두는 것과 실제로 기준선으로 쓰는 것 사이의 거리가 생각보다 멀었다.

효과는 일관성 쪽에서 먼저 나타났다. 변수 이름과 채널 이름과 도메인 규칙이 문서 기준으로 수렴했고, 중복 유틸이 눈에 띄게 줄었다. 여기서 정직하게 적어두면, 줄었다는 걸 숫자로 재지는 않았다. 중복 함수 개수를 이전과 이후로 세어본 적이 없다. 체감이다. 숫자로 말할 수 있는 건 CI가 막아준 병합 건수 정도인데 그건 다른 이야기다.

숫자보다 인상 깊었던 건 실패 신호가 나타나는 자리가 옮겨졌다는 점이다. 예전에는 코드가 깨지고 나서 알았다. 이제는 문서를 고치려는데 어디를 고쳐야 할지 모르겠는 순간에 먼저 걸린다. 그 순간이 설계에 빈틈이 있다는 신호다.

요청 문장을 바꿨다

체계보다 일상에서 더 크게 바뀐 건 내가 AI에게 던지는 문장이다.

안 쓰기로 한 문장들이 있다. "이 코드 리팩토링해줘"는 범위가 무제한이라 AI가 구조를 마음대로 바꾼다. 첫 번째 시도가 바로 이 문장에서 시작했다. "구조 개선해줘"는 설계 의도 없이 아키텍처를 재설계하게 만든다. "더 좋게 만들어줘"에서 '좋다'의 기준은 우리 팀 기준이 아니라 모델이 학습한 평균이다. "전체 파일 다시 써줘"는 범위 밖 변경이 섞여 들어올 확률이 제일 높다. "이거 안 쓰는 것 같은데 지워줘"는 제일 위험하다. 호출되지 않는 것처럼 보이는 초기화 코드나 지연 실행 코드를 지워버린 적이 있다.

대신 요청 전에 네 가지를 채운다. 관련 기준 문서를 붙이고, 변경해도 되는 파일과 함수를 명시하고, 건드리면 안 되는 계층과 인터페이스와 불변 조건을 명시하고, 구현이 끝나면 불변 조건 위반 여부를 스스로 점검해서 보고하게 한다.

지금 쓰는 요청 틀은 이렇게 생겼다.

## 설계 컨텍스트
[해당 모듈 책임 문서 또는 아키텍처 개요 붙여넣기]

## 전역 불변 조건
- INV-G001: 데이터 흐름 단방향. 역방향 참조 금지
- INV-G002: 순환 의존성 금지

## 모듈 불변 조건: [모듈명]
- INV-[번호]: [내용]

## 작업 범위
변경 허용: [파일/함수]
변경 금지: [계층/인터페이스/불변 조건]

## 요청
[동사형 한 문장]

## 완료 후 검토
위 조건을 위반하는 부분이 있으면 지적하고 수정 제안만 해.
구조 변경이 필요하다고 판단되면 직접 바꾸지 말고 결정 기록이 필요하다고 알려줘.

처음엔 이걸 매번 붙이는 게 번거로웠다. "리팩토링해줘" 일곱 글자로 되던 일이 스무 줄이 됐으니까. 그런데 저 스무 줄을 채우다가 요청을 취소한 적이 여러 번이다. 변경 금지 영역을 적으려는데 뭘 적어야 할지 모르겠으면, 그건 아직 시킬 준비가 안 된 것이다. 요청 틀이 필터 역할을 했다.

마지막 항목이 생각보다 셌다. "위 조건을 위반하는 부분이 있으면 지적하고 수정 제안만 해라. 구조 변경이 필요하다고 판단되면 직접 바꾸지 말고 결정 기록이 필요하다고 알려라." 이 두 문장을 붙이면 AI가 자기 판단으로 구조를 건드리는 빈도가 확 떨어진다. 생성보다 검증에 쓸 때 훨씬 안정적이라는 건 여기서 확인했다. 만들라고 시키면 그럴듯한 걸 만들지만, 이미 있는 구조가 기준과 어긋나는지 보라고 시키면 꽤 정확하게 짚는다.

같은 원리를 게임 저장소에서 한 번 더 써본 적이 있다. 규칙 문서를 에이전트가 먼저 읽고 나서 코드를 쓰게 만든 구성인데, 거기서도 효과가 난 건 지시문을 잘 써서가 아니라 참조할 기준이 한 군데로 고정돼 있어서였다.

프롬프트는 지시문이 아니라 기준 문서를 참조하는 수단이다. 이 문장 하나로 내 작업 방식의 절반이 설명된다.

무게중심이 옮겨갔다

AI에게 설계를 맡기는 건, 코드는 아주 잘 짜지만 이 시스템을 처음 보고 도메인을 모르는 고급 개발자에게 설계를 맡기는 것과 같은 위험이다. 실력이 없어서가 아니다. 이 도메인에서 무엇이 지켜져야 하는지를 모르기 때문이다.

복잡도가 낮으면 그냥 시켜도 된다. 단일 레이어, 단일 언어, 독립 모듈이면 범위만 말해주면 충분하다. 문제는 임계점이다. 다중 언어와 플랫폼 경계가 얽히는 지점부터는 기준선과 경계와 단일 기준 문서 없이는 실패한다. 그 지점에서 '코드 생성 능력'은 해법이 아니다.

그래서 개발자가 사라지는 흐름이라고는 생각하지 않는다. 무게중심이 구현자에서 설계자로 옮겨가는 과정에 가깝다. 여기서 말하는 설계자는 구조를 그리는 사람이 아니라 그 구조의 결과에 책임을 지는 자리다. AI는 구현과 검증을 확장해주지만 책임의 주체가 될 수는 없다. 커밋한 사람이 진다.

넉 달 걸려 배운 걸 이틀에 쓴 이야기를 따로 적은 적이 있는데, 거기서 이틀을 만든 건 도구가 아니라 넉 달 동안 만든 순서였다. 이 글도 결국 같은 이야기다. 순서를 만드는 일이 남고, 그 순서를 문장으로 고정할 수 있느냐가 재현 가능한지를 가른다.

한 가지 더 붙이자면, 이 체계도 고정된 게 아니다. 모델이 한 세대 올라갈 때마다 내가 붙여둔 규칙 중 몇 개는 필요 없어지고 몇 개는 새로 필요해졌다. 예전 모델이 자주 저지르던 실수를 막으려고 넣은 문장이 지금은 잔소리로만 남아 컨텍스트를 먹는 경우가 있다. 반대로 예전엔 문제가 아니었던 자리가 새로 생기기도 한다. 기준선을 만드는 일과 그 기준선을 갱신하는 일은 별개의 작업이고, 후자를 안 하면 문서가 다시 산출물로 돌아간다.

발표하려고 정리한 슬라이드 파일이 내 노트북에 1월 20일자로 찍혀 있고, 그걸 문서로 다시 쓴 파일이 3월 1일자다. 그때 이 얘기를 꺼냈을 때 반응은 미지근했다. 생산성 지표로 말이 안 됐기 때문이라고 생각한다. 설계를 먼저 하자는 말은 당장 느려지자는 말로 들린다.

반년쯤 지난 지금, 커뮤니티에서 같은 이야기가 돌기 시작했다. 기분이 묘하다. 내가 먼저 봤다는 얘기를 하려는 게 아니다. 하루에 열여덟 시간씩 이걸 붙들고 있으면 남들보다 몇 달 먼저 벽에 부딪히는 것뿐이고, 그건 통찰이 아니라 노출 시간이다. 다만 그때 공감을 못 받은 게 서운했던 건 사실이다.

지금 같은 자리에 서 있다면 갈리는 건 하나인 것 같다. AI가 만든 코드가 우리 프로젝트의 기준을 위반했는지 아닌지를 문서 한 곳을 열어서 판정할 수 있느냐다. 그게 없으면 프롬프트를 아무리 다듬어도 같은 자리에서 멈춘다고 보고 있다.