AI에게 일을 맡기기 전에 내 일을 정리해야 한다고 생각했다. 업무 메모를 모으고, 결정의 이유를 남기고, 반복되는 일을 스킬로 만드는 것. 여기까지는 출발점이다. 하지만 기록을 잘 정리하고 스킬을 많이 만들어 둔다고 해서 일이 계속 좋아지는 것은 아니다.
내가 만들고 싶은 체계의 핵심은 그다음에 있다. 스킬조차 그냥 쓰는 것이 아니라, 사용 결과를 추적하고 개선하면서 관리해야 한다. 한 번 잘된 방법을 저장해 두는 데서 끝내지 않고, 그 방법이 다음 작업에서도 도움이 되었는지 확인하는 것이다.
어떤 상황에서 썼는지, 어떤 결과가 나왔는지, 무엇을 고쳤는지, 그 수정이 실제로 나아졌는지. 이 연결이 끊기지 않아야 스킬이 쌓이는 만큼 일하는 방법도 나아질 수 있다. 그렇지 않으면 스킬 폴더는 결국 예전에 잘됐던 프롬프트를 모아 둔 보관함이 된다.
스킬이 있다는 것과, 스킬이 잘 작동한다는 것은 다르다
여기서 말하는 스킬은 자주 하는 일을 다시 수행할 수 있도록 절차와 기준을 묶어 둔 것이다. 가령 자료를 읽는 순서, 결과물을 만드는 방식, 빠뜨리면 안 되는 확인 항목이 들어간다. 매번 처음부터 설명하지 않아도 된다는 점에서 유용하다.
그런데 절차가 적혀 있다는 사실은 그 절차가 좋다는 증거가 아니다. 지난번에는 충분했던 확인 항목이 이번 작업에는 부족할 수 있다. 모델을 바꾸면 같은 지시를 다르게 해석할 수 있고, 입력 자료가 달라지면 전에 없던 실패가 생길 수도 있다.
그래서 스킬을 완성된 정답으로 보지 않으려 한다. 지금까지의 경험으로 만든 현재 버전의 작업 방법으로 본다. 사용 결과가 그 버전을 다시 평가하고, 평가에서 발견한 문제가 다음 수정을 만든다.
내가 생각하는 흐름은 이렇다.
일을 한다 → 결과와 실패를 남긴다 → 반복되는 원인을 찾는다 → 스킬 수정안을 만든다 → 같은 기준으로 다시 확인한다 → 유지하거나 되돌린다.
여기서 중요한 것은 자동으로 고친다는 말이 아니다. 고친 이유와 고친 뒤의 결과를 연결해서 볼 수 있어야 한다는 것이다.
모델 비교 화면을 만든 이유
이 화면의 제목은 "내 업무에서 AI는 얼마나 잘했을까"다. 질문의 기준을 모델의 일반적인 순위가 아니라 내 업무로 옮겼다. 상단에는 모델별 결과가 있고, 아래에는 업무별 점수가 있다. 점수 옆에는 비용, 토큰, 시간과 같은 항목도 함께 놓여 있다.
내가 이 화면으로 보고 싶은 것은 "누가 1등인가"만이 아니다. 같은 모델도 어떤 업무에서는 잘하고 어떤 업무에서는 부족할 수 있다. 종합 점수가 비슷하더라도 필요한 시간이나 비용은 다를 수 있다. 결과가 좋았다는 말만으로는 다음에도 그 방법을 쓸지 결정하기 어렵다.
업무별 결과를 남기면 질문이 더 구체적이 된다. 어떤 작업에서 부족했는가. 입력이 부족했는가, 절차가 빠졌는가, 확인 기준이 모호했는가. 모델을 바꿀 문제인가, 스킬을 고칠 문제인가. 점수는 그 질문을 시작하는 신호이고, 판단의 근거는 실제 작업 기록에서 찾아야 한다.
화면에는 "AI 모델 비교", "스킬 관리", "개선 이력"이라는 세 탭도 있다. 내가 연결하고 싶은 것은 바로 이 셋이다. 모델 비교에서 발견한 문제를 스킬 수정으로 옮기고, 그 수정의 결과를 개선 이력에 남기는 구조다. 비교 화면만 있는 평가 도구보다, 평가를 다음 작업 방법으로 이어 주는 관리 체계에 가깝다.
다만 지금 캡처에서 열린 것은 모델 비교 탭이다. 스킬 관리와 개선 이력의 상세 화면이나 자동 개선 기능이 실행되는 모습까지 보여 주는 것은 아니다. 이 글에서는 화면에서 확인할 수 있는 것과, 내가 만들고 싶은 운영 원칙을 구분해서 설명한다.
점수보다 중요한 것은 어떤 버전으로 일했는가다
결과를 추적하려면 결과만 저장해서는 부족하다. 무엇을 사용해서 그 결과를 만들었는지도 같이 남겨야 한다.
예를 들어 "보고서가 괜찮았다"는 기록은 다음 개선에 쓰기 어렵다. 어떤 모델을 썼고, 어떤 스킬 버전으로 작업했으며, 어떤 자료와 기준을 적용했는지 알아야 한다. 문제가 있었을 때도 마찬가지다. 결과가 나빴다는 말보다 어느 단계에서 무엇이 빠졌는지가 필요하다.
내가 관리 기록에 연결하고 싶은 항목은 다음과 같다.
- 작업과 입력 조건: 무엇을 하려고 했고 어떤 자료가 주어졌는가.
- 실행 조건: 어떤 모델과 스킬 버전으로 작업했는가.
- 결과와 검토: 어디까지 쓸 수 있었고 무엇을 사람이 고쳤는가.
- 수정과 결정: 무엇을 바꾸었고 왜 유지하거나 되돌렸는가.
모든 일을 복잡한 점수표로 만들 필요는 없다. 반복되는 일에서 개선 판단에 필요한 최소한의 근거부터 남기면 된다. 숫자로 판단할 수 있는 항목과 사람이 봐야 하는 항목도 나누어야 한다. 형식 준수나 누락 여부와, 설명이 납득되는지 같은 판단은 같은 방식으로 평가하기 어렵다.
또 작업 난도가 달라졌는데 점수만 비교하면 잘못된 결론을 내릴 수 있다. 개선을 확인하려면 가능한 한 같은 기준과 비교 가능한 조건을 유지해야 한다. 새 버전이 익숙한 예시 하나에만 잘 맞는 것은 아닌지도 확인해야 한다.
결정을 남긴다는 것은 수정 이유와 결과를 함께 남긴다는 뜻이다
가상의 예를 들어 보자. 주간 보고서를 만드는 스킬이 있고, 초안에 내용은 많지만 확인된 사실과 추정이 섞이는 문제가 반복된다고 하자.
"더 정확하게 써라"는 문장만 추가하면 어떤 문제가 해결되어야 하는지 불분명하다. 대신 원인을 먼저 남긴다. 출처가 없는 수치를 확정된 사실처럼 표현했고, 읽는 사람이 근거를 확인하기 어려웠다는 것이다. 그다음 스킬에 "수치에는 출처를 붙이고, 확인하지 못한 내용은 따로 표시한다"는 절차를 추가한다.
이후에는 수정된 스킬로 다시 만든 보고서를 같은 기준으로 검토한다. 출처 누락이 줄었는지, 추정이 사실처럼 쓰이지 않았는지, 반대로 불필요한 표시가 늘어서 보고서를 읽기 어려워지지는 않았는지 본다.
결정 기록에는 "출처 확인 절차 추가"만 남기지 않는다. 문제, 수정 내용, 확인 결과, 채택 또는 되돌림의 이유를 함께 남긴다. 나아지지 않았다면 이전 버전으로 돌아갈 수 있다. 그래도 그 시도가 왜 실패했는지는 지우지 않는다.
이 예시는 실제 성과를 말하는 것이 아니다. 내가 말하는 사용 결과 추적과 개선이 어떤 형태인지 설명하기 위한 가상의 상황이다. 핵심은 좋은 문장을 저장하는 일이 아니라, 작업 방법의 변경과 결과 사이에 근거를 남기는 데 있다.
GBrain에서 가져온 것은 맥락을 계속 정리하는 생각이다
이 체계를 생각할 때 참고한 자료 중 하나가 Garry Tan의 GBrain이다. 공개 저장소는 이를 AI 에이전트를 위한 기억 계층으로 설명한다. 메시지에서 필요한 신호를 기록하고, 먼저 축적된 기록을 찾아보고, 페이지와 타임라인을 남기며, 정기적으로 중복과 모순을 정리하는 흐름을 제시한다.
내가 가져온 생각은 답하기 전에 맥락부터 찾는다는 것, 그리고 기록을 한 번 저장하고 끝내지 않는다는 것이다. 메모가 많이 쌓여 있다는 것과 다음 판단에 필요한 맥락을 찾을 수 있다는 것은 다르다. 기록 사이의 관계와 변화가 정리되어 있어야 다음 작업에서 쓸 수 있다.
다만 GBrain의 기억 정리와 스킬의 성능 개선을 같은 것으로 보지는 않는다. 기억 정리는 판단에 필요한 맥락을 유지하는 바탕이다. 그 위에서 작업 방법 자체를 검토하고 바꾸는 과정은 별도로 필요하다. 그 부분을 더 직접적으로 보여 준 자료가 WikiSkill이다.
WikiSkill에서 본 것은 스킬과 개선 지식의 분리다
arXiv 논문 "WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution"은 실행 경험, 축적된 지식, 실제로 사용하는 스킬을 나눈다. 원본 실행 기록은 보존하고, 거기서 얻은 성공 전략과 실패 원인은 위키에 정리하며, 그 지식을 바탕으로 스킬을 만들거나 수정한다.
이 구조를 단순한 세 칸짜리 정리법으로 받아들이면 중요한 부분을 놓친다. 논문에는 실행, 경험 정리, 수정 제안, 검증과 되돌림이 연결된 반복 과정이 있다. 현재 스킬로 작업한 결과를 보고 다음 수정안을 만들고, 검증 결과를 통해 그 수정안을 받아들일지 결정한다.
특히 눈에 들어온 것은 스킬 변경을 되돌려도 위키는 남는다는 점이다. 실패한 수정안을 계속 사용하지는 않지만, 그 시도에서 얻은 지식까지 버리지 않는다. 수정 내용과 검증 점수, 채택 여부가 기록되기 때문에 다음 개선에서 같은 실패를 다시 제안하지 않도록 참고할 수 있다.
내가 말하는 결정 기록도 여기에 가깝다. 현재 사용하는 스킬은 계속 바뀔 수 있다. 하지만 무엇을 바꿨고 왜 받아들였는지, 무엇을 거절했고 왜 그랬는지는 남아 있어야 한다. 작업 방법과 작업 방법을 개선하면서 얻은 지식은 같은 것이 아니다.
논문은 정해진 데이터와 검증 기준을 사용하는 연구이고, 내가 다루는 실제 업무는 기준과 입력이 더 다양하다. 논문의 결과를 내 업무 성과로 옮겨 말할 수는 없다. 내가 차용한 것은 경험을 정리해 다음 스킬 개선에 쓰고, 변경을 검증하며, 실패한 변경의 이유까지 보존하는 원리다.
자동 개선보다 먼저 필요한 것은 변경을 관리하는 기준이다
"계속 개선한다"는 말은 매번 스킬을 바꾸라는 뜻이 아니다. 한 번의 실패를 모든 작업에 적용하면 오히려 절차가 늘어나고 다른 작업을 방해할 수 있다. 반복되는 문제인지, 특정 입력에서만 생긴 문제인지, 절차를 바꿔 해결할 수 있는 문제인지 먼저 봐야 한다.
그래서 개선에는 멈추는 기준도 필요하다. 무엇을 성공으로 볼지, 무엇이 나빠지면 되돌릴지, 어떤 변경은 사람이 검토해야 하는지 정해야 한다. 스킬을 수정하는 일과 그 수정안을 실제로 사용하는 일도 구분하고 싶다.
AI가 분석과 수정안을 도울 수는 있다. 하지만 평가 기준을 정하고, 중요한 변경을 받아들이고, 결과가 업무에 맞는지 판단하는 책임까지 점수 하나에 넘길 수는 없다. 추적은 사람의 판단을 없애기 위한 것이 아니라 판단에 필요한 근거를 잃지 않기 위한 것이다.
기록은 다음 스킬을 바꾸는 데 쓰여야 한다
처음에는 내 일을 다시 찾을 수 있게 정리하는 것이 중요했다. 이제는 그 정리가 다음 작업 방법을 바꾸는 데까지 이어져야 한다고 생각한다.
기록에서 맥락을 찾고, 맥락을 바탕으로 스킬을 쓰고, 사용 결과를 확인하고, 수정의 이유를 남긴다. 잘못된 수정은 되돌리되 배운 것은 남긴다. 그 연결이 있어야 스킬이 정적인 문서가 아니라 관리되는 작업 방법이 된다.
내가 만들고 싶은 것은 스킬을 많이 모아 둔 시스템이 아니다. 어떤 스킬이 어떤 조건에서 도움이 되었고, 왜 바뀌었으며, 다음에도 써도 되는지를 설명할 수 있는 체계다.