AI 엔지니어링은 쉽다, 일하는 방식을 바꾸는 게 어렵다
AI가 요구사항 정의부터 검증까지 개발 전 단계에 참여하기 시작하면서, 진짜 병목은 코딩이 아니라 그 주변의 일하는 방식이라는 지적이 나왔다. Dev.to 개발자 ujja가 'AI 하네스'라는 개념으로 정리한 글이다.
AI Engineering Is Easy. Changing How We Work Is Hard
AI engineering sounds fancy. New terms are everywhere: agentic development, AI-native engineering,...
개요 #
에이전틱 개발, AI 네이티브 엔지니어링, 스펙 주도 개발, AI 하네스 엔지니어링. 새로운 용어가 쏟아지지만 그 밑에서 실제로 벌어지는 변화는 하나다. AI가 요구사항 정리를 돕고, PRD의 허점을 지적하고, UX 아이디어를 탐색하고, 아키텍처를 따져보고, 구현 계획을 세우고, 코드를 쓰고, 결과를 검증하는 데까지 손을 뻗었다.
Dev.to에 글을 올린 개발자 ujja는 여기서 질문을 하나 바꿔 던진다. AI가 무엇을 할 수 있느냐가 아니라, 우리가 소프트웨어를 만드는 방식이 그걸 받아들일 준비가 됐느냐는 것이다.
다섯 단계에 AI가 들어온다 #
글쓴이가 실험해온 워크플로는 개발을 요구사항, 정제, 계획, 구현, 검증 다섯 단계로 나눈다. 단계 구분 자체는 새로울 게 없다. 달라진 건 AI가 각 단계에 참여할 수 있다는 점이다. 기존 제품 문서를 받아 문제를 명확히 하고, 가정을 되묻고, PRD의 빈틈을 찾아내고, 잘 정의된 요구사항을 계획과 구현 태스크로 바꿔놓는다.
그래서 요구사항의 품질이 전보다 훨씬 중요해진다. 프로젝트에 붙어 있는 사람은 "경험을 개선한다"가 무슨 뜻인지 안다. 그 주제로 몇 번이나 대화를 나눴기 때문이다. 에이전트에게는 그런 공유된 기억이 없다. 문제, 범위, 제약, 엣지 케이스, 기대 결과를 명시적으로 적어줘야 한다. 거대한 명세서를 쓰라는 얘기가 아니다. 만들기 전에 AI를 써서 요구사항을 정확하게 다듬으라는 쪽에 가깝다.
이 대목에서 AI는 꽤 쓸모 있으면서 약간 짜증나는 리뷰어가 된다. 실패하면 어떻게 되는지, 이 요구사항이 테스트 가능한지, 문서의 두 부분이 서로 모순되지 않는지, 아직 고려하지 않은 게 무엇인지 되묻는다. PRD 버전 간 비교를 시키거나, 한 모델의 결과물을 다른 모델에게 검토시키면 빈틈이 더 잘 드러난다. 핵심은 AI가 모호함을 드러내주는 역할이지, 결정을 대신하는 역할이 아니라는 것이다.
병목은 코딩이 아닐지도 모른다 #
팀이 실제로 시간을 어디에 쓰는지 들여다보면 이야기가 흥미로워진다. 복잡한 작업일수록 개발이 제대로 시작되기 전에 제품, UX, 요구사항, 엔지니어링 사이를 몇 번씩 오간다. 필요한 과정이긴 하지만 동시에 상당한 병목이기도 하다. AI 에이전트가 동작하는 구현을 빠르게 뽑아낼 수 있다면, 요구사항 하나 명확해지기를 2주 기다리는 일의 무게가 예전과 완전히 달라진다.
Photo by RDNE Stock project on Pexels
여기서 엔지니어가 더 일찍 들어와야 한다는 얘기가 나온다. 다 확정된 요구사항을 넘겨받는 방식으로는 안 된다. UX도 마찬가지다. 거친 프로토타입이나 와이어프레임 하나가 회의 한 번보다 요구사항의 구멍을 훨씬 빨리 드러낸다. AI 덕분에 그런 가벼운 프로토타입을 만드는 비용도 크게 떨어졌다. 요구사항, UX, 기술 설계가 순차적 인수인계가 아니라 하나의 반복 루프로 묶일 수 있다는 얘기다.
문서가 많다고 좋은 건 아니다 #
AI를 붙일 때 나오는 첫 본능은 문서를 더 주는 것이다. PRD를 더, 아키텍처 다이어그램을 더, 위키 페이지를 더, 컨텍스트를 더. 하지만 여러 문서가 같은 기능을 제각각 다르게 설명하고 있다면 에이전트에게 더 나은 컨텍스트를 준 게 아니다. 헷갈릴 방법을 더 준 것이다.
에이전트에게 필요한 건 시스템을 탐색할 수 있는 길이다. 명확한 프로젝트 구조, 초점이 잡힌 문서, 쓸모 있는 에이전트 지침, 왜 그렇게 만들었는지 설명하는 아키텍처 결정 기록, 잘 정돈된 코드베이스. 이쪽이 거대한 명세서 하나보다 훨씬 유용하다. 우리가 아는 걸 전부 AI에게 넘기는 게 목표가 아니다. AI가 필요할 때 필요한 걸 쉽게 찾게 만드는 게 목표다.
티켓 자체가 문제일 수 있다 #
AI를 쓰다 보면 일을 어떻게 쪼개고 있었는지도 의심하게 된다. 몇 주, 몇 달짜리 티켓은 에이전트가 다루기 어렵다. 사실 사람에게도 그렇게 유용한 작업 단위는 아니었다. "인증 구현"과 비밀번호 재설정, 토큰 검증, 비밀번호 변경, 그리고 각각의 테스트로 쪼갠 것은 완전히 다른 물건이다.
그렇다고 모든 기능을 잘게 썰어 티켓 수십 개로 만들라는 뜻은 아니다. 목적이 분명하고, 범위가 감당 가능하고, 완료 기준이 있는 작업이면 된다. 몇 달이 걸리는 일이라면 그건 Jira 옷을 입은 프로젝트다.
동시에 모든 작업에 AI 라이프사이클 전체를 적용할 필요는 없다. 큰 기능은 구조화된 요구사항, 정제, 계획, 검증이 도움이 되지만, 자잘한 운영성 변경은 프롬프트 하나와 개발자 한 명이면 충분하다. 모든 일에 같은 프로세스를 밀어넣으면 관료주의를 다른 관료주의로 바꿔치기하는 셈이 된다. 워크플로는 일의 복잡도에 맞춰야 한다.
에이전트는 진짜 시스템을 봐야 한다 #
꽤 근본적인 조건이 하나 더 있다. 에이전트가 실제 시스템을 이해해야 한다는 것이다. 관련 코드베이스 접근 없이 PRD만 던져주면 에이전트는 여전히 추측하고 있는 상태다. 코드가 있으면 기존 패턴을 찾고, 제약을 파악하고, 이미 있는 기능을 재사용하고, 제안된 해법이 맞지 않는 지점을 짚어낸다.
물론 AI에게 소스 코드 접근을 허용하는 순간 보안, 라이선스, 프라이버시, 조직 차원의 고려사항이 따라온다. AI 도입은 좋은 모델을 고르는 문제로 끝나지 않는다. 가장 큰 장벽 중 일부는 모델과 아무 상관이 없다.
여러 개발자와 여러 에이전트가 동시에 작업하기 시작하면 상황은 더 복잡해진다. 에이전트마다 자기 컨텍스트가 있고, 지금 보이는 것에 근거해 판단한다. 한 에이전트가 바꾼 것을 다른 에이전트가 모를 수 있고, 각자 합리적으로 내린 결정 둘이 합쳐지면 어긋날 수 있다. 이럴수록 기본기가 더 중요해진다. 작은 변경, 명확한 경계, 좋은 테스트, 잦은 리뷰, 일관된 프로젝트 규칙 같은 것들 말이다.
준비됐냐고 묻는다면 #
아마 완전히는 아닐 것이다. 그래도 괜찮다는 게 글쓴이의 입장이다. 자율 소프트웨어 개발로 곧장 뛰어들 필요는 없다. 실제 업무 조각을 골라 이 워크플로를 적용해보고, 어디서 깨지는지 확인하고, 그때그때 프로세스를 고쳐나가면 된다.
AI가 바꾸는 건 코드 작성 속도만이 아니다. 코드 주변에서 우리를 느리게 만들던 모든 것을 드러낸다. 불명확한 요구사항, 지나치게 큰 티켓, 뒤늦은 UX 참여, 문서 표류, 인수인계, 접근 제한, 며칠씩 걸리는 의사결정.
글쓴이가 AI 하네스라는 개념을 프롬프트나 에이전트 설정보다 큰 것으로 보는 이유도 여기 있다. 하네스는 AI 주변에 우리가 만들어놓은 환경 전체다. 일을 어떻게 정의하는지, 제품·UX·엔지니어링이 어떻게 협업하는지, 지식을 어떻게 구조화하는지, 저장소를 어떻게 정리하는지, 작업을 어떻게 검증하는지, 에이전트에게 어떤 접근 권한을 주는지.
AI가 새로운 부분일 수는 있다. 하지만 실제로 빨라지느냐를 결정하는 건 그 주변에서 우리가 일하는 방식이다.
AI 엔지니어링은 쉽다. 일하는 방식을 바꾸는 게 어렵다.
이 글은 위 출처를 바탕으로 한국 독자를 위해 재작성한 기사입니다. 원문의 사실과 수치에 근거하며, 별도의 견해를 포함하지 않습니다.