개발과 IT 운영에서의 AI

새벽 2시, AI가 개발자를 깨우는 방식

새벽 2시 13분. 결제 API의 오류율이 갑자기 치솟고, 슬랙 채널에는 알림이 쏟아집니다. 온콜 엔지니어는 대시보드 세 개, 로그 검색 화면 두 개, 최근 배포 내역, 설정 변경 기록, 이전 장애 보고서를 번갈아 봅니다. 문제는 코드 한 줄일 수도 있고, 캐시 설정일 수도 있고, 방금 적용된 네트워크 정책일 수도 있습니다. 이때 AI가 할 수 있는 일은 '정답을 맞히는 마술'이 아닙니다. 대신 흩어진 단서를 한곳에 모아 "가장 의심스러운 후보"를 빠르게 정리해 주는 것입니다.

개발과 IT 운영에서 AI의 가치는 바로 여기에 있습니다. AI는 개발자를 대체하기보다 반복 코딩, 검색, 요약, 초안 작성, 점검 목록 확인처럼 시간을 잡아먹는 일을 줄여 줍니다. 그렇게 확보한 시간은 더 중요한 설계 판단, 장애 영향도 판단, 보안 검토, 사용자 경험 개선에 쓰일 수 있습니다. 실제로 IBM은 McKinsey 조사를 인용하며 AI를 잘 활용한 고성과 소프트웨어 조직이 팀 생산성 16~30%, 소프트웨어 품질 31~45% 향상을 보고했다고 소개합니다.¹ 다만 이 숫자는 "AI에게 코드를 많이 쓰게 했다"는 뜻으로 읽으면 곤란합니다. 좋은 조직은 AI를 개발 생명주기 전체에 배치하고, 사람이 검증해야 할 지점을 명확히 둡니다.

AI는 코드 자동완성 도구가 아니라 SDLC 보조 엔진입니다

많은 팀이 AI 도입을 코드 에디터 자동완성에서 시작합니다. 이것은 좋은 출발점입니다. 하지만 거기서 멈추면 효과도 작게 머뭅니다. 소프트웨어 개발 생명주기, 즉 SDLC는 요구사항 이해, 설계, 구현, 테스트, 코드 리뷰, 배포, 운영, 문서화가 이어지는 긴 흐름입니다. AI는 이 흐름의 거의 모든 단계에서 반복 작업을 덜어 줄 수 있습니다.

핵심은 AI를 '코드 쓰는 손'으로만 보지 않는 것입니다. AI는 요구사항을 코드로 번역하기 전의 모호함을 줄이고, 코드가 작성된 뒤에는 테스트와 문서화의 빈틈을 채우며, 배포 이후에는 장애 대응 속도를 높입니다. 여러 SDLC 단계에 AI를 배치할수록 효과가 누적된다는 점은 생성형 AI 소프트웨어 개발 사례 자료에서도 반복적으로 강조됩니다.²

코드 작성 보조: 함수 하나보다 맥락 하나를 주세요

AI에게 "로그인 함수 만들어 줘"라고 요청하면 그럴듯한 코드를 줄 수 있습니다. 하지만 그 코드는 우리 서비스의 인증 정책, 에러 응답 형식, 로깅 규칙, 테스트 프레임워크, 보안 요구사항을 모릅니다. 개발에서 AI 출력 품질을 가르는 차이는 모델의 똑똑함보다 "맥락을 얼마나 잘 줬는가"에 있을 때가 많습니다.

좋은 요청은 이렇게 구성할 수 있습니다.

역할: 너는 이 저장소의 백엔드 개발 보조자다.
목표: 주문 생성 API의 서비스 레이어 초안을 작성한다.
맥락: Node.js, TypeScript, Express, Prisma를 사용한다. 기존 에러 형식은 AppError를 따른다.
제약: 결제 호출은 아직 구현하지 말고 인터페이스만 둔다. DB 트랜잭션을 사용한다. 입력 검증은 zod 스키마를 사용한다.
출력: 서비스 함수 코드, 필요한 타입, 단위 테스트 초안을 함께 제시한다.
검토 포인트: 예외 처리, 동시성, 테스트 누락 가능성을 마지막에 따로 적는다.

