TL;DR

  • AI가 구현 비용을 거의 제로에 가깝게 낮추는 상황에서 소프트웨어 엔지니어링의 핵심은 무엇을 만들지, 어떤 명세와 제약을 둘지, 에이전트를 어떻게 운영하고 결과를 검증할지로 이동함.
  • 지난 9~10개월 동안 설계와 구현을 AI에 더 많이 맡기면서 기존의 업무 방식이 완전히 끝났다고 받아들였으며, 검증 가능한 대부분의 소프트웨어 엔지니어링 작업은 강화학습 검증(RLVR) 대상이 될 수 있다고 봄.
  • 구현 비용이 낮아질수록 단기적으로 가치 있는 일은 해결할 문제와 제품의 형태를 정하는 일이며, 제품의 설명·형태·명세를 작성하는 일 자체가 사실상 코드 작성에 해당함.
  • 에이전트에 일을 맡기기 전 모호성 제거, 작업의 경계와 종료 조건 지정, 결정론적 하네스와 가드레일 설정이 필요함.
  • 코드 리뷰만으로 검증하기 어려운 결과물은 전문성이 부족한 영역일수록 종합적인 블랙박스 테스트로 위험을 줄여야 하며, 문제 해결·코딩·시스템 설계의 비중은 줄어드는 중임.

AI로 바뀐 업무 인식

  • 지난 9~10개월 동안 설계와 구현을 점점 더 많이 AI에 위임하면서 이전의 업무 생활은 완전히 끝났다고 받아들임. 이는 DHH가 Rails World 2026에서 이야기하기 훨씬 전의 일이며, 상실의 5단계를 모두 거침.
  • AI 회의론자들은 AI가 소프트웨어 엔지니어링(SWE) 업무를 가져간다고 말하는 사람들이 간단한 백엔드·프런트엔드가 있는 CRUD 앱만 만든다고 생각하는 경우가 많음.
  • 실제 업무는 GPU와 TPU에서 대형 언어 모델(LLM)의 학습과 추론 성능을 개선하는 일임. 검증 가능한 작업은 대부분 RLVR 대상이 될 수 있으며 AI가 쉽게 다룰 수 있는 영역임.
  • 최근의 어려운 사례인 나비에-스토크스 문제에서는 에이전트 1만 개가 88시간 동안 병렬로 다양한 아이디어를 시도함. 일상적인 설계와 구현 문제가 나비에-스토크스 증명보다 더 어렵다고 보지 않음.
  • 이 모든 상황을 인간으로서 어떻게 느끼는지에 대해서는 별도의 글을 쓸 필요가 있지만, 여기서는 향후 업무의 방향을 다룸.
  • 현재 AI 환경에서는 1년이 5년과 같으므로, 1년을 넘는 미래를 예측하는 데는 자신이 없음. 아래 전망은 향후 1년 안에 타당하다고 보는 내용임.

제품 관리

  • 이 변화에서 가장 기대되는 부분은 구현 비용이 거의 제로에 가까워지고 있다는 점임. 에이전트 하나 또는 여러 에이전트의 조합으로 개인의 틈새 용도에 맞는 Electron 앱부터 나비에-스토크스 문제 해결까지 다양한 작업이 가능하며, 후자는 현재 비용이 매우 큼.
  • 더 이상 설계와 구현 비용에 크게 제한받지 않으며, 주된 한계는 상상력이라고 느낌. 지나치게 많이 생각하거나 완벽주의 성향이 있으면 시작 비용이 두 배로 늘어나지만, AI 생산성은 이 문제도 상당 부분 줄여줌. 이는 매우 큰 힘을 부여하는 변화임.
  • 구현과 문제 해결 비용이 하락하는 세상에서 단기적으로 가치가 남는 일은 무엇을 해결하고 만들지, 어떤 형태로 만들지 결정하는 일임.
  • 구현 비용이 병목이 아니라면 무엇을 만들지 질문하게 됨.
  • 제품과 그 형태, 명세를 설명하기 시작하는 순간 사실상 코드를 작성하는 것과 같음.

