7장. 개발 업무에서 AI 활용하기

1. AI는 개발자의 모든 업무에 조금씩 들어올 수 있다

AI를 개발 업무에 활용한다고 하면 가장 먼저 코드 생성을 떠올리기 쉽다.

로그인 API 만들어줘.
React 컴포넌트 만들어줘.
SQL 쿼리 작성해줘.

물론 AI는 코드를 작성하는 데 큰 도움을 줄 수 있다.

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

개발자는 요구사항을 읽고,
기능 구조를 설계하고,
기존 코드를 이해하고,
테스트하고,
리뷰하고,
배포하고,
장애를 분석하고,
문서를 작성한다.

AI는 이 과정 곳곳에서 사용할 수 있다.

요구사항 정리
→ 설계 초안 작성
→ 코드 이해
→ 코드 작성
→ 테스트 코드 생성
→ 코드 리뷰
→ 문서 작성
→ 장애 분석
→ 운영 체크리스트 작성

즉, AI는 “코드를 대신 짜주는 도구”라기보다
개발 업무 전반을 보조하는 도구에 가깝다.

개발자가 AI를 잘 활용하면 단순 반복 작업을 줄이고,
더 중요한 판단과 설계에 시간을 쓸 수 있다.

다만 중요한 점이 있다.

AI가 개발 업무를 도와준다고 해서 개발자의 판단이 필요 없어지는 것은 아니다.

AI가 만든 결과는 항상 검토해야 한다.
AI는 회사의 전체 구조, 장애 이력, 팀의 개발 규칙, 운영 정책을 완벽히 알지 못하기 때문이다.

이 장에서는 개발자가 실제 업무에서 AI를 어디에, 어떻게 활용할 수 있는지 살펴본다.

2. 요구사항 정리에 활용하기

개발은 요구사항을 이해하는 것에서 시작한다.

하지만 실제 업무에서 요구사항은 항상 깔끔하게 정리되어 있지 않다.

기획 문서가 부족할 수도 있고,
회의에서 말로만 정리됐을 수도 있고,
운영팀 요청이 메신저로 짧게 들어올 수도 있다.

예를 들어 이런 요청이 왔다고 해보자.

관리자에서 회원 후원 내역 볼 수 있게 해주세요.
검색도 되면 좋겠고, 엑셀 다운로드도 필요할 것 같습니다.

이 요청만으로 바로 개발하기는 어렵다.

확인해야 할 것이 많다.

- 어떤 관리자가 볼 수 있는가?
- 어떤 회원 기준으로 조회하는가?
- 기간 검색이 필요한가?
- 후원 유형은 어떻게 구분하는가?
- 엑셀에는 어떤 컬럼이 들어가야 하는가?
- 개인정보 마스킹이 필요한가?
- 다운로드 권한은 별도로 제한해야 하는가?
- 데이터가 많을 때 성능 문제는 없는가?

AI는 이런 모호한 요구사항을 정리하는 데 도움을 줄 수 있다.

아래 요청을 개발 요구사항으로 정리해줘.

요청:
관리자에서 회원 후원 내역 볼 수 있게 해주세요.
검색도 되면 좋겠고, 엑셀 다운로드도 필요할 것 같습니다.

정리 형식:
1. 기능 개요
2. 필요한 화면 요소
3. 검색 조건
4. 권한 확인 항목
5. 개인정보 고려사항
6. 개발 전 확인 질문

AI는 다음과 같이 정리해줄 수 있다.

1. 기능 개요
- 관리자 페이지에서 특정 회원의 후원 내역을 조회하는 기능

2. 필요한 화면 요소
- 회원 검색 영역
- 후원 내역 목록
- 상세 보기 버튼
- 엑셀 다운로드 버튼

3. 검색 조건
- 회원 ID
- 닉네임
- 후원 기간
- 후원 유형
- 후원 상태

4. 권한 확인 항목
- 일반 관리자와 슈퍼 관리자 권한 분리 여부
- 엑셀 다운로드 가능 권한

5. 개인정보 고려사항
- 회원 ID, 닉네임 노출 범위
- 엑셀 다운로드 로그 저장 여부
- 민감 정보 마스킹 필요 여부

6. 개발 전 확인 질문
- 후원 금액 또는 하트 수량을 전체 노출할 것인가?
- 취소/환불된 후원도 포함할 것인가?
- 엑셀 다운로드 건수 제한이 필요한가?

이렇게 AI를 사용하면 모호한 요청을 개발자가 검토할 수 있는 형태로 빠르게 바꿀 수 있다.

요구사항 정리에서 AI를 사용할 때 중요한 것은
AI가 정리한 내용을 그대로 확정하지 않는 것이다.

AI가 만든 것은 요구사항 초안이다.

