버전이 섞인 코드
- javax 임포트가 3.x 프로젝트에 들어옴
- 제거된 보안 설정 방식으로 작성
- @MockBean처럼 삭제된 애노테이션 사용
- 구버전 전용 설정 속성 이름
이 파트에서 다루는 내용
AI 코드의 특성규칙 파일 고정반드시 확인할 지점적합한 작업과 책임
01
스프링 코드는 AI가 특히 그럴듯하게 만들어 냅니다
Spring은 20년 넘게 쌓인 예제와 블로그 글이 있습니다. 그만큼 AI가 학습한 자료도 많아서, 요청하면 즉시 형태가 갖춰진 코드가 나옵니다.
문제는 그 자료가 여러 버전에 걸쳐 있다는 점입니다. 2015년 글과 2025년 글이 같은 비중으로 섞여 있으니, 생성된 코드에도 시대가 다른 문법이 함께 들어옵니다.
더 까다로운 것은 대부분 컴파일도 되고 실행도 된다는 점입니다. 문제가 드러나는 시점이 운영이라 발견이 늦습니다.
동작하지만 위험한 코드
- 테스트 데이터에서는 빠른데 운영에서 N+1
- 예제용 보안 설정을 그대로 적용
- 트랜잭션 경계가 지나치게 넓음
- 예외를 삼켜 실패가 성공처럼 보임
맥락을 모르는 코드
- 이미 있는 공통 유틸을 다시 만듦
- 팀 규칙과 다른 계층 구조
- MyBatis 프로젝트에 JPA 코드 추가
핵심
AI가 만든 스프링 코드를 검토할 때 첫 질문은 '이게 맞는 코드인가'가 아니라 '이게 우리 버전과 우리 프로젝트에 맞는 코드인가'입니다. 문법 오류보다 버전 불일치와 맥락 불일치가 훨씬 자주 나옵니다.
02
버전과 규칙을 파일로 못 박습니다
매번 대화로 '우리는 3.5 쓰고 있어'라고 알려 주는 것은 관리가 아닙니다. 프로젝트 규칙을 파일로 저장소에 두면 팀 전체가 같은 기준으로 AI를 씁니다.
도구마다 파일 위치가 다릅니다. Cursor는 규칙 디렉터리, GitHub Copilot은 저장소 지침 파일, 도구 중립 형식으로는 AGENTS.md를 씁니다. IDE 코스에서 다룬 내용과 같습니다.
스프링 프로젝트 규칙 파일 예시markdown
# 프로젝트 규칙
## 환경
- Spring Boot 3.5, Java 17, Gradle
- 데이터 접근: JPA (복잡한 조회만 MyBatis)
- 임포트는 jakarta 를 사용한다. javax 는 쓰지 않는다
## 계층 규칙
- Controller: 요청 변환과 검증, 상태 코드 결정까지만
- Service: 업무 규칙과 트랜잭션 경계
- Repository: 데이터 접근만
- 서비스는 웹 타입(HttpServletRequest 등)을 참조하지 않는다
## 코드 규칙
- 의존성은 생성자 주입만 사용한다
- 요청·응답은 record DTO로 주고받고 엔티티를 노출하지 않는다
- 조회 전용 메서드에는 readOnly 트랜잭션을 지정한다
- 테스트 목 객체는 @MockitoBean 을 사용한다
## 금지 사항
- 설정 파일에 비밀번호·토큰을 직접 쓰지 않는다
- 운영 설정에서 ddl-auto 를 create 나 update 로 두지 않는다
- 트랜잭션 안에서 외부 API를 호출하지 않는다
- 요청 범위 밖 파일을 수정하지 않는다
## 검증
- 변경 후 ./gradlew build 로 확인한다
- 변경 파일과 이유를 요약해 보고한다금지 사항을 구체적으로 적는 것이 핵심입니다. '좋은 코드를 작성하라'는 지시는 효과가 없지만 '트랜잭션 안에서 외부 API를 호출하지 않는다'는 그대로 지켜집니다.
03
AI 코드에서 반드시 확인할 지점
앞의 14개 파트에서 다룬 함정 중, AI 생성 코드에서 특히 자주 나타나는 항목을 모았습니다. 리뷰할 때 이 순서로 확인하면 대부분의 문제가 걸립니다.
버전 문법 확인
javax 임포트, 제거된 보안 설정 방식, 삭제된 테스트 애노테이션이 섞여 있지 않은지 봅니다. 컴파일 오류가 없더라도 구버전 속성 이름이 남아 있을 수 있습니다.
주입 방식
필드 주입이 들어오면 생성자 주입으로 바꿉니다. AI는 예제에서 흔한 필드 주입을 자주 생성합니다.
엔티티 직접 노출
컨트롤러가 엔티티를 그대로 받거나 반환하지 않는지 확인합니다. 짧은 코드를 만들려다 자주 발생합니다.
트랜잭션 경계
같은 클래스 내부 호출에 @Transactional이 붙어 있지 않은지, 트랜잭션 안에서 외부 호출이나 파일 처리를 하지 않는지 봅니다.
연관 조회와 N+1
반복문 안에서 연관 데이터를 꺼내는 코드가 있는지 확인합니다. 실행되는 SQL을 한 번은 눈으로 봐야 합니다.
스키마 자동 변경
생성된 설정에 ddl-auto가 create나 update로 들어오는 경우가 있습니다. 예제 설정을 그대로 가져오기 때문입니다.
SQL 문자열 조립
MyBatis 코드에서 값 자리에 문자열 치환이 쓰였는지 확인합니다. 바인딩으로 바꿔야 합니다.
보안 설정 복사
CSRF 비활성화, 모든 요청 허용, 인메모리 계정처럼 예제용 설정이 그대로 들어오는지 봅니다.
Actuator 전체 노출
노출 설정에 별표가 들어오면 즉시 제한합니다.
비밀정보 하드코딩
설정 파일이나 코드에 예시 비밀번호와 키가 남아 있는지 확인합니다. 그대로 커밋되는 사고가 실제로 발생합니다.
중복 구현
이미 있는 공통 클래스를 다시 만들지 않았는지 확인합니다. AI는 기존 코드를 모두 알지 못합니다.
예외 처리
예외를 잡고 아무것도 하지 않거나, 모든 예외를 500으로 뭉개지 않는지 확인합니다.
04
맡기기 좋은 작업과 그렇지 않은 작업이 있습니다
맡기기 좋은 작업
- DTO와 변환 코드처럼 반복되는 작성
- 테스트 코드 초안 (검증 항목은 사람이 정함)
- 기존 코드 설명과 낯선 모듈 파악
- 에러 로그와 스택트레이스 해석
- 설정 속성 이름과 사용법 확인
- 리팩터링 후보 제안
사람이 판단할 작업
- 트랜잭션 경계와 정합성 설계
- 보안 정책과 권한 범위 결정
- 성능 튜닝과 인덱스 전략
- 도메인 규칙 판단
- 버전 업그레이드 시점 결정
함께하면 좋은 방식
설계는 사람이 정하고 구현을 맡기는 방식이 안정적입니다. 반대로 '알아서 잘 만들어 줘'는 검토 비용이 작성 비용보다 커집니다.
05
책임은 코드를 병합한 사람에게 있습니다
AI가 작성했다는 사실은 코드 품질에 대한 면책이 되지 않습니다. 장애가 나면 원인을 설명하고 고쳐야 하는 것은 사람입니다.
그래서 이해하지 못한 코드는 병합하지 않는다는 기준이 가장 중요합니다. 설명할 수 없는 코드는 장애 시점에도 손댈 수 없습니다.
- AI로 생성·수정한 범위를 PR에 남깁니다.
- 테스트를 통과하지 않은 변경은 병합하지 않습니다.
- 추가된 의존성은 라이선스와 필요성을 따로 확인합니다.
- 사내 코드의 외부 전송 가능 여부를 먼저 확인합니다. 도구별 차이는 IDE 코스에서 다룹니다.
- 프롬프트에 접속 정보와 개인정보를 넣지 않습니다.
코스를 마치며
이 코스에서 다룬 함정은 대부분 '동작은 하는데 나중에 문제가 되는 것'들입니다. AI는 동작하는 코드를 빠르게 만들어 주지만, 나중에 문제가 될지를 판단하지는 못합니다. 그 판단을 하기 위해 앞의 14개 파트가 필요했습니다.
버전
3.x와 4.x 차이
본문은 현장에서 가장 많이 쓰는 3.x 기준입니다. 4.x에서 달라진 부분만 아래에 정리합니다.
- 규칙 파일에 Spring Boot 버전과 Java 버전을 반드시 적습니다. 적지 않으면 학습 자료에 많은 구버전 문법이 섞여 나옵니다.
- 3.x 프로젝트라면 jakarta 임포트와 SecurityFilterChain 방식을, 4.x 프로젝트라면 @MockitoBean과 Jackson 3 기준을 규칙에 명시해 두면 재작업이 크게 줄어듭니다.
- 생성된 코드에 구버전 문법이 반복해서 나타나면 규칙 파일에 금지 항목으로 추가합니다. 대화로 매번 교정하는 것보다 효과적입니다.
체크