31장. AI 기반 개발 프로세스 만들기

앞 장에서는 AI 코드 리뷰 자동화를 살펴보았다.

AI는 PR 변경 내용을 요약하고, 테스트 누락 후보를 찾고, 보안과 권한 관점에서 확인할 부분을 정리해줄 수 있다고 했다.
하지만 AI 리뷰는 사람 리뷰를 대체하는 것이 아니라, 리뷰어가 더 중요한 부분에 집중할 수 있도록 돕는 보조 도구라고 했다.

이번 장에서는 코드 리뷰보다 더 넓은 범위를 다룬다.

바로 개발 프로세스 전체에 AI를 넣는 방법이다.

개발팀의 업무는 코드 작성만으로 끝나지 않는다.

- 요구사항 정리
- 이슈 생성
- 작업 분해
- 설계 검토
- 코드 작성
- PR 리뷰
- 테스트
- 배포
- 릴리즈 노트 작성
- 장애 대응
- 회의록 정리
- 주간 업무 보고
- 운영 문서 작성

이 과정에는 반복적인 일이 많다.
또 사람이 매번 정리해야 하는 문서와 기록도 많다.

AI는 이런 개발 프로세스의 여러 지점에서 보조 역할을 할 수 있다.

예를 들어 회의록에서 액션 아이템을 뽑아 Jira 이슈 초안을 만들 수 있다.
PR 내용을 보고 릴리즈 노트 초안을 만들 수 있다.
장애 로그와 타임라인을 바탕으로 장애 리포트 초안을 작성할 수 있다.
한 주 동안 완료된 Jira 이슈와 PR을 모아 주간 업무 보고 초안을 만들 수도 있다.

하지만 개발 프로세스에 AI를 넣을 때는 조심해야 한다.

AI가 문서를 만들어준다고 해서 그 문서가 항상 정확한 것은 아니다.
AI가 이슈를 생성한다고 해서 바로 작업 지시가 확정되는 것도 아니다.
AI가 장애 원인을 정리한다고 해서 그것이 최종 원인 분석이 되는 것도 아니다.

AI는 개발 프로세스에서 반복적인 정리와 초안 생성을 도와줄 수 있다.
하지만 승인, 판단, 책임은 여전히 사람이 가져야 한다.

이 장에서는 Jira, GitHub, 릴리즈 노트, 장애 리포트, 회의록, 주간 보고 같은 개발팀 업무에 AI를 연결하는 방법을 살펴본다.

1. 개발 프로세스에 AI를 넣는다는 것

개발 프로세스에 AI를 넣는다는 것은 단순히 개발자가 ChatGPT를 쓰는 것을 의미하지 않는다.

개인 개발자가 AI에게 코드를 물어보는 것도 유용하다.
하지만 팀 단위 개발 프로세스에서 AI를 사용하려면 조금 더 구조적으로 봐야 한다.

예를 들어 다음과 같은 흐름을 생각해보자.

회의록 작성
→ AI가 액션 아이템 추출
→ Jira 이슈 초안 생성
→ 담당자가 내용 확인
→ 개발자가 작업
→ PR 생성
→ AI가 PR 요약
→ 리뷰어가 검토
→ 배포
→ AI가 릴리즈 노트 초안 생성
→ 담당자가 최종 확인

이 흐름에서 AI는 여러 단계에 등장한다.

하지만 AI가 모든 것을 자동으로 결정하지는 않는다.
AI는 초안을 만들고, 정리하고, 누락 후보를 찾아준다.
사람은 그 결과를 확인하고 승인한다.

개발 프로세스에 AI를 넣을 때 중요한 기준은 이것이다.

AI가 결정하는가?
아니면 AI가 사람이 결정하기 쉽게 정리하는가?

실무에서는 후자가 더 안전하다.

AI가 바로 이슈를 만들고, 담당자를 지정하고, 코드를 수정하고, 배포까지 한다면 위험하다.
그 과정에서 잘못된 판단이 들어가면 장애나 보안 사고로 이어질 수 있다.

반면 AI가 회의록에서 할 일을 정리하고, 이슈 초안을 만들고, 담당자가 승인한 뒤 등록하는 방식은 상대적으로 안전하다.

AI 기반 개발 프로세스는 자동화와 승인 구조를 함께 설계해야 한다.

개발 프로세스 자동화란?
개발 과정에서 반복적으로 발생하는 정리, 생성, 검토, 알림 작업을 도구로 자동 처리하는 것을 말한다.
AI를 사용하면 단순 규칙 기반 자동화보다 자연어 문서, 회의록, 코드 변경 내용 같은 비정형 데이터를 더 잘 다룰 수 있다.

