코드는 빨리 만들어지는데, 왜 개발은 더 느려질까

AI가 코드를 쓰기 시작한 시대

지난 몇 년 동안 소프트웨어 개발 환경은 꽤 빠르게 바뀌었다. 특히 AI 코딩 도구의 등장 이후 개발자의 작업 방식은 이전과 비교할 수 없을 정도로 달라졌다. 예전에는 새로운 기능을 구현하려면 먼저 관련 문서를 찾아보고, 라이브러리의 사용법을 하나씩 확인하고, 비슷한 문제를 해결한 사례를 검색하면서 필요한 코드 조각을 직접 만들어야 했다. 이 과정은 생각보다 많은 시간이 걸렸고, 특히 처음 접하는 기술이나 도메인에서는 코드 작성 자체가 가장 큰 장벽이 되기도 했다. 많은 개발자가 하루 중 상당한 시간을 단순히 코드를 작성하는 데 사용했고, 개발 생산성을 높이는 방법 역시 대부분 이 작업을 얼마나 빠르고 정확하게 수행할 수 있는지에 집중되어 있었다.

하지만 AI 코딩 도구가 등장하면서 상황은 상당히 달라졌다. Copilot이나 Cursor 같은 도구를 사용해 본 개발자라면 누구나 비슷한 경험을 했을 것이다. 간단한 설명 몇 줄을 입력하면 AI가 코드 초안을 만들어 주고, 필요하다면 테스트 코드나 예외 처리까지 함께 생성해 주기도 한다. 이전에는 몇 시간 동안 고민하며 작성해야 했던 코드가 이제는 몇 초 만에 화면에 나타난다. 이 경험은 처음 접할 때 꽤 강렬하다. 많은 개발자가 같은 순간에 비슷한 생각을 하게 된다. 이제는 코드 작성 자체가 더 이상 큰 문제가 아닐지도 모른다는 생각이다. 그리고 자연스럽게 다음과 같은 기대가 이어진다. AI가 코드를 이렇게 빠르게 만들어 준다면 개발 속도도 크게 빨라지지 않을까라는 기대다.

실제로 이 기대는 어느 정도 현실적인 근거를 가지고 있다. AI는 반복적인 패턴을 기반으로 코드를 생성하는 데 매우 강하다. 웹 애플리케이션의 기본적인 CRUD 로직이나 API 호출 코드, 데이터 모델 정의 같은 작업은 상당히 높은 정확도로 자동 생성된다. 개발자는 이제 빈 화면에서 코드를 처음부터 작성하기보다는 AI가 생성한 코드를 읽고 수정하는 방식으로 작업을 시작하게 된다. 겉으로 보기에는 개발자의 생산성이 크게 높아진 것처럼 보인다. 그러나 조금 더 시간이 지나고 실제 프로젝트 경험이 쌓이기 시작하면 흥미로운 질문이 등장한다. 코드 작성 속도는 분명히 빨라졌는데, 왜 전체적인 개발 속도는 기대만큼 빨라지지 않는 것처럼 느껴질까. 이 질문은 단순히 체감의 문제가 아니라, 실제 개발 프로세스의 구조와도 깊게 연결되어 있다.

소프트웨어 개발에서 ‘병목’은 어디에 있었는가

이 질문을 이해하려면 먼저 소프트웨어 개발을 하나의 생산 시스템으로 바라볼 필요가 있다. 어떤 시스템이든 전체 속도를 결정하는 지점이 존재한다. 이를 보통 병목(bottleneck) 이라고 부른다. 공장에서 제품을 생산할 때도 마찬가지이고, 물류 시스템에서도 마찬가지다. 아무리 일부 공정이 빠르게 동작하더라도 특정 구간에서 속도가 제한되면 전체 시스템의 처리량은 결국 그 지점에 의해 결정된다. 소프트웨어 개발 역시 크게 다르지 않다. 개발 프로세스는 설계, 구현, 테스트, 리뷰, 배포 같은 여러 단계로 이루어져 있으며, 그중 어느 한 단계가 느려지면 전체 프로젝트의 진행 속도도 자연스럽게 느려지게 된다.

