우리는 더 이상 코드만 작성하지 않습니다. 우리는 에이전트를 지휘합니다.

소프트웨어 엔지니어링(Software Engineering) 분야에 무언가 변화가 일어났으며, 우리는 아직 그것을 온전히 명명하지 못했다고 생각합니다.

수년 동안 이 직업의 핵심은 주로 코드를 직접 작성하는 것이었습니다. 그러다 자동 완성(Autocomplete) 기능이 좋아졌습니다. 그다음에는 채팅 기반의 코딩 어시스턴트(Coding Assistants)가 등장했습니다. 이제 워크플로우(Workflow)가 다시 한번 변화하고 있습니다. 우리는 목표를 설명하고, 작업의 덩어리들을 에이전트(Agents)에게 넘기고, 그들의 결과물을 검토하며, 테스트를 강화하고, 무엇을 머지(Merge)할지 결정합니다.

이것은 단순히 키보드 속도가 빨라진 동일한 작업이 아닙니다. 이는 작업의 형태 자체가 달라진 것입니다. 저는 이를 에이전틱 엔지니어링 (Agentic Engineering)이라고 부르고 싶습니다.

엔지니어는 감독관(Director)이 되어가고 있습니다

에이전틱 엔지니어링 (Agentic Engineering)이 엔지니어가 사라진다는 것을 의미하지는 않습니다. 오히려 엔지니어의 판단력이 더욱 중요해지고 있습니다.

코딩 에이전트(Coding Agent)는 파일을 읽고, 변경 사항을 만들고, 명령어를 실행하며, 풀 리퀘스트(Pull Requests)를 생성하고, 에러를 통해 반복 작업을 수행할 수 있습니다. GitHub는 Copilot의 에이전트 모드(Agent Mode)를 에이전트가 계획을 세우고, 편집하고, 터미널 명령어를 실행하며, 작업이 완료될 때까지 계속 작업할 수 있는 워크플로우(Workflow)라고 설명합니다. Google은 Jules를 작업 내용을 받아 가상 머신(Virtual Machine)에서 작업하고 풀 리퀘스트(Pull Request)를 생성할 수 있는 비동기식 코딩 에이전트(Asynchronous Coding Agent)로 설명합니다. Anthropic의 Claude Code 가이드는 여러 개의 Claude 세션을 병렬로 사용하고, 에이전트에게 명확한 컨텍스트(Context)를 제공하며, 그들을 지시가 필요한 작업자처럼 취급하는 것에 대해 공개적으로 이야기합니다.

이것이 바로 변화입니다. 엔지니어는 더 이상 모든 줄을 직접 타이핑하는 사람만이 아닙니다. 엔지니어는 무엇을 구축해야 하는지, 어떤 제약 조건이 중요한지, 결과를 어떻게 검증할지, 그리고 에이전트가 언제 틀렸는지를 결정하는 사람이기도 합니다.

프롬프팅(Prompting)은 이 현상을 설명하기에 너무 작은 단어입니다

사람들은 종종 이 작업을 프롬프팅 (Prompting)이라고 설명하곤 하지만, 이는 그 가치를 과소평가하는 것입니다.

프롬프트 (Prompt)는 단 하나의 지시사항일 수 있습니다. 하지만 에이전트 엔지니어링 (Agentic engineering)은 위임 (Delegation)에 더 가깝습니다. 당신은 작업을 정의하고, 관련 컨텍스트 (Context)를 제공하며, 경계를 설정하고, 체크 항목을 만들고, 결과물을 검토하며, 다음 단계를 결정합니다. 만약 에이전트가 잘못된 방향으로 간다면, 그 실패가 항상 모델의 잘못인 것은 아닙니다. 때로는 작업이 너무 모호했을 수도 있습니다. 때로는 저장소 (Repository)에 테스트가 없었을 수도 있습니다. 때로는 수락 기준 (Acceptance criteria)이 누군가의 머릿속에만 존재했을 수도 있습니다.

이것이 바로 이 새로운 워크플로 (Workflow)에서 최고의 엔지니어가 단순히 타자가 가장 빠르거나 프롬프트를 가장 영리하게 작성하는 사람이 아닌 이유입니다. 그들은 모호한 의도를 명확하고 테스트 가능한 작업으로 전환할 수 있는 사람들이 될 것입니다.

테스트와 검토는 줄어드는 것이 아니라 더 중요해집니다

불편한 사실은 에이전트가 나쁜 엔지니어링 습관의 비용을 더 높게 만든다는 점입니다.

