오랜 소프트웨어 엔지니어 경험 후에 Uber에서 엔지니어링 매니저를 했던 Gergely Orosz가 The Pragmatic Engineer Newsletter를 오랫동안 운영했던 소프트웨어 엔지니어 전체 커리어에 대한 조언을 정리한 책이다.

소프트웨어 엔지니어 경력 전체를 한번에 다뤄주기 때문에 생각을 정리하고 커리어 고민이 많을 때 자신이 여기에 있는 커리어 경력 어딘가에는 있을 것이므로 도움이 될 것이라고 본다.

1부 개발자 커리어의 기본 사항

1부에서는 커리어 관리라는 게 어떤 것이고 소프트웨어 일하면서 자연히 겪게 되는 성과 평가, 승진, 이직 등에서 어떤 관점들이 있고 어떻게 관리하는지 설명한다.

영어는 커리어에 중요한 역할을 했다. 소프트웨어 엔지니어 경력에도 마찬가지다.

아주 동의한다. 나는 결국 영어를 제대로 못 했지만... 항상 빨리 영어부터 어떻게 할 걸 이라는 후회를 많이 한다.(지금도 이런 생각만 하고 영어 공부 안 해서 나중에 또 후회하겠지)

나는 매니저가 되고 나서야 개발자가 자신의 커리어패스에 대한 주인의식을 가지는 것이 얼마나 큰 차이를 만들어내는지 깨달았고, 이 덕에 개발자의 성장을 돕는 역할을 충실히 해낼 수 있었다.
자신의 커리어를 주도하라! 소프트웨어 엔지니어에게 이만한 커리어 조언은 없다. 자기 커리어를 자신만큼 중요하게 생각하는 사람은 아무도 없다.

자신의 커리어는 스스로 관리해야 한다. 주도적으로 목표를 설정하고, 이를 추적하고, 지속적으로 개선해 더 나아지는 사람의 성과가 더 좋은 법이다. 노력을 거의 하지 않거나 자신이 아닌 매니저가 대신 목표를 설정하고, 자신을 그 목표까지 밀어주기를 기다리는 사람에게는 주변이 어떤 도움을 줘도 효과가 없다.

커리어를 직접 관리해야 한다는 부분은 완전히 동의하지만 그렇다고 쉽진 않은 거 같다. 자신이 잘하는 것, 자신이 즐거워하는 것, 장점, 단점 등을 파악하면서 빠르게 변하는 업계에도 맞춰가면서 커리어에 대해 고민을 하고 관리해야 한다. 열심히 공부한 지식과 노력한 경험은 어디 사라지진 않겠지만 의도한 대로 되지 않는 것도 사실이다. 하지만 직접 고민하고 자신을 계속 관찰하는 건 맞다고 생각하는 편이다.

건설적인 피드백을 주는 사람이 있다면 일부러 시간을 내 피드백을 했다는 점을 기억하자. 피드백에 방어적으로 대응하려는 마음이 들겠지만 이 점을 명심하자.

나는 매니저라면 가능한 한 빨리 피드백을 공유할 의무가 있다고 생각한다.

피드백은 여전히 받는 거나 주는 거나 쉽지 않다고 생각한다. 부정적인 피드백이면 더욱 그렇다. 업무에서 그동안 피드백을 많이 받지 않은 편이라고 생각해서 그 요구사항을 잘 이해 못하기 때문에 더 어렵다는 생각이 든다. 이 부분은 계속 연습해야 한다.

새로운 일을 시작하거나 새로운 사람들과 함께 일할 때는 주저하지 말고 피드백을 구하자. 새로운 상황에서 피드백을 구하는 건 잘못된 행동이 아니며 오히려 권장하는 일이다. 피드백은 진지하게 받아들이되, 지시가 아닌 의견이라는 점을 기억하자. 사람들이 피드백을 준다고 해서 꼭 그에 따라 행동할 필요는 없다.

앞에서도 말했지만, 피드백을 구하는 건 더 어렵다고 생각한다. 사실 잘한다는 얘기보다는 개선할 부분에 관한 얘기를 듣고 싶다고 생각은 하지만 실제로 들으면 아마 방어기제가 동작할 것이고 사람들은 굳이 부정적인 얘기를 잘 하지 않기 때문에 피드백을 구한다는 것은 생각은 많이 해봤지만, 여전히 어렵다.

