코드를 읽지 못해도 버그를 잡는 방법

AI 요약

프리랜서용 국제 청구 서비스 Alisio를 만드는 창업자는 PM·UX 경력은 있지만 개발 경험이 없습니다. 코드 전체를 AI 코딩 도구가 작성하며, 본인은 코드를 직접 다루지 않습니다. 그래서 코드가 맞는지 확인하는 대신 제품이 예상대로 동작하는지 검증합니다.

실제 상황을 테스트 사례로 만듭니다

기능을 요청하기 전에 여러 고객이 서로 다른 통화로 결제하는 상황, 월말 자정 직전에 송장을 보내는 경우, 소수점 대신 쉼표를 입력하는 경우처럼 처리해야 할 사례를 구체적으로 적습니다. 그런 다음 제품을 직접 사용하며 결과를 확인합니다. 문제가 생기면 코드의 특정 줄을 지목하지 않고, 해당 상황에서 어떤 값이 예상과 다른지 설명합니다. 글쓴이는 이런 설명만으로도 AI가 버그를 찾는 데 충분한 경우가 많다고 합니다.

코드 차이(diff)를 읽고 빠르게 판단하는 것보다 느리지만, 기능이 실패하는 상황을 직접 그리지 못한다면 기능을 제대로 이해하지 못한 것일 수도 있다고 덧붙입니다. Alisio는 아직 초기 단계이며 유료 고객은 없습니다.

회귀 테스트와 접근 제어 제안

댓글에서는 과거에 발견한 통화·날짜 문제를 작은 회귀 체크리스트에 기록하고, 변경할 때마다 새 기능뿐 아니라 기존 사례도 다시 확인하라는 제안이 나옵니다. 송장 앱에서는 다른 고객 계정으로 로그인해 직접 URL로 송장과 다운로드 파일에 접근할 수 있는지도 검사하라는 보안 점검이 제시됐습니다. MX 레코드가 없는 이메일 도메인, 국가 설정과 맞지 않는 전화번호 형식도 추가 테스트 사례로 언급됐습니다.

한 개발자는 AI 수정이 예상하지 못한 곳을 바꾸면 비개발자가 변화를 알아채지 못할 수 있다며 회귀를 어떻게 다루는지 질문합니다. 또 다른 댓글은 일반 프롬프트 하나로 생성할 때 결과물이 같은 템플릿처럼 보였던 경험을 들며, 조사·문구·디자인·배포를 별도 에이전트에 맡기고 오케스트레이터가 결과를 확인하는 방식을 소개합니다. 반응에는 실제 해외 프리랜서 고객을 만나기 전에 테스트 사례가 제품을 크게 바꾼 적이 있는지 묻는 질문도 있습니다.

Indie Hackers 반응

• @feech — 송장 앱이라면 고객 두 명으로 테스트해 보겠습니다. 고객 B로 로그인한 뒤 직접 URL을 입력해 고객 A의 송장을 열어 보세요. 송장이 목록에서 사라지는지만 볼 게 아니라 다운로드도 확인해야 합니다.
• @brk — 애플리케이션의 회귀 문제는 어떻게 다루시는지 궁금합니다. 값이 잘못된 걸 발견하면 AI에게 고치라고 할 수 있지만, 예상하지 못한 부분을 바꿔서 검증할 생각조차 못 하면 어떻게 되나요? 제품을 만드는 개발자인 저도 겪는 문제라 이런 테스트를 자동화하는 데 꽤 많은 시간을 썼습니다. 그쪽에서는 따로 하는 일이 있는지 궁금합니다.
• @Aryan_09 — 좋은 접근입니다. 제품 버그를 잡으려면 꼭 코드를 이해할 필요는 없습니다. 실제 상황을 테스트 사례로 정의하고 동작을 확인하면 특히 초기 단계에서 많은 문제를 찾을 수 있습니다.
• @roundhand — 네, 맞습니다. 앞으로 나아갈 방향입니다.
• @victor_james — 좋은 글입니다! 코드에 파고들기보다 실제 상황에 집중하는 점이 좋습니다. 제품을 출시할 준비가 됐는지 확인하는 좋은 방법입니다.
• @elijahbrown — 차이를 읽을 수 없을 때 실제 사례로 동작을 검증하는 건 좋은 습관입니다. Alisio라면 연락처 관련 사례도 추가하겠습니다. MX 레코드가 없는 도메인으로 송장 이메일을 보내는 경우와 고객 전화번호를 다른 국가의 지역 형식으로 입력하는 경우입니다. 쉼표 소수점 사례처럼 UI에서 실패를 확인하면 AI가 고칠 구체적인 단서가 생깁니다.
• @brianainews — 정말 와닿습니다. 많은 사람이 초록색 체크 표시를 증거로 여기지만, 실제 증거는 까다로운 예외 사례입니다. 기능을 만들기 전에 테스트 사례를 적는 습관이 좋습니다. 에이전트를 지휘할 때는 과거에 발생한 문제를 작은 회귀 체크리스트로 관리하고, 변경 뒤마다 실행하는 게 도움이 됐습니다. 그래야 예전 통화나 날짜 버그가 다시 나타나지 않습니다. 동작부터 확인하는 게 맞습니다.
• @adityaarora — 코드를 확인하는 대신 동작을 확인하는 게 맞습니다. 차이를 읽을 수 있는 사람에게도 그렇다고 생각합니다. 저희 회사에서 AI 앱을 만들 때도 비슷한 문제를 겪었습니다. 일반 프롬프트 하나로 모든 일을 시키면 사이트는 만들어지지만, 단어만 바꾼 같은 템플릿처럼 보였습니다. 그래서 조사·문구·디자인·배포를 각기 다른 에이전트에 맡기고, 오케스트레이터가 결과를 검토한 뒤 공개하도록 나눴습니다. 만드는 방식이 아니라 요청한 결과가 나왔는지 판단한다는 점에서 같은 접근입니다. 실제 사례를 한곳에 모아 두고 새 기능 사례만이 아니라 매 변경 뒤 전부 다시 실행하세요. 예전 사례가 조용히 깨지는 경우가 있습니다.
• @aryan_sinh — 테스트 사례에서 제품을 크게 바꿀 만큼의 실패를 발견했나요, 아니면 실제 해외 프리랜서들이 더 어려운 예외 상황을 알려주기를 기다리고 있나요?
• @bestusukiptv — 이런 관점이 좋습니다. 저도 Xstream4K를 만들고 있어서 공감됩니다. 처음에 이 문제를 살펴보게 된 계기가 무엇인가요?
  • @Nico Minetti — 선택이 아니라 필요 때문에 시작했습니다. 초반에는 오류 없이 실행되면 기능을 승인했는데, 며칠 뒤 테스트하지 않은 특정 통화 조합이나 월 경계의 날짜에서 문제가 생긴 걸 발견했습니다. 차이를 읽을 수 없으니 미리 구체적인 사례를 적고 나중에 직접 결과를 확인하는 수밖에 없었습니다. 코드 리뷰로도 놓쳤을 문제를 잡은 적이 있습니다. 차이가 깔끔해 보여도 아무도 적어 두지 않은 사례에서는 틀릴 수 있습니다. Xstream4K에서는 어떤가요? 기대한 대로 재생되는지 확인하는 식으로 스트림을 검증하나요?

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