AI 코딩에서 어려운 부분: 작업이 끝났다고 판단하기

Code Factory는 AI 코딩 에이전트가 작업을 마친 뒤 요구사항과 테스트 범위를 확인하고, 검사 결과를 검증 대상 코드와 연결하는 로컬 우선 워크플로를 제안합니다. 작성자는 기록이 정확성을 보장하지 않으며 테스트와 사람의 판단이 여전히 필요하다고 밝힙니다.

주제: AI 개발 도구 테스트

에디터 노트

검사 결과를 코드와 입력에 묶는 설계는 "테스트 통과"만 보여주는 것보다 검토자가 확인할 근거를 더 많이 남깁니다. 특히 빈 CSV 결과나 권한 없는 레코드처럼 미리 정해야 할 사례를 드러내는 데 유용합니다. 다만 기록이 무엇을 검사했는지 보여줘도 명세가 맞는지, 테스트가 중요한 실패 조건을 다뤘는지까지 입증하지는 않습니다. 댓글에서 나온 규칙 파일 해시, 계획과 실제 변경 파일의 비교, 부정 사례 기록은 이 빈틈을 구체적으로 짚습니다. 기록을 코드 변경 뒤 어떻게 무효화할지도 아직 답이 없습니다.

AI 요약

AI 코딩 에이전트가 "끝났다"고 말한 뒤에도 요구사항을 제대로 구현했는지, 테스트가 어떤 동작을 확인했는지, 검사 결과가 현재 코드에 해당하는지 따져야 합니다. Code Factory는 이 확인 과정을 로컬 우선 워크플로로 묶습니다.

작업과 검사 기록

CSV 내보내기를 예로 들면 먼저 사용자가 내보낼 수 있는 레코드와 결과가 비어 있을 때의 동작을 정합니다. 이를 작은 작업으로 나누고 하나씩 구현한 뒤 검토와 관련 검사를 진행합니다. 검사 결과를 검사에 사용한 입력과 연결해 검토자가 변경 과정을 따라가도록 합니다. 초보자에게는 다음 단계가 명확해지고, 숙련 개발자에게는 에이전트 기록을 뒤져 작업 경위를 재구성하는 수고가 줄어드는 것이 작성자가 설명한 기대 효과입니다.

스캐너는 참고용이며 오탐이 있습니다. 검사 기록은 작업을 살피는 근거를 제공하지만 소프트웨어가 정확하다는 증명은 아닙니다. 작성자는 테스트와 사람의 판단이 계속 필요하다고 선을 긋습니다.

Indie Hackers 반응

