AI를 프로젝트에 도입한 지 꽤 됐지만, 여전히 “어디까지 맡기고 어디서부터 직접 해야 하는가”는 매번 다시 고민하게 되는 질문입니다. 이 글에서는 실무에서 AI를 도구로 다루면서 도움이 됐던 방법들을 정리합니다.

1. 코드 리뷰 보조로 활용하기

AI에게 PR 전체를 맡기기보다, 리뷰의 첫 단계로 활용하는 편이 효과적입니다. 사람이 놓치기 쉬운 부분(예외 처리 누락, 네이밍 불일치, 반복 로직)을 먼저 걸러내면, 실제 리뷰 시간은 설계나 비즈니스 로직처럼 더 중요한 부분에 쓸 수 있습니다.

• diff 단위로 리뷰를 요청하고, “이 변경이 기존 로직과 충돌할 여지가 있는지”처럼 구체적인 질문을 던집니다.
• 리뷰 결과를 그대로 반영하지 않고, 왜 그렇게 제안했는지 근거를 확인한 뒤 판단합니다.

2. 테스트 케이스 초안 생성

테스트를 처음부터 다 짜는 것보다, 경계값이나 예외 상황을 놓치지 않았는지 점검하는 용도로 쓰면 효율이 좋습니다.

// 예: 이런 식으로 케이스 목록만 먼저 뽑아달라고 요청
// - null 입력
// - 빈 문자열
// - 최대 길이 초과
// - 동시 요청 시 경합 조건

목록을 받은 뒤 실제 테스트 코드는 직접 작성하거나 검토하면서 채워 넣습니다. 특히 TestContainers나 통합 테스트처럼 환경 의존성이 있는 코드는 AI가 놓치는 디테일이 많아서 직접 확인이 필수입니다.

3. 새로운 개념을 배울 때 능동적으로 질문하기

HL7, ASTM처럼 도메인 특화된 프로토콜이나 AppSec의 새로운 개념을 처음 접할 때, 문서를 읽기 전에 AI에게 “이 개념이 왜 필요한지”, “실무에서 어떤 문제를 해결하는지”부터 물어보면 이후 공식 문서를 훨씬 빠르게 이해할 수 있습니다. 다만 AI의 설명은 학습의 출발점일 뿐이므로, 핵심 개념은 반드시 공식 문서나 스펙으로 재검증합니다.

4. 문서화 자동화

커밋 히스토리나 코드 변경 사항을 기반으로 릴리스 노트, 함수 설명, README 초안을 생성하는 데 AI를 활용하면 문서화에 드는 시간을 크게 줄일 수 있습니다. 다만 생성된 문서는 실제 코드 동작과 반드시 대조해서 확인해야 합니다 — 특히 API 스펙 문서는 사소한 오차도 사용하는 쪽에서 큰 혼란을 일으킬 수 있습니다.

5. AI 출력을 그대로 믿지 않기 — 특히 보안 관련 코드

인증/인가 로직, 암호화, 입력 검증처럼 보안에 직결되는 코드는 AI가 그럴듯하지만 취약한 패턴을 제안하는 경우가 있습니다. 예를 들어:

• 비밀번호 해싱에 약한 알고리즘을 기본값으로 제안하는 경우
• SQL 쿼리를 문자열 결합으로 작성해 인젝션에 취약한 경우
• 에러 메시지에 내부 구현 정보를 그대로 노출하는 경우

이런 코드는 반드시 OWASP 가이드나 팀의 시큐어 코딩 기준과 대조해서 검토해야 합니다. AI는 빠른 초안을 만들어주는 도구이지, 보안 검토를 대신해주는 도구가 아닙니다.

마무리

결국 AI는 판단을 대신해주는 도구가 아니라, 판단에 필요한 시간을 벌어주는 도구에 가깝습니다. 반복적이고 기계적인 작업은 맡기고, 맥락을 이해해야 하는 판단은 여전히 개발자의 몫으로 남겨두는 것 — 지금까지 실무에서 AI를 쓰면서 가장 크게 배운 원칙입니다.