AI로 많이 만들었다. 그래서 정말 나아졌나?

AI를 활용하는 방법을 계속 만들어 왔다. 반복하는 업무를 스킬로 정리했고, 구현과 리뷰를 에이전트에게 나눠 맡겼고, AI가 근거를 바탕으로 판단하는 앱도 만들었다. 최근에는 인터뷰 준비와 기록 정리, 문제 정의와 기존 구현 검증까지 AI의 도움을 받았다.

그 과정에서 중요했던 결과 중에는 새 코드로 남지 않는 것도 있었다. 이미 있는 기능을 다시 만들지 않기로 한 판단, 흩어진 요구를 하나의 문제로 좁힌 과정, 모호한 디자인 가이드를 답할 수 있는 질문으로 바꾼 일이 그랬다.

그런데 최근에는 무엇을 만들었는지 설명하는 것보다 다음 질문에 답하는 일이 더 어렵다.

그래서 내 일이 정말 나아졌나?

예전보다 빨리 끝냈는지, 더 정확하게 판단했는지, 확인할 것이 줄었는지. AI가 없었을 때와 비교하면 어떤지. AI를 쓰더라도 지금 만든 스킬과 앱을 거치는 편이 일반적인 대화보다 나은지.

각각 다른 질문인데, 한동안은 무언가를 구현했다는 사실이 그 답을 대신해 주는 것처럼 느꼈다. 이제는 그 사이를 조금 더 구체적으로 확인하고 싶다. 특히 측정 도구의 점수가 일을 설명하는 데 그치지 않고, 어떤 일을 할지까지 바꾸기 시작한다면 무엇을 봐야 할까.

만든 것과 아직 확인하지 못한 것

Agent Skill Garden은 반복하는 업무의 절차와 판단 기준을 스킬로 정리한 저장소다. 요청에 맞는 절차를 선택하고, 변경의 영향을 확인하고, 결과를 검증하는 방식을 여러 에이전트 환경에서 이어 쓰려 했다. 처음 이 저장소를 만든 글에서도 도구가 바뀌어도 남는 업무 방식을 보존하고 싶다고 적었다.

이 구조 덕분에 무엇을 지키려는지는 파일로 설명할 수 있게 됐다. 다만 스킬이 설치되고 호출됐다는 사실만으로 판단이 좋아졌다고 말할 수는 없다. 잘못된 지적이 줄었는지, 중요한 문제를 더 찾았는지, 내가 확인하는 시간이 줄었는지는 다른 증거가 필요하다.

Career Radar는 이력서와 채용 공고를 받아 적합도를 판단하는 앱이다. 근거를 연결하고, 모델의 출력에 정책을 적용하고, 인용을 검증하고, 실패를 기록하는 구조를 만들었다.

여기서는 실제 모델을 실행한 평가 보고서까지 남겼다. 하지만 회고에는 일반 채팅에 같은 자료를 넣었을 때보다 나은지 비교하지 못했다고 썼다. 당시에는 평가 사례를 사람이 검토하는 일도 남아 있었다.

그 보고서는 구현한 장치가 어떻게 동작하는지 보여준다. 그 장치가 내 의사결정에 얼마나 도움이 됐는지는 여전히 열려 있다. 인용이 입력 문서의 한 구절과 연결되더라도, 그 구절이 결론을 충분히 뒷받침하는지는 따로 확인해야 한다.

두 프로젝트를 돌아보니 다음에 만들고 싶은 것도 조금 달라졌다. 판단을 생성하는 기능에 더해, 그 판단을 검토하고 고친 결과가 실제로 도움이 됐는지 확인하고 싶어졌다.

코드가 늘지 않아도 일이 앞으로 간 순간

최근에는 담당자 인터뷰와 운영 백로그에서 출발해 문제 후보를 정리했다. 나온 요청을 바로 구현 목록으로 옮기지 않고, 기존 기획 문서와 과제 상태, 실제 코드와 대조했다. 이미 있는 기능인지, 일부만 구현됐는지, 화면 수정에 앞서 데이터나 운영 정책을 확인해야 하는지 나눴다. AI는 자료를 연결하고 차이를 찾는 데 활용했고, 정리한 내용은 담당자에게 사실관계와 영향을 확인받는 과정으로 이어졌다.

