/goal 앱 만들어줘 라고 쓰지 마세요
AI에게 일을 맡겼는데, 왜 나는 계속 신경쓰고 지시하고 있을까?
Codex와 Claude Code를 쓰다 보면 어느 순간 같은 말을 반복하게 됩니다.
“계속해줘.” “이것도 고쳐줘.” “테스트 다시 돌려줘.” “문서도 업데이트해줘.”
AI가 느려서 생기는 문제가 아닙니다. 오히려 AI는 충분히 빠릅니다. 문제는 사람이 계속 다음 지시를 넣어야 한다는 데 있습니다.
AI에게 일을 맡겼다고 생각했는데, 실제로는 사람이 계속 옆에서 판단하고 있습니다. 어디까지 했는지 보고, 무엇이 빠졌는지 확인하고, 다음 작업을 다시 지시합니다.
그러면 병목은 다시 사람에게 돌아옵니다.
AI에게 일을 맡긴다는 것은 작업 목록을 넘기는 일이 아니라, 종료 조건을 설계하는 일이다.
/goal은 이 반복을 줄이기 위한 기능입니다.
단순히 명령을 한 번 더 보내는 기능이 아닙니다. AI에게 무엇을 하라고 말하는 대신, 어떤 상태가 되면 끝인지를 알려주는 방식에 가깝습니다.
/goal의 핵심은 AI에게 일을 더 많이 시키는 것이 아닙니다. 사람이 붙잡고 있던 끝났는지 판단하는 일을 일부 넘기는 데 있습니다.
좋은 목표는 할 일이 아니라 끝나는 상태를 말합니다
우리는 보통 이렇게 말하곤 합니다.
/goal 앱 만들어줘
이 목표는 약합니다. 무엇이 완성인지 알 수 없기 때문입니다.
앱이란 무엇일까요? 화면이 뜨면 끝일까요? 로그인까지 되어야 할까요? 저장 기능도 있어야 할까요? 오류가 나지 않아야 할까요? 테스트까지 통과해야 할까요?
목표가 애매하면 AI는 둘 중 하나를 합니다.
너무 일찍 끝났다고 판단하거나, 계속 주변만 맴돕니다.
좋은 /goal은 다르게 생겼습니다.
/goal 로그인 관련 테스트가 모두 통과하고, 코드 검사와 빌드가 성공할 때까지 수정해줘.
이 목표는 훨씬 낫습니다. 끝 상태가 보이기 때문입니다.
AI가 스스로 확인할 수 있습니다.
-
로그인 테스트가 통과했는가?
-
코드 검사가 통과했는가?
-
빌드가 성공했는가?
이렇게 확인할 수 있는 기준이 있으면 AI는 끝났는지를 더 잘 판단합니다.
AI를 오래 일하게 만들고 싶다면, 무엇을 하라고 말하기보다 언제 멈춰야 하는지 알려줘야 합니다.
좋은 /goal에 들어가야 하는 것
좋은 /goal에는 보통 세 가지가 들어갑니다.
-
무엇이 되면 끝인지
-
무엇은 건드리면 안 되는지
-
어떤 명령으로 확인할지
예를 들면 이런 식입니다.
/goal 오래된 글 작성 기능을 새 방식으로 바꾸고, 기존 동작은 그대로 유지해줘. 테스트를 삭제하거나 건너뛰지 말고, pnpm test, pnpm lint, pnpm build가 모두 성공할 때까지 진행해줘.
이 정도로 쓰면 AI는 단순히 코드를 고치는 데서 멈추지 않습니다.
고친 뒤에 확인합니다. 실패하면 다시 고칩니다. 빠진 것이 있으면 이어서 작업합니다.
좋은 목표는 무엇을 할지보다 어떤 상태가 되면 끝인지를 더 분명하게 말합니다.
프롬프트를 잘 쓰는 것보다 중요한 것은, 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에는 금지 조건도 같이 넣어야 합니다.
-
테스트를 삭제하거나 건너뛰지 말 것
-
사용자가 쓰는 기능의 동작을 바꾸지 말 것
-
새 라이브러리를 추가하지 말 것
-
관련 없는 파일은 수정하지 말 것
-
타입 안정성을 낮추지 말 것
-
가짜 데이터로 실제 문제를 덮지 말 것
자율성을 주려면 경계도 같이 줘야 합니다.
이건 AI를 못 믿어서가 아닙니다. 일을 맡기는 방식의 문제입니다. 사람에게 일을 맡길 때도 “이건 건드리지 말아 달라”, “이 기준은 유지해 달라”고 말합니다. AI에게도 마찬가지입니다.
오래 돌릴 때는 멈추는 조건도 필요합니다
/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가 할 일이 훨씬 선명해집니다.
중요한 것은 문장을 길게 쓰는 게 아닙니다. AI가 스스로 판단할 수 있는 증거를 넣는 것입니다.
결론
/goal은 모든 것을 해결해주는 마법의 버튼이 아닙니다.
엉성한 목표를 넣으면 엉성하게 돕니다. 하지만 끝나는 기준, 확인 명령, 지켜야 할 제약을 잘 적으면 AI를 꽤 실용적인 작업 파트너처럼 쓸 수 있습니다.
핵심은 간단합니다.
-
작업을 길게 설명하지 않습니다.
-
끝났다고 말할 수 있는 상태를 정의합니다.
-
확인할 수 없는 표현을 줄입니다.
-
AI가 쉽게 우회하지 못하도록 제약을 넣습니다.
-
필요하면 AI에게 먼저 좋은
/goal을 만들게 합니다.
AI 시대에 사람이 계속 병목이 되는 이유도 여기에 있습니다. 우리는 일을 맡겼다고 생각하지만, 실제로는 판단 기준을 여전히 손에 쥐고 있습니다.
그래서 AI가 멈출 때마다 사람이 다시 와서 “계속해줘”, “이것도 확인해줘”, “아직 아니야”라고 말하게 됩니다.
좋은 /goal은 그 반복을 줄입니다. AI가 더 똑똑해져서가 아니라, 사람이 맡길 수 있는 형태로 일을 다시 정의했기 때문입니다.
결국 /goal의 본질은 명령을 길게 쓰는 데 있지 않습니다.
AI에게 더 많은 일을 시키는 것이 아니라, 사람이 붙잡고 있던 끝났는지 판단하는 일을 넘기는 데 있습니다.
좋은 /goal은 프롬프트 기술이라기보다 위임 기술에 가깝다.
무엇을 만들지보다 무엇이 되면 충분한지, 어디까지는 건드리면 안 되는지, 어떤 증거가 있어야 끝났다고 말할 수 있는지를 정하는 일입니다.
그때부터 Codex와 Claude Code는 단순한 코드 생성기가 아니라, 목표를 향해 계속 움직이는 작업 파트너에 가까워집니다.
