TL;DR

  • 복잡한 문제를 해결하고 더 넓은 영향력을 내려면 기술 역량만으로는 부족하며, 문제 정의부터 해결책의 도입까지 사람들과 함께 이끌어야 함.
  • 관련 구성원을 초기에 참여시키되, 모두의 완전한 합의를 기다리지 말고 다수의 동의와 소수의 타협을 이끌어야 함.
  • 다양한 동료와 동맹을 만들고 여러 관점에서 문제를 살펴 해결책의 품질을 높여야 함.
  • 사용자와 이해관계자를 우선시하고, 실제 운영 환경에서 충분히 테스트하며, 빠른 피드백으로 해결책을 개선해야 함.
  • 문제의 중요성을 대상에 맞게 자주 소통하고, 아이디어를 사용자에게 내놓으며, 명확한 의제와 정기적인 회의로 추진력을 유지해야 함.

문제 해결은 해결책을 만드는 데서 끝나지 않음

  • 시니어 역할의 성공에는 기술 역량과 성과뿐 아니라 주어진 과업의 범위를 넘어서는 능력이 필요함. 주니어 역할에서는 주어진 문제의 해결책을 내놓는 것만으로도 좋은 성과를 낼 수 있지만, 더 높은 역할로 나아가려면 문제를 정의하고 해결책을 만드는 일이 여정의 시작임.
  • 이 글은 연차나 직급에 따른 기대치보다 개인의 목표를 넘어 일을 성사시키는 사람과 그렇지 못한 사람의 차이를 다룸. 복잡한 문제를 해결하는 사람들에게서 발견한 특성을 정리하며, 이를 다른 사람에게 전할 수 있도록 명확히 설명함.

1. 사람들을 참여시킴

  • 범위가 넓은 팀은 각 영역의 주제 전문가(SME)에게 의존하는 경향이 있음. 성과를 내지 못하는 계획에서는 전문가가 자신의 범위 안에서만 유효한 문제와 해결책을 정의하는 경우가 있음.
  • 문제가 전문가의 담당 범위에만 국한되지 않는데도 해결책을 만드는 데 시간을 들이면, 실제로 사용되지 않거나 충분히 도입되지 않을 수 있음. 다른 팀 구성원의 필요에 맞추는 데 더 많은 시간을 들이면 더 나은 해결책을 찾을 수 있음.
  • 모두를 만족시키기는 어려우므로, 완전한 합의를 기다리지 않는 접근도 필요함.

2. 완전한 합의를 기다리지 않음

  • 배경과 경험이 다양한 팀에서는 문제의 성격과 해결책을 두고 의견 차이가 생기기 마련임.
  • 문제 해결을 맡은 사람은 다수가 동의하도록 하고 소수가 타협하도록 이끌면서, 각자가 어떤 이해와 이유로 그런 입장을 취했는지 파악해야 함.
  • 팀원 한 명의 반대 때문에 유용한 계획이 시작조차 하지 못하고, 팀 전체가 문제의 결과를 계속 감당하는 사례가 있음. 합의를 더 쉽게 이끌려면 동맹을 많이 만들어야 함.

3. 동맹을 많이 만듦

  • 경험이 쌓일수록 여러 영역에 걸친 문제는 동맹 없이는 거의 해결되지 않는다는 점이 분명해짐.
  • 《The Staff Engineer’s Path》는 위에서 일을 지원하는 ‘스폰서’를 설명하지만, 여기서 특히 중요한 사람은 같은 수준에서 협력하는 동료 동맹임. 이들은 서로 다른 자리에서 계획을 지지하고, 해결책을 개선하는 피드백을 제공함.
  • 모든 동맹과 많은 공통점을 가질 필요는 없으며, 각자와 공통 기반을 찾으면 됨. 다양한 문제를 해결하는 경우에는 서로 다른 배경을 지닌 동맹이 여러 명 있으면 적어도 한 명과 문제를 논의할 수 있음.

