Imprint Engineering이 검증 루프로 AI 개발 과정을 개선한다

Imprint Engineering은 AI가 소프트웨어를 수정할 때 검증 과정을 문서로 남기고, 그 기록을 다음 개선에 활용하는 루프를 도입했다. 이 방식은 코드 검증을 빠뜨리지 않도록 하는 동시에 자동화 도구가 어려움을 겪는 지점을 찾아내는 데 초점을 둔다.

검증 패턴의 목적

Imprint Engineering은 small-change 패턴을 도입한 뒤 개발 과정을 개선하기 위해 검증 루프를 구현하고 있다. 이 패턴은 계정 @poteto의 pstack을 통해 널리 알려졌으며, 니코 마차키스(Niko Matsakis)의 correctness ratchet에 관한 글 등에서도 비슷한 아이디어를 찾을 수 있다.

검증 패턴은 코드베이스를 검사하는 특정 도구나 메커니즘을 뜻하지 않는다. 테스트나 린터가 이미 있는데 왜 검증이 필요한지 묻는 팀도 있지만, 이 글은 검증 패턴을 원하는 결과로 작업 과정을 이끄는 chain-of-thought 패턴에 더 가깝다고 설명한다.

예를 들어 모든 풀 리퀘스트는 자동화 도구가 변경 사항을 검증하기 위해 수행한 단계와 검증하지 못한 항목을 verifications/{pr_num}.md 파일에 기록해야 한다. 자동화 도구가 이미 검증을 했을 수도 있지만, 기록을 요구하면 실제 수행 여부를 확인할 수 있다. Imprint Engineering은 기본 린트를 실행하지 않은 채 CI/CD로 넘어간 풀 리퀘스트를 본 경험을 들어, 검증 기록이 수행 여부를 분명하게 만든다고 설명한다.

이 기록은 자동화 도구가 검증에 어려움을 겪는 부분을 지속적으로 보여준다. Imprint Engineering은 이런 문제 목록을 자동화 도구가 더 안정적으로 작업하도록 개선할 지침으로 삼는다.

검증 루프와 유지 관리

Imprint Engineering의 검증 루프는 다음과 같이 진행된다.

• 로그에 나타난 새 오류처럼 해결이 필요한 문제를 구현한다. 이 문제는 자동화 시스템이 찾아낼 수도 있다.
• 자동화 도구가 로컬에서 변경 사항을 검증한 뒤 풀 리퀘스트를 만든다. verifications/{pr}.md 파일이 있어야 풀 리퀘스트를 초안 상태에서 검토 준비 상태로 바꿀 수 있다.
• 모든 풀 리퀘스트를 자동으로 검토하는 ai-code-review 도구를 통해 피드백을 받는다. 필요하면 사람의 검토도 더한다.
• 피드백을 반영하거나 거부한다. 품질이 낮은 피드백은 풀 리퀘스트 댓글에서 /dismiss {reason} 형식으로 명시적으로 기각한다.

팀은 이 과정을 매일 이어가며 시스템도 관리한다. pstack의 /maintain-verification-skill 기능을 사용해 변경 사항과 검증 과정에서 발견된 문제를 바탕으로 기능 맵과 도구를 갱신하고, 검토용 풀 리퀘스트를 자동 생성한다. 검증 기록에서 부족한 부분을 찾아 개선 과제를 만들고, ai-code-review가 제안한 피드백 중 반영되거나 거부된 항목을 검토해 지침도 다듬는다.

Imprint Engineering에 따르면 이 과정에서 프런트엔드, 백엔드, 데이터, 네이티브 등 주요 코드 영역마다 보통 검토할 풀 리퀘스트 4~6개가 생성된다. 회사는 이를 통해 잠자는 동안에도 코드베이스의 정확성을 개선하고 있다고 설명한다.

CI/CD 문제를 위한 feedback 도구

검증 루프만으로는 CI/CD와 테스트 패턴 자체의 문제를 모두 찾기 어렵다. 이를 보완하기 위해 Imprint Engineering은 테디 라이커(Teddy Riker)가 Designing for Agents에서 설명한 feedback 도구 패턴을 구현했다. 회사는 이 도구가 특정 풀 리퀘스트의 검증을 넘어 CI/CD와 자동화 도구의 실패 지점을 찾는 데 효과적이었다고 전한다.

feedback과 검증 기록은 서로 대체하는 방식이 아니라 보완 관계다. 예를 들어 컨테이너 실행기가 작업을 끝내기 전에 충돌하면 feedback 도구는 문제를 보고할 수 있지만, 검증 파일은 아예 생성되지 않을 수 있다.

중앙화와 탐색 사이의 선택

AI 도입 과정에는 새로운 방법을 각자 시도해 가능성을 넓히는 ‘탐색’과, 절차를 중앙화해 모두의 도구와 검토 수준을 끌어올리는 ‘활용’ 사이의 선택이 있다. 탐색은 성과의 상한을 높일 수 있고, 중앙화는 전반적인 수준을 끌어올릴 수 있다는 설명이다.

다만 팀이나 개인의 선호에 맞춘 지침을 지나치게 늘리면 코드베이스 전체의 일관성이 떨어질 수 있다. Imprint Engineering은 서로 어긋나는 지침을 ‘컨텍스트 오염’으로 보고, 같은 주제에 대한 중복 지침을 없애 일관된 방향을 유지하려 한다.

현재 회사는 저장소별로 중앙화된 과정을 운영하며, 검증 패턴을 바탕으로 코드 영역마다 계속 개선되는 지침 자료를 구축하고 있다. 이 방식이 잘 작동한다고 보면서도 중앙화의 범위를 넓히는 데 대한 회의에는 일리가 있다고 인정한다. 주로 기존 방식을 활용하더라도 새로운 방법을 계속 탐색해야 하며, 2027년 AI 보조 개발의 최선의 기법은 아직 대부분 알려지지 않은 아이디어에서 나올 수 있다고 본다.