매주 또는 격주로 성과를 기록하자. 완료한 프로젝트를 정리해두고, 이메일이나 채팅에서 업무에 대한 칭찬을 스크린숏으로 찍어두는 등 성과를 입증할 수 있는 증거를 남겨두자.

이건 좋은 경험이라고 생각한다. 나한테는 블로그가 비슷한 작업이었지만 성과를 따로 정리하진 않는다. 노트가 있긴 하지만 정리에도 정말 많은 시간이 들어가기 때문에 열심히 적다가 바빠지면 또 한참 못 적고 하는 게 반복이다. 매년 혹은 6개월마다 이력서를 갱신하라는 것도 비슷한 맥락의 조언이지만 귀찮아서 실제 이렇게 해본 적은 없다.

비슷하게 난 성과보다는 뭔가 작업할 때 고민했던 문제들을 적어두려고 하는 편이긴 하다. 고민할 때는 꽤 어려웠던 문제가 해결된 뒤에는 해결책을 알고 있어서 왜 고민했었는지 잘 기억나지 않는 경우도 많아서 그때의 생각을 정리해 놓는 걸 좋아하는데 이것도 하다 말다 하긴 한다.

물론 성과 평가가 중요하긴 하지만 지나치게 집착하지 말고 장기적인 관점을 유지하자.

성과 평가는 중요하긴 하지만 성격 탓인지 나는 아주 크게 신경 쓰는 편은 아닌 거 같다. 그렇다고 장기적인 관점을 유지한 건 아니고...

어떻게 하면 대규모 엔지니어 그룹에 영향을 미치고 중요한 비즈니스 성과를 이끌어낼까? 분명한 답은 조직이 안고 있는 엔지니어링 문제를 해결하는 것이다. 하지만 승진을 위해서는 ‘무엇을’(영향력)을 보이는 정도로는 부족하다. 또한 다음 단계인 ‘어떻게’(역량)에도 보이는 성과를 내야 한다. 다시 말해/ 그러려면/ 그 과정에서/ ... 대규모 그룹을 조율해야 하고 어려운 엔지니어링 과제, 즉 사소하지 않은 일을 해내야 한다.

언제부터 그랬는지 알 수 없지만 나는 회사에서 필요하다고 생각하는 일을 재밌게 할 수 있는 편인 거 같다. 보통 얼라인 맞추기가 제일 어렵고 동기가 떨어지는 편인데 그 부분에서 체력 소진이 덜한 편이고 그 일을 하기 위한 리소스는 최대한 끌어다가 일하는 편인데 규모가 큰 일을 하는 방법은 계속 배워나가는 중이다.

수평적 이동이나 새로운 기술 스택 같은 직업적 선택은 경력에 즉각적인 보상은 주지 않겠지만, 장기적으로는 좋은 투자다.

다양한 경험은 당연히 좋지만, 경력이 오래되고 나이가 들어서인지 점점 보수적으로 되는 거 같고 아무래도 이런 태도를 깨뜨리기도 쉽지 않아서 걱정이기도 하다.

2부 유능한 소프트웨어 개발자

2부는 일 잘하는 소프트웨어 개발자가 되기 위해서 어떻게 일하는 게 좋고 어떤 연습을 해야 하는지를 설명한다.

한 가지 경고를 하자면, 뭔가 새로운 일을 맡겠다고 나서기 전에 ‘내가 처리해야 하는’ 업무를 먼저 완료해야 한다는 점이다. 가장 중요하고 할당된 업무를 먼저 끝낸다는 전제하에 새로운 일을 맡아야 다른 사람이 여러분을 생산적인 사람으로 본다.

동의하는 편이다. 일을 하다 보면 뭔가 새로운 일, 다시 말하면 팀 동료들이 좋아하고 인정할 일을 시도하는 경우가 있는데 이때는 당연히 기존에 하기로 한 일이 잘 처리되어야 한다. 물론 기존에 합의한 일을 잘하는 것도 중요하지만 그 이상이 되려면 여기서 플러스가 있어야 동료들한테도 좋은 인상을 줄 수 있다.

유능한 소프트웨어 엔지니어로 계속 성장하려면 매일 코딩을 해야 한다. 이를 대체할 방법은 없다.