이렇게 요청하면 AI는 단순히 코드를 찍어 내는 기계가 아니라, 팀의 규칙을 따라 작업하는 보조 개발자에 가까워집니다. 특히 반복적인 보일러플레이트에는 효과가 큽니다. 관리자 페이지의 기본 CRUD API, 외부 API 클라이언트, DTO 변환 코드, 설정 파일, 마이그레이션 스크립트, 테스트 더미 데이터 생성기는 사람이 매번 처음부터 쓸 필요가 없습니다.

꿀팁은 '생성'과 '검토'를 분리하는 것입니다. 한 번의 프롬프트로 코드를 만들고 검토까지 끝내려 하지 마세요. 먼저 초안을 만들게 한 뒤, 다음 프롬프트에서 완전히 다른 관점으로 공격하게 하는 편이 좋습니다.

방금 작성한 코드를 리뷰어처럼 검토해 줘.
다음 항목을 반드시 확인해라.
보안 취약점, 성능 병목, 예외 처리 누락, 동시성 문제, 테스트 누락, 오픈소스 라이선스 위험, 로깅에 민감정보가 남을 가능성.
각 항목마다 위험도와 수정 제안을 표로 정리해라.

이 두 번째 프롬프트가 중요합니다. AI가 만든 코드는 "거의 맞지만 어딘가 위험한" 상태일 수 있습니다. 개발자는 AI가 준 답을 그대로 붙여 넣는 사람이 아니라, AI가 만든 후보를 선택하고 다듬고 버릴 줄 아는 책임자여야 합니다.

테스트와 리뷰: AI를 두 번째 눈으로 세우세요

테스트 작성은 개발자가 자주 미루는 일 중 하나입니다. 이유는 간단합니다. 기능 구현보다 덜 즐겁고, 시간이 부족할 때 가장 먼저 잘리기 쉽기 때문입니다. 그러나 AI는 바로 이 지점에서 강력합니다. 함수의 입력과 출력, 예외 상황, 경계값을 읽고 단위 테스트 초안을 빠르게 만들 수 있기 때문입니다.

예를 들어 결제 금액 계산 함수가 있다면 AI에게 정상 케이스만 묻지 말고, 실패와 경계 조건을 함께 요구해야 합니다. 무료 쿠폰, 소수점 반올림, 음수 입력, 통화 단위, 최대 할인 한도, 동시 주문 요청 같은 상황을 명시하면 테스트 품질이 달라집니다. 통합 테스트에서는 외부 API 실패, 타임아웃, 재시도, 부분 성공, 롤백 조건을 묻는 것이 좋습니다.

AI 에이전트는 반복적인 PR 리뷰 항목도 잘 처리합니다. 변수명이 팀 규칙과 맞는지, 새 API에 문서가 붙었는지, 에러 응답 형식이 일관적인지, 테스트 파일이 함께 변경됐는지, 보안 스캔을 통과했는지 확인할 수 있습니다. 사람 리뷰어는 그 대신 더 중요한 질문에 집중합니다. 이 변경이 시스템의 책임 경계를 흐리지는 않는가. 앞으로 기능이 늘어날 때 유지보수하기 쉬운가. 지금 빠르게 합치는 것이 장기 기술 부채를 만들지는 않는가.

배포 전 체크리스트도 AI와 잘 맞습니다. 릴리스 노트를 요약하고, 마이그레이션 포함 여부를 확인하고, 롤백 절차가 있는지 점검하고, 관측 지표가 준비됐는지 확인하게 할 수 있습니다. 단, 체크리스트 통과는 "병합 허가"가 아니라 "검토 자료"입니다. 최종 병합과 배포 판단은 여전히 개발자와 운영자가 내려야 합니다.

대규모 코드베이스: AI를 코드 탐험가로 만들기

