08-the-software-engineer-guidebook

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

📝 목차

• 1장. 커리어패스
• 2장. 커리어 관리
• 3장. 성과 평가
• 4장. 승진
• 5장. 어디서나 통하는 접근법
• 15장. 소프트웨어 아키텍처
• 25장. 소프트웨어 아키텍처
• 7장. 업무를 완수하는 개발자
• 11장. 업무를 완수하는 엔지니어
• 16장. 프로젝트 관리
• 19장. 팀 구조
• 20장. 팀 내 역학
• 22장. 협업
• 16장. 프로젝트 관리
• 26장. 배움을 멈추지 말자
• 8장. 코딩
• 9장. 소프트웨어 개발
• 12장. 협업 및 팀워크
• 13장. 소프트웨어 엔지니어링
• 💬 느낀점

---

1장. 커리어패스

가장 열심히 일하거나 최고 품질의 결과물을 만들어야만 항상 가장 높은 보너스를 받고 승진 기회를 얻는 것은 아니란 사실을 깨달았다. 🐧🍋

경력을 인정받으려면 추가적인 노력이 필요하다. 🍋

1.4장. 비용 센터, 수익 센터

수익 센터에서 일하면 자신이 비용 센터보다 우월하다고 느끼기 쉽다. 하지만 효과적인 기업에는 두 가지 유형의 팀과 조직이 모두 필요하므로 각 조직에서 성공하는 방법을 아는 것은 유용한 기술이다. 🌵

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

2장. 커리어 관리

2.1장. 커리어 주인의식

주도적으로 목표를 설정하고, 이를 추적하고, 지속적으로 개선해 더 나아지는 사람의 성과가 더 좋은 법이다. 🍋

성공하고 싶다면 자신의 커리어패스에 대한 주인의식을 가져라. 🐧

2.2장. 일을 잘하는 사람

약속한 작업을 완료하고, 중요한 작업에 집중하고, 작업을 완료하면 다른 사람에게 알리자. 그렇지 않으면 내가 한 일은 눈에 띄지 않게 된다. 🍋

영향력 있는 일을 해냈다면 비즈니스에 미치는 영향을 측정하고 공유하자. 🌵

2.3장. 작업 일지 작성

이런 상황에 대비해 매주 수행한 주요 작업을 기록하자. 🌵

2.5장. 매니저를 아군으로 만드는 법

많은 소프트웨어 엔지니어는 자신이 하는 일을 매니저가 잘 알고 있을 거라고 생각하지만, 그렇지 않다. ... 그러니 매니저에게 말하자! 정기적인 1:1 미팅이 필요한 이유다. 🍋🐧

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

3장. 성과 평가

3.2장. 습관의 힘

자신이 하는 일을 지나치게 많이 공유하는 것도 좋지 않다고 생각하지만, 내가 하는 일을 매니저가 잘 알거라 가정하지 않는 편이 좋다. 가끔씩 작업 일지를 매니저에게 공유하며 자신이 하는 일을 모두 설명하는 것이 좋다. 🐧

성과 평가에 앞서 매니저와 동료에게 피드백을 요청하자. 가능한 한 빨리 요청해 나중에 평가가 나빠서 놀라는 일을 피하자. 🐧

3.4장 성과 평가

피드백을 정말 잘하는 매니저는 거의 없다. 🐧

성과 평가보다는 여러분이 참여한 프로젝트, 강력한 관계를 맺은 사람, 습득한 기술, 해결한 과제 등이 더 큰 영향을 미친다. 🍋

피드백은 하나의 데이터 포인트에 불과하다. 물론 피드백은 매우 중요하다고 느껴지지만 실제로는 커리어와 장기적인 연관성이 거의 없다. 🌵

^{⬆️ 위로 이동}

---

4장. 승진

4.2장. 승진 절차의 유형

예를 들어, 같은 프로젝트에서 일했더라도 CTO와 자주 대화하는 사람이 ‘승진을 결정하는 회의 참가자’와 아무런 교류가 없던 사람보다 우위를 점할 수 있다. 🍋

