8분 만에 공개된 앱, Cursor 덕분일까 명세 덕분일까

AI 요약

작성자는 Hacktoberfest와 MLH Global Hack Week의 미니 앱 과제로 단일 HTML 파일 팁 계산기 Propina를 만들었습니다. USD와 MXN을 선택하고 수동 환율을 입력하면 팁, 총액, 인당 금액을 두 통화로 표시합니다. 프레임워크와 빌드 단계, 환율 API는 쓰지 않습니다. 환율 기본값은 1달러당 18페소이며 사용자가 직접 바꿉니다.

8분 안에 공개한 과정

시간은 채팅 기록과 GitHub 커밋으로 확인했습니다. 오전 8시 25분에 Claude에게 Cursor용 프롬프트를 요청했고, 8시 26분에 통화와 브랜드 색상 조건을 보탰습니다. 8시 28분에 저장소를 만들고 8시 32분에 첫 커밋을 했으며, 8시 33분에 푸시해 GitHub Pages 사이트를 공개했습니다. 작성자는 구현 중 Cursor에 수정을 요청하지 않았고, 8시 39분에 계산 결과를 손으로 확인했습니다.

프롬프트에는 단일 HTML 파일, 입력과 출력, 통화 변환 표시 방식, 디자인 색상과 글꼴을 구체적으로 적었습니다. 입력이 비거나 잘못됐을 때 NaN이나 빈 화면 대신 0.00을 표시하고, 음수와 0 이하 환율을 거부하며, textContent를 쓰라는 조건도 명시했습니다. 마지막에는 목록에 없는 기능을 추가하지 말라고 했습니다. 작성자는 결정을 미리 끝낸 명세 덕분에 Cursor가 채팅 중 요구사항을 추측하거나 확인할 일이 줄었다고 봅니다.

구현과 검토는 별도 단계

작성자는 Cursor 무료 크레딧을 다 써서 최종 검토를 Claude에 맡겼습니다. Claude는 index.html 424줄을 읽고 세 가지를 지적했습니다. 인원 입력에 1.5를 넣어도 통과하는 문제는 수정했고, 스크린 리더에 결과 변경을 알리지 않는 문제도 aria-live를 추가해 고쳤습니다. 실제로 일치하지 않는 CSS 규칙은 동작에 영향이 없어 남겼습니다. 두 줄을 고친 두 번째 커밋은 첫 구현에서 약 20분 뒤 올라갔습니다.

작성자는 명세에 인원이 1명 이상이라고만 적었고 정수여야 한다는 조건은 빼먹었습니다. Cursor는 명시한 조건대로 동작했지만, 검토 과정에서 예상하지 못한 입력이 드러났습니다. 작성자는 검토자가 명세와 코드의 일치 여부만 보는 대신 잘못된 입력에서 실제 화면이 어떻게 동작하는지 시험했다고 설명합니다. 수동 환율과 간단한 계산기라는 범위에서는 이런 프롬프트가 잘 작동했지만, 상태나 백엔드가 들어가는 다음 프로젝트에서도 같은 방식이 통할지는 아직 시험하지 않았다고 덧붙입니다.

댓글에서 나온 검토 방식

@matbusel은 1.5명 문제가 명세의 빈틈을 보여준다고 짚습니다. 명세는 최소 1명이라고 했으므로 구현이 그 조건을 만족했지만, 정수 조건은 빠져 있었습니다. 그는 검토자가 명세를 그대로 대조하기보다 잘못된 입력을 직접 시험한 점에 의미를 둡니다. 이후에는 명세를 가설로 보고, 버그가 발견되면 명세부터 고쳐 다음 작업에 반영하자고 제안합니다. 작성자는 명세 변경 이력을 남기면 나중에 조건이 추가된 이유를 추적할 수 있다고 답합니다.

@vladzoff는 명세와 검증을 분리하자고 제안합니다. 명세는 항상 지켜야 할 조건을 담고, 빌드 에이전트와 별도로 관리하는 테스트가 그 조건을 확인해야 한다는 의견입니다. 예를 들어 1,437.50을 3명에게 나누면 479.17씩 계산해 합계가 1센트 어긋날 수 있으므로, 남는 센트를 누구에게 배정할지 정하고 테스트해야 합니다. 작성자는 첫 번째 사람이 잔돈을 부담하는 규칙을 정해 문서화하겠다고 답합니다.