최종 요구사항은 기획팀, 운영팀, 개발팀이 함께 확인해야 한다.

3. 개발 전 확인 질문 만들기

좋은 개발자는 바로 코드를 작성하기 전에 질문을 잘한다.

요구사항이 불명확한 상태에서 개발을 시작하면 나중에 수정 비용이 커진다.

AI는 개발 전에 확인해야 할 질문을 뽑아내는 데 유용하다.

예를 들어 다음 요청이 있다고 해보자.

BJ별 후원 랭킹을 관리자에서 볼 수 있게 해주세요.

이 요청을 그대로 개발하면 위험하다.

후원 랭킹은 단순 조회 기능처럼 보이지만, 실제로는 정책과 보안 이슈가 많다.

AI에게 다음처럼 요청할 수 있다.

아래 기능을 개발하기 전에 확인해야 할 질문을 정리해줘.

기능:
BJ별 후원 랭킹을 관리자 페이지에서 조회하는 기능

관점:
- 기획
- 운영
- 개인정보
- 권한
- 성능
- 데이터 기준

그러면 다음과 같은 질문을 얻을 수 있다.

기획 관점:
- 랭킹 기준은 후원 금액인가, 후원 횟수인가?
- 일간, 주간, 월간 랭킹이 모두 필요한가?
- 동점자는 어떻게 정렬할 것인가?

운영 관점:
- 관리자 전체가 볼 수 있는가?
- 특정 부서만 접근 가능한가?
- 랭킹 데이터를 엑셀로 다운로드할 수 있는가?

개인정보 관점:
- 후원자 ID를 노출할 것인가?
- 닉네임만 노출할 것인가?
- 일부 마스킹이 필요한가?

권한 관점:
- 조회 권한과 다운로드 권한을 분리할 것인가?
- 조회 로그를 남겨야 하는가?

성능 관점:
- 실시간 집계인가, 배치 집계인가?
- 데이터 범위가 커질 경우 조회 속도는 어떻게 보장할 것인가?

데이터 기준:
- 환불된 후원은 제외하는가?
- 테스트 계정은 제외하는가?
- 비정상 후원은 어떻게 처리하는가?

이런 질문은 개발 전 회의에서 매우 유용하다.

AI가 모든 질문을 완벽하게 뽑아주지는 못해도,
개발자가 놓칠 수 있는 관점을 빠르게 확장해준다.

배치는 특정 작업을 실시간으로 바로 처리하지 않고, 정해진 시간이나 주기에 맞춰 한꺼번에 처리하는 방식이다.
예를 들어 매일 새벽 전날 후원 랭킹을 집계하는 작업은 배치 처리에 해당한다.

4. 설계 초안 만들기

AI는 설계 초안을 만드는 데도 활용할 수 있다.

예를 들어 “사내 문서 검색 챗봇”을 만든다고 해보자.

처음부터 완벽한 설계를 만들기는 어렵다.

이때 AI에게 초안을 요청할 수 있다.

사내 문서 검색 챗봇을 만들려고 해.

조건:
- 사용자는 회사 내부 직원
- 문서는 PDF, Markdown, Google Docs 형태로 존재
- 답변에는 출처가 필요함
- 부서별 문서 접근 권한이 다름
- 초기에는 PoC로 작게 시작할 예정

아키텍처 초안을 만들어줘.

출력 형식:
1. 전체 흐름
2. 주요 컴포넌트
3. 데이터 흐름
4. 보안 고려사항
5. PoC 범위

AI는 다음과 같은 초안을 제시할 수 있다.

1. 전체 흐름
문서 수집
→ 문서 분할
→ 임베딩 생성
→ 벡터DB 저장
→ 사용자 질문 입력
→ 관련 문서 검색
→ LLM 답변 생성
→ 출처와 함께 응답

2. 주요 컴포넌트
- 문서 수집기
- 문서 파서
- 임베딩 생성기
- 벡터DB
- 검색 API
- LLM 응답 생성기
- 권한 검사 모듈

3. 데이터 흐름
사용자가 질문하면 검색 API가 권한을 확인한 뒤,
접근 가능한 문서 범위 안에서 관련 문서를 검색하고,
검색 결과를 LLM에 전달해 답변을 생성한다.

4. 보안 고려사항
- 부서별 문서 접근 권한 적용
- 질문/답변 로그 내 민감 정보 마스킹
- 외부 AI API 사용 시 문서 전송 범위 검토

5. PoC 범위
- 특정 부서 문서 50개만 대상으로 시작
- 권한은 단순 그룹 기준으로 적용
- 답변에는 문서명과 섹션 표시

이런 초안은 바로 최종 설계가 되지는 않는다.