가장 기본적이면서도 쉽지 않은 일이기도 하다. 당연히 여기서 코딩은 비슷한 코딩을 계속 반복하는 게 아니라 계속 새롭거나 어렵거나 다른 접근방법을 고민하면서 하는 게 필요하다고 생각한다. 난 항상 코딩이 꽤 부족했는데 요즘은 더 부족해져서 걱정이 많다.

깊이 있게 공부하는 또 다른 방법은 매일 접하는 ‘지루하지만 필요한 것’을 공부하는 것이다. 소프트웨어 엔지니어인 벤 쿤(Ben Kuhn)은 이를 ‘블럽 스터디(blub study)’라고 부른다.
...
자신이 사용하는 도구와 프레임워크가 실제로 어떻게 작동하는지 알아보는 블럽 스터디가 좋은 예가 될 수 있다. 나의 안전지대를 벗어나 새로운 것을 배우는 데 시간을 투자한다면 지식과 기술의 깊이와 폭이 넓어질 것이다.

블럽 스터디라는 말은 처음 알았지만, 이런 부분의 지식을 쌓는 것은 무조건 도움이 된다고 생각한다. 내 예측은 항상 타율이 높진 않지만, AI 시대에는 더 중요해질 거라고 생각하는 편이다.

3부 다재다능한 시니어 엔지니어

어느 시점에서는 누구나 다 시니어 엔지니어가 된다. 시니어 엔지니어가 가져야 할 접근 방법을 정리한 챕터다.

업무를 완수하는 시니어 엔지니어로 인정받으려면 두 가지 능력이 필요하다.
1. 복잡한 엔지니어링 문제를 실용적인 방식으로 해결하는 능력
2. 동료 및 매니저와 업무 진행 상황, 직면한 장애물, 장애물에 대한 해결책, 복잡성 등 업무에 대한 커뮤니케이션을 하는 능력

항상 주니어 같은 기분이었지만 언젠가부터는 시니어 아니라고 말하기 어려운 시점을 넘어선 지도 꽤 되었다. 그전에 내가 보는 시니어는 1번이 거의 전부였지만 지금은 2번이 훨씬 더 중요하다고 생각한다. 매니저 트랙이 아니더라도 시니어가 됨에 따라 어느 정도 매니징 관련된 부분이 늘어갈 수밖에 없고 이게 혼자만 잘하는 게 아니라 동료도 잘할 수 있게 만들어서 시니어의 의미를 보여준다고 생각한다.

운이 좋게도 직장에 품질 보증(quality assurance, QA) 전담 직원/팀이 있다 해도 QA 팀에 여러분의 업무를 떠넘기지 말자. 나는 일부 엔지니어링 팀이 QA 담당자와 함께 일하면 테스트나 품질 보증을 모두 QA 팀의 책임이라고 생각하는 안티 패턴을 발견했다.

실제로 비슷한 경험을 해본 적이 있다. QA가 테스트를 해줄 테니 기본적인 소프트웨어의 테스트도 제대로 안 되고 인수되는 상황을 봤는데 꼭 QA가 아니더라고 비슷하게 느끼는 경우가 꽤 많이 있다. 물론 팀 간의 업무 영역이 있고 모든 부분을 다 커버할 수는 없기에 결국은 그 영역을 어디까지 보는지를 합의하는 문제라고 생각한다. 아직 이 생각의 차이를 줄이는 방법은 고민 중이다.

가장 생산성이 높은 엔지니어라도 항상 코딩을 빠르게 하거나 컴퓨터 시스템을 잘 이해하는 건 아니다. 오히려 엔지니어링에 능숙한 동시에 제품과 고객, 비즈니스에 대한 이해도가 뛰어난 경우가 더 많다. 생산성이 높은 엔지니어는 현명한 절충점을 찾고 덜 복잡한 엔지니어링 솔루션을 더 빠르게 구축할 뿐 아니라 고객의 실제 문제를 해결할 솔루션을 제공한다.

이것도 꽤 동의하는 부분이다. 어떤 문제는 풀지 않아야 하는 문제로 만들 수도 있고 기술적인 부분 외에 다른 부분으로 풀 수 있는 문제도 상당히 많은 편이다. 항상 고민은 쉬운 해결책을 먼저 고민하고 어려운 해결책을 고민해야 하는데 당연히 그 성과와 같이 고려해야 한다.

