AI 비서에게 일을 맡기자 규칙이 먼저 늘었습니다
노바폴드는 일정 정리 · 문서 초안 · 자료 조사를 AI 비서 여럿에게 나눠 맡깁니다. 문서와 코드를 직접 고치는 코딩 에이전트(사람 대신 파일을 열고 고치는 AI)도 함께 씁니다.
처음에는 지시문 한 장이면 충분했습니다. 일을 더 맡길수록 지시문이 길어지더니 얼마 지나지 않아 그것만으로는 모자랐습니다. 어느 계정으로 일하는지, 어느 폴더에 파일을 두는지, 초안을 언제 보여 주고 언제 멈추는지 같은 규칙이 붙었습니다. 외부 서비스에 접근하는 연결, 반복하는 일을 묶은 절차, 되돌리기 어려운 일을 막는 권한도 함께 필요해졌습니다.
이 묶음을 하네스(harness)라고 부릅니다. 말에게 채우는 마구에서 온 이름으로, 힘을 쓰는 쪽은 모델이고 그 힘이 어디로 가는지는 하네스가 정합니다. 직접 써 보니 일의 성패는 모델보다 하네스 쪽에서 더 자주 판가름 났습니다.
하네스는 쌓는 일보다 깎는 일이 많습니다
규칙은 대개 사고에서 생깁니다. AI가 같은 실수를 두 번 하면 바로 한 줄을 더합니다. 그런데 더하기만 하면 하네스는 금방 무거워집니다. 규칙끼리 부딪히고 옛 규칙이 새 결정을 덮으면서 AI는 어느 쪽을 따라야 할지 모르게 됩니다.
그래서 노바폴드는 규칙을 더하는 만큼 덜어 내는 데도 공을 들입니다. 지금 지키는 방식은 넷이며 대부분 코딩 에이전트의 규칙에서 나왔습니다.
첫째, 규칙마다 날짜와 계기를 남깁니다. 「시간 낭비하는 해법을 제안하지 않는다」는 규칙 옆에는 그 규칙이 생긴 날과 그날 있었던 일이 함께 적혀 있습니다. 9월 중순부터 11월 초까지 작업 중 지적을 받아 생긴 규칙은 48건이고, 모두 날짜와 이유를 달고 있습니다.
계기가 적힌 규칙은 나중에 지울지 판단할 수 있습니다. 그 상황이 더는 생기지 않는다면 규칙도 내려놓으면 됩니다. 계기 없이 남은 규칙은 아무도 지우지 못하고 쌓이기만 합니다.
둘째, 같은 내용은 한 곳에만 둡니다. AI 도구가 여럿이면 같은 규칙이 여러 문서에 복제되기 쉽습니다. 노바폴드는 어떤 요청에 어떤 절차를 쓸지 적은 라우팅 표를 하나만 두고, 규칙을 바꾸면 그 표와 각 도구의 지시문을 함께 고칩니다.
「무엇이 현행 문서인가」가 헷갈릴 만한 주제는 등기부(주제마다 정본 파일 하나의 위치만 적은 목록)에 올리고, 매일 아침 검사 프로그램이 등기부와 실제 파일을 대조합니다. 파일이 사라졌는지, 같은 주제의 정본이 둘인지, 검토 기한이 지났는지만 보는 단순한 검사입니다.
규칙끼리 어긋날 때 무엇이 이기는지도 미리 적어 둡니다. 예를 들어 화면 설계와 옛 정책 문서가 다르면 화면이 이긴다는 식입니다. 이 한 줄이 없으면 AI는 옛 문서를 근거로 확정된 화면을 되돌리려 합니다. 실제로 그런 일을 겪은 뒤에 붙은 규칙입니다.
셋째, 기계로 확인할 수 있는 규칙은 검사로 옮깁니다. 「버튼을 화면마다 새로 그리지 않는다」 같은 규칙은 지시문에 적어 두어도 바쁠 때 어겨집니다. 그래서 금지 패턴을 찾아내는 검사 프로그램을 따로 두고 화면을 고치기 전과 고친 뒤에 돌려, 지적이 0건일 때만 작업을 확정합니다. 검사로 옮긴 규칙은 지시문에서 지울 수 있습니다. 그만큼 지시문이 짧아지고 사람이 점검할 분량도 줄어듭니다.
넷째, 안 쓰는 연결을 걷어 냅니다. 연결해 둔 외부 서비스와 설정이 실제로 쓰이는지 주기적으로 대조하고, 더는 쓰지 않는 것은 지웁니다. AI가 접근할 수 있는 범위가 좁을수록 사고가 났을 때 피해도 좁습니다.
회사에 옮기면 누가 깎느냐부터 걸립니다
이 방식은 규칙의 주인이 분명한 환경에서 나왔습니다. 규칙을 더하는 사람과 지우는 사람이 같았기에 돌아갔습니다. 회사로 옮기면 이 전제가 먼저 무너집니다.
가상의 예로, 한 영업팀이 공용 AI 도우미를 만들어 지시문을 함께 고쳐 쓴다고 해 봅시다. 처음 한 쪽이던 지시문이 석 달 뒤에는 세 쪽이 됩니다. 팀장은 「견적 금액은 반올림하지 말 것」을, 신입은 「답변은 짧게」를, 다른 담당자는 「고객사 이름은 정식 명칭으로」를 더합니다. 하나하나는 옳지만 아무도 지우지 않습니다. 어느 날 도우미가 엉뚱한 답을 내도 어느 줄이 원인인지 찾을 사람이 없습니다.
노바폴드는 사내 AI 도구를 도입하는 조직에 모델 선택보다 먼저 정할 것이 셋 있다고 봅니다. 하네스의 주인이 누구인지, 규칙을 더할 때 계기를 어디에 남기는지, 얼마나 자주 덜어 낼지입니다. 주인이 없는 지시문은 여러 사람의 메모장이 되고 덜어 내는 주기가 없으면 규칙이 서로를 덮습니다.
권한도 마찬가지입니다. 처음에 넓게 열어 두면 나중에 좁히기 어려우니, 필요할 때마다 하나씩 여는 편이 관리하기 쉽습니다. 고친 기록은 보안 · 감사 담당자도 볼 수 있는 곳에 둡니다. AI 도구의 지시문도 결국 회사의 업무 규정입니다.
앞의 영업팀이라면 시작은 작아도 됩니다. 지시문 맨 아래에 고친 날짜 · 고친 사람 · 고친 이유를 한 줄씩 남기게 합니다. 그리고 한 달에 한 번 담당자 한 명이 지시문 전체를 읽으며 계기가 사라진 줄을 지웁니다. 「반올림하지 말 것」처럼 숫자로 확인할 수 있는 규칙은 견적서 양식의 검산 칸으로 옮기고 지시문에서 뺍니다. 이렇게 돌리면 지시문이 다시 짧아지고 남은 줄마다 왜 있는지 설명할 수 있습니다.
AI 도구를 키우는 일은 규칙을 덜어 내는 일에 가깝습니다
AI 도구를 운영하면서 배운 것이 있습니다. AI는 규칙을 많이 받는다고 나아지지 않습니다. 적은 규칙을 정확하게 지킬 때 가장 잘 일합니다. 그래서 하네스를 다루는 일은 보태는 기술보다 고르는 판단에 무게가 실립니다. 남길 것과 지울 것을 가르는 기준이 곧 그 조직이 일하는 방식이기 때문입니다.
모델은 몇 달마다 좋아지지만 하네스는 저절로 좋아지지 않습니다. 주기적으로 깎지 않으면 새 모델이 들어와도 낡은 규칙 위에서 일하게 됩니다. AI 도구를 들인 지 반년이 지났다면 그 도구의 지시문을 처음부터 끝까지 한 번 읽어 보시길 권합니다. 지금 지울 수 있는 줄이 몇 개인지 세어 보면 그 도구가 어떻게 관리되어 왔는지 보입니다.