AI Native Development

AI Native와 Agentic Coding의 차이 — AI로 코딩하면 끝일까?

Kun Woo Kim 2026. 9. 11. 09:40

728x90

코드를 작성하는 에이전트와, 그 결과를 검증하고 운영하는 개발 시스템

만들고 나서 이름을 알았다

언제부턴가 AI Native라는 단어가 계속 눈에 들어왔다. 채용 공고, 컨퍼런스 세션 제목, 유튜브, 기술 뉴스. 한 군데서 보이기 시작하면 다른 데서도 보이는 그런 단어였다.

그 무렵 나는 팀에 스펙 기반 개발(Spec-Driven Development) 워크플로우 킷을 만들어 넣은 참이었다. CLAUDE.md로 프로젝트 지침을 정리하고, 스펙 템플릿을 두고, hook과 슬래시 커맨드를 붙였다. 파일 열댓 개짜리다.

읽다 보니 내가 만든 게 그중 어느 쪽인지 애매했다. AI Native인지 Agentic Coding인지, 둘 다인지 둘 다 아닌지.

정의를 찾아보니 문제가 더 커졌다. 글마다 범위가 달랐고, 어떤 글은 두 단어를 아예 같은 뜻으로 쓰고 있었다.

정의 없이 쓰다 보면 각자 다른 걸 상상한 채로 합의했다고 착각하게 된다. 팀에 뭔가를 도입하려는 상황이라면 이게 꽤 큰 문제다.

그래서 공식 문서까지 찾아가며 정리해봤다. 그 과정에서 널리 퍼진 설명 중에 원 출처와 어긋나는 게 몇 개 나왔다.

먼저 결론

Agentic Coding은 작업이 실행되는 방식이고, AI Native 개발은 그 실행이 팀에서 계속 굴러가도록 시스템을 설계하는 관점이다.

포함 관계라기보다 층위가 다르다. 한쪽은 "이 작업의 다음 행동을 누가 정하는가"이고, 다른 쪽은 "우리 개발 시스템이 무엇을 전제로 짜여 있는가"다.

하나 미리 말해둘 게 있다. 이 두 용어는 출처마다 범위가 다르다. 어떤 글은 AI Native를 IDE와 플랫폼 선택 문제로 좁게 쓰고, 어떤 글은 조직 문화까지 넓게 쓴다. 내가 아래에서 "AI Native 개발"이라고 부르는 걸 "Agentic Development"라고 부르는 글도 있다.

그러니 이 글의 구분도 업계 표준 정의가 아니라, 혼동을 피하려고 내가 골라 쓰는 기준이다.

첫 번째 함정: "고정된 워크플로우는 에이전틱하지 않다"

Agentic Coding부터 보자. 에이전트가 목표와 제약을 받아서 도구를 쓰고, 실행 결과를 읽고, 그걸 근거로 다음 행동을 정하는 방식이다. 코드베이스를 훑고 파일을 고치고 테스트를 돌린 뒤, 실패 원인을 분석해서 다시 고치는 루프가 대표적이다.

여기서 흔히 이런 이분법이 따라붙는다. "정해진 순서를 따르면 자동화, 스스로 정하면 에이전트."

절반은 맞다. 미리 짜둔 파이프라인 중간에 LLM 호출이 한 번 끼어 있다고 해서 에이전트가 되지는 않으니까. 문제는 이걸 "고정된 워크플로우는 에이전틱하지 않다"로 확장할 때다. 원 출처는 이 단어를 더 넓게 쓴다.

Anthropic의 Building Effective Agents는 완전 자율 시스템과 미리 정의된 워크플로우를 따르는 구현을 모두 agentic systems로 묶은 다음, 그 안에서 둘을 구조적으로 구분한다.

agentic systems
├── workflows   미리 정의된 코드 경로로 LLM과 도구를 오케스트레이션
└── agents      LLM이 자기 프로세스와 도구 사용을 스스로 지시

