첫 업무 맡기기

이 장에서 배우는 것 읽는 장이 아니라 하는 장입니다. 안전한 순서로 첫 업무를 맡겨봅니다.

안전한 순서

처음부터 파일을 고치게 하지 않습니다. 세 단계로 올라갑니다.

graph TD
  A["1단계: 계획만<br/>실행 안 함"] --> B["2단계: 읽기만 하는 업무"]
  B --> C["3단계: 파일을 고치는 업무"]

1단계 — 계획만 시켜보기

등록한 작업 폴더 카드에서 새 업무를 만들고, 자율성을 계획만으로 선택하세요.

확인할 것

• 계획이 나오고 파일은 안 바뀝니다
• 프로젝트 구조를 실제로 읽고 답하는지
• 제안이 우리 상황에 맞는지

이 단계의 목적은 결과물이 아니라 "무엇을 하려는지 보는 것"입니다. 계획이 엉뚱하면 지시가 부족했던 것이고, 그건 실행 전에 알아야 합니다.

2단계 — 읽기만 하는 업무

계획이 그럴듯하면 실제 업무로 넘어갑니다. 읽고 정리만 하는 것부터입니다.

확인할 것

• 진행 상황이 실시간으로 보이는지
• 어떤 파일을 읽었는지 표시되는지
• 결과가 실제와 맞는지 (한두 개 직접 확인해보세요)

세 번째가 중요합니다. 결과를 검증해봐야 이 도구를 얼마나 믿을지 감이 잡힙니다.

3단계 — 파일을 고치는 업무

이제 실제로 고치게 합니다. 작고 되돌리기 쉬운 것부터입니다.

좋은 지시의 네 요소를 그대로 적용한 형태입니다.

확인할 것

• 어떤 파일을 바꿨는지 표시되는지
• 바뀐 내용을 화면에서 볼 수 있는지
• 범위를 지켰는지 (README만 바뀌었는지)

작업 전에 커밋해두세요. git을 쓰고 있다면 되돌리기가 쉽습니다. 처음 몇 번은 이렇게 안전망을 두는 게 좋습니다.

업무를 맡길 때 함께 정하는 것

업무 탭입니다. 맡긴 일이 카드로 쌓이고 상태가 함께 보입니다.

여러 개를 동시에

카드가 여러 개면 각각에 다른 업무를 동시에 맡길 수 있습니다.

전부 함께 돌아가고, 대시보드에서 각각의 진행이 보입니다. 이게 관제실이라고 부르는 이유입니다.

결과가 마음에 안 들면

「처음 써보기」에서 배운 것과 같습니다 — 이어서 다시 말하면 됩니다.

자주 하는 실수

처음부터 큰 업무를 맡깁니다

"전체 코드를 리팩터링해줘" 같은 것으로 시작하면, 뭘 했는지 확인할 수도 없고 되돌리기도 어렵습니다. 작게 시작해서 신뢰를 쌓는 순서가 맞습니다.

계획만 단계를 건너뜁니다

바로 실행시키면 "왜 이걸 건드렸지?"를 사후에 알게 됩니다. 처음 몇 번은 계획만으로 보는 게 훨씬 빠릅니다.

결과를 검증 안 합니다

첫 몇 번은 결과를 직접 확인해보세요. 어디까지 맞고 어디서 틀리는지 감이 잡혀야 어디까지 맡길지 정할 수 있습니다.

확인

1. 왜 "계획만" 단계부터 시작합니까?

2. 2단계(읽기만)에서 결과를 직접 확인해봐야 하는 이유는?

3. 여러 카드에 동시에 업무를 맡기면 무엇이 좋습니까?

자율성 수준을 자세히 봅니다 → 어디까지 맡길지 정하기