AI 코딩 도구가 등장하기 전까지, 대부분의 개발 조직에서 병목은 비교적 명확한 위치에 있었다. 바로 코드를 작성하는 과정이다. 새로운 기능을 구현하려면 개발자가 직접 로직을 설계하고 코드를 작성해야 했으며, 이 과정은 생각보다 많은 시간이 필요했다. 특히 복잡한 비즈니스 로직이나 새로운 기술 스택을 도입하는 상황에서는 코드 작성 자체가 가장 큰 비용이 되는 경우가 많았다. 그래서 개발자의 숙련도는 자연스럽게 코드 작성 능력과 강하게 연결되었다. 경험 많은 개발자는 문제를 더 빠르게 이해하고 더 안정적인 코드를 작성할 수 있었고, 이 차이가 프로젝트의 생산성에도 직접적인 영향을 주었다.

이러한 구조에서는 개발 생산성을 높이기 위한 노력 역시 대부분 코드 작성 과정을 중심으로 이루어졌다. 더 좋은 프로그래밍 언어를 만들거나, 더 편리한 개발 프레임워크를 도입하거나, 코드 자동 완성 기능을 강화하는 도구들이 등장한 것도 같은 맥락이다. 모든 개선의 목표는 결국 하나였다. 개발자가 코드를 더 빠르고 정확하게 작성할 수 있도록 돕는 것이다. 그래서 오랫동안 소프트웨어 개발에서 가장 중요한 능력은 얼마나 많은 코드를 얼마나 빠르게 작성할 수 있는가로 여겨졌다. 그러나 AI 코딩 도구의 등장 이후 이 전제가 조금씩 흔들리기 시작한다.

AI 코딩 도구가 만든 생산성 착시

AI 코딩 도구를 처음 사용해 본 개발자들은 대체로 비슷한 경험을 이야기한다. 코드를 작성하는 과정이 훨씬 가벼워졌다는 느낌이다. 예전에는 기능 하나를 구현하기 위해 수십 줄의 코드를 직접 작성해야 했지만, 이제는 AI가 먼저 코드를 생성하고 개발자는 그것을 수정하는 방식으로 작업이 시작된다. 화면에 빠르게 나타나는 코드와 자동으로 생성되는 함수 구조를 보면 자연스럽게 생산성이 크게 높아진 것처럼 느껴진다. 실제로 많은 개발자가 AI 도구를 처음 사용할 때 강한 속도감을 경험한다. 마치 개발이 훨씬 빠르게 진행되고 있는 것처럼 보이기 때문이다.

하지만 이 경험에는 일종의 생산성 착시가 존재한다. 코드를 작성하는 속도는 확실히 빨라졌지만, 그것이 전체 개발 과정의 속도를 동일하게 끌어올리는 것은 아니다. AI가 생성한 코드는 대부분 초안에 가깝다. 코드가 문법적으로는 맞더라도 프로젝트의 실제 구조나 기존 시스템과 완전히 일치하지 않는 경우가 많다. 그래서 개발자는 결국 그 코드를 읽고, 이해하고, 필요한 부분을 수정해야 한다. 때로는 AI가 생성한 코드의 의도를 파악하는 데 예상보다 더 많은 시간이 필요하기도 한다. 특히 프로젝트 규모가 커질수록 이 과정은 더 복잡해진다.

또한 AI는 개별 코드 조각을 생성하는 데는 뛰어나지만, 전체 시스템의 맥락을 완전히 이해하지는 못한다. 예를 들어 특정 기능을 구현하는 코드를 생성할 수는 있지만, 그 코드가 기존 아키텍처와 어떻게 연결되는지, 장기적인 유지보수에 어떤 영향을 미칠지는 판단하기 어렵다. 그래서 개발자는 AI가 생성한 코드를 그대로 사용하는 대신, 그것이 실제 시스템에 적합한지 하나씩 확인해야 한다. 이 과정에서 코드 생성으로 절약된 시간이 다시 검증과 수정 과정으로 이동하게 된다. 결과적으로 개발자는 여전히 많은 시간을 코드와 씨름하고 있지만, 그 작업의 성격이 조금 달라졌을 뿐이다.

이 지점에서 중요한 질문이 다시 등장한다. AI 덕분에 코드 작성 속도가 크게 빨라졌다면, 왜 개발 과정 전체는 생각만큼 빨라지지 않을까. 이 질문에 답하려면 이제 개발 과정에서 실제로 어떤 변화가 일어나고 있는지 조금 더 자세히 살펴볼 필요가 있다. 다음 섹션에서는 실제 연구 사례를 통해 AI 코딩 도구가 개발 속도에 어떤 영향을 미쳤는지 살펴보고, 그 과정에서 나타난 예상 밖의 결과들을 분석해 보려고 한다.

