FDE에게 필요한 건 프롬프트가 아니라 해체하는 능력이다

 

에이전트를 만들다 보면, 프롬프트를 쓰는 시간보다 고객이 덩어리로 준 것들을 어디까지 쪼갤지 정하는 시간이 훨씬 깁니다. 그 쪼개기가 데리다가 말한 해체와 되게 닮아 있어서, deconstruction이라는 말을 빌려 정리해 봤습니다.

해체라는 말을 빌린 이유

 

데리다의 해체주의 얘기로 시작하겠습니다. 어떤 글이나 이론을 아주 꼼꼼히 읽어서, 그 글이 스스로 세운 규칙을 자기도 모르게 어기는 지점을 찾아내는 겁니다. 부수는 게 아니라, 이미 안에 있던 균열을 드러내는 거죠. 그리고 순서를 뒤집는 데서 멈추지 않습니다. 말이 글보다 앞선다는 위계를 뒤집어서 "글이 말보다 낫다"로 끝내면 그것도 또 다른 위계가 되니까, 둘로 나누는 틀 자체를 흔듭니다.[1]

 

판정 에이전트를 몇 번 만들고 나니 이게 남의 얘기가 아니더라고요. 고객이 준 규정을 꼼꼼히 읽어서 규정이 스스로 어기는 지점을 찾아내고, 새로 설계하는 게 아니라 이미 안에 있던 경계를 따라 뜯어내고, 모델에서 코드로 옮기는 데서 멈추지 않고 코드와 모델을 둘로 나누는 틀까지 흔드는 것. 판정 에이전트를 만들 때 하는 일이 정확히 이 세 동작이었습니다.

 

지난 글에서 FDE는 혼자 다 하는 사람이 아니라고 썼는데요, 이번엔 FDE 한 사람한테 무슨 능력이 필요한가 얘기입니다. 핵심 주장을 먼저 던지면 이겁니다. FDE에게 필요한 건 프롬프트를 잘 쓰는 능력이 아니라 고객이 덩어리로 준 것을 판정 가능한 단위까지 해체하는 능력이다. 공학에서는 decomposition이라고 부르지만 굳이 deconstruction이라고 쓰는 이유가 있어요. 처음부터 설계해서 나누는 게 아니라 이미 돌아가고 있던 덩어리를 뜯어서 다시 나누는 일이고, 뜯는 자리를 우리가 정하는 게 아니라 규정 안에 있던 균열이 정하거든요.

고객은 덩어리로 준다

고객은 항상 덩어리로 줍니다. 규정집 몇 권, 양식 몇십 장, 그리고 규정대로 검토해 주는 AI라는 한 문장. 담당자 입장에서는 그게 전부예요. 그분들 머릿속에서 규정은 나눠져 있지 않거든요. 몇 년 동안 손으로 검토하면서 몸에 밴 하나의 감각이죠. 그런데 에이전트는 그 감각을 그대로 못 받습니다. 규정을 항목으로, 항목을 판정 주체로, 입력을 건 단위로 쪼개서 넘겨줘야 돌아가요.

 

이 쪼개기를 누가 하느냐가 문제입니다. 도메인 담당자는 코드와 모델의 경계를 모르고, 개발팀은 규정을 모르죠. 둘 사이에 들어가 있는 사람이 FDE고, 그래서 이 일이 FDE한테 떨어집니다. 결국에는 무엇을 쪼갤지, 어디까지 쪼갤지, 어디서 멈출지를 정하는 게 프로젝트의 거의 전부더라고요.

프롬프트 하나로 시작하면 왜 안 되는가

첫 버전은 대개 되게 단순합니다. 기준 항목을 몇 개씩 묶어서 모델한테 던지고 자연어로 판정을 받는 구조죠. 결과가 그럴듯하게 나와요. 그런데 문제가 바로 그 그럴듯함입니다.

 

