시리즈를 시작하며: 왜 ‘휴먼 인 더 루프’인가

안녕하세요. 금융IT 분야에서 20년째 코드를 쓰고, 그중 8년을 챗봇 시스템을 운영하며 보낸 개발자입니다. 이 글은 회사의 입장이 아닌 순전히 개인의 경험과 견해임을 먼저 밝힙니다.

이 시리즈 「휴먼 인 더 루프: AI 시대, 사람만 할 수 있는 일」은 총 12화에 걸쳐, AI가 빠르게 침투하는 업무 현장에서 사람의 역할이 어떻게 재정의되고 있는지를 다룹니다. 거창한 미래학이 아니라, 매일 아침 터미널을 열고 장애 알림을 확인하는 현장 개발자의 눈으로 본 이야기입니다.

앞으로의 여정을 간략히 소개하면 이렇습니다:

• 1~3화: AI 도입 현실 진단 — 기대와 실제의 격차
• 4~6화: 사람이 개입해야 하는 지점 — 판단·맥락·책임
• 7~9화: 협업 설계 — AI와 사람의 역할 분배 전략
• 10~12화: 생존 전략 — 대체되지 않는 역량 만들기

오늘은 그 첫 번째 이야기입니다. AI를 도입하면 업무가 줄어들 거라는 기대, 결과는 정반대였습니다.

우리 팀에 AI가 들어온 날

1년 전쯤이었습니다. 조직 차원에서 대규모 언어 모델 기반 도구가 도입됐습니다. 코드 리뷰 보조, 문서 자동 생성, 테스트 케이스 추천, 장애 로그 요약까지. 팀원들의 첫 반응은 한결같았습니다.

“드디어 야근이 줄겠다.”

솔직히 저도 그렇게 생각했습니다. 20년간 반복해온 보일러플레이트 코드, 매번 비슷한 패턴의 장애 보고서 작성, 신규 입사자를 위한 온보딩 문서 업데이트 — 이런 것들이 자동화되면 핵심 로직에만 집중할 수 있을 거라 믿었습니다.

3개월이 지났을 때, 팀의 JIRA 보드를 보고 당황했습니다. 티켓 수가 도입 전보다 40% 넘게 증가해 있었습니다. 단순히 일이 늘어난 게 아니었습니다. 일의 종류가 달라져 있었습니다.

바빠진 이유 #1: 검증 비용의 폭발

AI가 코드를 생성하면 끝일까요? 아닙니다. 생성된 코드를 검증하는 일이 새로 생깁니다. 그것도 상당히 미묘한 형태로요.

예를 들어볼게요. AI가 작성한 금융 거래 처리 로직이 있습니다. 문법적으로 완벽하고, 단위 테스트도 통과합니다. 하지만 특정 시간대에 원화-달러 환율 적용 순서가 뒤바뀌는 엣지 케이스를 놓치고 있습니다. 이건 10년 전 한 번 발생했던 장애에서 배운 교훈인데, 어떤 문서에도 명시적으로 적혀 있지 않은 암묵지입니다.

AI는 이런 맥락을 모릅니다. 그래서 사람이 한 줄 한 줄 읽어야 합니다. 문제는 이렇습니다:

• 직접 작성한 코드는 작성 과정에서 이미 사고가 반영되어 있어 리뷰가 빠릅니다.
• AI가 생성한 코드는 ‘왜 이렇게 썼는지’를 역추적해야 하므로 리뷰 시간이 오히려 늘어납니다.

실제로 팀 내 코드 리뷰 시간을 측정해봤습니다. AI 보조 도입 전에는 PR당 평균 리뷰 시간이 25분이었는데, 도입 후에는 38분으로 증가했습니다. 코드 작성 시간은 줄었지만, 검증 시간이 그 이상으로 늘어난 것입니다.

검증의 심리적 함정

더 교묘한 문제가 있습니다. AI가 생성한 코드에 대한 신뢰 편향입니다. “AI가 만들었으니까 대충 맞겠지”라는 무의식적 가정이 리뷰 품질을 떨어뜨립니다. 반대로, 과도하게 의심하면 AI를 쓴 의미가 없어집니다. 이 균형을 잡는 것 자체가 새로운 인지 부하입니다.

금융 시스템에서 이 문제는 특히 심각합니다. 1원이 틀려도 정산 오류로 이어지고, 정산 오류는 규제 리포팅으로 번지며, 규제 리포팅 지연은 과태료로 귀결됩니다. AI가 99.7% 정확하다 한들, 나머지 0.3%가 재앙이 될 수 있는 도메인에서는 검증 비용을 줄일 수 없습니다.

바빠진 이유 #2: 기대치 인플레이션

AI 도입 전에는 “이 기능은 3스프린트 걸립니다”라고 말하면 대부분 수긍했습니다. 하지만 AI 도입 후, 경영진의 기대치가 급격히 높아졌습니다.

“AI 쓰면 반으로 줄어드는 거 아닌가요?”

