8장. 책임은 어디로 이동하는가?

규칙은 있었지만 실행되지 않았다.

결함을 안고 배포된 자동 검사 도구는 문서에 있다고 적은 규칙을 건너뛰었다. 규칙을 몰라서 생긴 오류와 알고도 적용 경로에 연결하지 못한 오류는 다르다. 이 사건이 보여 준 것은 규칙의 존재와 실행은 다른 문제라는 점이었다.

문서 작성, 검사 로직, 호출 경로, 테스트, 배포는 서로 다른 지점이다. 한 사람이 모두 맡았을 수도 있고 여러 사람이 나눴을 수도 있다. 남은 기록만으로 실제 역할 배분을 복원할 수는 없다. 어느 지점에서도 규칙과 실행의 연결을 확인하지 못한 채 결과가 배포됐다는 사실은 남는다.

이때 마지막 배포 버튼을 누른 사람만 찾으면 앞의 단절을 놓친다. 문서의 규칙을 실행에 연결할 권한, 누락된 호출을 검사할 의무, 결함을 발견했을 때 배포를 멈출 권한은 같은 자리에 있지 않을 수 있다. 책임의 위치를 찾으려면 직함보다 각 지점에서 무엇을 바꿀 수 있었는지를 봐야 한다.

자동화는 책임을 없애지 않았고 한 사람에게 그대로 남겨 두지도 않았다. 규칙을 정하는 일, 실행에 연결하는 일, 결과를 승인하고 관찰하는 일로 책임의 자리를 나눴다. 목표 설정, 예외 정책, 승인, 관찰, 정지 권한을 따로 보는 까닭은 이 연결이 어디서 끊겼는지 찾기 위해서다.

다섯 개의 책임 역할

목표 설정은 시스템이 무엇을 좋은 결과로 볼지 정하는 일이다. 전환, 오류 예방, 충분한 이해, 운영 단순성 가운데 무엇을 우선할지 선택한다. 목표가 여러 점수의 합이라면 항목과 가중치, 평정자 범위도 목표의 일부다.

예외 정책은 기본 규칙이 맞지 않을 때 다른 경로를 허용하는 일이다. 접근성 요구, 취약한 사용자, 법적 의무, 특수 데이터처럼 평균 규칙으로 처리하기 어려운 상황을 누가 발견하고 어떤 방식으로 우회할지 정한다. 예외가 없다는 결정도 하나의 정책이다.

승인은 특정 결과를 실행 상태로 넘기는 권한이다. 사람이 화면을 확인할 수도 있고, 점수가 임계값을 넘으면 자동 배포할 수도 있다. 클릭의 존재보다 어떤 조건에서 승인으로 간주되고 누가 그 조건을 바꿀 수 있는지를 본다.

관찰은 실행 뒤 결과를 받아보는 의무다. 성과 지표만 볼지, 오류와 불만, 집단별 손실, 예상하지 못한 사용을 함께 볼지 정한다. 관찰 자료가 있어도 목표나 예외를 바꿀 권한과 연결되지 않으면 시스템은 같은 선택을 반복한다.

정지 권한은 자동화를 멈추고 이전 규칙이나 수동 흐름으로 돌아갈 수 있는 권한이다. 중대한 오류가 발생해도 정지 주체가 없거나 호출 방법을 모르면 승인자가 많아도 책임 구조는 닫히지 않는다. 정지 조건, 연락 경로, 복구 상태를 함께 적어야 한다.

다섯 역할은 다섯 사람이 맡아야 한다는 뜻이 아니다. 한 사람이 모두 맡을 수도 있고 여러 팀과 시스템이 나눌 수도 있다. 필요한 것은 역할 사이의 연결이다. 목표를 정한 쪽이 결과를 받지 못하거나, 관찰자가 정지를 요청할 수 없으면 책임의 사슬이 끊긴다.

세 가지 작업 흐름

수동 제작에서는 사람이 후보를 만들고 검토하며 최종안을 배포한다. 목표는 제품 계획과 리뷰에서 정해지고, 예외는 제작자와 전문 검토자가 처리하며, 승인은 책임자가 내릴 수 있다. 관찰과 정지 권한은 배포 이후 운영 체계에 남는다.

수동 흐름이 책임을 자동으로 보장하지는 않는다. 목표가 회의마다 바뀌고 승인자가 손실을 모르며 관찰 결과가 제작팀으로 돌아오지 않을 수 있다. 사람이 모든 파일을 직접 만들었다는 사실은 다섯 역할의 연결을 증명하지 않는다.

