AI로 정말 나아졌는지, 내 스킬부터 확인해 보기

지난 글 「AI로 많이 만들었다. 그래서 정말 나아졌나?」에서는 AI가 만든 산출물의 양과 실제로 일이 나아진 정도를 구분하고 싶다고 썼다. 코드를 빠르게 추가한 일도 있었지만, 흩어진 자료를 대조해 만들 필요가 없는 일을 찾아낸 순간도 있었다. 작성이 빨라진 만큼 누군가의 확인과 수정 부담이 늘었을 가능성도 함께 봐야 했다.

그 글의 끝에서는 실제 작업 몇 건부터 돌아보겠다고 했다. 무엇이 불분명했고, AI가 무엇을 도왔고, 사람이 어디를 고쳤으며, 어떤 결정이 달라졌는지 남겨 보고 싶었다.

아직 AI의 효과를 설명할 만큼 기록을 모으지는 못했다. 그런데 그 질문을 붙들고 있다가 이번에도 작은 도구를 만들었다. 이 도구를 만들었다는 사실 역시, 일이 나아졌다는 답이 될 수는 없다. 그래서 이번에는 무엇을 더 만들었는지와 함께, 이 도구로 어떤 결정을 하려는지부터 적어 두려 한다.

첫 대상은 내가 반복해서 쓰는 리뷰 스킬이다. 전편에서 적었던 기준도 그대로다. 중요한 결함을 놓치지 않으면서, 지적이 맞는지 사람이 확인하는 부담을 줄일 수 있는가. 이번 글은 그 질문을 비교 가능한 크기로 좁히고, 확인할 근거를 남길 방법을 준비한 과정이다.

스킬의 지침을 남길지, 지울지 결정하고 싶었다

Agent Skill Garden에는 반복하는 업무의 절차와 판단 기준을 모아 두었다. 처음 만들 때는 도구가 바뀌어도 이어 쓸 수 있는 업무 방식을 남기는 데 관심이 있었다. 이제는 그 방식이 계속 도움이 되는지도 확인하고 싶다.

리뷰에서 같은 실수가 반복되면 스킬에 문장을 더 넣게 된다. 이미 수정된 문제를 다시 지적하지 말라고 쓰고, 근거가 부족하면 단정하지 말라고 덧붙인다. 무엇을 고쳤는지는 파일에 남는다. 하지만 지침을 추가한 뒤 오탐이 줄었는지, 그 대신 중요한 문제를 덜 찾게 됐는지는 응답을 따로 봐야 한다.

내가 내리고 싶은 결정은 구체적이다. 이 변경을 계속 쓸지, 더 고칠지, 되돌릴지 정하고 싶다. 스킬이 길어졌다는 사실만으로 개선이라고 부르지 않고, 불필요한 지침은 지울 수 있었으면 한다.

그러려면 세 조건의 응답을 비교할 수 있어야 했다.

• 스킬 지침을 제공하지 않은 기본 AI
• 현재 스킬의 지침을 제공한 AI
• 수정한 스킬의 지침을 제공한 AI

기본 AI와 현재 스킬의 비교는 지침을 더한 효과를 묻는다. 현재 스킬과 수정한 스킬의 비교는 이번 변경을 남길 이유를 묻는다. AI 없이 사람이 수행하는 기존 방식과의 비교는 아직 별도로 해야 할 일이다. 이 실험으로 AI 자체의 기여까지 모두 설명할 수는 없다.

그래서 Garden에 응답을 수집하고 사람의 판정을 비교하는 기능을 붙였다. 이름은 Garden Eval이고, 첫 구현은 PR #12를 통해 저장소에 반영했다. 실제 사용에서 어떤 차이를 만드는지는 이제 확인해야 한다.

전편에서 보고 싶었던 것 중 어디까지 담았나

전편에서는 판단의 품질, 사람의 부담, 완료와 비용, 실제 효용을 함께 보자고 했다. 이번 도구가 그 네 가지에 답해 주는 것은 아니다. 지금 기록할 수 있는 것과 앞으로 확인해야 할 것을 나누면 다음과 같다.

실제 효용을 묻는 마지막 질문에는 리포트가 대신 답할 수 없다. 비교 결과를 읽고 스킬 변경을 유지하거나 되돌렸는지, 다음 작업에서 같은 문제를 덜 겪었는지는 실제 사용 기록으로 남겨야 한다.