주의할 게 있다. 상위 범주가 같다는 게 구조적 차이가 없다는 뜻은 아니다. Anthropic은 이걸 중요한 아키텍처 차이라고 명시한다. 실행 흐름을 미리 정의된 코드가 잡느냐, 모델이 동적으로 잡느냐가 갈린다.

다만 이걸 자율성의 그라디언트로 읽는 해석도 있다. Matt Pocock은 둘의 차이가 자율성의 정도이고 여전히 연속체처럼 느껴진다고 평했다.

어느 쪽으로 읽든 결론은 같다. 고정된 절차는 "에이전틱하지 않은 것"이 아니라 agentic systems 안에서 workflow 쪽이다.

이게 왜 중요하냐면, 이분법을 그대로 밀면 이상한 결론이 나오기 때문이다. 우리 팀 워크플로우는 이렇다.

스펙 승인 → 구현 → 테스트 → PR → 리뷰 승인 → 배포

이 순서는 고정되어 있다. 그럼 우리 팀은 에이전틱 코딩을 안 하는 건가. 그럴 리가 없다. 저 안의 "구현" 단계에서 에이전트는 어떤 파일을 열지, 뭘 고칠지, 실패한 테스트를 어떻게 해결할지를 스스로 정한다.

바깥 절차가 통제되어 있어도 안쪽 작업은 에이전틱할 수 있다.

이 중첩 구조는 통제와 자율성을 함께 설계하는 한 방법이다. 고정된 바깥 형태 안에서 모델이 선택하는 이 중간 지대가 실제로 쓸 만한 시스템이 놓이는 자리라는 정리도 있다.

판단 기준은 "순서가 정해져 있느냐"가 아니다.

주어진 권한 안에서 다음 행동을 동적으로 고르는가.

참고로 PR 생성은 대표적인 사례일 뿐 필수 조건이 아니다. PR을 안 만들어도 에이전틱할 수 있고, PR을 자동으로 만든다는 사실만으로 자율적인 코딩 에이전트라고 할 수도 없다.

AI Native 개발: 팀이 반복해서 운영할 수 있는가

개인이 Claude Code로 기능 하나를 잘 뽑아내는 건 Agentic Coding이다. 그게 다음 주에도, 다른 팀원이 해도, 모델이 바뀌어도 같은 기준으로 검증하고 운영할 수 있게 만드는 것이 AI Native 쪽이다. 유지하려는 건 동일한 결과가 아니라 검증과 책임의 기준이다.

구체적으로는 이런 것들이 저장소 안에 명시되어 있느냐의 문제다.

필요한 맥락을 어디서 찾는가
어떤 규칙을 따라야 하는가
무엇으로 "완료"를 판정하는가
어떤 변경에 승인이 필요한가
실패에서 배운 걸 어디에 남기는가

모든 단계에 에이전트를 넣자는 뜻은 아니다. 규칙이 명확한 작업은 그냥 스크립트가 맡고, 탐색과 판단이 필요한 데 에이전트를 쓰고, 위험한 결정에는 승인 절차를 둔다. 어떤 판단을 에이전트에게 맡기고 어디서 사람의 검토나 승인을 요구할지를 명시하는 것에 가깝다.

Agentic Coding    이 작업의 다음 행동을 누가 정하나
                  단위: 개별 작업
                  실패 모습: 에이전트가 엉뚱한 걸 고침

AI Native 개발     협업이 지속되게 시스템을 어떻게 짜나
                  단위: 팀 · 저장소 · 배포 과정
                  실패 모습: 잘하는 사람 한 명한테만 의존하게 됨

두 번째 실패 모습이 더 무섭다. 티가 안 나기 때문이다. 팀 생산성 지표는 올라가는데 그게 한 사람의 개인기라면, 그 사람이 다른 팀으로 가는 순간 원래대로 돌아간다.

두 번째 함정: 지침과 강제는 다르다

