품질 지키기

빠르게 만드는 것과 좋은 코드를 갖는 것은 다른 문제다. 검토 없이 받아들인 코드가 쌓이면, 동작은 하지만 아무도 이해하지 못하는 코드 더미가 된다. 이 강의는 속도를 유지하면서도 품질과 안전을 지키는 습관을 다룬다.

학습 목표

• 생성된 코드를 읽고 핵심을 이해한다.
• 적절한 테스트를 요청하고 활용한다.
• 언제 에이전트에 맡기고 언제 직접 손볼지 판단한다.
• 비밀값(키·토큰)과 보안을 안전하게 다룬다.

받은 코드를 읽는다

가장 중요한 습관이다. 모든 줄을 외울 필요는 없지만, 적어도 이 정도는 답할 수 있어야 한다.

• 이 코드는 무엇을 입력받아 무엇을 내보내는가?
• 데이터는 어디에 저장되고 어떻게 흐르는가?
• 실패하면(네트워크 오류, 빈 값) 어떻게 되는가?

이해가 안 되면 그대로 두지 말고 설명을 요청한다.

> 방금 추가한 useEffect가 무슨 일을 하는지 한 줄씩 설명해줘.
> 의존성 배열이 왜 이렇게 되어 있어?

설명을 읽고도 과하거나 어색하면 단순화를 요청한다. 그럴듯하지만 불필요하게 복잡한 코드는 나중에 부담이 된다.

테스트를 요청한다

핵심 로직에는 테스트를 붙여 두면 이후 변경이 안전해진다.

> 할 일 필터링 함수에 대해 테스트를 작성해줘.
> 빈 목록, 전체 완료, 일부 완료 케이스를 포함해줘.

테스트도 코드이므로 한 번 읽어 본다. 테스트가 의미 있는 것을 검증하는지, 아니면 그냥 통과만 시키는지 확인한다.

npm test

테스트는 "지금 맞다"보다 "나중에 깨지면 알려준다"는 가치가 크다. 다만 프로토타입 단계에서는 모든 것에 테스트를 강제할 필요는 없다. 오래 살아남을 핵심부터 붙인다.

언제 직접 손볼까

바이브 코딩이 항상 최선은 아니다. 다음 경우엔 직접 고치는 게 빠르거나 안전하다.

• 사소한 한두 줄 수정: 설명하는 시간이 고치는 시간보다 길 때.
• 미묘한 핵심 로직: 정확성이 중요한데 내가 더 잘 아는 부분.
• 반복해서 같은 실수를 할 때: 6강처럼 맴돌면 직접 개입.
• 결과를 검증할 수 없는 영역: 맞는지 판단 못 하면 위임이 위험하다.

직접 손보는 것은 실패가 아니다. 운전대를 적절히 잡는 것이다.

비밀값과 보안

이 부분은 타협하지 않는다. 에이전트가 만든 코드라도 보안 문제는 내 책임이다.

• API 키·토큰·비밀번호를 코드에 직접 넣지 않는다. 환경 변수로 분리한다.

# .env (절대 커밋하지 않는다)
API_KEY=sk-xxxxxxxx

const key = process.env.API_KEY;

• .env 같은 비밀 파일은 .gitignore에 넣는다. 커밋 전 git status로 확인한다.
• 실제 키를 대화에 붙여넣지 않는다. 예시는 <YOUR_API_KEY> 같은 자리표시자로.
• 외부 입력은 신뢰하지 않는다. 사용자 입력 검증, SQL/HTML 주입 방지를 명시적으로 요청한다.

> 이 검색 기능에서 사용자 입력이 그대로 쿼리에 들어가지 않게,
> 파라미터 바인딩으로 처리해줘.

생성된 코드에 키가 하드코딩돼 있거나, 검증이 빠져 있는지 직접 눈으로 확인하는 습관이 필요하다.

커밋 전 점검 루틴

• 변경된 파일을 git diff로 훑어본다.
• 비밀값이나 디버그 로그가 섞여 있지 않은지 본다.
• 의도와 다른 파일이 건드려지지 않았는지 확인한다.
• 핵심 로직이면 테스트가 있는지 본다.

요약

품질은 검토에서 나온다. 받은 코드를 읽어 핵심을 이해하고, 모르면 설명을 요청하고, 오래 살아남을 로직엔 테스트를 붙인다. 사소하거나 미묘한 부분은 직접 손보는 편이 나을 때가 있다. 무엇보다 비밀값은 환경 변수로 분리하고 절대 커밋하지 않으며, 외부 입력 검증을 명시적으로 챙긴다. 속도는 검토를 생략하는 데서가 아니라, 작은 단위로 빠르게 검토하는 데서 나온다.