소프트웨어 개발 워크플로

개발자에게 ChatGPT는 마법 지팡이처럼 보일 때가 있다. 요구사항을 입력하면 코드가 나오고, 에러 메시지를 붙여 넣으면 원인을 설명하며, 낡은 함수를 주면 그럴듯한 리팩터링안을 내놓는다. 그런데 바로 이 편리함 때문에 가장 위험한 착각이 생긴다. "코드가 생성되었다"는 사실을 "소프트웨어가 완성되었다"는 뜻으로 받아들이는 착각이다.

소프트웨어 개발에서 ChatGPT의 진짜 가치는 코드를 대신 써 주는 데 있지 않다. 더 정확히 말하면, 개발자가 생각해야 할 질문을 빠르게 드러내고, 선택지를 만들고, 검증 절차를 촘촘하게 만드는 데 있다. OpenAI가 Codex를 기획·구현·리팩터링·리뷰·릴리스까지 이어지는 코딩 파트너로 설명하는 것도 같은 흐름이다.¹ 국내에 소개된 개발 활용서들도 코드 생성뿐 아니라 테스트 주도 개발, 디버깅, 리팩터링, 문서 자동화, API·LangChain 연계까지 개발 프로세스 전체에 ChatGPT를 연결하는 방식을 다룬다.²

이 장의 핵심 문장은 하나다. AI가 쓴 코드도 우리 팀의 코드다. 그러므로 개발자가 이해하지 못한 코드는 머지하지 않고, 테스트하지 않은 코드는 배포하지 않으며, 보안 검토를 거치지 않은 코드는 운영에 올리지 않는다. ChatGPT는 동료 개발자처럼 활용하되, 최종 책임자는 여전히 사람과 팀이다.

개발 워크플로를 다시 그리기

전통적인 개발 흐름은 대략 요구사항을 정리하고, 설계하고, 구현하고, 테스트하고, 리뷰하고, 배포한 뒤 운영하는 순서로 설명된다. ChatGPT를 넣는다고 이 순서가 사라지지는 않는다. 오히려 각 단계에서 산출물을 더 명확히 만들고, 다음 단계로 넘어가기 전에 확인할 질문을 늘리는 쪽으로 바뀐다.

개발 워크플로에서 ChatGPT가 맡을 수 있는 역할은 크게 네 가지다. 첫째, 모호한 말을 구조화한다. 고객의 요청, 기획자의 아이디어, 운영팀의 불만을 사용자 스토리와 수용 기준으로 바꿔 준다. 둘째, 초안을 만든다. 함수, 테스트, 문서, 릴리스 노트 같은 반복 산출물의 첫 버전을 빠르게 작성한다. 셋째, 대안을 비교한다. 어떤 라이브러리를 쓸지, 어떤 API 구조가 나은지, 동기 처리와 비동기 처리 중 무엇이 적절한지 장단점을 정리한다. 넷째, 검토 목록을 만든다. 사람이 놓치기 쉬운 예외 조건, 경계값, 인증·권한, 로그, 실패 처리 항목을 체크리스트로 끌어낸다.

다만 이 네 가지는 모두 "보조"다. ChatGPT가 작성한 코드는 컴파일러, 테스트, 정적 분석, 보안 스캐너, 코드 리뷰, 운영 로그 앞에서 검증되어야 한다. 특히 2026년 현재의 AI 코딩 도구는 단순 자동완성을 넘어 파일을 수정하고, 명령어를 실행하고, 패키지를 설치하고, 테스트를 돌리고, 브랜치를 푸시하는 에이전트형 도구로 확장되고 있다. OWASP는 이런 에이전트형 코딩 환경에서 저장소 문서, 이슈, PR 댓글, 외부 도구 응답이 모두 에이전트의 행동에 영향을 줄 수 있으므로 신뢰 경계를 분명히 해야 한다고 경고한다.³

그래서 이 장에서는 ChatGPT를 "코드 생성기"가 아니라 "검증 가능한 개발 흐름을 만드는 도구"로 다룬다.

요구사항 단계: 아이디어를 개발 가능한 언어로 바꾸기

많은 프로젝트는 코드가 어려워서 실패하기보다, 무엇을 만들지 애매해서 실패한다. "회원 등급별 쿠폰 기능을 넣어 주세요"라는 요청은 쉬워 보이지만, 실제로는 질문이 쏟아진다. 등급은 누가 정하는가. 쿠폰은 중복 사용 가능한가. 환불하면 쿠폰은 복구되는가. 만료된 쿠폰을 장바구니에서 어떻게 보여 줄 것인가. 관리자 화면도 필요한가. 이벤트 트래픽이 몰리면 어떻게 할 것인가.

