AI 코딩 도우미에게 일 잘 시키는 법

1. 1

   목표·제약·완료 기준 먼저 말하기

   재설정 버튼을 한 번 눌렀는데 메일이 두 통 왔다고 합시다. “메일을 한 통만 보내”라고 요청하기 전에 어느 동작을 한 번으로 셀지 정해야 합니다. 화면 클릭 한 번, 서버 요청 한 번, 메일 함수 호출 한 번은 서로 다릅니다. 이 수업에서는 메일 함수가 같은 입력에서 두 번 호출되는 작은 재현 예제로 범위를 좁힙니다.

   실제 계정이나 메일 서비스를 연결하지 않습니다. 발송 대신 배열에 기록하는 가짜 mailer를 사용합니다. user@example.com도 테스트용 문자열입니다. 아래 코드는 실제 프로젝트에서 발견한 결함의 보고서가 아니라 수정·검증 순서를 배우기 위해 편집자가 작성한 연습 코드입니다.

   코딩 도우미에게 관련 파일, 입력, 기대 결과, 현재 결과를 함께 줍니다. 운영 로그를 붙일 때는 키·세션·이메일 같은 값을 제거하고 조직의 허용 범위를 확인합니다. 큰 저장소를 한꺼번에 보내기보다 버그가 드러나는 최소 파일부터 읽게 하면 변경 범위를 검토하기 쉽습니다.

   같은 일을 막연하게 맡길 때와 구체적으로 맡길 때

   항목	막연하게	구체적으로
   목표	로그인 고쳐 줘	비밀번호 재설정 메일이 두 번 발송되는 문제 수정
   범위	(없음)	src/auth/reset.ts, src/mail/send.ts
   제약	(없음)	메일 템플릿과 공개 API는 바꾸지 말 것
   완료 기준	(없음)	재설정 요청 1회당 메일 1통, 기존 테스트 통과

   목표: 비밀번호 재설정 메일이 두 번 발송되는 문제 수정
   관련 파일: src/auth/reset.ts, src/mail/send.ts
   제약: 메일 템플릿과 공개 API는 바꾸지 말 것
   완료 기준: 재설정 요청 1회당 메일 1통, 기존 테스트 통과