2. AI를 넣기 좋은 업무와 조심해야 할 업무

AI를 개발 프로세스에 넣기 전에 먼저 업무를 나눠봐야 한다.

모든 업무에 AI를 똑같이 넣는 것은 좋지 않다.

AI를 넣기 좋은 업무는 다음과 같다.

- 문서 초안 작성
- PR 요약
- 회의록 요약
- 액션 아이템 추출
- 릴리즈 노트 초안 생성
- 장애 리포트 초안 작성
- 테스트 케이스 후보 정리
- 변경 영향도 후보 정리
- 반복적인 업무 보고 초안 작성

이런 업무는 AI가 틀려도 사람이 검토하고 수정할 수 있다.
최종 결과가 바로 운영 시스템을 변경하지 않는다.

반대로 조심해야 할 업무는 다음과 같다.

- 배포 실행
- 운영 DB 수정
- 권한 변경
- 사용자 데이터 삭제
- 결제나 정산 데이터 변경
- 관리자 기능 실행
- 장애 복구 명령 실행
- 외부 업체 API에 쓰기 요청

이런 업무는 AI가 잘못 수행하면 바로 피해가 발생할 수 있다.

따라서 AI를 쓰더라도 반드시 사람 승인 단계가 필요하다.

업무를 다음 세 가지로 나눠볼 수 있다.

이 구분은 회사와 팀의 상황에 따라 달라질 수 있다.

중요한 것은 AI가 직접 실행해도 되는 업무와, 반드시 사람이 승인해야 하는 업무를 나누는 것이다.

AI는 자연어를 잘 다루지만, 책임을 질 수는 없다.

3. Jira 이슈와 AI 연결

개발팀에서 Jira는 작업 관리의 중심이 되는 경우가 많다.

요구사항, 버그, 개선 작업, 운영 요청, 장애 후속 조치가 Jira 이슈로 관리된다.

AI는 Jira 이슈를 만드는 과정에서 도움을 줄 수 있다.

예를 들어 회의록에 다음 내용이 있다고 해보자.

관리자 페이지에서 사용자 검색이 느리다는 의견이 있었다.
최근 3개월 이상 데이터 검색 시 응답 시간이 길어지는 것으로 보인다.
우선 검색 조건별 인덱스 사용 여부를 확인하고,
필요하면 검색 기간 제한 또는 별도 검색 옵션을 검토하기로 했다.
담당은 플랫폼개발1팀에서 확인한다.

AI는 이 내용을 바탕으로 Jira 이슈 초안을 만들 수 있다.

제목:
관리자 사용자 검색 성능 저하 원인 분석

설명:
관리자 페이지 사용자 검색에서 최근 3개월 이상 데이터 조회 시 응답 시간이 길어지는 문제가 보고되었다.
검색 조건별 인덱스 사용 여부를 확인하고, 필요 시 검색 기간 제한 또는 별도 검색 옵션을 검토한다.

작업 내용:
- 현재 검색 쿼리 확인
- 검색 조건별 인덱스 사용 여부 확인
- 대량 데이터 조회 시 실행 계획 확인
- 검색 기간 제한 필요 여부 검토
- 운영팀 안내 문구 필요 여부 검토

완료 기준:
- 주요 검색 조건별 실행 계획 확인 완료
- 개선 방향 정리
- 적용 필요 시 후속 개발 이슈 생성

이런 방식은 회의 후 이슈 정리 시간을 줄여준다.

하지만 Jira 이슈를 AI가 바로 생성하도록 하면 문제가 생길 수 있다.

AI가 회의 내용을 잘못 이해할 수 있다.
중요하지 않은 내용을 이슈로 만들 수 있다.
담당자나 우선순위를 잘못 지정할 수 있다.

따라서 처음에는 다음 흐름이 안전하다.

회의록 또는 요청 내용 입력
→ AI가 Jira 이슈 초안 생성
→ 담당자가 내용 확인
→ 필요한 부분 수정
→ Jira에 등록

AI가 Jira와 직접 연결되어 있다면 쓰기 권한을 조심해야 한다.

처음에는 읽기 전용이나 초안 생성 수준으로 시작하는 것이 좋다.

4. 좋은 Jira 이슈를 만들기 위한 AI 요청

AI에게 Jira 이슈를 만들게 할 때는 출력 형식을 정해두면 좋다.

예를 들어 다음과 같은 프롬프트를 사용할 수 있다.