이런 단계에서 ChatGPT를 동료 개발자처럼 쓰면 효과가 크다. 기획 초안을 붙여 넣고 바로 코드를 요청하지 말고, 먼저 요구사항을 개발 가능한 단위로 쪼개 달라고 요청한다.

당신은 시니어 백엔드 개발자이자 애자일 팀의 기술 리드다.
아래 기능 아이디어를 개발 가능한 요구사항으로 정리하라.

기능 아이디어:
회원 등급별로 쿠폰을 발급하고, 주문 시 적용할 수 있게 하고 싶다.

출력 형식:
1) 기능 목표 한 줄
2) 사용자 스토리 5개 이내
3) 수용 기준
4) 화면 또는 API 후보
5) 예외 조건
6) 보안·개인정보 고려 사항
7) MVP 범위와 이후 범위
8) 추가로 확인해야 할 질문

주의:
모르는 정책은 추정하지 말고 '확인 필요'로 표시하라.

여기서 중요한 것은 ChatGPT의 답을 요구사항 확정본으로 쓰지 않는 것이다. ChatGPT의 답은 회의 안건이다. 좋은 답변이라면 팀은 그 답변을 보며 "맞다", "아니다", "그건 2차 범위다", "이건 법무 확인이 필요하다"라고 말할 수 있다. 결국 AI가 하는 일은 빈 회의실에 칠판을 세우는 것이다. 아무것도 없는 상태에서 말싸움을 시작하는 대신, 고칠 수 있는 초안을 놓고 토론하게 만든다.

요구사항을 정리할 때는 다음 산출물을 차례로 만들면 좋다.

기획 회의가 길어지는 팀일수록 ChatGPT의 요구사항 구조화 기능은 강력하다. 단, 회의록을 그대로 붙여 넣을 때 고객명, 계약 조건, 내부 매출 목표, 미공개 전략이 들어 있지 않은지 먼저 확인해야 한다. 요구사항 정리는 안전한 샘플 데이터와 익명화된 표현으로도 충분히 가능하다.

설계 단계: 정답보다 비교표를 요구하라

설계 단계에서 ChatGPT에게 가장 잘못 묻는 방식은 "이 기능의 아키텍처를 설계해 줘"라고 던지는 것이다. 그러면 그럴듯한 박스와 화살표가 나오지만, 왜 그 구조가 우리 팀에 맞는지는 알 수 없다. 좋은 질문은 정답을 요구하지 않는다. 선택지를 요구한다.

예를 들어 쿠폰 기능을 만들 때 단일 서비스 안에 넣을지, 별도 쿠폰 서비스로 분리할지, 이벤트 기반으로 발급할지 고민한다고 하자. 이때는 다음처럼 묻는다.

다음 상황에서 가능한 설계 대안을 비교하라.

상황:
- 기존 서비스는 모놀리식 구조다.
- 주문, 결제, 회원 등급 기능은 이미 있다.
- 새로 회원 등급별 쿠폰 발급 기능을 추가한다.
- 초기 트래픽은 작지만, 이벤트 기간에는 주문량이 10배까지 증가할 수 있다.

비교할 대안:
A. 기존 주문 서비스 내부에 쿠폰 모듈 추가
B. 별도 쿠폰 서비스 분리
C. 이벤트 큐를 이용한 비동기 쿠폰 발급

출력:
- 대안별 장점
- 대안별 단점
- 데이터 일관성 이슈
- 장애 시나리오
- MVP에 적합한 선택
- 나중에 구조를 바꿀 때의 마이그레이션 포인트

이런 요청은 ChatGPT의 강점을 잘 활용한다. AI는 많은 설계 패턴과 사례를 알고 있으므로 비교표를 빠르게 만든다. 그러나 최종 선택은 코드베이스의 역사, 팀의 숙련도, 운영 인프라, 출시 일정, 장애 대응 능력을 아는 사람이 해야 한다. 작은 팀이 과도한 마이크로서비스 구조를 택하면 개발보다 배포와 관측에 더 많은 시간을 쓸 수 있다. 반대로 성장한 서비스가 모든 기능을 한 덩어리에 계속 넣으면 장애 범위와 변경 비용이 커진다.

