인사이트 · 3분 · 08.07

AI 코딩 시대의 진짜 부채는 코드가 아니라 ‘잃어버린 맥락’일 수 있습니다

loopy vibecoder

핵심 요약 (TL;DR)

AI가 코드를 빨리 만들수록 팀은 새로운 종류의 부채를 만납니다. 파일은 남아 있는데 왜 이 기능을 이렇게 만들었는지, 어떤 위험을 받아들였는지, 무엇을 확인하고 끝냈는지가 사라지는 문제입니다. 8월 5일 공개된 Evan Schwartz의 AI 코딩 전환 메모는 이런 변화 속에서 개발자가 맥락과 판단을 잃지 않는 문제를 짚습니다. 최근 갱신된 Coniunctio Intelligentiarum의 사례도 중요한 규칙을 프롬프트에만 맡기지 않고 Git·세션 훅 같은 외부 장치에 두려는 방향을 보여 줍니다.

‘코드가 돌아간다’는 말만으로 왜 부족할까요?

기능이 동작하는 순간에는 결과가 분명해 보입니다. 그러나 다음 주 다른 사람이 그 코드를 바꾸려 할 때, 입력 조건과 예외 처리의 의도까지 이해하지 못하면 작은 수정도 위험해집니다. AI가 초안을 빠르게 낼수록 사람이 놓치기 쉬운 것은 타이핑 시간이 아니라 결정의 이유입니다.

그래서 완료 기준은 배포 성공보다 조금 더 길어야 합니다. 무엇을 바꿨는지, 왜 이 방법을 골랐는지, 어떤 경로로 확인했는지를 남겨야 합니다. 긴 회의록이 아니라 기능당 다섯 줄이면 됩니다. 목표, 바뀐 범위, 포기한 대안, 검증 결과, 남은 위험입니다. 이 다섯 줄은 다음 에이전트에게 주는 프롬프트보다 사람에게 남기는 설계 기록에 가깝습니다.

규칙은 프롬프트가 아니라 어디에 두어야 할까요?

Coniunctio Intelligentiarum의 README는 ‘기억해야 할 규칙’을 모델 바깥의 Git 훅과 세션 훅으로 옮기자는 제안을 합니다. 예를 들어 비밀값 검사나 필수 테스트처럼 빼먹으면 안 되는 일은 ‘항상 해 주세요’라는 요청만으로는 충분하지 않을 수 있습니다. 사람이든 AI든 긴 작업에서는 문맥이 흐려질 수 있기 때문입니다.

하지만 자동화된 게이트를 만능 보안 장치로 착각해서는 안 됩니다. 해당 프로젝트도 잘 의도된 에이전트의 망각을 다루는 장치이지, 적대적 공격자를 막는 벽은 아니라고 한계를 밝힙니다. 이 구분이 중요합니다. 외부 검사는 실수를 줄이는 안전벨트이고, 민감 정보 접근 통제와 코드 리뷰를 대체하지는 않습니다.

작은 프로젝트에서는 어떻게 시작하면 좋을까요?

첫째, AI에게 기능 구현을 맡기기 전에 완료 조건을 사람이 세 문장으로 씁니다. 둘째, 변경 전후에 실행할 확인 명령이나 화면 경로를 정합니다. 셋째, 커밋 또는 배포 직전에 비밀값·테스트·모바일 화면처럼 놓치기 쉬운 항목을 체크리스트로 확인합니다. 이 흐름은 개발자가 아니어도 적용할 수 있습니다. 중요한 것은 모든 것을 이해하는 것이 아니라, 이해하지 못한 부분을 ‘확인 없이 통과’시키지 않는 것입니다.

AI 코딩의 경쟁력은 더 긴 프롬프트에서만 나오지 않습니다. 내 판단이 다음 작업에도 살아남고, 검증이 말이 아니라 실제 결과로 남는 과정에서 나옵니다. 속도를 얻으려다 맥락을 잃지 않는 팀이 결국 더 멀리 갑니다.

FAQ: AI가 테스트를 만들고 통과했다고 하면 끝인가요?

아닙니다. 테스트가 무엇을 확인하는지와 실제 사용자 흐름이 맞는지 별도로 봐야 합니다. 특히 결제·권한·개인정보·모바일 화면은 사람이 실제로 확인하는 단계를 남겨야 합니다.

FAQ: 문서를 길게 써야 하나요?

그럴 필요 없습니다. 다음 사람이 같은 결정을 다시 하지 않도록, 목적과 검증 결과를 짧고 구체적으로 남기는 것이 핵심입니다.

FAQ: 체크리스트가 창의성을 방해하지 않나요?

반복적으로 빠지면 큰 비용이 되는 항목만 기계적으로 확인하면 됩니다. 무엇을 만들지와 어떤 위험을 감수할지는 여전히 사람이 판단할 일입니다.