소프트웨어 엔지니어링

  • 만들 제품을 정했다고 가정해도, 여기서 제품은 앱 같은 실제 종단 간 제품일 수도 있고 Google Cloud TPU에서 학습·추론 성능을 개선하는 목표일 수도 있음.
  • “목표 X를 달성하라” 또는 “제품 Y를 만들어라”처럼 모호한 프롬프트를 주는 시도는 크게 실패함.
  • 예를 들어 Google Cloud TPU에서 모델 X의 추론 성능을 개선하려면 먼저 최적화 대상이 무엇인지 구체화해야 함.

모호성

  • 작업을 AI에 맡기기 전에 모든 모호성을 파악해야 함.
  • “추론 성능 최적화”가 정확히 무엇을 뜻하는지, 에이전트가 무엇을 최적화해야 하는지, 어떤 워크로드와 목적 함수를 사용할지, 어떤 모델과 하드웨어를 대상으로 할지 정해야 함.
  • 에이전트가 언제 작업을 멈출지와 종료 조건을 정해야 함.
  • 에이전트가 절대 넘지 말아야 할 경계와 양자화를 허용할지, 허용한다면 어느 수준까지 허용할지 지정해야 함.
  • 에이전트 작업에서는 모호성이 조금이라도 남으면 문제가 생길 수 있음. 몇 주 동안 지시를 개선해 모든 모호성을 제거하고 명확한 경계를 설정했다고 생각했지만, 에이전트가 추측 디코딩의 수용 길이를 늘리려고 모델 일부를 재학습하는 상황이 발생함.
  • 추론 최적화에서는 모델을 재학습하지 않고 고정된 상태로 둔다는 전제가 있었으며, 추가 양자화는 고려할 수 있었음. 에이전트가 요청 없이 재학습할 수 있다는 점을 예상하지 못해 작업을 처음부터 제한하지 못함.
  • 그 결과 에이전트 작업 시간 몇 시간이 낭비되고 회사 자원이 소모됨.

하네스와 가드레일

  • 작업에 따라 에이전트의 특정 동작을 결정론적으로 강제해야 할 수 있음.
  • 성능 최적화 에이전트라면 변경 사항을 커밋하기 전에 correctness.sh를 실행해 모델 품질이 저하되지 않았는지 확인하도록 강제해야 함.
  • 프롬프트로 요청할 수는 있지만 에이전트가 반드시 따르리라는 보장은 없음. 자동으로 자주 압축되는 장시간 세션에서는 특히 그러함.

검증

  • 에이전트가 결과를 전달하면 이를 어떻게 검증할지 정해야 함.
  • 중요한 작업이 아니라면 AI가 작성한 코드를 검토하는 일의 관련성은 점점 낮아지고 있다고 봄. 이 경우 AI의 생산성 향상 배수는 사람의 코드 리뷰 속도에 막힘.
  • AI가 팀의 전문성을 벗어난 코드를 다루면 문제가 더 심각해짐. 최근에는 AI가 잘 알려지지 않은 특정 GPU 하드웨어용 서드파티 라이브러리의 커널을 작성했으며, 일부에는 PTX 코드도 포함됨.
  • 해당 GPU 아키텍처와 PTX 코드 어느 쪽에도 전문가가 아니었지만 에이전트의 변경 사항은 성능을 크게 개선함.
  • 선택지는 해당 분야의 전문가가 되기 위해 많은 시간을 쓰거나, 생산성을 확보하기 위해 종합적인 블랙박스 테스트로 위험을 줄이는 것이었음. 후자의 위험은 전문가가 검토하는 경우보다 여전히 큼.
  • 내부 세부사항을 실제로 이해하지 않고도 블랙박스가 예상대로 동작하는지 확인하는 방법이 검증 과제임.

교훈

  • AI 이전의 소프트웨어 엔지니어링 경력을 경험한 점은 만족스럽지만, 과거의 문제 해결·코딩·시스템 설계는 모두 사라지고 있다고 봄. 이를 받아들였으며, 구현 비용은 이제 저렴함.
  • 이제 중요한 일은 무엇을 구현할지(제품), 어떤 형태와 동작으로 구현할지(명세와 제약), 에이전트가 효율적으로 작업하도록 어떻게 할지(하네스와 가드레일), 결과를 어떻게 검증·확인할지 결정하는 것임.
  • 안타깝게도 문제 해결 자체의 비중은 줄어드는 중임.