하지만 회의 시작점으로는 충분히 유용하다.

개발자는 이 초안을 보고 다음을 검토할 수 있다.

- 우리 회사 문서 구조와 맞는가?
- 권한 모델이 실제와 맞는가?
- 외부 AI API로 문서를 보내도 되는가?
- 초기 PoC 범위가 적절한가?
- 운영 환경에서는 어떤 부분을 추가해야 하는가?

설계에서 AI를 활용할 때는 “정답 설계”를 받으려 하기보다,
논의할 수 있는 초안을 빠르게 만드는 용도로 사용하는 것이 좋다.

PoC는 Proof of Concept의 약자다.
본격 개발 전에 “이 방식이 실제로 가능한지”를 작게 검증해보는 단계를 말한다.

5. 기존 코드 이해에 활용하기

개발 업무에서 많은 시간을 차지하는 일 중 하나는 기존 코드를 이해하는 것이다.

특히 오래된 서비스나 레거시 시스템에서는 코드 구조가 명확하지 않은 경우가 많다.

함수 이름이 모호하거나,
주석이 부족하거나,
여러 조건이 얽혀 있거나,
한 파일에 너무 많은 역할이 들어 있을 수 있다.

이럴 때 AI는 코드 이해를 도와줄 수 있다.

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

아래 PHP 코드를 처음 보는 개발자가 이해할 수 있게 설명해줘.

설명 기준:
1. 전체 흐름
2. 주요 조건문
3. DB 조회/수정 부분
4. 외부 API 호출 여부
5. 주의해야 할 부분

코드:
[코드 붙여넣기]

AI는 복잡한 코드를 단계별로 풀어 설명해줄 수 있다.

또 특정 관심사만 따로 물어볼 수도 있다.

이 코드에서 방송 시작 처리와 관련된 부분만 찾아서 흐름을 정리해줘.

이 코드에서 회원 상태를 변경하는 조건만 뽑아줘.

이 함수가 호출하는 다른 함수들을 기준으로 의존 관계를 정리해줘.

기존 코드를 이해할 때 AI를 사용하면 다음 작업이 쉬워진다.

- 함수 역할 파악
- 조건문 흐름 정리
- 사이드 이펙트 확인
- DB 변경 지점 확인
- 외부 API 호출 위치 확인
- 리팩토링 후보 찾기

다만 주의할 점이 있다.

AI는 코드 일부만 보고 전체 시스템을 추측할 수 있다.
그래서 AI 설명이 실제 호출 흐름과 다를 수 있다.

특히 다음 상황에서는 반드시 직접 확인해야 한다.

- 동적으로 호출되는 함수
- 설정값에 따라 달라지는 로직
- 프레임워크 내부 동작
- DB 트리거나 프로시저
- 이벤트 기반 처리
- 배치나 큐를 통한 비동기 처리

AI의 코드 설명은 빠른 이해를 돕는 도구다.

하지만 최종 이해는 실제 코드 실행 흐름, 로그, 테스트, 호출 관계를 확인하면서 완성해야 한다.

사이드 이펙트는 함수가 값을 반환하는 것 외에 외부 상태를 변경하는 일을 말한다.
예를 들어 DB 업데이트, 파일 저장, API 호출, 로그 기록 등이 사이드 이펙트에 해당한다.

6. 코드 작성에 활용하기

AI는 코드 작성에 직접적으로 도움을 줄 수 있다.

간단한 유틸 함수, API 초안, 테스트 코드, 변환 로직, 정규식, SQL 등은 AI가 빠르게 작성해줄 수 있다.

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

Node.js Express 기준으로 로그인 API 예시를 작성해줘.

조건:
- email, password를 입력받음
- bcrypt로 비밀번호 검증
- 로그인 성공 시 JWT 발급
- 로그인 실패 시 동일한 에러 메시지 반환
- 예외 처리를 포함

AI는 기본 코드를 만들어준다.

하지만 이 코드를 바로 운영에 넣으면 안 된다.

코드 작성에서 AI를 사용할 때는 다음 흐름이 좋다.

1. AI에게 초안 작성 요청
2. 코드가 실제 요구사항과 맞는지 확인
3. 프로젝트 구조에 맞게 수정
4. 예외 처리 보강
5. 보안 검토
6. 테스트 작성
7. 코드 리뷰

AI가 잘하는 코드 작업은 다음과 같다.

- 반복적인 CRUD 코드 초안
- 간단한 변환 함수
- 테스트 데이터 생성
- 정규식 초안
- SQL 초안
- API 응답 타입 정의
- 문서용 예제 코드

반대로 AI에게 전적으로 맡기기 어려운 코드도 있다.

