• 뛰어난 엔지니어는 최고의 프로그래머가 아니라 코드 주변의 사람, 정치, 조율, 모호성을 탐색하는 방법을 터득한 사람들임
• 기술보다는 프로젝트와 팀에서 반복적으로 나타나는 패턴에 초점을 맞춘 내용으로, 사용자 문제 해결, 팀 협업, 코드 품질, 경력 관리 등을 포괄함
• 명확성이 선임 엔지니어의 핵심 자질이며 영리함은 오버헤드일 뿐이라는 점과, 작성하지 않은 코드가 최고의 코드라는 역설적 통찰을 보여줌
• 대규모 조직에서는 정렬 실패가 속도 저하의 주요 원인이며, 측정 지표가 목표가 되면 왜곡된다는 조직 운영의 함정을 드러냄
• 장기적 관점에서 시간이 돈보다 가치 있는 자원이 되며, 네트워크는 각 직장보다 오래 지속되므로 의도적인 경력 설계가 필요함

1. 최고의 엔지니어는 사용자 문제 해결에 집착함

• 기술에 먼저 빠져 적용처를 찾는 것은 유혹적이지만, 가장 큰 가치를 창출하는 엔지니어는 역으로 작업함 – 사용자 문제를 깊이 이해하고 거기서 솔루션을 도출
• 사용자 집착이란 지원 티켓에 시간 투자, 사용자와 대화, 사용자의 어려움 관찰, 근본에 도달할 때까지 “왜”를 질문하는 것을 의미함
• 문제를 진정으로 이해하는 엔지니어는 종종 우아한 솔루션이 예상보다 단순함을 발견함
• 솔루션부터 시작하는 엔지니어는 정당화를 찾기 위해 복잡성을 구축하는 경향이 있음

2. 옳은 것은 쉽지만, 함께 옳음에 도달하는 것이 진짜 업무

• 모든 기술 논쟁에서 이기고도 프로젝트를 잃을 수 있으며, 항상 방에서 가장 똑똑한 사람이 되어 조용한 반감을 축적하는 뛰어난 엔지니어들을 목격함
• 비용은 나중에 “불가사의한 실행 문제”와 “이상한 저항”으로 나타남
• 핵심 기술은 옳은 것이 아니라 문제 정렬을 위해 토론에 참여하고, 타인을 위한 공간을 창출하며, 자신의 확신에 회의적 태도를 유지하는 것
• 강한 의견, 약한 집착 – 확신이 부족해서가 아니라, 불확실성 하의 결정을 정체성에 결합해서는 안 되기 때문

3. 행동 편향을 가지고 출시하라. 나쁜 페이지는 편집 가능하지만 빈 페이지는 불가능

• 완벽 추구는 마비를 초래하며, 한 번도 만들어보지 않은 것의 이상적 아키텍처를 몇 주간 논쟁하는 엔지니어들을 목격함
• 완벽한 솔루션은 사고만으로 나오지 않고 현실과의 접촉에서 등장하며, AI가 여러 방식으로 도움을 줄 수 있음
• 먼저 하고, 제대로 하고, 더 잘하는 순서로 진행 – 못생긴 프로토타입을 사용자 앞에 두고, 지저분한 디자인 문서 초안을 작성하고, 약간 부끄러운 MVP를 출시함
• 한 주의 실제 피드백에서 한 달의 이론적 논쟁보다 더 많이 학습하며, 추진력이 명확성을 만들고 분석 마비는 아무것도 만들지 못함

4. 명확성이 시니어의 징표이며, 영리함은 오버헤드

• 영리한 코드 작성 본능은 엔지니어에게 거의 보편적이며 역량 증명처럼 느껴짐
• 소프트웨어 엔지니어링은 시간과 다른 프로그래머를 추가할 때 발생하며, 그 환경에서 명확성은 스타일 선호가 아닌 운영 리스크 감소를 의미함
• 코드는 장애 중 새벽 2시에 유지보수할 낯선 사람들을 위한 전략 메모이므로, 우아함이 아닌 그들의 이해도를 최적화해야 함
• 가장 존경받는 선임 엔지니어들은 영리함을 명확성과 매번 교환하는 법을 학습함

5. 새로움은 장애, 채용, 인지 오버헤드로 갚는 빚