설계 검토에서 ChatGPT에게 반드시 물어야 할 질문은 "무엇을 만들까"보다 "무엇이 깨질 수 있을까"다. 장애 시나리오, 데이터 정합성 문제, 재시도 정책, 중복 요청 처리, 롤백 전략, 로그와 알림 기준을 함께 요청해야 한다. 이 질문들은 뒤에서 다룰 테스트와 운영 관측가능성으로 자연스럽게 이어진다.

코드 생성: 초안은 빠르게, 검증은 엄격하게

코드 생성은 ChatGPT 활용에서 가장 눈에 띄는 부분이다. 하지만 가장 조심해야 할 부분이기도 하다. ChatGPT는 함수 하나를 몇 초 만에 만들 수 있지만, 그 함수가 실제 프로젝트의 버전, 라이브러리, 예외 처리 방식, 보안 규칙, 성능 조건에 맞는지는 별개의 문제다.

개발에서 AI 코드 생성을 안전하게 쓰려면 요청 단위를 작게 나누어야 한다. "쇼핑몰 백엔드를 만들어 줘"가 아니라 "주어진 쿠폰 정책에 따라 적용 가능한 쿠폰 목록을 필터링하는 순수 함수를 작성해 줘"라고 묻는다. 순수 함수란 같은 입력에 대해 같은 출력을 내고 외부 상태를 직접 바꾸지 않는 함수를 말한다. 이런 단위는 테스트하기 쉽고, AI가 만든 코드를 사람이 이해하기도 쉽다.

당신은 TypeScript 백엔드 개발자다.
아래 조건을 만족하는 순수 함수 초안을 작성하라.

목표:
주문 금액과 회원 등급, 쿠폰 목록을 입력받아 적용 가능한 쿠폰만 반환한다.

조건:
- 쿠폰은 만료일이 지나면 제외한다.
- 최소 주문 금액보다 주문 금액이 작으면 제외한다.
- 회원 등급 제한이 있으면 해당 등급만 사용할 수 있다.
- 중복 사용 가능 여부는 판단하지 않는다. 이 함수의 책임에서 제외한다.

출력:
- 함수 코드
- 타입 정의
- 단위 테스트 후보 5개
- 이 함수가 처리하지 않는 책임
- 성능상 주의할 점

이 프롬프트에는 중요한 장치가 들어 있다. 함수의 책임을 제한했고, 테스트 후보를 함께 요구했으며, 처리하지 않는 책임도 말하게 했다. AI 코드 생성에서 "하지 말아야 할 일"을 명시하는 것은 "해야 할 일"을 명시하는 것만큼 중요하다. 그래야 함수가 주문 생성, 결제 검증, 쿠폰 차감까지 한꺼번에 처리하는 괴물이 되는 일을 막을 수 있다.

AI가 만든 코드를 받은 뒤에는 다음 순서로 확인한다.

• 이해: 함수의 입력, 출력, 부작용, 예외를 개발자가 말로 설명할 수 있는지 확인한다.

• 빌드: 실제 프로젝트에서 컴파일 또는 타입 검사를 통과하는지 확인한다.

• 테스트: 정상 케이스, 경계값, 실패 케이스를 자동 테스트로 검증한다.

• 성능: 데이터가 커졌을 때 시간 복잡도와 쿼리 수가 폭증하지 않는지 확인한다.

• 보안: 입력 검증, 인증·권한, 비밀키, 의존성 취약점, 로그 노출을 점검한다.

• 일관성: 팀의 네이밍, 에러 처리, 폴더 구조, 린트 규칙과 맞는지 확인한다.

개발자가 이해하지 못한 코드를 그대로 붙여 넣는 것은 낯선 사람이 건넨 USB를 운영 서버에 꽂는 것과 비슷하다. 작동할 수도 있다. 하지만 왜 작동하는지 모른다면, 고장 났을 때 고칠 수도 없다.

리팩터링: 예쁘게가 아니라 안전하게 바꾸기

리팩터링 요청도 흔하다. 긴 함수를 붙여 넣고 "깔끔하게 바꿔 줘"라고 하면 ChatGPT는 변수명을 바꾸고 함수를 나누고 중복을 줄여 준다. 이 자체는 유용하다. 그러나 리팩터링의 목적은 코드를 예쁘게 만드는 것이 아니라, 동작을 유지하면서 변경 비용을 줄이는 것이다.

따라서 리팩터링 프롬프트에는 반드시 보존해야 할 동작과 변경 금지 범위를 넣어야 한다.

