방법 대신 목적지 | What vs How
AI에게 방법보다 목적지를 말하는 방식과 What 방식이 에이전트 루프를 여는 이유를 설명할 수 있습니다
Overview
Part 1에서 같은 프롬프트를 넣어도 어떤 때는 깔끔한 코드가, 어떤 때는 엉뚱한 코드가 나온 경험이 있을 것입니다.
LLM은 본질적으로 뽑기 기계입니다. 버튼을 누르면 매번 다른 결과가 나옵니다. Part 2의 목표는 이 뽑기를 검증 가능한 작업 흐름으로 바꾸는 것입니다. 매번 완벽히 같은 결과를 기대하는 대신, 결과가 수용 가능한 기준 안에 들어오도록 확인하고 고칩니다.
그 첫 번째 전환점이 AI에게 일을 맡기는 방식입니다.
학습 목표
- What vs How의 차이와 What 방식이 AI 협업에 유리한 이유를 이해합니다.
- 같은 기능을 How와 What 두 가지로 지시해 보고 차이를 구별할 수 있습니다.
- What 방식으로 시작되는 에이전트 루프가 어디까지 스스로 판단할 수 있는지 설명할 수 있습니다.
원리: 경로보다 목적지를 말하기
택시를 타고 강남역에 가는 상황을 떠올려 보겠습니다.
How(어떻게) 방식으로 경로를 단계별로 지시합니다.
"여기서 좌회전, 두 번째 신호에서 우회전, 고가도로 타고 3km 직진."
What(무엇) 방식으로 목적지만 말합니다.
"강남역 2번 출구요."
How 방식에서는 공사 중인 도로가 나오면 기사님이 멈추고, 승객이 새 경로를 다시 알려 줘야 합니다. What 방식에서는 기사님이 알아서 우회합니다. 도착이라는 결과만 같으면 어떤 경로든 상관없기 때문입니다.
기능 구현에서도 같은 차이가 있습니다. 방법을 지정하면 AI는 먼저 그 방법 안에서 구현하려 합니다. "useReducer로 바꿔"라고 지시하면, 커스텀 훅으로 분리하는 게 더 자연스러운 상황에서도 AI는 useReducer를 전제로 해법을 찾습니다. 그래서 방법까지 정해 주기보다 원하는 결과를 먼저 말하는 편이 낫습니다.
같은 목표를 두 방식으로 맡겨 보기
택시 비유를 기능 구현으로 옮겨 보겠습니다. Todo 앱에 남은 항목 수를 보여주는 기능을 두 방식으로 맡겨 보겠습니다.
How 방식으로 맡기면 다음과 같습니다.
"TodoApp 컴포넌트에서 todos 배열의 completed가 false 인 항목 수를 계산하는 변수를 만들어. 목록 아래에 p 태그를 추가하고, '{count}개 남음' 텍스트를 넣어. 클래스는 text-sm text-gray-500."
What 방식으로 맡기면 다음과 같습니다.
"Todo 목록에 남은 항목 수를 보여줘. 완료하지 않은 할 일이 몇 개인지 한눈에 보고 싶어."
결과만 보면 두 지시는 같습니다. 둘 다 Todo 앱에 남은 항목 수를 보여 달라는 요청입니다. 차이는 그 결과에 이르는 경로를 누가 정하느냐에 있습니다.
세부 경로를 직접 말할 때 생기는 문제
How 방식을 쓰려면 개발자가 먼저 알아야 하는 게 많습니다. 컴포넌트 이름이 TodoApp인지 TodoList인지, 코드 구조가 어떤지, 프로젝트가 쓰는 스타일 컨벤션이 text-sm text-gray-500인지 미리 파악해야 합니다.
그 정보를 모두 확인해 설명해야 한다면 AI에게 맡기는 이점이 줄어듭니다. 경로를 직접 말하는 순간, 개발자는 구현 세부 정보를 먼저 조사하고 AI는 그 경로 안에서만 해법을 찾게 됩니다.
목적지만 말할 때 달라지는 일
What 방식으로 넘어가면 앞서 나열한 세부 정보(컴포넌트 이름, 코드 구조, 스타일 컨벤션)를 개발자가 직접 설명하지 않아도 됩니다. AI가 프로젝트를 직접 열어 보고 확인합니다.
AI가 코드에서 확인하는 것들
What 방식으로 지시하면 AI는 다음 순서로 움직입니다.
- 프로젝트 파일 구조를 탐색합니다.
- 기존 컴포넌트와 코드 구조를 읽습니다.
- 적절한 위치에 코드를 추가합니다.
- 기존 스타일 컨벤션에 맞춰 작성합니다.
Claude Code 같은 Agentic 도구라서 가능합니다. package.json을 보고 의존성과 스크립트를 파악하고, 기존 코드를 읽어 패턴을 이해하고, 그 패턴을 새 코드에 반영합니다. 개발자가 설명하는 것보다 AI가 직접 보는 편이 더 정확합니다. 설명은 개발자의 기억을 거치며 낡거나 어긋날 수 있지만, 코드에는 현재 프로젝트의 구조와 규칙이 그대로 담겨 있기 때문입니다.
개발자가 미리 파일 이름과 스타일 규칙을 모두 설명할 필요는 없습니다. AI가 코드에서 확인할 수 있는 내용은 직접 읽게 두고, 개발자는 원하는 결과와 판단 기준을 분명히 적는 데 집중합니다.
막혔을 때 다른 경로를 찾는 루프
목적지만 정하면 AI는 경로를 바꿔 가며 시도할 수 있습니다.
How 방식에서 AI가 막히면 멈춥니다. 경로가 이미 지정돼 있고, 그 경로가 막혔을 때 "다음에 뭘 할지"를 개발자가 다시 알려 줘야 하기 때문입니다. What 방식에서 AI가 막히면 다른 경로를 시도합니다. 목표(원하는 동작)는 그대로이고, 경로는 AI의 판단 영역이기 때문입니다.
이 "시도 → 확인 → 수정"의 자율적 반복을 Anthropic 공식 문서는 에이전트 루프(Agent Loop)라 부릅니다. Part 1에서 본 Agent(Tool + Loop + 자율 판단)가 기능 구현에서 실제로 작동합니다. 코드가 실행 즉시 결과나 에러를 출력하므로, AI는 그 피드백을 읽고 사람이 개입하지 않아도 다음 시도를 스스로 정합니다.
AI가 스스로 판정할 수 있는 경계
에이전트 루프가 돌기는 하지만, 지금 AI가 스스로 확인할 수 있는 건 "코드가 에러 없이 실행되는가" 까지입니다. "이 기능이 사용자가 원하는 대로 동작하는가"는 아직 사람이 판단해야 합니다. Todo 앱에서 남은 항목 수가 정확한지, 완료하면 줄어드는지, 0 개일 때 어떻게 표시되는지는 브라우저를 열어 직접 보기 전까지는 AI도 알 수 없습니다.
즉 What 방식은 AI의 경로 탐색을 열었지만, 최종 판정은 여전히 사람이 합니다. Part 1에서 사람이 직접 돌리던 수동 체크리스트가 여기서도 여전히 필요합니다. 다음 레슨에서는 이 경계를 한 단계 더 넓혀 봅니다.
핵심 포인트 정리
- What 방식: 방법보다 원하는 결과를 먼저 말하면 AI가 프로젝트 맥락을 확인하고 구현 경로를 선택합니다.
- 코드 구조 확인: 파일 이름, 코드 구조, 스타일 규칙은 AI가 현재 코드를 읽어 직접 확인합니다.
- 에이전트 루프의 경계: AI는 시도와 실행 결과 확인을 반복할 수 있지만, 원하는 동작인지 판단하려면 테스트 같은 기준이 필요합니다.
FAQ
이어서 배울 내용
What 방식으로 AI가 경로를 탐색할 수 있게 됐지만, "원하는 동작인가"의 최종 판정은 여전히 사람 몫입니다. 다음 레슨은 그 판정까지 AI가 스스로 할 수 있도록, 브라우저에서 사람이 돌리던 수동 체크리스트를 AI가 읽을 수 있는 정답지로 바꾸는 방법을 다룹니다.
- 수동 체크리스트를 테스트 코드로 변환
- AI 에이전트 루프 직접 실행해 보기
- 기존 기능이 그대로 동작하는지 자동으로 확인하기