다른 하나는 생성 자동화다. 요구와 참고 자료를 넣으면 도구가 여러 후보를 만든다. 제작 동작은 줄지만 목표 설정은 프롬프트, 시스템 지시, 참고 사례, 후보 선택 기준으로 분산될 수 있다. 어떤 값이 기본값이고 누가 수정했는지 기록하지 않으면 결과의 출처가 흐려진다.

이 흐름에서 승인은 여전히 사람이 할 수도 있고 규칙이 할 수도 있다. 접근성 하한을 통과한 후보만 보여 주고 책임자가 하나를 택할 수 있다. 예외 정책은 생성 규칙 밖의 후보를 허용할지, 금지된 결과를 어떻게 다룰지, 실패했을 때 수동 제작으로 돌아갈지에 들어간다.

또 하나는 생성과 평가 자동화다. 시스템이 후보를 만들고 점수나 규칙으로 걸러 하나를 선택한다. 사람은 모든 후보를 보지 않을 수 있고 임계값을 넘은 결과가 바로 실행될 수도 있다. 이때 평가기는 결정을 없애기보다 선택된 목표를 반복 실행한다.

평가 자동화에는 선행 선택이 들어간다. 무엇을 점수화할지, 어느 평정자 모집단을 대표로 삼을지, 어떤 가중치와 임계값을 쓸지 정해야 한다. 안정된 목표와 동질적인 평정 범위에서는 여러 합리적 방법이 같은 결과를 낼 수 있지만, 그것이 선행 선택의 존재를 없애지는 않는다.

도식에서 오른쪽으로 갈수록 책임이 줄어드는 것은 아니다. 실행 동작은 자동화되지만 목표와 예외를 정하는 일이 앞단으로 이동할 수 있고, 관찰과 정지의 중요성은 커질 수 있다. 반대로 목표 선택과 책임 추적까지 안정된 시스템이라면 추가 판단이 남지 않을 수도 있다.

평가기가 들어온 작업대

생성 도구가 주목받을 때 작업대의 중심은 후보 생산량에 놓인다. 얼마나 빨리 몇 개를 만들 수 있는지가 변화의 표식이 된다. 평가기가 들어오면 무엇을 남기고 버릴지, 어떤 오류를 감수할지, 누가 임계값을 바꿀지를 다루게 된다.

이미지가 강조하는 것은 평가의 우월성이 아니다. 후보를 많이 만드는 능력만으로는 어떤 결과를 실행할지 정해지지 않는다는 전환이다. 평가가 자동화돼도 목표와 예외, 정지 조건이 안정적인지 확인해야 한다.

책임이 흐려지는 네 순간

하나는, 기본값이 결정으로 읽힐 때다. 모델이나 평가 도구의 초기 설정이 그대로 쓰이면 아무도 값을 선택하지 않은 것처럼 보인다. 기본값을 채택하고 검토하지 않은 결정이 있었다. 누가 기본값의 범위를 확인하고 업데이트를 승인하는지 남겨야 한다.

다른 하나, 승인 버튼이 책임 전체를 덮을 때다. 검토자가 수백 결과를 짧게 확인하고 승인했다면 실제로 목표나 예외를 바꿀 수 있었는지 물어야 한다. 변경 권한 없이 결과만 확인한 사람에게 모든 책임을 모으면 앞단의 선택이 보이지 않는다.

또 하나, 지표 소유자와 손실 경험자가 다를 때다. 전체 전환이 좋아져도 특정 집단의 오류나 통제권 손실이 커질 수 있다. 관찰이 평균 지표만 받으면 예외 정책을 다시 열 신호가 사라진다. 집단별 손실을 언제 별도 경보로 볼지 정해야 한다.

마지막 하나, 중단이 기술 기능으로만 남을 때다. 정지 버튼이 있어도 누가 어떤 조건에서 눌러야 하는지 모르고, 누른 뒤 복구 상태가 준비되지 않았다면 권한은 형식적이다. 운영 훈련과 연락 경로, 되돌릴 버전이 함께 있어야 한다.

책임을 선명하게 만드는 일은 이름을 많이 적는 일이 아니다. 각 역할이 가진 입력, 결정, 변경 권한, 다음 역할로 넘기는 기록을 적는 일이다. 직함 목록만으로는 관찰이 정지로 이어지는지 확인할 수 없다.

자동화가 책임을 더 선명하게 하는 반례

자동화는 책임을 흐리기만 하지 않는다. 규칙 버전, 입력, 점수, 예외, 승인 시각을 일관되게 남기면 수동 회의보다 선택 출처를 더 잘 복원할 수 있다. 정지 조건이 코드와 운영 절차에 함께 고정돼 있으면 누구의 기억에 의존하는 수동 흐름보다 안정적일 수 있다.