아래 코드를 리팩터링하라.

목표:
- 동작은 바꾸지 않는다.
- 중복을 줄인다.
- 함수 이름과 변수 이름을 더 명확히 한다.
- 예외 처리를 읽기 쉽게 정리한다.

변경 금지:
- 공개 API 시그니처는 바꾸지 않는다.
- 데이터베이스 스키마는 바꾸지 않는다.
- 반환 에러 코드는 기존과 같아야 한다.

출력:
1) 리팩터링 코드
2) 변경한 이유
3) 동작이 바뀔 가능성이 있는 부분
4) 추가해야 할 회귀 테스트

여기서 회귀 테스트란 과거에 잘 되던 기능이 새 변경 때문에 깨지지 않았는지 확인하는 테스트다. 리팩터링은 겉보기에 기능 추가가 아니므로 테스트를 소홀히 하기 쉽다. 하지만 실제 장애 중 상당수는 "동작은 안 바뀔 줄 알았던" 변경에서 나온다. ChatGPT에게 리팩터링을 맡겼다면, 그 대가로 회귀 테스트 목록을 반드시 받아야 한다.

테스트 주도 개발: AI에게 정답보다 실패를 찾게 하라

테스트 주도 개발, 즉 TDD는 먼저 테스트를 작성하고 그 테스트를 통과하는 코드를 구현하는 방식이다. ChatGPT와 TDD는 꽤 잘 맞는다. AI에게 바로 구현을 시키는 대신 테스트 케이스를 먼저 만들게 하면, 요구사항의 빈틈이 빨리 드러난다.

쿠폰 기능의 테스트를 만든다고 해 보자. "테스트 코드 작성해 줘"보다 다음 질문이 낫다.

다음 요구사항에 대한 테스트 목록을 먼저 작성하라.

요구사항:
회원 등급별 쿠폰은 등급 조건, 만료일, 최소 주문 금액을 만족할 때만 적용 가능하다.

출력:
- 정상 케이스
- 경계값 케이스
- 실패 케이스
- 시간 관련 케이스
- 권한 또는 악용 가능성 케이스
- 각 테스트가 검증하는 수용 기준

아직 구현 코드는 작성하지 말라.

이렇게 하면 ChatGPT는 코드보다 먼저 질문을 만든다. 만료일의 기준 시간이 서버 시간인지 사용자 지역 시간인지, 최소 주문 금액이 할인 전 금액인지 할인 후 금액인지, 탈퇴 회원의 쿠폰은 어떻게 되는지 같은 문제가 드러난다. 테스트 목록은 곧 요구사항의 현미경이다.

버그 수정에서도 같은 원리가 적용된다. 에러 로그를 붙여 넣고 "고쳐 줘"라고 하는 대신, 원인 가설과 확인 실험을 분리하도록 요구한다.

아래 버그 리포트와 로그를 분석하라.

요청:
- 가능한 원인 가설을 우선순위 순으로 정리하라.
- 각 가설을 확인할 수 있는 실험 또는 로그 확인 방법을 제안하라.
- 바로 코드를 수정하지 말라.
- 재현 절차가 부족하면 필요한 추가 정보를 질문하라.

버그 리포트:
[요약]

로그:
[비밀키와 개인정보를 제거한 로그]

이 방식은 디버깅을 훨씬 안전하게 만든다. AI가 곧바로 수정 코드를 내놓으면 그럴듯한 패치를 붙여 넣고 싶어진다. 하지만 원인 가설과 확인 실험을 분리하면, 개발자는 "정말 이게 원인인가"를 먼저 검증하게 된다. 좋은 디버깅은 빠른 수정보다 정확한 재현에서 시작한다.

코드 리뷰: AI는 첫 번째 체, 사람은 마지막 문

코드 리뷰에서 ChatGPT는 매우 유용하다. 특히 작은 팀, 1인 개발, 리뷰어가 바쁜 조직에서는 AI 리뷰가 단순 실수와 누락을 먼저 걸러 주는 체 역할을 한다. 실제로 GitHub Actions와 GPT를 연결해 PR이 열리거나 갱신될 때 변경 내용을 분석하고 리뷰 댓글을 남기는 방식은 이미 널리 사용되고 있다.⁴

