9월 19일 토요일

긴 AI 작업을 맡길 때 조직의 검증과 책임 범위는 어떻게 달라지는가?

짧고 잘 정리된 티켓에서는 여러 모델이 모두 기준을 넘을 수 있다. 차이는 문제가 적힌 화면에서 출발해 원인을 찾고, 수정하고, 테스트하고, 작동 장면을 남기고, 변경 제안과 검토 대응까지 이어지는 긴 작업에서 드러난다. 단계가 늘어날수록 한 번의 잘못된 선택이 전체 결과를 무너뜨릴 가능성이 누적되기 때문이다. 그래서 모델을 고르는 질문도 ‘가장 어려운 문제를 풀었는가’에서 ‘사람의 추가 지시 없이 얼마나 오래 맥락을 유지했는가’, ‘사람이 다시 개입할 때 이미 쓸 수 있는 결과인가’로 바뀐다. 이는 단순한 도구 비교가 아니라 업무 설계의 변화다. 사람이 매 단계마다 일을 쪼개고 감시하는 대신, 시작점과 종료점 사이를 넓게 맡기되 검증 가능한 결과물을 요구해야 한다.

1. 01

   평균 성능보다 실패가 누적되는 바닥을 본다

   원문은 10분마다 실패할 확률이 5%인 작업을 예로 든다. 한 번의 10분 창에서는 성공률이 95%지만, 같은 위험이 이어지면 4시간 성공률은 약 29%까지 낮아진다. 단위 실패율을 3%로 낮추면 같은 4시간 성공률이 약 48%로 오른다. 짧은 시험에서 비슷해 보인 모델도 긴 실행에서는 차이가 커진다는 뜻이다. 조직은 한 번의 인상적인 성공보다 반복 실행 기록에서 중앙 실행 시간, 긴 작업 구간, 중단 원인을 함께 봐야 한다.

2. 02

   업무를 어렵게 하기보다 시작점과 종료점을 넓힌다

   넓은 위임은 난도를 무작정 높이는 일이 아니다. 사람이 파일명과 수정 위치를 미리 정해 주는 대신 문제의 증상과 원하는 결과를 설명하고, AI가 조사와 변경 범위를 찾게 하는 방식이다. 수정 뒤에도 사람에게 빌드와 테스트를 넘기지 않고, 시뮬레이터 실행과 작동 영상, 변경 제안, 검토에서 생긴 문제의 해결까지 연결한다. 이렇게 해야 사람이 하던 준비와 전달, 중간 확인이 실제로 줄었는지 판단할 수 있다.

3. 03

   승인 표시보다 실행 증거를 받는다

   코드는 읽는 것만으로 모든 고장을 드러내지 않는다. 원문이 제시한 리뷰 방식은 변경을 내려받아 실제로 실행하고, 필요한 가설마다 격리된 실행 환경에서 시험한 뒤 이미지나 영상으로 결과를 돌려주는 것이다. 드롭다운이 올바르게 닫히는 장면이나 가입 흐름이 처음부터 끝까지 작동하는 영상은 단순한 승인보다 판단 근거가 많다. 위임 범위가 넓어질수록 사람의 최종 책임은 사라지는 것이 아니라, 무엇을 증거로 완료를 받아들일지 정하는 쪽으로 이동한다.

4. 04

   반복 실패는 프롬프트가 아니라 작업 환경의 문제일 수 있다

   긴 실행은 실패를 숨기는 방법이 아니라 반복 장애물을 빨리 발견하는 방법이기도 하다. AI가 같은 지점에서 계속 막힌다면 지시를 더 길게 붙이는 것만으로는 충분하지 않다. 원문은 새로 합류한 숙련 개발자도 같은 코드베이스와 시스템에서 비슷한 어려움을 겪을 수 있다고 지적한다. 실행 기록에서 잘못된 방향을 만든 도구와 파일, 구조를 찾아 작업 환경을 고쳐야 이후의 한두 시간짜리 일도 안정된다. 모델 비용만 볼 것이 아니라 사람이 준비하고 감시하고 재확인하는 시간까지 함께 계산해야 한다.

도입의 핵심은 사람을 검증 과정에서 빼는 데 있지 않다. 과거에 실패했던 작업을 다시 맡겨 신뢰 가능한 범위를 확인하고, 사람 없이 이어진 시간과 사람이 돌아왔을 때 결과가 작동할 확률을 함께 기록해야 한다. 그 위에서 문제 설명부터 실행 증거와 검토 대응까지 한 덩어리로 위임할 수 있다. 실패가 반복되면 모델만 탓하기보다 코드베이스와 개발 절차의 장애물을 고치는 것까지 운영 책임에 포함해야 한다. 더 긴 자율 실행은 더 느슨한 관리가 아니라, 완료 기준과 증거, 개입 시점을 더 구체적으로 설계하는 일이다.