에이전틱 코딩 (Agentic Coding)에서 가장 유용한 기술은 만약 당신이 누군가를 관리해 본 경험이 있다면 이미 가지고 있는 기술입니다. 프레임워크도, 언어도, 컴퓨터 과학 (CS) 학위도 아닙니다. 바로 당신이 원하는 것을 다른 사람이 구현할 수 있을 만큼 명확하게 말하고, 결과물로 돌아온 것이 실제로 맞는지 판단하는 능력입니다. MIT의 'Missing Semester' 시리즈 중 이와 관련된 강의도 동일한 사고 모델(Mental Model)을 제시합니다. 즉, 당신은 더 이상 코더 (Coder)가 아니라, 세세한 작업을 수행하지만 방향 설정이 필요하고 때때로 잘못된 일을 저지르기도 하는 인턴을 관리하는 매니저 (Manager)라는 것입니다.

이러한 관점의 전환은 좋은 소식인 동시에 경고이기도 합니다. 좋은 소식인 이유는 진입 장벽이 구문 (Syntax)이 아닌 판단력 (Judgment)에 있으며, 판단력은 도메인 전문가 (Domain Expert)가 흔히 풍부하게 가지고 있는 역량이기 때문입니다. 경고는 아무도 튜토리얼에서 말해주지 않는 부분입니다. 에이전틱 코딩 (Agentic Coding)은 당신이 믿기 힘들 정도로 빠르게 작동하는 제품의 80%까지 도달하게 해주지만, 나머지 20% 구간에서 당신을 조용히 고립시킬 것입니다. 그 절벽이 어디인지 낭떠러지로 떨어지기 전에 아는 것이, 제품을 출시 (Shipping)하느냐 아니면 처음부터 다시 시작하느냐를 결정짓는 차이입니다.

에이전틱 코딩 (Agentic Coding)이란 정확히 무엇인가

이 용어가 주변의 모든 것과 모호하게 섞이기 때문에 명확한 정의부터 시작하겠습니다. Google Cloud는 이를 다음과 같이 명확하게 설명합니다. 에이전틱 코딩 (Agentic Coding)은 자율적인 AI 에이전트 (AI Agents)가 인간의 개입을 최소화하면서 코드를 계획, 작성, 테스트 및 수정하는 소프트웨어 개발 접근 방식입니다. 핵심 단어는 자율성 (Autonomous)입니다. 전통적인 AI 어시스턴트 (AI Assistant)는 당신이 타이핑하기를 기다렸다가 다음 줄을 제안합니다. 반면 코딩 에이전트 (Coding Agent)는 상위 수준의 지시 (High-level instruction)를 받아 이를 단계별로 나누고, 프로젝트 전반에 걸쳐 파일을 읽고 쓰며, 명령어를 실행하고, 자신의 작업 내용을 확인하며, 작업이 완료될 때까지 계속 진행합니다.

그것이 바로 대부분의 초보자가 실제로 궁금해하는 질문인 AI 코딩 (AI coding)과 에이전틱 코딩 (agentic coding)의 차이점입니다. 자동 완성 (Autocomplete)은 당신의 문장을 완성하지만, 에이전트 (Agent)는 심부름을 수행합니다. MIT의 강의에서는 에이전트를 '도구에 접근할 수 있는 대화형 AI 모델 (conversational AI model)'로 정의합니다. 여기서 도구란 파일을 읽고 쓰는 것, 웹 검색, 셸 명령어 (shell commands) 호출 등을 의미합니다. 모델은 두뇌이며, 도구는 손입니다. 에이전트에게 목표를 부여하면, 에이전트는 사전이 단어를 제안하는 방식이 아니라, 계약업자가 작업 현장에서 일하는 방식처럼 당신의 코드베이스 (codebase)를 운영합니다.

실제로 당신이 시작하게 될 도구들은 이제 성숙한 단계에 접어들었습니다. Claude Code와 Codex는 터미널 (terminal)에서 실행되며 커맨드 라인 (command line)에서 다단계 작업을 수행합니다. Cursor와 Windsurf는 동일한 에이전트를 코드 에디터 (code editor) 안에 탑재했습니다. 첫날부터 어떤 것이 가장 좋은지 알 필요는 없습니다. 당신이 알아야 할 것은 이 모든 도구가 동일한 일을 하고 있다는 점입니다. 즉, 당신의 의도 (intent)를 받아 행동 (actions)으로 전환한 뒤, 그 결과를 보여주는 것입니다.