하지만 AI 리뷰는 사람 리뷰를 대체하지 않는다. AI는 변경된 diff만 보고 전체 의도를 오해할 수 있고, 프로젝트의 숨은 제약을 모를 수 있으며, 자신 있게 틀린 보안 지적을 할 수도 있다. 교육 분야의 GPT 기반 코드 리뷰 연구에서도 즉각적이고 개인화된 피드백 가능성은 확인되지만, 부정행위 방지와 정확한 피드백 설계를 위해 시스템 흐름과 프롬프트를 신중하게 구성해야 한다는 점이 강조된다.⁵

AI 코드 리뷰를 팀에 도입할 때는 리뷰 범위를 명확히 해야 한다. 모든 코드를 통째로 보내는 방식은 비용과 보안 면에서 위험하다. 일반적으로는 PR diff, 관련 테스트, 팀 컨벤션 문서, 보안 체크리스트 정도로 범위를 제한한다. 리뷰 프롬프트는 다음처럼 작성할 수 있다.

당신은 우리 팀의 보조 코드 리뷰어다.
아래 PR diff를 검토하라.

집중할 항목:
- 버그 가능성
- 예외 처리 누락
- 입력 검증 부족
- 인증·권한 문제
- 중복 코드와 과도한 복잡도
- 성능상 위험한 반복문 또는 쿼리
- 비밀키·토큰·개인정보 노출
- 테스트 누락

출력 규칙:
- 반드시 중요한 문제부터 말하라.
- 확실하지 않은 내용은 추정이라고 표시하라.
- 스타일 취향만의 지적은 낮은 우선순위로 분리하라.
- 수정 코드는 필요한 경우에만 최소한으로 제안하라.

코드 리뷰 체크리스트는 팀마다 다르지만, 최소한 다음 항목은 포함해야 한다.

AI 리뷰 자동화를 CI에 붙일 때는 권한을 최소화해야 한다. PR에 댓글을 달 권한은 필요할 수 있지만, 임의로 배포하거나 보호 브랜치에 직접 푸시할 권한은 필요하지 않다. 외부 기여자의 PR에서 실행되는 워크플로는 특히 조심해야 한다. 이슈 본문이나 PR 설명에 숨은 지시가 들어 있을 수 있고, AI 에이전트가 이를 명령처럼 받아들일 수 있기 때문이다.

보안 점검: AI가 만든 코드는 일단 의심하라

AI가 만든 코드는 빠르다. 그러나 빠른 코드가 안전한 코드는 아니다. 여러 보안 기업과 연구 글은 ChatGPT가 기능적으로는 작동하는 코드를 만들 수 있지만, 입력 검증 누락, 하드코딩된 자격 증명, 취약한 인증·권한 처리, 오래된 라이브러리 사용, SQL 인젝션 같은 문제를 포함할 수 있다고 지적한다.⁶ Nord Security의 실험에서도 단순 로그인 예제를 요청했을 때 SQL 인젝션, 사용자 열거, 하드코딩된 접속 정보 같은 문제가 나타났고, 보안을 명시적으로 요구해야 개선되는 경향이 보고되었다.⁷ Trend Micro 역시 AI 생성 코드는 보조 수단으로 써야 하며, 생산 환경에 넣기 전 테스트와 리뷰를 거쳐야 한다고 강조한다.⁸

여기서 얻을 교훈은 간단하다. 보안은 프롬프트에 명시해야 하고, 그래도 별도로 검증해야 한다.

예를 들어 로그인 API를 요청한다면 "로그인 API 만들어 줘"가 아니라 다음처럼 말해야 한다.

보안을 고려한 로그인 API 초안을 작성하라.

필수 조건:
- 비밀번호는 안전한 해시 알고리즘을 사용한다.
- SQL 인젝션을 막기 위해 파라미터 바인딩을 사용한다.
- 로그인 실패 메시지는 계정 존재 여부를 드러내지 않는다.
- 반복 실패에 대한 rate limit 또는 잠금 정책을 고려한다.
- 인증 토큰 저장과 만료 정책을 설명한다.
- 비밀키는 코드에 쓰지 않고 환경 변수 또는 시크릿 관리 도구를 사용한다.

출력:
- 코드 초안
- 보안상 남은 위험
- 운영 배포 전 확인할 체크리스트

하지만 이렇게 요청해도 충분하지 않다. AI는 특정 프레임워크의 최신 보안 권장 사항을 놓칠 수 있고, 존재하지 않는 패키지명을 제안할 수 있으며, 오래된 API 사용법을 섞을 수 있다. OWASP는 AI 코딩 도구가 환각으로 존재하지 않는 의존성을 제안할 수 있고, 공격자가 그런 이름의 악성 패키지를 등록하는 위험까지 언급한다.³ 따라서 새 패키지를 추가할 때는 다운로드 수, 유지보수자, 최근 릴리스, 취약점 데이터베이스, 라이선스를 확인해야 한다.