이 과정의 결과는 문서 몇 장이라는 숫자보다 판단의 변화에 있었다. 새 기능으로 생각했던 요청을 기존 기능의 충족 여부를 확인하는 문제로 바꾸고, 단순한 화면 개선처럼 보였던 요구에서 API나 정책 합의가 먼저 필요한 부분을 구분했다. 바로 개발할 수 있는 일과 아직 시작하면 안 되는 일을 가려내는 데 도움이 됐다.

그렇다고 문서를 만들었다는 사실만으로 시간을 절약했다고 말할 수는 없다. 검토한 내용이 실제 우선순위나 실행 범위에 반영됐는지, 나중에 잘못된 판단으로 드러나지는 않았는지 확인해야 한다. 다만 이 기여를 보려면 처음부터 코드 외의 증거도 읽어야 한다.

자료를 공유한 뒤 받은 답도 중요했다. 한 담당자는 내가 만든 분석 자료를 활용해 보겠다고 하면서, 자신이 정말 알고 싶었던 것은 그다음 단계의 행동이라고 짚어줬다. 그 피드백을 받고 이미 확인할 수 있는 정보, 설정으로 해결할 수 있는 부분, 별도 개발이 필요한 부분을 더 좁혀 정리했다. 자료를 많이 모았다는 사실보다 상대의 질문에 가까워진 과정이 더 의미 있었다. 활용 의사를 들은 것과 실제로 반복 사용하거나 시간을 절약한 것까지 확인한 것은 구분해 두려 한다.

여러 화면의 표시 규칙을 확인했던 작업도 비슷하다. 가이드와 실제 화면의 차이를 정리해 확인할 수 있는 질문으로 바꾸고, 합의한 기준으로 수정한 뒤 담당자의 확인을 받았다. AI는 자료 대조와 검증 정리를 도왔다. 최종 코드에는 수정된 값이 남지만, 그 값을 정하기 위해 모호함을 줄인 과정까지 같은 비중으로 보이지는 않는다.

AI가 도움이 됐다고 느낀 부분에는 이런 자료 대조와 질문 정리도 있다. 동시에 내 검증 과정에서는 반복 실패와 잘못 짚은 원인 때문에 시간이 더 들기도 했다. 그 둘을 함께 봐야 한다. AI를 썼다는 이유로 모든 조사를 성과로 부를 수도 없고, 코드로 남지 않았다는 이유로 기여에서 빠뜨릴 수도 없다.

내가 회의감을 느끼는 지점은 여기다. 문제를 좁혀 구현할 일을 줄이는 기여보다, 무엇이든 구현해 산출물을 남기는 일이 더 잘 보인다면 다음에는 어떤 일을 고르게 될까?

Fieldguide를 보며 생각한 판단의 단위

이 고민 중에 감사·자문 업무를 위한 AI 플랫폼인 Fieldguide를 살펴봤다.

공개된 Agent Knowledge 설명에 따르면, 이전 감사의 유사한 작업 문서를 검색해 현재 작업의 문맥으로 제공한다. 과거에 어떤 증거를 충분하다고 봤는지, 어떤 방식으로 기준과 자료를 비교했는지가 다음 작업에 쓰인다. 결과는 사람이 검토할 초안으로 다룬다.

내가 흥미롭게 본 것은 경험을 다음 판단에 연결하는 방식이었다. 내 스킬에도 경험에서 나온 규칙은 들어 있다. 그렇다면 규칙과 과거 사례를 제공한 뒤, AI가 실제로 덜 틀리고 사람이 덜 고치게 되는지 확인할 수 있지 않을까.

물론 자료를 더 넣으면 확인할 양만 늘어날 수도 있다. 과거 사례가 현재 상황에 맞지 않을 수도 있다. 그래서 이 아이디어 역시 구현하기 전에 무엇을 개선으로 볼지부터 정해야 한다.

위브 같은 도구가 답해 줄 수 있을까

엔지니어링 활동과 AI 사용을 연결해 보여주는 서비스로 Weave가 있다. 공개적으로 제공되는 상용 서비스이므로, 제품이 설명하는 지표와 측정 방식은 공개 자료를 바탕으로 살펴볼 수 있다. 여기서는 특정 조직의 리포트나 개인 점수를 다루지 않는다.

