교차 검증 3개월 회고 - 프롬프트 노하우가 도구로 쌓이기까지

TL;DR
교차 검증 플러그인을 3개월간 실무에 사용했습니다. 반복하던 검증 프롬프트가 프로필로 자산화되었습니다.
“이걸 놓칠 뻔했다”는 순간이 쌓이자 지적 재산으로 가져가고 싶은 욕심이 생겼고, 퍼블릭 전환으로 이어졌습니다.
도구를 만든 것보다, 쓰면서 쌓인 노하우가 진짜 자산이었습니다.

---

들어가며

이전 글에서 도구를 구현하고, 자체 검증과 실전 검증을 거쳤습니다.
이번 글은 그 이후, 도구를 실무에서 꾸준히 쓰면서 느낀 것들의 기록입니다.

도구를 만든 직후에는 “잘 만들었다”는 만족감이 큽니다. 하지만 진짜 가치는 며칠, 몇 주가 지나면서 드러납니다. 검증을 반복할수록 프롬프트에 경험이 쌓이고, 그 경험이 도구의 일부가 되는 과정을 기록합니다.

1. 도구를 쓰면서 달라진 것

습관으로 자리 잡은 검증

처음에는 “큰 작업 끝나면 한번 돌려보자” 수준이었습니다. 3개월이 지나자 작업 흐름의 일부가 되었습니다.

시점	검증 습관
도입 초기	피처 완료 후 1회 검증
1개월 차	설계 변경 시마다 검증
3개월 차	커밋 전 검증이 자연스러운 절차

습관이 된 이유는 단순합니다. 놓칠 뻔한 것을 실제로 잡아줬기 때문입니다.

잊기 쉬운 것을 잡아주는 도구

개발자는 집중하고 있는 문제에 시야가 좁아집니다. 교차 검증은 4축을 강제로 훑기 때문에, 지금 집중하지 않는 축의 문제를 환기시켜 줍니다.

상황	놓칠 뻔한 것	잡아준 축
미터링 집계 배치 구현에 몰두	타임존 일관성: LocalDate.now()가 서버 타임존에 의존	설계
API 응답 구조 설계	당일 실시간 병합으로 페이지네이션 비대칭 발생 가능	설계
@Transactional 없는 DELETE+INSERT	경고가 아닌 의도적 설계임을 확인, 오히려 불필요한 수정을 방지	구현

세 번째 사례가 특히 의미 있었습니다. 자동화 도구였다면 “@Transactional 누락” 경고를 띄웠을 것입니다. 교차 검증은 “왜 없는가”를 추적하여 멱등성 + 백필 복구가 트랜잭션의 역할을 대체하는 설계 의도를 확인했습니다. 잘못된 수정을 막는 것도 검증의 가치입니다.

2. 프롬프트 노하우의 자산화

반복되는 프롬프트 입력

검증을 반복하면서 패턴이 보이기 시작했습니다. 매번 비슷한 맥락을 프롬프트로 전달하고 있었습니다.

• “UseCase는 WHAT만 표현하는지 확인해줘”
• “Repository CUD는 단일 도메인 원칙 준수하는지 봐줘”
• “헥사고날 아키텍처 위배 여부 체크해줘”

이 반복이 프로필 시스템의 동기가 되었습니다.

프로필: 반복 프롬프트의 구조화

.claude/cross-verify.json에 프로젝트별 검증 관점을 정의합니다.

{
  "conventions": "docs/CONVENTIONS.md",
  "focusAxes": ["설계", "구현"],
  "customChecks": {
    "설계": [
      "UseCase는 WHAT만 표현하는가",
      "인프라 계층에서만 트리거를 구분하는가"
    ],
    "구현": [
      "Repository CUD는 단일 도메인 원칙을 준수하는가",
      "@Transactional은 public 메서드에만 적용되는가"
    ]
  }
}

이 설정 파일 하나에 3개월간 반복 입력하던 프롬프트가 응축되어 있습니다.

자산화의 세 단계

돌이켜보면 자산화는 의도한 것이 아니라, 사용하면서 자연스럽게 일어났습니다.

