TL;DR

  • 인공지능(AI) 활용은 전면 위임과 전면 거부의 양자택일이 아니며, 소프트웨어 엔지니어링에서는 인간과 기계가 서로 잘하는 일을 나누는 협업이 핵심임.
  • 프로그래밍을 에이전트에 완전히 맡기면 문제 해결을 통해 쌓이는 엔지니어의 직관이 약해질 수 있음.
  • 에이전트의 모든 작업을 옆에서 감독하면 같은 일을 병렬로 반복하게 되어 소진으로 이어질 수 있음.
  • 인간은 문제 이해와 설계, 판단, 검토, 복잡한 코드 작성과 디버깅을 맡고, AI 도구는 반복 코드와 테스트, 문서 검색, 명확히 정의된 구성 요소 구현 등을 맡을 수 있음.
  • 코드 생산량보다 작업 인계의 품질이 중요하며, 협업 방식에는 실험과 규율, 자신의 한계에 대한 정확한 이해가 필요함.

텔레비전 앞의 트레이너

  • 첫 번째 가능성은 달리기를 멈춘 주자가 소파에서 로봇의 달리기를 지켜보며 무릎을 더 높이 들고, 보폭을 늘리고, 더 규칙적으로 호흡하라고 지시하는 방식임.
  • 로봇은 주자처럼 운동을 이해하지 못하므로 정확한 지시가 필요하며, 개선할 때마다 새롭고 구체적인 명령으로 바꿔야 함. 지시가 점점 구체화될수록 설명과 수행이 모두 어려워짐.
  • 주자는 더는 훈련하지 않아 능력이 떨어지고, 로봇이 하는 일을 이해하기도 어려워짐. 달리기에 관한 이론은 남아 있어도 운동의 신체적 감각을 잃게 됨.
  • 지식은 있지만 실천하지 않는 이 트레이너는 결국 지식과 훈련 능력을 모두 잃게 됨.
  • 엔지니어가 프로그래밍을 완전히 위임하고 에이전트의 코드 생성을 지켜보기만 하면, 지시는 할 수 있어도 문제 해결로 형성되는 직관은 서서히 사라질 수 있음.

함께 달리기

  • 두 번째 가능성은 주자와 로봇이 같은 코스를 동시에 달리며, 주자가 로봇을 훈련시키는 동시에 로봇을 이기려는 방식임.
  • 주자는 달리고, 로봇을 관찰하고, 동작을 고치고, 성과를 비교하는 일을 계속해야 하므로 지침. 주자도 같은 코스를 달려야 한다면 로봇을 훈련시키는 목적도 불분명해짐.
  • AI 도구에 기능 구현을 맡기면서 모든 코드 줄과 결정, 생성 파일을 곁에서 감독하는 방식도 이와 같음. 직접 일을 하면서 같은 일을 병렬로 수행하는 또 다른 작업자까지 감독하게 됨.
  • 로봇이 하나가 아니라 열 대라면 대체로 소진으로 이어짐. 결과가 쓸모 있을 수는 있지만 주자의 건강을 대가로 치르는 매우 비싼 코드 생산 방식일 수 있음.

경기 방식 바꾸기

  • 세 번째 가능성은 주자와 로봇이 같은 코스에서 경쟁하는 대신 경기 방식을 바꾸는 것임. 개인 100미터 경주를 계주로 바꾸면 주자와 로봇이 일을 나눠 맡고, 바통을 주고받으며 승리를 위해 서로를 필요로 함.
  • 이는 타협이 아니라 다른 경기임. 주자도 훈련을 이어가고 로봇도 훈련함.
  • 주자는 경주를 이해할 책임을 유지하되 로봇이 잘 달릴 수 있는 구간을 중복해서 달리느라 힘을 낭비하지 않음. 로봇은 인간 주자가 될 필요 없이 계주의 자기 구간을 잘하면 됨.
  • AI 협업에서도 엔지니어는 문제 이해, 아키텍처 설계, 상충 관계 판단, 결과 검토, 가장 복잡한 코드 작성, 계획과 현실이 어긋날 때의 디버깅을 맡을 수 있음.
  • AI 도구는 대안 탐색, 반복 코드 작성, 테스트 준비, 문서 검색, 엔지니어가 다른 문제를 다루는 동안 명확히 정의된 구성 요소 구현을 맡을 수 있음.

사라진 중간 지대

  • 인터넷에서 흔히 홍보되는 방식은 아님. 양자택일식 입장은 설명하기 쉽고 판매하기 쉬워 논의도 양극단으로 흐르기 쉬움.
  • 한쪽은 AI가 소프트웨어 엔지니어를 쓸모없게 만들 것이라 하고, 다른 쪽은 AI 사용을 거부하며 생성된 코드 한 줄 한 줄을 기술 자체에 대한 공격으로 여기기도 함.
  • 양쪽 모두 인간과 기계가 어떤 일을 함께 해야 하는지라는 실용적 질문을 놓칠 수 있음.
  • Michael Hashimoto는 AI 도입에 관한 글에서 더 흥미로운 여정을 설명함. 모든 AI 도구를 즉시 받아들이거나 영원히 거부하지 않고, 자신의 작업을 재현해 보며 에이전트가 유용한 경우와 시간 낭비인 경우를 파악하고 검증을 중심으로 작업 흐름을 구축함.
  • David Heinemeier Hansson(DHH)은 최근 Rails World에서 훨씬 더 급진적인 입장을 설명함. 해당 보도에 따르면 37signals는 AI 에이전트를 기본 코드 생성 도구로 취급하며, 코드를 직접 작성하는 일은 예외적인 활동이 됨.
  • 이런 방식은 일부 작업에서 생산적일 수 있음. 그러나 코드 생산량만을 유일한 지표로 삼는다면 이미 잘못된 경기를 선택한 것임.
  • 소프트웨어 엔지니어링은 초당 가장 많은 문자를 생산하는 사람이 이기는 100미터 경주가 아님. 각 주자의 속도만큼이나 인계의 품질이 중요한 계주에 훨씬 가까움.
  • 어려운 부분은 코드 생산만이 아니라 무엇을 왜 만들어야 하는지, 결과가 잘못됐을 때 어떻게 알아차릴지를 판단하는 일임.
  • DHH가 패배자라고 생각하지는 않지만, 그의 결론은 시대에 뒤처져 있음. 여전히 소프트웨어 엔지니어링을 최대 생산량을 겨루는 경주로 보고 있음.

협업으로서의 접근

  • 협업 방식에는 작업 흐름의 변화가 필요함.
  • 기계의 결과물을 이해할 만큼 스스로 훈련해야 함. 검증할 수 있을 만큼 명확하면서도 시간을 절약할 만큼 의미 있는 작업을 맡겨야 함. 경기의 모든 구간을 위임하는 대신 어려운 코스는 직접 달려야 함.
  • 양자택일을 고르는 것보다 어려운 접근임. 실험과 규율, 자신의 한계에 대한 정확한 이해가 필요함.
  • 이 일을 올바르게 처리하는 사람을 알고 있지는 않음. 엔지니어링의 미래는 AI를 가장 많이 쓰는 사람이나 완전히 거부하는 사람에게 속하지 않을 수 있음.
  • 대신 경기 방식을 바꾸는 법을 배우는 사람에게 미래가 속할 수 있음.