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

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

문의가 들어오면 담당자는 생각보다 많은 맥락을 다시 꺼내야 한다. 이 문의가 어떤 기능과 관련되어 있는지, 사용자가 어떤 상태에서 문제를 겪었는지, 사용자 행동 로그와 서버 로그에는 무엇이 남아 있는지, 과거에도 비슷한 사례가 있었는지, 이미 해결된 문의 중 참고할 만한 내용은 없는지 살펴봐야 한다.

하나하나는 대단히 어려운 일이 아닐 수 있다. 하지만 매번 반복되면 꽤 큰 비용이 된다. 더 피곤한 점은 이것이 문제를 푸는 일이라기보다, 문제를 풀기 위해 필요한 주변 정보를 모으는 일에 가깝다는 것이다. 제품을 만드는 사람은 결국 판단하고 구현해야 하는데, 그 전에 흩어진 정보를 뒤지는 시간이 계속 끼어든다.

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

초기 사용자 검증에서 받은 피드백은 꽤 긍정적이었다. 실제로 써본 사람들은 이전보다 조사 시간이 줄었다고 느꼈고, 귀찮은 정보를 대신 모아준다는 점에서 만족했다. 에이전트가 모든 문제를 완벽하게 해결한 것은 아니었지만, 적어도 사용자가 느끼는 불편 하나는 분명히 줄이고 있었다.

사용자 관점에서는 가치가 있었다.

그런데 내부 정량 평가는 달랐다.

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

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

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

물론 정량 평가가 틀렸다는 말은 아니다. 로그를 잘못 읽는 에이전트를 그대로 열 수는 없다. 특히 사용자 문의를 돕는 에이전트는 사용자가 놓친 맥락을 대신 찾아주는 도구이기 때문에, 잘못된 근거를 바탕으로 그럴듯한 답을 만드는 순간 신뢰가 무너진다.

내부 도구라고 해서 대충 열어도 되는 것은 아니다. 오히려 내부 도구일수록 사용자가 빠르게 신뢰하거나 빠르게 포기한다. 한두 번 엉뚱한 근거를 가져오면, 사용자는 다시 직접 로그를 보게 된다.

그래서 정량 평가는 필요했다. 문제는 정량 평가 자체가 아니라, 정성 평가와 정량 평가 사이의 차이를 충분히 설명하지 못했다는 데 있었다.

사용자는 시간이 줄었다고 말했다. 평가는 로그 해석이 부족하다고 말했다. 둘 다 사실일 수 있다. 에이전트는 사용자에게 충분히 도움이 되었지만, 동시에 특정 기준에서는 아직 부족했을 수 있다.

그런데 둘을 함께 해석하는 언어가 없으면 팀은 쉽게 한쪽으로 쏠린다. 이번 경우에는 점수가 낮다는 사실이 제품의 전체 가치를 덮어버렸다. 반대로 정성 피드백만 믿었다면, 실제로 위험한 결함을 놓쳤을 수도 있다.

중요한 것은 둘 중 무엇이 맞느냐가 아니었다. 어떤 평가가 어떤 질문에 답하고 있는지 구분하는 일이었다.

정성 평가는 “사용자가 이 제품에서 실제로 가치를 느끼는가?”에 가까운 질문에 답한다. 정량 평가는 “우리가 중요하다고 정의한 능력을 안정적으로 수행하는가?”에 답한다. 두 평가는 서로를 대체하지 않는다.

그런데 이 차이를 명확히 붙잡지 못하면 제품 개발은 사용자의 문제를 푸는 일에서 평가 항목을 통과하는 일로 좁아지기 쉽다.

처음에는 이 문제가 로그 조사 방식을 고치면 해결될 거라고 생각했다. 에이전트가 로그를 더 잘 읽게 만들고, 필요한 정보를 더 잘 가져오게 만들면 된다고 봤다. 실제로 그런 개선은 필요했다.

하지만 시간이 지나면서 이것이 단순한 기능 개선 문제가 아니라는 생각이 들었다.

겉으로는 “로그를 더 잘 읽게 만들자”는 문제처럼 보였다. 하지만 안쪽에는 더 많은 것이 얽혀 있었다. 어떤 로그를 봐야 하는지, 로그의 어떤 필드를 신뢰해야 하는지, 제품의 특정 상태가 무엇을 의미하는지, 과거 문의에서 어떤 정보를 재사용할 수 있는지, 도메인 용어를 어떻게 해석해야 하는지 같은 문제들이 있었다.