@orian-wolf는 검토자가 다른 에이전트라는 사실만으로 독립성이 보장되지는 않는다고 반박합니다. 같은 명세를 받은 검토자는 같은 가정을 이어받을 수 있으므로, 검토에서 다른 질문을 던지는 것이 중요하다는 주장입니다. 입력의 타입과 허용 범위, 잘못된 입력의 처리 방식을 먼저 선언하게 하는 방법을 제시합니다. 작성자는 평소에는 단계별 구현과 QA를 하지만 이번에는 8분 과제라 그 절차를 생략했다고 설명합니다.

dev.to 반응

• @benchsmoke — 채팅 기록과 커밋 이력으로 시간을 뒷받침한 점이 좋습니다. 많은 "몇 분 만에 만들었다"는 글은 근거를 생략합니다. 프롬프트가 실제 작업이었다는 데 동의합니다. 검토에서 찾은 버그는 프롬프트에 빠진 조건이었나요, 아니면 Cursor가 다르게 해석한 조건이었나요?
  • @earlgreyhot1701d — 고맙습니다. 정확한 시간을 적어두지 못해 아쉬웠는데 채팅 기록과 커밋 이력이 도움이 됐습니다. 조건이 빠진 경우였습니다. 프롬프트에는 인원이 최소 1명이어야 한다고 적었고 Cursor는 그대로 구현했습니다. 1.5도 1명 이상입니다. 정수라고 쓴 사람은 없었으니 Cursor가 다르게 해석한 게 아닙니다.
• @promptalo — 다음 미니 앱에도 재사용할 프롬프트 요소는 입력 규칙입니다. 인원은 정수인지, 비율의 범위는 무엇인지, 빈 입력은 어떻게 처리하는지 블록으로 만들어 두면 다음 앱은 검토에서 1.5명 문제를 다시 발견하지 않아도 됩니다.
  • @earlgreyhot1701d — 동의합니다. 보통은 단계별로 만들고 각 단계마다 QA를 하며 입력 규칙 블록도 재사용합니다. 이번에는 8분 과제라 그 절차를 생략했고, 1.5명 문제가 그 대가였습니다. 제가 얻은 교훈은 재사용 블록을 새로 만들라는 게 아니라 작은 작업에서도 이미 있는 블록을 쓰라는 것입니다.
• @vladzoff — 다음 시험은 앱을 작게 유지하면서 상태와 외부에서 고정한 인수 테스트를 추가해 보세요. 잘못된 환율, 소수 인원, 나눗셈 반올림, 새로고침 뒤 상태를 확인할 수 있습니다. 한 번에 만들었는지가 아니라 입력이 잘못되거나 상태가 바뀌어도 불변 조건을 지키는지가 더 흥미로운 지표입니다.
  • @earlgreyhot1701d — 제안한 시험은 다음 단계와 가깝고, 특히 나눗셈 반올림은 미처 적지 못했습니다. 1,437.50을 세 명이 나누면 각자 479.17이 되어 합계가 1센트 차이 납니다. 불변 조건은 사용자가 무엇을 해도 지켜져야 하는 규칙으로 이해했습니다. 이 조건을 명세에 쓸지 별도 검토 목록에 둘지는 아직 정하지 못했습니다.
  • @vladzoff — 불변 조건은 명세에 두되 인수 테스트는 빌드 과정과 독립적으로 관리하면 됩니다. 검토에서 빠진 조건이 발견되면 둘 다 의도적으로 갱신하세요. 에이전트가 자신이 평가받는 테스트를 조용히 바꾸지 못하게 해야 합니다. 나머지 센트도 각 몫을 따로 반올림하는 대신 총액이 맞도록 결정적 규칙을 정하고 시험하세요.
  • @earlgreyhot1701d — 두 가지를 의도적으로 분리하고 빌드 에이전트가 정답지를 고치지 못하게 하는 방식으로 이해했습니다. 남는 센트는 규칙을 정해 적겠습니다. 아마 첫 번째 사람이 내도록 하겠습니다. 누군가는 내야 하고 시험하기 쉽기 때문입니다.

원문: dev.to / 번역·요약: Trawling