4.4장. 빅테크에서의 승진

스태프 엔지니어로 승진하려는 엔지니어는 조직 전체의 문제에 대해 기존의 타사 프레임워크를 사용하는 대신 자체적인 사내 솔루션을 개발하는 경우가 많다. 🌵

승진을 하면 보상이 다음 구간의 맨 아래로 이동한다. 🐧

승진 지향 개발. 빅테크에서 승진 및 성과 평가가 영향력 중심적으로 진행되면 '승진 지향 개발'이라는 불행한 결과가 발생할 수 있다. 기업은 당신의 직급이 올라갈수록 더 큰 그룹에 영향을 미치는 업무를 맡기고, 더 영향력 있는 비즈니스 성과를 이끌어내길 기대한다. 🐧

4.5장. 승진을 위한 조언

매니저의 중요성. 매니저와 이야기할 때 승진 이야기를 꺼내자. 매니저가 여러분의 위치를 어떻게 생각하는지, 그리고 매니저의 지원을 받으려면 무엇을 해야 하는지 물어보자. 직접 작성한 자기평가서를 보여주자. 일반적으로 참여할 프로젝트를 결정하는 최종 권한은 매니저에게 있다. 🐧

4.6장. 장기적인 경력

충분한 영향력을 입증하고, 균등하게 주어지지 않은 기회를 잡는 이가 승진을 얻는다. 🍋

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

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

5장. 어디서나 통하는 접근법

5.2장. 플랫폼 팀

플랫폼 팀에서 일할 때의 단점. 제품 팀은 최신 기능으로 매출이 증가하거나 더 많은 사용자를 유치했다고 쉽게 주장할 수 있다. 하지만 플랫폼 팀은 비즈니스에서 중요한 지표를 쉽게 만들기 어렵다. 🐧

5.3장. 평시 vs 전시

제품 팀은 최신 기능으로 매출이 증가하거나 더 많은 사용자를 유치팼다고 쉽게 주장할 수 있다. 하지만 플랫폼 팀은 비즈니스에서 중요한 지표를 쉽게 만들기 어렵다. 🍋

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

15장. 소프트웨어 아키텍처

15.1장. 디자인 문서, RFC 및 아키텍처 문서

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

15.2장. 프로토타이핑 및 PoC

프로토타입을 출시하기 부담스럽다면 일부러 프로덕션에서 쓰지 않는 플랫폼이나 기술을 사용해 프로토타입을 구축하자. 🌵

PoC용으로 빌드한 내용은 버려지므로 코드리뷰, 자동화된 테스트 또는 나중에 유지 관리할 수준의 코드가 필요하지 않다는 점을 명확히 하면 더 빠르게 만들 수 있다. 🍋

15.3장. 도메인 주도 설계

DDD 원칙을 소프트웨어 엔지니어링 프로젝트에 적용했을 때 가장 큰 장점은 소프트웨어 엔지니어가 비즈니스 콘텍스트를 이해하게 된다는 점이다. 🌵

15.4장. 출시를 위한 소프트웨어 아키텍처

비즈니스에 미치는 영향을 파악하면 변경의 우선순위를 정할 근거를 쉽게 만들 수 있을 것이다. 🍋

주요 관계자가 서면 제안서에 동의하도록 하는 가장 좋은 방법은, 제안서를 작성하기 전에 의견을 구하는 것이다. 🍋

소프트웨어에 최종 결정이란 없다! 🍋

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

25장. 소프트웨어 아키텍처

25.1장. 가능한 한 단순하게 하기

아키텍처는 간단하게 시작하고 복잡한 전문 용어를 사용하지 말자. 공식적인 접근 방식을 사용하지 말자는 것이 아니라, 그 방식이 가치를 더한다는 확신이 팀원 사이에서 공감될 때만 그렇게 하라는 것이다. 🌵🍋

25.2장. 전문 용어는 알되, 남용하지 않기

