샘플 입력 세 개를 먼저 고정하기

시리즈: 바이브코딩 Tips #30

이전: 29편 | 목록 | 다음 없음

2026년 6월 11일 | 바이브코딩 Tips

---

코딩 에이전트에게 작은 리팩터링을 맡길 때, 나는 요즘 요구사항보다 샘플 입력 세 개를 먼저 적는 쪽으로 습관을 바꾸고 있다. “이 파서를 더 튼튼하게 만들어 줘”라고 쓰면 에이전트는 대체로 그럴듯한 방향으로 움직인다. 그런데 문제는 그럴듯함이다. 정상 입력 하나만 통과해도 완료처럼 보이고, 내가 실제로 걱정하던 빈 값이나 깨진 행은 뒤늦게 다시 나온다.

처음에는 테스트를 많이 붙이면 해결된다고 생각했다. 물론 테스트는 중요하다. 다만 바이브코딩 흐름에서는 테스트 파일을 열기 전부터 이미 방향이 넓어지는 경우가 많다. 에이전트가 어떤 케이스를 대표로 보는지 모르는 상태에서 “견고하게” 같은 말을 던지면, 수정 범위도 넓어지고 완료 기준도 흐려진다. 그래서 나는 작업을 맡기기 전에 아주 작은 입력 묶음을 먼저 만든다. 성공해야 하는 입력, 애매해서 조심해야 하는 입력, 절대 바꾸면 안 되는 입력. 이 세 개만 있어도 대화가 꽤 달라진다.

좋은 예시 하나보다 다른 방향 세 개

샘플 입력을 세 개로 고정한다는 말은 예시를 많이 만들자는 뜻이 아니다. 오히려 반대에 가깝다. 예시를 열 개 붙이면 에이전트도 사람도 핵심을 덜 본다. 나는 보통 첫 번째를 정상 경로로 둔다. 지금도 되어야 하는 가장 평범한 입력이다. 두 번째는 경계 경로다. 빈 문자열, 긴 제목, 누락된 필드, 한국어와 숫자가 섞인 값처럼 실제로 자주 깨지는 입력을 넣는다. 세 번째는 보존 경로다. 이번 수정으로 모양이 바뀌면 안 되는 기존 결과를 하나 고른다.

예를 들어 CSV를 JSONL로 바꾸는 작은 변환기를 손본다고 치면, 나는 “정상 한 줄”, “빈 필드가 포함된 한 줄”, “이미 잘 변환되던 한 줄”을 먼저 적는다. UI 컴포넌트라면 “짧은 제목”, “두 줄로 넘어가는 긴 제목”, “아이콘만 있는 항목” 정도가 된다. 이 정도는 테스트 스위트라고 부르기도 민망하지만, 에이전트에게는 충분히 강한 신호가 된다. 무엇을 개선해야 하는지와 무엇을 그대로 둬야 하는지가 동시에 보이기 때문이다.

작업 설명이 아니라 판정 표면

이 방식의 장점은 샘플이 작업 설명을 대신한다는 데 있지 않다. 더 중요한 건 샘플이 판정 표면이 된다는 점이다. 에이전트가 수정한 뒤 “완료했습니다”라고 말해도, 나는 세 입력을 다시 돌려 보거나 눈으로 비교하면 된다. 정상 경로는 여전히 통과하는지, 경계 경로는 새로 처리되는지, 보존 경로는 그대로 남았는지. 이 세 질문이 있으면 완료 답변을 읽는 시간이 줄어든다.

반대로 샘플 없이 시작하면 검증이 뒤늦게 추상화된다. “조금 나아졌나?”, “대체로 맞나?” 같은 감각으로 diff를 읽게 된다. 이때 에이전트가 코드 스타일을 정리하거나 주변 함수를 같이 만지면, 사람도 어느새 본래 문제를 놓친다. 샘플 세 개를 먼저 고정하면 diff를 읽는 순서가 바뀐다. 바뀐 코드가 예쁘냐보다, 세 입력의 결과가 어떻게 달라졌는지를 먼저 보게 된다.

프롬프트에 넣을 때는 짧게

나는 이걸 거창한 표로 만들지는 않는다. 첫 프롬프트에 네 줄 정도만 넣는다. “아래 세 입력을 기준으로 수정해 달라. A는 기존처럼 통과해야 한다. B는 이번에 새로 처리해야 한다. C는 출력이 바뀌면 안 된다. 수정 후 세 결과를 먼저 보고해 달라.” 이 정도면 충분하다. 필요하면 실제 값은 코드 블록 대신 짧은 목록으로 붙인다. 중요한 건 입력 자체보다 역할이다. 어느 입력이 성공 기준이고, 어느 입력이 회귀 방지 기준인지가 보여야 한다.