에이전트가 알아야 하는 것은 코드 몇 줄이나 프롬프트 몇 문장이 아니라, 제품을 둘러싼 운영 맥락 전체에 가까웠다.

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

기술부채는 비교적 익숙하다. 빠르게 만들기 위해 구조화나 테스트를 미루고, 나중에 갚아야 할 비용을 남기는 것이다. 일정이 촉박하거나 아직 요구사항이 변하는 중이라면 어느 정도의 기술부채는 불가피하다.

하지만 이번에 더 크게 느껴진 것은 기술부채만이 아니었다. 오히려 인지부채와 의도부채가 더 부담스럽게 다가왔다.

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

인지부채는 팀이나 시스템이 이해해야 할 맥락이 흩어져 있는 상태다. 사용자 문의를 돕는 AI 에이전트는 단순히 답변을 생성하는 도구가 아니다. 제품 맥락, 사용자 행동 로그, 서버 로그, 과거 문의, 이미 해결된 사례, 도메인 용어를 함께 이해해야 한다.

이 정보들이 각자 다른 곳에 있고, 사람마다 다르게 이해하고 있다면 에이전트의 품질은 쉽게 흔들린다.

사람이 직접 조사할 때는 어느 정도의 맥락 누락을 감으로 메울 수 있다. “이 케이스는 아마 저 기능 때문일 것이다”, “이 로그는 이 상황에서는 크게 의미 없다”, “비슷해 보이지만 저 문의와는 원인이 다르다” 같은 판단을 사람이 한다.

하지만 에이전트에게 일을 맡기려면 그 감의 일부를 구조로 바꿔야 한다. 어디를 봐야 하는지, 무엇을 근거로 삼아야 하는지, 어떤 경우에는 모른다고 해야 하는지를 남겨야 한다.

이 전환이 생각보다 어렵다. 사람이 하던 일을 AI에게 넘긴다는 것은 단순히 작업자를 바꾸는 일이 아니다. 암묵지를 어느 정도 명시지로 바꾸는 일이다. 그리고 이 과정에서 흩어진 맥락이 그대로 드러난다.

제품 안에서 당연하게 여겼던 용어, 팀 안에서만 통하던 판단 기준, 특정 사람이 알고 있던 예외 케이스들이 모두 부채처럼 나타난다.

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

왜 이 평가 기준을 우선하는지, 사용자 피드백은 어느 정도까지 신뢰할지, 어떤 수준이 되어야 다음 단계로 넘어갈 수 있는지, 지금 미루는 것은 무엇이고 감수하는 위험은 무엇인지가 선명하지 않으면 팀은 계속 움직이지만 방향은 흐려진다.

목표에는 모두 동의했을 수 있다. 하지만 동의했다는 사실만으로 팀이 같은 방향으로 움직이는 것은 아니다. 목표는 문장으로 존재하지만, 매일의 선택은 훨씬 작고 구체적인 단위에서 일어난다.

어떤 기능을 먼저 만들지, 어떤 평가를 더 믿을지, 어떤 결함을 감수할지, 언제 멈춰서 정리할지 같은 결정들이 쌓여 실제 방향을 만든다.

이때 의도가 남아 있지 않으면 기능 자체가 목적이 되기 쉽다. 원래 기능은 목표를 달성하기 위한 수단이어야 한다. 그런데 목표와 기능 사이의 관계를 계속 확인하지 않으면, 어느 순간 기능 자체가 목적처럼 움직인다.

“이걸 만들면 좋아질 것 같다”, “저것도 붙이면 점수가 오를 것 같다”는 판단은 계속 생기지만, 그것이 처음의 목표와 어떻게 연결되는지는 흐려진다.

여기에 AI가 만든 코드가 더해지면서 또 다른 문제가 생겼다.

속도를 내기 위해 많은 부분을 LLM의 도움을 받아 구현했다. 이 방식은 실제로 빠르다. 막혀 있던 구현이 풀리고, 익숙하지 않은 코드도 금방 형태를 갖춘다. 작은 팀에서 AI의 도움을 받아 빠르게 제품을 만드는 것은 이제 꽤 자연스러운 일이 되었다. 나 역시 그 속도의 이점을 분명히 느꼈다.

하지만 빠르게 만들어진 코드가 곧바로 팀의 이해가 되는 것은 아니었다.