공식 설명에서 Output은 PR의 범위와 복잡도를 분석해 숙련된 엔지니어가 수행하는 데 필요한 일을 추정한 값이다. 코드 줄 수나 PR 개수만 세는 방식보다 작업의 차이를 반영하려는 접근이다. AI 사용과 비용, 리뷰 과정, 리버트와 코드 변경 추이도 함께 다룬다. 공개 보고서는 고객사의 개발 도구와 AI 사용 기록에서 수집한 데이터를 바탕으로 한다.

이런 도구의 장점은 여러 곳에 흩어진 기록을 연결해 준다는 데 있다고 본다. 산출량이 늘었는데 리뷰가 밀리는지, AI 비용이 늘어난 구간에서 결과도 달라졌는지 살펴볼 출발점이 생긴다.

하지만 Output이 올랐다는 것을 그대로 생산성이 올랐다고 읽으려면 몇 가지 질문이 더 필요하다.

추정된 작업량은 실제 투입 시간과 얼마나 맞을까. 그 기간에 맡은 일의 종류가 달라지지는 않았을까. 산출물을 늘리는 동안 확인과 재작업도 늘지는 않았을까. 코드로 남지 않은 조사, 설계, 문제 예방은 어디에서 확인할 수 있을까.

공개 서비스라는 사실만으로 측정 기준이 보편적인 표준이 되지는 않는다. 나 역시 그 추정의 정확성을 직접 검증한 것은 아니다. 같은 산식으로 모든 작업을 평가하는 일관성도 중요하지만, 그 산식이 내가 알고 싶은 결과를 얼마나 잘 설명하는지는 따로 봐야 한다.

더구나 AI 사용이 많은 사람의 Output이 높다고 해도, 그 차이 전체가 AI 때문에 생겼다고 할 수는 없다. 숙련도, 업무 배정, 프로젝트 단계, 협업 환경이 함께 작용할 수 있다. AI를 자주 쓰는 사람에게 원래 산출물을 만들기 쉬운 일이 더 많이 배정됐을 가능성도 있다.

공개 설명만으로 위브의 모든 기능이 비코딩 기여를 전혀 다루지 못한다고 단정할 수는 없다. 내가 문제 삼는 것은 PR 중심의 Output을 일 전체의 가치로 읽는 방식이다. 인터뷰로 개발 범위를 줄인 결정과 합의를 돕기 위한 자료 대조는 그 점수만으로 충분히 설명되지 않는다.

그래서 지금은 위브 같은 도구를 변화의 단서를 찾는 데 사용하고 싶다. 점수가 움직인 구간에서 실제로 어떤 일이 있었는지 확인하는 방식이다. 개인 순위를 매기거나 AI의 기여율을 확정할 때는 그보다 더 많은 근거가 필요하다.

점수를 올리는 일이 먼저가 되면

다음과 같은 상황을 생각해 보자. 테스트를 추가할 일을 고르면서, 어떤 회귀를 막을지보다 산출량 점수를 얼마나 올릴 수 있을지를 먼저 따진다. 이때 나를 불편하게 하는 것은 테스트가 main 브랜치에 들어간다는 사실이 아니다. 테스트는 당연히 제품 코드와 함께 관리할 수 있고, 부족했던 테스트를 보강하는 것은 가치 있는 일이다.

문제는 필요성을 판단하는 순서가 바뀌는 것이다. 예방할 실패를 정한 뒤 테스트를 만드는 과정에서, 점수를 만들기 위해 추가할 코드를 찾는 과정으로 옮겨간다. 점수에 관심을 가졌다는 이유만으로 결과물이 쓸모없다고 단정할 수는 없다. 다만 왜 그 일을 골랐고 무엇을 검증했는지 다시 확인할 이유는 생긴다.

여기서 특정 테스트가 위브의 실제 점수를 올린다고 검증한 것은 아니다. 제품이 해당 변경을 어떻게 채점하는지와, 사람이 점수를 예상하며 행동하는지는 구분해야 한다. 후자의 믿음만으로도 작업의 우선순위는 달라질 수 있다. 기록을 다시 살펴보니 측정에서 빠지는 활동을 확인하고, 기여가 누락되지 않도록 작업 방식을 맞추는 데에도 대화와 시간이 쓰였다. 측정은 결과를 읽는 도구이면서, 사람에게 무엇을 남겨야 하는지 알려주는 신호가 되기도 한다.

