28장. AI와 함께 코드 작성하기

앞 장에서는 AI 코딩 도구의 종류와 특징을 살펴보았다.

GitHub Copilot, Cursor, JetBrains AI, Claude Code, ChatGPT 같은 도구는 모두 개발자의 코드 작성 과정을 도와준다.
하지만 도구마다 잘하는 일이 다르고, 사용 방식도 다르다.

이번 장에서는 한 단계 더 들어가서 실제로 AI와 함께 코드를 작성하는 방법을 살펴본다.

AI에게 단순히 “코드 만들어줘”라고 요청하면 결과가 애매할 때가 많다.
AI는 개발자가 원하는 시스템 구조, 팀의 코드 규칙, 예외 처리 방식, 운영 환경을 기본적으로 알지 못하기 때문이다.

그래서 AI와 함께 코드를 작성할 때는 요청을 잘게 나누고, 필요한 맥락을 제공하고, 결과를 검토하는 습관이 필요하다.

이번 장에서는 다음 흐름을 중심으로 살펴본다.

- 요구사항을 코드로 바꾸기
- 기존 코드 분석시키기
- 리팩토링 요청하기
- 테스트 코드 생성하기
- 버그 원인 찾기
- 코드 설명 문서 만들기
- 큰 작업을 작은 단위로 나눠 요청하기
- AI에게 코드 맥락을 전달하는 방법
- AI가 만든 코드를 검토하는 기본 습관

AI는 코드를 빠르게 만들 수 있다.
하지만 좋은 코드는 단순히 빠르게 만들어진 코드가 아니다.

요구사항에 맞고, 팀의 구조에 맞고, 장애 상황을 고려하고, 운영 중에도 추적 가능한 코드가 좋은 코드다.

AI와 함께 코드를 작성할 때도 이 기준은 달라지지 않는다.

1. AI에게 코드를 요청하기 전에 해야 할 일

AI에게 코드를 요청하기 전에 먼저 해야 할 일이 있다.

바로 “무엇을 만들 것인지”를 정리하는 것이다.

많은 사람이 AI에게 바로 이렇게 요청한다.

로그인 API 만들어줘.

게시글 CRUD 만들어줘.

결제 취소 기능 만들어줘.

이런 요청은 너무 넓다.

AI는 어떤 언어를 쓸지 모른다.
어떤 프레임워크를 쓰는지 모른다.
DB 구조도 모른다.
인증 방식도 모른다.
팀에서 사용하는 응답 형식도 모른다.

그래서 결과는 보통 일반적인 예제 코드가 된다.

예제 코드는 학습용으로는 도움이 된다.
하지만 실무 코드로 바로 쓰기에는 부족하다.

AI에게 코드를 요청하기 전에는 최소한 다음을 정리해야 한다.

- 어떤 기능을 만들 것인가
- 어떤 언어와 프레임워크를 사용하는가
- 기존 프로젝트 구조는 어떤가
- 입력값은 무엇인가
- 출력값은 무엇인가
- 실패할 수 있는 경우는 무엇인가
- 인증과 권한이 필요한가
- DB 접근 방식은 어떻게 하는가
- 로그나 감사 기록이 필요한가
- 테스트가 필요한 케이스는 무엇인가

이 내용을 모두 길게 설명해야 하는 것은 아니다.
하지만 중요한 조건이 빠지면 AI는 일반적인 방식으로 코드를 만든다.

실무에서는 일반적인 코드보다 “우리 서비스에 맞는 코드”가 중요하다.

2. 요구사항을 코드로 바꾸기

AI와 함께 코드를 작성할 때 가장 먼저 할 수 있는 일은 요구사항을 코드 구조로 바꾸는 것이다.

예를 들어 다음과 같은 요구사항이 있다고 해보자.

관리자가 특정 사용자를 차단할 수 있어야 한다.

이 요구사항만 보면 간단해 보인다.
하지만 실제 코드로 만들려면 더 많은 질문이 필요하다.

- 누가 차단할 수 있는가
- 어떤 사용자를 차단할 수 있는가
- 이미 차단된 사용자를 다시 차단하면 어떻게 할 것인가
- 차단되면 로그인 세션은 유지되는가
- 차단 사유를 저장해야 하는가
- 관리자 감사 로그를 남겨야 하는가
- 사용자에게 알림을 보내야 하는가
- 차단 해제 기능도 필요한가