소프트웨어 엔지니어는 코드 작성에 대한 보수를 받지 않는다. 우리는 코드 작성으로 비즈니스 문제를 해결해 보수를 받는다.

당연한 얘기다.

다른 사람에게 2인 협업을 요청하는 걸 두려워하지 말자! 이러한 느낌은 경험이 적은 엔지니어에게 더 흔히 나타나지만, 심지어 시니어 엔지니어는 스태프나 수석 엔지니어에게 짝이 되어달라고 요청하면 자신이 그 일을 못한다고 인정하는 모양이 될까 걱정하는 경우도 있다. 그렇지 않다. 2인 협업을 요청해 일을 더 빨리 끝내면서 새로운 지식을 배울 수 있다.

2인 협업은 페어 프로그래밍일 수도 있고 프로젝트를 같이하는 것일 수도 있을 텐데 혼자 작업하면 아무래도 외롭고 어려운 문제를 만났을 때도 혼자 끙끙 앓고 힘든 경우가 많다. 해결은 비슷하더라도 협업자가 있으면 최소한 같이 고민한다는 것만으로도 크게 위안이 될 수 있고 자연스럽게 버스 팩터를 높일 수 있는 효과도 있다.

공식적인 멘토링을 시작하는 가장 좋은 방법은 킥오프다. 나는 잠재적 멘토에게 찾아가 ‘평소에 존경하고 있었습니다. 잠시 시간을 마련해 주실 수 있을까요? 제가 성장하고 싶은 분야와 멘토로서 도와주실 방법을 이야기하고 싶습니다’라고 제안한다.

이런 걸 생각해 본 적은 없어서 흥미로웠다. 고민하는 부분은 항상 있기 마련이고 특히 회사 규모가 어느 정도 된다면 내부에도 존경할 만한 사람이 있을 수 있으므로 이런 자리를 요청해 보는 것도 괜찮아 보였다. 하지만 용기 내서 과연 할 수 있을는지...

효과적인 멘토링은 다른 사람의 문제를 해결하지 않고, 멘티가 스스로 문제를 해결하도록 해 성장을 돕는 것이다.

동의하지만 어떻게 돕는 게 효과적인지는 계속 배워나가고 있다.

피드백을 제공하기 전에 먼저 질문을 하자. 상대방의 작업에 익숙하지 않거나 상대방이 명시적으로 피드백을 요청하지 않았다면 특히 질문이 필수다.

질문을 먼저 하려고 하는 편이긴 한데 또 어떨 때는 설명하고 싶은 욕구가 잘 제어 안 될 때가 있다. 그리고 질문도 내가 설명하려는 걸 너무 억지로 질문으로 바꾸면 상대도 보통 눈치챌 것이기 때문에 이 부분도 걱정이긴 하다. 사실 질문도 너무 질문 살인마처럼 보이진 않을까 걱정되기도 한다. ㅠ

‘개인 브랜드 구축’이라는 개념은 특히 실속 없이 겉치레에 치중하는 식으로 변질되면 부정적인 정치 행위로 비칠 수 있습니다. 조직 내에서 자신이 어떤 사람으로 보이는지 되돌아봐야 합니다. 누군가 사회 초년생인 나에게 스스로의 ‘브랜드’를 되돌아보라고 알려줬다면 얼마나 좋았을까요?

나도 블로그와 외부 활동을 통해서 개인 브랜드를 구축해 온 사람이지만 이런 경우 겉치레는 잘 보이지만 실속은 어떤지 보이기 어렵기 때문에 오해받기 쉽다고 생각한다. 이러한 활동이 난 필요하다고 생각하지만, 겉치레에 너무 치중하면 정말 보기 싫어지기 마련이고 나도 이런 걸 많이 안 좋아하긴 한다. 결국 겉치레로 하는 게 아니라 먼저는 후든 실속이 따라갈 수 있도록 본인이 노력하는 수밖에 없다고 생각하고 과대포장을 조심해야 한다고 생각하지만, 그 외에는 개인 브랜드 구축을 위한 외부 활동은 무조건 좋다고 생각한다.