- 결제 처리
- 인증/권한 처리
- 개인정보 암호화
- 정산 로직
- 복잡한 도메인 정책
- 장애 복구 로직
- 대규모 트래픽 처리 로직

이런 코드는 AI가 초안을 도와줄 수는 있지만,
도메인 지식과 운영 경험이 있는 개발자가 반드시 검토해야 한다.

예를 들어 정산 로직은 단순 계산처럼 보여도 실제로는 복잡하다.

- 수수료
- 세금
- 환불
- 보류 금액
- 지급 상태
- 예외 계정
- 기간별 정산 기준
- 운영자 수동 조정 이력

AI가 이런 내부 정책을 모른 상태에서 코드를 작성하면 위험하다.

AI는 빠른 초안 작성에 강하다.
하지만 비즈니스 핵심 로직은 반드시 사람이 중심을 잡아야 한다.

CRUD는 Create, Read, Update, Delete의 약자다.
데이터를 생성, 조회, 수정, 삭제하는 기본 기능을 의미한다.

7. 리팩토링에 활용하기

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

AI는 리팩토링 방향을 찾거나, 긴 코드를 작은 함수로 나누는 데 도움을 줄 수 있다.

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

아래 코드는 방송 시작 처리 로직이야.

문제:
- 조건문이 많아 읽기 어렵다.
- 하나의 함수에서 검증, DB 처리, 외부 API 호출을 모두 처리한다.

요청:
- 기능 동작은 유지하면서 읽기 쉽게 리팩토링 방향을 제안해줘.
- 바로 전체 코드를 바꾸지 말고, 먼저 개선 포인트를 설명해줘.

코드:
[코드 붙여넣기]

이렇게 요청하면 AI가 바로 코드를 갈아엎기보다 구조적 문제를 먼저 설명할 수 있다.

리팩토링에서는 단계가 중요하다.

1. 현재 코드 흐름 설명
2. 문제점 도출
3. 변경해도 되는 부분과 위험한 부분 구분
4. 작은 단위로 개선안 제시
5. 테스트 기준 정리
6. 수정 코드 작성

AI에게 바로 “리팩토링해줘”라고 하면 기존 동작이 바뀔 수 있다.

특히 오래된 코드에서는 작은 조건 하나가 중요한 운영 정책일 수 있다.

예를 들어 이런 조건이 있다고 하자.

if ($user['status'] === 'SUSPENDED' && $user['type'] !== 'PARTNER') {
    return false;
}

AI가 보기에는 이상한 조건처럼 보일 수 있다.

하지만 실제로는 “파트너 계정은 정지 상태여도 특정 관리자 기능은 허용한다”는 내부 정책일 수 있다.

그래서 리팩토링에서는 반드시 조건을 지켜야 한다.

리팩토링 요청 시 조건:
- 기존 동작은 변경하지 마.
- 조건문 의미를 임의로 바꾸지 마.
- 위험한 변경은 별도로 표시해.
- 테스트가 필요한 케이스를 함께 정리해.

AI 리팩토링은 빠르고 유용하지만,
기존 동작 보존이 가장 중요하다.

리팩토링은 기능은 그대로 유지하면서 코드 구조를 개선하는 작업이다.
동작을 바꾸는 것이 목적이 아니라, 읽기 쉽고 유지보수하기 쉽게 만드는 것이 목적이다.

8. 테스트 코드 작성에 활용하기

AI는 테스트 코드 작성에도 매우 유용하다.

개발자는 기능 구현에 집중하다 보면 테스트 케이스를 빠뜨릴 수 있다.
AI는 정상 케이스뿐 아니라 예외 케이스를 찾는 데 도움을 줄 수 있다.

예를 들어 로그인 API 테스트를 만든다고 해보자.

아래 로그인 API에 대한 테스트 케이스를 작성해줘.

관점:
- 정상 로그인
- 존재하지 않는 사용자
- 비밀번호 불일치
- email 누락
- password 누락
- DB 오류
- 로그인 실패 메시지 일관성

테스트 프레임워크:
Jest

코드:
[코드 붙여넣기]

AI는 테스트 코드 초안을 만들어줄 수 있다.

또 코드 없이 테스트 케이스 목록만 먼저 요청할 수도 있다.

로그인 API 테스트 케이스를 표로 정리해줘.

컬럼:
- 케이스
- 입력값
- 기대 결과
- 중요도

이 방식은 개발 전 테스트 설계에도 유용하다.

AI에게 테스트를 요청할 때는 정상 케이스만 요청하면 부족하다.

다음 관점을 함께 줘야 한다.

- 정상 케이스
- 실패 케이스
- 경계값
- 누락값
- 잘못된 타입
- 권한 없음
- 중복 요청
- 외부 API 실패
- DB 오류