보안 검토는 AI에게 한 번 물어보는 일이 아니라 개발 파이프라인의 일부가 되어야 한다. 최소한 정적 분석 도구, 의존성 취약점 검사, 시크릿 스캔, 테스트, 코드 리뷰를 CI에 포함한다. AI가 "안전합니다"라고 말해도 스캐너와 리뷰어가 동의하지 않으면 머지하지 않는다.

내부 코드와 데이터: 무엇을 넣지 말아야 하는가

개발자는 문제를 해결하려고 에러 로그, 설정 파일, 코드 조각을 그대로 붙여 넣고 싶어진다. 그러나 프롬프트도 데이터 이동이다. 회사 외부 서비스에 입력하는 순간, 그 정보가 어떤 약관과 보존 정책, 접근 통제 아래 처리되는지 확인해야 한다.

특히 다음 정보는 기본적으로 ChatGPT 대화창에 직접 넣지 않는 편이 안전하다.

• API 키, 토큰, 인증서, SSH 키, 데이터베이스 접속 문자열

• 고객 개인정보, 결제 정보, 진료·금융·법률 등 민감 데이터

• 비공개 알고리즘, 영업비밀, 보안 취약점 상세 정보

• 운영 서버 로그 중 사용자 식별자와 내부 인프라 정보

• 라이선스 검토가 필요한 외부 코드 또는 계약상 반출 금지 코드

그렇다고 개발에서 AI를 쓰지 말라는 뜻은 아니다. 안전한 방법을 선택하라는 뜻이다. 민감한 값은 제거하고, 실제 고객 데이터는 샘플 데이터로 바꾸고, 내부 구조가 드러나는 이름은 일반화한다. 예를 들어 customer_id=938471 대신 user_id=sample_001을 쓰고, 실제 도메인 대신 api.example.internal 같은 가짜 값을 사용한다. 문제를 재현하는 데 꼭 필요한 최소 코드만 추려 내는 것도 중요하다.

기업 환경에서는 ChatGPT Enterprise, API 계약, Azure OpenAI 같은 관리형 환경, 또는 사내에서 승인한 모델·게이트웨이를 사용할 수 있다. 어떤 방식을 쓰든 확인해야 할 것은 같다. 데이터가 모델 학습에 사용되는지, 보존 기간은 얼마인지, 접근 로그를 남길 수 있는지, 사용자별 권한을 분리할 수 있는지, 퇴사자 접근을 차단할 수 있는지, 민감 데이터 입력을 탐지할 수 있는지 확인해야 한다.

개발 워크플로에 LangChain, LlamaIndex, MCP 서버, 사내 검색 시스템을 연결할 때는 더 조심해야 한다. 연결 도구는 편리하지만, 권한이 잘못 설계되면 AI가 읽지 말아야 할 저장소, 티켓, 문서, 로그까지 읽을 수 있다. 검색 증강 생성, 즉 RAG를 붙일 때도 "검색할 수 있는 것"과 "답변에 사용할 수 있는 것"을 분리해야 한다. 개발 문서 검색 봇이 고객 개인정보가 든 장애 로그를 함께 검색한다면, 그것은 편의 기능이 아니라 사고의 입구다.

문서 자동화: 코드와 문서의 거리를 줄이기

개발자가 가장 미루기 쉬운 일 중 하나가 문서화다. 하지만 ChatGPT를 잘 쓰면 README, API 문서, 주석, 아키텍처 결정 기록, 변경 이력, 릴리스 노트, 장애 회고 초안을 빠르게 만들 수 있다. 여기서도 원칙은 같다. 문서는 생성보다 대조가 중요하다.

README를 작성할 때는 저장소 구조, 실행 방법, 환경 변수, 테스트 명령, 배포 절차를 근거로 삼아야 한다. API 문서는 실제 라우터 코드, 스키마, 테스트, OpenAPI 정의와 맞아야 한다. 릴리스 노트는 이슈, PR, 커밋 메시지와 일치해야 한다. 장애 회고는 로그와 타임라인에 근거해야 한다.

문서 자동화 프롬프트는 다음처럼 쓸 수 있다.

아래 변경 내역을 바탕으로 릴리스 노트 초안을 작성하라.