어떤 판정 작업이든 뜯어보면 상당 부분은 산술이고 룩업이고 패턴입니다. 비율이 한도 안인지는 숫자 두 개를 나누면 끝나죠. 코드나 번호가 맞는지는 표 하나 뒤지면 되고, 형식은 정규식 한 줄입니다. 규정 검증 같은 도메인에서는 이런 항목이 절반 가까이 되는데, 첫 버전에서는 이걸 전부 모델이 자연어로 판정하고 있어요. 같은 입력을 두 번 돌리면 문구가 달라지고, 가끔은 판정도 달라집니다. 확신에 찬 오답이죠.

 

한 덩어리라서 생기는 문제가 하나 더 있어요. 틀렸을 때 어디가 틀렸는지 모릅니다. 규정을 잘못 읽은 건지, 문서에서 값을 잘못 뽑은 건지, 비교를 잘못한 건지가 한 번의 호출 안에 섞여 있으니까요.

 

그런데도 처음에 아무도 안 쪼개는 이유가 있어요. 프롬프트 하나가 제일 빠르고, 데모가 제일 잘 나오거든요. 쪼개기는 항상 데모 다음에, 실제 문서 수백 건이 들어오고 나서 시작됩니다. 결국에는 여기서부터 쪼개기가 시작됩니다.

기준을 원자로

실제 기준을 통합하고 아이템화 하는 화면

 

가장 먼저 쪼갤 건 기준입니다. 규정이든 정책이든 체크리스트든, 원본 문서를 항목 하나하나로 나누고 번호를 붙여요. 번호가 곧 주소입니다. 이후 모든 룰, 모든 결과 카드, 모든 고객 피드백이 이 번호로 대화하게 되죠. 데리다식으로 말하면 꼼꼼히 읽기가 여기서 시작됩니다. 통째로 읽을 때는 안 보이던 것들이 항목 단위로 읽으면 보이거든요. 두 항목이 같은 말을 다르게 정의하고 있다든지, 한 항목이 다른 항목의 전제를 어기고 있다든지.

 

사소해 보이는데 되게 중요합니다. 주소가 없으면 고객이 준 의견을 코드의 어느 룰에 반영해야 하는지 매번 다시 찾아야 하거든요. 검수 의견이 항목 번호로 돌아오면 수백 건이라도 룰과 자동으로 대조할 수 있어요. 기준 문서가 둘 이상이라 충돌하는 항목이 있으면 더 엄격한 쪽을 택한다는 식의 규칙 하나를 고객과 먼저 정해 두는 게 좋아요. 결국에는 기준이 원자가 돼야 그 위의 모든 것들이 원자 단위로 움직이고, 고객과도 같은 번호로 말할 수 있습니다.

 

FDE 입장에서 이 단계는 표 하나를 만드는 일이에요. 항목 번호, 원문, 출처 페이지. 이 표가 이후 모든 작업의 원장이 됩니다. 뒤의 컬럼들은 다음 단계에서 하나씩 채워져요.

번호	항목 원문 (요약)	출처	레인	시점	판정 주체
R-12	인건비는 총사업비의 25% 이내	지침 p.14	추출 종속	사전, 사후	코드
R-37	사업번호는 연도-과제-항목 형식	지침 p.3	결정론	사전	코드
R-58	참여 대상은 XXX에 한함	지침 p.21	자격	사전	모델, 게이트 선행
R-104	용역 계약에는 견적서 2부 이상	매뉴얼 p.40	절차	사후	모델
R-131	지출 목적이 사업 취지에 부합	매뉴얼 p.9	의미	사후	모델
R-140	승인 경로는 예산 규모에 따름	지침 p.30	안내	사전	사람

누가 판정하는가를 가르기

다음엔 항목 하나하나에 누가 판정하는가를 붙입니다. 저희는 이걸 레인이라고 불러요. 항목의 성격을 뜯어보면 대개 다섯 갈래가 나옵니다.