아래 회의 내용을 바탕으로 Jira 이슈 초안을 작성해줘.

형식:
- 제목
- 배경
- 작업 내용
- 완료 기준
- 확인 필요 사항
- 관련 리스크

주의:
- 회의 내용에 없는 내용은 추가하지 말 것
- 확실하지 않은 내용은 “확인 필요”로 표시할 것
- 담당자와 일정은 임의로 지정하지 말 것
- 개발 작업과 정책 결정 사항을 구분할 것

이렇게 요청하면 AI가 이슈를 더 안정적으로 정리할 수 있다.

Jira 이슈에서 중요한 것은 완료 기준이다.

완료 기준이 없으면 작업이 끝났는지 판단하기 어렵다.

나쁜 이슈는 다음과 같다.

관리자 검색 개선

좋은 이슈는 다음과 같다.

제목:
관리자 사용자 검색 쿼리 실행 계획 점검

완료 기준:
- 주요 검색 조건별 EXPLAIN 결과 정리
- 인덱스 미사용 조건 확인
- 최근 1개월, 3개월, 전체 검색 성능 비교
- 개선 방안 문서화
- 적용 필요 시 후속 개발 이슈 생성

AI에게도 완료 기준을 반드시 포함하도록 요청하는 것이 좋다.

이슈는 작업 지시서에 가깝다.
좋은 이슈는 개발자가 무엇을 해야 하고, 언제 끝났다고 볼 수 있는지 알려준다.

AI는 이슈 초안을 만들 수 있지만, 최종 작업 범위와 우선순위는 사람이 정해야 한다.

5. GitHub PR과 AI 연결

GitHub PR은 개발 변경 사항이 모이는 지점이다.

AI는 PR 작성과 리뷰 과정에서 여러 가지 도움을 줄 수 있다.

앞 장에서 AI 코드 리뷰 자동화를 다뤘으므로, 여기서는 개발 프로세스 흐름 관점에서 PR과 AI 연결을 살펴보자.

PR 생성 시 AI가 할 수 있는 일은 다음과 같다.

- PR 제목 추천
- PR 설명 초안 생성
- 변경 내용 요약
- 관련 Jira 이슈 연결 확인
- 테스트 결과 요약
- 리뷰어가 볼 포인트 정리
- 릴리즈 노트 후보 작성

예를 들어 개발자가 여러 커밋을 올렸다고 해보자.

feat: add user memo save api
test: add user memo service test
refactor: move validation to request class

AI는 이 커밋과 diff를 보고 PR 설명 초안을 만들 수 있다.

변경 목적:
관리자 페이지에서 사용자 메모를 저장할 수 있도록 API를 추가한다.

주요 변경:
- 사용자 메모 저장 Controller 추가
- UserMemoService 추가
- UserMemoRepository에 저장 메서드 추가
- 요청값 검증 로직 추가
- Service 테스트 추가

테스트:
- 정상 저장
- 메모 길이 초과
- 대상 사용자 없음
- Repository 예외 발생

리뷰 요청:
- 관리자 권한 검증 위치 확인
- 감사 로그 항목 적절성 확인

이런 PR 설명은 리뷰어에게 도움이 된다.

PR 설명이 충분하면 리뷰 품질도 좋아진다.

반대로 PR 설명이 부족하면 리뷰어는 변경 의도를 추측해야 한다.
추측이 많아지면 리뷰가 느려지고, 중요한 문제를 놓칠 수 있다.

AI는 PR 설명을 자동으로 만들어줄 수 있지만, 개발자는 반드시 확인해야 한다.

AI가 변경 의도를 잘못 요약할 수 있기 때문이다.
또 실제 테스트하지 않은 항목을 테스트했다고 적을 수도 있다.

따라서 PR 설명 자동화는 “초안 생성”으로 쓰는 것이 안전하다.

6. Jira와 GitHub를 함께 연결하기

실무에서는 Jira 이슈와 GitHub PR이 연결되어야 한다.

이슈는 “무엇을 할 것인가”를 담고, PR은 “무엇을 변경했는가”를 담는다.

둘이 연결되어 있으면 추적이 쉬워진다.

Jira 이슈
→ 작업 브랜치
→ GitHub PR
→ 리뷰
→ 배포
→ 릴리즈 노트

AI는 이 연결 관계를 정리하는 데 도움을 줄 수 있다.

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

이 PR이 Jira 이슈의 완료 기준을 충족하는지 확인해줘.

Jira 이슈 내용:
...

PR 변경 내용:
...