AI에게 바로 “사용자 차단 API 만들어줘”라고 하면 이런 조건이 빠질 수 있다.

그래서 먼저 AI에게 요구사항을 코드로 바꾸기 전에 질문을 뽑아달라고 할 수 있다.

관리자 사용자 차단 기능을 만들려고 한다.

바로 코드를 만들지 말고,
먼저 백엔드 개발 관점에서 확인해야 할 요구사항을 정리해줘.

인증, 권한, DB, 로그, 예외 처리, 운영 관점으로 나눠서 정리해줘.

이렇게 요청하면 AI는 구현 전에 확인해야 할 항목을 정리해준다.

그다음 필요한 조건을 선택해서 다시 코드 생성을 요청하는 것이 좋다.

조건은 다음과 같다.

- 관리자만 사용자 차단 가능
- 이미 차단된 사용자를 다시 차단하면 성공 처리하되 변경하지 않음
- 차단 사유는 최대 200자
- 차단 시 기존 로그인 세션 삭제
- 관리자 ID, 대상 사용자 ID, 차단 사유, 처리 시간을 감사 로그로 저장
- PHP 기반 Controller, Service, Repository 구조 사용
- Controller는 요청 검증과 Service 호출만 담당
- 실제 SQL은 작성하지 말고 Repository 메서드 형태로 작성

이 조건으로 코드 초안을 만들어줘.

이렇게 하면 AI의 결과가 훨씬 실무에 가까워진다.

코드를 잘 만들려면 먼저 요구사항을 잘 나눠야 한다.
AI는 이 요구사항 분해 과정에서도 도움을 줄 수 있다.

3. 나쁜 요청과 좋은 요청

AI에게 코드를 요청할 때 결과 품질은 요청 품질에 크게 영향을 받는다.

나쁜 요청은 보통 짧고 모호하다.

게시판 만들어줘.

이 코드 리팩토링해줘.

버그 고쳐줘.

테스트 코드 만들어줘.

이런 요청은 AI가 알아서 추측해야 하는 부분이 너무 많다.

좋은 요청은 맥락과 기준이 있다.

PHP 8.2 기준으로 게시글 목록 조회 API 초안을 만들어줘.

조건:
- Controller, Service, Repository 구조
- Controller는 요청 파라미터 검증만 수행
- Service는 비즈니스 로직 담당
- Repository는 DB 조회 담당
- page, limit 파라미터 사용
- limit 최대값은 100
- 응답 형식은 { result, message, data } 구조
- 삭제된 게시글은 제외
- 최신순 정렬
- 실제 SQL은 단순 예시로만 작성

이렇게 요청하면 AI는 더 구체적인 코드를 만들 수 있다.

리팩토링 요청도 마찬가지다.

나쁜 요청은 다음과 같다.

이 코드 깔끔하게 고쳐줘.

좋은 요청은 다음과 같다.

아래 코드를 리팩토링해줘.

기준:
- 동작은 바꾸지 말 것
- 중복 조건문을 줄일 것
- 함수 분리는 2개까지만 할 것
- 외부에서 호출하는 public 메서드 이름은 유지할 것
- 예외 처리 방식은 기존 코드 스타일을 따를 것
- 변경 이유를 함께 설명할 것

AI에게 좋은 요청을 한다는 것은 단순히 말을 길게 쓰는 것이 아니다.
AI가 추측해야 할 부분을 줄이는 것이다.

4. 기존 코드 분석시키기

AI는 새 코드를 만드는 것뿐 아니라 기존 코드를 분석하는 데도 유용하다.

특히 오래된 프로젝트에서는 코드의 의도를 파악하는 데 시간이 오래 걸린다.

함수 이름은 있는데 실제로 무엇을 하는지 애매할 수 있다.
비슷한 조건문이 여러 곳에 흩어져 있을 수 있다.
왜 이런 예외 처리가 들어갔는지 문서가 없을 수도 있다.

이럴 때 AI에게 기존 코드를 설명하게 할 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

아래 코드를 설명해줘.

설명할 때는 다음 기준으로 나눠줘.

- 전체 역할
- 입력값과 출력값
- 주요 분기 조건
- DB에 영향을 주는 부분
- 외부 API를 호출하는 부분
- 예외 처리
- 운영 중 주의할 점