결정론 레인은 산술, 룩업, 정규식으로 끝나는 것들입니다. 비율 한도, 코드 일치, 형식 패턴이 여기 들어가죠. 추출 종속 레인은 비교 자체는 코드지만 비교할 값을 문서에서 모델이 뽑아야 하는 것들이에요. 자격 레인은 사람이나 대상이 조건에 맞는지 보는 항목, 절차 레인은 필수 서류가 갖춰졌는지 보는 항목, 의미 레인은 목적에 맞는 지출인지 같은 판단이 필요한 항목입니다. 앞의 둘은 코드가 판정하고 뒤의 셋은 모델이 판정합니다.

 

이렇게 나누면 코드가 판정하는 항목이 절반 가까이 나오고 모델 호출은 수십 분의 일로 줄어요. 그런데 호출 수보다 중요한 건 재현성입니다. 코드 레인은 같은 입력에 항상 같은 답을 내니까, 판정이 흔들리면 그건 모델 레인이거나 추출 쪽 문제라는 게 바로 좁혀지죠.

 

레인 앞에는 게이트가 둘 있습니다. 이 문서 종류에 이 항목이 해당하는가, 그리고 이 문서의 조건에서 이 항목이 적용되는가. 해당없음이라는 판정을 처음부터 넣어 두지 않으면, 모델이 항목을 건너뛸 때마다 조건부나 미비로 떨어져서 오탐이 쌓입니다.

 

레인은 고정이 아니에요. 검수를 거치면서 옮겨 다닙니다. 절차 레인은 사전 단계에서 비고 사후로 몰리고, 판정하지 않고 사람한테 문구만 띄우는 안내 레인이 새로 생기기도 하죠. 결국에는 레인이라는 게 항목마다 코드, 모델, 사람 중 누구한테 보낼지 적어 둔 라우팅 표고, 그 표를 고객과 같이 고쳐 나가는 게 FDE의 일이더라고요. 앞에서 만든 원장에 레인 컬럼 하나를 더하는 거예요.

 

 

표로 놓으면 이렇습니다. 실무에서 제일 자주 보는 컬럼은 오른쪽 둘이에요.

레인	무엇을 보는가	판정 주체	같은 입력에 같은 답이 나오나	값을 못 얻으면
결정론	산술, 룩업, 형식	코드	항상	미비
추출 종속	비교는 코드, 비교할 값은 문서에서 추출	코드, 값은 모델	추출이 같으면	미비
자격	대상이 조건에 맞는가	모델, 게이트 선행	대체로	미비
절차	필수 서류가 있는가	모델, 파일명은 코드	대체로	미비
의미	목적과 취지에 맞는가	모델	흔들림	미비
안내	판정하지 않음, 조건 발생 시 문구만	사람	해당 없음	표시 안 함

추출과 판정을 가르기

그 다음이 추출과 판정의 분리입니다. 판정에 앞서 입력에서 값을 뽑아 구조화된 팩트시트로[2] 모아 두고, 룰은 그 팩트시트만 읽게 하는 거죠. 추출은 입력당 한 번, 판정은 룰마다 한 번. 이렇게 하면 모델은 값을 읽는 데만 쓰이고 비교는 코드가 합니다.

 

여기서 한 번 더 쪼개야 하는 게 결정론이라는 말 자체예요. 비율 한도는 비교만 결정론입니다. 분자와 분모를 문서에서 뽑아내는 건 100% 모델이죠. 추출 종속 레인이 따로 있는 이유가 이겁니다. 그래서 결정론을 판정 결정론과 추출 종속으로 나누고, 코드가 판정했다고 해서 컨피던스 1.0을 주지 않게 막아야 해요.

 