실제 연구 사례: AI를 써도 개발이 빨라지지 않았다

AI 코딩 도구가 개발 생산성을 높인다는 기대는 매우 강력했다. 실제로 많은 기술 기업과 연구 기관이 AI가 개발 속도를 얼마나 개선할 수 있는지 측정하려는 실험을 진행했다. 그런데 흥미로운 점은, 일부 연구 결과가 개발자들의 직관적인 기대와 완전히 일치하지 않았다는 것이다. 특히 최근 몇 년 사이 발표된 연구 중에는 AI 도구를 사용했음에도 작업 속도가 크게 개선되지 않거나, 오히려 일부 작업에서는 더 느려지는 결과가 보고되기도 했다.

대표적으로 자주 언급되는 사례 중 하나가 METR(Model Evaluation & Threat Research) 연구다. 이 연구에서는 실제 소프트웨어 개발 과제를 수행하는 개발자들을 대상으로 AI 코딩 도구의 영향을 분석했다. 연구진은 개발자들에게 동일한 작업을 수행하도록 하고, 일부 그룹에는 AI 도구를 제공하고 다른 그룹에는 제공하지 않는 방식으로 실험을 진행했다. 결과는 꽤 흥미로웠다. AI를 사용한 개발자들은 코드 생성 속도 자체는 확실히 빨랐지만, 전체 작업 완료 시간은 기대만큼 단축되지 않았다. 일부 경우에는 오히려 더 많은 시간이 소요되기도 했다. 이는 AI가 생성한 코드가 완벽하지 않기 때문에, 개발자가 추가적으로 검증하고 수정하는 과정이 필요했기 때문이다.

이 결과는 단순히 AI 성능의 문제라기보다는 개발 과정의 구조와 더 깊이 연결되어 있다. AI는 빠르게 코드를 만들어 주지만, 그 코드가 실제 시스템에서 정확하게 동작하는지 확인하는 과정은 여전히 인간의 책임이다. 그리고 그 검증 과정은 생각보다 많은 시간을 요구한다. 개발자는 AI가 생성한 코드를 읽어야 하고, 그 코드가 기존 시스템과 충돌하지 않는지 확인해야 하며, 예상하지 못한 오류가 발생할 가능성까지 고려해야 한다. 결국 AI가 코드 작성 시간을 줄여 주는 만큼, 그 이후 단계에서의 검토 비용이 늘어나는 구조가 나타나게 된다. 이 현상은 특히 대규모 코드베이스에서 더 두드러지게 나타난다.

이 연구 결과가 중요한 이유는 AI 코딩 도구의 한계를 보여주기 때문이 아니다. 오히려 더 중요한 메시지는 개발 속도를 결정하는 요소가 단순히 코드 작성 속도가 아니라는 사실이다. 코드 생성이 빨라졌다고 해서 개발 전체가 동일한 속도로 빨라지는 것은 아니다. 개발 과정에는 코드 작성 외에도 수많은 단계가 존재하고, 그중 일부 단계는 AI로 쉽게 자동화하기 어렵다. 그래서 AI가 등장한 이후 개발 프로세스의 병목은 예상치 못한 방향으로 이동하기 시작했다.

새로운 병목: 코드 리뷰와 코드 이해

AI 코딩 도구가 만들어 낸 가장 큰 변화 중 하나는 코드 생성의 속도다. AI는 몇 초 만에 수십 줄, 때로는 수백 줄의 코드를 생성할 수 있다. 예전에는 개발자가 직접 작성해야 했던 코드 구조와 함수 정의, 예외 처리 로직까지 빠르게 생성된다. 이 속도는 인간 개발자의 작업 속도와 비교하면 매우 빠르다. 그러나 이 지점에서 중요한 문제가 발생한다. 코드를 생성하는 속도와 코드를 이해하는 속도는 완전히 다른 문제라는 점이다.

AI는 코드를 매우 빠르게 만들어 낼 수 있지만, 인간이 그 코드를 이해하는 속도는 크게 변하지 않는다. 개발자는 여전히 코드를 한 줄씩 읽고, 그 로직이 무엇을 하는지 파악해야 한다. 특히 AI가 생성한 코드가 프로젝트의 기존 구조와 어떻게 연결되는지 확인하는 과정은 상당한 집중력을 요구한다. 코드의 길이가 길어질수록 이 작업은 더 어려워진다. AI는 코드 생성 속도를 수십 배까지 높일 수 있지만, 인간의 코드 이해 속도는 그렇게 쉽게 증가하지 않는다.