전문용어를 피할 수 있다면 사용하지 않는 것이 좋지만, 스태프 + 앤지니어는 업무와 관련된 기술 어휘, 즉 '전문 용어'를 알아야 한다. 🌵

전문 용어를 너무 많이 사용하면 이해하지 못하는 사람을 배제하게 된다. 🍋

25.6장. 확장 가능한 아키텍처

확장 가능한 접근 방식은 비즈니스가 결제 수단을 계속 추가할 것이라는 점을 인식하는 데서 시작된다. 🐧

아키텍처 결정은 회사의 성장 목표에 맞춰 시스템을 발전시키고 확장하는 데 도움이 되어야 한다. 그러나 비즈니스에 필요하지도 않은 확장 가능한 시스템을 구축하는 데 시간과 노력을 들이는 건 리소스를 제대로 활용하지 못하는 것이다. 🐧

25.7장. 실무 작업과 충분히 가까운 거리 유지하기

코딩에 대부분의 시간을 할애하지는 않겠지만, 이론만 아는 소프트웨어 설계자가 되지 않도록 노력해야 한다. 🐧

아키텍처 결정 과정에 계속 참여하며 다른 엔지니어가 더 나은 아키텍트가 되도록 지원하자. … 스태프+엔지니어로서 우선순위가 높은 다른 업무가 많더라도 시간을 내어 다른 엔지니어가 제안하는 아키텍처 접근 방식과 개선 사항을 검토하고 토론하자. 🍋

25.8장. 소프트웨어 아키텍트의 특성

이렇게 전형은 성찰의 도구로 사용한다. 당신은 이론적인 아키텍트인가. 아니면 실용적인 아키텍트인가? 🐧

서로 다른 특성을 가진 엔지니어가 함께 일하면 훌륭한 결과를 만들어낸다. 🌵

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

7장. 업무를 완수하는 개발자

7.1장. 가장 중요한 업무에 집중하기

가장 중요한 업무가 무엇인지 자문하라. 지금 가장 중요한 업무는 무엇인가? 이번 주에 단 한 가지 일만 할 수 있다면 뭘 할 건가? 이 질문에 답하자. 🐧

모든 일을 거절할 필요는 없지만, 급한 일이 생겨서 최우선 과제를 완료하지 못할 위험이 있다면 거절하자. 다시 말하지만 '네, 도와드리고 싶지만...'으로 시작하는 것이 좋다. 🐧

7.2장. 막힌 부분 풀기

경험상, 30분 이상(길어야 1시간)이 지나도 의미 있는 진전이 없다면 스스로 막힌 상태임을 인정해야 한다. 🐤🌵

머리를 비운다. 산책을 하거나 관련 없는 다른 작업으로 전환하자. 다시 문제로 돌아왔을 때 새로운 관점에서 문제를 바라보거나 이전에 놓쳤던 부분이 보일 것이다. 🐧

7.3장. 작은 단위로 작업 쪼개기

모든 작업이나 다른 방식의 업무 처리는 반드시 생산성을 높이는 방향이어야 한다. 코드 작성이 아닌 업무 처리에 더 많은 시간을 투자하는 건 좋지 않다. 🐧

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

^{⬆️ 위로 이동}

---

11장. 업무를 완수하는 엔지니어

11.1장. 인식과 현실

어떤 작업이었고 왜 어려웠는지 설명해야 하며, 이 작업은 얼마나 중요하고 복잡한지, 그 과정에서 내가 어떤 노력을 했는지 설명해야 한다. 🌵🐤

• 튜브: 조금만 다가서도 멀어지는 나의 사랑 나의 꿈~

11.2장. 나만의 작업 시간 확보

일을 제대로 완수하는 사람으로 인식되는 가장 좋은 방법은, 약속한 만큼의 업무를(그리고 때로는 그 이상을!) 일관되게 제공하는 것입니다. 🐤

기능의 작동 방식, 엣지케이스, 범위를 벗어난 부분을 설명하는 사양서를 작성해 이런 오해를 예방하자. 🐤

11.3장. '제대로' 완수하기