여기에는 서로 다른 숫자도 섞이기 쉽다. AI 사용량, 작업 산출량, 테스트 커버리지, 개발 절차를 따랐는지 평가하는 점수는 같은 것이 아니다. 테스트를 추가하면 어떤 평가에 도움이 된다는 말만으로 특정 제품의 생산성 점수가 실제로 올랐다고 주장해서는 안 된다.

실제 테스트 추가 사례도 이 관점에서 다시 읽어봤다. 페이지에 메뉴와 목록이 정해진 순서로 조립되는지 고정하는 테스트가 있었다. 진입 이벤트나 필수 영역 누락을 막는 역할은 있다. 다만 요청의 배경이 “이 부분을 직접 검사하는 테스트가 없다”에서 끝난다면, 왜 다른 문제보다 지금 먼저 해야 하는지는 여전히 설명되지 않는다.

다른 페이지 테스트에는 재조회 실패 때 기존 내용이 유지되는지 확인하는 검증과 화면 영역의 전체 순서를 고정하는 검증이 함께 있었다. 전자는 고객이 보던 내용이 사라지는 실패와 연결하기 쉽다. 후자는 순서 자체가 중요한 요구사항인지, 곧 바꿀 구성인지에 따라 가치가 달라진다. 같은 파일 안에서도 줄이려는 위험과 변경 비용이 다르다.

금액 부호나 부분 취소 후 남은 수량처럼 고객에게 잘못 표시되면 문제가 되는 규칙을 검사하는 사례도 있었다. 이런 테스트까지 산출량을 위한 일로 묶을 수는 없다. 살펴본 일부 사례만으로 전체 테스트의 효용이나 작성자의 동기를 판단할 수도 없다.

그래서 내 질문은 “이 테스트는 통과하는가”에서 한 단계 앞에 있다. 왜 지금 이 위험을 줄여야 하는가? 이 테스트가 이후의 변경과 확인을 얼마나 쉽게 만드는가? 테스트가 없다는 사실은 점검할 단서이지만, 그 자체가 투자 우선순위는 아니다.

이 문제는 AI 이전부터 있었다. Google의 Code Coverage Best Practices는 높은 커버리지가 테스트의 품질을 보장하지 않으며, 숫자를 맞추기 위한 복사·붙여넣기나 낮은 가치의 테스트가 유지보수 부담을 만들 수 있다고 설명한다. 커버리지는 실행된 코드를 알려주지만, 실패를 제대로 검출했는지까지 보장하지 않는다.

테스트에는 작성 이후의 비용도 남는다. 요구사항이 바뀌면 기대값을 고쳐야 하고, 실패 원인을 읽고, 테스트를 유지할지 바꿀지 판단해야 한다. AI가 초안을 쉽게 만들어 준다고 이 비용까지 사라지는 것은 아니다.

빠르게 변하는 제품에서는 그 차이가 더 크게 느껴질 수 있다. 그래도 요구사항 변경 때문에 테스트를 수정한다는 이유만으로 낭비라고 할 수는 없다. 이전 계약을 의도적으로 바꾸는 순간을 확인하는 일이기도 하다. 반면 외부에서 기대하는 동작은 그대로인데 함수 분리나 내부 호출 순서 변경마다 여러 테스트를 고쳐야 한다면, 테스트가 보호하려는 동작보다 내부 구현에 지나치게 의존하는 것은 아닌지 살펴봐야 한다.

Software Engineering at Google의 단위 테스트 장은 요구사항 변경과 순수한 리팩터링을 구분한다. 테스트가 요구사항을 설명하면서 내부 구현 변경에는 견디도록 설계하자는 기준이다. Google의 Change-Detector Tests Considered Harmful도 현재 구현을 다른 형태로 복제해 놓고 변경마다 함께 수정해야 하는 테스트의 비용을 지적한다.

가령 상품 목록의 기본 정렬이 추천순에서 최신순으로 바뀌었다고 해 보자. 기본 정렬을 검증하는 테스트를 새 요구사항에 맞추는 것은 필요한 변경이다. 같은 정렬 결과를 유지하면서 내부 훅을 나눴는데 훅 호출 횟수와 중간 상태를 확인하는 테스트가 한꺼번에 깨진다면, 그 세부사항 자체가 요구사항인지부터 확인하고 싶다. 구현을 그대로 따라 쓴 기대값이라면 현재의 오류도 함께 정답으로 고정할 수 있다.