이로 인해 개발 과정에서 새로운 병목이 등장한다. 바로 코드 리뷰와 코드 이해 과정이다. 예전에는 개발자가 직접 작성한 코드를 리뷰했기 때문에 코드의 의도를 비교적 쉽게 이해할 수 있었다. 하지만 AI가 생성한 코드는 그 작성 과정이 인간에게 완전히 투명하지 않다. 개발자는 코드가 어떻게 만들어졌는지보다, 그 코드가 무엇을 하는지부터 다시 분석해야 한다. 이 과정에서 개발자는 AI가 생성한 코드의 의도를 역으로 추적하게 된다. 이는 기존 코드 리뷰보다 더 많은 인지적 부담을 요구할 수 있다.

또한 코드 리뷰 과정에서도 새로운 문제가 등장한다. AI는 매우 많은 코드를 빠르게 생성할 수 있기 때문에, 리뷰해야 할 코드의 양 자체가 늘어날 가능성이 높다. 개발자는 더 많은 코드를 더 짧은 시간 안에 검토해야 하는 상황에 놓이게 된다. 결국 코드 생성 단계에서는 시간이 절약되지만, 그 이후 단계에서는 오히려 더 많은 시간이 필요해질 수 있다. 이 변화는 개발 생산성의 핵심이 어디에 있는지를 다시 생각하게 만든다. AI 시대의 개발 속도는 더 이상 코드 작성 능력만으로 결정되지 않는다.

AI 코드의 또 다른 문제: 맥락 부족

AI가 생성하는 코드에는 또 하나의 중요한 특징이 있다. AI는 코드 패턴을 매우 잘 학습하지만, 프로젝트의 전체 맥락을 완전히 이해하지는 못한다는 점이다. 이는 AI 모델의 구조적인 한계와도 관련이 있다. AI는 방대한 코드 데이터를 기반으로 패턴을 학습하고, 주어진 프롬프트에 맞는 코드를 생성한다. 이 방식은 특정 기능을 구현하는 데는 매우 효과적이다. 하지만 실제 소프트웨어 시스템은 단순한 코드 조각들의 집합이 아니라, 수많은 구조와 규칙이 얽혀 있는 복잡한 시스템이다.

예를 들어 하나의 API를 구현하는 코드를 생각해 보자. AI는 HTTP 핸들러를 만들고, 데이터베이스 쿼리를 작성하고, 응답을 반환하는 코드를 생성할 수 있다. 그러나 그 코드가 프로젝트의 아키텍처 규칙과 정확히 맞는지는 별개의 문제다. 어떤 프로젝트는 특정한 레이어 구조를 사용하고 있을 수 있고, 또 다른 프로젝트는 특정한 에러 처리 패턴이나 로깅 규칙을 요구할 수도 있다. AI는 이러한 규칙을 일부 학습할 수는 있지만, 프로젝트마다 존재하는 수많은 암묵적인 설계 원칙까지 완전히 이해하기는 어렵다.

그래서 AI가 생성한 코드는 종종 겉보기에는 그럴듯하지만, 실제 시스템에서는 미묘하게 어긋나는 경우가 발생한다. 코드 스타일이 맞지 않거나, 데이터 흐름이 기존 구조와 다르게 설계되거나, 특정한 성능 고려사항이 빠져 있는 경우도 있다. 이러한 문제는 코드 자체의 오류라기보다는 시스템 맥락과의 불일치에서 발생한다. 결국 개발자는 AI가 생성한 코드를 단순히 검토하는 수준을 넘어, 그것이 시스템 구조와 얼마나 잘 맞는지 판단해야 한다.

이 과정에서 개발자의 역할은 단순한 코드 작성자가 아니라 일종의 시스템 편집자(system editor) 에 가까워진다. 개발자는 AI가 만들어 낸 코드 조각을 프로젝트의 구조에 맞게 수정하고 재구성해야 한다. 그리고 이 작업은 생각보다 많은 시간과 집중력을 요구한다. AI가 코드 작성 속도를 높였다는 사실은 분명하지만, 동시에 개발자가 수행해야 할 판단 작업의 양도 함께 증가하고 있다. 그래서 AI 시대의 개발 생산성 문제는 단순히 기술의 문제가 아니라, 개발 과정의 구조 자체가 어떻게 변화하고 있는가라는 질문과 연결된다.