CS 학위 없이 시작하는 방법

첫 번째 단계는 전체 앱을 만드는 것이 아니라, 가능한 한 가장 작은 실제 작업을 수행하는 것입니다. MIT의 예시는 좋은 형태를 보여줍니다. 이미 가지고 있는 스크립트를 가져와서 에이전트에게 다음과 같이 말하세요. "이것을 인자 파싱 (argument parsing) 기능이 있는 제대로 된 커맨드 라인 프로그램으로 바꿔줘." 한 번의 변경, 하나의 파일, 그리고 결과를 확인할 수 있는 무언가로 시작하세요. 당신은 에이전트가 똑똑한지 테스트하는 것이 아닙니다. 묘사하고 (describe), 관찰하고 (watch), 수정하고 (correct), 반복하는 (repeat) 루프 (loop)를 배우는 것입니다.

그 과정에서 복리로 쌓이는 단 하나의 기술은 좋은 사양 (specification)을 작성하는 것이며, 이는 과학이라기보다 예술에 가깝습니다. MIT 강의는 다음과 같이 두 가지 실패 방향에 대해 한 번에 경고합니다.

에이전트에게 주는 입력값이 에이전트가 당신이 원하는 대로 행동할 수 있을 만큼 충분히 묘사적이어야 하지만, 그렇다고 당신이 직접 너무 많은 일을 해야 할 정도로 과도하게 묘사되어서는 안 됩니다.

MIT, "Agentic Coding," The Missing Semester of Your CS Education

너무 모호하면 에이전트가 추측하게 되는데, 대개 틀립니다. 반대로 너무 상세하면 당신이 영어로 코드를 작성하는 셈이 되어 에이전틱 코딩의 의미가 퇴색됩니다. 핵심(sweet spot)은 '무엇(what)'을 할 것인지와 '제대로 작동했는지 어떻게 알 수 있는지(how-you-will-know-it-worked)'를 명시하고, '어떻게(how)' 구현할지는 에이전트에게 맡기는 것입니다. 실제 사례를 통해 그 차이를 살펴보겠습니다.

모호한 예: "로그인 페이지를 만들어줘."

구체적인 예: "이메일과 비밀번호를 사용하는 로그인 페이지를 만들어줘. 이메일 형식이 유효하지 않으면 인라인 에러(inline error)를 표시해줘. 로그인 시도 5회 실패 시 계정을 5분 동안 잠가줘. 성공 시 /dashboard로 리다이렉트(redirect)해줘. 인증되지 않은 사용자가 /dashboard에 접속하면 다시 /login으로 리다이렉트시켜줘."

두 번째 예시는 코드가 아닙니다. 평이한 언어로 작성된 명확한 '완료 정의(description of done)'이며, 이것이 바로 엔지니어가 아닌 사람도 가질 수 있는 정확한 기술입니다. 구현은 에이전트가 처리합니다. 당신은 기준(standard)을 유지합니다.

마지막 시작 습관은 규칙 파일(rules file)을 유지하는 것입니다. 모든 에이전트는 프로젝트 레벨의 파일(보통 AGENTS.md)을 찾습니다. 여기에 당신의 컨벤션(conventions)을 적어두고, 더 유용하게는 에이전트가 이전에 저질렀던 모든 실수를 기록하여 같은 실수를 반복하지 않도록 만드세요. 이를 인턴을 위한 온보딩 문서(onboarding doc)라고 생각하십시오. 이는 당신이 들일 수 있는 가장 적은 노력으로 얻을 수 있는 신뢰성입니다.

그리고 네, 무료로 시작할 수 있습니다. 대부분의 에이전트는 무료 티어(free tier)나 저렴한 입문용 플랜을 제공하며, 오픈 소스(open-source) 옵션은 당신의 로컬 머신에서 실행할 수 있습니다. 비용은 장벽이 아닙니다. 진짜 장벽은 무엇을 요청해야 하는지 아는 것과, 답변이 틀렸을 때 이를 알아차리는 능력입니다.