예를 들어 후원 처리 기능이라면 이런 테스트가 필요할 수 있다.

- 정상 후원 처리
- 잔액 부족
- 이미 처리된 요청 재전송
- 존재하지 않는 방송방
- 정지된 회원의 후원 요청
- 후원 금액이 0 이하
- PG 콜백 중복 수신
- DB 저장 성공 후 이벤트 발송 실패

AI는 테스트 케이스를 빠르게 확장해준다.

하지만 실제 프로젝트의 테스트 환경, mock 방식, fixture 구조는 개발자가 맞춰야 한다.

mock은 실제 객체나 외부 시스템 대신 테스트용 가짜 객체를 사용하는 방식이다.
예를 들어 실제 결제 API를 호출하지 않고, 성공 응답을 주는 가짜 결제 모듈을 만들어 테스트할 수 있다.

9. 코드 리뷰에 활용하기

AI는 코드 리뷰를 보조하는 데 사용할 수 있다.

코드 리뷰는 사람이 해야 하는 중요한 작업이다.
하지만 AI를 사용하면 리뷰 전에 1차 점검을 할 수 있다.

예를 들어 PR을 올리기 전에 AI에게 다음처럼 요청할 수 있다.

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

관점:
- 버그 가능성
- 예외 처리
- 보안 문제
- 성능 문제
- 기존 동작 변경 가능성
- 테스트 누락

조건:
- 실제 문제가 될 가능성이 높은 것부터 정리
- 단순 취향이나 스타일 지적은 제외
- 수정 방향을 함께 제안

코드:
[변경 코드]

AI는 다음과 같은 문제를 찾아줄 수 있다.

- null 체크 누락
- 배열이 비어 있을 때 예외 가능성
- 권한 체크 위치 문제
- 입력값 검증 부족
- 로그에 민감 정보 노출 가능성
- 중복 요청 처리 누락

AI 코드 리뷰의 장점은 빠르다는 것이다.

사람 리뷰어가 보기 전에 기본적인 위험 요소를 먼저 확인할 수 있다.

하지만 AI 리뷰에는 한계도 있다.

AI는 팀의 코드 스타일, 과거 장애 이력, 의도적인 설계 선택을 모를 수 있다.
또 실제로는 문제가 아닌 부분을 문제라고 지적할 수도 있다.

그래서 AI 리뷰는 사람 리뷰를 대체하는 것이 아니라,
사람 리뷰 전에 사용하는 보조 도구로 보는 것이 좋다.

좋은 사용 방식은 다음과 같다.

개발자 본인 1차 확인
→ AI 리뷰
→ 수정 반영
→ 사람 리뷰어 리뷰
→ 최종 머지

AI 리뷰를 PR 자동화에 연결할 수도 있다.

예를 들어 GitHub Actions에서 변경 파일을 AI에게 보내고,
PR 요약이나 위험 요소를 댓글로 남기게 할 수 있다.

다만 이 경우에도 주의할 점이 있다.

- 회사 코드 외부 전송 가능 여부
- 민감 정보 포함 여부
- AI 리뷰 결과의 신뢰도
- 자동 댓글이 너무 많아지는 문제
- 사람이 검토해야 할 기준

AI 리뷰는 리뷰어의 시간을 줄여줄 수 있지만,
리뷰 책임을 AI에게 넘겨서는 안 된다.

PR은 Pull Request의 약자다.
개발자가 변경한 코드를 메인 브랜치에 반영하기 전에 리뷰를 요청하는 절차를 말한다.

10. 문서 작성에 활용하기

개발자는 생각보다 많은 문서를 작성한다.

- API 문서
- 설계 문서
- 장애 보고서
- 회의록
- 배포 안내
- 운영 매뉴얼
- README
- 코드 주석
- 테스트 시나리오

AI는 이런 문서의 초안을 만드는 데 매우 유용하다.

예를 들어 API 문서를 작성할 때 다음처럼 요청할 수 있다.

아래 API 코드를 기준으로 API 문서 초안을 작성해줘.

포함할 내용:
- API 목적
- 요청 URL
- Method
- 요청 파라미터
- 응답 예시
- 에러 코드
- 주의사항

코드:
[API 코드]

장애 보고서도 초안을 만들 수 있다.

아래 장애 메모를 바탕으로 내부 공유용 장애 보고서 초안을 작성해줘.

형식:
1. 장애 개요
2. 발생 시간
3. 영향 범위
4. 원인
5. 조치 내용
6. 재발 방지 대책
7. 추가 확인 필요 사항

조건:
- 확인된 내용과 추정 내용을 구분해줘.
- 원인이 불확실한 부분은 단정하지 마.

AI 문서 작성의 장점은 시작이 쉬워진다는 것이다.