‘풀스택 엔지니어링’은 기술 업계 전반에서 시니어 엔지니어의 기본적인 기대치가 되고 있다. 제품 담당자와 비즈니스 이해관계자는 임베디드, 백엔드, 프런트엔드/웹의 구분에 크게 신경 쓰지 않기 때문이다. 이들은 이런 구분을 엔지니어 당사자들에게나 중요한 일로 본다.
...
인접 스택에서 어떤 일이 일어나는지 모른다면 더 복잡한 풀스택 문제를 디버깅하고 풀스택 기능을 빌드하고 출시하는 프로젝트에 어려움이 생긴다.

몇 년 전부터 국내에서는 풀스택 엔지니어링이 좀 조롱거리처럼 되어서 쉽게 사용할 수 없게 되었지만, 개인적으로는 나도 풀스택 엔지니어라고 생각하고 접근하고 있고 실제로 이 글처럼 중요하다고 생각하고 있다. 하지만 또한 모두가 풀스택이어야 하냐? 하면 잘 모르겠다. AI가 많은 걸 바꾸고 있어서 더 쉬워지긴 했지만, 모두가 풀스택이 될 필요까진 없고 팀이 풀스택을 커버할 수 있으면 되지 않나 싶긴 하다. 이것도 어느 정도 취향의 문제이기도 하지만 인접 스택의 일은 어느 정도 알고 있어야 도움 되는 건 사실이다.

실용적인 엔지니어는 기술 부채를 안 좋은 것이 아닌 속도와 품질의 절충안으로 여긴다. 그들에게 기술 부채란 시스템의 특성이다. 프로젝트 목표의 맥락에서 기술 부채를 필요 이상으로 갚으려고 하지 않는다.

기술 부채를 떠안고 가는 것은 스타트업에서 일하면서 더 많이 배운 부분이기도 하다. 기술 부채라는게 정확히 어떤 수치처럼 나오는 것은 아니라서 기본적으로는 항상 기술 부채를 줄이려고 노력하는 편이긴 하다. 기술 부채란 게 줄이자고 팍팍 줄어드는 건 아니라서 계속 줄이려고 노력해도 잘 안 줄어드니 항상 그런건 아니지만, 지속적으로 계속 줄이는 게 낫다는 입장이다.

RFC 프로세스의 진정한 목표를 잊지 말자. 피드백을 조기에 받아 프로젝트를 출시하는 데 걸리는 시간을 단축하는 것이다.

RFC 프로세스를 꽤 많은 사람이 좋아하지만, 프로세스 자체를 별로 안 좋아해서인지 나는 아주 선호하는 편은 아니다. 그럼에도 RFC가 의미 있는 부분이 당연히 있지만(가장 크게는 조직 간의 협업이 필요한 부분이라고 생각한다.) 또 그로 인해 속도가 불필요하게 느려지는 부분이 있기에 이 절충을 어떻게 할지가 제일 큰 고민이다.

자신이 절대 지지하지 않는 접근 방식을 채택하고, 될 것 같은 방식을 포기하는 상황에서 분명 분쟁이 발생할 것이다. 그런데 그 결과는 생각만큼 나쁘지 않을 수도 있다. 소프트웨어에 최종 결정이란 없다!

4부 실용주의 테크리드

4부는 시니어와 별개로 테크리드를 따로 다루는 부분이다.

테크리드는 보통 시니어 이상의 숙련된 엔지니어를 말한다. 프로젝트의 리더거나 엔지니어링 팀에서 모든 프로젝트를 총괄하는 사람을 테크리드라 부른다.
...
테크리드는 사람을 관리할 책임은 없지만, 사람들이 더 잘 적응하도록 돕는 관리 책임을 맡는 경우가 많다.

기본적인 내 이해와 비슷하지만, 구체적인 영역에서는 아직 테크리드를 겪어보지 않아서 어렵게 느껴지는 부분이 많이 있다. 물론 난 아직 사람 관리에 대한 부분도 경험이 많지 않고 잘 이해하지 못하고 있어서 더 그런 거 같기도 하다.

이해관계자 관리의 핵심은 모든 사람이 같은 정보를 공유해 프로젝트를 성공으로 이끄는 것이다. 많은 프로젝트가 실패하는 이유는 관계자가 할 일과 방법에 대해 서로 다른 생각을 가지고 있기 때문이다.

