이 장에서 배우는 것 읽는 장이 아니라 하는 장입니다. 안전한 순서로 첫 업무를 맡겨봅니다.
처음부터 파일을 고치게 하지 않습니다. 세 단계로 올라갑니다.
graph TD
A["1단계: 계획만<br/>실행 안 함"] --> B["2단계: 읽기만 하는 업무"]
B --> C["3단계: 파일을 고치는 업무"]왼쪽 끝 목록에서 등록한 작업 폴더를 고르고 사이드바의 새 업무를 눌러, 자율성을 계획만으로 선택하세요.
이 단계의 목적은 결과물이 아니라 "무엇을 하려는지 보는 것"입니다. 계획이 엉뚱하면 지시가 부족했던 것이고, 그건 실행 전에 알아야 합니다.
계획이 그럴듯하면 실제 업무로 넘어갑니다. 읽고 정리만 하는 것부터입니다.
세 번째가 중요합니다. 결과를 검증해봐야 이 도구를 얼마나 믿을지 감이 잡힙니다.
이제 실제로 고치게 합니다. 작고 되돌리기 쉬운 것부터입니다.
좋은 지시의 네 요소를 그대로 적용한 형태입니다.
작업 전에 커밋해두세요. git을 쓰고 있다면 되돌리기가 쉽습니다. 처음 몇 번은 이렇게 안전망을 두는 게 좋습니다.
| 항목 | 설명 |
|---|---|
| 작업 폴더 | 어느 폴더에서 일할지 |
| 자율성 수준 | 다음 장에서 자세히 |
| 지시 내용 | 무엇을 할지 |
맡긴 일은 사이드바의 업무 칸에 쌓이고, 누르면 작업대에 탭으로 열립니다. 목록은 상태로 묶입니다 — 끝났는데 아직 안 본 것이나 승인·답을 기다리는 것은 맨 위 확인 필요에, 도는 것은 진행 중에, 나머지는 최근에 섭니다.
작업 폴더가 여러 개면 각각에 다른 업무를 동시에 맡길 수 있습니다.
전부 함께 돌아가고, 대시보드에서 각각의 진행이 보입니다. 이게 관제실이라고 부르는 이유입니다.
「처음 써보기」에서 배운 것과 같습니다 — 이어서 다시 말하면 됩니다.
"전체 코드를 리팩터링해줘" 같은 것으로 시작하면, 뭘 했는지 확인할 수도 없고 되돌리기도 어렵습니다. 작게 시작해서 신뢰를 쌓는 순서가 맞습니다.
바로 실행시키면 "왜 이걸 건드렸지?"를 사후에 알게 됩니다. 처음 몇 번은 계획만으로 보는 게 훨씬 빠릅니다.
첫 몇 번은 결과를 직접 확인해보세요. 어디까지 맞고 어디서 틀리는지 감이 잡혀야 어디까지 맡길지 정할 수 있습니다.
1. 왜 "계획만" 단계부터 시작합니까?
무엇을 하려는지 실행 전에 보기 위해서입니다. 계획이 엉뚱하면 지시가 부족했던 것이고, 그건 파일이 바뀌기 전에 알아야 합니다.
2. 2단계(읽기만)에서 결과를 직접 확인해봐야 하는 이유는?
어디까지 믿을지 감을 잡기 위해서입니다. 검증해봐야 어디까지 맡길 수 있는지 판단할 수 있습니다.
3. 여러 폴더에 동시에 업무를 맡기면 무엇이 좋습니까?
서로 기다리지 않고 함께 돌아갑니다. 대시보드에서 각각의 진행이 보이고, 이것이 "관제실"이라고 부르는 이유입니다.
업무가 내부에서 어떻게 실행되고 결과가 나오는지 봅니다 → 업무 실행 원칙과 결과 보기
자율성 수준을 자세히 봅니다 → 어디까지 맡길지 정하기
이 프로젝트의 구조를 파악하고,README를 개선한다면 무엇을 어떻게 바꿀지 계획을 세워주세요.실제로 수정하지는 마세요.이 프로젝트에서 테스트가 없는 파일 목록을 뽑아주세요.파일 경로와 그 파일이 무엇을 하는지 한 줄 설명을 표로 정리해주세요.파일은 수정하지 마세요.[목표]README.md의 "설치 방법" 부분을 최신 상태로 고쳐주세요.[범위]- README.md 파일만 수정- 다른 파일은 건드리지 말 것[완료 조건]- 현재 package.json의 스크립트와 일치할 것- 명령어는 복사해서 바로 실행 가능한 형태로[맥락]- 이 프로젝트는 pnpm을 씁니다 (npm 아님)shop-api → "테스트 없는 파일 목록 뽑기"shop-frontend → "사용하지 않는 컴포넌트 찾기"문서정리 → "회의록 3개를 표로 정리"표에 "마지막 수정일" 열을 추가해주세요.그리고 테스트 파일 자체는 목록에서 빼주세요.