이 한 마디가 모든 일정 산정을 무너뜨렸습니다. 실제로 AI 보조 덕분에 초기 프로토타이핑은 빨라졌습니다. 하지만 소프트웨어 개발의 본질적 복잡도 — 요구사항 분석, 아키텍처 설계, 통합 테스트, 운영 안정화 — 이것들은 AI가 대신해줄 수 없는 영역입니다.

결과적으로 벌어진 일:

• 일정이 절반으로 줄어든 건 아닌데, 기대는 절반의 일정으로 고정됨
• 부족한 시간을 야근으로 메움
• 품질 하락 → 장애 증가 → 장애 대응에 추가 시간 소모
• 악순환 형성

이건 기술의 문제가 아닙니다. 기술 도입에 따른 조직의 기대치 관리 실패입니다. AI는 도구일 뿐인데, 마법처럼 인식되는 순간 현장 엔지니어에게 그 괴리의 무게가 전가됩니다.

바빠진 이유 #3: 새로운 종류의 장애

챗봇을 8년간 운영하면서 깨달은 것이 있습니다. AI 시스템의 장애는 전통적 시스템 장애와 질적으로 다릅니다.

전통적 시스템 장애는 대부분 결정론적입니다. 같은 입력에 같은 오류가 반복됩니다. 로그를 추적하면 원인을 특정할 수 있습니다. 하지만 AI 기반 시스템의 오류는 확률적입니다.

• 어제는 정상 응답했던 동일한 쿼리가 오늘은 환각(hallucination) 응답을 내놓습니다
• 프롬프트를 쉼표 하나 바꿨을 뿐인데 출력 품질이 급락합니다
• 모델 업데이트 후 기존에 잘 작동하던 파이프라인이 미묘하게 틀어집니다

이런 장애를 디버깅하려면 전통적인 로그 분석과는 완전히 다른 접근이 필요합니다. 입력-출력 쌍을 수집하고, 통계적으로 패턴을 분석하고, 프롬프트를 실험적으로 조정해야 합니다. 이건 기존 개발자들이 훈련받지 않은 영역이고, 배우는 데 시간이 걸립니다.

모니터링의 복잡도 증가

전통적 모니터링은 비교적 단순합니다. CPU 사용률, 메모리, 응답 시간, 에러율. 이 지표들이 임계치를 넘으면 알림을 보냅니다.

하지만 AI 시스템은 여기에 추가로:

• 응답 품질 모니터링: 수치적으로 정상이어도 내용이 부정확할 수 있음
• 드리프트 감지: 시간이 지나면서 모델 성능이 서서히 저하되는 현상
• 비용 모니터링: API 호출 비용이 예측 불가능하게 변동
• 윤리적 모니터링: 부적절한 응답이 사용자에게 전달되지 않는지 확인

모니터링 대시보드가 2배로 늘었고, 그걸 해석하는 인력도 필요해졌습니다.

바빠진 이유 #4: 프롬프트 엔지니어링이라는 새 업무

1년 전만 해도 우리 팀에 ‘프롬프트 엔지니어링’이라는 업무는 존재하지 않았습니다. 지금은 팀원의 업무 시간 중 무시할 수 없는 비중을 차지합니다.

단순히 프롬프트를 작성하는 것으로 끝나지 않습니다:

• 프롬프트 버전 관리: 어떤 프롬프트가 어떤 결과를 냈는지 이력 추적
• 프롬프트 테스트: 엣지 케이스에서의 동작 검증
• 프롬프트 최적화: 비용과 품질의 균형점 탐색
• 프롬프트 문서화: 왜 이 프롬프트가 이렇게 설계됐는지 기록

아이러니하게도, 이 모든 것이 “코드를 덜 쓰기 위해” 도입한 도구 때문에 생긴 추가 업무입니다. 코드를 덜 쓰는 대신, 자연어를 더 정밀하게 쓰게 된 것뿐입니다. 복잡도는 사라지지 않고 형태만 바뀌었습니다.

바빠진 이유 #5: 학습과 적응의 끝없는 러닝머신

20년간 기술 변화를 수없이 겪었습니다. Java 버전 업그레이드, 마이크로서비스 전환, 클라우드 이전. 하지만 이번엔 체감 속도가 다릅니다.

AI 도구와 모델은 분기 단위로 세대 교체됩니다. 3개월 전에 학습한 베스트 프랙티스가 이미 구식이 됩니다. 새 모델이 나오면 기존 프롬프트를 재검증해야 하고, 새 기능이 추가되면 워크플로우를 재설계해야 합니다.

이게 단순히 ‘새 프레임워크 배우기’와 다른 점은, 안정적인 정착점이 보이지 않는다는 것입니다. Spring Framework를 배우면 최소 3~5년은 그 지식이 유효합니다. 하지만 현재의 AI 도구 체계에서는 6개월 전 지식의 유효기간을 보장할 수 없습니다.

팀원들이 느끼는 피로감은 기술적인 것만이 아닙니다. “내가 지금 배우고 있는 것이 3개월 후에도 의미가 있을까?”라는 불확실성에서 오는 심리적 소모가 큽니다.