4. 충분한 시선이 모이면 큰 문제가 작아짐

  • 《The Cathedral and the Bazaar》에서 얻은 중요한 교훈 중 하나는 문제를 해결하다 보면 고립된 채 막히기 쉽다는 점임. 서로 다른 사람들의 관점과 렌즈를 모으면 큰 힘을 발휘함.
  • 사고 대응(IR) 절차는 문제에 적절한 시선을 모으는 동시에, 같은 팀이나 여러 팀에서 맥락을 아는 사람들의 관점을 최대한 확보하도록 설계됨.
  • 문제를 더 많은 사람에게 보여주려면 사용자와 이해관계자를 중요한 참여자로 대해야 함.

5. 사용자와 이해관계자를 최우선으로 대함

  • 도구나 프레임워크처럼 사람들이 사용할 해결책을 만들 때는 이해관계자를 매우 중요하게 대해야 함.
  • 누군가 버그를 보고하면 빠르게 수정하고 다시 시도해 달라고 요청해야 함. 바로 수정할 수 없다면 적절한 시간 안에 응답하고 진행 상황을 확인할 수 있는 티켓을 제공해야 함.
  • 사람들을 잘 대하면 해결책과 그 일을 추진하는 사람을 지지하는 옹호자가 되며, 새로운 유형의 버그를 찾고 해결책을 알리는 데 도움을 줌.
  • 다만 일부 사용자는 버그를 발견하자마자 도구 사용을 포기하고 버그를 보고하지 않을 수 있음. 따라서 사용자가 하는 것보다 더 많이 테스트해야 함.

6. 사용자보다 더 많이 테스트함

  • 운영 환경에서 문제를 재현하고 테스트하기 전에는 작업이 끝났다고 보지 않아야 함.
  • 마감이 임박했더라도 새 코드를 배포한 뒤 누군가 사용하기를 기다리는 것보다 배포를 미루는 편이 나음. 사용자가 발견하는 버그는 직접 찾아내지 못한 새로운 버그여야 함.
  • 버그가 있든 없든 자주, 명확하게, 일찍 소통해야 함.

7. 자주, 명확하게, 일찍 소통함

  • 관련 이해관계자에게 어떤 문제를 다루고 있는지, 그 문제가 왜 중요하다고 생각하는지 알려야 함.
  • 문제를 설명할 때는 대상의 언어를 사용해야 함. 개별 기여자(IC)는 실행에 더 관심을 두는 경우가 많고, 경영진은 더 넓은 영향에 관심을 둠.
  • 계획이 추진력을 얻지 못하는 이유는 중요성을 전달하는 방식이 대상과 맞지 않기 때문일 수 있음. 일찍 소통하면 모든 아이디어가 좋은 것은 아니지만 아이디어가 없는 것보다는 낫다는 점도 알게 됨.

8. 모든 아이디어가 좋은 것은 아니지만 아이디어가 없는 것보다는 나음

  • 훌륭한 아이디어를 낼 수도 있지만 그렇지 않을 수도 있음. 과거에 훌륭해 보였던 아이디어도 문제를 과대평가하거나 과소평가했거나, 잘못된 시점에 잘못된 문제에 집중한 경우가 있음.
  • 아이디어와 문제를 사람들과 자주 논의하면 관점을 얻을 수 있음.

9. 사용자에게 해결책을 맡기는 일을 두려워하지 않음

  • 해결책을 만들다 보면 예외 상황을 고민하며 실제 운영 환경에서도 같은 일이 일어날지 궁금해질 수 있음.
  • 모든 예외 상황을 따져 보거나 로직으로 빠짐없이 처리하려 하기보다 실제 사용자에게 해결책을 맡기고 어떤 일이 생기는지 확인하는 편이 나음.
  • 한 번에 모든 답을 얻을 수는 없으므로, 강력한 피드백 순환이 더 나은 해결책을 만드는 데 도움을 줌.

10. ‘관리’하는 법을 익힘

  • 중요하게 여기는 계획을 위해 눈에 띄지 않는 연결 작업을 수행해야 함.
  • 정기 회의는 진척에 큰 도움이 됨. 명확한 의제를 두고 사람들을 정기적으로 모으면 해결책을 향해 상당한 일을 해낼 수 있음.
  • 회의를 언제 끝내야 하는지도 알아야 함. 회의는 항상 선택 사항이어야 하며 더는 가치를 제공하지 않는다면 중단해야 함.

문제 해결을 이어감

  • 올바른 문제를 잘 해결하는 방법에 관해 더 많은 이야기가 있지만, 여기서 멈추고 계속 고민할 예정임.