여기서 다루지 않는 일의 가치도 그대로 남아 있다. 인터뷰로 개발 범위를 줄이거나 모호한 요구를 확인 가능한 질문으로 바꾼 기여는, 리뷰 스킬의 평가 결과로 설명되지 않는다. 그런 일은 전편에서 적은 것처럼 무슨 문제였고 어떤 결정이 달라졌으며, 누가 확인했고 이후에 어떻게 쓰였는지 연결해 봐야 한다. 작은 도구의 측정 범위를 업무 전체의 범위로 착각하지 않으려 한다.

첫 실험에서 무엇을 개선으로 볼 것인가

첫 평가 대상은 중요한 회귀를 찾는 critical-review로 골랐다. 자주 맡기는 작업이고, 판단이 달라져야 하는 상황을 작은 코드와 설명으로 구성할 수 있었다. 공개용으로 새로 만든 합성 사례 10개를 준비했다.

예를 들어 계정 소유권을 확인하던 코드가 제거된 사례에서는 다른 계정의 정보에 접근할 수 있는 문제를 찾아야 한다. 그 검사를 다시 넣은 사례에서는 현재 코드에 문제가 남았는지 다시 판단해야 한다. 이전 지적을 계속 반복하면 첫 사례를 맞히더라도 두 번째에서는 잘못된 판단이 된다.

반대로 아무것도 지적하지 않으면 오탐만 줄어든 것처럼 보일 수 있다. 그래서 정상적인 변경을 보여줄 때도 제공된 코드와 계약을 근거로 판단했는지 확인한다. 자료가 부족한 경우에는 확인할 수 없는 부분을 남겨야 한다. 그럴듯하고 단호한 설명 자체를 통과 기준으로 삼지는 않았다.

응답을 받은 뒤에는 사람이 판정 항목마다 pass, fail, unjudged를 기록한다. 통과나 실패에는 검토자와 구체적인 근거가 필요하다. 확인하지 않은 것은 미판정으로 남는다. 정답 기준과 이전 판정은 응답을 만드는 에이전트에게 제공하지 않는다.

리포트에서는 실패가 통과로 바뀐 항목과 통과가 실패로 바뀐 항목을 함께 보여 준다. 다른 항목의 개선에 퇴행이 가려지지 않도록 했다. 실행이 실패하거나 사람이 판정하지 않은 항목은 판단 불가로 남긴다. 실행에 성공했다는 사실만으로 판단까지 좋아졌다고 처리하지 않는다.

이때 한 항목이 개선됐다는 표시만 보고 변경을 채택할 수는 없다. 예를 들어 오탐이 줄었어도 중요한 결함을 새로 놓쳤다면 함께 봐야 한다. 답변을 확인하는 데 시간이 더 들었다면 그 부담도 남겨야 한다. 아직 수행하지 않은 실험이지만, 앞으로 결과를 읽을 때 어떤 이유로 변경을 남기거나 버릴지는 먼저 정해 두고 싶었다.

사용 흐름은 run으로 응답을 모으고, assess로 판정을 남기고, compare로 대조하는 세 단계로 나눴다. 구체적인 명령은 사용 가이드에 정리했다. 도구 안에서 결론까지 자동으로 내리기보다, 내가 그 결론을 검토할 때 필요한 자료를 함께 남기려는 구조다.

측정하려고 만든 코드도 같은 질문을 받았다

이 과정에서 실제로 달라진 것은 비교 도구의 구현이었다. 리뷰에서 ‘같은 조건’이라는 전제부터 어긋나는 문제가 나왔다.

첫 구현은 평가 자료의 해시를 계산할 때 JSON 키를 정렬했지만, AI에게 전달하는 프롬프트에서는 정렬하지 않았다. 자료의 키 순서만 바꾸면 기록에는 같은 입력으로 남는데, AI가 읽는 순서는 달라졌다. 그 상태에서 응답이 달라지면 스킬 수정의 효과로 오해할 수 있었다. 리뷰 지적을 재현하고, 실제로 전달하는 입력의 순서와 내용을 대조하도록 고쳤다.

한 차례 고친 뒤에도 비교의 전제에 빈틈이 남아 있었다. 같은 실행의 응답을 한쪽에서는 실패, 다른 쪽에서는 통과로 판정하면 도구는 이를 개선으로 표시했다. 스킬이나 응답이 달라진 것이 아니라 판정만 달라진 경우였다. 추가 리뷰를 받고 같은 실행을 중복 비교하지 못하게 했다.

