방법 대신 목적지 | What vs How

Overview

Part 1에서 같은 프롬프트를 넣어도 어떤 때는 깔끔한 코드가, 어떤 때는 엉뚱한 코드가 나온 경험이 있을 것입니다.

LLM은 본질적으로 뽑기 기계입니다. 버튼을 누르면 매번 다른 결과가 나옵니다. Part 2의 목표는 이 뽑기를 자판기로 바꾸는 것입니다. 버튼을 누르면 매번 원하는 결과가 나오게 만듭니다.

그 첫 번째 전환점이 AI에게 일을 맡기는 방식입니다.

학습 목표

• What vs How 의 차이와 What 방식이 AI 협업에 유리한 이유를 이해합니다
• 같은 기능을 How와 What 두 가지로 지시해 보고 차이를 구별할 수 있습니다
• What 방식으로 가능해지는 에이전트 루프의 구조와 현재의 경계를 설명할 수 있습니다

원리: 방법 대신 목적지 주기

택시를 타고 강남역에 간다고 떠올려 보겠습니다.

How(어떻게) 방식으로 경로를 단계별로 지시합니다.

"여기서 좌회전, 두 번째 신호에서 우회전, 고가도로 타고 3km 직진."

What(무엇) 방식으로 목적지만 말합니다.

"강남역 2번 출구요."

How 방식에서는 공사 중인 도로가 나오면 기사가 멈추고, 승객이 새 경로를 다시 알려 줘야 합니다. What 방식에서는 기사가 알아서 우회합니다. 도착이라는 결과만 같으면 어떤 경로든 상관없기 때문입니다.

AI에게 코드를 맡길 때도 같은 차이가 있습니다. 방법을 지정하면 AI는 더 나은 대안을 찾으려 하지 않습니다. "useReducer로 바꿔"라고 지시하면, 커스텀 훅으로 분리하는 게 더 자연스러운 상황에서도 AI는 useReducer 쪽으로 끌려갑니다.

같은 기능, 두 가지 지시 방식

같은 기능("Todo 앱에 남은 항목 수 표시")을 두 방식으로 지시해 봅니다.

How 방식:

"TodoApp 컴포넌트에서 todos 배열의 completed가 false 인 항목 수를 계산하는 변수를 만들어. 목록 아래에 p 태그를 추가하고, '{count}개 남음' 텍스트를 넣어. 클래스는 text-sm text-gray-500."

What 방식:

"Todo 목록에 남은 항목 수를 보여줘. 완료하지 않은 할 일이 몇 개인지 한눈에 보고 싶어."

두 지시가 같은 결과를 내긴 합니다. 하지만 How 방식을 쓰려면 개발자가 먼저 알아야 하는 게 너무 많습니다. 컴포넌트 이름이 TodoApp 인지 TodoList 인지, state가 todos 배열인지, completed 필드가 맞는지, 프로젝트가 쓰는 스타일 컨벤션이 text-sm text-gray-500 인지. 그걸 다 파악할 시간이면 차라리 직접 코드를 쓰는 편이 빠릅니다. 이 지점에서 What 방식이 만드는 두 가지 변화가 드러납니다.

달라지는 점 1: 한 문장으로 줄어드는 지시

What 방식으로 넘어가는 순간, 앞서 나열한 빈칸(컴포넌트 이름, state 구조, 스타일 컨벤션)을 개발자가 채울 필요가 없어집니다. AI가 프로젝트를 직접 열어 보고 채웁니다.

AI가 대신 채우는 빈칸: 파일 구조, 상태, 컨벤션

What 방식으로 지시를 받은 AI는 다음 순서로 움직입니다.

1. 프로젝트 파일 구조를 탐색합니다
2. 기존 컴포넌트와 state 구조를 읽습니다
3. 적절한 위치에 코드를 추가합니다
4. 기존 스타일 컨벤션에 맞춰 작성합니다

Claude Code 같은 Agentic 도구이기 때문입니다. package.json 을 보고 의존성과 스크립트를 파악하고, 기존 코드를 읽어 패턴을 이해하고, 그걸 새 코드에 반영합니다. 개발자가 설명하는 것보다 AI가 직접 보는 편이 더 정확합니다. 설명은 개발자의 기억을 거치며 낡거나 어긋날 수 있지만, 코드에는 지금 프로젝트가 어떻게 생겼는지 그대로 적혀 있기 때문입니다.

파일 이름·스타일 컨벤션을 외워 두는 부담은 그동안 개발자가 떠안아 왔던 일입니다. 본업은 무엇을 만들지 정하는 일입니다. What 방식은 그 짐을 AI에게 넘깁니다. 개발자는 "무엇을 만들지"에 집중하면 됩니다.

달라지는 점 2: 에이전트 루프로 다른 경로 시도