여기가 실무에서 제일 크게 갈리는 지점이다.

CLAUDE.md에 규칙을 적어두고 hook을 붙여놓으면 "규칙이 코드로 강제된다"고 느끼기 쉽다. 그런데 이건 세 개의 다른 계층이고, 각자 막는 대상과 적용 시점이 다르다.

1. CLAUDE.md · rules · 스펙 템플릿   컨텍스트. 문서가 강제가 아니라고 명시
2. hook                           모델 결정과 무관하게 실행
                                  PreToolUse는 호출을 실제로 차단
3. permissions · sandbox · CI      도구 접근, 실행 환경, 병합·배포를 통제

1번은 추측이 아니라 문서에 쓰여 있다. Claude Code 공식 문서는 CLAUDE.md를 강제된 설정이 아니라 컨텍스트로 취급한다고 못 박고, 무엇을 결정하든 동작을 차단하려면 PreToolUse hook을 쓰라고 안내한다. 트러블슈팅 절에는 CLAUDE.md가 시스템 프롬프트가 아니라 그 뒤의 사용자 메시지로 전달되며 엄격한 준수는 보장되지 않는다고 적혀 있다. 공식 문서가 "Claude가 내 CLAUDE.md를 안 따른다"를 별도 트러블슈팅 항목으로 다룰 정도다.

2번은 진짜 막는다. PreToolUse에서 exit 2를 쓰거나, exit 0과 함께 permissionDecision: "deny" JSON을 반환하면 도구 호출이 실행 전에 차단된다. "로컬에 있으니 권고일 뿐"이라고 뭉뚱그리면 안 된다. PostToolUse와는 완전히 다르다. 후자는 이미 실행된 뒤라 되돌리는 장치가 아니다.

막을 수 있다는 것과, 그것만으로 접근 통제가 보장된다는 건 다르다. 확인해둘 조건들이 있다.

exit code       exit 1은 차단 신호가 아니다. 종료 코드만으로 막으려면 exit 2
if 필터         best-effort다. 허용·거부 정책을 이 필터에만 기대면 안 된다
경로 오타        스크립트가 없으면 게이트가 조용히 비활성화된다
                transcript에 비차단 오류가 뜨지만 놓치기 쉽다
타임아웃         PreToolUse의 command·http·mcp_tool hook은 차단 결정 없이
                일반 권한 평가로 넘어간다
disableAllHooks  일반 hook은 끌 수 있다. managed hook은 못 끈다

특히 세 번째가 그렇다. hook이 설정 파일에 등록돼 있다는 것만으로 차단이 작동한다고 판단하면 안 된다. 비차단 오류를 놓치면 검사가 실패했는데도 보호되고 있다고 오인하게 된다.

한 가지 덧붙이면, hook이 차단하지 않았다는 것과 호출이 무조건 허용됐다는 것도 다르다. hook의 결정이 없으면 일반 권한 흐름으로 넘어가고, 거기서 막힐 수 있다.

3번은 통제 지점이 다르다. permissions는 도구 접근을, sandbox는 Bash와 자식 프로세스의 OS 수준 자원 접근을, 서버 측 required check와 브랜치 보호는 병합과 배포를 통제한다. managed settings는 이것들과 나란히 놓이는 또 하나의 차단 장치라기보다 조직이 설정을 배포하고 하위 설정보다 우선 적용시키는 방식이다.

문서도 settings 규칙은 Claude의 결정과 무관하게 클라이언트가 강제하지만 CLAUDE.md는 행동을 형성할 뿐 하드 강제 계층이 아니라고 표로 갈라놓는다.

비슷한 킷을 운영 중이라면 규칙마다 두 가지를 확인해보길 권한다. 하나는 이 장치가 지침인지, 경고인지, 실제로 차단하는지. 다른 하나는 그 장치를 누가 변경하거나 우회할 수 있는지.