내가 테스트에 기대하는 역할은 이런 것이다. 실패했을 때 어떤 약속을 어겼는지 알 수 있고, 무엇은 바꿔도 되는지 판단하는 데 도움이 되는 것. 테스트 이름과 기대값만 봐서는 지켜야 할 이유를 알 수 없고, 코드를 고칠 때마다 기계적으로 같은 수정을 해야 한다면 그 가치는 다시 검토할 필요가 있다.

그래서 테스트를 추가할 때는 보호할 동작과 줄일 위험, 나중에 변경하거나 걷어낼 판단 기준을 함께 생각하고 싶다. 탐색 중인 화면 구조는 자주 달라져도 개인정보 노출이나 중복 처리 방지 같은 요구는 계속 중요할 수 있다. 제품이 빠르게 변한다는 이유만으로 테스트를 줄이기보다는, 오래 보호할 계약과 변하는 세부사항에 서로 다른 검증 방식을 선택하는 편이 맞겠다.

측정도 생성 시점에서 끝내고 싶지 않다. 이후 변경에서 어떤 회귀를 알려줬는지, 요구사항 수정과 무관한 실패를 처리하느라 시간을 얼마나 썼는지, 실제로 검토나 수동 확인을 얼마나 덜게 했는지를 표본으로 남길 수 있다. 결함을 아직 잡은 적이 없다는 것만으로 예방 가치를 0으로 보지는 않되, 테스트 개수와 추가 코드량만 보고 향후 유지보수 비용을 빼놓은 채 이득을 계산하지는 않으려 한다.

Goodhart의 법칙으로 알려진 문제도 이와 연결된다. Marilyn Strathern은 1997년 대학 평가를 다룬 논문에서 측정값이 목표가 되면 좋은 측정값으로서의 역할을 잃는다고 표현했다. Donald Campbell 역시 1976년 글의 재수록본에서 정량 지표가 의사결정에 강하게 사용될수록 그 지표와 측정 대상의 활동이 왜곡될 압력을 받는다고 설명한다.

Holmström과 Milgrom의 1991년 다중 과업 인센티브 연구는 이 고민의 다른 면을 설명한다. 한정된 시간과 주의를 나눠 써야 하는 여러 일 중 측정하기 쉬운 일에 강한 보상이 붙으면, 측정하기 어려운 일에서 노력이 이동할 수 있다는 모형이다. 여기서 가져오는 것은 특정 현장의 인과관계가 아니라 일 선택을 이해하는 관점이다. 점수가 정확하게 계산되더라도, 점수 밖의 중요한 일을 소홀히 하게 만드는 평가 방식일 수 있다.

이것을 모든 측정이 실패한다는 법칙처럼 받아들이고 싶지는 않다. 내가 가져오고 싶은 질문은 구체적이다. 이 숫자를 높게 받아야 하는 사람이 원래 목적과 상관없이 취할 수 있는 행동은 무엇인가? 지표를 도입할 때 그 질문도 함께 해야 한다.

AI는 코드와 문서의 생산 비용을 낮출 수 있다. 내 가설은 그만큼 점수에 유리해 보이는 산출물을 추가하는 비용도 낮아질 수 있다는 것이다. 이 가설을 특정 제품이나 사람에 대한 확정된 평가로 쓰지는 않으려 한다. 다만 지표가 좋아질 때 결과물의 필요성도 함께 살펴봐야 할 이유로는 충분하다.

오래된 측정 문제와 최근 AI 연구가 만나는 곳

SPACE 프레임워크는 개발자 생산성을 하나의 활동량이나 한 차원의 지표로 설명할 수 없다고 본다. 만족도와 웰빙, 성과, 활동, 소통과 협업, 효율과 흐름이라는 여러 차원을 함께 다룬다. 내게는 지표를 다섯 배로 늘리라는 이야기보다, 지금 보고 있는 숫자 밖에도 일이 있다는 경고로 읽힌다.

DevEx 연구는 피드백 루프, 인지 부하, 몰입 상태에 주목하고 시스템 데이터와 개발자의 경험을 함께 볼 것을 제안한다. AI가 답을 빨리 내더라도 그 답을 이해하고 의심하고 수정하는 부담이 커질 수 있다. 실행 기록과 함께 어떤 확인이 가장 힘들었는지 물어볼 이유가 여기 있다. 다만 편해졌다는 체감 자체를 절약 시간으로 환산하지는 않아야 한다.