빈 문서에서 시작하는 것보다 AI 초안을 놓고 수정하는 편이 훨씬 빠르다.

하지만 문서도 반드시 검토해야 한다.

- 사실이 맞는가?
- 독자에게 맞는 수준인가?
- 내부 정보가 외부 문서에 들어가지 않았는가?
- 확인되지 않은 내용을 단정하지 않았는가?
- 후속 작업이 명확한가?

AI는 문장을 잘 만들지만, 문서의 책임은 작성자에게 있다.

특히 임원 보고서, 고객 공지, 장애 보고서처럼 책임이 있는 문서는 반드시 사람이 최종 검토해야 한다.

11. 장애 분석에 활용하기

장애가 발생하면 빠르게 상황을 파악해야 한다.

이때 AI는 로그, 메모, 지표를 정리하고 원인 후보를 뽑는 데 도움을 줄 수 있다.

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

아래 장애 로그와 운영 메모를 보고 원인 후보를 정리해줘.

조건:
- 확인된 사실과 추정되는 원인을 분리
- 원인 후보를 가능성이 높은 순서로 정렬
- 추가로 확인해야 할 로그나 지표 제안
- 임시 대응과 근본 대응을 나눠서 제안

--- 장애 로그 ---
[로그]

--- 운영 메모 ---
[메모]

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

확인된 사실:
- 14:05부터 API 응답 시간이 증가
- 일부 요청에서 Redis timeout 발생
- 동일 시간대 방송방 입장 실패 문의 증가

추정되는 원인:
1. Redis 응답 지연
2. 특정 API 요청 집중
3. 네트워크 지연 가능성

추가 확인 필요:
- Redis Slowlog
- API별 응답 시간
- 해당 시간대 배포 이력
- 서버 CPU/Memory
- 네트워크 지표

임시 대응:
- Redis 연결 재시도 설정 확인
- 문제 API 트래픽 제한 검토

근본 대응:
- Redis 사용 패턴 분석
- 캐시 키 구조 개선
- 장애 알림 기준 추가

이렇게 AI는 복잡한 정보를 구조화하는 데 강하다.

하지만 장애 원인을 AI가 확정하게 하면 안 된다.

AI는 로그 일부만 보고 추정할 뿐이다.

장애 분석에서는 반드시 실제 지표와 로그를 확인해야 한다.

- API 응답 시간
- 에러율
- 서버 CPU/Memory
- DB 커넥션
- Redis 상태
- 배포 이력
- 외부 API 상태
- 네트워크 지표

AI는 장애 대응 회의의 정리 담당자처럼 활용하면 좋다.

사실을 정리하고,
가능성 있는 원인을 나열하고,
추가 확인 항목을 제안하게 하는 것이다.

최종 원인 판단과 조치 결정은 사람이 해야 한다.

12. 운영 체크리스트 작성에 활용하기

새 기능을 배포하기 전에는 체크리스트가 필요하다.

하지만 매번 처음부터 체크리스트를 만드는 것은 번거롭다.

AI는 기능별 운영 체크리스트를 빠르게 만들어줄 수 있다.

예를 들어 AI 기반 고객 문의 요약 기능을 배포한다고 해보자.

AI 기반 고객 문의 요약 기능을 운영 배포하기 전에 확인해야 할 체크리스트를 만들어줘.

관점:
- 기능
- 보안
- 개인정보
- 비용
- 장애 대응
- 로그
- 관리자 UX

출력 형식:
| 구분 | 체크 항목 | 확인 방법 | 중요도 |

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

체크리스트는 배포 품질을 높이는 데 도움이 된다.

AI를 사용하면 다양한 관점을 빠르게 포함할 수 있다.

다만 AI가 만든 체크리스트도 우리 서비스에 맞게 조정해야 한다.

- 실제 배포 절차와 맞는가?
- 담당자가 명확한가?
- 확인 방법이 현실적인가?
- 빠진 내부 정책은 없는가?
- 중요도 기준이 적절한가?

AI 체크리스트는 초안으로 사용하고,
팀의 운영 경험을 반영해 최종 체크리스트로 다듬는 것이 좋다.

13. 학습과 온보딩에 활용하기

AI는 개발자의 학습과 온보딩에도 도움이 된다.

새로운 개발자가 팀에 합류하면 알아야 할 것이 많다.

- 서비스 구조
- 도메인 용어
- API 흐름
- 배포 방식
- 장애 대응 절차
- 코드 스타일
- 주요 DB 테이블
- 운영 정책

AI를 활용하면 기존 문서나 코드를 바탕으로 학습 자료를 만들 수 있다.

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

아래 회원 API 문서를 신입 백엔드 개발자 온보딩 자료로 바꿔줘.