신규 개발자가 오래된 저장소에 처음 들어갔다고 해 보겠습니다. 폴더는 120개, 서비스는 40개, README는 2년 전 상태입니다. 로그인 흐름 하나를 이해하려고 해도 컨트롤러, 미들웨어, 세션 저장소, 권한 검사, 프론트엔드 라우터, 테스트 파일을 계속 오가야 합니다. 이때 AI는 '검색창'보다 훨씬 유용한 코드 탐험가가 됩니다.

대규모 코드베이스에서 AI에게 맡기기 좋은 질문은 구체적이어야 합니다.

• 이 모듈의 책임을 10줄 이내로 요약해 줘.

• 이 함수가 호출되는 경로와 주요 호출자를 정리해 줘.

• 이 API 응답 필드를 바꾸면 영향을 받을 가능성이 있는 파일을 찾아 줘.

• 관련 테스트 파일과 누락된 테스트 후보를 알려 줘.

• 이 코드가 의존하는 외부 서비스와 실패 시 동작을 설명해 줘.

이런 작업은 신규 개발자 온보딩 시간을 줄이고, 레거시 코드 탐색 시간을 단축합니다. 특히 '변경 영향도'를 묻는 질문은 실무에서 큰 가치를 만듭니다. 예를 들어 고객 등급 계산 로직을 수정해야 할 때, AI가 관련 모듈, 배치 작업, 관리자 화면, 리포트 쿼리, 테스트 위치를 한 번에 정리해 주면 개발자는 무작정 grep을 반복하지 않아도 됩니다.

하지만 AI 요약은 지도이지 영토가 아닙니다. 코드베이스가 크고 복잡할수록 AI는 오래된 문서, 사용되지 않는 코드, 테스트와 실제 운영 흐름의 차이를 혼동할 수 있습니다. 그래서 중요한 변경은 반드시 코드 리뷰, 테스트, 실제 호출 로그, 배포 이력으로 확인해야 합니다. AI가 "영향 없음"이라고 말해도 운영 데이터가 다르게 말하면 운영 데이터가 이깁니다.

RAG 내부 지식 검색: 사내 개발 기억을 연결하세요

개발팀의 지식은 코드에만 있지 않습니다. 이슈 트래커에는 왜 특정 버그를 고쳤는지가 남아 있고, PR에는 설계 논쟁의 흔적이 있으며, 장애 보고서에는 다시 밟으면 안 되는 지뢰가 적혀 있습니다. 아키텍처 결정 기록, API 명세, 사내 위키, 배포 가이드, 고객 문의 기록까지 합치면 조직의 개발 지식은 거대한 퍼즐이 됩니다.

RAG는 Retrieval-Augmented Generation의 줄임말로, 쉽게 말하면 '내부 자료를 먼저 찾아보고 그 근거를 바탕으로 답하는 AI 방식'입니다. 일반 챗봇에게 묻는 대신, 사내 문서와 코드 저장소를 검색해 관련 조각을 가져오고, 그 조각을 근거로 답을 만들게 하는 구조입니다. 이렇게 하면 "그럴듯한 추측"보다 "근거 링크가 있는 답변"에 가까워집니다.

RAG 기반 개발 지식 검색이 답할 수 있는 질문은 다음과 같습니다.

• 이 API를 바꾸면 어떤 서비스와 화면이 영향받는가?

• 지난번 동일한 장애는 어떤 원인으로 발생했고 어떻게 복구했는가?

• 이 테이블 컬럼은 왜 nullable로 설계됐는가?

• 특정 모듈의 소유 팀과 최근 주요 변경자는 누구인가?

• 결제 서비스의 배포 전 필수 점검 항목은 무엇인가?

구축할 때는 자료를 많이 넣는 것보다 권한과 신뢰도를 먼저 설계해야 합니다. 모든 문서를 한꺼번에 넣으면 오래된 문서가 최신 코드보다 큰 목소리를 낼 수 있습니다. 문서별 최신성, 출처, 소유자, 접근 권한, 폐기 여부를 함께 저장해야 합니다. 답변에는 반드시 근거 링크를 붙이게 하고, 근거가 없으면 "확실하지 않음"이라고 말하게 해야 합니다.