• 기술 선택을 작은 “혁신 토큰” 예산을 가진 조직처럼 다루고, 실질적으로 비표준적인 것을 채택할 때마다 하나씩 소비함 – 많이 감당할 수 없음
• 요점은 “절대 혁신하지 말라”가 아니라 “고유하게 혁신하도록 보상받는 곳에서만 혁신” 하는 것이며, 나머지는 지루함이 기본값이어야 함
• 지루함은 알려진 실패 모드를 가지고 있기 때문
• “작업에 최고의 도구”는 종종 “많은 작업에 걸쳐 최소-최악의 도구” 를 의미함 – 동물원 운영이 실제 세금이 되기 때문

6. 코드는 당신을 옹호하지 않으며, 사람들이 옹호함

• 초기 경력에서 훌륭한 업무가 스스로 말할 것이라 믿었으나 이는 오류였으며, 코드는 저장소에 조용히 앉아있을 뿐
• 관리자가 회의에서 당신을 언급하거나 하지 않고, 동료가 프로젝트에 당신을 추천하거나 다른 사람을 추천함
• 대규모 조직에서는 초대받지 않은 회의에서, 직접 작성하지 않은 요약으로, 5분과 12개 우선순위를 가진 사람들이 결정을 내림
• 당신이 없는 방에서 아무도 당신의 영향을 표현할 수 없다면 그 영향은 사실상 선택 사항이며, 이는 자기 홍보가 아니라 가치 사슬을 자신을 포함한 모두에게 읽기 가능하게 만드는 것

7. 최고의 코드는 작성할 필요가 없었던 코드

• 엔지니어링 문화에서 창조를 축하하지만, 삭제가 추가보다 시스템을 더 개선하는 경우가 많은데도 코드 삭제로 승진하는 사람은 없음
• 작성하지 않은 모든 코드 라인은 디버깅, 유지보수, 설명할 필요가 없는 라인
• 구축 전 질문을 고갈시켜야 함: “그냥… 하지 않으면 어떻게 될까?” – 때때로 답이 “나쁜 일 없음”이면 그것이 솔루션
• 문제는 엔지니어가 코드를 작성하지 못하거나 AI로 작성하지 못하는 것이 아니라, 너무 잘 작성해서 작성해야 하는지를 묻는 것을 잊는 것

8. 규모에서는 버그조차 사용자를 보유함

• 충분한 사용자가 있으면 모든 관찰 가능한 동작이 의존성이 되며, 약속과 무관함 – 누군가는 API를 스크래핑하고, 특이점을 자동화하며, 버그를 캐싱함
• 이는 경력 수준의 통찰을 창출함: 호환성 작업을 “유지보수”로, 새 기능을 “실제 작업”으로 취급할 수 없으며, 호환성이 곧 제품
• 시간, 도구, 공감으로 지원 중단을 마이그레이션으로 설계해야 함
• 대부분의 “API 설계”는 실제로 “API 은퇴” 를 의미함

9. 대부분의 “느린” 팀은 실제로 정렬되지 않은 팀

• 프로젝트가 지연될 때 본능은 실행을 비난하는 것 – 사람들이 충분히 열심히 일하지 않음, 기술이 잘못됨, 엔지니어가 충분하지 않음 – 하지만 보통 이것이 실제 문제가 아님
• 대기업에서 팀은 동시성의 단위이지만, 팀이 곱해질수록 조정 비용은 기하급수적으로 증가함
• 대부분의 느림은 실제로 정렬 실패를 의미함 – 잘못된 것을 구축하거나, 올바른 것을 호환되지 않는 방식으로 구축함
• 선임 엔지니어는 “코드를 더 빨리 작성”보다 방향, 인터페이스, 우선순위 명확화에 더 많은 시간을 투자함 – 실제 병목이 거기 있기 때문

10. 통제 가능한 것에 집중하고, 불가능한 것은 무시하라

• 대기업에서는 수많은 변수가 통제 밖에 있음 – 조직 변경, 관리 결정, 시장 변화, 제품 전환 – 이것에 몰두하면 행위성 없는 불안을 창출함
• 제정신을 유지하고 효과적인 엔지니어는 영향력 범위에 집중함 – 재조직 발생 여부는 통제할 수 없지만, 업무 품질, 대응 방식, 학습 내용은 통제 가능함
• 불확실성에 직면하면 문제를 조각으로 나누고 자신에게 가능한 구체적 행동을 식별해야 함
• 이는 수동적 수용이 아니라 전략적 집중이며, 바꿀 수 없는 것에 쓰는 에너지는 바꿀 수 있는 것에서 훔쳐오는 에너지