DORA의 소프트웨어 전달 지표는 처리 속도와 함께 변경 실패와 재작업을 본다. 적용 단위도 하나의 애플리케이션이나 서비스가 적합하다고 설명한다. 서비스의 전달 성과를 개인의 코드 생산량 순위로 바로 바꿔 읽기 어려운 이유다.

AI의 효과를 직접 비교한 연구도 읽어봤다. METR의 2025년 실험에서는 익숙한 오픈소스 저장소에서 일하는 개발자 16명이 246개 작업을 수행했고, 당시 AI 사용을 허용한 조건에서 완료 시간이 19% 더 길었다. 참가자들은 실험 후에도 AI가 자신을 더 빠르게 했다고 추정했다. 체감과 측정이 어긋날 수 있다는 사례지만, 이를 현재의 모든 AI 도구와 개발자에게 적용할 수는 없다.

특히 2026년 2월 후속 글을 함께 읽어야 한다. METR은 AI 없이 일하기를 원하지 않는 개발자가 참여를 피하거나 일부 작업을 실험에 제출하지 않는 선택 효과, 에이전트 병렬 사용 시 시간 측정 문제 때문에 실험 설계를 바꾸고 있다고 밝혔다. 이전 실험에서 19% 더 느려졌다는 결과만 골라 인용해서는 지금 상황을 설명할 수 없다.

이 자료들에서 얻은 것은 특정 점수나 연구를 최종 답으로 삼을 수 있다는 확신이 아니었다. 무엇을, 누구에게서, 어떤 조건으로 측정했는지를 결과와 함께 읽어야 한다는 기준이었다.

빨라진 일과 더 하게 된 일을 나눠 보기

최근 자료 중 내 고민에 특히 가까웠던 것은 METR의 2026년 5월 연구 노트 Task Substitution and Uplift였다. 이 글은 기존에 하던 일의 속도 향상, AI를 사용할 수 있게 된 뒤 선택한 일의 속도 향상, 실제로 만들어 낸 가치의 증가를 구분한다.

이 구분을 내 프로젝트에 적용하면 질문이 더 날카로워진다. AI 덕분에 예전에는 엄두를 내지 못했던 앱을 만들었다면 분명 새로운 가능성이 열린 것이다. 하지만 직접 만들었으면 오래 걸렸을 것이라는 추정만으로 그 시간 전부를 절약했다고 계산하기는 어렵다. AI가 없었으면 그 앱을 만들지 않고 다른 중요한 일을 했을 수도 있다.

그래서 새로 가능해진 일을 무가치하다고 분류할 필요도, 모두 시간 절약으로 환산할 필요도 없다. 새 도구를 만들었다면 실제로 다시 쓰였는지, 어떤 결정을 바꿨는지, 배운 것이 다른 작업에 쓰였는지를 별도로 볼 수 있다.

여기에는 서로 다른 두 힘이 있다. AI 때문에 유용한 일의 비용이 낮아져 더 할 수도 있고, 평가 점수에 유리해 보여서 그 일을 더 할 수도 있다. 두 경우 모두 산출물이 늘지만, 그 이유와 가치를 확인하는 질문은 달라야 한다. METR의 노트는 이 구분을 생각할 이론적 틀이고, 특정 현장에서 어느 쪽이 일어났는지를 증명한 자료는 아니다.

내가 줄인 시간이 다른 사람에게 옮겨간 것은 아닐까

AI 효과를 생각할 때 가장 먼저 떠오르는 것은 작성 시간이다. 코드나 문서가 빨리 나오면 절약이 눈에 보인다. 결과를 읽고, 맞는지 확인하고, 잘못된 부분을 설명하는 시간은 그 뒤에 붙는다.

가상의 예로 직접 리뷰할 때 60분이 걸렸다고 해 보자. AI를 쓴 뒤 코드를 읽는 시간은 20분으로 줄었지만, 지적의 타당성을 확인하고 오탐을 반박하는 데 50분이 들었다면 총 70분이다. 반대로 시간이 같아도 이전에 놓치던 중요한 버그를 발견했다면 그 사용은 가치가 있을 수 있다.