실무적으로는 세 단계로 시작하면 좋습니다. 첫째, README, API 명세, 장애 보고서처럼 정돈된 문서부터 색인합니다. 둘째, 코드 저장소와 PR 기록을 연결합니다. 셋째, 이슈 트래커와 운영 로그 요약을 붙입니다. 처음부터 완벽한 사내 AI 포털을 만들려고 하면 실패하기 쉽습니다. 가장 자주 묻는 질문 20개를 정하고, 그 질문에 대한 답변 품질을 높이는 방식으로 시작하세요.

레거시 현대화: AI에게 재작성 버튼이 아니라 손전등을 주세요

레거시 시스템 앞에서 가장 위험한 말은 "AI로 한 번에 새로 만들자"입니다. 오래된 코드는 보기 싫어도 회사의 실제 업무 규칙을 품고 있습니다. 어떤 이상한 if문은 10년 전 대형 고객의 예외 계약 때문일 수 있고, 아무도 지우지 못한 배치 작업은 월말 정산을 지탱하고 있을 수 있습니다. AI가 그 맥락을 모르고 깔끔하게 고치면, 코드는 아름다워져도 비즈니스는 깨질 수 있습니다.

레거시 현대화에서 AI가 가장 잘하는 일은 "먼저 이해하게 만드는 것"입니다. 코드 고고학, 의존성 지도 작성, 중복 패턴 탐지, 오래된 API 후보 찾기, 주석과 문서 초안 작성, 테스트 후보 생성처럼 인간이 지치기 쉬운 작업을 빠르게 처리합니다. Coder의 레거시 현대화 가이드도 AI가 마법의 변환 버튼이 아니라 코드 탐색, 패턴 인식, 기계적 변환, 문서화에서 특히 유용하다는 현실적인 관점을 제시합니다.³

안전한 순서는 다음과 같습니다.

1. 현재 시스템의 핵심 흐름과 절대 바뀌면 안 되는 동작을 적습니다.

2. AI로 모듈, 의존성, 외부 연동, 데이터 흐름을 요약하게 합니다.

3. 기존 동작을 고정하는 골든 마스터 테스트나 특성화 테스트를 만듭니다.

4. 작은 단위로 리팩터링하고, 한 PR에는 하나의 의도만 담습니다.

5. CI에서 회귀 테스트, 보안 검사, 의존성 검사를 통과해야만 병합합니다.

6. 카나리 배포나 섀도 트래픽으로 실제 동작 차이를 비교합니다.

이 흐름의 핵심은 "행동을 먼저 잠그고, 구조를 나중에 바꾸는 것"입니다. 테스트가 없으면 AI가 만든 개선이 실제로는 동작 변경인지 알 수 없습니다. 그래서 레거시 현대화에서 AI 테스트 생성은 코드 변환만큼 중요합니다. 레거시 현대화 실무 가이드들도 의존성 매핑, 동작 기준선, 작은 PR, CI 품질 게이트, 별도 보안 검사를 안전장치로 강조합니다.⁴

AI SRE: 장애 원인 후보를 빠르게 좁히는 운영 동료

운영에서 AI의 역할은 개발과 조금 다릅니다. 개발 단계의 AI가 "코드를 빨리 이해하고 초안을 만드는 도구"라면, SRE와 IT 운영의 AI는 "상황을 빠르게 정리하고 다음 행동 후보를 제시하는 도구"입니다. 장애가 발생하면 로그, 메트릭, 트레이스, 알림, 배포 이력, 설정 변경, 인프라 이벤트가 동시에 쏟아집니다. 사람은 이 모든 것을 한 번에 보기 어렵습니다.

AI SRE는 다음과 같은 흐름으로 도움을 줄 수 있습니다.

