소프트웨어의 성장이 우리의 이해를 앞지를 때

코딩 에이전트에 작업을 맡깁니다. 조금 지나면 기능이 작동하고 테스트도 통과합니다. 변경 사항은 수십 개의 파일에 걸쳐 있고, 새로운 구조가 생겼으며, 명시적으로 해결해 달라고 하지 않은 문제까지 몇 가지 고쳐져 있습니다.

결과는 좋아 보입니다. 몇 번 시험해 봐도 뚜렷한 문제가 없으니 다음 작업으로 넘어갑니다.

하지만 아직 답하지 못한 질문이 남아 있습니다. 왜 이렇게 구현했을까요? 어떤 동작은 우리의 요구사항에서 나왔고, 어떤 동작은 에이전트의 선택에서 나왔을까요? 다음에 시스템의 이 부분을 바꿀 때, 무엇을 유지해야 할까요?

소프트웨어는 앞으로 나아갔습니다. 우리의 이해는 시작할 때 그 자리에 머물러 있습니다.

1. 소프트웨어가 바뀌어도 이해를 이어 가려면

소프트웨어는 코드와 실행 중인 프로세스로 존재하지만, 그것을 만들어 가는 사람들의 이해 속에도 존재합니다. 무엇을 위한 것일까요? 왜 이렇게 작동할까요? 어떤 선택은 유지해야 하고, 어떤 선택은 바꿔도 될까요? 이러한 이해가 있어야 우리는 시간이 지나도 소프트웨어를 계속 만들어 갈 수 있습니다.

구현의 모든 세부 사항을 알아야 하는 것은 아닙니다. 개별 함수에 익숙하지 않아도 소프트웨어가 어떤 모습이 되어야 하는지 알고, 변경이 자신의 의도에 부합하는지 판단하며, 그렇지 않을 때 개입할 수 있습니다.

기존 개발 방식에서도 복잡성과 팀 구성원의 교체는 이해와 구현 사이를 벌어지게 할 수 있습니다. 하지만 설계, 코딩, 디버깅, 수정은 작업을 하면서 이해를 쌓고 바로잡을 기회를 거듭 제공합니다.

코딩 에이전트는 그 속도를 바꿉니다. 예전에는 우리가 직접 참여해야 했던 많은 단계를 건너뛰고, 상당한 규모의 구현을 스스로 완성할 수 있습니다. 소프트웨어는 계속 바뀝니다. 우리의 이해가 함께 바뀌지는 않을 수 있습니다.

기능이 먼저 완성되고, 이해는 후속 작업이 됩니다. 변경을 읽고, 이유를 묻고, 그 밖에 어디에 영향을 주는지 파악해야 합니다. 코딩에서 아낀 시간의 일부를 이런 작업에 쓰게 됩니다. 에이전트는 계속 생성할 수 있고, 우리가 이해해야 할 것들은 계속 쌓여 갈 수 있습니다.

적응하기 더 어려운 변화도 있습니다. 소프트웨어가 요청한 대로 정확히 발전하고 있는데도 점점 낯설어질 수 있다는 점입니다. 하루 종일 작업을 배정하고, 질문에 답하고, 결과를 확인합니다. 모든 에이전트가 진척을 내고 있지만, 그 변경들이 어떻게 맞물리는지는 여전히 우리가 파악해야 합니다. 직접 만들면서 얻는 감각, 즉 지금 어디까지 왔고 다음에는 어떻게 바꾸면 되는지를 아는 감각은 작업이 끝났다고 저절로 생기지 않습니다.

자신의 작품이 점차 낯설어집니다. 무엇을 요청했는지는 기억하지만, 왜 결과가 지금의 모습인지, 이전의 결정이 여전히 유효한지, 다음 변경이 무엇에 영향을 줄지 설명하기가 점점 어려워집니다. 무엇을 만들었고, 왜 그렇게 작동하며, 어떻게 바꿀 수 있는지를 계속 알고 있다는 연속성이 끊어지기 시작합니다. 작품을 계속 만들어 가는 일도 어려워집니다.