컨피던스는 판정의 것이 아니라 추출의 것이다. 결정론이라는 말 안에 이미 있던 균열이에요. 추출이 안 된 항목은 통과가 아니라 미비로 떨어지게 하고요.[3] 결국에는 추출을 따로 떼어 놓아야 어디서 틀렸는지가 팩트시트 한 장에서 보입니다.

시점으로 가르기

같은 항목이라도 사전 문서만으로 볼 수 있는 것들이 있고, 사후 문서와 첨부가 와야 볼 수 있는 것들이 있거든요. 항목 전체를 놓고 한 번은 전수로 물어봐야 합니다. 리트머스는 하나예요. 지금 손에 있는 입력만으로 판정할 데이터가 존재하는가. 해보면 사전에 남는 것, 사전과 사후로 갈라지는 것, 사후로 넘어가는 것 세 무더기로 나뉩니다.

무더기	예	처리
사전 문서만으로 판정 가능	번호 형식, 계획 단가 상한, 대상 자격	사전에 남긴다
계획값과 실제값을 둘 다 봐야 함	한도 비율, 인원당 단가, 총액	둘로 쪼갠다. 사전에서 계획값, 사후에서 실제값
사후 문서가 와야 판정 가능	필수 서류 구비, 실제 지급액, 참석 인원	사후로 옮긴다

 

그런데 여기서 과잉 이동을 막는 게 이동시키는 것만큼 중요하더라고요. 실제 값은 사후에 나오니까 한도 항목을 전부 사후로 옮기자는 논리가 그럴듯한데, 그러면 사전 단계에서 계획 값이 상한을 넘는 걸 아무도 안 봅니다. 결국에는 쪼갠다는 건 옮긴다는 뜻이 아니라 각 시점에 맞는 질문을 남긴다는 뜻입니다.

 

공통을 의심하기

 

쪼개다 보면 공통이라고 믿었던 것들이 제일 늦게 뜯깁니다. 사후 검증에는 첨부 서류가 갖춰졌는지 보는 공통 담당이 하나 있게 마련인데, 영수증이나 계산서 확인을 모든 항목에 똑같이 돌리기 쉬워요. 그런데 개인한테 계좌로 바로 지급하는 항목은 영수증이 애초에 없거든요. 이런 룰은 실패를 잔뜩 내는데 전부 오탐입니다. 규정이 한 페이지에서는 모든 지출에 서류를 갖추라고 써 놓고, 다른 페이지에서는 개인 지급에 영수증을 요구하지 않는 거죠. 규정이 스스로 세운 규칙을 자기도 모르게 어기는 지점이고, 해체가 드러내야 하는 균열이 바로 이런 것들입니다.

 

그래서 에이전트를 항목 종류별로 다시 쪼개게 돼요. 처음엔 몇 개였던 담당이 기준 문서의 세부 번호와 1:1로 맞춰지면서 십수 개가 됩니다. 공통 담당에는 정말로 모든 항목에 공통인 서류만 남기고, 영수증은 그걸 요구하는 항목의 룰로 옮기고요. 공통이라고 믿었던 규칙은 대개 어떤 부분집합에서만 참이다. 결국에는 공통 룰 하나가 오탐을 만들면 그건 룰이 틀린 게 아니라 아직 덜 쪼개진 거더라고요.

여기까지를 그림으로 놓으면 위아래 차이가 분명하죠.

쪼개면 안 되는 곳

쪼개기가 늘 답은 아닙니다. 경계가 없는 곳을 쪼개는 경우가 있어요. 병렬 처리를 하려고 워커 프로세스를 여러 개 복제해서 돌리는 식인데, 병목이 CPU가 아니라 모델 대기라면 복제할 이유가 없죠. 워커 한 기가 여러 건을 동시에 처리하면 됩니다. 반면 코드는 코어와 AI 패키지로 갈라서 import 방향까지 테스트로 강제할 만해요. 거기엔 경계가 실제로 있으니까요. 해체는 부수는 게 아니라 안에 있던 균열을 드러내는 거라고 했잖아요. 균열이 없는 곳을 자르는 건 해체가 아니라 그냥 파괴입니다.

 

