개발자가 AI를 잘못 쓰는 가장 흔한 방식은 도구가 약해서가 아니라 시작점을 잘못 잡아서다. 기능 전체를 맡기고, 서비스 구조를 바꾸게 하고, 설계 판단까지 넘기면 신뢰가 빨리 깨진다.

프로덕션 코드를 쓰고, PR을 리뷰하고, 장애를 디버깅하고, 내부 도구를 유지하는 개발자라면 시작점은 더 좁아야 한다. AI가 유용한 지점은 판단을 대신하는 것이 아니라, 비싼 작업 구간 하나를 줄여주는 데 있다.

이 글은 실무에서 바로 써먹을 수 있는 다섯 가지 시작점을 다룬다. 코드 초안 만들기, 디버깅 속도 높이기, 제약 있는 리팩터링, 기존 동작을 테스트로 바꾸기, 이미 있는 코드를 문서화하기다.

1. 완성이 아니라 초안을 맡긴다

가장 안전한 시작은 “기능 전체를 써 달라”가 아니라 “첫 초안을 만들어 달라”는 식이다. 그러면 개발자는 비어 있는 화면 대신 구체적인 초안을 기준으로 수정할 수 있다.

헬퍼 함수, API 클라이언트 래퍼, 검증 로직, 반복되는 보일러플레이트 같은 영역은 특히 잘 맞는다.

예를 들어 Copilot, Cursor, ChatGPT에 비슷한 엔드포인트 세 개에 대한 typed fetch wrapper 초안을 요청할 수 있다. 대신 파라미터 이름, 에러 처리, retry 정책, 로그 포맷은 개발자가 직접 검토해야 한다.

좋은 요청 예시: 이 세 엔드포인트에 대한 typed fetch wrapper 초안을 만들어 달라. 응답 shape는 유지하고, 에러 처리는 명시적으로 넣되 retry나 caching은 추가하지 마라.

2. 디버깅 루프를 줄이는 데 쓴다

AI는 새 기능 생성보다 디버깅에서 더 유용한 경우가 많다. 짧은 오류 요약, 스택 트레이스, 실패 조건만 있어도 가능한 원인이나 빠진 체크 포인트를 더 빨리 좁힐 수 있다.

첫 답을 믿는 게 목적이 아니라, 더 좋은 디버깅 가설에 빨리 도달하는 것이 목적이다.

실제로는 “이 요청 로그, 스택 트레이스, 최근 변경점을 보고 가장 가능성 높은 원인 세 가지와 먼저 볼 위치를 정리해 달라” 정도만 던져도 된다. 맹목적으로 찾는 시간을 줄이는 데 효과가 크다.

이럴 때 좋다: 범인을 빠르게 좁히고, 빠진 체크 포인트를 찾고, 어디부터 볼지 우선순위를 정해야 할 때다.

3. 제약 있는 리팩터링에 쓴다

리팩터링은 현재 코드가 이미 있고 목표도 좁게 줄 수 있기 때문에 AI와 잘 맞는다. 함수 분리, 이름 정리, 테스트하기 쉬운 구조로 바꾸기, 중복 로직 추출 같은 작업이 대표적이다.

범위가 좁을수록 리뷰가 쉬워지고, 미묘한 오작동 위험도 낮아진다.

“이 파일 정리해 줘”보다 “중복된 validation만 helper로 빼 달라”, “200줄 handler를 세 함수로만 나눠 달라”, “동작은 유지하고 분기 이름만 정리해 달라”처럼 제약을 주는 방식이 더 안전하다.

안전한 제약: 동작은 바꾸지 말고, API shape와 side effect와 외부 의존성은 유지하라고 명시한다.

4. 기존 동작을 테스트로 바꾸는 데 쓴다

모듈이 어떻게 동작해야 하는지는 알고 있지만 테스트 작성은 미루는 경우가 많다. 이때 AI는 함수 동작, API 응답, 엣지 케이스를 바탕으로 첫 테스트 목록을 빠르게 만드는 데 쓸 수 있다.

이미 코드가 있고 그 주변을 테스트로 감싸야 할 때 특히 효율적이다.

예를 들어 함수 하나를 붙여 넣고 “happy path, input validation, null case, regression case를 기준으로 Vitest 테스트 목록을 뽑아 달라”고 하면 첫 테스트 매트릭스를 빠르게 만들 수 있다.

기대해야 할 것: 완벽한 테스트 코드가 아니라, 검토할 만한 첫 테스트 표면을 빠르게 얻는 것이다.

5. 나중에라도 문서화를 시작하는 데 쓴다

문서화는 항상 뒤로 밀린다. 하지만 구현이 끝난 뒤 파일 역할, 라우트, 설정 책임, 실행 순서를 요약하는 데 AI를 쓰면 시작 장벽이 훨씬 낮아진다.

핵심은 멋진 홍보 문구가 아니라 내부 명확성이다. 이 파일이 무엇을 하는지, 이 스크립트가 무엇을 기대하는지, 무엇이 바뀌면 깨질 수 있는지를 분명히 하는 것이다.

좋은 출력은 README 초안, 신규 팀원을 위한 셋업 메모, “이 cron job이 무엇을 하는지” 요약, 배포 스크립트 위에 붙는 짧은 설명 같은 것이다. 화려한 문구보다 다시 읽을 수 있는 문서가 중요하다.

이렇게 요청하면 된다: 이 모듈이 하는 일, 입력값, 깨질 수 있는 지점, 다른 개발자가 변경 전에 읽어야 할 것을 짧게 정리해 달라.

개발자가 초반에 피해야 할 것은?

가장 큰 실수는 리뷰 습관이 없는데도 AI를 판단 대체 수단으로 쓰는 것이다. 정확성, 테스트, 경계 조건, 보안 영향을 빨리 검증할 수 없다면 더 넓은 자동화는 아직 이르다.

처음에는 검토 비용이 낮은 구간부터 시작해야 한다. 그리고 자기 코드베이스에서 “좋은 출력”이 무엇인지 감이 생긴 뒤에야 범위를 넓히는 게 맞다.

다음에 보면 좋은 글

개발자용 AI 블로그를 계속 읽는다면 다음 단계도 같은 원칙으로 가면 된다. 이번 주에는 다섯 개 중 하나만 골라 실제로 써 보고, 두세 번 검토 비용이 낮게 유지되는지 확인한 뒤에만 범위를 넓힌다.

개발자 AI 블로그 유닛과 예정 글 보기.