자료:
- PR 제목 목록
- 주요 커밋 메시지
- 변경된 API 목록
- 해결한 이슈 목록

출력 형식:
1) 사용자에게 보이는 변경 사항
2) 개발자에게 필요한 마이그레이션 안내
3) 버그 수정
4) 알려진 제한 사항
5) 롤백 시 주의점

주의:
자료에 없는 성능 개선이나 버그 수정을 만들어내지 말라.
불확실한 항목은 확인 필요로 표시하라.

아키텍처 결정 기록, 흔히 ADR이라고 부르는 문서에도 ChatGPT가 잘 맞는다. ADR은 왜 어떤 기술적 결정을 내렸는지 남기는 짧은 기록이다. 몇 달 뒤 "왜 이걸 이렇게 만들었지?"라는 질문이 나왔을 때 팀을 구해 준다. ChatGPT에게 회의 메모를 바탕으로 배경, 선택지, 결정, 결과, 남은 위험을 정리하게 하면 초안을 빠르게 만들 수 있다. 다만 최종 ADR은 반드시 의사결정자가 확인해야 한다. AI가 그럴듯한 이유를 덧붙이면, 훗날 팀은 존재하지 않았던 판단 근거를 믿게 될 수 있다.

개발 워크플로에 통합하기: IDE, PR, CI, 이슈를 잇는 법

ChatGPT를 개발에 쓰는 방식은 성숙도에 따라 달라진다. 처음에는 대화창에 질문하는 것으로 충분하다. 그다음에는 IDE 확장, PR 리뷰 봇, CI 단계, 사내 문서 검색, 이슈 분류 자동화로 확장할 수 있다. 중요한 것은 한 번에 모든 것을 자동화하지 않는 것이다.

도입 순서는 보통 다음이 안전하다.

1. 개인 보조: 개발자가 익명화된 코드 조각, 에러 메시지, 테스트 아이디어를 대화창에서 검토한다.

2. 팀 템플릿: 요구사항 정리, 코드 리뷰, 테스트 생성, 문서화 프롬프트를 팀 표준으로 만든다.

3. PR 보조: GitHub Actions 같은 도구로 PR diff에 대한 AI 리뷰를 생성하되, 댓글 권한만 부여한다.

4. CI 검증 연계: AI 제안과 별개로 빌드, 테스트, 린트, SAST, 의존성 검사를 필수 게이트로 둔다.

5. 사내 지식 연결: 승인된 문서와 코드 스타일 가이드만 검색 대상으로 연결한다.

6. 제한적 자동 수정: 낮은 위험도의 문서, 테스트, 포맷 수정부터 자동 PR을 만들게 한다.

AI 에이전트가 직접 파일을 수정하고 명령어를 실행하는 단계로 갈수록 권한 통제가 중요해진다. 자동 승인 모드를 켜기 전에 이 에이전트가 어떤 파일을 읽고 쓸 수 있는지, 네트워크 접근이 가능한지, 패키지를 설치할 수 있는지, 시크릿에 접근할 수 있는지, 실패 시 롤백할 수 있는지 확인해야 한다. 개발자 노트북에서 실행되는 에이전트는 사실상 그 개발자의 권한을 빌려 움직인다. 그러므로 에이전트의 실수는 개발자의 실수처럼 저장소에 남는다.

팀의 완료 기준: AI 사용을 Definition of Done에 넣기

애자일 팀에서는 어떤 작업이 끝났다고 볼지 정의하는 기준을 Definition of Done이라고 부른다. ChatGPT를 개발에 본격적으로 쓴다면 이 기준에도 AI 사용 원칙을 넣어야 한다.

AI 보조 개발의 완료 기준은 다음과 같이 정할 수 있다.

• AI가 생성한 핵심 코드는 담당 개발자가 직접 이해하고 설명할 수 있다.

• 생성 코드에는 단위 테스트와 필요한 회귀 테스트가 포함되어 있다.

• 새 의존성은 라이선스, 취약점, 유지보수 상태를 확인했다.

• 비밀키, 고객 데이터, 내부 기밀이 프롬프트와 코드에 노출되지 않았다.

• 보안 관련 변경은 입력 검증, 인증·권한, 로깅, 오류 메시지를 검토했다.

• PR 설명에는 AI를 사용한 범위와 사람이 검토한 항목이 적혀 있다.

• CI의 빌드, 테스트, 린트, 보안 스캔을 통과했다.

