기술부채보다 먼저 찾아온 인지부채와 의도부채

처음 목표는 단순했다. 제품을 만드는 사람들이 반복적인 사용자 문의 조사에 쓰는 시간을 줄이고 싶었다.

문의가 들어오면 담당자는 생각보다 많은 맥락을 다시 꺼내야 한다. 어떤 기능과 관련된 문의인지, 로그에 무엇이 남아 있는지, 예전 문의 중 참고할 만한 것이 있는지 살펴봐야 한다. 하나하나는 크게 어렵지 않은데 매번 반복되니 비용이 된다. 제품을 만드는 사람은 결국 판단하고 구현해야 하는데, 그 전에 흩어진 정보를 뒤지는 시간이 계속 끼어든다.

그래서 내부 사용자를 위한 작은 AI 에이전트를 만들기 시작했다. 제품 맥락과 로그, 과거 문의, 이미 해결된 사례를 함께 살펴보고 필요한 정보를 먼저 모아주는 도구였다. 제품을 만드는 사람이 더 중요한 판단과 구현에 시간을 쓸 수 있게 하는 것이 목표였다.

초기 사용자 검증에서 받은 피드백은 꽤 긍정적이었다. 실제로 써본 사람들은 이전보다 조사 시간이 줄었다고 했고, 귀찮은 정보를 대신 모아준다는 점에서 만족했다. 사용자가 느끼는 불편 하나는 분명히 줄이고 있었다. 사용자 관점에서는 가치가 있었다.

그런데 내부 정량 평가는 달랐다. 기준 평가셋으로 에이전트 성능을 측정했더니 로그를 읽고 해석하는 부분에서 점수가 낮게 나왔다. 내부 사용자를 위한 도구였지만 내부 평가 기준에서는 좋은 점수를 받지 못했다. 정성 피드백과 정량 평가 사이의 간극을 해석하는 시간이 길어지면서, 다음 단계로 넘어가는 판단도 함께 늦어졌다.

정성 피드백과 정량 평가는 서로 다른 질문에 답한다. 문제는 둘 중 하나를 고르는 것이 아니라, 그 차이를 해석할 언어가 있는지였다.

이때부터 이상한 감각이 들었다. 우리는 제품을 더 좋게 만들고 있는 걸까, 아니면 평가 점수를 올리는 방향으로만 움직이고 있는 걸까.

정량 평가가 틀렸다는 말은 아니다. 로그를 잘못 읽는 에이전트를 그대로 둘 수는 없다. 사용자가 놓친 맥락을 대신 찾아주는 도구가 잘못된 근거로 그럴듯한 답을 내놓는 순간 신뢰가 무너진다. 내부 도구일수록 사용자는 빠르게 신뢰하거나 빠르게 포기하고, 한두 번 엉뚱한 근거를 가져오면 다시 직접 로그를 보게 된다.

사용자는 시간이 줄었다고 말했고, 평가는 로그 해석이 부족하다고 말했다. 정성 평가는 “사용자가 이 제품에서 실제로 가치를 느끼는가?”에 답하는 질문이고, 정량 평가는 “우리가 중요하다고 정의한 능력을 안정적으로 수행하는가?”에 답하는 질문이다. 두 평가는 서로를 대체하지 않는다. 둘을 함께 해석하는 언어가 없으면 팀은 한쪽으로 쏠린다. 이번에는 점수가 낮다는 사실이 제품의 전체 가치를 덮어버렸다. 정성 피드백만 믿었다면 위험한 결함을 놓치는 길도 있었다.

처음에는 로그 조사 방식을 고치면 해결될 줄 알았다. 에이전트가 로그를 더 잘 읽고 필요한 정보를 더 잘 가져오게 만들면 된다고 봤고, 그런 개선이 필요한 것도 맞았다. 그런데 파고들수록 기능 밖의 문제가 더 크게 다가왔다. 로그 필드의 신뢰 범위, 제품 상태의 의미, 도메인 용어의 해석처럼 어디에도 문서로 남아 있지 않은 판단들이었다. 에이전트가 알아야 하는 것은 코드 몇 줄이나 프롬프트 몇 문장이 아니라, 제품을 둘러싼 운영 맥락 전체에 가까웠다.