큰 흐름은 볼 수 있었지만 내부 구현에 대한 확신은 낮아졌다. 동작은 하지만, 왜 이렇게 되어 있는지 충분히 이해하고 있다고 말하기 어려운 상태가 생겼다. 문제가 생겼을 때 어디를 봐야 하는지, 어떤 변경이 어떤 부작용을 낼지, 지금 구조가 어떤 가정을 깔고 있는지 확신하기 어려웠다.

AI는 구현의 초안을 빠르게 만들어준다. 하지만 그 초안을 팀의 코드로 만드는 일은 여전히 사람의 몫이다. 읽고, 이해하고, 결정의 이유를 남기고, 불필요한 복잡성을 덜어내고, 책임질 수 있는 구조로 바꾸는 시간이 필요하다.

이 시간을 생략하면 구현 속도는 빨라지지만 이해 속도는 뒤처진다.

이 차이가 부채 비용으로 돌아온다. 코드를 읽는 비용, 의도를 복원하는 비용, 평가 기준을 다시 합의하는 비용, 무엇을 믿어도 되는지 확인하는 비용이 생긴다. 예전에는 구현 자체가 오래 걸려서 부채가 천천히 쌓였다면, 이제는 구현이 빨라진 만큼 부채도 더 빠르게 쌓일 수 있다.

그래서 AI 시대에도 부채 비용은 여전히 어렵다. 아니, 어쩌면 더 어려워졌다. 만드는 속도는 빨라졌지만 이해하는 속도는 그만큼 빨라지지 않았기 때문이다.

예전에는 구현 속도가 병목이었다면, 이제는 팀이 같은 것을 보고 같은 기준으로 판단하는 능력이 병목이 될 수 있다.

돌아보면 성취는 기능을 많이 만든 상태가 아니었다. 초기 사용자 검증에서 좋은 반응을 얻은 것도 성취였고, 정량 평가에서 약점을 발견한 것도 성취였다.

하지만 더 중요한 성취는 빠르게 움직인 뒤에도 무엇을 미뤘고 무엇을 감당해야 하는지 알고 있는 상태였던 것 같다.

부채를 만들지 않는 것은 불가능에 가깝다. 특히 작은 팀에서는 더욱 그렇다. 제한된 시간 안에서 움직여야 하고, 모든 판단을 완벽하게 기록할 수도 없고, 모든 구현을 처음부터 이상적으로 만들 수도 없다.

속도를 내려면 어떤 것은 미뤄야 한다. 문제는 미루는 행위 자체가 아니라, 무엇을 미뤘는지 모르는 상태다.

기술부채는 그나마 코드에 흔적이 남는다. 테스트가 부족하거나, 구조가 어색하거나, 중복이 보이거나, 특정 모듈이 과하게 커지는 식으로 드러난다. 물론 이것도 방치하면 위험하지만, 적어도 어느 정도는 눈에 보인다.

반면 인지부채는 더 조용하다. 정보가 흩어져 있고, 판단 기준이 사람들의 머릿속에 있고, 도메인 용어가 문서보다 대화에 더 많이 존재한다. 누군가 빠지면 갑자기 속도가 떨어지고, 비슷한 질문이 반복되고, 같은 맥락을 다시 설명해야 한다.

팀은 계속 일하고 있지만, 실제로는 이해를 복원하는 데 많은 시간을 쓰게 된다.

의도부채는 더 늦게 드러난다. 당시에는 모두가 동의한 것처럼 보인다. 하지만 시간이 지나면 왜 그 결정을 했는지, 무엇을 포기했는지, 어떤 위험을 감수하기로 했는지가 흐려진다.

그러면 다음 결정을 할 때 과거의 의도를 재사용하지 못한다. 팀은 같은 논의를 다시 하고, 같은 불안을 다시 느끼고, 같은 종류의 결정을 새로 하는 것처럼 반복한다.

이런 부채가 쌓이면 결국 속도를 위해 만들었던 선택들이 다시 속도를 늦춘다. 처음에는 빠르게 만들기 위해 기록을 줄이고, 구조화를 미루고, 평가 기준을 대략 합의한다.

그런데 어느 순간부터는 그 미룸 때문에 더 이상 빠르게 움직이기 어려워진다. 같은 제품을 보고 있는지 확인해야 하고, 같은 기준으로 판단하는지 다시 맞춰야 하고, 코드가 왜 이렇게 되어 있는지 다시 읽어야 한다.

이 지점에서 “속도를 낮추는 시간”이 필요해진다.

