불확실성의 시대, 개발자가 기준 삼아야 할 것들
이 글은 Pragmatic Engineer 뉴스레터 The Pulse #131: Why is every company launching its own coding agent?을 바탕으로 작성되었습니다.
각 기업이 앞다투어 '코딩 에이전트'를 내놓는 흐름 속에서, 실무에서의 경험과 맞닿는 지점을 짚어보고, AI 시대의 소프트웨어 설계와 개발 문화가 어떻게 달라지고 있는지에 대해 사유해 본 글입니다.
코딩 에이전트, 왜 지금 여기까지 왔는가
이번 호 뉴스레터에서는 Canva, X(구 트위터), OpenAI, WordPress까지 단 일주일 사이에 모두 ‘코딩 에이전트’를 출시했다는 이야기를 다룹니다.
이 흐름은 단순한 유행이 아니라, 하나의 ‘기술적 전환점’을 시사합니다.
예전에는 '코딩을 자동화한다'는 개념이 실현되기 어려운 이상향 같았지만, 지금은 오픈소스 LLM, API 툴킷, IDE 연동 기술의 발전으로 “에이전트를 만드는 것 자체는 더 이상 어려운 일이 아니다”라는 단계까지 도달한 것입니다.
하지만 ‘누구나 만들 수 있다’는 말과 ‘누구나 잘 만들 수 있다’는 말은 다릅니다.
실무 개발자로서 느낀 진짜 문제는 ‘기술’이 아니라 ‘설계’
저는 스타트업에서 실제로 AI 기반 자동화 기능을 만들고 도입하는 경험을 하고 있습니다. 이 과정에서 느낀 건 다음과 같습니다.
에이전트를 만드는 데 필요한 기술 자체는 오픈된 상태지만,
그것을 “어떤 흐름에서, 누구의 문제를 해결하기 위해, 어떤 책임을 가지고 설계할 것인가”는 전혀 다른 문제입니다.
AI 시대의 소프트웨어 설계는 단순한 기능 나열이 아니라,
"에이전트가 사용자의 의도를 어떻게 파악하고, 어떤 경계 내에서 행동하며, 실패했을 때는 어떻게 복구할 것인가"라는 구조적 설계가 핵심입니다.
이런 부분은 모델 성능이나 UI 수준만으로는 해결되지 않습니다.
실제 팀 협업과 도메인 지식, 사용자 피드백을 반영한 반복 설계 없이는 에이전트가 아닌 애물단지 자동화가 되기 십상입니다.
결국, ‘자동화’가 아니라 ‘문제 정의’가 먼저다
The Pulse는 이런 흐름을 관찰하면서도, 동시에 중요한 함의를 던집니다:
모두가 코딩 에이전트를 만들 수 있게 되었을 때, 진짜 경쟁력은 무엇이 되는가?
저는 그 답이 문제 정의에 있다고 봅니다.
단순히 ‘코드 생성’을 자동화하는 것이 아니라,
“이 사용자가 지금 이 상황에서 진짜로 원하는 건 무엇인가?”라는 질문을 제대로 던지고 풀어내는 설계야말로,
AI 시대의 소프트웨어 엔지니어가 가장 신경 써야 할 역량이 아닐까 싶습니다.
지금, 우리가 진짜로 생각해봐야 할 질문
이 뉴스레터의 흐름을 따라가며, 저는 몇 가지 질문을 스스로에게 던지게 되었습니다.
나의 팀은 ‘자동화’를 도입하면서 실제 사용자와 업무 흐름을 충분히 고려했는가?
기술을 도입할 때, 그것이 ‘필요’에 기반한 것인지, 단지 트렌드를 따라간 것인지는 어떻게 구분할 수 있을까?
나 자신은 '설계자'로서 문제를 정의하고, 책임 있게 구조화하는 역량을 얼마나 갖추고 있는가?
기술은 점점 더 쉬워지고, 구현은 점점 더 빨라지고 있습니다.
이제 중요한 건 기술이 무엇을 할 수 있느냐가 아니라, 왜 그렇게 해야만 하느냐입니다.
실무에서 AI와 함께 일하고 있는 개발자로서, 이 흐름을 단지 ‘유행’으로만 보지 않으려 합니다.
앞으로 1~2년 안에 코딩 에이전트는 '없으면 이상한 기능'이 될 가능성이 높습니다.
바로 지금, 우리가 어떻게 설계하고, 어떤 책임을 나누고, 무엇을 우선순위에 두어야 할지를 함께 고민할 때입니다.