이제 다음 단계에서 중요한 질문이 등장한다. AI가 등장하면서 코드 작성의 부담은 줄어들었지만, 개발자의 역할은 어떤 방향으로 이동하고 있을까. 그리고 이러한 변화는 개발자의 역량과 개발 조직의 구조에 어떤 영향을 미치게 될까. 다음 섹션에서는 이러한 변화가 실제로 개발자의 역할을 어떻게 재정의하고 있는지 살펴보려고 한다.

개발자의 역할은 코드 작성에서 판단으로 이동한다

지금까지 살펴본 변화들을 종합해 보면 하나의 중요한 흐름이 보이기 시작한다. AI는 코드 생성 능력을 크게 확장했지만, 동시에 개발 과정에서 인간이 수행해야 하는 작업의 성격도 함께 바꾸고 있다는 점이다. 과거의 개발자는 주로 코드를 직접 작성하는 역할을 수행했다. 기능을 구현하기 위해 필요한 로직을 설계하고, 알고리즘을 선택하고, 실제 코드로 옮기는 과정이 개발자의 핵심 작업이었다. 그래서 개발자의 역량은 자연스럽게 얼마나 정확하고 효율적으로 코드를 작성할 수 있는가와 밀접하게 연결되어 있었다.

하지만 AI 코딩 도구가 등장하면서 이 구조는 조금씩 달라지고 있다. AI는 기본적인 코드 구조를 빠르게 생성할 수 있고, 많은 경우 그 코드의 품질도 꽤 높은 편이다. 그래서 개발자는 점점 더 코드를 직접 작성하는 사람이 아니라 코드를 선택하고 수정하는 사람에 가까워지고 있다. 이 변화는 단순한 작업 방식의 변화가 아니라 개발자의 역할 자체가 이동하고 있다는 신호이기도 하다. 개발자는 이제 AI가 생성한 여러 코드 후보 중에서 어떤 것이 시스템에 가장 적합한지 판단해야 하고, 필요하다면 코드 구조를 다시 설계해야 한다.

이 과정에서 중요한 능력은 코드 작성 능력보다 시스템을 이해하고 판단하는 능력이 된다. 예를 들어 동일한 기능을 구현하는 코드라도 시스템의 구조에 따라 전혀 다른 방식이 더 적합할 수 있다. 어떤 코드는 성능 측면에서 유리하고, 어떤 코드는 유지보수 측면에서 더 나을 수도 있다. AI는 이러한 선택을 완전히 대신해 줄 수 없다. 결국 개발자는 AI가 만들어 낸 가능성들 사이에서 최적의 선택을 해야 한다. 그래서 AI 시대의 개발자는 점점 더 코드 생산자(code producer) 가 아니라 코드 큐레이터(code curator) 에 가까워지고 있다.

이러한 변화는 개발자의 역량 구조에도 영향을 미친다. 예전에는 특정 언어의 문법이나 프레임워크 사용법을 얼마나 잘 알고 있는지가 중요한 경쟁력이었다. 하지만 앞으로는 시스템 설계, 문제 구조화, 기술 선택, 장기적인 유지보수 전략을 판단하는 능력이 더 중요한 역할을 하게 될 가능성이 높다. AI는 코드를 생성할 수 있지만, 어떤 시스템이 더 좋은 구조를 가지는지에 대한 판단은 여전히 인간의 영역에 남아 있기 때문이다. 그래서 AI가 코드 생산을 가속할수록 개발자의 역할은 오히려 더 높은 수준의 판단으로 이동하게 된다.

AI 시대의 개발 조직은 어떻게 바뀔까

개발자의 역할 변화는 개인의 업무 방식에만 영향을 주는 것이 아니다. 이러한 변화는 결국 개발 조직의 구조에도 영향을 미치게 된다. 과거의 소프트웨어 조직에서는 일정 규모의 개발 인력을 통해 코드를 작성하고 기능을 구현하는 것이 핵심적인 생산 활동이었다. 프로젝트가 커질수록 더 많은 개발자가 필요했고, 조직의 생산성은 종종 얼마나 많은 코드를 얼마나 빠르게 작성할 수 있는가에 의해 결정되었다. 그래서 많은 조직이 코드 작성 능력이 뛰어난 개발자를 중심으로 팀을 구성했다.