예전 겉멋 AI 글에서는 발신자가 아낀 시간이 수신자의 해석과 재질문 비용으로 넘어갈 수 있다고 적었다. 이번에는 그 질문을 내가 만든 도구에도 적용해 보고 싶다.

DORA의 분석도 AI로 초기 생성을 빠르게 해도 절약한 시간이 감사와 검증에 다시 쓰일 수 있다고 설명한다. 생성 단계만 보면 놓치는 일이 있다는 뜻이다.

그래서 사람의 투입 시간과 작업이 끝나기까지의 경과 시간을 구분해 보려 한다. 내가 직접 확인한 20분, 다른 사람이 재검토한 15분, 답을 기다린 하루는 서로 다른 비용이다. 에이전트 여러 개가 동시에 실행됐다고 사람의 시간을 그 수만큼 절약했다고 계산할 수도 없다.

지표를 더 고르기 전에, 어떤 결정을 할지 정하기

지금 내게 필요한 결정은 어떤 일에 AI를 계속 쓰고, 어떤 산출물은 줄이며, 어디에 사람의 시간을 더 써야 하는지다. 구현과 리뷰뿐 아니라 조사와 문제 정의에서도 다음 네 가지를 함께 보고 싶다. 아래 표는 앞의 연구들을 참고해 내 실험에 맞게 고른 기록 항목이며, 검증된 새 표준을 제안하는 것은 아니다.

업무별로 보면 기록할 증거는 더 구체적이다.

짧은 사례 기록이면 충분하다. 어떤 판단이 바뀌었는지, 근거와 확인자는 누구인지, 다음 작업에서 다시 문제가 생겼는지 남긴다. 기록을 잘 쓰는 사람이 유리한 또 다른 평가표가 되지 않도록, 별도 보고서를 늘리기보다 기존 작업 기록과 담당자의 확인을 연결하고 싶다.

측정 단위는 업무에 따라 달라질 것이다. Career Radar라면 근거를 확인한 뒤 공고를 검토할지 보류할지 결정하는 데 도움이 됐는지가 중요하다. 최종 합격이나 불합격에는 다른 요인이 많으므로 그것만으로 적합도 판단의 정답을 정하기는 어렵다.

Garden의 리뷰 스킬이라면 중요한 결함을 놓치지 않으면서 지적을 확인하는 부담이 줄었는지가 먼저다. AI의 설명이 길거나 자신 있어 보인다는 것은 별도의 품질 근거로 세지 않으려 한다.

오류율을 적을 때도 분모가 필요하다. 알려진 중요한 결함 몇 개 중 몇 개를 놓쳤는지, 잘못된 지적 몇 개 중 몇 개를 수용했는지 남겨야 한다. 자연스럽게 발생한 PR에서는 놓친 결함 전체를 알기 어려우므로, 정답을 검토한 평가 사례에서 얻는 수치와 실제 사용 중 관찰한 수치를 구분해야 한다.

비용도 당장 하나의 금액으로 환산할 필요는 없을 것 같다. 사람의 시간, 모델 비용, 오류와 실패를 각각 남겨 두고 무엇을 얻고 무엇을 더 부담했는지 보고 싶다. 속도를 조금 얻는 대신 중요한 문제를 더 놓친다면 그 차이를 평균 점수 안에 감추고 싶지 않다.

여러 지표를 붙인다고 점수 최적화가 사라지지는 않을 것이다. 그래서 처음에는 개인별 목표 점수로 쓰지 않고, 작업 방식의 전후를 이해하는 데 쓰려 한다. 검토 시간을 줄였다면 놓친 문제도 같이 보고, 오류가 줄었다면 보류와 미완료가 늘지는 않았는지 같이 본다. 테스트 개수보다 일부 테스트가 실제로 어떤 실패를 검출하는지 확인하는 식으로 숫자와 사례를 연결하려 한다.

그리고 실행 전에 그 작업을 하는 이유와 완료 조건을 짧게 남기고 싶다. AI 때문에 새로 가능해진 일은 따로 표시한다. 나중에 산출물의 양만 보고 원래 중요했던 일인 것처럼 해석하는 것을 조금이라도 줄이기 위해서다. 기록을 남기는 데 든 시간도 측정 비용에 포함한다. 테스트를 추가하는 작업이라면 병합 직후뿐 아니라 다음 요구사항 변경이나 리팩터링 이후에도 돌아볼 시점을 정해 두고 싶다.