전부 CI로 올릴 필요는 없다. 각 장치가 어디까지 책임지는지 구분하는 것만으로도 충분히 다르다.

완료는 에이전트가 선언하는 게 아니다

두 번째로 중요한 지점이다.

에이전트가 "테스트 통과했습니다"라고 말하는 것과 실제로 동작하는 것은 다르다. Anthropic이 장기 실행 에이전트 사례에서 관찰한 것도 같은 문제다. 단위 테스트나 간단한 호출만 확인하고 완료로 표시했는데 정작 기능이 끝까지 동작하지 않는 경우가 있었고, 브라우저를 통한 종단 간 검증이 이걸 개선하는 데 도움이 됐다고 한다.

여기서 파생되는 더 조용한 문제가 있다.

에이전트: 구현 수정 → 테스트 실패
에이전트: 테스트 기대값 수정 → 통과
에이전트: "완료했습니다"

구현과 테스트를 같은 에이전트가 같은 턴에 수정할 수 있으면, 깨진 구현에 맞춰 기대값이 조정될 여지가 생긴다. 요구사항이 실제로 바뀌어서 테스트를 함께 고치는 건 정상이다. 문제는 둘이 diff에서 똑같이 생겼다는 거다. 변경 자체는 보이지만, 그게 합격 기준을 낮추는 변경인지는 놓치기 쉽다. 단언 하나가 슬쩍 느슨해지거나 skip 하나가 붙는 식이라서 그렇다.

핵심은 AI에게 테스트를 못 쓰게 하는 게 아니다.

결과물을 만든 쪽이 합격 기준까지 임의로 낮출 수 없게 하는 것.

실무 규칙으로 옮기면 이렇게 된다.

수용 기준은 스펙 단계에서 확정한다. "고치지 마"라고 프롬프트에 쓰는 것과 쓰기 권한을 실제로 막는 것은 다르다. 바로 앞 절의 구분이 여기에도 그대로 적용된다
테스트 삭제, 단언 완화, skip 추가는 변경 이유를 명시하고 별도 검토 대상으로 삼는다. 필요하면 커밋이나 PR을 분리한다. 다만 분리 자체가 검토를 보장하지는 않는다. 실제로 강제하려면 required review나 code owner 승인 같은 병합 조건이 필요하다
완료 판정은 자기평가가 아니라 사전에 합의된 기준과 독립적으로 확인 가능한 증거로 한다

측정: 사람의 검토 시간을 비용에 넣어야 한다

"에이전트가 코드의 몇 퍼센트를 썼다"는 지표만으로는 생산성이 좋아졌는지 알 수 없다. PR 개수도 마찬가지다.

DORA는 AI의 효과가 조직의 기존 강점과 약점을 증폭시킨다고 지적한다. 코드 작성에서 얻은 속도가 테스트, 보안 리뷰, 배포 병목에 그대로 흡수될 수 있다는 것이다.

숫자로 만들어보면 감이 온다. 실제 측정값이 아니라, 사람의 총투입시간이 늘어날 수 있다는 걸 보여주는 가상 예시다. 아래 숫자는 전부 사람이 투입한 시간이다.

        구현(사람)   리뷰·수정     합계
이전       60분        20분       80분
이후       10분        90분      100분

구현 담당자는 빨라졌다고 느끼기 쉽다. 자기가 줄인 50분은 자기 눈에 바로 보이고, 늘어난 리뷰 시간은 다른 사람들에게 분산돼서 안 보이기 때문이다.

전체 개발 비용을 따지면서 사람의 검토·수정 시간을 빼면 비용을 과소평가하게 된다.

봐야 할 건 이 정도다.

에이전트 작업     외부 검증 통과율 · 재시도 횟수 · 사람의 수정 시간 · 작업당 비용
팀 개발 시스템     요구사항→배포 리드타임 · 리뷰 대기시간 · 배포 후 결함 · 재작업