겉으로 보면 느려지는 것처럼 보인다. 하지만 실제로는 계속 달리기 위해 정렬하는 시간에 가깝다. 코드의 중요한 흐름을 다시 읽고, 에이전트가 참조해야 할 맥락을 정리하고, 평가 기준이 무엇을 측정하는지 다시 확인하고, 정성 피드백과 정량 평가를 함께 해석하는 기준을 만드는 일이다.

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

최근에는 내부 사용자를 위한 작은 AI 에이전트에 여러 사람이 붙는 것이 항상 좋은 방식인지도 고민하게 된다. 사람을 더 붙이면 속도가 빨라질 것 같지만, 맥락과 의사결정의 면적도 함께 넓어진다.

특히 작은 자동화 제품에서는 더 많은 인원이 아니라 더 작은 소유권, 더 선명한 기준, 더 적은 커뮤니케이션 면적이 필요할 때가 있다.

이 말이 모든 일을 혼자 해야 한다는 뜻은 아니다. 여러 팀에서 재사용될 AI 시스템과 플랫폼은 함께 만들어야 한다. 공통 도구, 평가 체계, 로그 접근 방식, 권한 관리, 배포와 모니터링 같은 기반은 조직의 자산으로 다뤄져야 한다. 이런 것들은 각자 따로 만들수록 오히려 전체 부채가 커진다.

다만 그 위에서 특정 문제를 푸는 에이전트 제품은 가능한 한 작고 명확한 소유권 안에서 움직이는 편이 나을 수 있다. 내부 사용자를 위한 작은 에이전트는 도메인 맥락과 제품 판단이 촘촘하게 붙어 있다.

이때 사람이 많아지면 구현 속도보다 맥락 동기화 비용이 더 커질 수 있다. 누가 최종 판단을 하는지, 어떤 피드백을 우선하는지, 어떤 부채를 감수하는지 선명하지 않으면 사람 수는 속도가 아니라 불확실성을 늘리기도 한다.

그래서 요즘은 속도와 안정성을 반대말로 두기보다, 부채를 다루는 방식의 결과로 보게 된다.

속도가 빠른 팀은 단순히 코드를 빨리 쓰는 팀이 아니다. 무엇을 미뤘는지 알고, 어떤 기준으로 성공을 판단할지 알고, 지금의 선택이 나중에 어떤 비용으로 돌아올지 어느 정도 감각하고 있는 팀이다.

반대로 안정적인 팀도 모든 것을 천천히 만드는 팀은 아니다. 안정성은 완벽함에서만 나오지 않는다. 빠르게 만든 뒤에도 이해 가능한 상태를 남기는 데서 나온다.

다음 사람이 읽을 수 있는 코드, 나중에 다시 꺼낼 수 있는 결정 이유, 평가 결과를 해석할 수 있는 기준, 사용자의 정성적 반응을 제품 판단으로 연결하는 언어가 안정성을 만든다.

결국 부채를 잘 다룬다는 것은 부채를 만들지 않는다는 뜻이 아니다.

지금 무엇을 빠르게 만들고 있는지, 무엇을 이해하지 못한 채 지나가고 있는지, 어떤 기준으로 성공을 판단할 것인지 남기는 일에 가깝다.

AI는 앞으로 더 많은 것을 빠르게 만들어줄 것이다. 코드도, 문서도, 실험도, 에이전트도 더 빨리 만들 수 있게 될 것이다. 하지만 그 결과물을 팀이 이해하고 책임질 수 있는 상태로 만드는 비용은 사라지지 않는다. 오히려 더 중요해질 수 있다.

나에게 성취는 이제 단순히 기능을 많이 만든 상태와는 조금 다르게 느껴진다.

빠르게 움직였지만, 그 뒤에 무엇을 미뤘는지 알고 있는 상태. 사용자에게 어떤 가치를 줬는지와 내부적으로 어떤 약점이 남았는지를 함께 볼 수 있는 상태. 그리고 필요할 때 속도를 낮춰서 다시 이해 가능한 제품으로 돌려놓을 수 있는 상태.

그쪽이 더 오래가는 성취에 가까운 것 같다.

속도와 안정성은 반대말이 아니다. 속도를 내고도 안정성을 유지하려면, 가끔은 속도를 낮춰야 한다. 부채를 갚기 위해서만이 아니라, 다시 같은 제품을 보고 같은 기준으로 판단할 수 있게 만들기 위해서다.