예를 들어 특정 서비스의 500 오류가 급증했다면 AI는 최근 30분 내 배포된 PR, 같은 시간대의 DB 커넥션 증가, 특정 엔드포인트의 지연, 설정 저장소 변경을 함께 보여 줄 수 있습니다. "방금 바뀐 인증 미들웨어가 결제 콜백 요청을 차단했을 가능성"처럼 원인 후보를 제시할 수도 있습니다. IBM은 ServiceNow, 데이터 정규화, 그래프 기반 시각화, 에이전트형 AI, 실행 플레이북을 연결해 장애 데이터를 해석하고 조치안을 제안하는 접근을 설명합니다.⁵

다만 운영 자동화는 단계적으로 적용해야 합니다. 모든 조치를 자동 실행하게 만들면, 잘못된 판단이 장애를 더 키울 수 있습니다. 현실적인 운영 수준은 다음 세 단계로 나누는 것이 좋습니다.

• 보조 단계: AI가 요약, 원인 후보, 조치안을 제시하지만 실행은 사람이 합니다.

• 반자동 단계: AI가 명령어와 런북을 준비하고, 운영자가 확인 후 실행합니다.

• 조건부 자동 단계: 영향이 작고 되돌리기 쉬운 조치는 자동 실행하되, 고객 영향이 큰 조치는 승인 흐름을 거칩니다.

예를 들어 개발 환경의 죽은 테스트 컨테이너 정리는 자동화할 수 있습니다. 그러나 프로덕션 데이터베이스의 설정 변경, 대규모 롤백, 트래픽 차단은 사람 승인 없이 실행해서는 안 됩니다. 자동화의 기준은 "AI가 얼마나 자신 있어 하는가"가 아니라 "틀렸을 때 얼마나 빨리 되돌릴 수 있는가"여야 합니다.

개발팀을 위한 실전 꿀팁 모음

첫째, AI에게 한 번에 큰 일을 맡기지 말고 작은 단위로 나누세요. "이 서비스를 개선해 줘"보다 "이 함수의 예외 처리를 우리 에러 규칙에 맞게 바꿔 줘"가 낫습니다. AI는 범위가 좁고 성공 기준이 명확할수록 강해집니다.

둘째, 코드 생성 프롬프트에는 반드시 금지 조건을 넣으세요. 예를 들어 "새 라이브러리를 추가하지 마라", "공개 API 응답 형식은 바꾸지 마라", "마이그레이션 없이 DB 스키마를 바꾸지 마라"처럼 제약을 적으면 사고를 줄일 수 있습니다.

셋째, AI가 만든 테스트를 그대로 믿지 마세요. AI는 테스트처럼 보이는 코드를 잘 만듭니다. 하지만 그 테스트가 정말 중요한 위험을 잡는지는 사람이 봐야 합니다. 특히 "구현을 그대로 따라 하는 테스트"는 버그까지 함께 승인해 버릴 수 있습니다.

넷째, AI 리뷰는 사람 리뷰 전에 돌리세요. 사소한 스타일, 누락된 문서, 명백한 예외 처리 문제는 AI가 먼저 잡게 하고, 사람은 설계와 의미를 보게 하는 편이 좋습니다. 이렇게 하면 리뷰 피로도가 줄어듭니다.

다섯째, 보안 검토는 별도 루프로 분리하세요. AI에게 보안 취약점을 묻는 것도 필요하지만, SAST, 의존성 스캔, 비밀키 탐지, 라이선스 검사 같은 도구를 함께 써야 합니다. AI 리뷰는 보안 체계의 일부이지 대체물이 아닙니다.

여섯째, 사내 코드와 데이터를 외부 AI 도구에 넣을 때는 규칙을 세우세요. 어떤 코드는 입력해도 되는지, 어떤 데이터는 익명화해야 하는지, 고객 정보와 비밀키는 어떻게 차단할지 정해야 합니다. 개발자 개인의 판단에만 맡기면 언젠가 사고가 날 수 있습니다.

조직 도입법: 도구보다 루틴이 먼저입니다