이렇게 요청하면 단순 설명보다 실무에 필요한 관점으로 분석할 수 있다.

기존 코드 분석에서 특히 유용한 요청은 다음과 같다.

이 코드에서 사이드 이펙트가 있는 부분을 찾아줘.

이 함수가 DB 상태를 변경하는지 확인해줘.

이 로직에서 중복 실행되면 문제가 될 부분이 있는지 봐줘.

이 코드에서 개인정보가 로그에 남을 가능성이 있는지 확인해줘.

이 함수가 실패했을 때 호출자에게 어떤 영향이 있는지 설명해줘.

사이드 이펙트란?
함수 실행 결과로 외부 상태가 바뀌는 것을 말한다.
예를 들어 DB 저장, 파일 삭제, 외부 API 호출, 메시지 발행, 세션 삭제 같은 작업은 사이드 이펙트다.

AI의 코드 분석은 특히 처음 보는 코드에서 빠른 이해를 도와준다.

하지만 AI가 분석한 내용이 항상 정확한 것은 아니다.

AI가 “이 함수는 사용자 상태를 변경한다”고 말했더라도, 실제 Repository 내부에서 아무 변경도 하지 않을 수 있다.
반대로 AI가 놓친 외부 호출이 있을 수도 있다.

따라서 AI의 분석은 코드 이해를 위한 출발점으로 사용해야 한다.
최종 판단은 실제 코드와 실행 흐름을 확인해야 한다.

5. 리팩토링 요청하기

리팩토링은 기능의 외부 동작은 유지하면서 내부 구조를 개선하는 작업이다.

AI는 리팩토링 초안을 만드는 데 유용하다.

중복 코드를 줄이거나, 긴 함수를 나누거나, 조건문을 정리하거나, 이름을 더 명확하게 바꾸는 데 도움을 줄 수 있다.

하지만 리팩토링은 위험한 작업이기도 하다.

겉보기에는 코드가 깔끔해졌지만, 실제 동작이 바뀌면 버그가 된다.

그래서 AI에게 리팩토링을 요청할 때는 반드시 기준을 줘야 한다.

아래 코드를 리팩토링해줘.

조건:
- 외부 동작은 절대 바꾸지 말 것
- public 메서드 이름과 파라미터는 유지할 것
- 반환 형식은 유지할 것
- 예외 메시지는 바꾸지 말 것
- 중복 조건문만 줄일 것
- 변경 전후 차이를 설명할 것
- 테스트해야 할 케이스를 함께 정리할 것

이렇게 요청하면 AI가 과도하게 구조를 바꾸는 것을 줄일 수 있다.

리팩토링 요청은 한 번에 크게 하지 않는 것이 좋다.

나쁜 예시는 다음과 같다.

이 회원 도메인 전체를 리팩토링해줘.

이 요청은 너무 크다.

AI가 여러 파일을 한 번에 바꾸면 검토가 어렵다.
어디서 동작이 바뀌었는지 추적하기도 어렵다.

좋은 방식은 작은 단위로 나누는 것이다.

1단계: 이 함수의 역할을 설명해줘.

2단계: 중복된 조건문을 찾아줘.

3단계: 동작을 바꾸지 않고 조건문만 정리해줘.

4단계: 변경 전후 차이를 설명해줘.

5단계: 테스트 케이스를 만들어줘.

AI와 함께 리팩토링할 때는 “한 번에 많이”보다 “작게 나누고 검토”가 중요하다.

6. 테스트 코드 생성하기

AI가 특히 도움 되는 영역 중 하나가 테스트 코드 작성이다.

테스트 코드는 중요하지만, 많은 개발자가 작성에 부담을 느낀다.
어떤 케이스를 테스트해야 할지 정리하는 것도 시간이 걸린다.

AI에게 테스트 코드를 요청할 때는 단순히 이렇게 말할 수 있다.

이 함수 테스트 코드 만들어줘.

하지만 이 요청은 부족하다.

더 좋은 요청은 테스트해야 할 조건을 함께 알려주는 것이다.

아래 함수에 대한 테스트 코드를 만들어줘.

테스트 케이스:
- 정상적으로 사용자를 조회하는 경우
- 사용자가 존재하지 않는 경우
- Repository에서 예외가 발생하는 경우
- 권한이 없는 사용자가 요청한 경우