@IAmaniaKos — 저는 개발자가 아니지만 Claude Code로 결제가 포함된 사이트 전체를 만들었기에 이 내용이 와닿습니다. 제게 효과가 있었던 방법은 "코드가 완성돼 보인다"가 아니라 제가 직접 확인할 수 있는 상태를 완료로 정의하는 것입니다. 실제 결제가 끝까지 진행되는지, 환불이 실제로 반영되는지, 휴대전화에서 페이지가 열리는지 확인합니다. 코드를 읽지 않고 검증할 수 없다면 아직 끝난 게 아닙니다. 코드를 읽을 수 있을 때는 완료 여부를 어떻게 판단하시나요?
@safad — 제게 가장 비용이 큰 부분은 세 번째입니다. 검사가 실제로 충분했는지 아는 일이요. 에이전트는 방금 바꾼 경로를 테스트 하나도 건드리지 않았는데 "테스트 통과"라고 보고할 수 있습니다. 그래서 변경이 잘못됐다면 어떤 테스트가 실패해야 하는지 에이전트에게 묻기 시작했습니다. 검사한 입력과 결과를 연결하는 건 좋은 생각입니다. 나중에 같은 파일을 수정하면 Code Factory가 기록을 오래된 것으로 표시하나요?
@Arg Software — 기본적으로 코드와 구조를 검토하는 일입니다. 각 기능에서 안전망을 만들려고 에이전트가 무엇을 테스트할지 상세히 정하고 주로 단위 테스트와 통합 테스트를 씁니다. 마지막에는 변이 테스트로 테스트에 한 겹을 더하고 테스트가 충분히 관련 있는지, 아니면 더 응집력이 필요한지 확인합니다.
@PromptAlo — 검사 기록에 한 가지 빠진 점이 있습니다. 테스트가 무엇을 확인했는지는 기록하지만 에이전트가 어떤 규칙 파일을 따랐는지는 기록하지 않습니다. 두 실행 사이에 지침이 바뀌었다면 통과 기록 두 개를 서로 비교하기 어렵습니다. 규칙 파일의 해시를 각 기록에 넣으면 차이가 드러납니다.
@Emiliano Loguidici — 제게는 변경 사항 검토가 가장 큰 일이고, 특히 작업 범위 밖의 변경이 그렇습니다. 에이전트가 CSV 내보내기를 고치면서 마이그레이션, 공용 헬퍼나 설정 파일까지 "작동하게 하려고" 건드릴 수 있습니다. 테스트가 통과해도 결국 전부 읽어야 합니다. 계획에서 바꾸기로 한 파일과 실제 변경 파일을 비교해 차이를 표시하면 어떨까요? 마이그레이션, 인증, 결제 코드 변경은 항상 사람이 검토하게 할 수도 있습니다. 검토 시간을 많이 줄여줄 겁니다.
@LucasOpenCL — 가장 어려운 점은 에이전트가 시작하기 전에 "완료"가 대개 정의되지 않는다는 겁니다. 무엇을 충족해야 하는지 모르면 diff 검토에 시간이 더 듭니다. 인수 기준이나 실패하는 테스트를 먼저 작성하고 에이전트 결과를 대조하면 사후 검토보다 시간을 아낄 수 있을 것 같습니다. 기록도 같은 이유로 흥미롭습니다. "믿어 달라"를 직접 확인할 수 있는 것으로 바꿉니다. 테스트도 같은 에이전트가 작성한 경우는 어떻게 처리하시나요?
@theboris7 — 제게는 세 번째 문제가 시간 잡아먹는 일입니다. 검사가 충분했는지 아는 것이요. 도움이 된 습관은 규칙마다 코드와 부정 테스트를 작성하는 것입니다. 부정 테스트는 일부러 잘못된 입력을 넣어 실패해야 하는 테스트입니다. 에이전트의 "완료"가 이를 통과하지 못하면 끝난 게 아닙니다. CSV 예시는 잘 맞습니다. 정상 내보내기 테스트는 쉽게 통과하지만 유용한 검사는 빈 결과와 사용자가 내보낼 권한이 없는 레코드입니다. 작업에서 어떤 부정 사례를 실행했는지 기록하면 검토자가 통과 여부뿐 아니라 어떤 실패 조건을 시험했는지도 볼 수 있습니다. ForgeLine에서는 부정 사례가 없으면 작업을 미완료로 표시할 수 있나요?
@Naeem Hossain — 좋은 완료 기준은 실제 기기에서, 불안정한 네트워크에서, 안내문을 읽지 않는 사용자와 함께 작동하는 것입니다. AI는 "내 컴퓨터에서는 작동함"까지 빠르게 데려가지만 나머지는 여전히 우리 몫입니다.
@ska1296 — 검사가 충분한지 싸게 확인하는 한 가지 방법은 새 코드를 일부러 망가뜨리는 것입니다. 조건을 뒤집거나 빈 목록을 반환한 뒤 같은 테스트를 실행합니다. 그래도 통과한다면 해당 동작을 검사하지 않은 것이고 "전부 통과"라는 말은 그 사실을 알려주지 않습니다. 변이 테스트 도구가 이를 자동화합니다. "이 기능을 제거했을 때 이 테스트들이 실패했다"고 기록한 영수증은 "이 테스트들이 통과했다"보다 훨씬 강한 근거입니다. 코드가 나중에 바뀌었을 때 어떤 검사가 오래됐는지도 보여줍니다.
@Fitri Afiq — 제게는 검사입니다. diff는 읽을 수 있지만 "모든 테스트 통과"만으로는 새 동작을 실제로 검사했는지, 에이전트가 시작하기 전부터 기존 테스트가 통과했는지 알 수 없습니다. CSV 예시에서는 누군가 미리 정하지 않으면 빈 결과 사례가 빠지기 쉽습니다. 명세 자체가 틀렸을 때는 어떻게 되나요? 기록에는 코드가 명세에 맞았는지만 나오나요?
@Code Factory — 댓글 모두 감사합니다. 모두 잘 기록해 두었고 앞으로 개선과 자동화를 기대해 주세요.

원문: Indie Hackers / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