함정: 80퍼센트 문제 (the 80 percent problem)

여기에 절벽이 있습니다. 에이전트는 데모(demo)처럼 보이는 소프트웨어 부분에는 놀라울 정도로 뛰어나지만, 그것을 실제 제품(product)으로 만드는 부분에서는 고집스럽게 약합니다. 이 패턴은 매우 흔해서 이름이 붙여질 정도인데, 바로 '80퍼센트 문제'입니다.

에이전트는 작동하는 코드를 작성했습니다. 하지만 에이전트는 살아남는 코드를 작성하지는 못했습니다.

Augment Code, "The 80% Problem"

첫 80%는 해피 패스 (happy path)입니다. 즉, 기능을 예상된 방식으로 사용할 때 기능이 의도한 대로 작동하는 단계입니다. 누락된 나머지 20%는 그것을 '실제'로 만드는 모든 것입니다. 예상하지 못한 입력값에 대한 에러 핸들링 (Error handling), 단일 양식이 아닌 시스템 전체에 적용되는 보안 (Security), 왜 고장 났는지 파악할 수 있게 해주는 로깅 (Logging), 그리고 엣지 케이스 (edge cases) 등이 여기에 해당합니다. 그리고 그 20%는 그저 예의 바르게 기다리고만 있지 않습니다. 해결되지 않은 채 방치되면 기술 부채 (technical debt)로 쌓이게 되며, 이는 처음부터 올바르게 구축했을 때보다 나중에 수정하는 비용이 더 많이 듭니다. 왜냐하면 그때쯤이면 중복과 불일치가 당신이 읽지도 않은 파일들 전반에 퍼져 있기 때문입니다.

이것이 대부분의 초보자가 부딪히고 오해하는 지점입니다. 데모는 작동했으니 프로젝트가 90% 완료된 것처럼 느껴지지만, 새로운 변경 사항이 생길 때마다 기존의 두 가지 기능이 망가지고 아무도 그 이유를 말할 수 없게 됩니다. 우리는 I built a vibe-coding mess에서 그 이야기의 한 버전을 들려주었고, The Second 80%에서 왜 마지막 구간이 그토록 완고한지에 대해 깊이 파고들었습니다. 당신이 에이전틱 코딩 (agentic coding)을 잘못한 것이 아닙니다. 코드를 생성하는 것과 신뢰할 수 있는 제품을 만드는 것은 서로 다른 작업이며, 에이전트 (agent)는 오직 첫 번째 작업에만 자원했을 뿐입니다. 이 접근 방식 전체의 솔직한 트레이드오프 (trade-off)는 다음과 같습니다. 시작 단계에서의 속도, 마무리 단계에서의 부채, 그리고 그 부채는 당신이 그 안에 발을 들이기 전까지는 보이지 않는다는 것입니다.

격차를 줄이는 기술

그렇다면 병목 현상 (bottleneck)이 코드 생성에 있는 것이 아니라면, 무엇일까요? '바이브 코딩 (vibe coding)'이라는 용어를 만들고 올해

Andrej Karpathy는 Sequoia의 AI Ascent에서 중요한 경계선을 그었습니다.

바이브 코딩 (Vibe coding)은 소프트웨어 측면에서 모든 사람이 할 수 있는 일의 하한선 (floor)을 높이는 것에 관한 것입니다. 에이전틱 엔지니어링 (Agentic engineering)은 전문적인 소프트웨어의 품질 기준 (quality bar)을 유지하는 것에 관한 것입니다.

Andrej Karpathy, Sequoia AI Ascent 2026