1. 2

   작은 단위로 나눠 요청하기

   먼저 재현 코드를 별도 파일로 저장하고 실행합니다. Node.js의 기본 테스트 도구를 쓰므로 메일 계정이나 추가 라이브러리는 필요 없습니다. 파일 이름을 mail.test.mjs로 정한 뒤 node --test mail.test.mjs로 실행하세요. 함수의 마지막 두 줄이 같은 메일을 두 번 기록합니다.

   

   도우미에게는 “중복 호출의 원인을 찾되 공개 함수 인자와 메시지 문구를 유지하라”고 요청합니다. 이 예제의 완료 조건은 요청 함수 한 번에 기록 한 건입니다. 템플릿을 다시 쓰거나 이름을 바꾸거나 전역 발송 목록을 추가하는 변경은 이 결함을 고치는 데 필요하지 않습니다.

   계획은 재현, 최소 수정, 같은 검사 재실행으로 나누면 충분합니다. 파일 몇 개 이하라는 숫자가 안전을 보증하지는 않습니다. 한 줄이라도 오류를 숨기는 변경이라면 되돌려야 하므로, 각 변경이 실패 원인과 어떤 관계인지 설명할 수 있어야 합니다.

   버그 하나를 리뷰할 수 있는 크기로 나눈 예

   순서	요청	끝났는지 확인
   1	버그를 재현하는 테스트 작성	테스트가 실패함
   2	중복 발송 원인 수정	새 테스트와 기존 테스트가 통과함
   3	동시에 두 번 요청하는 경우 보강	동시 요청 테스트가 통과함
   4	로그와 주석 정리	변경이 두 파일 안에 머묾

   바로 고치지 말고, 이 문제를 리뷰하기 쉬운 단계로 나눈 작업 계획부터 보여 줘. 단계마다 끝났는지 확인하는 방법도 적어 줘.

   수정 전에는 기대 1, 실제 2로 실패해야 합니다. 이 파일은 실제 비밀번호 재설정 기능이 아니며 토큰 발급이나 네트워크 발송을 구현하지 않습니다.

   코드 예시복사

   import test from "node:test"; import assert from "node:assert/strict"; async function requestPasswordReset(email, { mailer }) { const message = { to: email, subject: "Practice reset" }; await mailer.send(message); await mailer.send(message); // Intentional practice bug } test("one recorded mail per invocation", async () => { const sent = []; const mailer = { async send(message) { sent.push(message); } }; await requestPasswordReset("user@example.com", { mailer }); assert.equal(sent.length, 1); assert.equal(sent[0].to, "user@example.com"); });

2. 3

   테스트를 먼저 쓰게 하기

   실패 메시지에서 sent.length가 2인지 확인합니다. 모듈을 찾지 못하거나 문법 오류가 나서 멈춘 것은 중복 발송을 재현한 결과가 아닙니다. 실패했다는 사실보다 왜 실패했는지가 먼저입니다. 테스트가 처음부터 통과하면 실행한 파일과 함수가 의도한 예제인지 확인하세요.

   이제 중복된 await mailer.send(message) 한 줄을 지웁니다. 테스트의 기대값을 2로 바꾸거나 배열의 첫 항목만 세면 버그를 정상 동작으로 바꿔 정의한 것입니다. 테스트와 구현을 동시에 고칠 때는 요구사항을 보존했는지 특히 주의해서 봅니다.

   같은 테스트를 다시 실행해 1건이 기록되는지 확인합니다. 수신자 검사도 남겨 두세요. “한 통”만 맞추려고 수신자를 고정값으로 바꾸는 수정은 다른 결함을 만듭니다. 실제 저장소라면 이 작은 검사 뒤에 영향을 받는 모듈의 기존 검사도 실행합니다.

   수정하기 전에, 재설정 메일이 두 번 발송되는 상황을 재현하는 테스트를 먼저 작성해 줘. 지금 코드에서는 이 테스트가 실패해야 해.

   확인해 보기

   • 수정 전 2건으로 실패하고 수정 후 1건으로 통과했는지 기록합니다.
   • 검사 실패가 사라진 이유를 코드의 삭제한 한 줄과 연결해 설명합니다.
3. 4

   리뷰도 맡기되, 판단은 직접 하기

   도우미가 동시 요청과 발송 실패를 지적했다면 실제 결함인지 추가로 확인합니다. 이 작은 예제는 요청 한 번 내부의 중복만 다룹니다. 버튼을 두 번 누른 상황이나 네트워크 재시도까지 같은 방식으로 해결했다고 쓰면 범위를 과장하게 됩니다.

   가짜 mailer가 오류를 던지도록 바꿔 함수도 실패하는지 확인할 수 있습니다. 오류를 잡고 무조건 성공으로 반환하는 수정은 발송 실패를 숨깁니다. 반대로 전역 변수에 “이미 보냄”을 저장해 모든 후속 요청을 막는 코드는 정상적인 두 번째 요청도 막을 수 있습니다.

   실제 서비스의 중복 처리에는 요청 식별자, 저장소 제약, 재시도 정책과 발송 시스템의 동작을 함께 봐야 합니다. 메일을 보낸 뒤에만 기록하면 기록 전 장애에서 다시 보낼 수 있고, 먼저 기록하면 발송 전 장애에서 누락될 수 있습니다. 이 교재의 한 줄 수정이 그런 전달 보장을 구현하지는 않습니다.

   방금 변경 사항을 리뷰해 줘. 동시에 두 번 요청이 들어오는 경우, 메일 발송이 실패하는 경우를 특히 확인해 줘.

   검토 질문: 같은 요청이 다시 도착했는가, 새 요청인가? 발송이 실패했는가, 응답만 끊겼는가? 현재 예제는 이 질문에 답할 저장소와 네트워크 기록을 갖고 있지 않으므로 후속 설계 항목으로 남깁니다.

   확인해 보기

   • AI가 짚은 문제를 그대로 믿지 말고, 그 경우를 테스트로 만들어 실제로 재현되는지 확인하세요.
   • 보안, 결제, 개인정보가 걸린 변경은 사람 리뷰를 한 번 더 거칩니다.
4. 5

   변경 내역을 읽고 범위 확인하기

   수정 전후 파일을 비교하면 같은 발송문 한 줄이 사라져야 합니다. 도우미가 함수 전체를 다른 구조로 바꾸었다면 왜 필요한지 먼저 묻습니다. 테스트가 통과해도 관련 없는 서식·문구·의존성 변경이 섞이면 검토할 내용이 늘어납니다.

   

   변경 설명에는 문제, 수정, 확인한 범위, 남은 범위를 적습니다. 예를 들어 “한 호출 내부의 중복 send를 제거했고 가짜 mailer에서 한 건을 확인했다. 실제 메일 서비스와 동시 요청은 시험하지 않았다”면 다음 사람이 정확히 이해할 수 있습니다.

   실제 고객에게 보낼 결과나 운영 환경 변경은 코드 검사를 넘는 단계입니다. 어떤 버전으로 배포하고 실패하면 어떻게 돌아갈지 확인해야 합니다. 이 연습은 로컬 파일 안에서 끝내며, 운영 계정이나 발송 기능을 연결하지 않습니다. 작은 시험에서 얻은 증거의 범위를 유지하세요.

정답을 맞혀야 다음 수업으로 가는 시험이 아닙니다. 해설을 읽고 이해하는 데 사용하세요.

1. Q1기대값을 1에서 2로 바꾸니 테스트가 통과합니다. 수정으로 인정할까요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   아닙니다. 요구사항은 한 호출에 한 건이므로 기대값을 바꾸면 결함을 허용한 것입니다. 중복된 함수 호출을 제거하고 원래 기준으로 확인합니다. 숫자는 연습 코드의 조건입니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

2. Q2“모듈을 찾을 수 없음”으로 테스트가 실패했습니다. 버그 재현 성공인가요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   아닙니다. 검사할 함수까지 실행되지 않았습니다. 실행 경로를 고친 뒤 실제 기록 수가 2라는 실패를 확인해야 합니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

3. Q3로컬 검사가 통과했으니 동시 요청에도 정확히 한 통만 간다고 보고해도 될까요?

   내 생각 적기 (선택)

   내 생각 적기 (선택)

   작성 내용은 전송되지 않으며, 페이지를 떠나거나 새로고침하면 사라져요. 필요한 내용은 복사해 두세요.

   답과 해설 보기

   아닙니다. 이 검사는 한 호출 내부의 중복만 다룹니다. 동시 요청과 재시도의 전달 보장은 식별자·저장소·발송 시스템을 포함한 별도 설계와 검사가 필요합니다.

   해설을 읽고 이해했어요

   직접 비교한 표시이며 자동 채점은 아니에요.

1. 6

   직접 해 보기: 두 번째 검사 추가하기

   첫 검사를 보존한 채 다른 수신자로 한 번 더 호출하는 검사를 만드세요. 새 가짜 mailer를 쓰고 두 수신자가 각각 전달되는지 확인합니다. 함수 안에 user@example.com을 하드코딩한 잘못된 수정이라면 이 검사가 잡아내야 합니다.

   다음에는 send가 오류를 던지는 가짜 mailer를 만들고 requestPasswordReset도 거부되는지 검사합니다. 오류 문구가 예쁘게 보이는지보다 실패가 호출자에게 전달되는지를 봅니다. 네트워크 없는 검사이므로 실제 메일은 한 통도 나가지 않습니다.

   정상 수신자, 다른 수신자, 발송 실패의 결과를 기록하고 도우미에게 변경 설명을 요청하세요. 설명에 “모든 중복 발송 해결”처럼 확인하지 않은 범위가 들어가면 바로 고칩니다. 완료 보고도 코드와 마찬가지로 검증한 사실에 맞춰야 합니다.