그래서 AI 도입은 실패인가?

여기까지 읽으면 “AI 도입은 실패였다”라는 결론처럼 보일 수 있습니다. 하지만 그건 아닙니다. 실패한 것은 AI가 아니라 우리의 기대와 전략이었습니다.

AI 도입 1년 후의 솔직한 성적표:

• 프로토타이핑 속도: 확실히 빨라짐 (체감 2~3배)
• 반복적 문서 작업: 확실히 줄어듦
• 코드 초안 작성: 빨라짐, 단 검증 비용 증가
• 총 업무 시간: 줄어들지 않음, 오히려 소폭 증가
• 업무 만족도: 양극화 (단순 반복 감소로 올라간 사람 vs. 불확실성 증가로 내려간 사람)

핵심 교훈은 이것입니다: AI는 일을 대신 해주는 것이 아니라, 일의 구조를 바꾸는 것입니다. 준비 없이 도입하면 구조 변환 비용이 생산성 향상분을 초과합니다.

1년간의 시행착오에서 배운 것

교훈 1: 자동화할 것과 하지 말 것의 경계를 먼저 정의하라

우리 팀의 실수는 “가능한 모든 곳에 AI를 적용하자”는 접근이었습니다. 이후 깨달은 원칙:

• 자동화 적합: 실패해도 복구 비용이 낮은 업무 (초안 작성, 아이디어 브레인스토밍, 테스트 데이터 생성)
• 자동화 부적합: 실패 시 복구 비용이 높은 업무 (프로덕션 배포 로직, 금융 정산, 보안 정책)

이 경계를 명확히 한 후에야 AI 도입의 효과가 제대로 나타나기 시작했습니다.

교훈 2: AI 도입은 업무 재설계와 함께 가야 한다

기존 프로세스 위에 AI를 얹으면, 기존 프로세스의 비효율까지 증폭됩니다. AI를 도입하려면 먼저:

• 현재 워크플로우를 분해하고
• 각 단계에서 사람과 AI의 역할을 재정의하고
• 새로운 검증 체크포인트를 설계하고
• 기대치를 현실적으로 설정해야 합니다

이건 기술 도입이 아니라 조직 변화 관리(Change Management)의 영역입니다. 그리고 대부분의 기술 조직은 이 부분에 취약합니다.

교훈 3: ‘사람이 하는 일’을 재정의해야 한다

가장 중요한 깨달음입니다. AI 도입 후 사람의 역할은 “실행자”에서 “감독자·설계자·판단자”로 이동합니다. 이건 단순한 직무 변경이 아니라, 근본적으로 다른 역량 체계를 요구합니다.

코드를 직접 쓰는 것과, AI가 쓴 코드를 검증·승인하는 것은 같은 기술 스택을 쓰지만 완전히 다른 인지 과정입니다. 후자가 더 어렵다고 감히 말하겠습니다.

이 시리즈에서 다룰 것들

앞으로 11화에 걸쳐, 이 “바빠진 현실”을 어떻게 다루고 있는지 구체적으로 풀어가겠습니다:

• AI의 출력을 효과적으로 검증하는 체크리스트 (2화)
• 챗봇 8년 운영에서 배운 AI 장애 대응 노하우 (3화)
• 프롬프트 엔지니어링을 넘어선 시스템 설계 (4화)
• AI와 사람의 역할 분배 프레임워크 (5화)
• 금융IT에서의 AI 안전 가드레일 설계 (6화)
• AI 시대의 코드 리뷰 문화 (7화)
• 주니어 개발자의 성장 경로 재설계 (8화)
• 비개발 직군과의 AI 협업 인터페이스 (9화)
• AI 피로감 관리와 지속가능한 학습 전략 (10화)
• 5년 후를 대비하는 커리어 설계 (11화)
• 시리즈 총정리: 사람만 할 수 있는 일의 본질 (12화)

매 화마다 이론이 아닌 현장의 경험, 숫자, 그리고 실패담을 중심으로 이야기하겠습니다.

마무리하며

AI가 우리의 일을 대체할 것이라는 공포, 혹은 모든 문제를 해결할 것이라는 환상. 둘 다 현실과 거리가 있습니다. 현실은 훨씬 더 복잡하고, 그래서 더 흥미롭습니다.

20년간 기술의 파도를 타며 배운 것이 하나 있다면, 새로운 기술은 문제를 해결하는 만큼 새로운 문제를 만든다는 것입니다. 중요한 건 그 새로운 문제를 얼마나 빨리 인식하고, 얼마나 솔직하게 마주하느냐입니다.

다음 화에서는 “AI가 생성한 코드를 어떻게 효과적으로 검증할 것인가”에 대한 구체적인 체크리스트와 팀 내 실험 결과를 공유하겠습니다.

📝 이번 주 한 줄 노트: AI는 일을 줄여주는 게 아니라 일의 종류를 바꾼다. 그 변화를 인식하는 것이 첫 번째 단계다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.