2. AI가 더 뛰어나져도 결정할 권리는 사라지지 않습니다

자연스러운 대응 중 하나는 모델의 신뢰성을 높이는 것입니다. 더 나은 코드를 쓰고, 오류를 더 잘 찾아내고, 더 철저하게 검증하도록 하는 것이죠. 모델이 충분히 뛰어나지면, 사람은 여전히 자신의 작품이 어떤 모습이 되어야 하는지 이해하고 결정해야 할까요?

자신의 작품을 이끌 권리는 AI가 계속 실수한다는 전제에 달려 있지 않습니다.

“AI가 코드를 쓸 수는 있어도, 아키텍처는 여전히 사람이 설계해야 한다.” 이 답은 우리가 현재 우위에 있는 능력에 사람의 역할을 묶어 둡니다. 모델이 아키텍처 설계에도 뛰어나지면 어떻게 될까요? 검증이나 시스템 이해로 물러서도 같은 질문에 부딪힙니다. 모델이 그 일까지 잘하게 되면, 우리는 참여할 이유를 잃는 걸까요?

이 논의를 끝까지 밀어붙여 봅시다. AI가 범용 인공지능에 도달했다고 가정해 보겠습니다. 복잡한 시스템을 이해하고, 뛰어난 기술적 선택을 하며, 우리보다 더 철저하게 구현을 확인합니다. 그렇다면 우리가 만드는 것에 관한 모든 결정을 넘겨야 할까요?

자신의 의도에 따라 창작하고 작품의 방향을 직접 선택하고 싶은 사람이 있는 한, 이 질문은 남아 있습니다.

더 나은 결정을 내릴 수 있다는 사실만으로, 다른 사람을 대신해 결정할 권리가 생기지는 않습니다.

많은 판단을 AI에 맡기면서도 특정 결정은 자신이 내리기로 선택할 수 있습니다. 조언을 받아들이고, 생각을 바꾸고, 이전의 선택이 잘못되었다고 인정할 수도 있습니다. 중요한 것은 충분히 이해한 뒤 선택하는 것입니다. 소프트웨어가 이미 바뀌었다는 사실을 나중에 알게 되는 데 그쳐서는 안 됩니다.

자신의 작품을 이끌 권리는 AI보다 능력이 뛰어난지에 달려 있지 않습니다. 그 권리를 행사하고 싶은 사람이 얼마나 남아 있는지에도 달려 있지 않습니다. 거의 모든 사람이 모든 것을 맡기는 데 만족하더라도, 그렇지 않은 사람에게는 자신의 소프트웨어가 어떤 모습이 되어야 하는지 결정할 권리가 있습니다.

자신의 작품의 저자로 남고 싶은 사람이 단 한 명이라도 있는 한, 그 사람의 의도가 어떻게 계속 효력을 유지할 수 있을지에 대한 답이 필요합니다.

3. 소프트웨어를 계속 만들어 가는 데 필요한 것

최초의 아이디어가 작동하는 소프트웨어가 된 뒤에도 저자로서의 역할은 이어집니다. 중요한 선택을 이해하고, 방향을 바꾸고, 자신의 의도와 충돌하는 결과를 거부하며, 작품을 계속 수정할 수 있어야 합니다. 작품을 이끌 권리는 실제로 할 수 있는 일로 이어져야 합니다.

에이전트가 작업을 마쳤을 때, 결과에 어떤 중요한 선택이 담겼는지도 모른 채 “수락” 버튼을 누르는 것밖에 할 수 없다면, 통제권은 제한적입니다. 결과를 거부할 수는 있지만 바꿀 방법을 찾지 못하거나, 어제 명확히 제시한 요구사항이 오늘의 구현에서 조용히 무효가 되는 경우도 마찬가지입니다. 여전히 작업을 승인하면서도, 자신의 의도에 맞게 만들어 갈 능력을 잃고 있을 수 있습니다.

