"AI가 소프트웨어 개발을 바꿨다"는 말은 자주 들리지만, 정확히 어느 단계를 가리키는지는 모호하다. 구현을 만들어내는 일, 설계를 탐색하는 일, 그리고 이 시스템이 올바른 문제를 푸는지 판단하는 일은 서로 연결돼 있으나 같지 않다. 한쪽을 자동화한다고 나머지가 저절로 해결되지는 않는다. 에이전트는 구현 작업을 더 많이 떠맡고 분석·설계·테스트를 거들 수 있지만, 무엇을 만들지와 어떤 근거가 있어야 그 결과를 받아들일지는 여전히 엔지니어의 책임으로 남는다. 일의 성격은 바뀌어도 책임 자체가 사라지는 것은 아니다. 이 글의 저자 아르만도 피콘은 이를 '코드를 찍어내는 사람을 대체한다'는 식으로 포장하는 데 거부감을 보인다. 그 표현은 개발자를 타이핑하는 존재로 축소하고, 작업 자동화를 일자리 대체 주장으로 비약시키기 때문이다. 대체를 말하려면 인상적인 데모 이상의 증거가 필요하다.
결정은 대화가 아니라 문서에
대화형 세션은 선택지를 탐색하기엔 편하지만, 아키텍처 결정을 남기는 유일한 기록처로는 취약하다. 모델의 컨텍스트는 유한하다. 긴 세션은 요약되거나 압축되고, 일부 정보만 추려 재개된다. 이 과정에서 결론은 보존돼도 그 결론을 합리적으로 만든 조건은 사라지기 쉽다. "로컬 캐시를 쓰라"는 지시와 "이 화면은 네트워크가 없어도 작동해야 하므로 로컬 캐시를 쓰라"는 지시는 전혀 다르다. 실무자라면 이 차이의 무게를 안다. Anthropic이 공개한 장시간 실행 에이전트 보고서도 컨텍스트 윈도를 넘나들 때의 연속성 문제와, 작업을 잘게 쪼개 진행 상황을 지속적 산출물로 남기는 접근을 설명하며, 압축 과정에서 지시가 불명확해질 수 있다고 전한다. 다만 이것은 특정 환경을 다룬 벤더의 엔지니어링 보고일 뿐 모든 워크플로를 비교한 보편적 결론은 아니다.
그래서 저자는 오래 가는 결정에 작고 검토 가능한 '집'을 마련하길 권한다. 가령 PROJECT_GUIDE.md 같은 파일이다. 단, 파일 이름 자체에 특별한 힘은 없다. 에이전트가 그 파일을 자동으로 읽어들인다는 보장은 없으므로, 도구가 지원하는 프로젝트 지침 기능에 연결하거나 작업에 명시적으로 포함시킨 뒤 에이전트가 그것을 어떻게 해석했는지 확인해야 한다. 마크다운으로 적어둔다고 검색과 준수가 보장되지는 않는다. 매 작업마다 모든 문서를 넣으면 컨텍스트와 비용이 늘고, 선택적으로 넣으면 입력은 줄지만 문서를 유지·검색·교정하는 데 또 다른 자원이 든다. 절감을 주장하려면 생성 시간만이 아니라 작업 전체를 측정해야 한다.
작은 단위마다 해석을 확인하라
각 증분 작업에서는 관련 파일을 건네고, 의도한 변경·제약·수용 조건을 짧게 서술하게 해 본다. 이 재서술은 오해를 일찍 잡아내는 기회다. 저자가 든 가상의 모바일 검색 화면 예시를 보자. 첫 증분의 범위는 기존 항목에 대한 로컬 검색으로 한정하고 원격 검색과 저장 방식 변경은 제외한다. 수용 조건을 미리 명시하면 한 가지 기술적 질문이 드러난다. 과연 필터링에 비동기 처리가 꼭 필요한가. 템플릿이 동시성을 기대한다는 이유만으로 끌어들일 게 아니라, 예상 데이터 크기와 응답성 요구에 비추어 판단할 문제다. 이 예시에서는 단방향 데이터 흐름, 명시적 UI 상태, 필터링 로직과 렌더링의 분리를 택해 상태 전이를 들여다보기 쉽게 만들 수 있다. 다른 시스템이라면 다른 구조가 정당화되며, 이는 목적을 가진 공학적 선택이다.
작업이 끝나면 diff를 살피고 관련 검사를 돌리며 화면을 직접 만져 본다. 범위를 로컬 검색으로 제한했는데도 에이전트가 저장 계층을 다시 썼다면, 테스트가 통과한다고 그 확장이 용인되지는 않는다. 빈 상태 화면이 멀쩡해 보여도 검색이 엉뚱한 필드를 매칭한다면 스크린샷 한 장이 정확성을 증명하지 못한다. 에이전트의 출력은 확률적이므로, 수용은 들여다볼 수 있고 가능하면 재현할 수 있는 증거에 기대야 한다.
검증은 서로 다른 질문에 답한다
로컬 검증 명령은 포매팅, 정적 분석, 컴파일, 초점을 맞춘 테스트를 돌린다. 포매터는 관례를, 컴파일러는 언어·타입 규칙을, 테스트는 선택된 조건에서의 선택된 동작을 확인한다. 그러나 어느 것도 우리가 '올바른 제품 동작'을 골랐음을 보증하지는 않는다. 통제된 검증에는 통제된 입력이 필요하다. 도구 버전, 픽스처, 실행 조건이 중요하며, 타이밍·기기·네트워크·외부 서비스가 얽힌 테스트는 불안정할 수 있다. 결정적이라고 부른다고 결정적이 되지는 않는다. 완벽히 반복 가능한 검사조차 엉뚱한 것을 검증할 수 있다. 어떤 결과가 '나오는지'만 확인하고 어떤 결과인지는 확인하지 않는 검색 테스트가 그렇다. 생성된 테스트는 생성된 구현과 똑같은 오해를 충실히 담아낼 수 있으므로, 단언문을 수용 조건과 대조하고 실패 사례를 포함한 의도적 예시를 써야 한다. 성능이 걸린다면 성공을 선언하기 전에 기기·데이터셋·시나리오·임계값으로 측정 기준을 먼저 정의해야 한다. 체감 반응 속도는 유용한 피드백이지만 지연 측정값은 아니다. 훅은 검사를 앞당겨 주지만 무엇이 그것을 촉발하고 우회 가능한지에 따라 범위가 달라진다. 로컬 훅은 서버 측 검사나 저장소 보호 같은 원격 강제 정책과 동일하지 않다.
문서의 비례성과 한계
저자는 작은 변경 하나를 보려고 긴 생성 문서 체인을 먼저 요구하는 방식에 회의적이다. 문서마다 검토·조정·갱신 부담이 따르고, 글을 싸게 생성한다고 그것을 이해하는 비용까지 싸지지는 않기 때문이다. 이는 비례성과 피드백 주기에 대한 비판이다. 스펙 주도 개발에도 여러 갈래가 있다. Birgitta Böckeler의 2025년 Kiro·spec-kit·Tessl 분석은 스펙을 먼저 쓰는 방식, 유지보수 중에도 보존하는 방식, 그것을 일차 원천으로 삼는 방식을 구분한다. François Zaninotto는 문서 과잉 워크플로의 검토 부담과 지시 준수 문제를 사례로 제기한다. 이런 사례들은 조사의 출발점이 되지만, 스펙이 일반적으로 나쁜 결과를 낳는다고 단정하지는 못한다. 반대로 안전 제약, 규제 대상 작업, 공개 인터페이스, 마이그레이션 호환성, 팀 간 협업 같은 영역에서는 더 강한 스펙이 가치를 지닌다. 문서의 쓸모를 가르는 기준은 실용적이다. 이 문서가 어떤 결정·구현·검증을 뒷받침하며 누가 유지할 것인가. 호환성 제약을 설명하는 몇 쪽은 남기되, 결정을 바꾸지도 평가를 돕지도 않는 반복 문장은 지운다.
결국 저자가 제안하는 순환은 단순하다. 다음 동작을 정의하고, 필요한 컨텍스트를 공급하고, 해석을 확인하고, 변경을 들여다보고, 증거를 모아 수용 여부를 결정한다. 결정이 바뀌면 지속 지침을 갱신하고, 검토가 감당되지 않으면 에이전트에게 더 만들라고 하기 전에 증분을 줄이거나 검사를 개선한다. 이 접근은 엔지니어의 이해도, 증거의 질, 지침 유지 비용에 의존한다는 한계가 있으며, 통제된 연구나 입증된 생산성 향상이 아니라 하나의 작업 가설이다. 생성 시간만이 아니라 검토·재작업·결함·유지보수까지 셈해야 그런 향상을 말할 수 있다. 무엇을 요청했고 무엇이 바뀌었으며 왜 그 증거가 수용을 뒷받침하는지 설명할 수 있을 때, 저자는 비로소 더 많은 작업을 에이전트에 맡긴다. 대화가 끝난 뒤에도 당신의 워크플로에서 어떤 결정이 눈에 보이는 형태로 남는지, 그리고 에이전트가 그것을 지켰다고 말해 주는 증거는 무엇인지 물어볼 때다.