테크리드는 자신의 역할부터 시작해 팀 내의 어떤 역할이 명시적이고 어떤 역할이 암시적인지 파악해야 한다. 최소한, 매니저가 테크리드에게 기대하는 바가 무엇인지 명확히 파악하자.

프로세스는 결코 목표가 돼선 안 된다. 팀에 어떤 프로세스를 마련해야 하는지 묻지 말고, 어떻게 해야 팀이 더 빠르고 효율적으로 업무를 처리할 수 있는지 물어보자!

명확성을 확인하는 쉬운 방법은 엔지니어에게 팀의 목표가 무엇인지, 왜 이러한 목표가 존재하는지 물어보는 것이다. 모든 사람이 거의 같은 대답을 한다면 명확하다고 볼 수 있다. 그렇지 않다면 다른 대답을 하는 이유를 물어보자.

이런 얘기는 난 별로 좋아하지 않는 편이다. 팀의 목표라는 게 있기는 하지만 수년 동안 거의 바꿀 일 없는 표어 같은 목표를 계속 주입한 것이 아니라면 모두가 거의 같은 대답을 할 수 있나가 의문이고 일이라는 게 그렇게 한 문장으로 표현할 수 있을 정도로 간단한가 싶기도 하다. 물론 이렇게 하나의 목표를 정하자는 사람도 많은 걸 보면 내 취향상 이런 부분이 크게 와닿지 않는 건가 싶기도 하다.

대화는 다른 팀과의 관계를 강화하는 좋은 방법이다.

5부 롤모델로서의 스태프 및 수석 엔지니어

마지막에 회사내에서 롤모델이 될 수 있는 스태프 엔지니어 이상의 엔지니어를 설명한다. 아직 스태프 엔지니어에 대한 이해도가 높진 않았지만, 여러 타입의 스태프 엔지니어와 일하는 방식에 관한 설명을 재밌게 읽었다.

대부분의 소프트웨어 엔지니어는 북극성, KPI, OKR이란 개념이 지루하고 관련성이 없다고 생각한다. 소프트웨어 엔지니어는 구체적인 내용을 선호하기 때문에 CEO가 OKR을 이야기하거나 프로덕트 매니저가 KPI를 이야기할 때 큰 흥미를 느끼지 않는다. OKR과 KPI보다는 어떤 프로젝트를 왜 해야 하는지에 더 흥미가 많다.

왜 해야 하는지는 정말 중요하다고 보는 편이다. 과거에 이걸 왜 해야 하는지에 대한 수긍할만한 답변을 받지 못하고 누가 시켰다거나 하는 등의 대답을 들어서 더 그런지 모르겠지만 왜 해야 하는지를 이해해야 프로젝트가 제대로 갈 수 있고 동기부여에도 큰 영향을 준다고 생각해서 "왜"를 설명하는 데 시간을 많이 사용해야 한다고 생각한다.

OKR에 너무 집착하지는 말자. OKR은 개발에서 티켓팅 시스템 같은 도구가 효율을 높이듯 팀의 집중력을 높이는 도구다. 다른 도구와 마찬가지로 OKR을 과도하게 사용하면 고객을 위한 올바른 결과물보다 특정 결과의 달성에 집착하게 될 위험이 있다.

어떤 도구나 접근 방법이나 주객전도가 되는 경향이 있다고 생각하기에 이런 일이 생기지 않도록 계속 주의 깊게 봐야 한다.

뛰어난 엔지니어링 팀과 평균적인 엔지니어링 팀의 눈에 띄는 차이점은 뛰어난 팀에서는 엔지니어가 제품 담당자에게 KPI와 심지어 OKR에 대해서도 의문을 제기한다는 점이다. 롤모델이 되는 스태프급 이상의 엔지니어들은 이러한 관행을 당연하게 여긴다.

이런 팀을 만드는 건 정말 중요하다고 생각한다. 여러 가지 요소가 갖춰져야 이런 팀이 될 수 있다고 생각하는데 정말 쉽지 않다. 하지만 특정 몇 명이 문제를 파악하기는 쉽지 않기 때문에 모두가 의문이 생길 때 의문을 제기할 수 있어야 프로젝트나 업무가 잘못되지 않고 잘 될 수 있다. 그렇게 해야 햔다고 말하는 건 스태프급 이상의 엔지니어에게 쉬운 일이지만 모두가 그렇게 할 수 있게 만드는 건 차원이 다른 일이다.

