검증 결과를 읽을 때 통과한 항목은 쉽게 눈에 들어옵니다. 반대로 실행하지 못한 확인은 짧은 보고서에서 사라지기 쉽습니다. 그런데 다음 작업을 정하는 데에는 그 빈칸이 더 중요할 수도 있습니다. AI가 만든 변경을 검토한다면, 성공한 검사 목록 옆에 아직 확인하지 못한 동작과 이유를 함께 남겨 보면 좋겠습니다. 완료 표시를 늘리기보다 다음 판단의 재료를 남기는 것입니다.
Will Larson은 2026년 10월 30일 공개한 글에서 Imprint 엔지니어링의 검증 패턴을 설명합니다. 각 PR에 수행한 검증과 수행하지 못한 검증을 적은 파일을 남기고, 그 기록을 다음 도구 개선에 활용한다는 내용입니다. 이는 한 조직의 운영 경험이며 독립적으로 확인한 생산성 효과는 아닙니다. 나는 보고서의 빈칸을 다음 작업으로 연결하는 부분을 참고하고 싶습니다.
참고 원문: Will Larson의 관련 원문
확인하지 못한 일을 한 문장으로 쓰기
가상의 검색 화면을 고치는 작업을 생각해 보겠습니다. 검색어가 없을 때 목록을 보여 주는 동작을 수정했고, 자동 검사 몇 개는 통과했다고 가정합니다. 하지만 실제 모바일 화면에서는 확인하지 못했습니다. 보고서에 ‘테스트 통과’만 적으면 이 조건이 보이지 않습니다. 다음 사람이 어디까지 안심해도 되는지 알기 어렵습니다.
조금 더 구체적으로는 이렇게 적어 볼 수 있습니다. ‘빈 검색어의 반환값은 자동 검사로 확인했다. 모바일 화면의 줄바꿈과 조작은 해당 환경에 접근할 수 없어 확인하지 못했다.’ 이 문장은 완성된 제품의 상태를 판정하지 않습니다. 확인한 사실과 남은 질문을 나란히 놓습니다. 수행하지 못한 일을 수행한 것처럼 바꾸지 않는 것이 출발점입니다.
이유를 적을 때에는 단순한 ‘환경 문제’에서 한 단계 더 나아가면 좋겠습니다. 기기가 없는지, 로그인이 필요한지, 시험 자료가 준비되지 않았는지에 따라 다음 행동이 달라집니다. 다만 보고서를 자세히 쓰겠다고 계정의 비밀정보나 비공개 자료를 넣을 필요는 없습니다. 필요한 접근의 종류와 부족한 조건만으로도 다음 결정을 도울 수 있습니다.
빈칸마다 다음 확인의 모양 붙이기
확인하지 못한 항목이 많으면 보고서가 미완료 목록으로만 보일 수 있습니다. 그때는 각각에 다음 확인을 붙여 봅니다. 예시의 모바일 화면이라면 정해 둔 너비에서 검색어를 지우고 목록과 버튼이 유지되는지 보는 것입니다. 막연히 ‘모바일 QA 필요’라고 적는 것보다, 어떤 동작을 보고 판단할지 알 수 있습니다.
다음 확인을 누가 할지도 실제 업무 분담에 맞추어 적습니다. 이름을 아는 사람이 없는데 임의로 담당자를 만들지는 않습니다. 아직 분담이 안 됐다면 그 상태를 그대로 남기면 됩니다. 보고서가 일을 넘겼다는 증거가 되려면, 상대방이 실제로 맡았는지와 필요한 자료가 준비되어 있는지도 별도의 확인이 필요합니다.
언제 다시 볼 것인지도 날짜만으로 해결되지는 않습니다. 접근이 복구되었을 때인지, 같은 기능의 다음 변경 전에 볼 것인지, 발행 전에 반드시 끝낼 것인지 구분해 봅니다. 예시의 화면이 공개 전에 필요한 검사라면, 그 검사가 남아 있는 동안의 상태도 준비와 공개 완료로 나누어야 합니다. 예정 시각이 지났다는 사실이 검증을 대신해 주지는 않습니다.
자동으로 확인할 수 있는 것과 실제로 써 봐야 하는 것도 구분합니다. 반환값을 검사했다고 버튼의 글자가 잘 보인다고 결론 내릴 수는 없습니다. 화면이 보인다고 그 버튼을 눌렀을 때 필요한 경로가 실행된다고 말할 수도 없습니다. 서로 다른 증거가 필요한 항목을 같은 통과 표시 아래에 뭉치지 않는 편이 좋겠습니다.
같은 빈칸이 반복될 때 고칠 것
한 번의 보고서에서 해결하지 못한 항목이 다음 변경에서도 반복된다면, 개별 변경 밖의 문제일 수 있습니다. 매번 시험 자료를 구할 수 없었다면 자료 준비 과정을 살필 수 있고, 같은 조작을 기록하기 어려웠다면 관측 방법을 살필 수 있습니다. 이때 필요한 것은 보고서에서 빈칸을 지우는 요령이 아니라, 그 확인을 실제로 할 수 있게 만드는 일입니다.
가상의 팀이 최근 보고서들을 모았다고 해 보겠습니다. 화면 확인이 빠진 건수만 세면 작업이 많다는 사실은 알 수 있습니다. 하지만 기기 부족과 로그인 실패, 문서에 적힌 실행 방법의 오류가 섞여 있다면 고칠 순서가 보이지 않습니다. 부족한 조건을 구분해 읽어야 다음에 무엇을 준비할지 정할 수 있습니다.
그렇다고 빈칸을 많이 적는 것이 더 좋은 보고서라는 뜻은 아닙니다. 변경과 관련 없는 모든 검사를 나열하면 중요한 항목이 묻힙니다. 이번 변경이 어떤 동작을 바꾸었는지, 그 동작에 어떤 확인이 필요한지 연결해야 합니다. 관련성을 설명할 수 없는 목록을 길게 늘리기보다, 판단에 영향을 주는 빈칸을 구체적으로 남기고 싶습니다.
검증한 대상도 함께 남기기
검사를 수행한 뒤 파일을 다시 고쳤다면 앞선 결과가 새 상태에도 그대로 적용되는지 확인해야 합니다. 예시 검색 화면의 버튼 구조를 검사 뒤 바꾸었다면, 적어도 영향을 받는 확인은 다시 볼 이유가 생깁니다. 보고서에 결과뿐 아니라 어떤 상태를 확인했는지도 적는 이유입니다. 파일 이름이나 날짜만으로 대상을 구분할 수 없다면 별도의 버전 표시가 필요할 수 있습니다.
보고서를 AI가 썼을 때에도 원칙은 같습니다. ‘실행했다’는 문장과 실제 실행 결과가 연결되는지 봅니다. 시작한 명령이 끝났는지, 필요한 값이 나타났는지, 다른 화면을 보고 적은 것은 아닌지 확인합니다. 문서가 매끄럽다는 이유로 근거의 빈칸까지 채워졌다고 생각하지 않으려 합니다.
남은 확인이 있다고 모든 독립 작업을 멈출 필요는 없을 것입니다. 예시의 모바일 검사가 막혀 있어도 변경 내용을 정리하고 시험 자료를 준비하는 일은 할 수 있습니다. 다만 그 준비를 공개 완료로 부르면 안 됩니다. 무엇을 마쳤고 무엇이 남았는지 나누어 적어야 기다리는 사람도 다음 행동을 알 수 있습니다.
나는 좋은 검증 보고서가 빈칸 없는 서류라기보다, 다음 사람이 같은 질문을 처음부터 되풀이하지 않아도 되는 기록이면 좋겠습니다. 오늘의 변경에서 확인하지 못한 항목 하나가 있다면 이유와 다음 확인을 함께 남겨 보면 어떨까요. 그 한 줄이 다음 작업을 더 작고 구체적으로 만들어 줄 수 있겠습니다.
함께 읽기: 테스트가 통과했는데, 고치려던 동작은 실행됐을까
공개 원문을 참고하고 AI의 도움으로 구성한 글입니다. 자체 예시는 본문에 구분했으며, 원문의 제품이나 실험을 직접 실행한 후기가 아닙니다.
