AI가 모든 것을 만들어주는 시대, 인간은 무엇을 이해해야 할까

AI 시대에 던져야 할 중요한 질문은 AI에게 얼마나 더 많은 일을 맡길 수 있는가보다, AI가 만들어낸 결과 가운데 무엇을 내가 이해해야 하는가에 가깝다고 생각한다.

AI는 더 빠르게 만들지만, 인간은 더 빠르게 이해하지 못한다

AI를 활용하기 시작하면 한 사람이 만들어낼 수 있는 결과물의 양은 빠르게 늘어난다. 여러 작업을 동시에 실행하고, Tool Calling 기반으로 에이전트를 만들고, 반복 업무를 자동화하면 과거에는 여러 사람이 오랜 시간에 걸쳐 만들었을 결과를 짧은 시간 안에 얻는 것도 가능해진다.

한 사람이 수백 개의 에이전트를 운영하면서 코드와 문서, 설계안, 테스트, 분석 결과가 동시에 쏟아지는 모습이 그리 낯설지 않을 것이다.

문제는 생성 속도가 높아져도 사람이 읽고 이해할 수 있는 양은 그만큼 늘어나지 않는다는 데 있다.

AI가 결과를 만들어내는 속도는 사람이 그것을 검토하고 이해하는 속도보다 비교할 수 없을 만큼 빠르다. 조금만 작업을 병렬화해도 확인해야 할 정보가 쌓이기 시작하고, 자동화의 범위가 넓어질수록 사람이 감당해야 하는 인지적 부담도 더욱 커진다.

그래서 앞으로의 병목은 무엇을 더 많이 만들 수 있는가보다, 만들어진 결과 가운데 무엇을 이해할 수 있는가에서 나타날지도 모른다.

AI가 생성한 모든 코드와 모든 판단을 사람이 직접 확인하려 한다면, 자동화를 통해 얻은 생산성이 다시 검토 비용으로 사라질 수 있다. 반대로 아무것도 이해하지 않은 채 결과만 받아들인다면 시스템은 빠르게 커질 수 있지만, 어느 순간 왜 지금과 같은 형태가 되었는지를 누구도 제대로 설명하지 못하는 상태에 이를 수 있다.

따라서 중요한 것은 모든 결과를 이해하는 것도, 모든 결과를 이해하지 않은 채 사용하는 것도 아닐 것이다.

어떤 결과에 자신의 시간과 집중력을 사용하고, 어떤 결과는 내부를 모두 이해하지 않은 채 사용해도 되는지를 구분하는 능력이 필요하다.

우리에게는 한정된 ‘인지 예산’이 있다

나는 사람이 사용할 수 있는 시간과 집중력, 이해력을 하나의 인지 예산으로 생각한다.

사람의 인지 예산에는 한계가 있다. 반면 AI가 만들어낼 수 있는 정보의 양은 끝없이 늘어난다. 이런 상황에서 모든 것을 이해하려는 태도는 성실함처럼 보이지만, 경우에 따라서는 정작 중요한 문제에 사용할 인지 자원을 낭비하는 일이 될 수도 있다.

모든 것을 이해하는 것이 항상 좋은 선택인 것은 아닐 수 있다. 이해할 필요가 크지 않은 대상에는 인지 예산을 사용하지 않는 것 역시 중요한 능력에 가까울 것이다.

그렇다면 무엇을 이해하고, 무엇은 이해하지 않은 채 사용해도 될까?

구현과 설계로만 나누면 충분할까

처음에는 구현은 AI에게 맡기고 설계는 사람이 이해해야 한다고 단순하게 나눌 수 있다고 생각했다. 하지만 구현과 설계의 구분만으로는 충분하지 않은 것 같다.

더 중요한 기준은 그 결과가 한 번 소비되고 끝나는지, 아니면 이후 의사결정의 전제가 되는지에 있을 수 있다.

한 번 쓰고 끝나는 결과는 블랙박스로 받아들여도 된다

예를 들어 AI가 HTML로 보고서나 프레젠테이션을 만들었다고 해보자.

대부분의 경우 중요한 것은 결과물의 내용과 전달력일 것이다. 내부 마크업이 얼마나 우아한지, 어떤 라이브러리를 사용했는지, 사소한 코드상의 문제가 있는지는 크게 중요하지 않을 것이다.

결과물이 목적을 달성한 뒤 더 이상 다른 판단의 기반으로 사용되지 않는다면, 내부 구현까지 모두 이해할 필요는 없다고 생각한다. 이런 작업은 굳이 내부를 자세히 들여다보기보다 블랙박스로 받아들이는 편이 더 효율적이다.

결과가 한 번 사용된 뒤 역할을 다한다면, 사람이 이해해야 할 것은 내부 구현보다 결과물이 목적에 맞는지 여부일 가능성이 크다.

하지만 다음 결정의 기반이 되는 결과는 다르다

반면 아키텍처, 인증과 인가, 데이터 모델, 캐시 전략 등 이후의 의사결정이 계속 그 위에 겹겹이 쌓이는 영역은 다르게 다뤄야 한다.