조건:
- 처음 보는 사람도 이해할 수 있게 설명
- 주요 API 흐름 중심
- 실무에서 주의해야 할 점 포함
- 마지막에 확인 질문 5개 추가

문서:
[회원 API 문서]

또는 코드 분석 결과를 학습 자료로 바꿀 수도 있다.

아래 방송 시작 API 코드를 온보딩 자료로 설명해줘.

출력 형식:
1. 이 API의 역할
2. 전체 처리 흐름
3. 주요 조건
4. DB 변경 지점
5. 외부 연동 지점
6. 주의해야 할 운영 이슈

AI는 어려운 코드를 쉽게 설명하는 데 강하다.

또 같은 내용을 여러 수준으로 바꿔 설명할 수 있다.

이 내용을 신입 개발자 수준으로 설명해줘.

이번에는 팀장 보고용으로 핵심만 요약해줘.

이번에는 실제 작업자가 봐야 할 체크리스트로 바꿔줘.

이렇게 하면 하나의 자료를 여러 목적에 맞게 재사용할 수 있다.

다만 온보딩 자료는 정확성이 중요하다.

AI가 내부 정책을 추측해서 잘못 설명할 수 있으므로,
반드시 기존 담당자가 최종 검토해야 한다.

14. 반복 업무 자동화에 활용하기

개발팀에는 반복적으로 발생하는 업무가 많다.

- PR 요약 작성
- 릴리즈 노트 작성
- 회의록 정리
- 장애 보고서 초안 작성
- Jira 이슈 정리
- 테스트 케이스 초안 작성
- API 문서 생성
- 운영 체크리스트 작성

AI는 이런 반복 업무를 줄이는 데 효과적이다.

예를 들어 PR 요약을 자동화할 수 있다.

아래 변경 내용을 바탕으로 PR 요약을 작성해줘.

출력 형식:
## 변경 요약
## 주요 변경 파일
## 테스트 방법
## 리뷰어가 중점적으로 봐야 할 부분

변경 내용:
[git diff 또는 커밋 목록]

릴리즈 노트도 만들 수 있다.

아래 Jira 이슈 목록과 PR 목록을 바탕으로 릴리즈 노트를 작성해줘.

조건:
- 사용자에게 영향 있는 변경 중심
- 내부 리팩토링은 별도 구분
- 장애 수정은 명확히 표시
- 너무 기술적인 표현은 줄여줘.

입력:
[Jira 이슈 목록]
[PR 목록]

이런 작업은 매번 사람이 처음부터 쓰기보다,
AI가 초안을 만들고 사람이 검토하는 방식이 효율적이다.

반복 업무 자동화는 나중에 API, GitHub Actions, Jira 연동과 연결할 수 있다.

처음에는 ChatGPT 같은 도구에 직접 붙여 넣어 사용하고,
반복이 많아지면 자동화하는 방식이 좋다.

수동 활용:
개발자가 직접 AI에게 요청

반자동:
템플릿을 만들어 반복 사용

자동화:
GitHub Actions, Jira, Slack, MCP 등을 연결해 자동 실행

처음부터 거창한 자동화를 만들 필요는 없다.

반복되는 업무를 찾고,
AI로 초안을 만들고,
효과가 확인되면 자동화하는 순서가 좋다.

15. AI를 사용할 때 업무별 주의사항

AI는 개발 업무 전반에 사용할 수 있지만, 업무마다 주의할 점이 다르다.

요구사항 정리에서는 AI가 누락한 정책을 확인해야 한다.

주의할 점:
- AI가 내부 정책을 모를 수 있음
- 기획 의도를 잘못 해석할 수 있음
- 최종 요구사항은 담당자 확인 필요

코드 작성에서는 실행과 테스트가 중요하다.

주의할 점:
- 존재하지 않는 함수 사용 가능
- 프로젝트 구조와 맞지 않을 수 있음
- 보안과 예외 처리가 부족할 수 있음

코드 리뷰에서는 AI 지적을 그대로 믿으면 안 된다.

주의할 점:
- 실제 문제가 아닌 것을 문제라고 할 수 있음
- 중요한 도메인 정책을 놓칠 수 있음
- 사람 리뷰를 대체하면 안 됨

문서 작성에서는 독자와 공개 범위가 중요하다.

주의할 점:
- 내부 정보가 외부 문서에 포함될 수 있음
- 확인되지 않은 원인을 단정할 수 있음
- 문체가 보고 대상과 맞지 않을 수 있음

장애 분석에서는 사실과 추정을 구분해야 한다.

주의할 점:
- 로그 일부만 보고 원인을 단정할 수 있음
- 실제 지표 확인 없이 결론을 낼 수 있음
- 임시 조치와 근본 대책이 섞일 수 있음