이 작은 장치는 출력 형태를 고정하는 습관과도 잘 맞는다. 결과를 “수정 요약”으로만 받지 않고, “세 입력별 결과”로 먼저 받으면 된다. 그러면 에이전트가 어떤 파일을 읽었는지, 어떤 수정을 했는지, 어떤 검증을 못 했는지도 자연스럽게 따라온다. 특히 여러 파일을 건드릴 수 있는 작업에서는 이 순서가 중요하다. 입력 세 개가 먼저 있으면 에이전트가 괜히 주변 개선을 열기 전에, 지금 수정이 어디까지 필요한지 스스로 좁히게 된다.

샘플이 틀리면 바로 멈추기

주의할 점도 있다. 샘플 입력은 요구사항의 축소판이라서, 샘플 자체가 틀리면 작업이 이상한 방향으로 빨리 간다. 그래서 나는 애매한 케이스를 억지로 기대 출력까지 확정하지 않는다. 확신이 없으면 “이 입력은 먼저 관찰만 하고, 결과를 제안해 달라”라고 둔다. 경계 경로를 판정이 아니라 질문으로 남기는 편이 안전할 때가 있다. 에이전트에게 모든 걸 닫아 주는 것보다, 닫힌 것과 열린 것을 나눠 주는 쪽이 낫다.

또 하나는 세 개를 넘기지 않는 것이다. 실제 테스트는 나중에 더 붙여도 된다. 하지만 첫 프롬프트에서 기준 입력이 너무 많아지면 에이전트가 요약부터 하느라 시간을 쓴다. 내가 원하는 건 완전한 테스트 설계가 아니라, 첫 수정의 방향을 잡는 작은 나침반이다. 정상, 경계, 보존. 이 세 칸이 채워졌으면 일단 시작해도 된다.

리뷰할 때 남는 흔적

샘플 입력을 먼저 적어 두면 리뷰 메모도 단순해진다. 나는 diff를 다 읽기 전에 세 줄짜리 확인표를 먼저 본다. A는 그대로인지, B는 새로 처리됐는지, C는 깨지지 않았는지. 이 표가 비어 있으면 아직 완료가 아니다. 에이전트가 테스트를 실행하지 못했다면 그 사실도 표에 남기게 한다. “로컬에서 확인 불가”라는 말은 실패가 아니라 다음 사람이 바로 이어 볼 수 있는 상태 표시가 된다.

특히 여러 세션에 걸쳐 작업할 때 이 흔적이 유용하다. 다음 세션은 긴 설명을 다시 읽지 않아도 된다. 세 입력과 마지막 결과만 보면, 어디까지 믿어도 되는지 대략 잡힌다. 내가 handoff를 받을 때도 마찬가지다. “수정 완료”라는 문장보다 “A 통과, B 실패, C 미확인” 같은 짧은 상태가 훨씬 빠르다. 그래서 샘플 입력 세 개는 프롬프트의 장식이 아니라 작업 인수인계의 작은 단위에 가깝다.

이 확인표를 남길 때는 값보다 차이를 먼저 적는다. A는 이전 출력과 동일, B는 빈 필드를 빈 문자열로 유지, C는 아직 미확인처럼 쓰면 된다. 문장 하나가 길어질 필요도 없다. 중요한 건 다음 사람이 같은 입력을 다시 만들지 않아도 되는 것이다. 작은 입력 세 개가 재현 가능한 발판으로 남으면, 다음 지시는 훨씬 짧아진다. 실패 원인을 추측하는 대신, 어느 입력에서 갈라졌는지를 바로 가리킬 수 있기 때문이다.

바이브코딩의 속도는 대충 맡길 때보다 작게 고정할 때 더 잘 나온다. 요구사항을 길게 쓰는 대신 샘플 입력 세 개를 먼저 적어 두면, 에이전트의 첫 수정도 작아지고 내 검증도 빨라진다. 무엇보다 좋은 점은 실패했을 때다. 세 입력 중 어디서 어긋났는지 바로 보이니, 다음 지시가 “다시 해 봐”가 아니라 “B만 다시 보자”로 줄어든다. 이 차이가 반복 작업에서는 꽤 크다. 작은 기준을 먼저 박아 두면 속도와 안전성이 같이 올라간다. 다시 읽을 때도 덜 헤맨다. 다음 수정도 더 작아진다.

시리즈: 바이브코딩 Tips #30

이전: 29편 | 목록 | 다음 없음