AI 에이전트 시대, 개발자에게 필요한 것은 무엇인가

코드를 잘 짜는 능력이 개발자의 핵심 역량이라는 공식이 흔들리고 있다. 실리콘밸리의 일부 팀은 이미 구현의 상당 부분을 AI에게 맡기고 있으며, 엔지니어는 코드를 작성하는 사람에서 AI가 잘 작동할 수 있는 환경을 설계하는 사람으로 역할이 이동하고 있다. 이 변화가 현장 개발자에게 무엇을 요구하는지, 그리고 어떤 개념들을 이해해야 하는지를 정리한다.

---

AI 엔지니어링을 구성하는 네 가지 축

현재 AI를 활용한 개발 방법론은 크게 네 가지 영역으로 구분된다. 이 네 가지는 순서대로 적용하는 단계가 아니라, 상호 보완적으로 함께 작동하는 구성 요소이다.

1. Prompt Engineering

LLM 모델에게 의도를 정확하게 전달하는 기술이다. 구체적인 지침을 작성하거나 페르소나를 설정하는 방식이 대표적이다. 가장 먼저 알려졌고 가장 익숙한 영역이지만, 단독으로는 한계가 명확하다.

2. Context Engineering

AI에게 프로젝트 구조, 기존 코드 예시, API 문서 등을 함께 전달하는 기술이다. 단순히 정보를 많이 주는 것이 아니라, 필요한 정보를 적절하게 선별해서 제공하는 것이 핵심이다. 정보를 과도하게 제공하면 오히려 역효과가 발생한다는 것이 실제 사용 사례들을 통해 확인되었으며, LLM 모델마다 컨텍스트를 유지하는 용량이 다르기 때문에 설계 기술이 필요해졌다.

컨텍스트는 세 개의 레이어로 구성된다.

• System Context: 에이전트가 항상 참조하는 기본 설정 (CLAUDE.md, AGENTS.md 등)
• Conversation Context: 대화 과정에서 누적되는 이전 맥락
• Tool & Environment Context: 도구 실행을 통해 얻은 실시간 정보 (MCP, 플러그인 등)

3. Harness Engineering

하네스(Harness)는 원래 말을 통제하기 위해 씌우는 마구(馬具)를 뜻한다. Harness Engineering은 강력한 AI 에이전트를 안전하게 통제할 수 있는 환경을 만드는 기술이다.

전통적인 소프트웨어는 결정론적이다. 같은 입력에는 반드시 같은 결과가 나온다. 그러나 LLM은 비결정론적이다. 같은 입력이라도 상황에 따라 다른 결과가 나올 수 있다. 이 특성 때문에 단순히 프롬프트를 정교하게 작성하는 것만으로는 부족하며, 실패가 구조적으로 반복되지 않도록 환경 자체를 설계해야 한다.

예를 들어, "DB 테이블을 절대 삭제하지 마라"고 프롬프트에 적는 것은 Prompt Engineering 방식이다. Harness Engineering 방식은 pre-commit hook을 사용해 변경된 코드에 DB 삭제 구문이 포함되어 있으면 커밋 자체가 실패하도록 강제하는 것이다. 규칙을 지키도록 요청하는 것이 아니라, 어기는 것이 불가능한 구조를 만드는 것이다.

4. Agentic Engineering

에이전트가 자율적으로 복잡한 작업을 수행할 수 있도록 설계하는 기술이다. 단일 LLM 호출이 아니라, 여러 에이전트가 역할을 나누어 협력하거나 작업을 반복·검증하는 파이프라인을 구성하는 것이 핵심이다.

Vibe Coding과 Agentic Engineering의 가장 큰 차이는 테스트다. 견고한 테스트 스위트가 있으면 AI 에이전트는 테스트가 통과할 때까지 스스로 반복하며, 그 결과에 높은 확신을 가질 수 있다. — Google Chrome Team

---

