TL;DR

  • AI 코딩 에이전트가 구현 작업 상당 부분을 맡으면서, 소프트웨어 엔지니어 한 명이 고객 이해부터 요구사항·아키텍처·설계, 구현 검토와 운영까지 책임지는 역할로 돌아가는 흐름임.
  • 역할 분업이 커지면서 인수인계 때마다 지식이 사라지고 고객 요구가 결과물에 정확히 반영되지 않는 문제가 발생함.
  • AI 시대에는 명세가 단순한 문서가 아니라 코드 생성을 위한 입력이므로, 요구사항 우선 개발(Spec-Driven Development)이 핵심임.
  • 클라우드, 컨테이너, 보안, 컴플라이언스, 관측 가능성 등 시스템 복잡성이 커져 폭넓은 지식과 결과물의 정확성·보안성을 판단하는 역량이 필요함.
  • 팀은 계속 필요하지만 규모는 작아지고 개인의 전체 시스템 책임은 커지며, 기업은 큰 그림을 보는 인재와 명확한 명세에 투자해야 함.

역할 분업이 시작된 과정

  • 1990년대 소프트웨어 엔지니어로 일을 시작했을 때는 IBM 메인프레임에서 코볼(COBOL)을 프로그래밍했고, 이후 클라이언트/서버 애플리케이션이 등장함.
  • 당시에는 기술보다 조직 방식이 단순했으며, 고객과 대화하고 요구사항을 수집하며 아키텍처와 설계를 맡고 코드를 작성한 뒤 애플리케이션의 운영 환경 배포까지 한 사람이 담당함.
  • 프로젝트와 팀 규모가 커지면서 업무가 전문화됨. 비즈니스 분석가가 요구사항을 작성하고, 아키텍트가 아키텍처를 담당하며, 개발자가 구현하고, 테스터가 테스트하고, 운영팀이 제품 환경에 배포하는 구조임.
  • 문서상으로는 효율적으로 보였지만, 인수인계마다 지식이 사라지는 단점이 생김. 개발자는 고객과 직접 대화하지 않고, 아키텍트는 시스템이 운영 환경에서 어떻게 작동하는지 보지 못하며, 고객은 원하는 결과를 정확히 얻지 못하는 경우가 발생함.
  • 애자일(Agile) 방법론은 여러 기능을 갖춘 팀, 짧은 반복 주기, 제품 책임자와의 긴밀한 협업을 통해 문제를 줄이는 데 도움을 줬지만 역할 자체는 유지됐고 인수인계 시간만 짧아짐.

AI가 바꾸는 업무 범위

  • AI 코딩 에이전트가 구현 작업의 상당 부분을 처리하면서 코드와 테스트 작성, 보일러플레이트, 마이그레이션, 매핑을 빠르고 능숙하게 수행함.
  • 그 결과 한 사람이 다음 업무 전반에 시간을 쓸 수 있는 여지가 생김.
  • 고객과 대화하며 문제를 제대로 이해함.
  • 요구사항을 명확히 기술함.
  • 아키텍처와 설계를 정의함.
  • AI가 수행한 구현을 안내하고 검토함.
  • 애플리케이션이 운영 환경에서 안전하고 안정적으로 작동하는지 확인함.
  • 이는 1990년대에 한 사람이 맡았던 역할과 같지만, 더 빠르게 수행하는 형태임.

과거와 달라진 점

  • 명세가 문서에 그치지 않고 입력이 됨. 과거에는 요구사항을 머릿속에 둔 채 고객과 대화한 뒤 곧바로 프로그래밍을 시작해도 됐음. 개발자가 직접 고객과 만났기 때문임.
  • 이제 ‘개발자’ 역할을 AI가 맡지만, AI는 고객 회의에 참석하지 않으므로 전달받은 정보만 알 수 있음. 따라서 명세가 프로젝트에서 가장 중요한 산출물이 됨. 명세가 좋으면 좋은 코드가 나오고, 나쁘면 나쁜 코드가 빠르게 많이 생성됨.
  • 이는 오래된 발상의 연장선임. 코볼은 영어와 거의 비슷하게 보이도록 설계돼 프로그래밍 지식이 없는 비즈니스 담당자도 코드를 읽을 수 있도록 했음. 이제는 자연어로 작성하면 AI가 코드로 변환하는 단계에 도달함.
  • 이것이 요구사항을 먼저 정하고 나머지를 그에 따라 도출하는 요구사항 우선 개발(Spec-Driven Development)의 핵심임. AI 통합 프로세스(AI Unified Process)에서는 코드의 첫 줄을 작성하기 전에 요구사항, 사용 사례, 엔터티 모델을 다룸.
  • 시스템이 더 복잡해짐. 1990년대에는 코볼 프로그램과 터미널을 사용하는 메인프레임이 있었고, 이후에는 데이터베이스 서버와 PC 애플리케이션으로 구성된 클라이언트/서버 환경이 등장했으며, 당시 시스템은 관리 가능한 수준이었음.
  • 오늘날에는 클라우드, 컨테이너, 보안, 컴플라이언스, 관측 가능성 등이 더해져 폭넓은 지식이 필요함.
  • AI가 생성한 코드는 그럴듯해 보일 수 있지만 실제로 정확한지, 안전한지, 아키텍처에 맞는지 판단해야 함. 전체 시스템을 이해하는 사람만이 이를 평가할 수 있음.

새로운 역할: 다시 손을 더럽히는 아키텍트

  • 새로운 역할은 비즈니스를 이해하고 기술을 파악하며, 경험 많은 개발자가 팀을 이끌듯 AI를 안내하는 아키텍트에 가까움.
  • 가장 중요한 역량은 더 이상 문법과 프레임워크가 아님.
  • 고객이 실제로 원하는 것을 듣고 이해함.
  • 사람과 AI가 같은 뜻으로 이해하도록 명확하게 작성함.
  • 아키텍처와 설계가 올바르도록 구조적으로 사고함.
  • 좋은 코드만 운영 환경에 들어가도록 비판적으로 검토함.
  • 이러한 역량은 늘 중요했지만 이제 필수임.

팀에 미치는 영향

  • 팀은 여전히 필요하며, 대규모 시스템을 혼자 구축할 수는 없음.
  • 팀 규모는 작아지고 각 구성원은 다시 전체에 더 큰 책임을 지며, 인수인계와 지식 손실은 줄고 피드백 주기는 빨라지는 흐름임.
  • 기업은 전체를 조망하는 인재와 AI가 구축하는 모든 것의 기반이 되는 명확한 명세에 투자해야 함.

결론

  • 30년간의 전문화 이후 소프트웨어 엔지니어링의 본질인 문제 이해와 좋은 해결책 구축으로 돌아가는 변화를 긍정적으로 바라보는 관점임.
  • 도구는 새롭지만 원리는 오래된 것으로, 핵심은 정보기술을 단순하게 유지하는 것임.