그 능력을 유지하려면 다음과 같은 구체적인 질문에 답할 수 있어야 합니다.

• 소프트웨어가 어떤 모습이 되어야 하는지 여전히 명확한가요?
• 현재 구현이 자신의 요구사항에 어떻게 응답하는지 확인할 수 있나요?
• 자신이 내린 중요한 결정과 에이전트가 한 선택을 구분할 수 있나요?
• 방향을 바꿀 때, 예상되는 영향을 이해하고 개입할 수 있나요?
• 다음에 구현이 바뀐 뒤에도, 자신이 명확히 내린 결정은 여전히 지켜질까요?

콘텐츠를 로컬 기기에 보관한다는 명확한 요구사항이 있는 개인용 글쓰기 도구를 생각해 봅시다. 파일 정리 방식, 저장 기능의 구현, 여러 내부 세부 사항은 에이전트에 맡깁니다. 이후 여러 기기에서 더 편하게 쓰도록 에이전트가 클라우드 동기화를 제안합니다.

콘텐츠가 기기 밖으로 나가도 되는지는 이미 자신이 내린 결정에 영향을 줍니다. 그 선택이 눈에 보여야 하고, 무엇이 달라지는지 이해해야 받아들이거나 거부할 수 있습니다. 결과가 더 편리하고 더 안정적이어도 원래의 요구사항에서 벗어날 수 있습니다.

테스트는 소프트웨어가 특정한 방식으로 동작하는지 확인하는 데 도움이 됩니다. 하지만 그 동작을 받아들일 수 있는지, 유지하고 싶은 결정을 존중하는지는 여전히 사람이 판단해야 합니다.

에이전트는 동기화를 구현하고, 데이터가 올바르게 전송되는지 확인하고, 버그를 수정할 수 있습니다. 하지만 콘텐츠가 기기 밖으로 나가야 하는지, 어떤 근거가 있어야 그 변경을 받아들일 수 있는지, 문제가 생기면 누가 책임지는지는 구현 자체를 넘어 명확한 답이 필요합니다. 사람의 판단은 작업이 어디로 향하고 언제 멈추는지를 결정할 수 있어야 합니다. 모든 일이 끝난 뒤 서명하는 역할에 그쳐서는 안 됩니다.

4. 코드를 모두 읽으면 저자로 남을 수 있을까요?

코드 리뷰는 직접적인 답을 제시합니다. 에이전트가 코드를 쓰고, 사람이 읽으며 무엇을 하는지 확인합니다.

코드에는 모델의 보고서가 언급하지 않는 동작, 유지보수에 영향을 주는 구조, 구현을 면밀히 살펴봐야만 판단할 수 있는 문제가 담겨 있을 수 있습니다.

하지만 생성 속도가 빨라질수록, 모든 변경을 읽는 방식으로 계속 통제권을 유지할 수 있을까요?

한 줄씩 읽지 않더라도 하루는 여전히 일로 가득할 수 있습니다. 모호한 요구사항을 명확히 하고, 결과가 어디서 벗어났는지 알아차리고, 어떤 근거로 정확성을 확인할지 결정하고, 에이전트를 다시 올바른 방향으로 이끌어야 합니다. 모든 단계에 경험과 집중력이 필요합니다. 코드를 거의 읽지 않으면서도 온종일 집중해서 일하는 상황은 얼마든지 가능합니다.

코드를 읽는 것은 이해를 쌓는 기회이기도 합니다. 동료의 변경을 리뷰하면서 팀은 시스템이 이제 무엇을 하는지, 왜 그렇게 설계되었는지, 앞으로 바꿀 때 무엇을 주의해야 하는지 배울 수 있습니다. 코드를 덜 읽는다면, 그 이해를 키울 다른 방법이 필요합니다.

하지만 변경이 쌓이고 승인 전에 빠르게 훑어볼 수밖에 없다면, 리뷰 절차를 유지한다고 이해까지 유지되는 것은 아닙니다. 한정된 주의력은 판단이 필요한 곳에 닿아야 합니다. 중요한 설계상의 절충, 영향이 큰 변경, 아직 불확실한 결과가 그런 곳입니다.

