복잡한 자동화를 운영자가 판단 가능한 화면으로

왜 문제

운영 담당자가 이해하지 못하면, 자동화는 다시 병목이 된다.

자동화가 늘어도 운영자가 지금 무엇을 봐야 하는지 모르면, 결국 다시 사람에게 병목이 생깁니다. 자료는 쌓이는데 요약이 안 되고, 실행은 도는데 이상 여부를 알 수 없고, 판단은 내려졌지만 왜 그런 결론이 나왔는지 따라갈 수 없기 때문입니다.

그래서 제가 푼 문제는 "에이전트를 몇 개 더 붙이느냐"가 아니라 비개발자도 수집된 정보, 요약된 쟁점, 자동화 상태, 판단 근거, 다음 학습을 같은 흐름으로 이해하게 만드는 것이었습니다. 어려운 것은 쉽게 보이게 하고, 쉬워 보이는 결정은 근거까지 깊게 따라갈 수 있어야 했습니다.

구조 시스템 아키텍처

수집·요약·자동화·판단·학습을 한 흐름으로 묶고, 담당은 나눴다.

데이터는 단일 공유 데이터(SSOT)에 모으고, 운영 흐름은 수집 → 요약 → 자동화 → 판단 → 학습으로 읽히게 만들었습니다. 동시에 담당은 의미 단위로 나눴습니다. 자료를 모으는 일, 실행하는 일, 판단하는 일, 외부 요청을 받는 일이 뒤섞이지 않아야 운영 담당자가 어디서 고쳐야 할지 바로 찾을 수 있기 때문입니다.

핵심은 복잡한 내부 구조를 기술자용 다이어그램으로 끝내지 않는 것입니다. 각 배치는 "무엇을 모았는가", "무엇이 요약됐는가", "무엇을 자동으로 돌렸는가", "어떤 근거로 승인·반려했는가"를 남기고, 다음 담당자가 같은 기준으로 이어받을 수 있게 했습니다.

네 개의 독립 시스템 · 단일 공유 데이터(SSOT) · 만든 사람과 검사하는 사람 분리를 코드 경로로 강제.

판단근거 · 가정 · 리스크 분리

아이디어를 바로 실행하지 않고, 사실·가정·편향을 나눠 본 뒤 왜 이 결정을 해야 하는지를 남긴다. 통과한 것만 실행에 넘겨 자기 합리화를 줄인다.

실행자동화 · 배치 운영

반복 작업을 의미 단위 배치로 묶고, 상태와 이상 여부를 남긴다. 운영자는 전체 로그를 뒤지지 않고 봐야 할 묶음부터 확인한다.

요약업무 맥락 · 메모리 정리

흩어진 맥락을 다음 사람이 읽을 수 있는 형태로 정리한다. 민감한 개인 메모리는 공유 영역과 분리해, 필요한 정보만 운영 화면에 보이게 한다.

요청외부 입력 · 승인 게이트

외부 요청은 바로 실행하지 않고, 범위와 위험을 확인한 뒤 사람 승인으로 넘긴다. 요청이 들어오는 창구와 실행 담당을 나눠 안전하게 이어받는 구조를 만든다.

그리고 이 구조는 데모가 아니라 실가동 중입니다 — 4개 독립 시스템으로 돌며, 실전 분석 4건이 사실·가정·편향 교차검증을 통과했고 비서 테스트 19건이 통과했습니다(큐 연계는 전 과정(입력부터 끝까지) 검증 완료).

이 운영은 상시 자동화로 돕니다 — 자료수집·리뷰를 매일 처리하고, 러닝레이어에서 매일 학습을 승인/반려(승인율 ~70%)하며, 3개 모델 순차 폴백으로 단일 모델 병목·할당량 소진에도 작업이 끊기지 않게 했습니다. 중요한 건 자동화 자체가 아니라, 학습한 내용과 반려 이유가 남아서 다음에 무엇을 고치면 되는지 보이는 것입니다.

~39공유 데이터 테이블 (SSOT)

31상시 자동화 잡

16운영 콘솔 화면

상시 잡 31개의 역할별 분포 — (콘텐츠 자동화는 실행 허브에 연결된 별도 콘텐츠 OS가 담당)

실행 허브 ~22

판단 4

콘텐츠 자동화 ~5

비서 2

콘솔 16화면 운영 콘솔

운영 담당자가 쉽게 쓰고, 누구나 판단할 수 있도록 화면을 설계했다.

내부 시스템의 목표는 개발자가 설명해야만 쓸 수 있는 화면이 아니라, 운영 담당자가 직접 보고 판단할 수 있는 화면입니다. 그래서 16화면 운영 콘솔을 수집·요약·자동화·판단·학습 흐름에 맞춰 묶었습니다. 평가 포인트는 화면이 예쁜지가 아니라, 무엇을 해야 하는지, 왜 해야 하는지, 누가 이어받아야 하는지가 바로 보이는가입니다.

내 작업 화면의 실제 캡처 기반 공개용 이미지 — **내 작업** 후보와 자동화 로그를 분리하고, 오늘 사람이 열어야 할 배치만 남겨 판단 피로를 줄인다.