조건:
- PHPUnit 기준
- Repository는 Mock으로 처리
- 테스트 이름은 한글 설명이 아니라 영어 메서드명으로 작성
- 각 테스트가 무엇을 검증하는지 주석으로 설명

이렇게 요청하면 AI가 더 실무에 가까운 테스트 코드를 만들 수 있다.

테스트 코드 생성에서 AI에게 시킬 수 있는 일은 크게 세 가지다.

첫째, 테스트 케이스를 뽑게 할 수 있다.

이 기능에서 테스트해야 할 케이스를 정상, 실패, 예외, 권한 관점으로 나눠서 정리해줘.

둘째, 실제 테스트 코드 초안을 만들게 할 수 있다.

위 테스트 케이스를 기준으로 PHPUnit 테스트 코드를 만들어줘.

셋째, 테스트 누락 여부를 점검하게 할 수 있다.

아래 테스트 코드에서 빠진 케이스가 있는지 봐줘.

특히 경계값, 권한, 예외 상황을 기준으로 확인해줘.

다만 AI가 만든 테스트도 그대로 믿으면 안 된다.

자주 생기는 문제는 다음과 같다.

- 테스트가 실제 검증을 하지 않는다
- Mock 설정이 틀렸다
- 프로젝트 테스트 프레임워크와 맞지 않는다
- 중요한 실패 케이스가 빠졌다
- 내부 구현에 너무 강하게 의존한다
- 테스트는 통과하지만 의미가 없다

좋은 테스트는 단순히 실행되는 코드가 아니다.
요구사항이 깨졌을 때 실패하는 코드다.

AI가 만든 테스트는 초안으로 사용하고, 개발자가 검증 의미를 확인해야 한다.

7. 버그 원인 찾기

AI는 버그 원인을 찾는 과정에서도 사용할 수 있다.

특히 오류 메시지, 로그, 스택 트레이스, 최근 변경 코드가 있을 때 도움이 된다.

예를 들어 다음과 같이 요청할 수 있다.

아래 오류 로그를 보고 원인 후보를 정리해줘.

단, 확정하지 말고 가능성이 높은 순서로 정리해줘.

각 원인별로 추가로 확인해야 할 로그나 코드를 함께 알려줘.

이 요청에서 중요한 것은 “확정하지 말고”라는 표현이다.

AI는 오류 원인을 단정적으로 말할 때가 있다.
하지만 실제 장애 분석에서는 여러 가능성을 열어두고 확인해야 한다.

좋은 버그 분석 요청은 다음 정보를 포함한다.

- 오류 메시지
- 발생 시점
- 최근 배포 여부
- 재현 조건
- 관련 코드
- 입력값 예시
- 기대한 결과
- 실제 결과
- 이미 확인한 내용

예를 들어 다음처럼 요청할 수 있다.

결제 취소 API에서 간헐적으로 500 오류가 발생한다.

상황:
- 전체 요청 중 일부에서만 발생
- 최근 배포 후 발생 빈도가 증가
- PG사 응답 timeout 로그가 일부 있음
- DB에는 취소 요청 기록이 남아 있음
- 사용자에게는 실패 응답이 내려감

아래 로그와 코드를 보고 원인 후보를 정리해줘.

원인 후보, 확인할 로그, 추가로 넣으면 좋은 방어 코드로 나눠서 설명해줘.

이렇게 요청하면 AI는 장애 분석 문서 초안처럼 정리해줄 수 있다.

하지만 장애나 버그 원인 분석에서는 특히 조심해야 한다.

AI가 제안한 원인은 가설이다.
실제 원인은 로그, 메트릭, DB 상태, 외부 API 응답, 배포 이력으로 확인해야 한다.

AI는 “가능성 높은 후보”를 정리하는 데 도움을 줄 수 있다.
하지만 장애 원인을 확정하는 주체는 운영자와 개발자다.

8. 코드 설명 문서 만들기

개발자가 AI를 유용하게 쓸 수 있는 또 다른 영역은 문서화다.

실무에서는 코드보다 문서가 부족한 경우가 많다.

기능은 동작하지만 왜 그렇게 만들었는지 기록이 없을 수 있다.
운영자가 봐야 하는 처리 흐름이 코드 안에만 있을 수 있다.
신규 입사자가 구조를 이해하는 데 시간이 오래 걸릴 수 있다.