하한선(floor)을 높이는 것이 나머지 80%를 달성하게 해줍니다. 품질 기준(quality bar)을 유지하는 것이 나머지 20%를 달성하게 해주며, Karpathy는 그 방법을 명확히 제시합니다. 즉, 에이전트(agent)와 협력하여 매우 상세한 명세(spec), 기본적으로 문서(docs)를 설계한 다음, 에이전트가 그 명세에 따라 코드를 작성하도록 하는 것입니다. 핵심 기술은 코딩이 아닙니다. 정밀하게 명세(specifying)하고 정직하게 검증(verifying)하는 것입니다. 이것이 바로 에이전트가 당신을 대신해 할 수 없는 일입니다. 왜냐하면 그것이 무엇이 '옳은지'를 정의하는 것이며, 에이전트가 바로 그 검증을 받는 대상이기 때문입니다.

이것이 바로 BrainGrid가 메우기 위해 구축된 격차이며, 정확히 컴퓨터 과학 (CS) 학위가 없는 사람들을 위해 만들어졌습니다. BrainGrid는 아이디어를 당신이 신뢰할 수 있는 실제 제품으로 만들어주는 시스템입니다. 당신이 위에서 로그인 페이지를 설명했던 것처럼 평이한 언어로 기능을 설명하면, Planning Agent(기획 에이전트)가 시니어 엔지니어가 할 법한 명확화 질문(clarifying questions)을 던지고, 당신이 생각하지 못한 예외 케이스(edge cases)를 드러내며, 당신의 의도를 명시적인 수락 기준(acceptance criteria)을 포함한 요구사항으로 변환합니다. 그 요구사항이 바로 당신의 에이전트가 작업할 명세(spec)이자, 결과물이 검증될 기준이 됩니다.

그다음부터는 구축 방법을 선택합니다. 범위가 정해진 작업(scoped tasks)을 당신의 환경에 있는 Claude Code, Cursor, 또는 Codex에 전달하거나, Builder Agent(빌더 에이전트)가 실시간 미리보기가 가능한 관리형 샌드박스(managed sandbox)에서 직접 구축하고 풀 리퀘스트(pull request)를 생성하도록 할 수 있습니다. 어떤 방식이든, 검증(verification)이 루프를 완성합니다. 모든 수락 기준(acceptance criterion)이 결과물과 대조되어 확인되며, 증거가 당신의 의도대로 작동함을 보여줄 때까지 기능은 완료된 것이 아닙니다. 이로써 나머지 20%는 운영 환경(production)에서 뒤늦게 발견되는 부분이 아니라, 사전에 명세(specifying)된 부분이 됩니다. 이것이 바로 Plan(계획), Build(구축), Verify(검증), Repeat(반복)로 이어지는 전체 루프이며, 이는 우리가 에이전틱 엔지니어링 (agentic engineering)과 명세 기반 개발 (spec-driven development)에서 다루는 것과 동일한 규율입니다.

도구의 이름과 유행하는 용어들을 걷어내고 나면 그 논리는 그 자체로 성립합니다. 에이전틱 코딩 (Agentic Coding)은 소프트웨어 제작 비용을 거의 제로(0)에 가깝게 낮추었으며, 이는 더 이상 희소한 자원이 '타이핑'이 아님을 의미합니다. 이제 중요한 것은 당신이 무엇을 원하는지 아는 것과, 그것을 얻었음을 증명하는 것입니다. 코딩을 할 줄 몰라서 개발을 할 수 없다는 말을 들어왔던 도메인 전문가 (Domain Expert)라면, 이 방정식은 방금 당신에게 유리하게 바뀌었습니다. 남은 작업은 당신이 항상 잘해왔던 바로 그 작업입니다.

FAQ

에이전틱 코딩 (Agentic Coding)이란 무엇인가요?

에이전틱 코딩 (Agentic Coding)은 자율적인 AI 에이전트 (AI Agents)가 최소한의 인간 개입으로 코드를 계획, 작성, 테스트 및 수정하는 소프트웨어 개발 접근 방식입니다. 자동 완성 (Autocomplete)처럼 다음 줄을 제안하는 대신, 코딩 에이전트는 상위 수준의 지시 사항을 받아 이를 단계별로 나누고, 프로젝트 전반의 파일을 읽고 쓰며, 명령어를 실행하고, 자신의 작업 내용을 점검하며, 작업이 완료될 때까지 반복합니다. 당신은 에이전트를 지시하고 결과를 검토하며, 에이전트는 구현 (Implementation)을 수행합니다.