이런 결정은 AI가 내렸더라도 사람이 어느 정도 납득할 수 있어야 한다.

여기서 납득한다는 것은 사람이 처음부터 같은 결론을 독립적으로 도출할 수 있어야 한다는 뜻은 아니다. AI가 사람보다 더 빠르게, 더 나은 결론에 도달하더라도 문제는 없을 것이다.

다만 설명을 들은 뒤 그 선택의 이유를 이해하고, 남아 있던 의문을 해소하며, 여러 대안 가운데 왜 그 결정을 받아들이는지에 대한 자신의 입장을 가질 수는 있어야 한다.

설계에는 언제나 다른 의견이 존재할 수 있다. 모두를 설득할 수 있는 절대적인 정답을 찾는 것이 목적일 필요는 없다고 생각한다.

중요한 것은 내가 무엇을 승인했는지, 그 선택이 어떤 문제를 해결하기 위한 것인지, 그리고 그 과정에서 어떤 대가를 감수하기로 했는지를 이해하는 일에 가까울 것이다.

이후의 판단이 어떤 결정 위에 계속 쌓인다면, 그 결정에는 일정한 인지 예산을 투자할 필요가 있다.

이해하지 않은 결정도 결국 부채가 된다

중요한 결정을 충분히 이해하지 못한 채 넘어가면 그 위에 또 다른 결정이 쌓이기 시작한다.

처음에는 테스트와 시뮬레이션이 모두 통과했기 때문에 별다른 문제가 없어 보일 수 있다. 하지만 이해하지 못한 설계 위에 새로운 기능과 또 다른 설계가 축적되면, 나중에는 어디에서부터 의문을 풀어야 할지조차 알기 어려워질 수 있다.

나는 이런 상태를 이해 부채라고 부르고 싶다.

기술 부채가 지금 빠르게 만들기 위해 미래의 유지보수 비용을 미루는 것이라면, 이해 부채는 지금 빠르게 승인하기 위해 미래의 이해 비용을 미루는 것에 가깝다.

이해 부채는 인지 예산을 사용하지 않았다는 이유만으로 생기는 것은 아닐 것이다. 중요하지 않은 일에 지나치게 많은 인지 예산을 사용하고, 정작 이후의 판단을 좌우하는 결정에는 충분한 인지 예산을 사용하지 않을 때 더 빠르게 쌓일 수 있다.

AI는 기술 부채를 줄이면서 이해 부채를 늘릴 수 있다

AI는 기술 부채를 줄이는 데 도움을 준다. 더 일관된 코드를 작성하고, 테스트를 만들고, 문서를 정리하는 일을 지원할 수 있기 때문이다.

하지만 활용 방식에 따라서는 이해 부채를 이전보다 훨씬 빠르게 늘릴 수도 있다.

시스템은 정상적으로 동작하고 테스트도 통과하지만, 그 위에서 일하는 사람들은 왜 그렇게 동작하는지 충분히 설명하지 못하는 상태에 놓일 수 있다. 문제가 발생했을 때 무엇을 먼저 의심해야 하는지, 기존의 결정을 유지해야 하는지 폐기해야 하는지 판단하는 일도 어려워질 것이다.

그래서 어떤 결과를 이해해야 하는지 판단할 때는 그 작업이 구현인지 설계인지보다, 이후의 판단이 그 결과 위에 얼마나 많이 쌓이게 되는지를 살펴보는 편이 더 적절할 수 있다.

그렇다면 설계는 반드시 사람이 해야 할까

이 기준으로 보면 설계는 반드시 사람이 직접 해야 한다는 결론이 나오지는 않는다.

AI가 REST와 gRPC 가운데 하나를 선택하거나, 모놀리스와 MSA 가운데 하나를 고르거나, 캐시와 데이터 구조를 설계하는 것 자체에 본질적인 거부감을 가질 필요는 없을 것이다.

충분한 맥락과 검증 수단이 주어진다면 AI가 사람보다 더 나은 결정을 내리는 경우도 생길 수 있다.

오히려 나는 AI가 요청받은 기능을 그대로 구현하는 데서 멈추지 않고, 문제 자체에 의문을 제기하기를 기대한다.

정말 이 기능이 필요한지, 더 근본적인 문제는 다른 곳에 있는 것이 아닌지, 이 부분만 수정하기보다 전체 구조를 바꾸는 편이 더 낫지 않은지 말이다.

이런 질문을 던지는 능력은 지금까지 좋은 인간 동료가 가진 중요한 장점 가운데 하나였는데, AI가 주어진 문제를 그대로 받아들이지 않고 더 나은 문제를 정의할 수 있다면, 문제 정의와 설계 역시 반드시 인간만의 역할로 남겨둘 이유는 크지 않을 수 있다.

중요한 것은 설계를 누가 했는지가 아닐지도 모른다.

그 결정이 이후의 시스템과 판단에 계속 영향을 미친다면, 사람이 그 선택의 이유와 대가를 이해하고 있는지가 더 중요할 수 있다.

인간의 역할은 직접 만드는 사람에서 경계를 정하는 사람으로 바뀐다