AI는 기존 코드를 기반으로 설명 문서 초안을 만들 수 있다.

예를 들어 다음과 같이 요청할 수 있다.

아래 코드 흐름을 개발 문서 형태로 정리해줘.

포함할 내용:
- 기능 목적
- 요청 흐름
- 주요 클래스 역할
- DB 변경 사항
- 외부 API 호출 여부
- 예외 처리 방식
- 운영 시 주의할 점

문서화할 때는 단순히 코드 설명만 하면 부족하다.

실무 문서에는 운영 관점이 들어가야 한다.

- 실패하면 어떤 로그를 봐야 하는가
- 재처리가 가능한가
- 중복 실행되어도 안전한가
- 데이터 정합성 문제는 없는가
- 장애 시 수동 복구가 필요한가
- 권한이 필요한 관리자 기능인가

AI에게 문서를 요청할 때도 이런 항목을 포함하는 것이 좋다.

예를 들어 다음처럼 요청할 수 있다.

이 코드를 운영 인수인계 문서 형태로 정리해줘.

개발자가 아니라 운영 담당자도 이해할 수 있게 설명해줘.

장애 발생 시 확인할 로그, 재처리 가능 여부, 주의할 데이터를 포함해줘.

이렇게 하면 코드 설명을 넘어 운영 문서 초안으로 활용할 수 있다.

다만 AI가 만든 문서도 코드와 마찬가지로 검토해야 한다.

AI가 코드에 없는 내용을 추측해서 문서에 넣을 수 있다.
예를 들어 실제로는 재처리 기능이 없는데 “재처리 가능”이라고 적을 수도 있다.

문서는 코드보다 더 쉽게 신뢰받는다.
그래서 AI가 만든 문서는 반드시 실제 코드와 비교해야 한다.

9. 큰 작업을 작은 단위로 나눠 요청하기

AI와 함께 코드 작업을 할 때 가장 중요한 습관 중 하나는 큰 작업을 작은 단위로 나누는 것이다.

큰 요청은 실패하기 쉽다.

예를 들어 다음 요청을 보자.

회원 서비스를 MSA 구조로 리팩토링해줘.

이 요청은 너무 크다.

MSA로 리팩토링하려면 단순히 코드를 나누는 문제가 아니다.

- 도메인 경계
- DB 분리 여부
- API 계약
- 인증 구조
- 트랜잭션 처리
- 이벤트 발행
- 데이터 동기화
- 장애 대응
- 배포 전략
- 모니터링

이런 문제를 함께 봐야 한다.

AI에게 이런 작업을 한 번에 맡기면 그럴듯한 답변은 나오지만, 실제 적용하기 어렵다.

큰 작업은 다음처럼 나눠야 한다.

1단계: 현재 코드 구조 설명시키기
2단계: 도메인 경계 후보 정리하기
3단계: 외부 의존성 찾기
4단계: DB 테이블 의존성 정리하기
5단계: 먼저 분리 가능한 함수 찾기
6단계: 작은 리팩토링부터 적용하기
7단계: 테스트 케이스 만들기
8단계: 배포 영향도 정리하기

AI에게도 단계별로 요청하는 것이 좋다.

먼저 이 코드에서 회원 도메인과 직접 관련된 함수만 찾아줘.

아직 코드는 수정하지 말고, 파일명과 역할만 정리해줘.

다음 단계에서는 이렇게 요청할 수 있다.

위에서 찾은 함수 중 외부 결제, 방송, 채팅 도메인과 연결된 부분을 분리해서 표시해줘.

그리고 그다음에야 수정 요청을 할 수 있다.

이 함수 하나만 리팩토링해줘.

동작은 바꾸지 말고,
외부 도메인 호출 부분을 별도 메서드로 분리해줘.

작게 나누면 AI 결과를 검토하기 쉽다.
문제가 생겨도 되돌리기 쉽다.
팀 리뷰도 쉬워진다.

10. AI에게 코드 맥락을 전달하는 방법

AI가 좋은 코드를 만들려면 맥락이 필요하다.

맥락이 부족하면 AI는 일반적인 예제 코드를 만든다.

실무에서 필요한 맥락은 다음과 같다.

- 사용하는 언어와 버전
- 사용하는 프레임워크
- 프로젝트 구조
- 기존 코드 스타일
- 입력값과 출력값
- 예외 처리 방식
- 응답 포맷
- DB 접근 방식
- 인증과 권한 구조
- 로그 정책
- 테스트 프레임워크
- 수정하면 안 되는 부분

