한눈에 보는 결론
현재의 AI 자동화는 사용자의 피드백을 받아 프롬프트와 절차를 고치는 방식으로 품질을 올린다. 이 방식은 이미 명시된 규칙, 즉 형식지(形式知)를 정교하게 만드는 데는 유효하지만, 사람이 결과를 보고도 완전히 설명하기 어려운 취향·안목·상황 판단까지 자산화하지는 못한다. 그래서 새 업무가 들어오면 이전에 잘 작동하던 에이전트가 다시 흔들리고, 예외를 막기 위해 프롬프트와 에이전트 그래프가 끝없이 복잡해진다.
영상의 핵심 제안은 딥러닝의 학습 구조를 AI 업무 자동화에 대응시키는 것이다. 에이전트의 결과를 단순히 “어떤 규칙으로 고쳐라”라고 설명하지 않고, 같은 입력에 대해 사람이 낸 결과를 정답에 가까운 비교 대상으로 제공한다. 에이전트 결과와 사람의 결과 사이의 차이를 손실(loss)처럼 계산하고, 그 차이를 줄이는 방향으로 에이전트 그래프와 내부의 판단 구조를 반복 업데이트한다. 발표자는 이 방식으로 사람의 암묵지를 자산화하는 도구를 ‘Deep Twin’이라고 부른다.
다만 이 영상에서 Deep Twin은 완성된 제품이나 검증된 연구 결과가 아니라 설계 가설과 개발 계획으로 제시된다. 암묵지가 실제로 어떤 데이터 구조로 저장되는지, 비교 결과에서 그래프의 무엇을 어떻게 바꾸는지, 다른 사람에게도 재현되는지는 후속 프레임워크와 실증을 통해 확인해야 한다.
1. AI 자동화가 ‘될 듯 말 듯’에서 멈추는 이유
1.1 에이전트는 답변기가 아니라 업무를 수행하는 실행 단위다
에이전트의 기본 흐름
영상은 에이전트를 단순한 채팅 답변이 아니라 목표를 받아 필요한 판단과 도구 사용을 이어 가며 결과를 만드는 실행 단위로 설명한다. 사용자가 업무를 맡기면 모델은 입력을 읽고, 필요한 파일이나 자료를 확인하고, 여러 단계를 거쳐 결과를 내놓는다. 에이전트에 지침과 절차를 저장한 skill.md 같은 파일을 붙이면 특정 업무를 반복 처리할 수 있다.
업무 자동화의 기대
예를 들어 고객 정보, 서비스 패키지, 고객의 코멘트와 회사 템플릿을 입력으로 받아 제안서 또는 견적서를 만드는 업무를 생각할 수 있다. 처음부터 모든 판단을 사람이 직접 하지 않고 에이전트에게 맡기면 반복 작업은 줄어든다. 문제는 결과가 한 번 나왔다고 자동화가 끝나는 것이 아니라, 그 결과가 실제로 쓸 수 있는 수준인지 사람이 다시 판단해야 한다는 데 있다.
1.2 첫 업무에서는 피드백이 빠르게 효과를 보인다
50%에서 75%, 다시 90%로
첫 번째 업무 결과의 품질이 약 50%라고 하자. 사람이 결과를 읽고 “이 부분은 이렇게 처리해야 한다”, “이 정보는 빠지면 안 된다”, “이런 표현은 쓰면 안 된다”와 같이 피드백을 주면 에이전트의 지침과 스킬이 수정된다. 그 결과 품질이 75% 정도로 오르고, 같은 유형의 첫 번째 업무를 다시 돌리면 90%에 가까워질 수 있다.
피드백이 저장하는 것
이 과정에서 시스템에 추가되는 것은 대체로 문장으로 적을 수 있는 규칙이다. 어떤 입력을 받아 어떤 절차로 처리하고, 어떤 오류를 피하며, 결과를 어떤 형식으로 내야 하는지를 프롬프트·스킬·체크리스트로 기록한다. 이미 드러난 실패를 반복하지 않게 만드는 데는 강력한 방식이다.
1.3 새 업무가 들어오면 기존 성공이 무너진다
90%의 지침이 다른 사례에서 60%가 되는 현상
두 번째 고객이나 새로운 조건의 업무를 넣으면 품질이 다시 60% 정도로 떨어질 수 있다. 첫 번째 사례에 맞춰 넣은 지침이 새 사례에는 맞지 않거나, 하나의 예외를 막기 위해 추가한 규칙이 다른 상황에서 충돌하기 때문이다. 다시 피드백을 주면 새 사례의 품질은 올라가지만, 그 피드백은 기존 규칙 위에 계속 덧붙는다.
프롬프트와 스킬의 팽창
이렇게 예외를 하나씩 명시하면 스킬 파일과 프롬프트는 길어진다. 한 업무에서 잘못된 결과가 나오지 않도록 넣은 조건이 다른 업무의 판단을 방해하고, 어느 규칙이 어느 판단을 만들었는지 파악하기도 어려워진다. 자동화가 고도화되는 동시에 유지보수 비용과 회귀(regression) 위험도 커진다.
2. 싱글 에이전트와 멀티 에이전트의 구조적 한계
2.1 싱글 에이전트에 모든 판단을 넣는 문제
하나의 긴 프롬프트가 모든 상황을 책임진다
업무가 단순할 때는 한 에이전트에 지침을 넣어도 된다. 그러나 입력 종류가 늘고 예외가 많아지면 하나의 에이전트가 조사, 작성, 검토, 수정, 품질 확인을 모두 맡게 된다. 컨텍스트 창 안에는 중요도가 다른 규칙과 사례가 함께 들어가고, 모델은 그중 어떤 지침을 우선해야 하는지 놓칠 수 있다.
복잡성의 대가
프롬프트가 길어질수록 모든 지침이 같은 비중으로 작동하지 않는다. 특정 사례에서 잘 작동한 조건이 일반 규칙처럼 적용되거나, 앞서 읽은 중요한 조건이 뒤의 내용에 묻힐 수 있다. 결과가 나빠질 때 원인이 모델인지, 입력인지, 지침 간 충돌인지, 도구 사용 과정인지도 분리하기 어려워진다.
2.2 멀티 에이전트는 복잡성을 분해하지만 없애지는 못한다
조사·작성·피드백·검수의 그래프
다음 접근은 업무를 여러 에이전트로 나누는 것이다. 한 에이전트는 자료를 조사하고, 다른 에이전트는 초안을 만들며, 또 다른 에이전트는 피드백을 주고, 검사 에이전트는 결과를 확인한다. 이들을 순서와 조건에 따라 연결하면 싱글 에이전트의 과부하를 줄일 수 있다.
노드와 엣지가 만드는 새 문제
멀티 에이전트에서는 각 에이전트가 노드가 되고, 노드 사이의 입력·출력 전달이 엣지가 된다. 반복 루프, 분기, 재시도, 메모리, 도구 호출까지 추가되면 단순한 순서도가 아니라 복잡한 업무 그래프가 된다. 각 노드가 무엇을 판단하고 어디서 실패했는지 추적하기가 어려워지며, 그래프를 만든 사람조차 전체 작동 방식을 한 번에 설명하기 힘들어진다.
2.3 연쇄 확률 비유가 보여주는 품질 문제
각 단계의 높은 성공률이 전체 성공을 보장하지 않는다
영상은 각 단계의 성공률이 99.9%, 또는 0.999라고 해도 여러 단계가 연결되면 전체 결과의 성공률은 계속 곱해진다는 비유를 든다. 단계가 많아질수록 작은 실패가 다음 단계로 전파된다. 최종 결과는 각각의 에이전트가 개별적으로는 잘 작동하는 것처럼 보여도 기대보다 나빠질 수 있다.
이 수치의 의미와 한계
0.999를 곱하는 설명은 멀티 에이전트 연쇄의 위험을 직관적으로 보여주는 비유다. 실제 시스템의 단계가 독립인지, 오류가 복구되는지, 검증 노드가 실패를 걸러내는지에 따라 결과는 달라진다. 따라서 이 숫자를 모든 에이전트 시스템의 실제 품질 공식으로 받아들이기보다, 그래프가 길어질수록 관찰·검증·복구 설계가 중요해진다는 주장으로 이해해야 한다.
3. 형식지와 암묵지의 차이
3.1 설명할 수 있는 지식은 자동화하기 쉽다
형식지(形式知, explicit/formal knowledge)
형식지는 말이나 글로 명시할 수 있고, 다른 사람이 읽어도 비교적 같은 방식으로 적용할 수 있는 지식이다. 업무의 입력·출력 형식, 처리 순서, 금지 조건, 품질 체크리스트가 여기에 해당한다. 현재의 프롬프트 엔지니어링과 스킬 파일은 주로 이 영역을 확장하는 방법이다.
형식지 피드백의 장점
결과를 보고 구체적으로 틀린 부분을 지적하면 에이전트는 다음 실행에서 같은 실수를 줄일 수 있다. 규칙이 안정적인 업무라면 이런 피드백만으로도 큰 생산성 개선을 얻을 수 있다. 문제는 모든 판단이 규칙으로 번역될 수 있다고 가정할 때 시작된다.
3.2 그림을 좋아하는 이유는 규칙 하나로 설명되지 않는다
여자친구에게 그림 취향을 묻는 비유
영상은 어떤 그림을 좋아하는 사람에게 “왜 이 그림이 좋아?”라고 묻는 장면을 예로 든다. 사람은 색감, 구도, 분위기, 작가, 기억 같은 이유를 말할 수 있다. 그러나 그 답변을 그대로 규칙으로 바꿔 다른 그림에 적용한다고 해서 그 사람이 실제로 좋아할 그림을 정확하게 골라낼 수 있는 것은 아니다.
말로 설명된 이유와 실제 판단 사이
사람이 답한 이유는 판단의 일부를 설명하는 형식지일 수 있다. 하지만 오랜 경험과 상황 감각이 한순간에 작동한 전체 판단에는 말로 표현하지 못한 요소가 남는다. 본인도 “왜 그런지”를 완전히 분해하기 어렵기 때문에, 설명된 이유를 많이 모으는 것만으로 취향과 안목을 그대로 복제할 수 없다.
3.3 제안서 작성은 암묵지가 드러나는 업무다
입력 목록 밖의 판단
제안서 작성 업무에는 고객 정보, 서비스 패키지, 요구사항, 회사 템플릿 같은 명시적 입력이 있다. 하지만 실제로 좋은 제안서를 만드는 사람은 고객이 직접 말하지 않은 우선순위, 문맥의 미묘한 변화, 어떤 표현을 어느 정도로 강조할지, 무엇을 생략해야 할지를 함께 판단한다.
두 번째 뇌와 위키의 한계
이런 판단을 정리해 개인 위키나 세컨드 브레인에 넣으면 기억과 검색에는 도움이 된다. 그러나 위키에 적힌 내용은 여전히 문장으로 표현된 형식지다. 형식지의 양을 늘리는 것이 암묵지의 자산화와 같은 것은 아니다. 현재의 AI 피드백이 계속 문장과 규칙을 추가하는 방식에 머문다면, 첫 사례의 성공을 새 사례에 일반화하는 데 구조적 한계가 생긴다.
4. 딥러닝에서 가져온 발상
4.1 사람이 규칙을 쓰는 대신 정답과 결과를 비교한다
전통적인 에이전트 피드백
현재 방식은 에이전트가 결과를 내면 사람이 “이 부분은 이렇게 바꿔라”라고 말하는 구조다. 이 말은 다시 프롬프트와 스킬에 들어갈 형식지로 변환된다. 발표자는 이 구조가 암묵지를 형식지로 억지로 번역하는 과정이라고 본다.
발상의 전환
새 제안에서는 사람이 모든 수정 규칙을 설명하지 않는다. 에이전트가 낸 결과와, 사람이 같은 입력을 보고 직접 낸 결과를 나란히 제공한다. “어떤 문장을 어떤 규칙으로 바꿔라”가 아니라 “내가 했다면 이 결과가 나온다”라는 비교 대상을 주는 것이다.
4.2 딥러닝의 데이터셋·정답·손실 구조
예측값과 실제값
딥러닝 학습에서는 데이터와 정답(label)을 준비하고, 정답을 가린 채 모델이 결과를 예측하게 한다. 예측값과 실제값의 차이를 손실(loss)로 계산한다. 학습 알고리즘은 손실을 줄이는 방향으로 모델의 가중치를 조금씩 바꾸고, 여러 epoch를 반복하면서 정확도를 높인다.
모델 파일에 사람이 읽을 규칙이 없어도 작동하는 이유
학습이 끝난 모델 파일을 열어 보면 “이 상황에서는 이 규칙을 적용한다”라는 문장이 들어 있지 않다. 사람이 이해할 수 없는 숫자와 가중치가 있을 뿐이다. 그런데도 모델은 학습 데이터에서 패턴을 익혀 보지 않은 입력에 대해 분류나 예측을 한다. 발표자는 이 점에서 모델이 형식지 문서가 아니라 깊은 암묵지를 갖고 있을 가능성을 상상한다.
4.3 에이전트에 적용할 Deep Twin 가설
에이전트 결과와 사람 결과의 차이
제안서 자동화 사례에서 에이전트가 만든 결과를 예측값, 사람이 같은 조건에서 만든 결과를 실제값에 대응시킬 수 있다. 두 결과 사이의 차이를 계산하면, 에이전트가 사람의 판단과 얼마나 다른지 나타내는 손실을 얻을 수 있다. 중요한 것은 그 차이를 사람이 다시 긴 규칙으로 설명하지 않아도 된다는 점이다.
암묵지를 보존하는 자리
발표자는 딥러닝에서 손실을 줄이는 알고리즘이 있던 자리에, 단순한 형식지 외의 무언가가 있어야 한다고 가정한다. 이 자리에 들어갈 구체적인 구조는 아직 공개되지 않았다. 추가 마크다운 파일인지, 임베딩된 수치인지, 다른 어텐션 구조인지도 후속 개발과 실증을 통해 밝혀야 할 부분이다.
5. Deep Twin의 상상된 작동 과정
5.1 사용자의 업무 설명으로 초기 그래프를 만든다
말과 자료에서 업무 프로세스 추출
사용자는 “암묵지를 자산화해 달라”라고 이론적으로 말하기보다, 실제 업무를 설명한다. 예를 들어 제안서 작성 업무를 30분 동안 음성으로 설명하면서 어떤 입력을 받고, 어느 순간 무엇을 확인하고, 어떤 자료를 참고하며, 어떤 판단을 거쳐 결과를 만드는지를 이야기한다. 도움이 되는 문서나 사례도 함께 넣을 수 있다.
그래프 0과 사용자 교정
도구는 사용자의 설명을 바탕으로 업무 프로세스를 그래프로 그린다. 사용자는 “맞다”, “이 부분은 이렇게 바뀌어야 한다”라고 피드백해 초기 그래프를 확정한다. 이 단계의 목적은 사용자가 그래프라는 내부 개념을 몰라도 자신의 업무 흐름을 확인하고 교정할 수 있게 하는 것이다.
5.2 첫 실행은 낮은 품질에서 시작한다
초기 상태는 무작위에 가깝다
확정된 초기 그래프에 첫 작업을 넣어도 결과는 처음 만든 에이전트와 크게 다르지 않다. 아직 실제 결과와 사람의 결과를 충분히 비교하지 않았기 때문이다. 발표자는 이를 딥러닝이 학습을 시작하기 전의 낮은 정확도 상태에 대응시킨다. 50%든 60%든 초기 결과는 학습의 출발점이다.
사람이 주는 비교 결과
첫 결과를 본 뒤 사람은 “이렇게 고쳐라”라는 규칙 대신 “내가 했다면 이 결과를 냈을 것”이라는 결과물을 제공한다. 도구는 에이전트 결과와 사람 결과의 차이를 계산하고, 그 차이를 줄이기 위한 업데이트를 시도한다.
5.3 그래프와 내부 판단 구조를 반복 업데이트한다
그래프 1과 그래프 1-1
그래프 안에는 여러 에이전트와 메모리, 노드 간 정보 전달, 각 단계에서 필요한 판단 근거가 들어 있다고 가정한다. 도구는 사람이 정확히 어떤 판단을 했는지 문장으로 모두 알지 못해도, 그래프 내부의 작동 구조에 변화를 준다. 그 결과 초기 그래프 0은 그래프 1이 되고, 이후 더 세밀한 버전인 그래프 1-1처럼 업데이트된다.
같은 업무를 다시 실행하는 이유
변경된 그래프에 처음과 같은 업무를 다시 넣으면 같은 결과가 나오지 않는다. 판단을 담당하는 그래프가 달라졌기 때문이다. 도구는 새 결과를 이전에 제공된 사람의 결과와 다시 대조하고, 새로운 손실을 계산한다. 이 과정을 반복해 손실이 줄어드는 방향으로 그래프를 업데이트한다.
5.4 멈춤 조건과 자산화
기울기가 완만해질 때까지 반복한다
학습은 결과가 더 이상 유의미하게 좋아질 기미가 보이지 않을 때까지 반복된다고 설명한다. 손실을 줄이는 변화가 충분히 작아지면 해당 버전의 그래프를 저장한다. 저장되는 것은 단순한 프롬프트 모음이 아니라 특정 업무에서 사람의 판단과 가까운 결과를 내도록 조정된 작동 구조라는 가설이다.
Deep Twin의 의미
딥러닝에서 모델이 데이터의 패턴을 학습하듯, Deep Twin은 한 사람 또는 한 조직의 업무 판단을 반복 비교해 업무 안목을 자산화하는 쌍둥이(twin)가 되는 것을 목표로 한다. 현재 영상에서 “암묵지”의 실제 내부 표현은 공개되지 않았으므로, 이 설명은 구현 완료에 대한 보고가 아니라 설계 방향이다.
6. 공개 계획과 검증 과제
6.1 오픈소스 프레임워크로 개발한다
스타터 킷과 확장성
발표자는 Deep Twin을 상상 속 도구로만 남기지 않고 오픈소스 프레임워크로 만들고 있다고 말한다. 기본 프로세스의 흐름은 프레임워크가 제공하되, 사용자가 그 위에서 구성요소를 부수고 끼우고 해체하며 확장할 수 있는 스타터 킷을 목표로 한다.
공개될 자료
프레임워크 공개와 함께 기반이 되는 논문, 사용 튜토리얼, 문서화 자료를 준비할 계획이다. 발표자 자신이 아닌 제3자가 실증하는 과정도 진행하고, 실증 결과를 계속 공유하겠다고 한다.
6.2 가장 중요한 미해결 질문
암묵지는 무엇으로 저장되는가
Deep Twin이 실제로 작동하려면 다음 질문에 답해야 한다.
표현과 업데이트
- 사람의 결과와 에이전트 결과의 차이를 어떤 방식으로 계산하는가.
- 손실을 줄일 때 그래프의 노드, 엣지, 메모리, 모델 설정 중 무엇을 업데이트하는가.
- 한 사례에 과적합되지 않고 새 업무에도 판단을 일반화할 수 있는가.
- 사람이 제공한 결과의 일관성·품질·편향을 어떻게 다루는가.
- 학습이 더 이상 좋아지지 않는 시점을 어떤 지표로 판단하는가.
- 개인의 안목과 조직의 업무 프로세스를 어떤 경계로 분리해 저장하는가.
검증의 필요
이 질문들이 답해지기 전에는 Deep Twin을 암묵지의 완전한 복제나 일반적인 AI 자동화 해결책으로 단정할 수 없다. 실제 업무의 여러 사례에 대해 초기 결과, 반복 횟수, 손실 변화, 새 사례의 성능, 회귀 여부를 공개적으로 비교해야 한다.
6.3 개발자와 AI 엔지니어가 읽어야 할 포인트
프롬프트보다 평가 데이터가 먼저다
이 설계가 주는 실무적 교훈은 에이전트의 프롬프트를 계속 길게 만드는 대신, 사람의 기준 결과와 에이전트 결과를 같은 입력에서 비교할 수 있는 평가 루프를 먼저 만들라는 것이다. 결과를 정답으로 고정할 수 있는 업무라면 데이터셋, 평가 함수, 회귀 테스트로 구체화할 수 있다.
그러나 완전한 딥러닝 모델 학습과는 다르다
Deep Twin은 모델 가중치를 직접 학습하는 시스템이라고 확정된 것이 아니다. 영상에서 제시한 것은 딥러닝의 데이터·정답·손실·반복 구조를 에이전트 그래프의 업데이트 과정에 빌려온 설계 비유이자 가설이다. 실제로는 그래프 재작성, 메모리 검색, 프롬프트 선택, 도구 라우팅, 모델 호출 정책 중 하나 또는 여러 조합일 수 있다.
7. 최종 정리
핵심 논지
현재 AI 자동화의 발전은 모델을 더 좋은 것으로 교체하는 것만으로 해결되지 않는다. 사람이 결과를 평가하고 피드백할 수 있는 업무에서는 이미 50%에서 75%, 90%로 빠르게 개선할 수 있지만, 그 성공은 특정 사례의 형식지를 학습한 결과일 수 있다. 새 사례에서 다시 품질이 떨어지는 이유는 사람이 실제로 사용하는 판단의 상당 부분이 설명하기 어려운 암묵지이기 때문이다.
제안의 가치와 한계
Deep Twin의 가치 있는 질문은 “사람이 판단 근거를 전부 문장으로 설명해야만 AI가 배울 수 있는가?”다. 사람의 기준 결과와 에이전트의 결과를 비교하는 것만으로도 자동화 그래프를 개선할 수 있다면, 프롬프트에 규칙을 덧붙이는 방식과 다른 학습 루프를 만들 수 있다. 다만 이 가능성은 아직 설계·개발·검증 중이며, 내부 표현과 일반화 성능을 확인하기 전까지는 가설로 다뤄야 한다.
핵심 요약 (40줄)
- AI 자동화는 처음에는 잘 되는 것처럼 보여도 업무 조건과 예외가 늘면 결과를 다시 갈아엎는 일이 반복된다.
- 에이전트는 목표를 받아 판단과 도구 사용을 이어 가며 결과를 만드는 실행 단위다.
skill.md같은 지침 파일은 반복 업무의 절차와 품질 조건을 에이전트에 저장한다.- 제안서·견적서 자동화처럼 입력과 출력이 비교적 분명한 업무는 에이전트 도입의 출발점이 된다.
- 첫 결과의 품질이 약 50%여도 사람의 구체적인 피드백으로 75%와 90%까지 빠르게 개선될 수 있다.
- 이 피드백은 대체로 프롬프트와 스킬에 추가되는 형식지다.
- 첫 번째 사례에서 90%였던 에이전트가 새로운 업무에서는 약 60%로 떨어질 수 있다.
- 새 사례마다 예외 규칙을 덧붙이면 프롬프트와 스킬이 팽창하고 회귀가 생긴다.
- 하나의 에이전트에 조사·작성·검수·수정을 모두 맡기면 컨텍스트와 주의력이 분산된다.
- 멀티 에이전트는 업무를 여러 노드로 나누지만 노드와 엣지로 된 복잡한 그래프를 만든다.
- 각 단계의 성공률이 높아도 연쇄 과정에서는 작은 실패가 뒤 단계로 전파된다.
- 0.999를 반복해서 곱하는 설명은 그래프가 길어질수록 검증과 복구가 중요하다는 비유다.
- 형식지는 말과 문서로 명시하고 다른 사람이 비교적 재현할 수 있는 지식이다.
- 암묵지는 경험·취향·안목·상황 판단이 결합되어 본인도 완전히 설명하기 어려운 지식이다.
- 그림을 좋아하는 이유를 설명한 말만으로 다른 그림에 대한 실제 취향을 재현하기는 어렵다.
- 설명된 이유와 사람이 실제로 내리는 전체 판단 사이에는 말로 표현되지 않은 층위가 있다.
- 좋은 제안서는 고객 정보와 템플릿 외에도 우선순위·강조·생략에 대한 안목을 요구한다.
- 세컨드 브레인과 AI 위키에 지식을 모아도 그 내용은 여전히 형식지에 머물 수 있다.
- 현재의 피드백 루프는 암묵지를 더 많은 문장과 규칙으로 번역하는 데 그칠 위험이 있다.
- 발표자는 해결의 단서를 딥러닝의 데이터셋·정답·손실 구조에서 찾는다.
- 딥러닝은 정답을 가린 입력에서 예측값을 만들고 실제값과의 차이를 손실로 계산한다.
- 학습은 손실을 낮추는 방향으로 가중치를 바꾸며 여러 epoch를 반복하는 과정이다.
- 학습된 모델 파일에는 사람이 읽는 규칙 대신 의미를 직접 해석하기 어려운 숫자와 가중치가 있다.
- 발표자는 모델이 형식지 문서가 아니라 깊은 암묵지를 갖고 있을 가능성을 상상한다.
- Deep Twin은 에이전트 결과와 사람이 같은 입력에서 낸 결과를 비교하는 설계 가설이다.
- 사람이 “이렇게 고쳐라”라고 규칙을 쓰는 대신 자신의 결과물을 비교 정답으로 제공한다.
- 두 결과의 차이를 손실처럼 계산하고 그 차이를 줄이는 방향으로 업무 그래프를 업데이트한다.
- 사용자의 업무 설명과 자료에서 초기 그래프를 만들고, 사용자가 그래프의 흐름을 교정한다.
- 초기 그래프의 첫 실행은 낮은 품질에서 시작하며 반복 비교를 통해 개선된다.
- 그래프의 노드·메모리·전달 관계·판단 근거에 어떤 변화가 생기는지는 아직 공개되지 않았다.
- 같은 업무를 업데이트된 그래프에 다시 넣고 사람의 결과와 재비교하는 과정이 학습 루프가 된다.
- 손실 감소가 더뎌질 때까지 반복한 뒤 더 나은 그래프 버전을 저장한다는 구상이다.
- Deep Twin의 목표는 한 사람이나 조직의 업무 안목과 암묵지를 업무 자산으로 만드는 것이다.
- 암묵지가 마크다운·임베딩·가중치·새로운 어텐션 중 무엇으로 표현될지는 미해결이다.
- 발표자는 Deep Twin을 실제 오픈소스 프레임워크와 확장 가능한 스타터 킷으로 개발 중이라고 말한다.
- 논문·튜토리얼·문서와 제3자 실증을 공개해 설계의 재현성을 확인할 계획이다.
- 사람의 기준 결과를 학습 데이터로 쓸 때 품질·일관성·편향을 관리해야 한다.
- 새로운 업무에 대한 일반화와 회귀 여부를 측정하지 않으면 암묵지 자산화를 주장하기 어렵다.
- Deep Twin은 완성된 제품이나 검증된 이론이 아니라 후속 개발과 실증이 필요한 설계 가설이다.
- 에이전트의 차별화는 모델 교체보다 사람의 판단을 비교·학습·검증하는 실행 루프에서 나올 수 있다.