기준:
- 완료 기준별 충족 여부
- 누락된 작업
- 테스트 필요 항목
- 리뷰어가 확인해야 할 부분

AI는 Jira 이슈의 완료 기준과 PR 변경 내용을 비교해줄 수 있다.

예를 들어 다음처럼 정리할 수 있다.

이런 비교는 리뷰에 도움이 된다.

개발자는 “이슈에서 요구한 것을 다 했는가”를 더 쉽게 확인할 수 있다.

다만 AI가 Jira와 GitHub를 모두 읽으려면 권한이 필요하다.

그래서 다음을 조심해야 한다.

- AI가 어떤 Jira 프로젝트를 읽을 수 있는가
- 어떤 GitHub 저장소를 읽을 수 있는가
- 외부 업체나 고객 정보가 포함되어 있지 않은가
- AI가 이슈나 PR에 직접 댓글을 쓸 수 있는가
- 쓰기 권한이 필요한가

처음에는 읽기와 요약 중심으로 시작하고, 쓰기 작업은 승인 후 진행하는 것이 좋다.

7. 릴리즈 노트 자동 생성

릴리즈 노트는 배포된 변경 사항을 정리하는 문서다.

서비스 운영에서는 릴리즈 노트가 중요하다.

개발팀은 어떤 기능이 배포되었는지 확인할 수 있다.
운영팀은 어떤 변화가 사용자에게 영향을 주는지 알 수 있다.
장애가 발생했을 때 최근 배포 내용을 추적할 수 있다.

하지만 릴리즈 노트 작성은 자주 미뤄진다.

작업은 끝났지만 문서 정리는 나중으로 밀리는 경우가 많다.
여러 PR이 모이면 무엇이 어떤 변경인지 다시 확인해야 한다.

AI는 PR 목록, 커밋 메시지, Jira 이슈를 바탕으로 릴리즈 노트 초안을 만들 수 있다.

예를 들어 다음과 같은 입력이 있다.

- USER-123 관리자 사용자 메모 저장 기능 추가
- USER-124 사용자 메모 조회 API 추가
- AUTH-77 로그인 실패 로그 개선
- BUG-88 특정 조건에서 검색 결과가 누락되는 문제 수정

AI는 이를 다음처럼 정리할 수 있다.

릴리즈 노트 초안

신규 기능:
- 관리자 페이지에서 사용자 메모를 저장하고 조회할 수 있는 API가 추가되었습니다.

개선:
- 로그인 실패 시 남는 로그 항목이 개선되었습니다.

버그 수정:
- 특정 검색 조건에서 일부 결과가 누락되는 문제가 수정되었습니다.

운영 참고:
- 사용자 메모 기능은 관리자 권한을 기준으로 접근이 제한됩니다.
- 로그인 실패 로그 포맷이 변경되었으므로 모니터링 조건 확인이 필요합니다.

릴리즈 노트에서 중요한 것은 독자다.

개발자용 릴리즈 노트와 운영팀용 릴리즈 노트는 다르다.

개발자용은 변경 파일, API, DB 변경, 배포 순서가 중요하다.
운영팀용은 화면 변화, 사용자 영향, 장애 확인 포인트가 중요하다.
경영진 보고용은 주요 기능, 기대 효과, 리스크가 중요하다.

AI에게 릴리즈 노트를 요청할 때는 대상 독자를 알려줘야 한다.

아래 PR 목록을 바탕으로 운영팀용 릴리즈 노트 초안을 작성해줘.

개발 용어는 줄이고,
사용자 영향, 운영 확인 사항, 장애 시 확인할 포인트 중심으로 정리해줘.

릴리즈 노트 자동화도 최종 확인은 사람이 해야 한다.

AI가 내부용 변경을 사용자 공개용 표현으로 잘못 바꿀 수 있다.
또 배포되지 않은 PR을 포함할 수도 있다.

릴리즈 노트는 기록이다.
기록은 정확해야 한다.

8. 장애 리포트 초안 생성

장애 대응 후에는 장애 리포트를 작성해야 한다.

장애 리포트에는 보통 다음 내용이 들어간다.

- 장애 발생 시각
- 장애 종료 시각
- 영향 범위
- 탐지 경로
- 원인
- 조치 내용
- 재발 방지 대책
- 후속 작업

하지만 장애 상황에서는 기록이 여러 곳에 흩어져 있다.

- Slack 대화
- 장애 대응 회의록
- 모니터링 알림
- 서버 로그
- 배포 이력
- Jira 이슈
- PR 기록

AI는 이 자료를 바탕으로 장애 리포트 초안을 만들 수 있다.

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