AI는 업무를 빠르게 도와주지만,
업무의 책임은 여전히 사람에게 있다.

16. AI 활용을 팀 문화로 만드는 방법

AI 활용은 개인이 잘 쓰는 것에서 끝나지 않는다.

팀 전체가 잘 쓰려면 공통 기준이 필요하다.

예를 들어 팀에서 자주 쓰는 프롬프트 템플릿을 만들 수 있다.

- 코드 리뷰 프롬프트
- 장애 보고서 프롬프트
- API 문서 생성 프롬프트
- 테스트 케이스 생성 프롬프트
- PR 요약 프롬프트
- 보안 점검 프롬프트

또 AI 사용 규칙도 필요하다.

- 어떤 데이터를 AI에 입력해도 되는가?
- 어떤 데이터는 입력하면 안 되는가?
- 코드 입력은 어디까지 허용되는가?
- AI가 만든 코드는 어떤 검토를 거쳐야 하는가?
- AI 답변을 공식 문서에 사용할 때 검토자는 누구인가?

AI 활용 결과를 공유하는 것도 좋다.

- 유용했던 프롬프트 공유
- 실패 사례 공유
- AI가 놓친 보안 이슈 공유
- 자동화 가능한 반복 업무 목록화
- 팀 공통 체크리스트 개선

AI를 잘 쓰는 팀은 단순히 도구를 많이 쓰는 팀이 아니다.

AI가 만든 결과를 검토하는 기준이 있고,
민감 정보를 보호하는 규칙이 있고,
반복 업무를 점진적으로 자동화하는 팀이다.

개인 생산성을 높이는 것에서 시작해,
팀의 개발 프로세스를 개선하는 방향으로 확장해야 한다.

17. AI를 개발 업무에 적용하는 단계

AI 활용은 한 번에 크게 바꾸려고 하면 실패하기 쉽다.

작게 시작해서 효과를 확인하고, 점점 확장하는 것이 좋다.

추천하는 단계는 다음과 같다.

1단계: 개인 생산성 향상
- 코드 설명
- 문서 초안
- 테스트 케이스 아이디어
- 에러 분석

2단계: 팀 공통 템플릿화
- 코드 리뷰 프롬프트
- 장애 보고서 양식
- PR 요약 양식
- 배포 체크리스트

3단계: 반복 업무 반자동화
- Jira 이슈 요약
- 릴리즈 노트 초안
- 회의록 정리
- 테스트 케이스 생성

4단계: 개발 프로세스 연동
- GitHub Actions 연동
- PR 자동 요약
- 코드 리뷰 보조
- 문서 자동 생성

5단계: 내부 시스템과 연결
- 사내 문서 검색
- 운영 로그 분석
- 업무 도구 연동
- MCP 기반 자동화

처음부터 AI 에이전트나 복잡한 자동화를 만들 필요는 없다.

가장 먼저 해야 할 일은 현재 개발팀에서 반복적으로 시간이 많이 드는 작업을 찾는 것이다.

- 매번 비슷한 보고서를 쓰는가?
- PR 설명이 부족해서 리뷰 시간이 오래 걸리는가?
- 장애 보고서 작성에 시간이 많이 걸리는가?
- 신규 입사자가 코드 이해에 오래 걸리는가?
- 테스트 케이스 누락이 자주 발생하는가?

이런 문제부터 AI를 적용하면 효과를 빠르게 확인할 수 있다.

18. 정리

AI는 개발 업무의 여러 단계에서 사용할 수 있다.

요구사항을 정리하고,
개발 전 확인 질문을 만들고,
설계 초안을 작성하고,
기존 코드를 이해하고,
코드를 작성하고,
리팩토링하고,
테스트 케이스를 만들고,
코드 리뷰를 보조하고,
문서를 작성하고,
장애를 분석하고,
운영 체크리스트를 만들 수 있다.

하지만 AI는 개발자를 대신하는 존재가 아니다.

AI는 빠른 초안을 만들고,
놓칠 수 있는 관점을 제안하고,
반복 업무를 줄여주는 도구다.

최종 판단은 개발자가 해야 한다.

특히 코드, 보안, 비용, 장애, 개인정보와 관련된 결과는 반드시 검증해야 한다.

AI를 잘 활용하는 개발자는 단순히 질문을 잘하는 사람이 아니다.

AI가 필요한 업무를 찾고,
초안을 빠르게 만들고,
검토 기준에 따라 수정하고,
팀의 반복 업무를 개선하는 사람이다.

이 장에서 기억해야 할 핵심은 하나다.

AI는 코드를 대신 짜주는 도구를 넘어,
개발 업무 전체를 더 빠르고 체계적으로 만드는 보조 도구다.

7장 핵심 요약