작업 후보 화면의 실제 캡처 기반 공개용 이미지 — **작업 후보** 아직 실행할 일이 아닌 요청을 후보로 보관하고, 합배치 전에 담당 영역과 다음 단계를 나눈다.

배치 상세 화면의 실제 캡처 기반 공개용 이미지 — **배치 상세** 현재 상태, 목표, 판단 근거, 완료 기준, 자동 실행 현황을 한 흐름에 묶어 의사결정하게 한다.

러닝 레이어 화면의 실제 캡처 기반 공개용 이미지 — **러닝 레이어** 승인·보류·반려와 그 이유를 남겨, 수집과 자동화가 다음 판단 기준을 학습하게 한다.

실제 운영 콘솔을 캡처한 뒤 개인명·내부 경로·작업 상세·식별값을 제거한 공개용 이미지입니다. 새로 그린 목업이 아니라, 판단 구조가 실제로 동작하는 화면을 기준으로 정리했습니다.

운영 흐름	콘솔 화면	의사결정에 필요한 것
수집·요약	작업 후보	흩어진 요청을 아직 실행 전 후보로 모아 영역과 담당 기준을 먼저 정리
자동화	자동화 상태	31잡·88로그를 빈도·샘플로 줄이고, 이상만 사람에게 보이게 함
판단	내 작업 · 배치 상세	우선순위·리스크·담당·완료 기준 + '검토 필요' 게이트로 읽기→결정 분리
학습·개선	러닝 레이어	승인·보류·반려 이유와 근거를 남겨, 다음 수집·자동화 기준으로 쌓이게 함

이 케이스의 핵심은 내부 시스템을 만들 때도 같은 원칙을 적용한다는 점이다. 어려운 것은 쉽게 — 운영 담당자가 바로 쓰는 UX로 만들고, 쉬운 것은 깊게 — 누구나 근거를 따라 판단할 수 있는 UX로 만든다.

결정 불변식

내가 만든 걸, 내가 채점하지 않도록 구조로 막았다.

좋은 시스템은 "그렇게 하기로 했다"가 아니라 "그렇게 될 수밖에 없다"로 증명됩니다. 운영자가 판단하기 쉬운 화면 위에, 자기검증·무단 실행·외부 입력 위험을 막는 네 가지 규칙을 구조로 고정했습니다.

① 만든 사람과 검사하는 사람을 분리 (구조로 강제 — 애초에 그렇게 만들어서)

운영자 본인의 평가값은 최종 판단 데이터에 구조적으로 들어가지 않습니다 — 자기채점 통로가 코드 경로상 아예 없습니다. 실제로 시스템이 자기 자신을 낮게 채점했을 때, 독립 검증기가 그 합리화 회로를 잡아낸 실증 사례를 확보했습니다.

② 검증 게이트를 산출물로 강제

"경고 후 그냥 진행"을 금지했습니다. 미검증 가정이 결론을 지탱하면 진행을 강제 중단합니다 — 통과는 선택이 아니라 산출물(아티팩트)로 남아야 다음 단계로 갑니다.

③ 결제 정보 미저장 · 긴급 중단 장치

결제 관련 개인정보는 시스템 어디에도 저장하지 않는 것을 불변식으로 못박고, 이상 동작 시 전체 자동화를 즉시 멈추는 긴급 중단 장치를 뒀습니다.

④ 외부 입력은 미신뢰 · 사람 승인 게이트

외부에서 쓰기가 가능한 공유 작업 큐의 지시문은 신뢰 불가 입력으로 취급합니다. 무인 자동 실행을 금지하고 사람 승인 게이트를 둔 뒤, 수상한 지시는 계약 문서로 명문화해 자동 거부합니다(전 과정(입력부터 끝까지) 검증 완료).

자격증명 요구범위 밖 권한 상승 시도자동 거부

범위 밖 접근계약 외 리소스 접근자동 거부

재귀 디스패치자기 증식 · 무한 호출자동 거부

정상 지시범위 내 · 검증 통과사람 승인 후 실행

정직 한계

이 케이스가 주장하지 않는 것

이 시스템의 사용자는 운영자 1인(저 자신)이고, 외부 사용자나 매출을 위한 제품이 아닙니다. 따라서 전환·리텐션·매출 같은 성과는 주장하지 않습니다. 보여드릴 수 있는 것은 화면의 미려함이 아니라, 복잡한 내부 운영을 누구나 이해하고 이어받을 수 있게 만든 정보 설계 역량 — 즉 B2B 사내 운영 도구에서 운영 상태·담당·승인·학습을 한 흐름으로 설계할 수 있다는 직접 증거입니다.

배움 러닝

이 작업에서 남은 것

멀티 에이전트의 핵심은 모델 성능이 아니라 운영자가 판단 가능한 구조였습니다 — 무엇을 수집했고, 어떻게 요약됐고, 어떤 자동화가 돌며, 왜 승인·반려됐는지를 이어서 볼 수 있게 만드는 것. 내부 도구의 가치는 화면 수가 아니라 학습과 수정이 쌓이는 정보 설계, 그리고 담당자가 쉽게 나뉘어도 같은 기준으로 일할 수 있게 만드는 제품 판단이었습니다.