그렇다고 같은 스킬의 비교까지 모두 막으면 또 다른 질문을 놓친다. 스킬을 바꾸지 않고 독립적으로 실행해도 답과 판정은 달라질 수 있다. 다음 리뷰에서는 그 편차를 확인할 기준선까지 막았다는 지적을 받았다. 같은 스킬의 독립 실행은 편차 측정을 명시적으로 선택했을 때 비교할 수 있게 하고, 그 차이는 스킬 개선과 구분해 표시했다. 작은 차이를 변경의 효과로 읽기 전에, 같은 조건을 반복했을 때도 얼마나 달라질 수 있는지 확인할 자리가 필요했다.

참조 파일을 빠뜨리는 문제도 있었다. Markdown만 읽는 구조에서는 JSON이나 YAML을 수정해도 그 변경이 AI에게 전달되지 않았다. 텍스트 참조 파일을 함께 제공하도록 고쳤더니, 이번에는 .env 같은 로컬 설정까지 포함되는 문제가 드러났다. 숨김 경로는 읽기 전에 제외하고, 지원하는 공개용 참조만 준비해 사용하도록 경계를 정리했다. 변경의 효과를 판단하려면 그 변경이 실험에 들어갔는지뿐 아니라, 함께 전달하면 안 되는 자료는 없는지도 확인해야 했다.

실패와 비용을 보는 방식에도 빈틈이 있었다. 긴 답을 쓰다가 시간 초과가 난 실행에서 실패 상태가 덮어써지거나, 모든 응답을 받은 뒤 마지막 저장이 실패하면 기록이 남지 않을 수 있었다. 실패 원인을 보존하고 응답을 하나 받을 때마다 기록하도록 고쳤다. 비교에 쓰지 못하더라도 시도한 과정과 비용은 기록에 남아야 했다.

일곱 번의 리뷰도 비용이었다

전편에서 테스트 개수보다 어떤 위험을 줄이는지 보자고 썼는데, 바로 내 코드에도 같은 질문이 돌아왔다. 첫 구현의 테스트가 통과했다는 사실은 비교의 전제가 맞다는 보장이 아니었다.

심지어 실행이 중단됐을 때 남은 프로세스를 정리하는 테스트는, 그 기능을 일부러 고장 내도 통과했다. 확인하려던 실패를 잡지 못하는 테스트였던 셈이다. 검증 방식을 고친 뒤에는 같은 결함을 넣었을 때 테스트가 실패하는 것을 재검토에서 확인했다. 테스트가 있다는 것과 필요한 순간에 실패한다는 것은 달랐다.

리뷰는 일곱 차례 이어졌다. 참조 파일을 빠뜨리지 않게 고친 변경이 로컬 설정을 함께 읽었고, 같은 실행의 중복 비교를 막으려던 변경은 편차를 살펴볼 독립 실행까지 막았다. 수정이 새로운 문제를 만드는 일이 반복됐다. 일곱 번을 거쳤다는 사실만으로 품질이나 생산성을 설명할 수는 없다. 지적을 재현하고, 수정하고, 다시 검토하는 일도 모두 이 도구를 만드는 데 든 비용이다.

사람이 실제로 들인 시간을 기록하지는 못했다. 그래서 AI 없이 구현했을 때보다 빨랐는지, 검토와 재작업에 얼마나 더 들었는지는 계산할 수 없다. 다만 처음 코드를 생성한 시점에서 일을 끝낸 것으로 셌다면, 그 뒤의 비용은 모두 빠졌을 것이다.

마지막 리뷰에서는 검토 범위 안에서 동작의 정확성을 해치는 결함을 찾지 못했고 병합해도 된다는 판단을 받았다. 진단 문구나 방어 조건을 더 명확히 하자는 의견은 후속 정리로 남았다. 이를 도구에 더 이상 문제가 없다는 뜻으로 받아들이지는 않는다. 이번 범위에서 실행해 볼 상태가 됐다는 판단으로 받아들였다.

병합 전 저장소 전체 테스트 188개와 CI가 통과했고, 스킬을 제공하지 않은 조건과 현재 스킬을 제공한 조건에서 응답 수집부터 비교 리포트 생성까지 확인했다. 이 검증에는 정해진 응답을 내는 실행기를 사용했다. 여기서 확인한 것은 도구의 동작이다. 실제 모델로 현재 스킬과 수정한 스킬을 비교해 판단이 개선됐는지 확인한 결과는 아직 없다.