아래 장애 대응 기록을 바탕으로 장애 리포트 초안을 작성해줘.

형식:
- 요약
- 발생 시간
- 영향 범위
- 탐지 경로
- 원인 후보
- 실제 조치 내용
- 재발 방지 대책
- 후속 Jira 이슈 후보

주의:
- 기록에 없는 원인은 단정하지 말 것
- 확실하지 않은 내용은 “확인 필요”로 표시할 것
- 시간 순서대로 정리할 것

AI는 흩어진 내용을 정리하는 데 강하다.

특히 타임라인 작성에 도움이 된다.

10:03 모니터링 알림 발생
10:05 API 500 오류 증가 확인
10:08 최근 배포 버전 확인
10:12 문제 API 트래픽 제한
10:20 원인 후보로 캐시 키 변경 확인
10:27 롤백 진행
10:35 오류율 정상화

이런 초안은 장애 회고를 빠르게 시작하는 데 도움이 된다.

하지만 장애 리포트에서 AI가 원인을 확정하면 안 된다.

AI는 로그와 대화를 보고 원인 후보를 정리할 수 있다.
그러나 실제 원인은 메트릭, 로그, 코드, 배포 이력, 재현 테스트로 확인해야 한다.

따라서 장애 리포트 프롬프트에는 반드시 다음 조건을 넣는 것이 좋다.

원인을 단정하지 말고,
근거가 있는 내용과 확인이 필요한 내용을 구분해줘.

장애 리포트는 책임 소재를 따지는 문서가 아니라, 재발을 막기 위한 문서다.

AI도 이 관점에 맞게 사용해야 한다.

9. 개발팀 업무 자동화 흐름

AI를 개발팀 업무에 넣을 때는 개별 기능보다 전체 흐름을 보는 것이 중요하다.

예를 들어 다음과 같은 흐름을 만들 수 있다.

회의
→ 회의록 작성
→ AI가 액션 아이템 추출
→ 담당자가 Jira 이슈로 전환
→ 개발 진행
→ PR 생성
→ AI가 PR 요약
→ 리뷰어 검토
→ 배포
→ AI가 릴리즈 노트 초안 작성
→ 운영팀 공유
→ 주간 보고에 자동 반영

이 흐름에서 AI는 여러 번 등장한다.

하지만 각 단계의 역할은 다르다.

이 표에서 알 수 있듯이 AI는 초안과 정리에 강하다.

반대로 승인과 책임이 필요한 일은 사람이 해야 한다.

AI 기반 개발 프로세스를 만들 때는 “자동화할 것”과 “승인할 것”을 구분해야 한다.

자동화가 많아질수록 승인 구조는 더 중요해진다.

10. 회의록에서 액션 아이템 추출

개발팀 회의에서는 많은 내용이 오간다.

문제는 회의가 끝난 뒤다.

회의 중에는 결정된 것 같았지만, 나중에 보면 담당자와 완료 기준이 불명확한 경우가 많다.

AI는 회의록에서 액션 아이템을 추출하는 데 유용하다.

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

아래 회의록에서 액션 아이템을 추출해줘.

형식:
- 할 일
- 담당자
- 완료 기준
- 기한
- 확인 필요 사항

주의:
- 회의록에 없는 담당자는 임의로 지정하지 말 것
- 기한이 없으면 “확인 필요”로 표시할 것
- 단순 논의와 실제 할 일을 구분할 것

AI는 회의 내용을 다음처럼 정리할 수 있다.

이런 정리는 회의 후 업무 누락을 줄이는 데 도움이 된다.

하지만 회의록에서 AI가 잘못 추출할 수도 있다.

예를 들어 단순 의견을 결정 사항으로 오해할 수 있다.
농담이나 가능성 이야기를 실제 작업으로 만들 수 있다.

따라서 액션 아이템 추출 결과는 회의 참석자가 확인해야 한다.

AI가 정리한 내용을 그대로 Jira에 넣기보다, 담당자가 확인한 뒤 등록하는 것이 좋다.

11. 주간 업무 보고 자동화

개발팀에서는 주간 업무 보고를 작성하는 경우가 많다.

이번 주에 무엇을 했고, 무엇이 완료되었고, 다음 주에는 무엇을 할 것인지 정리해야 한다.

이 작업은 생각보다 시간이 걸린다.

Jira 이슈를 보고, PR을 보고, 회의 내용을 보고, 장애 대응 기록까지 확인해야 할 수 있다.

AI는 이 정보를 모아 주간 업무 보고 초안을 만들 수 있다.

