소프트웨어 엔지니어를 위한 위험한 조언

• 실력 있는 시니어 엔지니어에게는 유용하지만 미숙한 엔지니어에게는 해가 될 수 있는 "위험한 조언(dangerous advice)" 개념을 다루는 글로, 프로덕션 SQL 접근 권한 같은 "날카로운 도구(sharp tools)" 에 비유
• 스스로 업무 우선순위를 정하고, 때로는 회사 규칙을 의도적으로 어기며, 불확실해도 강한 입장을 취하는 것 등이 위험한 조언의 구체적 예시
• 대부분의 커리어 조언은 책임 회피나 인상 관리를 위해 작성된 가짜이며, 실질적으로 일을 해내려면 공식 규칙 밖의 행동이 필요
• 매니저는 자신에게 돌아올 리스크 때문에 이런 조언을 직접 해줄 수 없는 구조적 한계 존재
• 위험한 조언은 고위험·고보상 특성을 가지며, 조직의 공식 규칙 너머에 있는 비가시적(illegible) 영역을 이해하는 것이 핵심

"날카로운 도구"와 "위험한 조언"의 비유

• "Sharp tools" 는 ssh, kubectl, 읽기-쓰기 가능한 프로덕션 SQL 콘솔처럼, 역량에 따라 큰 도움이 되거나 큰 피해를 줄 수 있는 도구
• "위험한 조언"도 동일한 특성을 가지며, 역량과 판단력이 있어야 제대로 활용 가능
• 잘못된 사람에게 위험한 조언을 주는 것은 잘못된 사람에게 프로덕션 SQL 접근 권한을 주는 것과 같음

블로그에서 제시하는 위험한 조언의 구체적 예시

• 스스로 무엇을 작업할지 결정할 것
• 때로는 회사의 성문화된 규칙을 의도적으로 어길 것
• 불확실할 때도 강한 입장을 취할 것
• 자신을 약간의 '그리프터(grifter)' 로 정체화할 것
• 출시(shipping)와 관련 없는 모든 활동을 의도적으로 회피할 것

대부분의 커리어 조언이 가짜인 이유

• 실력 있는 엔지니어는 날카로운 도구를 원하는 것과 같은 이유로 위험한 조언을 갈망
• 대부분의 커리어 조언은 책임 회피(liability avoidance) 또는 인상 관리(impress people) 목적으로 작성됨
• 일을 실제로 해내려는 사람이라면, 이런 위험한 행동들이 명백히 도움이 되기 때문에 결국 하게 됨
• 공식적으로는 그렇게 작동하지 않는다는 것을 알면서도 아무도 이야기해주지 않는 상황은 깊은 소외감을 유발
• 주니어 시절, 비공식적으로 솔직하게 이야기해준 소수의 동료가 큰 도움이 되었음

매니저가 위험한 조언을 해줄 수 없는 구조

• 매니저가 회사 정책을 무시하라고 조언했는데 엔지니어가 이를 잘못 실행하면(예: Slack에 매니저가 허락했다고 공개적으로 게시), 매니저에게 더 큰 피해가 돌아감
• 테크 기업 리더십은 엔지니어를 "유용한 바보(useful idiots)" 로 보는 경향이 있으며, 매니저에게는 프로페셔널한 행동을 기대
• 많은 매니저가 이런 조언을 해주고 싶어 하며, 엔지니어가 스스로 이런 방식으로 행동하면 높이 평가
• 업무를 좀 더 전략적으로, 직무 기술서에 덜 얽매여서 접근하면 훨씬 효과적일 강한 엔지니어를 관리하는 것은 매니저 입장에서 매우 답답한 일

위험한 조언의 본질: 고위험·고보상

• 위험한 조언을 따르려면 용기가 필요
• 고위험·고보상 특성 때문에 강한 엔지니어에게는 불균형적으로 유용하고, 약한 엔지니어에게는 해로움
• 편하지 않다면 절대 따르지 말아야 하지만, 이미 이런 방식으로 일하면서 장기적 실수를 걱정하고 있다면 그렇지 않을 가능성이 높음

Hacker News 반응과 조직의 비가시적 요소

• Hacker News에서 매우 긍정적인 반응과 매우 부정적인 반응이 혼재
• 부정적 댓글의 핵심 오류는 조직이 곧 성문화된 규칙의 집합이며, 조직 내 운영의 주요 모드가 공식적·구조적 협업이라고 보는 관점
• 이는 James C. Scott의 Seeing Like a State에서 말하는 가독성(legibility) 과잉 우선시의 실수
• 모든 커뮤니티에는 비가시적이지만 핵심적인(load-bearing illegible) 구성 요소가 존재
• 자신의 업무에서 이 비가시적 부분을 신중하게 생각하는 것이 이 글과 블로그 전체의 핵심 주장