AI 개발 도구를 도입할 때 가장 흔한 실패는 라이선스만 나눠 주고 끝내는 것입니다. 어떤 팀원은 매일 쓰고, 어떤 팀원은 불신해서 쓰지 않습니다. 어떤 사람은 생산성이 오르고, 어떤 사람은 AI가 만든 코드를 디버깅하느라 더 느려집니다. 지속적인 효과를 내려면 도구가 아니라 운영 루틴을 설계해야 합니다.

먼저 사용 사례를 고릅니다. 전사적으로 "AI로 개발 생산성 향상"이라는 모호한 목표를 세우기보다, 반복 CRUD 생성, 테스트 초안, PR 체크리스트, 장애 보고서 초안, 레거시 모듈 요약처럼 측정 가능한 사례부터 시작합니다. 다음으로 교육과 코칭을 붙입니다. 좋은 프롬프트 예시, 금지 사례, 보안 규칙, 리뷰 기준을 팀 단위로 공유해야 합니다.

측정도 중요합니다. 단순히 "AI가 몇 줄의 코드를 만들었는가"를 재면 안 됩니다. 줄 수는 많아도 품질이 나쁘면 부채만 늘어납니다. 대신 변경 리드타임, 배포 빈도, 변경 실패율, 장애 복구 시간, 리뷰 대기 시간, 테스트 커버리지의 의미 있는 변화, 개발자 만족도를 함께 봐야 합니다. IBM은 개발 생산성을 볼 때 DORA 지표와 SPACE 프레임워크처럼 속도와 품질, 개발자 경험을 함께 고려해야 한다고 설명합니다.¹

마지막으로 위험 통제를 제도화합니다. AI가 생성한 코드는 반드시 리뷰 대상이어야 하고, 중요한 변경에는 테스트와 보안 검사가 따라야 합니다. 내부 RAG 답변은 근거 링크를 포함해야 하며, 근거 없는 답변은 낮은 신뢰도로 표시해야 합니다. 운영 자동화는 심각도와 영향 범위에 따라 승인 흐름을 달리해야 합니다. 생산성은 통제와 함께 갈 때 오래갑니다.

개발자의 일은 더 어려워지고, 더 중요해집니다

AI가 반복 코딩을 줄이면 개발자의 일이 쉬워질까요? 어느 정도는 그렇습니다. 검색하고, 복사하고, 틀을 만들고, 문서를 시작하는 부담은 줄어듭니다. 그러나 동시에 개발자의 책임은 더 선명해집니다. 무엇을 만들지, 어떤 구조가 오래 버틸지, 어떤 위험을 감수할지, 어느 지점에서 자동화를 멈출지 판단해야 하기 때문입니다.

좋은 개발팀은 AI를 막연히 두려워하지도, 무작정 믿지도 않습니다. AI에게 반복 작업을 맡기되, 설계 판단은 사람이 합니다. AI에게 테스트 초안을 만들게 하되, 무엇이 중요한 테스트인지는 사람이 정합니다. AI에게 장애 원인 후보를 좁히게 하되, 고객 영향과 실행 승인은 운영자가 책임집니다.

결국 개발과 IT 운영에서 AI의 본질은 '대체'가 아니라 '증폭'입니다. 평범한 팀도 좋은 루틴을 갖추면 더 빠르게 배우고, 더 안전하게 배포하고, 장애에서 더 빨리 회복할 수 있습니다. 그리고 뛰어난 개발자는 키보드를 덜 두드리는 대신, 시스템을 더 깊이 이해하고 더 나은 결정을 내리는 데 시간을 쓰게 됩니다.

참고

¹IBM Think: 6 ways to enhance developer productivity with—and beyond—AI

²Space-O: 10 Generative AI Use Cases in Software Development Across the SDLC

³Coder: AI-Assisted Legacy Code Modernization: A Developer's Guide

⁴CodeGeeks Solutions: Legacy Code Modernization Using AI: Safe Steps, Tools, and Pitfalls

⁵IBM: Transforming IT incident response: How agentic AI automates root cause analysis and recovery