예를 들어 다음 요청은 맥락이 부족하다.

사용자 조회 API 만들어줘.

더 나은 요청은 다음과 같다.

PHP 8.2 기반 프로젝트다.

구조:
- Controller는 요청 검증과 Service 호출만 담당
- Service는 비즈니스 로직 담당
- Repository는 DB 접근 담당

응답 형식:
- 성공: { result: true, message: "", data: {...} }
- 실패: { result: false, message: "에러 메시지", data: null }

요구사항:
- userIdx로 사용자 조회
- 탈퇴한 사용자는 조회하지 않음
- 사용자가 없으면 result false 반환
- Repository 메서드는 findActiveUserByIdx로 작성
- 실제 SQL은 작성하지 말고 메서드 형태로만 작성

이 기준으로 Controller, Service, Repository 예시 코드를 만들어줘.

이렇게 맥락을 주면 AI가 프로젝트에 더 맞는 코드를 만들 수 있다.

또 하나 중요한 방법은 “하지 말아야 할 것”을 알려주는 것이다.

다음은 하지 말아줘.

- Controller에 DB 쿼리 작성 금지
- 새로운 외부 라이브러리 추가 금지
- public 메서드 이름 변경 금지
- 기존 응답 구조 변경 금지
- 실제 API 키나 설정값 하드코딩 금지

AI는 요청받은 것을 수행하려고 한다.
하지만 금지 조건을 알려주지 않으면 불필요한 변경을 할 수 있다.

실무에서는 “무엇을 해라”만큼 “무엇은 하지 마라”도 중요하다.

11. AI가 만든 코드를 검토하는 기본 습관

AI가 만든 코드는 반드시 검토해야 한다.

검토 기준은 사람이 만든 코드와 크게 다르지 않다.
다만 AI 코드는 그럴듯해 보여도 실제로 틀릴 수 있기 때문에 더 의식적으로 봐야 한다.

기본 검토 항목은 다음과 같다.

특히 AI 코드는 다음 부분을 자주 놓친다.

- 권한 검증
- 트랜잭션 처리
- 중복 요청 방어
- 실패 시 롤백
- 대량 데이터 성능
- 개인정보 마스킹
- 감사 로그
- 기존 공통 모듈 사용
- 팀의 네이밍 규칙
- 운영 환경 설정

AI가 만든 코드를 리뷰할 때는 이런 질문을 해보면 좋다.

이 코드를 내가 직접 설명할 수 있는가?

장애가 나면 어디를 확인해야 하는가?

같은 요청이 두 번 들어오면 안전한가?

권한 없는 사용자가 호출하면 막히는가?

실패했을 때 데이터가 어중간하게 남지 않는가?

운영 로그에 개인정보가 남지 않는가?

테스트 없이 배포해도 될 만큼 단순한가?

마지막 질문의 답은 대부분 “아니다”가 되어야 한다.

AI가 만든 코드일수록 테스트와 리뷰가 필요하다.

12. AI와 페어 프로그래밍하듯 작업하기

AI와 함께 코드를 작성하는 좋은 방식은 페어 프로그래밍처럼 사용하는 것이다.

페어 프로그래밍은 두 명의 개발자가 함께 코드를 작성하는 방식이다.
한 명이 코드를 작성하고, 다른 한 명이 옆에서 방향과 문제를 함께 본다.

AI도 비슷하게 사용할 수 있다.

AI에게 모든 작업을 맡기는 것이 아니라, 다음과 같이 역할을 나눌 수 있다.

개발자:
- 요구사항 판단
- 도메인 규칙 확인
- 코드 검토
- 최종 결정
- 테스트 실행
- 운영 영향 판단

AI:
- 코드 초안 작성
- 반복 코드 생성
- 누락 가능성 점검
- 테스트 케이스 제안
- 문서 초안 작성
- 오류 원인 후보 정리

이렇게 보면 AI는 동료 개발자라기보다, 빠르게 초안을 만들어주는 보조자에 가깝다.

예를 들어 작업 흐름은 다음과 같이 만들 수 있다.