AI 코딩과 에이전틱 코딩의 차이점은 무엇인가요?

전통적인 AI 코딩 어시스턴트 (AI Coding Assistants)는 반응형 (Reactive)입니다. 즉, 당신이 타이핑하기를 기다렸다가 제안을 하거나 질문에 답합니다. 반면 에이전틱 코딩 도구는 자율적 (Autonomous)입니다. 목표를 설정하면 파일 탐색, 터미널 명령어 실행, 테스트 실패 시 자체 수정 등을 통해 처음부터 끝까지 실행합니다. 가장 간단하게 표현하자면, 어시스턴트는 당신의 문장을 완성해 주는 존재이고, 에이전트는 심부름을 수행하는 존재입니다.

에이전틱 코딩에서의 80퍼센트 문제 (80 percent problem)란 무엇인가요?

80퍼센트 문제 (80 percent problem)란 에이전트가 안정적으로 생성해내는 작동 가능한 코드(솔루션의 약 80%)와, 에러 처리 (error handling), 보안 (security), 관찰 가능성 (observability), 예외 상황 (edge cases), 그리고 컴플라이언스 (compliance)와 같은 프로덕션 등급 (production-grade)의 나머지 20% 사이의 간극을 의미합니다. 에이전트는 해피 패스 (happy-path) 데모에는 매우 뛰어나지만, 소프트웨어가 실제 사용 환경에서 생존하게 만드는 부분에는 취약합니다. 이를 해결하지 않고 방치하면, 그 20%는 기술 부채 (technical debt)로 쌓이게 되며, 처음부터 올바르게 구축하는 것보다 나중에 수정하는 데 더 많은 비용이 들게 됩니다. 해결책은 에이전트가 단순히 데모 수준이 아니라 전체 표준에 맞춰 구축할 수 있도록, 사전에 전체 표준을 정의하는 것입니다.

에이전틱 코딩을 무료로 할 수 있나요?

네. 대부분의 코딩 에이전트는 무료 티어 (free tier) 또는 저비용 입문 플랜을 제공하며, 자신의 컴퓨터에서 비용 없이 실행할 수 있는 오픈 소스 (open-source) 에이전트들도 있습니다. 비용은 시작을 가로막는 실제 장벽인 경우가 드뭅니다. 더 어려운 부분은 명확한 사양 (specification)을 작성하는 법을 배우는 것과 에이전트의 출력이 잘못되었을 때 이를 인식하는 법을 배우는 것인데, 이 두 가지 모두 작은 작업들을 통해 무료로 연습할 수 있습니다.

에이전틱 코딩을 하려면 코딩을 할 줄 알아야 하나요?

컴퓨터 과학 (CS) 학위가 필요하지는 않지만, 판단력 (judgment)은 필요합니다. 가장 중요한 기술은 무엇을 원하는지, 그리고 그것이 제대로 작동했는지 어떻게 알 수 있는지를 명시하는 명확한 사양 (specification) 작성 능력과, 결과를 정직하게 검증하는 능력입니다. MIT의 프레임워크에 따르면 코딩 에이전트와 협업하는 것은 인턴을 관리하는 것과 같습니다. 당신은 방향을 제시하고 실수를 잡아내며, 에이전트는 세부적인 작업을 수행합니다. 자신의 분야에서 무엇이 좋은 결과물인지 정확히 아는 도메인 전문가 (domain experts)들은 종종 이미 가장 중요한 기술을 갖추고 있습니다. BrainGrid의 플래닝 에이전트 (Planning Agent)와 같은 도구는 평이한 언어로 된 아이디어를 수락 기준 (acceptance criteria)이 포함된 구조화된 요구사항으로 변환해주므로, 직접 코드를 작성하지 않고도 사양 정의와 검증을 수행할 수 있습니다.

BrainGrid는 당신의 평이한 언어로 된 아이디어를 코딩 에이전트가 구축하고 검증할 수 있는 사양으로 변환해주는 AI 제품 플래너 (AI Product Planner)입니다. 이를 통해 마지막 20%가 더 이상 뜻밖의 문제가 되지 않도록 도와줍니다. braingrid.ai에서 체험해보세요.