/goal 앱 만들어줘라고 쓰지 마세요

Codex와 Claude Code를 쓰다 보면 어느 순간 같은 말을 반복하게 됩니다.

“계속해줘.” “이것도 고쳐줘.” “테스트 다시 돌려줘.” “문서도 업데이트해줘.”

AI가 빠른 것은 맞습니다. 하지만 사람이 매번 다음 지시를 넣어야 한다면, 병목은 다시 사람에게 돌아옵니다.

/goal은 이 반복을 줄여주는 기능입니다.

단순히 명령을 한 번 더 보내는 기능이 아닙니다. AI에게 어디까지 해야 끝인지 알려주고, 그 상태에 도달할 때까지 스스로 확인하고 고치게 만드는 방식에 가깝습니다.

/goal의 핵심은 AI에게 일을 더 시키는 것이 아니라, 끝나는 기준을 맡기는 것이다.

---

좋은 목표는 할 일이 아니라 끝나는 상태를 말합니다

우리는 보통 이렇게 말하곤 합니다.

/goal 앱 만들어줘

이 목표는 약합니다. 무엇이 완성인지 알 수 없기 때문입니다.

웹앱이란 무엇일까요? 화면이 뜨면 끝일까요? 로그인까지 되어야 할까요? 저장 기능도 있어야 할까요? 오류가 나지 않아야 할까요? 테스트까지 통과해야 할까요?

목표가 애매하면 AI는 둘 중 하나를 합니다.

너무 일찍 끝났다고 판단하거나, 계속 주변만 맴돕니다.

좋은 /goal은 다르게 생겼습니다.

/goal 로그인 관련 테스트가 모두 통과하고, 코드 검사와 빌드가 성공할 때까지 수정해줘.

이 목표는 훨씬 낫습니다. 끝 상태가 보이기 때문입니다.

AI가 스스로 확인할 수 있습니다.

• 로그인 테스트가 통과했는가?

• 코드 검사가 통과했는가?

• 빌드가 성공했는가?

이렇게 확인할 수 있는 기준이 있으면, AI는 끝났는지를 더 잘 판단합니다.

AI를 오래 일하게 만들고 싶다면, 무엇을 하라고 말하기보다 언제 멈춰야 하는지 알려줘야 합니다.

---

좋은 /goal에 들어가야 하는 것

좋은 /goal에는 보통 세 가지가 들어갑니다.

• 무엇이 되면 끝인지

• 무엇은 건드리면 안 되는지

• 어떤 명령으로 확인할지

예를 들면 이런 식입니다.

/goal 오래된 글 작성 기능을 새 방식으로 바꾸고, 기존 동작은 그대로 유지해줘. 테스트를 삭제하거나 건너뛰지 말고, pnpm test, pnpm lint, pnpm build가 모두 성공할 때까지 진행해줘.

이 정도로 쓰면 AI는 단순히 코드를 고치는 데서 멈추지 않습니다.

고친 뒤에 확인합니다. 실패하면 다시 고칩니다. 빠진 것이 있으면 이어서 작업합니다.

좋은 목표는 “무엇을 할지”보다 “어떤 상태가 되면 끝인지”를 더 분명하게 말합니다.

---

/goal은 프롬프트가 아니라 작업 방식입니다

/goal이 강력한 이유는 한 번의 답변이 좋아서가 아닙니다.

작업이 끝날 때마다 AI가 현재 상태를 다시 봅니다.

• 테스트가 실패했는가?

• 코드 검사에서 문제가 나왔는가?

• 빌드가 실패했는가?

• 문서가 빠졌는가?

• 아직 해야 할 일이 남았는가?

부족한 점이 보이면 스스로 다음 작업으로 이어갑니다. 사람이 계속 “다음”이라고 말하지 않아도 됩니다.

예를 들어 “리팩토링해줘”라고만 하면 결과가 흔들립니다. 어디까지 정리해야 하는지 모르기 때문입니다.

하지만 이렇게 말하면 훨씬 안정적입니다.

/goal 중복된 저장 로직을 하나로 합치되, 사용자가 보는 동작은 바꾸지 말아줘. 같은 문제가 다시 생기지 않도록 테스트를 추가하고, 기존 테스트와 코드 검사가 모두 통과할 때까지 진행해줘.

여기에는 끝나는 기준이 있습니다. 지켜야 할 선도 있습니다. 확인 방법도 있습니다.