두 번째 변화는 더 근본적입니다. 목적지만 정해져 있으면 AI는 경로를 바꿔 가며 시도할 수 있습니다.

How 방식에서 AI가 막히면 멈춥니다. 경로가 이미 지정돼 있고, 그 경로가 막혔을 때 "다음에 뭘 할지"를 개발자가 다시 알려 줘야 하기 때문입니다. What 방식에서 AI가 막히면 다른 경로를 시도합니다. 목표(원하는 동작)는 그대로이고, 경로는 AI의 판단 영역이기 때문입니다.

이 "시도 → 확인 → 수정"의 자율적 반복이 Anthropic 공식 문서가 말하는 에이전트 루프(Agent Loop)입니다. Part 1에서 본 Agent의 정의(Tool + Loop + 자율 판단)가 개발 작업 안에서 실제로 어떻게 돌아가는지 보여주는 장면입니다. 코드는 실행하면 동작하거나 에러를 뱉고, AI는 그 피드백을 읽어 다음 시도를 결정할 수 있습니다. 코드를 다루는 작업이라서 이 루프가 돕니다.

AI가 스스로 판정할 수 있는 경계

에이전트 루프가 돌기는 하지만, 지금 AI가 스스로 확인할 수 있는 건 "코드가 에러 없이 실행되는가" 까지입니다. "이 기능이 사용자가 원하는 대로 동작하는가"는 아직 사람이 판단해야 합니다. Todo 앱에서 남은 항목 수가 정확한지, 완료하면 줄어드는지, 0 개일 때 어떻게 표시되는지는 브라우저를 열어 직접 보기 전까지는 AI도 알 수 없습니다.

즉 What 방식은 AI의 경로 탐색을 열었지만, 최종 판정은 여전히 사람이 합니다. Part 1 끝에서 사람의 몫으로 남은 수동 체크리스트가 여기서 다시 모습을 드러냅니다. 다음 레슨에서는 이 경계를 한 단계 더 넓혀 봅니다.

핵심 포인트 정리

1. 방법(How) 말고 목적지(What)를 줍니다: 방법을 지시하면 그 단어에 AI의 주의가 쏠려 더 나은 대안을 놓칩니다. 목적지만 주면 AI가 경로를 직접 선택합니다.
2. 지시가 한 문장으로 줄어듭니다: 파일 이름·state 구조·스타일 컨벤션은 AI가 프로젝트를 열어 직접 확인합니다. 개발자가 미리 파악해 설명하는 것보다 정확합니다.
3. 에이전트 루프가 돌아갑니다: 목적지가 정해져 있으면 AI는 시도 → 확인 → 수정을 스스로 반복합니다. 단 지금 AI가 판정할 수 있는 건 "에러 없이 실행되는가" 까지이고, "원하는 동작인가"의 최종 판단은 아직 사람 몫입니다.

FAQ

• Q: How 방식을 아예 쓰면 안 되나요?

  • A: 두 상황에서는 How가 맞습니다. 첫째, 변경 대상이 명확해 AI가 판단할 여지가 없는 경우입니다 (예: "변수 이름을 todoList에서 tasks로 바꿔 줘"). 둘째, AI가 같은 실수를 반복할 때 교정하는 경우입니다 (예: "코드 변경 후에는 반드시 타입 체크를 실행해"). 핵심은 AI가 판단할 여지가 클수록 What, AI가 혼자서는 알 수 없는 것만 How입니다

• Q: What으로 시키면 원하는 결과가 안 나올 수도 있지 않나요?

  • A: 네, 그래서 결과를 검증하는 장치가 필요합니다. 지금은 브라우저에서 직접 클릭해 확인하고 있지만, 다음 레슨에서 배우는 테스트 기반 검증을 쓰면 검증 루프까지 AI가 스스로 돌릴 수 있습니다

• Q: 에이전트 루프가 돌면 개발자는 뭘 하나요?

  • A: 역할이 나뉩니다. 개발자는 "무엇을 만들지·어떤 제약을 둘지·이 결과가 맞는지"에 집중하고, AI는 "그걸 만들려면 지금 뭘 해야 하는지"를 판단합니다

이어서 배울 내용

What 방식이 AI의 경로 탐색을 열었지만, "원하는 동작인가"의 최종 판정은 여전히 사람 몫으로 남았습니다. 다음 레슨은 그 판정까지 AI가 스스로 할 수 있도록, 브라우저에서 사람이 돌리던 수동 체크리스트를 AI가 읽을 수 있는 정답지로 바꾸는 방법을 다룹니다.

• 수동 체크리스트를 테스트 코드로 변환
• AI 에이전트 루프가 실제로 돌아가는 현장 체험
• 기존 기능이 깨지지 않는지 자동으로 확인하기