11. 추상화는 복잡성을 제거하지 않으며, 당신이 온콜일 때로 이동시킴

• 모든 추상화는 밑에 무엇이 있는지 이해할 필요가 없을 것이라는 내기이며, 때때로 이 내기에 이김
• 하지만 무언가는 항상 누출되며, 누출될 때 자신이 무엇 위에 서 있는지 알아야 함
• 선임 엔지니어는 스택이 높아질수록 “하위 레벨” 것들을 계속 학습함 – 향수가 아니라, 추상화가 실패하고 새벽 3시에 시스템과 홀로 있는 순간에 대한 존중 때문
• 스택을 사용하되, 기본 실패 모드에 대한 작동 모델을 유지해야 함

12. 글쓰기는 명확성을 강제함. 무언가를 더 잘 학습하는 가장 빠른 방법은 가르치려 시도하는 것

• 글쓰기는 명확성을 강제하며, 개념을 다른 사람에게 설명할 때 – 문서, 발표, 코드 리뷰 코멘트, 심지어 AI와 채팅 – 자신의 이해에서 공백을 발견함
• 무언가를 다른 사람에게 읽기 가능하게 만드는 행위가 자신에게 더 읽기 가능하게 만듦
• 이는 외과의사가 되는 법을 가르쳐서 배운다는 의미는 아니지만, 전제는 소프트웨어 엔지니어링 영역에서 대체로 참
• 이는 지식을 나누는 관대함만이 아니라 이기적인 학습 해크(hack) 이기도 함 – 무언가를 이해한다고 생각하면 간단히 설명을 시도하고, 막히는 곳이 이해가 얕은 곳
• 가르치는 것은 자신의 정신 모델을 디버깅하는 것

13. 다른 업무를 가능하게 하는 업무는 귀중하지만 보이지 않음

• 글루 작업 – 문서화, 온보딩, 팀 간 조정, 프로세스 개선 – 은 필수적이지만, 무의식적으로 하면 기술 궤적을 정체시키고 번아웃을 초래할 수 있음
• 함정은 이를 “도움됨”으로 하는 것이지, 의도적이고, 경계가 있고, 가시적인 영향으로 다루지 않는 것
• 시간 제한을 두고, 순환시키고, 산출물로 전환해야 함: 문서, 템플릿, 자동화 – 그리고 이를 성격 특성이 아닌 영향으로 읽기 가능하게 만들어야 함
• 귀중하지만 보이지 않는 것은 경력에 위험한 조합

14. 모든 논쟁에서 이기면, 아마도 조용한 저항을 축적하고 있는 것

• 자신의 확신을 의심하는 법을 배웠으며, 너무 쉽게 “이길” 때는 보통 무언가 잘못됨
• 사람들이 당신과 싸우는 것을 멈추는 이유는 당신이 설득했기 때문이 아니라 포기했기 때문이며, 회의가 아닌 실행에서 그 불일치를 표현함
• 진정한 정렬은 더 오래 걸림 – 다른 관점을 실제로 이해하고, 피드백을 통합하고, 때로는 공개적으로 마음을 바꿔야 함
• 옳다는 단기적 느낌은 기꺼이 협력하는 동료들과 함께 무언가를 구축하는 장기적 현실보다 훨씬 가치가 적음

15. 측정이 목표가 되면, 측정을 멈춤

• 관리에 노출하는 모든 지표는 결국 게임화되며, 악의가 아니라 인간이 측정되는 것을 최적화하기 때문
• 코드 라인을 추적하면 더 많은 라인을 얻고, 속도를 추적하면 부풀려진 추정치를 얻음
• 선임의 움직임: 모든 지표 요청에 쌍으로 응답함 – 하나는 속도용, 하나는 품질 또는 리스크용 – 그런 다음 임계값 숭배가 아닌 추세 해석을 주장함
• 목표는 통찰이지 감시가 아님

16. 모르는 것을 인정하는 것이 아는 척하는 것보다 더 많은 안전을 창출함

• “모르겠습니다”라고 말하는 선임 엔지니어는 약함을 보이는 것이 아니라 허가를 창출함
• 리더가 불확실성을 인정하면 다른 사람들도 동일하게 할 수 있다는 신호이며, 대안은 모두가 이해하는 척하고 문제가 폭발할 때까지 숨겨지는 문화
• 가장 선임인 사람이 혼란을 인정하지 않는 팀과 그 피해를 목격함 – 질문이 나오지 않고, 가정이 도전받지 않으며, 주니어 엔지니어는 다른 모든 사람이 이해한다고 가정하기 때문에 침묵함
• 호기심을 모델링하면, 실제로 학습하는 팀을 얻음