위브를 포함한 관측 도구에도 같은 기준을 적용할 수 있다. 수치가 움직였을 때 작업 사례를 확인하고, 유지·변경·중단 중 어떤 결정을 했는지 남기는 것이다. 정기적으로 봐도 아무 결정에 쓰이지 않는 지표라면 계속 수집할 이유부터 다시 생각해 볼 수 있다.

다음에는 실제 작업 몇 건부터

새 평가 앱을 만들기 전에 최근의 문제 정의, 요구사항 확인, 테스트 추가를 몇 건씩 돌아보려 한다. 시작할 때 무엇이 불분명했는지, AI가 무엇을 도왔는지, 사람이 어디를 고쳤는지, 결과로 어떤 결정이 바뀌었는지 같은 형식으로 남기는 것이다. 다음 관련 변경에서 그 결과가 다시 쓰였는지도 확인하고 싶다.

이런 회고만으로 AI의 인과적 효과나 생산성 향상률을 계산할 수는 없다. 대신 무엇을 더 관찰해야 하는지, 어떤 일이 점수에는 남고 어떤 일이 빠지는지 확인할 수 있다. 테스트라면 회귀 오류를 검출한 이득과 요구사항 변경에 맞춰 테스트를 수정하거나 간헐적인 실패를 처리한 비용을 함께 본다. 조사라면 합의나 우선순위에 쓰이지 않은 문서도 결과에 포함한다.

반복 가능한 판단 업무가 드러나면 그때 비교 실험을 할 수 있다. 기존 방식, 기본 AI, Garden 스킬을 적용한 AI를 비교하되, 같은 사람이 같은 답을 기억하는 효과를 피하도록 비슷한 난도의 서로 다른 사례를 배정한다. 판단 기준을 먼저 검토하고, 스킬을 고친 사례와 마지막 평가 사례를 분리하며, 모델·입력·스킬 버전을 남긴다. 작은 표본의 결과는 그 조건 안에서만 해석한다.

아직 이 비교를 실행한 것은 아니다. 우선 실제 일이 어떻게 달라졌는지부터 기록하고, 계속 필요한 확인 과정이 드러나면 도구로 옮기려 한다.

AI로 실제 도움이 되는 일을 하고 싶다

지금까지 만든 프로젝트에서 배운 것은 많다. 최근 인터뷰와 문제 정리, 요구사항을 확인하는 과정에서도 AI를 활용했다. 그 과정에서 느낀 도움을 구체적인 근거로 확인하고, 다음 문제를 해결하는 데에도 AI를 활용하고 싶다.

매번 같은 자료를 찾아 헤매는 시간을 줄이거나, 자꾸 놓치는 문제를 일찍 발견하거나, 복잡해서 미뤄 두었던 일을 끝낼 수 있게 돕는 것. 꼭 크고 새로운 서비스를 만들 필요는 없다. 누가 어디에서 불편을 겪고 있는지 듣고, 그중 AI로 덜어낼 수 있는 일을 하나 찾아 끝까지 해결해 보고 싶다.

직접 써 본 사람이 다음에도 다시 찾는지, 확인할 일이 줄었는지, 내가 편해진 만큼 다른 사람에게 부담이 넘어가지는 않았는지까지 보고 싶다. 도움이 됐다면 왜 그랬는지 남기고, 기대와 달랐다면 고치거나 멈출 수 있었으면 한다. 만드는 시간뿐 아니라 쓰고 유지하는 시간까지 책임지는 것도 그 일의 일부일 것이다.

지표를 고민하는 이유도 여기에 있다. 내가 들인 노력과 만든 결과물이 실제로 어디에 도움이 됐는지 알고 싶다. 다음 글에는 무엇을 만들었는지에 더해, 누가 어떤 일을 조금 더 수월하게 할 수 있게 됐는지도 적을 수 있으면 좋겠다.

코드를 더하는 날도, 만들지 않아도 될 일을 찾아내는 날도 있을 것이다. 어느 쪽이든 누군가의 불편이 줄고 일이 앞으로 갔는지 설명할 수 있었으면 한다.

AI를 활용해서 그런 진짜 일을 계속하고 싶다. 내가 고르는 일이 점수에 잘 보이는 일로만 좁아지지 않았으면 한다.