AI가 자율적으로 움직이려면 이런 경계가 필요합니다.

---

나쁜 목표와 좋은 목표

나쁜 목표는 대체로 이렇게 생겼습니다.

/goal 앱 좋게 만들어줘

문제는 명확합니다.

좋다는 기준이 없습니다. 어디까지 해야 끝인지도 없습니다. 확인할 방법도 없습니다.

그러면 AI가 마음대로 범위를 넓히기 쉽습니다.

좋은 목표는 이렇게 생겼습니다.

/goal 설정 페이지에서 저장 실패 시 사용자에게 오류가 보이지 않는 문제를 수정해줘. 같은 문제가 다시 생기지 않도록 테스트를 추가하고, pnpm test와 pnpm lint가 모두 성공할 때까지 진행해줘. 화면 주소와 서버 명령 구조는 바꾸지 말아줘.

이 목표에는 판단 가능한 기준이 있습니다.

• 어떤 문제를 고치는지

• 어떤 테스트를 추가해야 하는지

• 어떤 명령으로 확인할지

• 무엇을 바꾸면 안 되는지

AI에게 맡길수록 이런 기준이 중요해집니다.

---

내가 가장 추천하는 방식

직접 /goal을 쓰지 않는 것입니다.

조금 이상하게 들릴 수 있지만, 실제로는 이 방식이 제일 좋습니다. 사람은 보통 목표를 너무 느슨하게 씁니다.

반대로 AI는 프로젝트를 읽고, 그 프로젝트에 맞는 좋은 /goal을 꽤 잘 만듭니다.

저는 보통 먼저 이렇게 시킵니다.

이 프로젝트 구조를 먼저 살펴보고, 내가 /goal로 맡기면 효과가 클 작업 3가지를 제안해줘. 각 항목마다 왜 좋은 목표인지, 끝나는 기준은 무엇인지, 지켜야 할 제약은 무엇인지, 어떤 명령으로 확인해야 하는지 포함해줘. 마지막에는 바로 붙여넣을 수 있는 /goal 문장으로 정리해줘.

이렇게 하면 AI가 프로젝트에 맞는 목표 후보를 만들어줍니다.

프론트엔드 앱이라면 화면 테스트, 코드 검사, 빌드 확인이 들어갈 수 있습니다. Rust나 Tauri 앱이라면 Rust 테스트와 타입 확인 명령이 들어갈 수 있습니다.

중요한 것은 내가 모든 명령을 외우는 게 아닙니다.

AI에게 먼저 프로젝트를 읽게 하고, 좋은 목표 문장을 만들게 하는 것입니다.

좋은 /goal을 쓰는 능력보다 더 중요한 것은, 좋은 /goal을 만들게 하는 능력이다.

---

특히 효과가 큰 작업들

/goal은 모든 작업에 필요한 기능은 아닙니다. 작은 수정은 그냥 바로 시키는 편이 빠릅니다.

하지만 반복해서 확인해야 하는 작업에는 강력합니다.

대규모 정리 작업에는 이렇게 쓸 수 있습니다.

/goal 오래된 도우미 함수 사용을 모두 새 함수로 바꿔줘. 사용자가 보는 동작은 바꾸지 말고, 모든 테스트와 코드 검사가 통과할 때까지 진행해줘.

깨진 테스트를 고칠 때는 이렇게 쓸 수 있습니다.

/goal 현재 실패하는 테스트를 모두 고쳐줘. 실제 문제가 있었다면 같은 문제가 다시 생기지 않도록 테스트를 추가하고, 테스트를 삭제하거나 건너뛰지 말아줘.

문서를 정리할 때는 이렇게 쓸 수 있습니다.

/goal 공개된 사용법 문서에 예시를 추가하고, 오래된 설명을 제거해줘. 문서 안의 링크가 깨지지 않는지도 확인해줘.

반복 작업에도 잘 맞습니다.

/goal 최근 글 30개에 관련된 내부 링크를 2개씩 추가해줘. 문맥상 어색한 링크는 만들지 말아줘.

이런 작업들은 사람이 중간마다 계속 “다음”을 입력하기보다, AI에게 끝나는 기준을 맡기는 편이 낫습니다.

---

제약을 넣지 않으면 AI는 쉬운 길을 찾습니다

긴 작업에서 가장 위험한 것은 AI가 목표를 달성한 것처럼 보이게 만드는 것입니다.