이때부터 문제를 부채로 보기 시작했다.

기술부채는 비교적 익숙하다. 빠르게 만들기 위해 구조화나 테스트를 미루고 나중에 갚아야 할 비용을 남기는 것이고, 일정이 촉박하거나 요구사항이 변하는 중이라면 어느 정도는 불가피하다. 코드에 흔적이 남기 때문에 테스트가 부족하거나 특정 모듈이 과하게 커지는 식으로 눈에 보이기도 한다.

기술부채는 코드에 비교적 잘 드러난다. 하지만 인지부채와 의도부채는 흩어진 맥락과 사라진 결정 이유 속에 남는다.

인지부채는 조용하다. 제품 맥락과 로그, 도메인 용어가 저마다 다른 곳에 있고 판단 기준은 사람들 머릿속에 남아 있다. 사람이 직접 조사할 때는 이 누락을 감으로 메운다. “이 케이스는 아마 저 기능 때문일 것이다”, “비슷해 보이지만 저 문의와는 원인이 다르다” 같은 판단이다. 에이전트에게 일을 맡기려면 이 감의 일부를 구조로 바꿔야 한다. 어디를 봐야 하는지, 무엇을 근거로 삼아야 하는지, 모를 때는 모른다고 답하도록 남겨야 한다. 암묵지를 명시지로 바꾸는 이 과정에서 제품 안에서 당연하게 여겼던 용어와 특정 사람이 알고 있던 예외 케이스가 부채처럼 나타난다.

의도부채는 왜 그렇게 하기로 했는지가 남아 있지 않은 상태다.

정성 평가와 정량 평가가 다른 말을 하고 있을 때 팀에 필요한 것은 판단의 기준이었다. 평가 기준의 우선순위, 사용자 피드백을 신뢰하는 범위, 다음 단계로 넘어가는 조건, 지금 미루고 감수하는 위험. 이 기준이 선명하지 않으면 팀은 계속 움직이지만 방향은 흐려진다.

목표에는 모두 동의했다. 동의한 문장만으로 팀이 같은 방향으로 움직이지는 않았다. 목표는 문장으로 존재하지만 매일의 선택은 훨씬 작은 단위에서 일어난다. 무엇을 먼저 만들고 어떤 결함은 뒤로 미룰지 정하는 작은 결정들이 쌓여 실제 방향을 만든다.

의도가 남아 있지 않으면 기능 자체가 목적이 되기 쉽다. 기능은 목표를 달성하기 위한 수단인데, 목표와 기능 사이의 관계를 계속 확인하지 않으면 “이걸 만들면 좋아질 것 같다”, “저것도 붙이면 점수가 오를 것 같다”는 판단만 남고, 그 판단이 처음 목표와 어떻게 연결되는지는 점점 보이지 않는다.

의도부채는 늦게 드러난다. 당시에는 모두가 동의한 것처럼 보이지만 시간이 지나면 무엇을 포기했고 어떤 위험을 감수하기로 했는지 다시 떠오르지 않는다. 그러면 다음 결정을 할 때 과거의 의도를 재사용하지 못하고, 팀은 같은 논의를 다시 시작한다.

속도를 내기 위해 많은 부분을 LLM의 도움을 받아 구현했다. 실제로 빨랐다. 막혀 있던 구현이 풀리고 익숙하지 않은 코드도 금방 형태를 갖췄다. 작은 팀에서 AI의 도움을 받아 빠르게 제품을 만드는 일은 이제 자연스럽고, 그 속도의 이점은 분명히 느꼈다. 큰 흐름은 볼 수 있었지만 내부 구현에 대한 확신은 낮아졌다. 동작은 하는데, 문제가 생겼을 때 어디부터 봐야 할지, 지금 구조가 어떤 가정 위에 서 있는지 말하기 어려운 상태가 생겼다.