입력 데이터는 다음과 같을 수 있다.

- 이번 주 완료된 Jira 이슈
- 진행 중인 Jira 이슈
- 생성된 PR
- 병합된 PR
- 장애 대응 기록
- 회의록
- 릴리즈 내용

AI는 이를 바탕으로 다음처럼 정리할 수 있다.

이번 주 완료 업무:
- 관리자 사용자 메모 저장 API 개발 완료
- 로그인 실패 로그 개선 배포
- 사용자 검색 성능 저하 원인 분석 완료

진행 중 업무:
- 사용자 검색 조건별 인덱스 개선 검토
- AI 코드 리뷰 자동화 PoC 진행

이슈 및 리스크:
- 검색 쿼리 개선 시 쓰기 성능 영향 검토 필요
- AI 리뷰 자동화 도입 전 소스코드 외부 전송 정책 확인 필요

다음 주 계획:
- 검색 성능 개선안 확정
- AI 리뷰 프롬프트 초안 작성
- GitHub Actions 연동 방식 검토

주간 보고 자동화에서 중요한 것은 정보 출처다.

AI가 어디에서 가져온 내용인지 알 수 있어야 한다.

예를 들어 Jira 이슈 번호, PR 번호, 회의록 날짜가 함께 있으면 좋다.

- USER-123 관리자 메모 저장 API 완료
- PR #456 병합 완료
- 5월 8일 회의에서 검색 성능 개선 후속 검토 결정

출처가 없으면 보고 내용을 검증하기 어렵다.

AI가 만든 주간 보고는 초안으로 보고, 팀장이 최종 확인하는 흐름이 안전하다.

12. AI를 개발 프로세스에 넣을 때의 승인 구조

AI를 개발 프로세스에 넣을수록 승인 구조가 중요해진다.

AI가 문서를 요약하는 정도라면 위험이 낮다.
하지만 AI가 Jira 이슈를 만들거나, PR에 댓글을 달거나, 배포 관련 정보를 생성한다면 영향이 커진다.

업무를 읽기, 쓰기, 실행으로 나눠볼 수 있다.

읽기 작업도 권한이 필요하다.

AI가 모든 문서를 읽을 수 있게 하면 안 된다.
사용자가 볼 수 있는 문서만 AI가 볼 수 있어야 한다.

쓰기 작업은 더 조심해야 한다.

AI가 Jira 이슈를 생성하거나 PR 댓글을 작성하면 다른 팀원에게 영향을 준다.
잘못된 내용이 기록으로 남을 수 있다.

처음에는 AI가 초안을 만들고, 사람이 버튼을 눌러 등록하는 방식이 좋다.

실행 작업은 가장 위험하다.

배포, DB 수정, 권한 변경, 사용자 데이터 삭제 같은 작업은 AI가 단독으로 수행하면 안 된다.

필요하다면 다음 구조를 사용해야 한다.

AI가 작업 제안
→ 사람이 내용 확인
→ 승인
→ 시스템이 실행
→ 실행 로그 저장
→ 결과 확인

이런 구조를 뒤에서 배울 에이전트나 MCP와 연결할 때 특히 중요하다.

AI가 외부 도구를 사용할 수 있게 될수록 승인 구조는 필수다.

13. 개발팀 도입 로드맵

AI 기반 개발 프로세스는 한 번에 만들려고 하면 부담이 크다.

처음부터 Jira, GitHub, Slack, 문서, 배포 시스템을 모두 연결하려고 하면 실패하기 쉽다.

작게 시작하는 것이 좋다.

추천하는 도입 순서는 다음과 같다.

1단계: 개인 생산성 도구로 사용
2단계: PR 요약 자동화
3단계: 회의록 액션 아이템 추출
4단계: Jira 이슈 초안 생성
5단계: 릴리즈 노트 초안 생성
6단계: 장애 리포트 초안 생성
7단계: 주간 업무 보고 자동화
8단계: 승인 기반 업무 자동화
9단계: 개발팀 AI 운영 가이드라인 정착

처음에는 위험이 낮은 것부터 시작해야 한다.

가장 추천하는 시작점은 PR 요약과 회의록 정리다.

이 두 가지는 효과가 바로 보이고, 잘못되더라도 사람이 쉽게 수정할 수 있다.

그다음 Jira 이슈 초안, 릴리즈 노트, 장애 리포트로 확장할 수 있다.

쓰기 작업이나 실행 작업은 나중에 도입해야 한다.

특히 Jira 자동 생성, PR 자동 댓글, 배포 관련 자동화는 팀의 신뢰가 쌓인 뒤 진행하는 것이 좋다.