예를 들어 테스트를 통과시키라고만 하면, AI가 문제 있는 테스트를 삭제할 수도 있습니다. 코드 검사를 통과시키라고만 하면, 타입을 느슨하게 만들 수도 있습니다. 빌드를 성공시키라고만 하면, 문제가 되는 코드를 그냥 우회할 수도 있습니다.

그래서 /goal에는 금지 조건도 같이 넣어야 합니다.

• 테스트를 삭제하거나 건너뛰지 말 것

• 사용자가 쓰는 기능의 동작을 바꾸지 말 것

• 새 라이브러리를 추가하지 말 것

• 관련 없는 파일은 수정하지 말 것

• 타입 안정성을 낮추지 말 것

• 가짜 데이터로 실제 문제를 덮지 말 것

자율성을 주려면 경계도 같이 줘야 합니다.

---

오래 돌릴 때는 멈추는 조건도 필요합니다

/goal은 오래 돌 수 있습니다. 그래서 큰 작업에는 멈추는 조건을 넣는 편이 좋습니다.

예를 들면 이렇게 붙일 수 있습니다.

20번 시도한 뒤에도 끝나지 않으면 멈추고, 남은 문제와 막힌 이유를 정리해줘.

목표를 달성하지 못하더라도, 일정 시점 이후에는 현재 상태를 정리하게 만드는 것입니다.

이렇게 하면 같은 실패를 계속 반복하는 상황을 줄일 수 있습니다.

---

Claude Code와 Codex의 차이

Claude Code와 Codex는 둘 다 목표를 주고 오래 작업하게 만들 수 있습니다. 다만 체감은 조금 다릅니다.

Claude Code는 정해둔 목표를 기준으로 계속 이어서 작업하는 느낌이 강합니다. 자동 승인 모드와 같이 쓰면 중간 확인이 줄어들어서, 한 번 맡긴 일을 계속 진행하는 환경에 가깝습니다.

Codex는 조금 더 계획하고, 실행하고, 다시 확인하는 느낌이 강합니다. 코드베이스를 읽고, 무엇이 남았는지 판단하고, 필요한 다음 작업을 이어가는 흐름이 잘 맞습니다.

하지만 중요한 것은 어느 쪽이 더 낫냐가 아닙니다.

둘 다 애매한 말에는 약하고, 확인 가능한 목표에는 강합니다.

---

실전 템플릿

제가 자주 쓰는 형태는 이렇습니다.

/goal [원하는 최종 상태]. 끝나는 기준: [조건 1], [조건 2], [조건 3]. 제약: [하지 말아야 할 것]. 확인: [명령 1], [명령 2], [명령 3]. 막히면 멈추고 정확한 이유를 정리해줘.

예를 들면 이렇게 쓸 수 있습니다.

/goal 글 발행 설정 화면의 저장 경험을 안정화해줘. 끝나는 기준: 저장 성공과 실패 상태가 명확히 보이고, 저장 버튼을 여러 번 눌러도 중복 저장되지 않으며, 기존 설정 값이 사라지지 않는다. 제약: 새 라이브러리 추가 금지, 서버 명령 구조 변경 금지. 확인: pnpm lint, pnpm test, cargo test. 막히면 멈추고 정확한 이유를 정리해줘.

이 정도면 AI가 할 일이 훨씬 선명해집니다.

---

결론

/goal은 모든걸 해결해주는 마법의 버튼이 아닙니다.

엉성한 목표를 넣으면 엉성하게 돕니다. 하지만 끝나는 기준, 확인 명령, 지켜야 할 제약을 잘 적으면 AI를 꽤 실용적인 작업 파트너처럼 쓸 수 있습니다.

핵심은 간단합니다.

• 작업을 길게 설명하지 않습니다.

• 끝났다고 말할 수 있는 상태를 정의합니다.

• 확인할 수 없는 표현을 줄입니다.

• AI가 쉽게 우회하지 못하도록 제약을 넣습니다.

• 필요하면 AI에게 먼저 좋은 /goal을 만들게 합니다.

프롬프트를 잘 쓰는 것보다 중요한 것은 AI가 스스로 끝났는지 판단할 수 있는 환경을 만드는 것이다.

그때부터 Codex와 Claude Code는 단순한 코드 생성기가 아니라, 목표를 향해 계속 움직이는 작업 파트너에 가까워집니다.