목표가 좁고 오류 기준이 분명한 과업에서는 자동 승인이 책임 있는 선택이다. 필수 정보 누락, 대비 하한, 파일 규격처럼 판정 가능한 항목을 매번 사람이 확인할 필요는 없다. 목표, 예외, 관찰, 정지가 이미 연결돼 있다면 자동 실행은 책임의 공백이 아니다.

사람의 승인을 넣는 것이 오히려 책임을 흐릴 수도 있다. 실질적인 변경 권한이 없는 검토자가 형식적으로 확인하면 조직은 사람을 고리에 넣었다는 이유로 시스템 목표와 임계값의 책임을 피할 수 있다. 인간 검토의 존재보다 권한의 실질을 봐야 한다.

책임 이동은 자동화 수준 하나로 예측할 수 없다. 같은 평가 시스템도 목표 소유자와 중단 절차가 분명하면 추적 가능하고, 수동 제작도 승인과 관찰이 끊기면 불투명하다. 세 흐름은 가능한 구조를 비교한 것이지 자동화 효과를 측정한 결과가 아니다.

책임 지도를 만드는 법

먼저 다섯 역할마다 현재 위치를 한 줄로 적는다. 사람 이름보다 팀, 시스템, 문서, 규칙 버전을 쓴다. 승인: 제품 책임자에서 멈추지 않고 임계값을 넘은 결과를 배포하며 임계값 변경은 별도 승인처럼 권한 범위를 붙인다.

다음으로 역할 사이의 전달물을 적는다. 목표 설정은 평가 기준과 허용 손실을 넘기고, 예외 정책은 우회 조건을 넘기며, 승인은 실행 기록을 남긴다. 관찰은 목표와 손실에 대응하는 결과를 돌려주고, 정지는 중단 이유와 복구 상태를 남긴다.

자동화가 바뀔 때는 사라진 동작보다 이동한 권한을 본다. 사람이 후보를 만들지 않게 됐다면 생성 규칙을 누가 바꾸는지, 사람이 모든 결과를 보지 않게 됐다면 평가 목표와 표본 범위를 누가 승인하는지 묻는다. 인터페이스에서 버튼 하나가 사라져도 책임 역할은 다른 위치에 남을 수 있다.

예외가 실제로 처리되는지도 시험한다. 평균적인 입력만으로 흐름을 검토하면 예외 정책과 정지 권한이 빈칸이어도 드러나지 않는다. 의무 위반, 데이터 누락, 집단별 손실, 모델 변경 같은 상황을 넣고 누가 무엇을 받으며 어디서 멈추는지 확인한다.

책임 지도는 영구 조직도가 아니다. 모델, 평가 규칙, 제품 목표, 법적 의무가 바뀌면 다시 그린다. 버전과 변경 이유를 남겨야 나중에 어느 규칙 아래 결과가 나왔는지 복원할 수 있다.

책임의 연결

생성, 평가, 승인이 한 흐름에 있어도 필요한 권한은 서로 다르다. 후보를 늘리는 기능과 실행할 경로를 고르는 기능을 나누고, 프롬프트와 평가 규칙에 들어간 가치의 출처를 찾으면 책임의 위치도 구체적으로 표시할 수 있다.

이 흐름에서 디자이너의 역할을 마지막 심판으로 고정할 이유는 없다. 디자이너는 목표와 예외를 설계할 수도 있고, 평가 체계를 검토하거나 관찰 결과를 해석하고 정지 조건을 갱신할 수도 있다. 다른 전문 역할이나 안정된 시스템이 그 기능을 맡을 수도 있다.

누가 사람인지보다 어떤 선택이 있었고 누가 바꿀 수 있는지를 본다. 목표, 승인, 정지 조건이 연결돼 있고 관찰이 그 연결로 돌아오면 자동화된 흐름도 책임을 가질 수 있다. 연결이 없다면 수동 흐름도 책임 있는 선택이라고 부르기 어렵다.

결과가 다르다는 판단에도 좁은 기준이 필요하다. 낯섦 자체가 아니라 누구에게 어떤 결과가 달라지고 무엇을 잃는지를 말해야 책임 지도의 선택이 실제 경로와 이어진다.

이 지도가 설명하지 않는 것.

세 작업 흐름은 책임 역할의 가능한 위치와 연결 관계를 설명하는 구조도이며, 실제 조직의 자동화 효과를 측정한 결과가 아니다. 집계 목표와 평정 범위에 관한 해석도 특정 모델 응답 분포와 자극 범위를 넘어 일반화하지 않는다.