조직도에 AI 직원 8명을 넣어봤습니다
상상으로 그린 조직도는 실제 자금 흐름을 보고 다시 짰습니다
며칠에 걸쳐 소규모 법인 몇 곳의 업무를 역할별 AI 담당자로 쪼개 굴려봤습니다. 손에 남은 결과는 처음 그린 조직도가 아니라, 실제 자금 흐름을 하나하나 들여다보고 나서 다시 짠 구조였습니다. 조직도를 그리는 일과, 그 조직도가 실제로 일을 하게 만드는 일은 완전히 다른 작업이었습니다. 정리하면 이렇습니다.
- 역할을 나누는 기준은 부서 이름이 아니라 접근 가능한 자료였습니다. 자료가 끊긴 담당자는 아무것도 못 합니다.
- 표준 조직도를 얹는 방식은 실패했습니다. 최근 3개월 출금과 이체 내역을 법인별로 훑고 나서야 비로소 부서가 정해졌습니다.
- 실제로 굴러간 것은 조회, 대조, 초안 작성까지였습니다. 발송과 이체는 전부 막혀 있습니다. 앞으로도 열 생각이 없습니다.
- 하루치 작업으로 5시간 사용 한도의 90%를 썼습니다. 기능이 아니라 화면을 고치고 새로고침하고 눈으로 확인하는 순환을 반복하는 데 대부분이 들어갔습니다.
처음에 만든 것은 그냥 조직도였습니다
시작은 단순했습니다. 법인 구조를 한눈에 보려고 만든 HTML 조직도 한 장이었습니다. 대표에서 본부로, 본부에서 법인으로, 법인에서 부서로 내려가고, 노드를 클릭하면 담당 업무 설명이 옆에 뜨는 형태였습니다. 잘 그려지긴 했습니다. 그런데 며칠 지켜보니 쓸모가 없었습니다. 파일 이름부터가 조직도였으니 당연한 결과였습니다.
정적 HTML 파일이었습니다. 입력칸을 만들어 무언가를 적어 넣어도 아무 일도 일어나지 않았습니다. 화면 안에서 업무를 지시하고 그 결과까지 같은 화면에서 받으려면, 뒤에 실제로 일을 하는 엔진이 붙어 있어야 합니다. 여기서 방향을 틀었습니다. 조직도는 보조 메뉴로 내려버리고, 맨 앞에는 업무 지시와 결과 확인이 함께 붙어 있는 화면을 새로 만들기로 했습니다.
담당자 한 명을 구성하는 항목
역할별 담당자를 나눌 때 실제로 정의해야 했던 항목은 담당 역할, 업무 지침, 접근 가능한 자료, 사용할 도구, 보고 형식, 실행 조건, 승인 범위, 업무 이력까지 모두 여덟 가지였고, 이걸 다 채우기 전까지는 어떤 담당자도 제대로 굴러가지 않았습니다. 하나라도 비면 끝입니다. 그 담당자는 자료 없이 그럴듯한 말만 늘어놓다가 아무 결과도 내놓지 못하고 끝났습니다.
특히 접근 가능한 자료가 핵심이었습니다. 자료가 연결되지 않았을 때는 원인을 확정하지 못한다는 답도 돌아왔습니다. “확인 가능한 자료만으로는 원인을 확정할 수 없습니다.” 실제로 첫 업무를 넣었을 때도 첨부한 캡처 한 장만 보고 이체내역이 필요하다는 답이 돌아왔습니다. 정상 동작으로 봤습니다. 없는 숫자를 지어내는 것보다는 이쪽이 훨씬 안전합니다.
담당자를 늘릴 때 각각 별도 엔진을 24시간 켜두는 구조도 검토했다가 접었습니다. 대신 하나의 엔진이 업무를 받은 다음에 그 담당자의 역할과 자료 접근 범위, 처리 절차를 그때그때 불러오는 방식으로 갔습니다. 비용이 적습니다. 서로 엉뚱한 일에 손댈 여지도 줄어듭니다.
표준 부서 구조를 얹으려다 폐기했습니다
중간에 “50인 규모 중소기업의 일반적인 부서 형태”를 그대로 반영해보기로 했습니다. 총무팀과 인사팀, 재무회계팀, 영업팀, 마케팅팀, 생산관리팀으로 이어지는, 어디서든 한 번쯤 본 적 있는 익숙한 구조입니다. 참고 자료로는 멀쩡했습니다. 그런데 실제 법인 위에 얹어보니 전혀 맞지 않았습니다.
이유는 세 가지였습니다. 대표 한 명이 여러 법인을 겸직하고 있었고, 총무와 인사와 재무는 법인별로 나뉘는 대신 이미 한곳에 통합돼 돌아가고 있었으며, 무엇보다 “생산 또는 운영 본부”에 해당하는 부분은 법인마다 업종 자체가 달랐습니다. 시공업, 매장 운영, 지주 성격의 관리 법인을 같은 틀에 밀어 넣으면 정리가 되는 게 아니라 오히려 부정확해집니다.
결국 부서는 이체내역을 보고 정했습니다
방향을 바꿔 최근 3개월 출금과 이체 내역을 법인별로 요약 조회했습니다. 여기가 가장 컸습니다.
거래 상대만 봐도 갈렸습니다. 한 법인은 프랜차이즈 본사에서 돈이 들어오고 시공 협력업체로 나갔습니다. 다른 한 법인은 서류상 별개인데도 거의 동일한 패턴이었고, 거래하는 협력업체까지 겹쳤습니다. 매장 법인은 거래 건수가 가장 많았는데 대부분 카드사 정산 입금이었고, 여기에 인력 파견업체로 나가는 출금이 함께 잡혔습니다. 관리 법인은 반대였습니다. 거래 건수가 가장 적었고, 식자재 유통과 방역, 노무 자문, 상표 관리 쪽 지출이 중심이었습니다.
여기까지 와서야 부서가 정해졌습니다. 시공 쪽은 현장관리와 자재정산, 매장 쪽은 매장운영과 카드매출 정산, 관리 법인은 계약과 브랜드 관리로 나눴습니다. 상상으로 그린 게 아닙니다. 돈이 오간 기록에서 역산한 셈입니다.
서류상 조직과 실제 조직이 어긋나는 지점
작업 중에 예상하지 못한 문제가 나왔습니다. 서류상 완전히 분리된 두 법인인데, 급여가 한쪽에서 나가는 사람들이 양쪽 현장에 구분 없이 투입되고 있었습니다. 서류대로 그리면 실제 자금 흐름과 맞지 않고, 나중에 인건비 귀속을 따질 때 근거도 함께 사라집니다.
그래서 두 법인을 상위에서 하나의 사업부로 묶어 보여주되 그 아래를 다시 두 갈래로 나누고, 화면 상단에는 안내 배너를 달았습니다. 부서 목록 맨 위에는 “확인” 배지가 붙은 공동 투입인력 항목을 넣었고, 그걸 클릭하면 인건비 귀속 기준이 필요하다는 것, 현장별 실제 투입 기록이 필요하다는 것, 두 법인 사이의 정산 방식을 정해야 한다는 것까지 세 줄이 뜹니다.
이 항목만큼은 처리 방안을 AI가 제안하지 못하도록 아예 막아뒀습니다. 세무 판단이 걸린 사안입니다. 화면에는 리스크 표시만 남기는 쪽이 맞다고 봤습니다.
두 번째 담당자를 붙인 이유
리스크 표시만으로는 정리가 되지 않았습니다. 그래서 인력배치를 맡는 담당자를 하나 더 만들었습니다. 하는 일은 하나입니다. 급여 자료와 이체 내역을 대조해서 근무일, 투입 현장, 급여를 지급한 법인, 귀속되어야 할 원가를 한 장의 표로 정리하는 것입니다.
지침에 못 박아 넣은 제한이 두 가지 있습니다. 확실하지 않은 귀속은 절대 단정하지 말고 “확인 필요”로 표시할 것, 그리고 최종 세무 처리 방식은 스스로 결정하지 말고 세무사와 상의하라고 안내할 것입니다. AI가 판단해서는 안 되는 영역을 지침 수준에서 못 박아두지 않으면, 자료가 부족한 상태에서도 그럴듯한 결론을 그냥 만들어 내놓습니다.
담당자를 둘로 늘리면서 서버 구조도 바꿨습니다. 담당자 등록부를 딕셔너리로 만들고 엔드포인트를 담당자 ID 기준으로 일반화해서, 새 담당자를 추가할 때 등록부에 항목 하나만 밀어 넣으면 나머지가 따라오도록 만들었습니다. 각 담당자는 독립된 세션과 독립된 대화 기록 파일을 갖습니다. 안 나눴으면 섞였을 겁니다.
인력 명단은 화면에 이름 버튼으로 넣었습니다. 눌러도 바로 실행되지 않고, 요청문이 입력창에 만들어지기만 합니다. 전달 버튼을 따로 눌러야 실행됩니다. 오조작 방지용입니다. 사무직 명단과 현장 지급 명단은 분리했습니다. 현장 명단에는 세금계산서 발행자와 사업소득자, 협력업체가 뒤섞여 있어서 이들을 직원으로 확정하지 않고 그대로 뒀습니다. 퇴사자는 취소선을 긋고 배정 대상에서 뺐습니다.
되지 않은 것들
승인 버튼을 눌러도 아무것도 발송되지 않았습니다
승인 팝업은 만들어놨습니다. 대상은 외부 이메일이나 메시지 전송, 회계장부 확정 또는 수정, 원본 파일 수정과 이동과 삭제, 신고와 제출, 그리고 결제와 이체입니다.
그런데 화면에서 승인을 눌렀을 때 실제로 무슨 일이 일어나는지 뜯어봤더니, 승인했다는 텍스트가 다시 전달되고 회신 문구가 한 번 더 정리돼 화면에 표시되는 게 전부였습니다. 메신저 전송 도구가 붙어 있지 않습니다. 발송은 여전히 사람이 복사해서 보내야 합니다.
더 나빴던 건 팝업 문구였습니다. 성격이 전혀 다른 두 작업, 그러니까 실제 지급 실행과 단순 회신 발송을 하나로 묶어놓고 한 번에 승인을 받고 있었습니다. 실행이 안 되니 사고는 나지 않았습니다. 다만 승인 한 번에 이체까지 되는 것처럼 읽히는 문구는 그 자체로 위험합니다. 팝업을 둘로 쪼개는 안도 검토했습니다. 다만 어차피 승인해도 실제로 보낼 수 없는 상태라 일단 그냥 두기로 했습니다. 자동 발송은 지금도 붙일 생각이 없습니다.
모델을 바꿨는데 바뀌지 않았습니다
사용 한도에 걸려 기본 모델을 바꿨더니, 이번엔 화면 쪽 응답이 이상하게 나왔습니다. 원인은 세션을 이어서 부를 때 이전 대화에 저장돼 있던 모델이 그대로 복원되는 것이었습니다. 설정만 바꾸고 이어붙이기를 쓰면 새 모델은 적용되지 않습니다. 그래서 매 요청마다 현재 설정된 기본 모델을 다시 확인한 다음, 실행 옵션에 명시해서 넘기도록 고쳤습니다.
상태 표시가 보이지 않은 것은 화면 문제가 아니었습니다
처리 중 상태를 넣었는데 화면에 뜨지 않는다는 얘기가 나왔습니다. 확인해보니 백엔드는 멀쩡했습니다. 질문을 이해하는 중, 자료 조사 중, 답변 작성 중, 답변 완료까지 네 단계가 전부 정상적으로 돌고 있었습니다.
보이지 않은 이유는 브라우저 쪽 폴링이 그 화면에서 직접 보낸 요청에만 반응하도록 돼 있었기 때문입니다. API로 대신 밀어 넣은 테스트 요청은 서버 상태값만 바꿀 뿐, 화면은 갱신되지 않습니다. 착시였습니다. 테스트 방식이 실제 사용 경로와 달라서 생긴 문제였습니다.
주소창이 file:// 이면 아무것도 되지 않습니다
한 번은 화면에 “서버에 연결할 수 없습니다”가 떴습니다. HTML 파일을 그냥 더블클릭해서 연 상태였습니다. 서버 주소로 열어야 할 화면이 파일로 열려 있었으니, 연결될 리가 없었습니다. 이후에는 파일을 직접 열어도 서버 주소로 자동 전환되도록 처리했습니다.
자료 조회 도구가 어디에 붙어 있는지 착각했습니다
은행 이체내역과 세금계산서를 조회할 수 있는 연결이 분명히 있는데도, 담당자는 조회를 하지 못했습니다. 확인해보니 그 연결은 코드 편집기 쪽에만 등록돼 있었고 정작 화면이 쓰는 엔진에는 빠져 있었습니다. 따로 등록하고 인증까지 거친 뒤에야 조회가 됐습니다. 인증 승인 화면은 사람이 직접 눌러야 합니다. 등록한 뒤에는 서버를 재시작해야 비로소 도구가 주입됩니다.
등록할 때 조회용 도구만 허용했습니다. 수정 계열은 전부 뺐습니다. 이런 구조에서는 읽기만 되는 상태를 기본값으로 잡는 게 맞다고 봤습니다.
화면 손보는 데 시간을 가장 많이 썼습니다
기능보다 레이아웃 조정에 훨씬 많은 시간이 들어갔습니다. 한 화면에 다 보이게 압축해달라고 했더니 지나치게 납작해져서 아래쪽에 빈 공백이 생겼고, 그걸 되돌렸더니 이번엔 화면이 너무 길어졌습니다. 결국 살짝 스크롤하면 아래가 보이는 중간 밀도로 확정했습니다. 접기 버튼 위치를 잘못 알아듣고 엉뚱한 패널에 달았다가 다시 옮긴 일도 있었습니다.
숫자로 남은 조정은 이렇습니다. 상단 카드 두 개의 가로 폭을 30% 늘리자 안에 들어가던 내용이 3줄에서 2줄로 줄었고, 그 덕에 카드 높이도 80px에서 62px로 내려갔습니다. 제목 글자는 36px에서 25px로 줄였습니다. 오른쪽 업무 패널은 페이지를 내려도 화면 상단 12px 위치에 그대로 고정돼 따라오게 했습니다. 이걸 만드는 과정에서 페이지 높이가 끝없이 늘어나는 문제가 한 번 나왔습니다. 반복 감시 방식이 원인이었고, 그 부분을 걷어내니 해결됐습니다.
이 작업 하루에 5시간 사용 한도의 90%를 썼습니다. 화면을 고치고 새로고침하고 실제 렌더링을 눈으로 확인하는 순환이 계속 반복됐고, 중간 리비전을 여러 번 되돌렸다가 다시 적용한 것이 특히 컸습니다. 구조가 잡힌 뒤로는 담당자나 부서를 추가하는 일이 틀에 항목 하나 넣는 작업이 됐습니다. 소모가 크지 않습니다.
되는 것과 안 되는 것의 경계
인스타그램에서 말하는 “AI 직원”이 과장이냐고 물으면, 절반은 과장이고 절반은 아니라고 답하겠습니다.
실제로 되는 것은 업무 내용을 받아 의미를 정리하고, 필요한 자료 목록을 스스로 판단하고, 연결된 폴더와 조회 도구를 뒤져 자료를 찾아 대조하고, 차이가 난 원인의 후보를 제시하고, 마지막으로 회신 초안을 만들어 놓는 데까지입니다. 이 범위 안에서는 확실히 사람 손을 덜어줍니다. 여기까지는 진짜입니다.
되지 않는 것은 실제 발송, 이체, 장부 확정, 신고입니다. 도구가 없어서 못 하는 것도 있고, 도구가 생겨도 열지 않을 것도 있습니다. 이 구분을 화면 문구에서부터 정확히 해두지 않으면, 승인 버튼 하나를 눌렀을 때 실제로 무슨 일이 벌어지는지 쓰는 사람이 통째로 오해하게 됩니다.
한 가지가 더 남았습니다. 조직도에 담당자를 심는 작업의 실제 산출물은 화면이 아니었습니다. 어떤 자료를 누가 볼 수 있는지, 그 접근 범위를 정리한 결과였습니다. 어떤 자료를 어느 담당자가 볼 수 있는지 정하려면, 애초에 그 자료가 회사 어디에 어떤 형태로 쌓여 있는지부터 알아야 합니다. 그 과정에서 서류상 조직과 실제 운영이 어긋나는 지점이 드러났습니다. 화면을 안 만들었으면 그냥 넘어갔을 대목입니다.
이어서 읽을 기록