여기서 "AI 사용 범위"를 적는 이유는 책임 회피가 아니라 추적 가능성 때문이다. 예를 들어 테스트 케이스 초안을 AI가 만들었고 구현은 사람이 했다면, 리뷰어는 테스트의 누락 가능성을 더 주의 깊게 볼 수 있다. 반대로 리팩터링 코드 대부분을 AI가 만들었다면, 동작 변경 가능성과 회귀 테스트를 더 꼼꼼히 봐야 한다.

실습: 쿠폰 기능을 안전하게 개발해 보기

지금까지의 흐름을 하나의 실습으로 묶어 보자. 목표는 회원 등급별 쿠폰 기능의 MVP를 만드는 것이다. ChatGPT에게 한 번에 전체 구현을 맡기지 않고, 단계별 산출물을 만들게 한다.

첫 단계에서는 요구사항을 정리한다. 사용자 스토리, 수용 기준, 예외 조건, MVP 범위를 만든다. 두 번째 단계에서는 설계 대안을 비교한다. 기존 서비스 내부 모듈로 시작할지, 쿠폰 서비스를 분리할지, 이벤트 큐를 사용할지 장단점을 정리한다. 세 번째 단계에서는 핵심 도메인 함수만 구현한다. 적용 가능한 쿠폰을 판단하는 순수 함수부터 시작한다. 네 번째 단계에서는 테스트 목록을 만든다. 만료일, 최소 주문 금액, 회원 등급, 중복 사용, 환불, 시간대 문제를 포함한다. 다섯 번째 단계에서는 코드 리뷰 프롬프트로 보안과 예외 처리를 점검한다. 마지막 단계에서는 README와 릴리스 노트 초안을 만든 뒤 실제 코드와 대조한다.

이 실습에서 중요한 것은 ChatGPT가 얼마나 많은 코드를 썼는지가 아니다. 각 단계마다 사람이 확인할 수 있는 산출물이 남았는지가 중요하다. 요구사항 문서, 테스트 코드, 리뷰 기록, CI 결과, 릴리스 노트가 남아 있다면 팀은 다음 변경을 안전하게 이어 갈 수 있다. 반대로 대화창에서 생성한 코드를 복사해 붙여 넣고 아무 기록 없이 배포했다면, 그 기능은 빠르게 만들어졌지만 느리게 망가질 가능성이 높다.

개발자의 역할은 줄어들지 않는다, 이동한다

ChatGPT는 개발자의 일을 없애기보다 개발자의 무게중심을 옮긴다. 예전에는 빈 파일에 첫 줄을 쓰는 시간이 길었다면, 이제는 나온 초안을 읽고 판단하는 시간이 중요해진다. 예전에는 문법을 검색하는 시간이 길었다면, 이제는 요구사항의 경계와 운영 리스크를 정의하는 시간이 중요해진다. 예전에는 테스트를 나중으로 미뤘다면, 이제는 AI에게 테스트 후보를 먼저 만들게 하고 그 빈틈을 검토할 수 있다.

좋은 개발자는 AI보다 코드를 빨리 치는 사람이 아니다. 좋은 개발자는 AI가 낸 초안에서 위험한 가정을 찾아내고, 팀의 맥락에 맞게 고치고, 자동 테스트와 리뷰와 운영 지표로 검증 가능한 흐름을 만드는 사람이다. ChatGPT는 그런 개발자를 더 강하게 만든다.

소프트웨어 개발에서 가장 비싼 코드는 작성하는 데 오래 걸린 코드가 아니다. 이해되지 않고, 테스트되지 않고, 문서화되지 않고, 책임 소재가 흐린 코드다. ChatGPT를 제대로 쓰는 팀은 코드를 더 많이 생성하는 팀이 아니라, 더 빨리 검증하고 더 안전하게 바꾸는 팀이다. 그리고 그 차이가 AI 시대의 개발 생산성을 가른다.

참고

¹Codex | OpenAI의 AI 코딩 파트너

²소프트웨어 개발에 ChatGPT 사용하기

³OWASP Secure Coding with AI Cheat Sheet

⁴Code Review with ChatGPT - GitHub Marketplace

⁵A GPT-based Code Review System for Programming Language Learning

⁶ChatGPT and Secure Coding: Benefits and Security Vulnerabilities of ChatGPT-Generated Code

⁷ChatGPT and secure coding: The good, the bad, and the dangerous

⁸Security Vulnerabilities of ChatGPT-Generated Code