이 관점에서 인간의 역할은 모든 것을 직접 설계하고 구현하는 사람이라기보다, 무엇을 AI에게 맡기고 어디까지 이해할지를 결정하는 사람에 가까워질 수 있다.

사람은 AI에게 방향과 제약을 제공할 수 있다.

• 앞으로 6개월 동안은 구조의 아름다움보다 출시 속도를 우선한다.

• 고객 데이터가 손실될 가능성은 어떤 경우에도 허용하지 않는다.

• 운영 인력이 계속 증가해야 하는 구조는 피한다.

이처럼 목표와 감수할 수 있는 위험을 정의하고, 그 범위 안에서 구체적인 아키텍처와 구현 방식은 AI가 선택하도록 할 수 있다.

좋은 아키텍처보다 빠른 전달이 중요했던 경험

나 역시 인증과 인가, 도구 호출, 예약 작업처럼 독립적인 서비스로 분리할 수도 있었던 기능들을 하나의 애플리케이션 안에 함께 구성한 적이 있다.

책임을 분리한다는 관점에서는 각각을 나누는 편이 더 깔끔했을 수 있다. 하지만 당시에는 아키텍처의 아름다움보다 짧은 CI/CD 주기와 빠른 기능 전달이 더 중요했다.

서비스를 분리했다면 배포와 통신, 문서화, 운영의 복잡성도 함께 증가했을 것이다.

이 선택이 절대적으로 옳았다는 뜻은 아니다. 중요한 것은 당시 무엇을 우선했으며, 어떤 종류의 복잡성을 감수하지 않기로 했는지를 이해하고 있었다는 점이다.

AI가 이런 맥락을 충분히 이해한다면 같은 판단을 내릴 수도 있고, 그보다 더 나은 대안을 제시할 수도 있을 것이다.

문제는 조직의 모든 맥락을 AI에게 전달할 수 없다는 것이다

다만 조직이 가진 모든 맥락을 AI에게 전달할 수 있는지는 여전히 확신하기 어렵다.

기술 문서와 코드, 장애 이력, 회의 기록, 코드 검토 기록은 어느 정도 디지털화할 수 있다. 반면 조직 내부의 정치적 관계, 사람 사이의 신뢰, 공식적으로 표현되지 않은 경영 방향, 누군가 말하지 않은 불안이나 반대 의견까지 모두 기록하는 것은 쉽지 않다.

기술적으로 기록할 수 있다고 하더라도, 조직이 그런 정보를 기록하고 공유하기를 원하지 않을 수도 있다.

어떤 지식은 디지털화하기 어렵고, 어떤 지식은 디지털화하는 것 자체가 부담이 될 수 있다.

따라서 미래에도 사람만이 가지고 있는 맥락은 어느 정도 남을 가능성이 높다. 그렇다고 해서 모든 암묵적인 지식을 문서로 바꾸는 것이 항상 좋은 선택이라고 보기도 어렵다.

모든 지식을 기록하고 공유할 필요는 없다

여기에서도 인지 예산의 배분과 비슷한 선택이 필요하다.

어떤 지식은 AI와 조직 전체가 활용할 수 있도록 명시적으로 연결할 필요가 있다. 반면 어떤 지식은 굳이 구조화하지 않고 특정 사람이나 팀이 가진 제한적인 맥락으로 남겨두는 편이 나을 수도 있다.

모든 것을 기록하고 모든 것을 공유하는 것이 목표일 필요는 없다.

무엇을 공유된 지식으로 만들고, 무엇을 제한된 맥락으로 남길지를 판단하는 일이 더 중요할 수 있다.

결국 중요한 것은 ‘이해의 경계’를 선택하는 일이다

AI는 앞으로 더 많은 코드를 만들고, 더 많은 설계를 제안하고, 어쩌면 더 나은 문제 정의까지 내놓을지도 모른다.

그렇다고 인간이 아무것도 이해하지 않아도 되는 것은 여전히 아닐 것이다.

오히려 AI가 만들어내는 결과가 많아질수록 무엇을 끝까지 이해해야 하고, 무엇은 블랙박스로 받아들여도 되는지를 더 자주 선택해야 한다.

이 선택은 생산성의 문제가 아니라 책임의 문제다.

한 번 사용되고 끝나는 결과라면 내부 구현을 모두 이해하지 않아도 괜찮을 수 있다. 하지만 이후의 판단과 결정이 계속 쌓이는 기반이라면, 그 선택의 이유와 대가를 이해하지 않은 채 넘겨서는 안 된다.

그래서 AI 시대의 인간은 모든 것을 만드는 사람이 아니라, 어디까지를 이해하고 책임질 것인지를 결정하는 사람이 될 가능성이 클 것 같다.

생성은 AI가 대신할 수 있다. 하지만 이해의 경계를 정하는 일은 여전히 사람의 몫으로 남을 것이다.

어쩌면 AI 시대의 병목은 생성이 아니라, 내가 책임져야 할 이해의 범위를 어떻게 선택하느냐에 있을지도 모른다.