Harness Engineering을 깊이 이해해야 하는 이유

네 가지 축 중에서 현재 가장 주목받고 있으며, 실무 적용에서 가장 큰 변화를 만드는 영역이 Harness Engineering이다.

구성 요소 네 가지

기계가 읽는 컨텍스트 파일 코드 저장소 안에 AI가 읽고 따르는 런타임 설정 파일을 배치한다. CLAUDE.md, AGENTS.md, .cursorrules 등이 해당한다. 다만, 컨텍스트에 제약을 제공해도 이를 어기는 경우가 발생한다는 점을 전제로 해야 한다.

결정론적 CI/CD 게이트 AI 출력물이 반드시 통과해야 하는 자동화된 품질 관문이다. 린터, pre-commit hook, 구조 테스트 규칙으로 규칙 준수를 강제한다.

명시적 도구 경계 AI가 접근할 수 있는 파일, API, DB 시스템의 범위를 명확히 제한한다. 권한을 구조적으로 설정하면 모델이 아예 해당 영역에 접근하지 못하도록 차단할 수 있다.

지속적 피드백 루프 실패를 자동으로 감지하고, 규칙을 정제하며, 하네스 구조를 지속적으로 발전시킨다. Garbage Collection, 규칙 위반 감지, 자동 리팩토링, 아키텍처 체크를 주기적으로 실행하고 보완하는 구조가 필요하다.

하네스 시스템의 작동 단계

1. 분류기: 요청의 성격을 판별한다. 단순 질의인지, 실제 코드 작업인지.
2. 컨텍스트 관리자: 필요한 파일과 규칙만 선별해서 제공한다.
3. 실행 루프: 테스트를 통과할 때까지 자동으로 반복 실행한다.
4. 워커 격리: 코드를 작성하는 AI와 코드를 검토하는 AI를 분리해 이중 검증한다.

Hook의 네 가지 유형

Hook은 하네스 시스템의 핵심 작동 기제다.

유형 동작 시점 실전 예시

Pre-action	에이전트가 행동하기 전	코드 저장 전 lint 자동 실행
Post-action	에이전트가 행동한 후	커밋 후 자동 테스트 실행
Validation	에이전트 출력의 품질 검증	보안 취약점 스캔
Notification	특정 조건 충족 시	비용 임계치 초과 경고

Claude Code는 이미 이 구조 위에서 동작하고 있다. 파일 변경 시 관련 테스트가 자동 실행되고, package.json 수정 시 의존성 충돌을 검사하며, 보안 관련 파일 수정 시 보안 리뷰 에이전트가 자동으로 호출된다.

---

OpenAI의 실험이 보여준 것

OpenAI는 "수동으로 코드를 한 줄도 작성하지 않고 소프트웨어 제품을 만든다"는 의도적 제약을 설정하고 실제 프로젝트를 개발하는 실험을 진행했다. 3~7명의 인원이 약 5개월간 100만 줄의 코드를 작성했고, 이는 기존 대비 약 10배에 달하는 생산성이었다.

초기 진행이 예상보다 더뎠던 이유는 에이전트의 역량이 부족해서가 아니었다. 환경이 제대로 갖춰지지 않았기 때문이었다. 에이전트가 상위 목표를 달성하기 위한 도구, 추상화, 내부 구조가 부족했고, 팀의 주요 업무는 에이전트가 유용한 작업을 수행할 수 있도록 그 환경을 만드는 것으로 전환되었다.

이 실험에서 도출된 핵심 통찰은 다음과 같다.

역할의 분리가 명확해졌다.

• 인간: 의도 정의, 시스템 설계, 제약 설정
• AI: 코드 생성, 테스트, 리뷰, 수정 실행

중요한 것은 프롬프트가 아니라 구조다. 단순히 프롬프트를 잘 작성하는 것이 아니라, 저장소 구조, 문서 구조, 테스트 시스템, CI/CD, lint 규칙, Observability, 에이전트 워크플로우 전체를 설계하는 능력이 요구된다.