쪼개기에는 비용도 있습니다. 조각이 늘면 같이 고쳐야 하는 자리가 늘어요. 문서 종류 하나를 추가하면 분류기, 분할기, 이미지 판독기를 같이 고쳐야 하고, 한 곳을 빠뜨리면 새 종류가 어딘가에서 조용히 유실됩니다. 조각을 늘릴 때는 그 조각을 아는 곳이 몇 군데인지 세어 두는 게 좋아요.

 

말이 좀 돌아갔는데, 결국에는 쪼개는 기준이 하나입니다. 그 조각이 독립적으로 판정되거나 실행될 수 있는가. 독립적이지 않은 걸 쪼개면 조각 사이에 상태를 주고받는 코드만 늘어납니다.

판정 하나도 쪼갠다

마지막 해체는 판정 하나의 안쪽입니다. 대상 조건에 괄호로 제외 항목이 적혀 있는데 키워드 부분일치 룰이 그 제외 항목에 걸려서 정반대로 분류하는 일이 흔해요. 괄호 안이 제외 절이라는 걸 정규식은 모르죠. 글자 단위로 쪼개면 의미가 깨집니다. 이럴 땐 추출 직후에 모델이 그 표기를 포함과 제외로 한 번 분류해서 팩트시트에 남기고, 룰은 그 분류를 읽게 하면 됩니다.

 

여기가 데리다의 세 번째 동작이 필요한 자리예요. 앞에서 모델이 하던 걸 코드로 옮겼으니 코드가 모델보다 낫다로 끝내고 싶어지는데, 그러면 또 다른 위계가 됩니다. 정규식이 글자 하나에 걸려 넘어지는 게 그 위계의 균열이죠. 아니죠, 이건 모델로 되돌아가자는 얘기가 아닙니다. 코드냐 모델이냐로 나누는 틀 자체를 흔들자는 거예요. 판정 하나를 확실한 것, 애매한 것, 사람만 아는 것으로 쪼개고, 확실한 건 코드가, 애매한 건 모델이, 사람만 아는 건 미비로 사람한테 보내는 거예요. 이름 대조 같은 것도 같은 패턴이 됩니다. 확실한 일치와 확실한 불일치는 코드, 약식이나 변형 표기는 모델, 외국인 이름처럼 사람만 알 수 있는 건 미비로. 저희는 이걸 게이트라고 부릅니다.

 

 

처음엔 사람한테 넘기는 게 좀 후퇴처럼 느껴집니다. 판정률이 곧 성능 같으니까요. 그런데 사람도 판정 주체 중 하나고, 어느 조각을 사람한테 보낼지 정하는 것까지가 해체예요. 결국에는 모른다고 말할 수 있는 시스템만이 안다고 말할 때 믿을 수 있습니다.

쪼개 둔 것만 다시 합칠 수 있다

해체의 배당은 마지막에 옵니다. 같은 입력을 고쳐서 다시 돌리는 기능을 만들 때예요. 사용자가 서류를 고쳐서 다시 올렸을 때 화면의 주인공은 디프입니다. 무엇이 달라져서 결과가 바뀌었는가를 말하지 못하면 그냥 두 번째 실행이죠.

 

이게 되려면 안쪽이 쪼개져 있어야 합니다. 문서 하나하나가 해시로 구분돼 있어야 안 바뀐 문서는 재추출하지 않고, 항목이 번호로 구분돼 있어야 어느 항목이 해소됐는지 말할 수 있고, 추출과 판정이 갈라져 있어야 바뀐 문서만 모델에 보낼 수 있어요. 교체된 파일 뭉치도 옛 분할을 페이지 해시로 물려받으면 달라진 구간만 다시 자르면 되고요. 그러면 디프에 모델의 비결정성이 새어 들지 않습니다. 결국에는 처음부터 한 덩어리였다면 디프라는 개념 자체가 성립하지 않아요.