도입할 때는 다음 질문을 계속 해야 한다.

- 이 자동화가 실제 시간을 줄여주는가
- 결과를 사람이 검토할 수 있는가
- 잘못되었을 때 되돌릴 수 있는가
- 권한과 로그가 관리되는가
- 팀원이 신뢰하고 사용하는가

AI 도입은 기능을 많이 붙이는 것이 목표가 아니다.

팀의 반복 업무를 줄이고, 기록 품질을 높이고, 개발자가 더 중요한 판단에 집중하게 만드는 것이 목표다.

14. 개발 프로세스 AI 도입 시 주의할 점

AI를 개발 프로세스에 넣을 때 몇 가지 주의할 점이 있다.

첫째, AI 결과를 공식 기록으로 바로 사용하지 말아야 한다.

AI가 만든 회의록, 장애 리포트, 릴리즈 노트는 초안이다.
사람이 확인한 뒤 공식 기록으로 남겨야 한다.

둘째, 권한을 넓게 주면 안 된다.

AI가 모든 Jira 프로젝트, 모든 GitHub 저장소, 모든 문서를 읽을 수 있으면 위험하다.
사용자 권한에 맞게 접근 범위를 제한해야 한다.

셋째, 쓰기 작업은 승인 후 실행해야 한다.

Jira 이슈 생성, PR 댓글 작성, 문서 수정 같은 작업도 기록으로 남는다.
AI가 바로 쓰게 하지 말고 초안 확인 단계를 두는 것이 좋다.

넷째, 비용을 관리해야 한다.

회의록, PR, Jira, 문서를 모두 AI로 처리하면 호출량이 많아질 수 있다.
특히 대용량 diff나 긴 회의록을 자주 처리하면 비용이 증가한다.

다섯째, 프롬프트와 결과 품질을 관리해야 한다.

AI가 만든 결과가 팀 기준과 맞지 않으면 프롬프트를 개선해야 한다.
팀 용어, 이슈 형식, 보고서 형식, 리뷰 기준을 계속 반영해야 한다.

여섯째, 민감 정보를 처리하지 않도록 해야 한다.

운영 로그, 장애 기록, 고객 문의, 개인정보가 포함된 문서는 특히 조심해야 한다.

AI 기반 개발 프로세스는 편리하다.
하지만 편리함 때문에 통제 구조를 생략하면 안 된다.

15. 실무 예시: 회의록에서 Jira 이슈와 주간 보고까지

하나의 예시 흐름을 살펴보자.

개발팀 회의에서 다음 내용이 나왔다고 해보자.

관리자 메시지 검색에서 contents like 검색이 전체 데이터 대상으로 실행될 수 있다.
message 테이블은 데이터가 많고, contents는 text 컬럼이라 검색 부하가 크다.
운영팀에는 해당 옵션이 부하가 큰 검색이라는 것을 안내해야 한다.
장기적으로는 최근 기간 제한이나 별도 검색 구조를 검토해야 한다.

AI에게 먼저 회의록 정리를 요청한다.

아래 회의 내용을 액션 아이템으로 정리해줘.

형식:
- 할 일
- 배경
- 완료 기준
- 확인 필요 사항

AI는 다음처럼 정리할 수 있다.

할 일 1:
운영팀 메시지 내용 검색 옵션명 변경

배경:
contents like 검색은 message 테이블 전체를 대상으로 실행될 수 있어 부하가 크다.

완료 기준:
- 검색 옵션명에 부하가 큰 검색임을 표시
- 운영팀 안내 문구 확정
- 적용 후 운영팀 공유

확인 필요:
- 실제 적용할 옵션명
- 검색 제한 조건 추가 여부

할 일 2:
메시지 내용 검색 구조 개선 검토

배경:
text 컬럼 like 검색은 대량 데이터에서 성능 문제가 발생할 수 있다.

완료 기준:
- 현재 쿼리 실행 계획 확인
- 최근 기간 제한 적용 가능성 검토
- 별도 검색 엔진 또는 로그 저장 구조 검토
- 후속 개발 방향 정리

그다음 Jira 이슈 초안을 만들 수 있다.

위 액션 아이템을 Jira 이슈 형식으로 바꿔줘.

제목, 설명, 작업 내용, 완료 기준, 확인 필요 사항으로 정리해줘.

AI가 만든 이슈 초안은 담당자가 확인한 뒤 Jira에 등록한다.

작업이 끝난 뒤에는 PR 설명을 생성할 수 있다.