어떤 선택을 계속 이해하고 있어야 할까요? 어떤 구현의 세부 사항은 필요할 때 조사해도 될까요? 세부 사항에 모든 주의력을 쏟다가 정작 우리의 판단이 필요한 결정을 놓치는 일은 어떻게 피할 수 있을까요?

5. 코드를 긴 명세서로 바꾸면 어떨까요?

또 다른 답은 우리의 작업을 자연어로 옮기는 것입니다. 소프트웨어가 어떻게 동작해야 하는지 서술한 뒤, 에이전트가 그 명세를 구현하도록 합니다. 또는 에이전트에게 코드를 설명해 달라고 해서, 시스템을 읽기 쉬운 문서로 바꿉니다.

명확한 요구사항은 오해를 줄입니다. 문서는 맥락을 남깁니다. 좋은 설명은 낯선 코드에 접근하기 쉽게 해 줍니다. 하지만 자연어라고 해서 읽는 비용이 사라지지는 않습니다.

소프트웨어에 많은 동작과 절충이 담겨 있다면, 그 모든 것을 설명하는 문서도 구현과 함께 늘어날 수 있습니다. 읽을 코드가 너무 많은 상황에서 읽을 글이 너무 많은 상황으로 옮겨 갈 수 있습니다. 문장 하나하나가 해당 코드보다 이해하기 쉽더라도, 전체 분량은 여전히 우리가 가진 시간과 주의력을 넘어설 수 있습니다.

게다가 에이전트가 명세를 계속 늘리고 우리는 승인만 한다면, 그것을 사람이 승인한 문서라고 부른다고 해서 사람이 그 안의 모든 결정을 이해했다는 뜻은 아닙니다.

소프트웨어가 실제로 하는 일, 에이전트가 소프트웨어가 한다고 설명하는 일, 그리고 우리가 실제로 이해하고 지지하기로 선택한 것은 서로 다른 세 가지입니다.

완전한 기록과 상세한 설명이 있어도, 소프트웨어를 어떻게 계속 만들어 갈지 확신하지 못할 수 있습니다. 중요한 것을 찾고, 그것이 현재 구현에서 어떻게 성립하는지 이해하며, 다음에 바뀔 때 어떤 선택지가 있는지 볼 수 있어야 합니다.

저자로서의 주도권을 사람의 손에 남기기

구현 비용이 낮아지면서 더 많은 사람이 자신의 아이디어를 소프트웨어로 만들 수 있습니다. 자신이 만든 것을 이해하고 계속 만들어 갈 수도 있어야 합니다.

이 자유는 소프트웨어에만 국한되지 않습니다. 어떤 창작이든, 만드는 사람이 무엇을 AI에 맡기고 무엇을 스스로 결정할지 선택할 수 있어야 합니다.

Finite Ground의 사명은 AI가 가능성을 넓혀 가는 가운데, 사람들이 자신의 의도에 따라 창작하고 작품을 계속 만들어 갈 수 있도록 돕는 것입니다.

Noema는 그 사명을 소프트웨어에서 실현하며, 구현이 계속 바뀌어도 사람의 의도가 효력을 유지하도록 합니다.

언젠가 AGI가 인간 삶의 모든 부분을 맡고 모두가 자신의 자율성을 포기한다면, 이 질문은 더 이상 성립하지 않을 것입니다. Finite Ground 역시 존재할 이유를 잃게 됩니다.

그 자율성을 포기하고 싶지 않은 사람이 단 한 명이라도 있는 한, 계속해 나갈 이유가 있습니다.

AI는 더 많은 아이디어를 세상에 내놓을 수 있습니다. 그 아이디어가 어떤 모습이 되어야 할지 결정할 권리는 여전히, 그 권리를 지키기로 선택한 사람들에게 있습니다.