Claude Code 개발자 보리스 처니: "나는 자주 틀린다"

• 새로운 정보가 들어오면 문제 정의와 접근법, 목표도 바꿔야 함. 방향이 자꾸 바뀌는 것처럼 보여도, 복잡한 문제를 해결하는 데 필요한 반복일 수 있음
• 정보를 파악하고 부족한 내용을 채운 뒤, 문제와 단순한 해결 방법, 목표를 명확히 정하고 빠르게 실행하는 과정을 반복함
• 흔한 실패는 무엇을 풀려는지 불명확하거나 해결 방법이 복잡한 것이며, 이 상태에서는 계획만 커지고 성공 기준은 흐려짐
• 계획을 세운 당사자는 이런 문제를 알아차리기 어려우므로, 피드백을 가능한 한 실시간으로 주고받아 개인과 팀이 더 빨리 배울 수 있도록 해야 함
• 틀렸음을 발견하면 문제를 더 정확히 이해하고 해결책을 고칠 수 있음. 자신이 사용하는 문제 해결 절차도 예외 없이 수정할 수 있어야 함

여섯 단계로 문제를 풀고 새 정보에 맞춰 수정하기

• 거의 모든 문제와 제품에 다음 여섯 단계를 적용하며, 대부분의 날에 이 과정을 여러 번 반복함. 제품 역시 사용자의 문제를 해결하는 것이기 때문임
  1. 현재 확보한 정보를 이해함
  2. 부족한 정보를 수집함
  3. 문제를 정의함
  4. 문제를 해결할 명확하고 단순한 접근법을 정함
  5. 목표를 정함
  6. 목표 달성을 위해 신속하게 행동함
• 도중에 새로운 정보를 얻으면 3~5단계로 돌아가 문제, 접근법, 목표를 다시 정하고 반복함
  • 복잡한 문제는 제대로 풀기까지 여러 차례 시도가 필요할 수 있음
  • 이 과정은 갈팡질팡하는 것처럼 느껴질 수 있지만, 새 데이터에 맞춘 조정이 문제 해결에 필요함을 이해한다면 이러한 변동은 건강한 것임
  • 새 데이터가 생기면 기존 판단을 갱신해야 함

명확성을 높이는 상호 피드백과 틀림의 가치

• 단계를 빠뜨리거나 제대로 수행하지 못할 때 피드백을 주고받으며, 개인과 팀이 더 빨리 배울 수 있도록 가능한 한 실시간으로 전달함
• 가장 흔한 실패는 문제 정의의 불명확함과 명확하고 단순한 접근법의 부재임
  • 둘 중 하나라도 부족하면 계획이 복잡해지고 성공 기준이 불분명해짐
  • 복잡한 문제에서는 계획을 세우는 당사자가 명확성 부족을 알아차리기 어려워 다른 사람의 피드백이 더욱 중요함
• 문제 해결 절차 자체에 잘못된 부분이 있다면 그 절차도 바꿀 수 있어야 함
• 틀렸음을 발견하는 일을 반기는 이유는 문제를 더 명확히 정의하고, 올바른 해결책을 찾고, 더 빨리 배우며, 결국 문제를 해결하는 데 도움이 되기 때문임