18일 동안 정말 좋아졌는지, 무엇으로 확인하나?
SGK 스튜디오를 운영하면서 동시에 굴리는 코드 저장소는 마흔 개가 넘습니다. 회사 업무와 개인 프로젝트를 오가며 하루에도 여러 저장소를 드나들다 보면 '오늘 많이 했다'는 감각은 쉽게 남지만, 그 감각이 실제로 지난주보다 나아졌다는 증거는 아닙니다. 바쁘다는 느낌과 좋아지고 있다는 사실은 다른 것입니다.
이 구분이 흐려지면 위험한 이유가 따로 있습니다. 얼마 전 규칙 위반 문구를 자동으로 잡아내는 검사 도구를 하나 만들고, 양성 사례 다섯 건만 돌려 본 뒤 '믿을 만하다'고 판단한 적이 있습니다. 인접 도메인의 흔한 단어(the·Act·Law·Regulations)로 적대적 테스트를 돌리자 거짓 통과가 네 건이나 나왔습니다. 통과 케이스만 골라 돌린 결과는 도구가 작동한다는 증거가 아니라, 통과할 입력을 제가 직접 골랐다는 증거였습니다.
저장소·커밋·코드 줄 수 같은 자기 보고형 숫자에도 같은 함정이 있습니다. 숫자가 늘었다는 사실 자체는 부풀리기 쉽고, 그 숫자만으로 무엇이 실제로 나아졌는지는 알 수 없습니다. 그래서 감으로 판단하는 대신 정해 둔 시점 두 곳에서 똑같은 방식으로 자산을 재고, 그 사이 늘어난 항목을 하나하나 뜯어보기로 했습니다.
혼자 여러 프로젝트를 동시에 운영할 때는 이 확인이 더 중요해집니다. 옆에서 진행 상황을 지켜보는 동료가 없으니 스스로 남긴 기록 말고는 무엇을 얼마나 했는지 대조할 방법이 없습니다. 그래서 이번에는 인상 대신 기록으로, 18일 간격을 두고 저장소·커밋·코드 줄 수와 시스템을 운영하는 자동화 도구 규모를 각각 두 번씩 재기로 했습니다.
8월 21일 기준선 — 저장소 42개, 커밋 5,608개, 코드 109만 줄
측정 방법은 단순했습니다. 2026년 8월 21일을 기준선으로 잡고, 그 시점까지 만든 모든 개인 코드 저장소를 훑어 저장소 수·누적 커밋 수·전체 코드 줄 수를 그대로 세었습니다. 새로 만든 계측 도구가 아니라 이미 있는 버전 관리 기록을 그대로 읽는 방식이라, 판단이 끼어들 자리가 없습니다.
기준선 숫자는 저장소 42개, 누적 커밋 5,608개, 전체 코드 1,092,296줄이었습니다. 여기에 더해 시스템을 운영하는 데 쓰는 인공지능 자동화 도구도 함께 셌습니다. 모든 작업에 공통으로 적용되는 업무 지침서 29개, 특정 역할을 맡은 자동화 도우미 23개, 필요할 때만 꺼내 쓰는 업무 매뉴얼(스킬) 60개, 작업이 끝날 때마다 자동으로 도는 검사 프로그램 22개, 반복 실행되는 짧은 프로그램(스크립트) 210개, 정해진 시간마다 저절로 실행되는 정기 작업(크론) 142개였습니다.
이 숫자들은 그 자체로는 아무것도 증명하지 않습니다. 지금까지 쌓아 온 총량일 뿐, 최근 18일 동안 무엇을 했는지는 말해 주지 않습니다. 이 총량을 기준선으로 남기고, 9월 8일에 같은 방식으로 다시 재기로 했습니다.
세운 가설 — 숫자가 늘면 실력도 는다
세운 가설은 소박했습니다. 18일 뒤 다시 재서 저장소·커밋·코드 줄 수가 늘어 있고, 자동화 도구 여섯 항목(지침서·자동화 도우미·업무 매뉴얼·검사 프로그램·스크립트·정기 작업)도 고르게 늘어 있다면, 그 자체가 전반적으로 시스템이 나아졌다는 증거라고 봤습니다.
이 가설이 그럴듯했던 이유가 있습니다. 반복되는 업무일수록 우선순위를 정하는 기준은 반복 주기와 건당 소요 시간, 오류 비용을 곱한 값입니다. 자주 반복되고 오래 걸리고 실수 비용이 큰 일부터 자동화 대상으로 고르는 방식인데, 이 기준으로 여러 저장소에서 크고 작은 자동화를 동시에 진행하고 있었으니 여섯 항목이 비슷한 속도로 늘어날 거라고 자연스럽게 생각했습니다.
가설을 세운 시점에는 이 가정을 의심할 이유가 딱히 없었습니다. 매일 뭔가를 커밋하고 있었고, 새 저장소도 만들고 있었고, 자동화 도구도 계속 손보고 있었습니다. 문제는 이 가정을 실제 숫자로 확인해 본 적이 없었다는 데 있었습니다. b2b-consulting 저장소 하나만 해도 8월 21일 커밋 1,496개에서 9월 8일 2,133개로 637개가 늘었고, claude-os 저장소는 318개에서 880개로 562개가 늘었습니다. 이런 저장소별 숫자를 보면서도, 그 안에서 무엇이 늘었는지는 따로 들여다보지 않았습니다.
가설이 무너진 지점 — 왜 항목마다 증가율이 이렇게 달랐을까?
9월 8일, 같은 방식으로 다시 쟀습니다. 저장소는 42개에서 45개로 3개 늘었고, 누적 커밋은 5,608개에서 7,305개로 1,697개 늘었고, 전체 코드는 1,092,296줄에서 1,320,551줄로 228,255줄 늘었습니다. 겉으로 보면 가설이 맞아떨어지는 것처럼 보였습니다 — 세 항목 모두 늘었으니까요.
그런데 자동화 도구 여섯 항목을 하나씩 나눠 보니 이야기가 달라졌습니다. 지침서는 29개에서 31개로 2개, 계산하면 6.9% 늘었습니다. 자동화 도우미는 23개에서 27개로 4개, 17.4% 늘었습니다. 업무 매뉴얼은 60개에서 68개로 8개, 13.3% 늘었습니다.
반면 작업이 끝날 때마다 자동으로 도는 검사 프로그램은 22개에서 36개로 14개, 63.6% 늘었습니다. 반복 실행되는 스크립트는 210개에서 326개로 116개, 55.2% 늘었습니다. 정해진 시간마다 저절로 실행되는 정기 작업은 142개에서 184개로 42개, 29.6% 늘었습니다.
여섯 항목이 고르게 늘었다는 가설이 맞다면 증가율도 서로 비슷해야 했습니다. 실제로는 가장 크게 는 검사 프로그램(63.6%)과 가장 적게 는 지침서(6.9%) 사이에 9배 넘는 차이가 났습니다. 숫자가 늘어난 방향 자체가 균일하지 않았고, 그 방향이 무엇을 뜻하는지가 진짜로 확인해야 할 것이었습니다.
진짜 원인 — 지침서는 잊히고, 자동 검사 프로그램은 잊히지 않는다
원인은 지침서와 검사 프로그램이 일하는 방식 자체가 다르다는 데 있었습니다. 지침서는 사람이 매번 읽고 기억해서 지켜야 작동합니다. 저장소가 마흔 개를 넘고 하루에 여러 곳을 오가는 상황에서는, 아무리 잘 써 둔 지침이라도 그 순간 읽지 않으면 그대로 지나갑니다.
'이게 맞나'는 답할 수 없지만 '어떤 경우에도 이건 아니다'는 기계가 검사할 수 있고, 명세 없이도 돌고, 전 제품에 그대로 재사용된다.
검사 프로그램은 다릅니다. 한 번 만들어 두면 작업이 끝날 때마다 사람이 기억하는지와 무관하게 실행됩니다. 같은 문서는 판정 기준을 앞단에 기계가 읽는 형태로 적어 두라고도 합니다. 지침을 문장으로만 남기면 다음에 그 지침을 다시 읽을지는 그때그때 다르지만, 판정 기준을 코드로 옮겨 두면 실행될 때마다 똑같이 적용됩니다. 검사 프로그램이 지침서보다 9배 넘게 빠르게 늘어난 것은, 지침을 문장으로 늘리는 대신 이미 정해 둔 판정을 기계로 옮기는 작업에 더 많은 시간을 쓰고 있었다는 뜻이었습니다.
지금 재직 중인 회사(퀀팃투자자문)에서 맡고 있는 인공지능 도입 업무에서도 같은 방향의 변화가 있었습니다. 전자결재·법인카드 사용 내역을 모아 둔 장부를 다루는 그룹웨어 백오피스 감사 파이프라인은 담당자가 직접 적은 항목(적요)을 그대로 믿지 않고, 거래처·사업자번호·시각·금액처럼 변조하기 어려운 항목으로 교차 검증하는 3층 판정 구조로 설계했습니다. 최근 작업일 25일, 대상 파일 1,663건 규모입니다. 판정 기준을 사람의 재량이 아니라 코드로 고정한 자리입니다. 이 회사는 투자자문업을 하는 곳이라 사람이 몸으로 겪는 업무가 여전히 많고, 그 업무 중 반복되고 실수 비용이 큰 부분부터 이런 방식으로 옮기고 있습니다.
환급 처리 워크플로우 자동화에서도 파서·정규화·처리 대장 기록에 회귀 테스트를 붙여, 케이스 형식이 바뀌어도 조용히 어긋나지 않게 했습니다. 최근 작업일 32일, 대상 파일 1,689건 규모입니다. 둘 다 지침을 새로 쓰는 대신 이미 아는 판정을 코드로 고정하는 방향이었고, 이 방향이 정기 검사 프로그램과 스크립트가 지침서보다 훨씬 빠르게 늘어난 이유였습니다.
무엇을 먼저 기계에 넘길지, 어떻게 정했나?
모든 반복 작업을 한꺼번에 자동화 대상으로 올릴 수는 없었습니다. 대상을 고르는 기준은 감이 아니라 세 가지 숫자를 곱한 값이었습니다.
- 반복 주기 — 이 일이 얼마나 자주 돌아오는가
- 건당 소요 시간 — 한 번 처리하는 데 얼마나 걸리는가
- 오류 비용 — 놓쳤을 때 되돌리는 데 드는 비용이 얼마인가
세 값을 곱해 우선순위를 매기고, 값이 큰 일부터 먼저 손을 댔습니다. 자주 반복되고 오래 걸리고 놓치면 비싼 일일수록 사람이 매번 다시 판단하는 대신 기계에 넘기는 이득이 컸기 때문입니다.
자동화하기 전에는 그 일에 실제로 얼마나 시간이 드는지부터 먼저 기록했습니다. 체감이 아니라 기록으로 남겨야 나중에 개선 폭을 잴 기준이 생깁니다. 이 기록 없이 자동화부터 하면, 나중에 얼마나 나아졌는지 물어도 '빨라진 것 같다'는 인상밖에 남지 않습니다.
실제로 옮긴 사례 세 가지
이 기준으로 실제 회사 업무에서 세 가지를 기계로 옮겼습니다.
첫째, 환급 처리 워크플로우입니다. 환급 요청 메일 수신·케이스 정규화부터 전자결재 기안 작성·제출·승인 상태 확인·처리 대장 기록·문서번호 동기화까지 하나로 연결하고, 승인과 지급 실행만 사람이 남는 구조로 설계했습니다. 최근 작업일 32일, 처리 대상 파일 1,689건 규모이고 측정 구간은 2026년 6월 24일부터 9월 7일까지입니다.
둘째, 그룹웨어 백오피스 장부 자동 감사 파이프라인입니다. 그룹웨어 전 카테고리를 로컬로 미러링하고 전사 지출결의·법인카드 사용 내역 수만 건 규모를 자동으로 분석합니다. 담당자가 직접 적은 항목을 신뢰하지 않고 거래처·사업자번호·시각·금액 등 변조 불가 필드로 교차 검증하는 3층 판정 구조이고, 대상자별 상세 리포트를 자동으로 만듭니다. 최근 작업일 25일, 대상 파일 1,663건 규모입니다. 사람이 적은 설명 대신 시스템에 남는 흔적을 기준으로 삼았다는 점에서, 이 파이프라인도 판정을 지침이 아니라 코드로 고정한 사례입니다.
셋째, 광고 콘텐츠 검토에 쓰는 RAG 라우터입니다. 경량 모델이 먼저 걸러서 실제로 해당 콘텐츠에 적용될 규칙만 골라 주입하는 방식으로 바꾸자, LLM에 넣는 입력 토큰이 76%(427,000개에서 104,000개로) 줄고 총비용은 54% 줄었습니다. 이 결과는 감이 아니라 자동 평가로 확인했고, 골든 케이스 24개를 회귀 감시로 두어 배포할 때마다 판정이 흔들리지 않는지 확인합니다.
회귀 방어라는 원칙도 같은 방향입니다. 골든 케이스 회귀 감시를 배포 게이트(새 버전을 내보내기 전에 반드시 통과해야 하는 자동 확인 단계)로 운영해, 규칙이나 모델을 바꿔도 기존 판정이 깨지지 않는지 배포 전에 확인합니다. 사람이 매번 '이번에도 괜찮겠지'라고 판단하는 대신, 기존에 맞다고 확인한 판정 목록을 기준으로 기계가 매번 다시 확인하는 구조입니다.
9월 8일 재측정 — 자동 검사 프로그램 63.6%, 지침서 6.9%
18일 사이 늘어난 항목을 다시 정리하면 이렇습니다. 개인 코드 자산은 저장소 42개에서 45개로 7.1%, 누적 커밋 5,608개에서 7,305개로 30.3%, 전체 코드 1,092,296줄에서 1,320,551줄로 20.9% 늘었습니다.
자동화 도구는 지침서 6.9%, 업무 매뉴얼 13.3%, 자동화 도우미 17.4%, 정기 작업 29.6%, 스크립트 55.2%, 검사 프로그램 63.6% 늘었습니다. 가장 크게 는 세 항목(검사 프로그램·스크립트·정기 작업)은 전부 '판정을 기계가 실행하는' 쪽이고, 가장 적게 는 항목(지침서)은 '판정을 사람이 읽고 지키는' 쪽이었습니다.
이 결과는 처음 세운 가설을 정정하게 만들었습니다. '숫자가 고르게 늘면 실력이 늘었다는 뜻'이 아니라, '어느 방향으로 늘었는지가 실력이 는 방식을 보여준다'는 쪽이 더 정확한 설명이었습니다. 같은 18일이라도 지침을 늘리는 데 쓴 시간과 판정을 기계로 옮기는 데 쓴 시간은 남기는 흔적이 다릅니다.
새로 생긴 저장소 세 곳이 보여준 것
같은 18일 동안 저장소 세 개가 새로 생겼습니다. masters-db는 8월 26일 시작해 커밋 17개, 코드 623줄입니다. regcheck는 8월 21일 시작해 커밋 4개, 코드 1,534줄입니다. mobile-jarvis는 9월 6일, 그러니까 재측정 시점 이틀 전에 시작해 커밋 9개, 코드 37,939줄입니다.
mobile-jarvis 하나가 이틀 만에 쌓은 37,939줄은 이번 18일 동안 늘어난 전체 코드 228,255줄의 16.6%에 해당합니다. 코드 줄 수라는 지표가 이렇게 저장소 하나, 그것도 시작한 지 며칠 안 된 저장소 하나로 크게 흔들릴 수 있다는 뜻입니다. 새 프로젝트를 시작할 때 뼈대를 놓는 초기 며칠은 원래 코드 줄 수가 몰아서 늘어나는 구간이고, 그 뒤로는 증가 속도가 자연스럽게 느려집니다.
이 사실은 코드 줄 수 하나만으로 개선 여부를 판단하면 안 되는 이유를 한 번 더 보여줍니다. 커밋 수와 코드 줄 수는 여전히 유용한 신호지만, 그 신호가 어디서 왔는지 한 단계 더 들여다보지 않으면 새 저장소 하나가 만든 착시를 실력 향상으로 잘못 읽을 수 있습니다.
남는 한계 — 18일로는 증명하지 못하는 것
이 기록에는 밝히지 못한 부분이 있습니다. 지금 재직 중인 회사에서 진행하는 인공지능 도입 업무는 시스템 8개, 작업일 25일 규모지만, 시스템 이름과 경로는 공개 범위 밖이라 이 여덟 개 전부를 낱낱이 보이지는 못합니다. 이 글에서 구체적으로 다룬 세 가지(환급 워크플로우·그룹웨어 감사·RAG 라우터)는 그중 공개할 수 있는 일부일 뿐입니다.
18일이라는 관측 기간도 짧습니다. 증가율 차이가 이번 18일의 우연한 작업 배분 때문인지, 아니면 앞으로도 계속될 방향인지는 이번 한 번의 측정으로는 알 수 없습니다. 다음 기준선을 언제 다시 잴지는 아직 정하지 않았습니다. 관측 시점을 두 곳으로 늘리기 전까지는 이번 18일이 예외적인 구간이었는지 반복되는 흐름인지조차 구분할 근거가 없습니다.
증가율 차이가 방향은 보여줬지만 품질까지 증명하지는 않습니다. 검사 프로그램이 63.6% 늘었다고 해서 그 검사들이 전부 잘 만들어졌다는 뜻은 아닙니다. 실제로 양성 사례만 돌려 보고 '믿을 만하다'고 판단했다가 적대적 테스트에서 거짓 통과가 나온 경험이 있었던 만큼, 새로 늘어난 검사 프로그램도 각각 따로 검증이 필요합니다. 사내 품질 평가 원칙 문서는 이런 판정을 도메인을 아는 담당자 한 사람에게 맡기고, LLM 판정은 전문가 동의율이 64~68%에 그친다는 근거로 보조 역할에만 쓰라고 정해 두었습니다.
다시 확인하는 절차 자체도 무한정 믿을 수는 없습니다. 강한 모델일수록 '다시 봐도 문제없다'는 자기 확신이 오히려 정답률을 떨어뜨린다는 연구도 있습니다. 같은 연구에서는 강한 모델의 자기 수정 성공률이 16.7%로, 약한 모델의 26.8%보다 오히려 낮게 나왔습니다. 그래서 재검증은 사람의 재확인이나 테스트 결과 같은 외부 신호와 함께일 때만 의미가 있다고 봅니다.
측정 없이 인상만으로 판단하다 놓친 경험은 이 자리에도 있습니다. 챗봇 상담 자동 검수 기록도 검사 도구 하나를 만들고 나서, 정상 사례까지 같은 도구에 넣어봐야 도구 자체의 결함이 드러난다는 같은 문제를 다룹니다. 저장소·커밋 수 같은 자기 보고형 숫자를 어떻게 검증 가능한 형태로 바꿀지 궁금하다면 상담에서 이야기할 수 있습니다.