측정 방식이나 측정 대상을 조작할 수 있는가? 측정값은 창의적인 방법으로 조작할 수 있다. 한 예로, 우버가 모든 엔드포인트의 신뢰도를 99.9%로 만드는 걸 목표로 설정한 적이 있다. 그러자 신뢰도가 목표에 못 미치는 몇몇 팀이 코드는 손대지 않고 신뢰도 측정 방식을 변경해 99.9%를 달성했다. 다른 예로, 서버 실패를 의미하는 응답코드 500의 발생 횟수를 줄이는 것을 목표로 지정했는데, 한 팀이 기존의 응답 코드 500을 모두 200으로 변경하고, 오류 메시지를 응답 메시지 본문으로 옮겼다.

의심이 많은 성격이라 그런지 측정하면 항상 이런 어뷰징 걱정부터 하는 편이다. 물론 조직 내에서 설득하기가 항상 쉽지 않은 편인데 뭔가 측정하기 시작하면 무조건 어뷰징도 같이 발생한다고 생각한다.

시니어 엔지니어는 문제를 해결하고 스태프+ 엔지니어는 문제를 발견한다. 시니어 엔지니어와 스태프+ 엔지니어 모두 어려운 문제를 해결해야 하지만, 스태프+ 엔지니어는 해결할 문제도 찾아야 한다. 그러기 위해 고객의 입장에서 생각하는 것이 가장 확실한 방법이다.
...
스태프+ 엔지니어는 비즈니스 측의 파트너가 되어야 한다.

조직 내 사람들에게 영향을 미치는 능력과 그게 가능하게 만드는 강력한 조직 네트워크는 분리할 수 없는 관계다. 당신의 말에 귀를 기울이는 사람은 당신을 신뢰하는 사람이다. 즉 그만한 신뢰를 쌓기 위해 당신이 노력했다는 뜻이다.
...
신뢰 자본을 구축하는 가장 확실한 방법은 오랜 기간에 걸쳐 업무를 수행하며 실적을 쌓고 장기근속을 하는 것이다.

장기근속은 잘 모르겠지만 신뢰 자본 구축은 시니어가 아니라도 누구에게나 너무 중요한 문제이지만 시니어 이상에서 더 많이 발생하곤 한다. 내가 본 많은 문제는 신뢰 쌓기 전에 일을 진행하다가 발생하는 편이다. 대표적으로 회사의 고위직이 외부에서 영입되면 이런 일이 많이 발생한다.

eBay의 전 제품 담당 이사였던 앤 라이몬디(Anne Raimondi)는 자신에 대한 신뢰를 계산하는 공식을 소개했다. 신뢰를 ‘전문성과 책임감, 진실성의 합을 남들이 보기에 내가 이익을 추구하는 수준으로 나눈 값’으로 정의했다.

이런 수식을 생각해 보지 않았지만, 의미있는 공식이다.

스태프+ 엔지니어는 코딩에 얼마나 많은 시간을 할애해야 할까? 정답은 없지만 한 가지 확실한 것은 다른 할 일이 많다는 것이다. 그래서 코딩에 시간을 할애하되 그 양은 줄여야 한다.

대부분의 개발자 포털에 소프트웨어 템플릿 또는 스켈레톤을 정의하는 기능이 있는 이유는 간편한 스캐폴딩이 개발자의 생산성을 크게 높이기 때문이다!

반복 주기가 훨씬 짧아진 오늘날 엔지니어링 팀은 하루에 여러 번 배포하는 경우도 많다. 이제 코드를 모니터링하는 역할은 운영 팀이 아닌 엔지니어링 팀의 몫이며, 변경 사항을 적용하고 온콜 로테이션을 정의하는 역할도 엔지니어링 팀이 맡는다.

훌륭한 엔지니어는 배움을 멈추지 않는다. 이들은 새로운 언어와 기술을 습득할 뿐만 아니라 새롭고 흥미로운 접근 방식의 시도를 두려워하지 않는다.
...
무언가를 깊이 있게 배우는 가장 좋은 방법은 가르치는 것이다.

[Book] 소프트웨어 엔지니어 가이드북

댓글