엔지니어링 전략 수립

2장. 엔지니어링 전략은 유용한가요?

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

엔지니어들이 전략이 없다고 한탄하는 것을 자주 듣지만, 그들의 불만에는 전략이 왜 중요한지 설명하는 경우는 드뭅니다. 대신 예전에는 경제가 더 좋았고, 자식들은 부모를 존경했으며, 엔지니어링 조직에는 엔지니어링 전략이 있었다는 식의 사실에 더 가깝습니다.

이 장에서는 제가 매우 강력하게 믿는 사실, 즉 문서화되어 있지 않더라도 항상 엔지니어링 전략은 존재한다는 사실을 탐구하는 것으로 시작합니다. 그 다음에는 전략, 특히 문서화된 전략이 왜 조직에서 중요하게 생각하는지에 대해 논의할 것입니다.

자세히 살펴보겠습니다:

• 사람들이 전략이 없다고 말할 때에도 항상 전략이 있는 이유

• 전략이 제가 만난 회사를 어떻게 변화시켰는지

• 부적절한 전략이 별다른 보상 없이 조직에 큰 고통을 주는 방법

• 서면 전략이 조직의 학습을 촉진하는 방법

• 전략을 기록하지 않을 때의 비용

• 스스로 '전략'을 수행할 권한이 없을 때에도 전략이 개인의 학습과 개발을 지원하는 방법

이 장이 끝날 때쯤이면 전략은 여러분과 조직의 시간을 투자할 가치가 있는 작업이라는 데 동의하게 되기를 바랍니다.

항상 전략은 있다

제가 일했던 모든 회사에는 회사에 엔지니어링 전략이 없다고 느낀 엔지니어가 한 명 이상 있었습니다. 제가 임원이 되어 엔지니어링 전략을 직접 문서화하고 배포할 수 있게 된 후에도 전략 부재에 대한 불만은 사라지지 않고 제품이나 회사 전략 부재에 대한 불만으로 옮겨갔습니다.

심지어 결제 서비스 제공업체인 Stripe처럼 엔지니어링 전략이 확실히 있는 회사에서도 이런 일이 발생했습니다. 제가 2016년에 입사했을 당시에는 명확한 엔지니어링 전략과 함께 다음과 같은 여러 가지 지침 정책이 있었습니다:

• 거의 모든 비용으로 이전 버전 API 호환성을 유지하세요. (예를 들어, PCI 규정 준수를 유지하기 위해 TLS 1.2에서 TLS 1.3으로 강제 업그레이드하되, /v1/charges 엔드포인트에서 /v1/payment_intents 엔드포인트로 강제 업그레이드하지 마세요.)

• PCI 환경, 데이터 처리 또는 데이터 과학 작업이 아닌 한, 모노레포 내에서 Ruby로 작업하세요.

• 제품 또는 엔지니어링 관리자가 관여하는 경우에도 작업의 사용성에 대한 책임은 전적으로 엔지니어에게 있습니다.

특정 주제에 대한 회사의 엔지니어링 전략이 무엇인지 알기 위해서는 때때로 여기저기 물어봐야 했지만 대체로 명확했습니다. 시간이 지남에 따라 특정 의사 결정에 대해 논쟁의 여지가 많아져 전략이 무엇인지 명확하게 대답하기 어려워졌습니다. 예를 들어, Ruby를 채택할 것인지 Java를 채택할 것인지에 대한 논쟁은 충분히 논쟁적이어서 저는 의견 차이를 중재하기 위해 전략 문서를 배포했습니다. 지금 생각해보면 명백한 이유, 특히 강제 메커니즘이 없다는 점 때문에 그다지 성공적인 노력은 아니었습니다. ...