많은 엔지니어가 테스트 계획을 건너뛴다. 구현에 바로 뛰어드는 편이 재미있고 의욕이 생기기 때문이다. 하지만 테스트 방법과 테스트 대상에 대해 생각하기에 가장 좋은 시기는 계획 단계이다. 구현에 휩쓸리면 놓치기 쉽다. 🐧

가장 중요한 업무가 무엇인지 자문하라. 지금 가장 중요한 업무는 무엇인가? 이번 주에 단 한 가지 일만 할 수 있다면 뭘 할 건가? 이 질문에 답하자. 🐧

^{⬆️ 위로 이동}

---

16장. 프로젝트 관리

16.1장. 엔지니어가 프로젝트를 주도하는 회사

최고의 매니저가 어떤 사람인지 아십니까? 매니저가 되고 싶지 않았지만 자신만큼 일을 잘하는 사람이 없어 매니저가 되어야겠다고 결심한 훌륭한 개별 기여자입니다. 🐤

16.3장. 프로젝트 킥오프 및 마일스톤 설정

하지만 이 두가지를 분리하길 권한다. 계획 단계에서 기간과 마일스톤을 같이 설정하면 팀이 지름길을 택해 기술 부채를 발생시킬 가능성이 높기 때문이다. 🐤

마일스톤은 몇 주 이내에 달성할 수 있을 정도로 짧게 설정하는 것을 추천한다. 🐤

프로젝트의 적절한 마무리는 훌륭한 킥오프만큼 중요하다. 🐤

^{⬆️ 위로 이동}

---

19장. 팀 구조

19.1장. 직함과 역할

아무리 작은 프로젝트라도 프로젝트 리드의 역할을 팀원 전체에게 명확히 하면 언제나 좋은 효과를 불러온다. 이렇게 하면 프로젝트를 이끄는 사람에게 책임감을 부여하고 다른 팀원에게도 명확성을 부여한다. 프로젝트가 많은 팀에는 모든 사람이 프로젝트를 이끌 기회가 있다. 🐧

19.2장. 팀의 프로세스

프로세스는 팀이 존재하는 이유가 아니라 일을 완수하기 위해 존재한다. 🐤

19.3장. 팀의 집중력 향상

갑작스럽게 팀 최우선순위 업무가 변한다면 상부에서 내려온 지시라도 저항해야 한다. 초점을 자주 바꾸면 팀 전체의 분위기나 역량에 좋지 않은 영향을 끼친다. 🐧

영향력이 불분명하면 시작하지 말자. 결국, 모호하거나 영향력이 팀의 최우선순위로 업무보다 낮은 작업을 팀이 왜 하려고 하겠는가? 🐧

팀의 업무를 변경하려는 사람이 문제를 일관성 있게 설명하지 못하면, 팀은 정당한 이유 없이 업무에 지장을 받아 어떻게 할지 파악하는 데 며칠을 허비할 가능성이 높다. 자세한 사양이 없다면 작업을 거부하자. 🐧

^{⬆️ 위로 이동}

---

20장. 팀 내 역학

20.1장. 건강한 팀

팀은 '업무를 완수'한다. 즉, 프로젝트, 기능, 제품 및 서비스를 출시해 이해관계자에게 선보인다. 🐧

건강한 팀에서는 팀의 존재 이유와 목표, 목표 달성을 위한 방법이 명확하다. .명확성은 테크리드, 엔지니어링 매니저, 프로덕트 매니저 같은 리더십에서 시작된다. 🐤

20.2장. 건강하지 않은 팀

관리가 제대로 이뤄지지 않는다는 사실은 쉽게 알아차릴 수 있다. 팀원들끼리 서로 불편했던 일을 자주 이야기해 귀에 들어오게 된다. 🐧

방향과 목표가 자주 바뀌거나 불명확한 팀은 혼란스럽고 건강하지 못한 팀일 가능성이 높다. 🐧

팀이 너무 관료주의적으로 운영되면 코드 변경이나 새로운 도구 사용과 같은 간단한 일에도 큰 노력을 기울여야 하는 것처럼 느껴질 수 있다. 이는 팀의 효율과 사기를 떨어뜨리고 더 많은 인력 이탈을 초래할 수 있다. 🐧