용어 하나만 더: 제품의 AI Native와 개발 방식의 AI Native

헷갈리기 쉬운 지점이다. AI Native는 제품의 핵심 가치가 AI에 의존한다는 뜻으로도 쓰인다. AI가 부가 기능으로 나중에 붙은 게 아니라 설계 단계부터 중심에 있는 제품을 가리키는 용법이다.

이건 "AI와 협업하도록 개발 프로세스를 설계했다"와 다른 얘기다. 평범한 사내 관리 도구도 AI Native 개발 방식으로 만들 수 있고, AI가 핵심인 제품인데 개발 과정은 전통적일 수도 있다.

채용 공고나 조직 소개에서 이 단어를 보면 어느 쪽인지 먼저 확인하는 게 좋다. 면접에서 되물어보면 그 조직이 실제로 어느 쪽인지도 대충 드러난다.

처음부터 큰 킷이 필요한 건 아니다

여기까지 읽고 당장 킷을 만들어야 하나 싶다면, 그럴 필요 없다.

나도 처음부터 열댓 개 파일로 시작하지 않았다. 점진적으로 늘어난 결과물이다. 규칙을 문서화하는 데도 비용이 들고, 만들어두고 아무도 안 지키면 오히려 나쁘다. 지켜지지 않는 규칙이 저장소에 있으면 나중에 진짜 중요한 규칙까지 같이 무시된다.

다만 여기서 두 가지를 섞으면 안 된다.

반복성    표준화의 우선순위를 정한다
위험도    최소 안전장치를 정한다

반복되는 문제에 맞춰 지침과 자동화를 늘리는 건 나중에 해도 된다. 사람이 한둘이고 코드 리뷰에서 걸러지고 프로젝트 규칙이 몇 줄이면 설명된다면, 지금 하던 대로가 더 단순하다.

하지만 접근 권한과 변경의 위험도에 필요한 안전장치는 별개다. 한 사람이 에이전트 하나를 쓰더라도 운영 데이터나 배포 자격증명에 닿는다면 권한과 검증을 먼저 봐야 한다. "아직 사고가 없었다"는 건 안전장치를 생략할 근거가 아니다.

거꾸로도 성립한다. 여러 명이 쓰는 팀이라도 기존 CI와 승인 절차가 충분하다면 별도의 큰 킷은 필요 없을 수 있다.

정리

Agentic Coding과 AI Native 개발은 대체 관계가 아니다. 하나는 작업이 실행되는 방식이고, 하나는 그 실행을 담는 시스템이다.

실무에서 챙길 건 세 가지다.

1. 지침 · hook · permission을 구분한다
   각 장치가 어디까지 책임지는지, 누가 그걸 바꿀 수 있는지

2. 결과물을 만든 쪽이 합격 기준을 승인 없이 바꾸거나 임의로 낮추지 못하게 한다
   프롬프트로 부탁하는 것과 병합 조건으로 막는 것은 다르다

3. 사람의 검토 시간을 비용에 넣는다
   구현 속도만 보면 전체 비용을 과소평가한다

나머지는 대체로 용어 정리에 가깝다.

중요한 건 AI가 코드를 몇 퍼센트 썼느냐가 아니다. 모델은 계속 좋아지고 계속 교체된다. 남는 건 무엇을 만들려 했고, 왜 그렇게 판단했고, 어떤 검증을 거쳐 배포했는지가 저장소에 기록되는 시스템이다.

그래서 판단 기준은 이 정도로 잡으면 된다.

에이전트가 개별 작업을 어떻게 수행하는지가 문제라면 Agentic Coding이다.

그 작업이 사람·세션·모델이 달라져도 검증 가능한 방식으로 반복되게 하는 게 문제라면 AI Native 개발이다.

혼자 쓰더라도 두 번째에 해당할 수 있다. 인원수가 아니라 무엇을 설계하려는지가 기준이다.

728x90

저작자표시 비영리 변경금지 (새창열림)