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

“그날 나는 결심했다.

내가 매니저가 된다면 팀원들에게 성장에 필요한 조언을 주리라.”

현대 IT 산업에서 소프트웨어 엔지니어로 성공적인 커리어를 쌓으려면, 뛰어난 코딩 실력만으로는 부족합니다. 빠르게 변화하는 기술 환경 속에서 직무를 효율적으로 수행하고, 장기적인 커리어 발전을 이루기 위해서는 더 많은 준비가 필요합니다. 이 책은 많은 기업에서 엔지니어링 매니저로 재직한 저자가 현업에서 팀원들에게 조언을 주는 과정에서 깨달은 경력 관리의 비법을 담고 있습니다.

소프트웨어 엔지니어가 실제 직장에서 겪을 다양한 상황에 대한 해결책을 소개하는 가이드북입니다. 단순한 이론을 넘어 실제 현장에서 바로 적용할 수 있는 유용한 정보까지 담았습니다. 주니어 엔지니어부터 시니어 엔지니어, 스태프 엔지니어에 이르기까지 경력 단계에 따라 다음 단계로 나아가는 데 필요한 정보와 커리어 발전을 위한 구체적인 로드맵, 장기적인 커리어 성공을 위한 청사진을 만나보세요.

지은이 : 게르겔리 오로스 Gergely Orosz

소프트웨어 엔지니어이자 작가로, 75만 명 이상의 구독자를 보유한 테크 뉴스레터 ‘프래그매틱 엔지니어(The Pragmatic Engineer)’를 발행하고 있다. 우버에서 엔지니어링 매니저이자 엔지니어로 재직했으며, 마이크로소프트, JP모건, 스카이프, 스카이스캐너에서 엔지니어로 재직했다.

옮긴이 : 이민석

우리나라에 PC가 처음 들어올 때부터 여러 회사와 소프트웨어 및 하드웨어를 개발해왔다. 1995년 서울대학교에서 컴퓨터공학 박사 학위를 받았다. 1990년대 후반에는 선후배들과 리눅스로 스마트폰을 만드는 회사를 세우고 열심히 일했으며, 그 회사를 거쳐간 수많은 개발자가 리눅스 및 오픈 소스 개발자로 훌륭하게 성장할 수 있도록 도운 것을 자랑스럽게 생각하고 있다. 한성대학교와 NHN NEXT에서 교수와 학장으로 개발자들을 양성했다. 지금은 국민대학교 소프트웨어융합대학에서 전공자 및 비전공자를 위한 소프트웨어 교육에 힘쓰고 있다.

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

1장 커리어패스

_1.1 기술 기업의 유형

_1.2 전형적인 소프트웨어 엔지니어링 커리어패스

_1.3 보상에 따른 기업의 티어

_1.4 비용 센터, 수익 센터

_1.5 커리어 발전을 위한 대안적 사고방식

2장 커리어 관리

_2.1 커리어 주인의식

_2.2 일을 잘하는 사람

_2.3 작업 일지 작성

_2.4 동료와의 피드백

_2.5 매니저를 아군으로 만드는 법

_2.6 페이스 조절

3장 성과 평가

_3.1 빠른 준비: 상황 파악 및 목표 설정

_3.2 습관의 힘

_3.3 성과 평가 전에 할 일

_3.4 성과 평가

4장 승진

_4.1 승진은 어떻게 결정되는가?

_4.2 승진 절차의 유형

_4.3 터미널 레벨

_4.4 빅테크에서의 승진

_4.5 승진을 위한 조언

_4.6 장기적인 경력

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

_5.1 제품 팀 및 제품지향적 엔지니어

_5.2 플랫폼 팀

_5.3 평시 vs 전시

_5.4 기업 유형

6장 이직

_6.1 새로운 기회의 탐색

_6.2 승진 vs 이직

_6.3 기술 면접 준비

_6.4 하위 직급으로 이직

_6.5 상위 직급으로 이직

_6.6 새 직장 적응

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

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

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

_7.2 막힌 부분 풀기

_7.3 작은 단위로 작업 쪼개기

_7.4 작업 소요 시간 추정

_7.5 멘토 찾기

_7.6 선의 통장

_7.7 솔선수범하라

8장 코딩

_8.1 코딩 연습하기

_8.2 가독성 높은 코드

_8.3 품질 높은 코드 작성

9장 소프트웨어 개발

_9.1 프로그래밍 언어에 능숙해지기

_9.2 디버깅

_9.3 리팩터링

_9.4 테스트

10장 생산적인 소프트웨어 개발자의 도구