17. 네트워크는 당신이 가질 모든 직장보다 오래 지속됨

• 초기 경력에서 업무에 집중하고 네트워킹을 소홀히 했으며, 돌이켜보면 이는 실수였음
• 관계에 투자한 동료들 – 회사 안팎 – 은 수십 년간 혜택을 거둠
• 그들은 기회를 먼저 듣고, 더 빠르게 다리를 구축할 수 있었으며, 역할에 추천받고, 수년간 신뢰를 쌓은 사람들과 벤처를 공동 창업함
• 직장은 영원하지 않지만, 네트워크는 각 직장보다 오래 감 – 거래적 허슬이 아닌 호기심과 관대함으로 접근해야 함
• 떠날 때가 오면, 종종 관계가 문을 여는 것

18. 대부분의 성능 향상은 영리함 추가가 아닌 작업 제거에서 나옴

• 시스템이 느려질 때 본능은 추가하는 것 – 캐싱 레이어, 병렬 처리, 더 똑똑한 알고리듬 – 때때로 이것이 맞지만, “계산하지 않아도 되는 것이 무엇인가?”를 묻는 것에서 더 많은 성능 향상을 목격함
• 불필요한 작업 삭제는 거의 항상 필요한 작업을 더 빠르게 하는 것보다 더 영향력이 있으며, 가장 빠른 코드는 실행되지 않는 코드
• 최적화 전에 작업이 존재해야 하는지 의문을 가져야 함

19. 프로세스는 불확실성을 줄이기 위해 존재하며, 서류 흔적 생성을 위해서가 아님

• 최고의 프로세스는 조정을 더 쉽게 하고 실패를 더 저렴하게 만들며, 최악의 프로세스는 관료적 연극 – 도움이 아니라 잘못될 때 비난을 할당하기 위해 존재함
• 프로세스가 어떻게 리스크를 줄이거나 명확성을 높이는지 설명할 수 없다면, 아마도 그냥 오버헤드
• 사람들이 업무를 하는 것보다 업무 문서화에 더 많은 시간을 쓰고 있다면, 무언가 심각하게 잘못됨

20. 결국 시간은 돈보다 가치가 있게 되며, 그에 따라 행동하라

• 초기 경력에서는 시간을 돈으로 교환하며, 이는 괜찮지만, 어느 시점에서 계산이 역전됨 – 시간이 재생 불가능한 자원임을 깨닫기 시작함
• 다음 승진 레벨을 쫓고, 보상의 몇 퍼센트 포인트를 더 최적화하며 번아웃되는 선임 엔지니어들을 목격함
• 일부는 얻었지만, 대부분은 나중에 포기한 것이 가치가 있었는지 의문을 가짐
• 답은 “열심히 일하지 말라”가 아니라 “무엇을 교환하고 있는지 알고, 의도적으로 교환하라”

21. 지름길은 없지만, 복리는 있음

• 전문성은 의도적 연습에서 나옴 – 현재 기술을 약간 넘어서서 밀어붙이고, 성찰하고, 반복함 – 수년간 – 압축 버전은 없음
• 희망적인 부분: 학습은 새로운 선택지를 창출할 때 복리로 작용하며, 새로운 사소한 지식만이 아님
• 글을 쓰되 – 참여가 아니라 명확성을 위해 – 재사용 가능한 원시 요소를 구축하고, 상처 조직을 플레이북으로 수집함
• 경력을 복리 이자로 취급하는 엔지니어가 복권 티켓으로 취급하는 엔지니어보다 훨씬 앞서 나가는 경향

최종 생각

• 21가지 교훈은 많아 보이지만, 실제로는 몇 가지 핵심 아이디어로 귀결됨: 호기심을 유지하고, 겸손함을 유지하고, 업무는 항상 사람에 관한 것임 – 구축하는 사용자와 함께 구축하는 팀원
• 엔지니어링 경력은 많은 실수를 하고도 앞서 나갈 만큼 충분히 길며, 가장 존경하는 엔지니어들은 모든 것을 올바르게 한 사람이 아니라 잘못된 것에서 배우고, 발견한 것을 공유하고, 계속 나타난 사람들

[출처] https://news.hada.io/topic?id=24909