사람이 잘못된 함수를 작성하면, 당신은 디프 (Diff)를 검토합니다. 하지만 에이전트가 10개의 파일을 작성하고, 의존성 (Dependencies)을 업데이트하며, 설정을 건드리고, 테스트를 통과했다고 주장한다면, 당신은 훨씬 더 강력한 검증이 필요합니다. 좋은 자동화된 테스트 (Automated tests)가 필요합니다. 작은 풀 리퀘스트 (Pull requests)가 필요합니다. 로그 (Logs)가 필요합니다. 보안 경계 (Security boundaries)가 필요합니다. 에이전트가 어떤 명령어를 실행했는지, 그리고 왜 실행했는지 알아야 합니다.

생성형 AI (Generative AI)와 소프트웨어 개발에 관한 Martin Fowler의 글은 계속해서 이 지점으로 돌아옵니다. 즉, 루프 (Loop)에는 여전히 인간, 피드백, 그리고 엔지니어링 규율 (Engineering discipline)이 필요하다는 것입니다. Thoughtworks 또한 에이전트 코딩 도구들을 하나의 기술로서 추적해 왔지만, 낙관론 이면에는 동일한 기본적 경고를 담고 있습니다. 즉, 이러한 도구들은 팀이 도구를 중심으로 워크플로를 변경할 때 유용한 것이지, 에이전트의 출력물을 프로덕션 (Production)에 맹목적으로 붙여넣을 때 유용한 것이 아니라는 점입니다.

나는 에이전트의 가능성을 좋아합니다. 나 또한 그것들을 사용합니다. 하지만 나는 자신만만한 에이전트를 깨끗한 디프 (Diff), 통과하는 테스트 스위트 (Test suite), 그리고 제품을 이해하는 검토자 (Reviewer)보다 더 신뢰하지는 않습니다.

새로운 기술은 컨텍스트 엔지니어링입니다

"컨텍스트 엔지니어링 (Context engineering)"이라는 문구는 유행처럼 들리지만, 이는 실질적인 무언가를 가리킵니다. 에이전트는 적절한 파일, 적절한 제약 조건 (Constraints), 적절한 예시, 그리고 적절한 완료 정의 (Definition of done)를 가지고 있을 때 더 나은 성능을 발휘합니다.

이는 엔지니어링 팀이 더 나은 프로젝트 지식 (Project knowledge)을 유지해야 함을 의미합니다. 아무도 읽지 않는 긴 문서가 아니라, 유용한 컨텍스트 (Context)가 필요합니다: 설정 명령 (Setup commands), 아키텍처 노트 (Architecture notes), 테스트 규칙 (Testing rules), API 계약 (API contracts), 알려진 함정 (Known traps), 그리고 코드베이스 내의 좋은 작업 사례 (Examples of good work) 등이 그것입니다.

과거의 워크플로 (Workflow)에서는 문서화되지 않은 지식이 새로운 개발자의 속도를 늦췄습니다. 에이전트 중심의 워크플로 (Agentic workflow)에서는 문서화되지 않은 지식이 에이전트를 혼란스럽게 만듭니다. 숨겨진 비용이 눈에 보이게 되는 것입니다.

에이전트 중심의 엔지니어링 (Agentic engineering)은 여전히 엔지니어링입니다

과장된 버전은 에이전트가 우리를 위해 모든 것을 구축할 것이라고 말합니다. 냉소적인 버전은 에이전트가 쓰레기 (Slop)만을 만들어낼 것이라고 말합니다. 두 가지 모두 너무 안일한 생각입니다.

더 현실적인 버전은 다음과 같습니다: 에이전트는 엔지니어링 팀의 일부가 되고 있지만, 책임 (Accountable)은 지지 않습니다. 책임은 우리가 집니다. 에이전트는 초안 작성 (Draft), 리팩터링 (Refactor), 조사 (Investigate), 테스트 생성 (Generate tests), 그리고 에러 추적 (Chase errors)을 할 수 있습니다. 아키텍처 (Architecture), 트레이드오프 (Tradeoffs), 제품 판단 (Product judgment), 그리고 최종 머지 (Final merge)는 여전히 우리의 몫입니다.

그렇습니다, 우리가 엔지니어링을 수행하는 방식이 변했습니다. 무게 중심이 코드를 타이핑하는 것에서 작업을 지시하는 것으로 이동하고 있습니다. 이는 흥미로운 일이지만, 동시에 기준 (Bar)을 높입니다. 이제 유능한 엔지니어는 빌더 (Builder), 리뷰어 (Reviewer), 테스터 (Tester), 그리고 결코 지치지 않으며 우리가 가르치지 않는 한 비즈니스를 진정으로 이해하지 못하는 아주 작은 소프트웨어 에이전트들의 관리자 (Manager)처럼 생각해야 합니다.

그것이 직업의 다음 버전일지도 모릅니다: 기계적인 코딩은 줄어들고, 배포되는 코드 한 줄당 더 많은 판단 (Judgment)이 요구되는 시대 말입니다.

참고 문헌 (References)

원문 출처: [https://blog.jenuel.dev/blog/we-do-not-just-write-code-anymore-we-direct-agents]