_10.1 로컬 개발 환경

_10.2 자주 사용하는 도구들

_10.3 빠른 개발 사이클 유지 방법

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

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

_11.1 인식과 현실

_11.2 나만의 작업 시간 확보

_11.3 ‘제대로’ 완수하기

_11.4 팀

_11.5 큰 그림의 이해

12장 협업 및 팀워크

_12.1 코드 리뷰

_12.2 2인 협업

_12.3 멘토링

_12.4 피드백

_12.5 다른 엔지니어링 팀과의 협업

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

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

_13.1 언어, 플랫폼 및 도메인

_13.2 디버깅

_13.3 기술 부채

_13.4 문서

_13.5 소프트웨어 엔지니어링 방법론

14장 테스트

_14.1 단위 테스트

_14.2 통합 테스트

_14.3 UI 테스트

_14.4 자동화된 테스트를 위한 멘탈 모델

_14.5 특정 용도의 테스트

_14.6 프로덕션 환경에서의 테스트

_14.7 테스트 자동화의 장단점

15장 소프트웨어 아키텍처

_15.1 디자인 문서, RFC 및 아키텍처 문서

_15.2 프로토타이핑 및 PoC

_15.3 도메인 주도 설계

_15.4 출시를 위한 소프트웨어 아키텍처

[4부 실용주의 테크리드]

16장 프로젝트 관리

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

_16.2 프로젝트 관리는 왜 하는가?

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

_16.4 소프트웨어 물리학

_16.5 일상적인 프로젝트 관리

_16.6 위험 및 종속성

_16.7 프로젝트 마무리

17장 프로덕션 출시

_17.1 프로덕션 출시까지의 극단적인 상황

_17.2 전형적인 출시 프로세스

_17.3 원칙과 도구

_17.4 추가 검증 단계

_17.5 실용적인 위험 감수하기

_17.6 추가 고려 사항

_17.7 접근 방식의 선택

18장 이해관계자 관리

_18.1 이해관계자 관리의 진정한 목표

_18.2 이해관계자 유형

_18.3 이해관계자 파악하기

_18.4 지속적인 관리

_18.5 비협조적인 이해관계자

_18.6 이해관계자에게서 배우기

19장 팀 구조

_19.1 직함과 역할

_19.2 팀의 프로세스

_19.3 팀의 집중력 향상

20장 팀 내 역학

_20.1 건강한 팀

_20.2 건강하지 않은 팀

_20.3 성장통을 겪는 팀

_20.4 팀 역학 관계의 개선

_20.5 다른 팀과의 관계

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

21장 비즈니스의 이해

_21.1 북극성, KPI, OKR

_21.2 팀과 제품

_21.3 직장

_21.4 상장 기업

_21.5 스타트업

_21.6 산업 분야

22장 협업

_22.1 사내 정치

_22.2 다른 사람에게 좋은 영향력 끼치기

_22.3 매니저와의 협업

_22.4 스태프+ 동료와 협업하기

_22.5 인적 네트워크의 확장

_22.6 다른 사람 돕기

23장 소프트웨어 엔지니어링

_23.1 스태프+ 엔지니어의 코딩

_23.2 유용한 엔지니어링 프로세스

_23.3 빠른 반복을 위한 엔지니어링 사례

_23.4 엔지니어의 효율을 높이는 도구

_23.5 규정 준수 및 개인정보 보호

_23.6 안전한 개발

24장 신뢰성 높은 소프트웨어 시스템

_24.1 신뢰성에 대한 책임 의식

_24.2 로깅

_24.3 모니터링

_24.4 알림

_24.5 온콜

_24.6 사고 관리

_24.7 복원력 있는 시스템 구축

25장 소프트웨어 아키텍처

_25.1 가능한 한 단순하게 하기

_25.2 전문 용어는 알되, 남용하지 않기

_25.3 아키텍처 부채

_25.4 단방향 결정 vs 양방향 결정

_25.5 의사 결정의 ‘영향 반경’

_25.6 확장 가능한 아키텍처

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

_25.8 소프트웨어 아키텍트의 특성

[6부 결론]

26장 배움을 멈추지 말자

_26.1 호기심 유지

_26.2 계속 학습하기

_26.3 계속 도전하기

_26.4 업계 동향 파악

_26.5 휴식 시간

[부록]

좋은 개발자를 바라보는 다양한 시선

개발자의 역할: 기술과 사람의 만남

세상은 언젠가 우리에게 리더가 되라 한다

변화에 적응하고 실행하는 개발자의 마인드셋

AI 시대, 개발자의 성장과 미래