코드 가독성의 기준이 바뀌고 있다. 기존에는 옆에 있는 동료 개발자가 이해하기 쉬운 코드를 작성하는 것이 목표였다. 지금은 에이전트가 이해하고 자동으로 수정·검증할 수 있는 코드가 좋은 코드의 기준이 되고 있다.

모든 의사결정은 문서로 남아야 한다. 머릿속이나 구두로만 이루어지는 의사결정은 AI 시스템에서 의미가 없다. 규칙이 적용된 문서에 기록되어야 에이전트가 참조할 수 있다. 구조적이고 규칙적으로 정리하는 능력이 중요해졌다.

---

하네스 엔지니어링 설계 시 주의할 점

현장에서 실제로 구현할 때 반드시 염두에 두어야 할 사항들이다.

1. 큰 instruction 하나는 실패한다. 작고 연결된 문서 구조를 만들어, 필요할 때 필요한 정보만 참조할 수 있도록 Knowledge Graph 형태로 구성해야 한다.
2. Single Source of Truth 원칙을 지켜야 한다. 정보가 외부 문서, Slack, 담당자의 머릿속 등에 파편화되어 있으면 에이전트는 일관되게 작동할 수 없다.
3. 강한 구조적 제약이 필요하다. 아키텍처, lint 규칙, 폴더 구조, 접근 권한 설정은 선택이 아닌 필수다.
4. 리뷰도 에이전트가 수행한다. 리뷰 루프 자체가 자동화되는 방향으로 설계해야 한다.
5. AI에게 관찰 능력을 제공해야 한다. QA 병목을 해소하려면 Playwright, UI 스냅샷, 로그, 메트릭, trace 등 에이전트가 스스로 확인할 수 있는 도구를 갖춰야 한다.
6. 피드백 루프가 핵심이다. "실행 → 관찰 → 평가 → 수정 → 반복"이 자동으로 작동한다면, 인간의 개입 없이도 기능 개발이 가능해진다.
7. 개발 속도와 안정성의 균형이 재조정되고 있다. 기존에는 안정성 우선으로 코드 리뷰가 길게 이루어졌다. 현재는 속도를 우선하고, 문제가 생기면 빠르게 수정하는 방향으로 바뀌고 있다. AI를 활용하면 수정 비용이 거의 0에 가까워지기 때문이다.
8. Garbage Collection 설계가 필요하다. AI는 기존 패턴에 잘못된 것이 하나 들어가면 지속적으로 코드를 오염시킨다. 이를 자동으로 감지하고 정리하는 메커니즘이 반드시 필요하다.

---

시니어 개발자에게 요구되는 변화

이 흐름 속에서 시니어 개발자에게 요구되는 역량은 다음과 같이 정리된다.

문제를 구조화하는 능력과 시스템 설계 능력 AI가 이해하고 수행할 수 있도록 문제를 작게 쪼개고, 명세를 정확하게 작성하는 능력이 핵심 역량이 되었다.

좋은 코드의 기준 재정의 AI가 이해하기 쉽고, 자동 수정 및 검증이 가능한 코드가 좋은 코드다.

핵심 스킬의 변화 아키텍처 강제력 설계, 규칙 설계, 피드백 루프 설계, Observability 구축, 명세 작성 능력이 중요해지고 있다.

마인드셋의 전환 "내가 직접 해결한다"에서 "시스템이 해결하게 만든다"로의 전환이 필요하다. 이것이 이 시대 엔지니어에게 요구되는 가장 근본적인 변화다.

---

AI 에이전트는 이미 현장에 들어와 있다. 이 변화에서 살아남는 개발자는 코딩을 가장 잘하는 사람이 아니라, AI가 가장 잘 일할 수 있는 환경을 설계하는 사람일 가능성이 높다.