1. 개발자가 요구사항을 정리한다.
2. AI에게 구현 전에 확인할 질문을 뽑게 한다.
3. 개발자가 필요한 조건을 확정한다.
4. AI에게 코드 초안을 만들게 한다.
5. 개발자가 코드를 검토한다.
6. AI에게 테스트 케이스를 만들게 한다.
7. 개발자가 테스트를 보완한다.
8. PR에서 사람이 최종 리뷰한다.

이 흐름의 핵심은 AI가 중간중간 도와주지만, 방향과 책임은 개발자가 가진다는 점이다.

AI와 함께 일할수록 개발자의 판단력은 더 중요해진다.

13. 실무 예시: 기능 추가 요청 흐름

이번에는 AI와 함께 기능을 추가하는 흐름을 하나의 예시로 보자.

요구사항은 다음과 같다.

사용자가 자신의 닉네임을 변경할 수 있어야 한다.

바로 코드부터 요청하지 말고, 먼저 확인할 항목을 AI에게 정리시킨다.

사용자 닉네임 변경 기능을 만들려고 한다.

백엔드 개발 관점에서 구현 전에 확인해야 할 내용을 정리해줘.

입력값 검증, 중복 검사, 권한, DB, 로그, 운영 관점으로 나눠줘.

AI는 다음과 같은 항목을 제안할 수 있다.

- 닉네임 길이 제한
- 허용 문자 기준
- 금칙어 검사
- 중복 닉네임 허용 여부
- 변경 횟수 제한
- 로그인 사용자와 대상 사용자가 같은지 확인
- 변경 이력 저장 여부
- 관리자 감사 로그 필요 여부
- 캐시 갱신 필요 여부
- 검색 인덱스 갱신 필요 여부

이 중 필요한 조건을 확정한다.

조건은 다음과 같다.

- 로그인한 사용자 본인만 닉네임 변경 가능
- 닉네임은 2자 이상 20자 이하
- 한글, 영문, 숫자만 허용
- 중복 닉네임 불가
- 금칙어 검사는 forbiddenWordService를 사용
- 변경 이력 저장 필요
- 캐시 삭제 필요
- PHP 기반 Controller, Service, Repository 구조
- 응답 형식은 { result, message, data }

이 기준으로 코드 초안을 만들어줘.

AI가 코드를 만들면 바로 적용하지 않는다.

다음 요청으로 검토를 시킨다.

방금 만든 코드에서 빠진 예외 케이스가 있는지 봐줘.

특히 중복 요청, 캐시 삭제 실패, 변경 이력 저장 실패 관점에서 확인해줘.

그다음 테스트 케이스를 요청한다.

이 기능의 테스트 케이스를 정리해줘.

정상, 입력값 오류, 중복 닉네임, 금칙어, 권한 오류, 캐시 삭제 실패로 나눠줘.

이 흐름은 AI를 단순 코드 생성기로 쓰는 것보다 안전하다.

요구사항 정리 → 코드 초안 → 위험 검토 → 테스트 케이스 순서로 사용하면 AI의 장점을 살리면서도 실무 리스크를 줄일 수 있다.

14. AI 코드 작성에서 피해야 할 습관

AI와 함께 코드를 작성할 때 피해야 할 습관도 있다.

첫째, AI가 만든 코드를 읽지 않고 붙여넣는 것이다.

가장 위험한 습관이다.

코드가 그럴듯해 보이고 컴파일이 되더라도, 실제 요구사항과 다를 수 있다.

둘째, 한 번에 너무 큰 작업을 맡기는 것이다.

이 프로젝트 전체를 최신 구조로 바꿔줘.

모든 API를 리팩토링해줘.

테스트 코드를 전체 생성해줘.

이런 요청은 결과가 커지고 검토가 어려워진다.

셋째, 운영 로그나 개인정보를 그대로 넣는 것이다.

버그 분석을 위해 로그를 넣을 수는 있다.
하지만 사용자 ID, 전화번호, 이메일, 토큰, 세션값, 결제 정보는 제거해야 한다.

넷째, AI의 설명을 공식 문서처럼 믿는 것이다.

AI는 틀릴 수 있다.
특히 라이브러리 버전, 프레임워크 옵션, 클라우드 설정, 보안 정책은 실제 문서를 확인해야 한다.

다섯째, 테스트 없이 병합하는 것이다.

AI가 만든 코드는 사람이 만든 코드와 똑같이 테스트해야 한다.
중요한 도메인이라면 오히려 더 강하게 검증해야 한다.