20.4장. 팀 역학 관계의 개선

연습 상아, 이 장의 앞부분에 나온 건강한 특성과 건강하지 않은 특성 목록을 만들어 팀에 적용하자. 어떤 점이 보이는가? 팀의 가장 좋은 점 세 가지와 개선이 필요한 영역 세 가지를 기록하자. 🐧

즉 상급자로서 비전문적인 행동을 방관하면, 사실상 그런 행동을 지지하는 셈이다. 🐤🌵

^{⬆️ 위로 이동}

---

22장. 협업

22.1장. 사내 정치

하지만 코드베이스에 손을 대지 않고, 온콜 근무를 하지 않으며, 엔지니어가 동의하지 않는 변경 사항을 밀어붙이는 스태프+ 엔지니어는 의사결정에 냉담하고 손을 놓은 부정적인 이미지로 비칠 수 있다. 🐧

피드백을 받지 못한 엔지니어는 다른 사람이 보기에 정치적인 행동을 한다. 🌵

22.2장. 다른 사람에게 좋은 영향력 끼치기

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

22.5장. 인적 네트워크의 확장

인적 네트워크는 현재 직장을 넘어 커리어에 큰 도움이 된다. 서로 신뢰하는 사람은 향후 다른 회사에 소개나 추천을 해주거나, 공개 채용 공고에 없는 직책의 면접을 보거나 1차 면접을 건너뛸 수 있도록 도와줄 수 있다. 🐧

^{⬆️ 위로 이동}

---

16장. 프로젝트 관리

16.3. 프로젝트 킥오프 및 마일스톤 설정

프로젝트가 실패하는 가장 큰 이유는 잘못된 기대치에서 시작하기 때문이다. 🌵

16.4. 소프트웨어 물리학

나는 빅테크나 고성장 스타트업의 팀에서 품질은 협상의 대상이 아니며, 타임라인과 범위가 훨씬 더 중요하다는 사실을 깨달았다. 프로젝트에 투입되는 인력과 타임라인, 범위는 모두 연결되어 있다. 🌵

16.5. 일상적인 프로젝트 관리

시간이 지나면 이해관계자들과 신뢰가 쌓이게 된다. 그에 따라 결정을 내리기 전에, 통보만 해도 될지 이해관계자와 논의해야 할지 예측할 수 있게 될 것이다. 🌵

26장. 배움을 멈추지 말자

26.2장. 계속 학습하기

어떤 문제로 막혀 있을 때는 팀원에게 요청해 같이 앉아 함께 문제를 해결하자. 이것이 2인 협업이다! 🐤

기술 분야에서의 성공에 가장 중요한 요소는 자신이 할 줄 아는 새로운 것을 끊임없이 쌓아가면서 이를 결합하고 적용할 기회를 찾는 것이라고 생각합니다. 🌵

시간이 지남에 따라 학습에 대한 선호도와 접근 방식이 달라진다는 사실을 받아들이고 새로운 접근 방식을 시도하는 것을 주저하지 말자! 🌵

^{⬆️ 위로 이동}

---

8장. 코딩

8.1장. 코딩 연습하기

그렇기에 모든 리뷰를 긍정적으로 바라보며 그 댓글이 제가 아닌 코드를 향한 것이라고 생각하기로 했습니다. 🐤

따라서 매일 의미 있는 작업과 문제를 해결하는 데 코딩을 활용하자. 🐧

하지만 AI가 생성한 피드백은 항상 정확하지는 않으며, 동료가 리뷰하듯 추가적인 콘텍스트를 고려하지 않을 가능성이 높다는 점에 유의하자. AI 도구는 없는 것보다는 낫지만, 철저한 동료 검토를 능가하지 못한다. 🐧

해당 언어의 전문가가 아니거나 코드베이스에 익숙하지 않더라도 리뷰에 참여하자. 동료가 변경하는 모든 사항을 살펴보고, 그 기능을 이해하고, 접근 방식에 대해 메모하는 습관을 기르자. 🐧