결국에는 FDE의 능력

남는 생각은 이겁니다. 에이전트를 만드는 일의 대부분은 프롬프트를 쓰는 일이 아니에요. 고객이 덩어리로 준 걸 단위로 만드는 일입니다. 기준의 단위, 판정 주체의 단위, 추출의 단위, 시점의 단위, 입력의 단위. 그리고 어디서 쪼개기를 멈출지. 데리다의 세 동작으로 접으면 이렇습니다. 꼼꼼히 읽어서 규정이 스스로 어기는 지점을 찾고, 새로 설계하는 대신 이미 있던 균열을 따라 뜯고, 코드가 모델보다 낫다는 새 위계를 세우지 않는 것. 한 장으로 접으면 이렇게 됩니다.

무엇을 쪼개나	단위	잘 쪼개졌는지 묻는 질문	덜 쪼개졌을 때 증상
기준	항목 번호	고객 피드백이 번호로 오는가	의견 하나 반영에 룰을 처음부터 뒤진다
판정 주체	레인	같은 입력에 같은 답이 나오는가	판정이 실행마다 흔들린다
추출과 판정	팩트시트	틀린 곳이 팩트시트 한 장에서 보이는가	추출 오류와 판정 오류를 못 가른다
시점	사전, 사후	지금 입력만으로 판정할 데이터가 있는가	없는 값을 판정하려다 미비만 쌓인다
입력	의미 있는 건	조각이 독립적으로 판정되는가	건수가 부풀고 첨부 귀속이 깨진다
공통 룰	항목별 요구	그 룰이 정말 모든 항목에 참인가	특정 항목에서만 오탐이 쏟아진다
판정 하나	확실, 애매, 사람	애매한 것만 모델로 가는가	정규식이 글자 하나에 걸려 넘어진다

 

이건 개발팀 혼자서는 못 하는 일이에요. 규정의 어느 항목이 산술이고 어느 항목이 판단인지는 규정을 읽어 본 사람만 알거든요. 반대로 도메인 담당자 혼자서도 못 합니다. 어디까지가 코드로 되고 어디부터 모델이 필요한지는 만들어 본 사람만 알죠. 팔란티어가 온톨로지를 고객사에 내재화한다고 할 때 하는 일이 결국 이거라고 봅니다. 고객의 업무를 시스템이 다룰 수 있는 단위로 뜯어서 다시 세우는 것. 그래서 저는 FDE를 뽑을 때 프롬프트를 얼마나 잘 쓰는지보다, 규정 문서 한 권을 주면 그걸 레인이 붙은 표로 쪼갤 수 있는지를 보려고 합니다.

 

쪼개 놓은 걸 사용자한테 어떻게 내보낼지는 또 다른 얘기입니다. 안에서 잘게 쪼갠 걸 그대로 밖에 내보내면 아무도 못 읽더라고요. 그건 다음 글에서 쓰겠습니다.

주석

[1] 자크 데리다가 그라마톨로지에 대하여(1967)에서 서양 철학이 말을 글보다 앞세워 온 위계를 읽어 낸 방식입니다. 본문의 요약은 철학적으로 엄밀한 정의가 아니라 에이전트 설계에 빌려 쓰기 위한 것이고, 공학 쪽 문헌에서는 같은 동작을 decomposition이라고 부릅니다.

[2] 팩트시트. 판정에 앞서 입력에서 추출한 값들을 모아 둔 구조화 데이터입니다. 추출과 판정을 분리하면 추출은 입력당 한 번만 하고, 판정은 룰마다 이 팩트시트를 읽습니다.

[3] fail-closed. 판단에 필요한 값을 얻지 못했을 때 통과가 아니라 차단 쪽으로 떨어지는 설계입니다. 보안 쪽 용어를 빌려 왔습니다.