여섯째, 팀 규칙과 다른 코드를 허용하는 것이다.

AI가 만든 코드가 깔끔해 보여도 팀의 구조와 다르면 유지보수 비용이 늘어난다.

AI는 코드를 잘 만들 수 있다.
하지만 팀의 맥락을 모르면 팀에 맞지 않는 코드를 만들 수 있다.

15. AI와 함께 코드 작성 시 사용할 수 있는 요청 패턴

실무에서 바로 사용할 수 있는 요청 패턴을 몇 가지 정리해보자.

요구사항 정리용 요청이다.

이 기능을 구현하기 전에 확인해야 할 요구사항을 정리해줘.

백엔드 개발 관점에서
입력값, 권한, DB, 외부 API, 로그, 예외 처리, 운영 관점으로 나눠줘.

코드 초안 생성용 요청이다.

아래 조건을 기준으로 코드 초안을 만들어줘.

단, 실제 운영에 바로 넣을 코드는 아니고 구조를 검토하기 위한 초안으로 작성해줘.

Controller, Service, Repository 역할을 분리해줘.

리팩토링 요청이다.

아래 코드를 리팩토링해줘.

동작은 바꾸지 말고,
중복 제거와 가독성 개선만 해줘.

public 메서드 이름과 반환 형식은 유지해줘.

위험 검토 요청이다.

이 코드에서 운영 중 문제가 될 수 있는 부분을 찾아줘.

권한, 트랜잭션, 재시도, 중복 요청, 로그, 개인정보 관점으로 봐줘.

테스트 케이스 요청이다.

이 기능에 필요한 테스트 케이스를 정리해줘.

정상 케이스, 입력값 오류, 권한 오류, 외부 API 실패, DB 실패, 중복 요청으로 나눠줘.

문서화 요청이다.

이 코드 흐름을 개발 문서로 정리해줘.

기능 목적, 요청 흐름, 주요 클래스 역할, DB 변경, 예외 처리, 운영 주의사항을 포함해줘.

코드 리뷰 요청이다.

아래 코드를 PR 리뷰어 관점에서 검토해줘.

단순 스타일 말고,
장애 가능성, 보안, 권한, 데이터 정합성, 테스트 누락 중심으로 봐줘.

이런 요청 패턴을 잘 활용하면 AI를 더 안정적으로 사용할 수 있다.

중요한 것은 AI에게 완성품을 요구하는 것이 아니라, 개발 과정의 각 단계에서 보조 역할을 맡기는 것이다.

16. 정리

AI와 함께 코드를 작성하는 핵심은 “AI에게 코드를 맡기는 것”이 아니다.

요구사항을 정리하고, 작업을 작은 단위로 나누고, AI가 만든 결과를 검토하면서 개발 속도를 높이는 것이다.

AI는 요구사항을 코드 구조로 바꾸는 데 도움을 줄 수 있다.
기존 코드를 분석하고, 리팩토링 방향을 제안하고, 테스트 케이스를 만들고, 버그 원인 후보를 정리할 수 있다.
또 코드 설명 문서나 운영 인수인계 문서 초안을 작성하는 데도 유용하다.

하지만 AI가 만든 결과는 항상 검토해야 한다.

AI는 팀의 비즈니스 규칙을 완전히 알지 못한다.
운영 환경의 예외 상황도 모두 알지 못한다.
보안 정책, 감사 로그, 권한 구조, 데이터 정합성 기준을 놓칠 수 있다.

그래서 AI와 함께 코드를 작성할 때는 다음 원칙을 기억해야 한다.

- 바로 코드부터 요청하지 않는다
- 요구사항을 먼저 정리한다
- 큰 작업은 작은 단위로 나눈다
- 코드 맥락을 충분히 제공한다
- 하지 말아야 할 조건도 알려준다
- AI가 만든 코드는 직접 설명할 수 있어야 한다
- 테스트와 리뷰 없이 병합하지 않는다

AI는 좋은 개발자를 더 빠르게 만들어줄 수 있다.
하지만 개발자의 판단을 대신할 수는 없다.

AI를 잘 쓰는 개발자는 코드를 많이 생성하는 사람이 아니라, AI가 만든 결과를 올바르게 검토하고 서비스에 맞게 조정할 수 있는 사람이다.

28장 핵심 요약