일단 돈을 내면 중도 포기를 하지 않을 동기를 부여한다. 🐤

카타가 어렵지 않을 때까지 몇 주 동안 정기적으로, 이상적으로느 매일 하는 것을 목표로 하자.🌵

8.2장. 가독성 높은 코드

코드를 변경하는 엔지니어는 코드가 어떻게 작동해야 하는지 파악하는 데 많은 시간을 소비한다. 그 뒤, 코드를 더 읽기 쉽게 만들기보다 최소한의 부분만 수정해 더 가독성이 떨어지는 코드를 만들어낼 가능성이 있다. 🐤

^{⬆️ 위로 이동}

---

9장. 소프트웨어 개발

9.2장. 디버깅

디버깅을 잘하는 개발자가 디버깅을 어떻게 하는지 관찰하면 내 디버깅 실력을 향상시킬 수 있다. 🐤

9.4장. 테스트

믿음직한 개발자라면, 테스트 케이스를 개발 시작 전에 수작업으로라도 기록한다. 개발자는 이 목록을 확장하면서 이전에는 고려하지 않았던 새로운 엣지케이스를 찾기도 한다. 🐧

^{⬆️ 위로 이동}

---

12장. 협업 및 팀워크

12.1장. 코드 리뷰

좋은 코드 리뷰는 변경 사항 자체와 변경 사항이 코드베이스에 잘 들어맞는 지를 검토한다. 🐤

좋은 코드 리뷰는 이해하기 어려운 코드, 모호한 이름, 주석 처리된 코드 테스트되지 않은 코드, 간과된 엣지케이스 등 개선해야 할 사항을 지적한다. 🐧

더 나은 코드 리뷰는 공감을 표현한다. 🌵

12.6장. 다른 사람에게 좋은 영향력 전파하기

조직 내에서 자신이 어떤 사람으로 보이는지 되돌아봐야 합니다. 🐧🐤

내가 발견한 가장 효과적인 인맥을 쌓는 방법은 '인맥'을 쌓으려 하지 말고 공통의 문제를 해결하는 것이다. 🌵

^{⬆️ 위로 이동}

---

13장. 소프트웨어 엔지니어링

13.2장. 디버깅

회사에 입사하면 프로덕션 로그가 저장되는 위치와 시스템 상태 대시보드의 위치를 먼저 확인하자. 🐧

시니어 엔지니어는 살펴볼 대시보드와 로깅 시스템이 무엇인지 알아야 한다. 하지만 그런 시스템이 갖춰지지 않았다면, 시니어 엔지니어의 역할은 시스템을 만들고 쉽게 사용하게 하는 것이다. 🌵

13.3장. 기술 부채

읽은 코드를 바탕으로 아키텍처 다이어그램을 작성한 뒤, 팀원에게 확인을 요청하자. 어떤 기능을 코드의 어느 부분에서 구현되고 있는지 알아야 한다. 🐤

코드베이스를 계속 유지 관리하고 수정하기보다 전체 코드베이스를 삭제하고 다시 작성하는 편이 낫겠다고 판단되는 시점이 바로 기술 부채의 파산 순간이다. 🐧🐤

대규모 기술 부채를 제거하거나 마이그레이션 프로젝트를 위한 제안서에는 흔히 신뢰성, 비용 절감, 개발 주기 단축, 버그 감소 같은 사유를 인용한다. 🐤

생산적인 엔지니어는 기술 부채를 제거하기 위해 승인을 구하는 대신 영향력이 큰 프로젝트에서 기술 부채를 제거해 해당 프로젝트에 포함한다. 🐤🌵

내가 일했던 스타트업 중 성공을 거둔 곳들은 모두 초기에 기술 부채가 많은 접근 방식을 취했다. 🌵

^{⬆️ 위로 이동}

---

💬 느낀점

팀원	느낀점
펭귄
샐리
튜브

^{⬆️ 위로 이동}