이번 리뷰로 비교의 전제가 어긋나거나 실패 기록이 사라지는 문제를 고쳤다. 도구를 사용하는 사람이 그 덕분에 얼마나 수월하게 판단하는지는 다음 사용에서 확인해야 한다. 코드의 오류를 고친 사실과 AI 활용의 효과를 입증한 사실은 각각의 근거로 설명해야 한다.

내가 만든 평가도 목표가 될 수 있다

전편에서 위브 같은 관측 도구를 보며 고민했던 것은 점수가 어떤 일을 선택하게 만드는가였다. 내가 만든 평가 도구에도 같은 문제가 생길 수 있다. 공개된 사례를 통과하게 스킬을 고치는 일 자체가 목표가 될 수 있기 때문이다.

처음에는 개선에 쓸 사례 여섯 개와 마지막 확인용 사례 네 개를 나눴다. 각각 calibration과 holdout으로 표시한다. 다만 모두 공개되어 있다. 마지막 확인용이라는 이름만으로 오염을 막을 수는 없고, 그 사례까지 보며 고쳤다면 새로운 사례가 필요하다. 작은 사례집에서 얻은 결과를 실제 업무 전체로 넓혀 말할 수도 없다.

모델과 실행 환경도 가능한 한 맞춰야 한다. 이 도구는 사용자가 지정한 모델과 환경을 기록하지만, 실행 환경의 전역 지침이나 모델 제공자의 내부 변화를 모두 검증하지는 못한다. 사람의 판정도 틀릴 수 있으니 가능하면 어느 버전의 답인지 가리고 읽고, 의견이 갈리면 근거를 다시 확인해야 한다.

기록하는 비용도 생긴다. 사례를 만들고 응답을 읽고 판정을 남기는 시간이, 스킬을 쓰면서 줄어든 부담보다 커질 수 있다. 전편에서 말한 사람의 부담에는 이 평가를 운영하는 시간도 들어가야 한다.

그래서 처음부터 모든 업무를 이 형식에 맞추려 하지는 않는다. 반복해서 겪는 실패 하나와 실제로 고민 중인 스킬 수정 하나를 골라 써 보려 한다. 기존 PR이나 작업 기록에 변경 이유와 판단 근거를 이어 남기고, 기록 자체를 위한 일을 늘리지 않는 쪽으로 시작하고 싶다.

다음에는 이 기록으로 결정을 해 봐야 한다

다음 작업에서는 불편했던 판단 하나를 고르고, 현재 스킬의 응답과 필요한 수정의 이유를 먼저 남기려 한다. 수정한 스킬의 결과를 본 뒤에는 다른 사례에서 판단이 나빠지지는 않았는지, 사람이 확인하는 데 얼마나 걸렸는지 함께 살피고, 변경을 유지할지, 더 수정할지, 폐기할지 결정해 보려 한다. 그다음 실제 리뷰에서도 같은 문제가 줄었는지 돌아보고 싶다.

결과가 좋아 보여도 다음 작업에 쓰이지 않을 수 있다. 반대로 큰 수치 변화가 없어도, 반복해서 확인하던 한 가지를 덜 확인하게 될 수 있다. 어느 쪽이든 실제 사용에서 달라진 일을 적어야 한다. 평가 리포트를 만들었다는 사실은 그 자리를 대신하지 못한다.

스킬의 지침을 덜어내거나 작은 스크립트로 옮기는 결론이 나올 수도 있다. 이 도구 역시 결정을 돕지 못하고 관리할 일만 늘린다면 줄이거나 걷어낼 수 있어야 한다.

전편의 질문은 아직 남아 있다. AI를 활용해 누구의 어떤 불편이 줄었는지, 내가 편해진 만큼 다른 사람에게 일이 넘어가지는 않았는지. 이번에는 그중 반복해서 쓰는 리뷰 스킬 하나에 대해 확인할 자리를 만들었다.

다음에는 그 자리에 실제 사용 결과를 채우고 싶다. 왜 스킬을 고쳤고, 어떤 판단이 달라졌으며, 누가 무엇을 덜 확인하게 됐는지까지 설명할 수 있었으면 한다. 필요한 문제를 놓치지 않고, 불필요한 확인과 재작업을 줄이는 데 AI를 쓰고 싶다는 마음은 앞선 글과 같다.