하지만 AI 코딩 도구가 코드 생성 능력을 크게 확장하면서, 조직에서 필요한 역량의 균형도 조금씩 바뀔 가능성이 있다. 코드 자체를 만드는 작업은 점점 더 자동화될 수 있지만, 시스템의 방향을 결정하고 기술적인 선택을 하는 역할은 여전히 인간이 담당해야 한다. 그래서 개발 조직은 단순히 코드 작성 인력을 늘리는 방식보다는 시스템 설계와 기술 판단을 담당하는 역할을 더 중요하게 생각하게 될 수 있다. 이는 조직 구조에서도 변화로 나타날 가능성이 있다.

예를 들어 일부 조직에서는 이미 아키텍처 중심의 개발 문화를 강화하려는 움직임이 나타나고 있다. 코드 작성 자체보다는 시스템 구조를 먼저 정의하고, 그 구조 위에서 코드가 생성되도록 하는 방식이다. 이러한 접근은 AI 도구와도 비교적 잘 맞는다. AI는 명확한 구조와 규칙이 존재할 때 훨씬 안정적인 코드를 생성할 수 있기 때문이다. 반대로 시스템의 구조가 명확하지 않은 환경에서는 AI가 생성한 코드가 프로젝트의 방향과 충돌할 가능성이 높아진다.

또한 코드 리뷰 문화 역시 변화할 가능성이 있다. 예전에는 리뷰의 중심이 코드 품질이나 스타일에 있었다면, 앞으로는 코드가 시스템의 구조와 얼마나 잘 맞는지, 장기적인 유지보수에 어떤 영향을 미칠지 같은 설계 수준의 질문이 더 중요해질 수 있다. 이는 개발 조직이 단순한 코드 생산 조직에서 시스템 설계와 판단 중심의 조직으로 이동하고 있다는 신호일 수도 있다. 그리고 이러한 변화는 결국 개발자의 역할뿐 아니라 소프트웨어 산업 전체의 구조에도 영향을 줄 가능성이 있다.

코드가 아니라 시스템을 만드는 시대

이제 처음의 질문으로 다시 돌아와 볼 수 있다. AI 코딩 도구 덕분에 코드 작성 속도는 분명히 빨라졌다. 그러나 개발 전체가 같은 속도로 빨라지지는 않았다. 그 이유는 개발이라는 작업이 단순히 코드를 작성하는 과정이 아니라, 훨씬 더 복잡한 의사결정과 설계의 과정이기 때문이다. AI는 코드 생성이라는 특정 단계의 속도를 크게 높였지만, 시스템 설계와 기술 판단 같은 단계는 여전히 인간의 역할로 남아 있다. 그래서 개발 프로세스의 병목은 자연스럽게 코드 작성에서 판단과 설계의 영역으로 이동하고 있다.

이 변화는 소프트웨어 개발이라는 작업의 본질을 다시 생각하게 만든다. 우리는 오랫동안 개발자를 코드를 작성하는 사람으로 이해해 왔다. 하지만 실제로 소프트웨어 개발에서 가장 중요한 작업은 코드 자체가 아니라 시스템을 설계하고 문제를 구조화하는 과정일지도 모른다. 코드는 그 구조를 구현하는 수단일 뿐이며, 시스템의 방향을 결정하는 것은 결국 인간의 판단이다. AI가 코드 생산 능력을 크게 확장한 지금, 오히려 이 사실이 더 분명하게 드러나고 있다.

그래서 AI 시대의 개발자는 단순히 더 많은 코드를 빠르게 작성하는 사람이 아니라, 더 나은 시스템을 설계하고 더 좋은 기술적 선택을 할 수 있는 사람이 될 가능성이 높다. 코드 생성 능력이 확장될수록 이러한 판단 능력의 중요성은 더욱 커질 것이다. 그리고 이 변화는 개발자 개인뿐 아니라 소프트웨어 조직 전체의 구조에도 영향을 미칠 수 있다. 앞으로의 개발 환경에서는 코드의 양보다 결정의 질이 더 중요한 경쟁력이 될 가능성이 있다.

이 지점에서 자연스럽게 다음 질문이 이어진다. 만약 개발자의 핵심 역할이 코드 작성에서 판단으로 이동하고 있다면, AI 시대의 개발 조직은 어떤 구조를 가지게 될까. 그리고 코드 생산 능력이 크게 확장된 환경에서 개발 팀의 역할 분담은 어떻게 달라질까. 다음 글에서는 이러한 변화가 실제 개발 조직의 구조를 어떻게 바꾸고 있는지, 그리고 앞으로 어떤 형태의 개발 조직이 등장할 가능성이 있는지 살펴보려고 한다.