아래 diff를 바탕으로 PR 설명을 작성해줘.

운영팀 검색 옵션명 변경 목적과 부하 안내 문구 추가 내용을 포함해줘.

배포 후에는 릴리즈 노트에 반영한다.

이번 배포 내용 중 운영팀에 공유해야 할 내용을 릴리즈 노트 형태로 정리해줘.

주간 보고에는 다음처럼 정리할 수 있다.

이번 주 완료:
- 관리자 메시지 내용 검색 옵션명에 부하 안내 문구 추가
- message 테이블 contents 검색 부하 이슈 확인
- 장기 개선 방향 검토 이슈 생성

이 흐름에서 AI는 계속 초안을 만든다.

하지만 중요한 결정은 사람이 한다.

- 실제 옵션명 결정
- 검색 제한 여부 결정
- Jira 등록 여부 결정
- PR 병합 여부 결정
- 운영팀 공유 내용 확정

이것이 안전한 AI 기반 개발 프로세스의 기본 형태다.

16. AI 기반 개발 프로세스의 핵심은 기록 품질이다

AI를 개발 프로세스에 넣는 이유는 단순히 시간을 줄이기 위해서만은 아니다.

더 중요한 효과는 기록 품질을 높이는 것이다.

개발팀 업무는 시간이 지나면 맥락이 사라진다.

- 왜 이 작업을 했는가
- 누가 결정했는가
- 어떤 대안을 검토했는가
- 왜 이 방식으로 구현했는가
- 어떤 리스크가 있었는가
- 배포 후 무엇을 확인해야 했는가

이런 기록이 없으면 나중에 문제가 생겼을 때 다시 추적해야 한다.

AI는 회의록, Jira, PR, 릴리즈 노트, 장애 리포트 사이의 빈틈을 줄여줄 수 있다.

하지만 기록 품질을 높이려면 AI에게 형식을 잘 알려줘야 한다.

예를 들어 Jira 이슈에는 완료 기준을 넣게 하고, PR 설명에는 테스트 결과를 넣게 하고, 장애 리포트에는 타임라인과 재발 방지 대책을 넣게 하는 식이다.

AI를 잘 쓰는 팀은 AI에게 “글을 예쁘게 써달라”고만 하지 않는다.

팀이 필요한 기록 구조를 정하고, AI가 그 구조를 반복적으로 채우게 만든다.

결국 AI 기반 개발 프로세스의 핵심은 자동화가 아니라 일관된 기록이다.

기록이 좋아지면 인수인계가 쉬워지고, 리뷰가 빨라지고, 장애 대응이 나아지고, 주간 보고도 쉬워진다.

17. 정리

AI는 개발 프로세스 전체에서 활용할 수 있다.

Jira 이슈 초안 생성, GitHub PR 설명 작성, 릴리즈 노트 작성, 장애 리포트 초안 생성, 회의록 액션 아이템 추출, 주간 업무 보고 자동화에 도움을 줄 수 있다.

하지만 AI가 개발 프로세스를 대신 운영하는 것은 아니다.

AI는 정리하고, 요약하고, 초안을 만들고, 누락 후보를 알려주는 역할에 적합하다.
반면 우선순위 결정, 작업 범위 확정, 배포 승인, 장애 원인 확정, 권한 변경 같은 일은 사람이 해야 한다.

AI 기반 개발 프로세스를 만들 때는 다음 원칙이 중요하다.

- 낮은 위험 업무부터 시작한다
- AI 결과는 초안으로 본다
- 공식 기록으로 남기기 전 사람이 확인한다
- 읽기, 쓰기, 실행 권한을 구분한다
- 쓰기 작업은 승인 후 반영한다
- 배포, DB 변경, 권한 변경은 AI 단독 실행을 금지한다
- Jira, PR, 릴리즈 노트, 장애 리포트의 형식을 정한다
- 비용과 호출 빈도를 관리한다
- 민감 정보가 AI 입력으로 들어가지 않도록 한다

개발 프로세스에 AI를 넣는 목적은 개발자를 통제하기 위해서가 아니다.

반복적인 정리 작업을 줄이고, 기록을 일관되게 만들고, 개발자가 더 중요한 판단에 집중하도록 돕기 위해서다.

좋은 개발 프로세스 위에 AI를 붙이면 생산성이 높아진다.
하지만 정리되지 않은 프로세스에 AI만 붙이면 혼란이 더 빨리 퍼질 수 있다.

AI 기반 개발 프로세스는 자동화보다 기준이 먼저다.

31장 핵심 요약