AI는 구현의 초안을 빠르게 만들어주지만 그 초안을 팀의 코드로 만드는 일은 여전히 사람의 몫이다. 읽고 이해하고, 결정의 이유를 남기고, 책임질 수 있는 구조로 바꾸는 시간이 필요하다. 이 시간을 생략하면 구현 속도와 이해 속도가 벌어진다. 예전에는 구현 자체가 오래 걸려 부채가 천천히 쌓였다면, 이제는 구현이 빨라진 만큼 코드를 읽고 의도를 복원하는 비용도 그 속도로 쌓인다. 이제 병목은 구현 속도보다 팀이 같은 것을 보고 같은 기준으로 판단하는 능력에 가깝다.

돌아보면 성취는 다른 곳에 있었다. 초기 사용자 검증에서 좋은 반응을 얻은 것, 정량 평가에서 약점을 발견한 것, 그리고 빠르게 움직인 뒤에도 무엇을 미루고 무엇을 감당해야 하는지 알고 있는 상태가 성취에 가까웠다.

부채를 만들지 않는 것은 불가능에 가깝다. 작은 팀일수록 더 그렇다. 제한된 시간 안에서 움직여야 하고, 모든 판단을 완벽하게 기록할 수도 없다. 속도를 내려면 어떤 것은 미뤄야 한다. 문제는 미루는 행위 자체가 아니라, 무엇을 미뤘는지 모르는 상태다.

이런 부채가 쌓이면 속도를 위해 만들었던 선택들이 다시 속도를 늦춘다. 그때 필요해지는 것이 “속도를 낮추는 시간”이다. 겉으로 보면 느려지는 것처럼 보이지만, 계속 달리기 위해 정렬하는 시간에 가깝다. 코드의 중요한 흐름을 다시 읽고, 에이전트가 참조해야 할 맥락을 정리하고, 평가 기준이 무엇을 측정하는지 다시 확인하는 일이다.

속도를 낮추는 시간은 멈춤이 아니라 정렬이다. 이해와 의도를 복원해야 다시 빠르게 움직일 수 있다.

최근에는 이 에이전트에 여러 사람이 붙는 것이 항상 좋은 방식인지도 고민하게 된다. 사람을 더 붙이면 속도가 빨라질 것 같지만 맥락과 의사결정의 면적도 함께 넓어진다. 작은 자동화 제품에는 더 많은 인원보다 더 작은 소유권과 더 선명한 기준이 필요할 때가 있다. 도메인 맥락과 제품 판단이 촘촘하게 붙어 있는 에이전트는 사람이 많아지면 구현 속도보다 맥락 동기화 비용이 더 커지고, 누가 최종 판단을 하고 어떤 피드백을 우선할지가 불분명해진다.

여러 팀에서 재사용될 AI 시스템과 플랫폼 이야기는 다르다. 공통 도구와 평가 체계, 로그 접근 방식, 권한 관리, 배포와 모니터링 같은 기반은 조직의 자산으로 함께 만들어야 하고, 각자 따로 만들수록 전체 부채가 커진다. 다만 그 위에서 특정 문제를 푸는 에이전트 제품은 작고 명확한 소유권 안에서 움직이는 편이 낫다.

그래서 요즘은 속도와 안정성을 부채를 다루는 방식의 결과로 본다. 빠르게 오래 움직이는 팀은 무엇을 미뤘는지 알고, 어떤 기준으로 성공을 판단할지 알고, 지금의 선택이 나중에 어떤 비용으로 돌아올지 감각하고 있다. 다음 사람이 읽을 수 있는 코드, 나중에 다시 꺼낼 수 있는 결정 이유, 평가 결과를 해석할 수 있는 기준이 그 팀의 안정성을 만든다.

AI는 앞으로 더 많은 것을 빠르게 만들어줄 것이다. 코드도, 문서도, 에이전트도. 그 결과물을 팀이 이해하고 책임질 수 있는 상태로 만드는 비용은 사라지지 않는다. 만드는 속도와 이해하는 속도, 이 간격이 앞으로 좁혀질지 벌어질지 나는 아직 답을 갖지 못했다.