단계	형태	특징
1단계	매번 프롬프트 직접 입력	경험은 개발자 머릿속에만 존재
2단계	반복 패턴을 프로필로 정리	경험이 설정 파일로 외부화
3단계	프로필이 프로젝트 컨벤션과 연결	팀의 규칙이 검증 도구에 반영

1단계에서 2단계로의 전환이 핵심이었습니다. 머릿속에만 있던 검증 관점이 파일로 나오는 순간, 공유 가능하고 버전 관리 가능한 자산이 됩니다.

3. 한계와 트레이드오프

프롬프트-only의 구조적 한계

교차 검증 플러그인에는 실행 가능한 코드가 없습니다. 전체가 마크다운 프롬프트입니다. 이 선택에는 명확한 한계가 있습니다.

한계	영향
동일 입력에 대한 일관성 미보장	같은 코드를 검증해도 매번 다른 관점이 나올 수 있음
출력 품질의 프로그래밍적 강제 불가	검증 깊이가 모델 컨디션에 의존
거짓 양성 가능	문제가 아닌 것을 문제로 지적할 수 있음

과신은 금물

도구를 쓰면서 가장 경계한 것은 검증 통과 = 완벽이라는 착각입니다. 교차 검증은 “또 다른 시선”이지, 최종 판정이 아닙니다. A 등급을 받았다고 안심하면 도구가 오히려 해가 됩니다.

실제로 검증에서 잡지 못한 이슈가 코드 리뷰에서 나온 적도 있습니다. 도구의 한계를 인정하는 것이, 도구를 올바르게 쓰는 전제라고 생각합니다.

도구 관리라는 또 다른 과제

AI 시대에 도구 생성은 쉬워졌습니다. 생각나는 대로 만들 수 있습니다. 하지만 그만큼 정리되지 않은 도구가 쌓이는 것도 빨라졌습니다.

여러 플러그인을 만들고 사용하면서, 도구 자체를 관리하는 구조가 필요하다는 것을 느꼈습니다. 만드는 것보다 꾸준히 관리하는 것이 더 어렵고, 더 중요했습니다.

4. 퍼블릭 전환

자산화에서 구조로

3개월간 프로필에 쌓인 검증 노하우를 보면서, 이것은 프로젝트가 아닌 개인의 지적 재산이라는 생각이 들었습니다. 사내 환경에서만 존재하면 환경이 바뀔 때 사라집니다. 꾸준히 관리하고 발전시키려면 퍼블릭으로 가져가는 것이 맞았습니다.

범용과 커스텀의 분리

퍼블릭 전환에서 가장 중요한 결정은 분리 기준이었습니다.

구분	내용	위치
범용	4축 검증 프레임워크, 프로필 구조, 에이전트 정의	퍼블릭 레포 (github.com)
커스텀	프로젝트별 customChecks, 사내 컨벤션 참조	사내 레포 (프로젝트 로컬)

범용 부분만 퍼블릭에 두고, 프로젝트별 설정은 각 프로젝트가 소유합니다. 이 분리는 “오픈소스 프레임워크 + 사내 설정”이라는 흔한 패턴이지만, 개인 도구에 적용하니 관리 부담이 크게 줄었습니다. 범용 로직을 수정하면 모든 프로젝트에 반영되고, 프로젝트별 특수성은 각자 관리됩니다.

5. 앞으로의 방향

교차 검증 플러그인은 완성이 아니라 진행 중입니다.

방향	설명
프로필 고도화	사용하면서 발견되는 검증 관점을 계속 프로필에 추가
검증 이력 축적	어떤 검증에서 무엇을 발견했는지 기록하는 구조 검토
커뮤니티 피드백	퍼블릭 전환의 진짜 가치는 다른 사람의 시선. 다른 프로젝트에서의 사용 사례를 기대

3개월 전에는 “검증을 자동화하자”고 시작했습니다. 지금은 “검증하면서 쌓이는 경험을 어떻게 관리할 것인가”를 고민하고 있습니다. 도구는 사용하면서 진화합니다. 그 진화의 기록이 이 시리즈입니다.

이 글은 Claude와 함께 작업했습니다.