사례로 배우는 언어 전환 프로젝트 관리: 개발자라면 누구나 꿈꾸는

남경호 지음

로드북 2024년 01월 31일 출간 종이책 : 2023년 04월 20일 출간

작품소개

책소개

“다시 개발하는 게 낫겠어!” 개발자라면 현재 서비스 중인 코드(기술 스택)를 확 바꿔버리고 싶은 적이 몇 번은 있을 것이다. 이 책은 개발자가 직접 경험한 서비스의 언어 전환 프로젝트를 어떻게 성공시켰는지 스토리를 섞어 정제된 프로세스처럼 정리한 책이다. 꼭 언어 전환이나 기술 스택을 변경하는 목적의 프로젝트가 아니어도 프로젝트를 어떻게 관리해야 하는지 노하우를 덤으로 얻을 수 있다. 제목에 “프로젝트 관리”가 붙은 이유이기도 하다.

_대상 독자
개발자들은 언제나 크든 작든 필요에 의해 수많은 프로젝트를 진행한다. 팀의 결정으로 때론 개발자가 능동적으로 적극 설득(?)하여 프로젝트를 만들고 완수해야 하는 게 모든 개발자들의 숙명이자 업(일)이다. 이 책은 “서비스 중인 코드를 바꿔보자”라는 미션으로 시작된 프로젝트이기는 하지만, 개발 현장에서 일어나는 모든 프로젝트의 진행 방식과 크게 다르지 않다. 그래서, 이 책의 독자는 적어도 주니어의 티(?)를 벗은 개발자가 보면 많은 도움을 받을 것이다.

목차

프롤로그
인물 및 상황 설정

Chapter 1_ 〔배경〕 언어전환이 필요하다
1. 레거시와 생활하기
_〔사례〕
2. 전환의 이유 찾기
_〔사례〕
_1. 이유 예시
_2. 주의사항
3. 설득하기
_〔사례〕
_1. ‘신뢰자본’을 쌓자
_2. 설득할 대상에 따른 전략을 세우자
_3. 한 번만에 설득을 완수해야 한다고 생각하지 말자

Chapter 2_ 〔준비〕 지피지기면 백전불태
1. 프로젝트 로드맵 작성하기
_〔사례〕
_1. 로드맵 작성 시 이점
_2. 로드맵 도구들
2. 전환 전략 수립하기
_〔사례〕
_1. 작업 순서 결정
_2. 배포전략 수립
_3. 제약조건 설정
_4. 언어전환의 목적 확립
_5. 작업 범위 결정
_6. 작업 항목 목록화
3. 도메인 파악하기
_〔사례〕
_1. 도메인 목록 정의
_2. 행위 정의
_3. 모델 정의
4. API 정리하기
_〔사례〕
_1. REST API
_2. Graphql API
_3. gRPC
5. 기술 선정하기
_〔사례〕
_1. 웹 프레임워크
_2. API 프레임워크
_3. 영속 프레임워크
_4. 그 외에 고려해야 할 항목
_5. 프로토타입 작성하기
6. 패키지 구조 선정하기
_〔사례〕
_1. 패키지 구조를 선정할 때의 장점
_2. 대표 패키지 구조
7. 작업 생성하기
_〔사례〕
_1. 작업 생성 이유
_2. 작업 생성 전략

Chapter 3_ 〔과정〕 묻고 더블로 가!
1. 프로젝트 환경설정
_〔사례〕
_1. 버전 관리 시스템 설정
_2. 브랜치 전략
_3. 브랜치 보호 룰 설정
_4. 프로젝트 설정
_5. 지속적 통합 및 배포 설정
_6. 인프라 설정
2. 코드 기여 규칙 설정
_〔사례〕
_1. Lint를 이용한 코드 스타일 규칙 설정
_2. 팀 내 코딩 스타일 규칙 문서화
_3. 정적 분석 도구의 활용
_4. 버전 관리 시스템 사용 규칙
3. 테스팅 전략
_〔사례〕
_1. 테스트 장점
_2. 테스트 유형
_3. 테스트 조건
_4. 테스트 전략
4. 그 외 실천항목
_〔사례〕
_1. 제약조건 실천하기
_2. 중간 점검
_3. 작업 공유

Chapter 4_ 〔이슈〕 위기를 기회로
1. 운영이슈
_〔사례〕
_1. 기능 개선 및 추가 개발에 대한 협의
_2. 효율적인 운영이슈 처리 방법
_3. 장애 대응
2. 기술이슈
_〔사례〕
_1. 기술이슈에 대한 대응 자세
_2. 기술이슈를 해결하기 위한 전략
3. 작업 생산성
_〔사례〕
_1. 생산성에 영향을 미치는 요인들
_2. 생산성을 높이기 위한 노력
4. 이슈 공유
_〔사례〕
_1. 협업 관리도구 활용
_2. 문서 활용
_3. 정기 회의 활용

Chapter 5_ 〔종료〕 하얗게 불태웠어
1. QA 준비
_〔사례〕
_1. QA란 무엇인가
_2. QA를 위한 준비사항
2. 테스트 케이스
_〔사례〕
_1. 테스트 케이스 설계
3. 배포
_〔사례〕
_1. 배포 전 확인 항목들

Chapter 6_ 〔회고〕 회고합시다
1. 회고를 위한 사전 계획
_〔사례〕
_1. 작업 관리
_2. 회고 주기
_3. 사건 기록
2. 좀 더 유익한 회고를 위하여
_〔사례〕
_1. 5F
_2. KPT
_3. AAR
_4. YWT
_5. 4L
_6. 진행자의 역할
_7. 데이터 활용
_8. 피드백

Chapter 7_ 〔Q&A〕 후일담
1. 언어전환 프로젝트를 시작하게된 계기가 무엇인가요
2. 진행한 언어전환 프로젝트는 성공했다고 생각하나요
3. 언어전환 프로젝트의 목표는 무엇이었나요
4. 다른 개발자들에게 언어전환 프로젝트를 추천할 건가요
5. 언어전환 프로젝트 진행 중 기억나는 에피소드가 있나요
6. 언어전환 프로젝트와 제품 개발 프로젝트의 차이를 느꼈나요
7. QA 과정에서 발생한 버그 이슈 중 기억에 남는 이슈가 있나요
8. 가장 뿌듯했던 순간이 언제인가요
9. 회사나 다른 팀에서 보는 언어전환 프로젝트는 어떤 것인가요
10. 왜 코틀린과 스프링인가요 336
11. 언어전환 전후 프로젝트 진행의 차이점이 있나요
12. 만약에 프로젝트가 실패했다면 어떤 이유 때문일까요
13. 이 내용을 책으로 소개하게된 계기가 무엇인가요

찾아보기

출판사 서평

현재 서비스 중인 코드를 바꾸고 싶은 적이 있나요?
기존의 서버 코드를 대대적으로 고치고 싶을 때
백엔드 서버는 어떻게 만들어지는지 알고 싶을 때
대규모 프로젝트를 성공시키고자 할 때

코드가 유지보수가 어려울 정도로 복잡하게 짜여 있거나
개발자가 적어 채용시장에서 개발인력 보충이 어려운 상황이거나,
자사 제품에 적합한 기능 또는 솔루션을 좀 더 손쉬운 방법으로 제공해 주는 언어가 필요할 때, 현재 서비스 중인 코드의 언어를 바꾸고 싶어합니다.
서비스 중인 코드의 언어를 바꾸고 싶은 개발자를 위해, 가상의 사례를 통해 어떻게 언어 전환을 계획하고 진행하는지 가이드를 제공해주는 책입니다.

론칭한 지 2년 정도 지난 A 스타트업의 서비스.
제품의 서비스 성장을 위해 기능을 대폭 개선하고자 한다.
개발자는 10명 내외이며, 백엔드 개발자는 파트장 포함 4명
PO, PD, 프론트엔드, 안드로이드, QA 엔지니어 등이 있다.

이들은 서버 언어 전환 프로젝트를 성공할 수 있을까?


_주요 내용
_〔배경〕 언어전환이 필요하다
▷ 레거시와 생활하기 ▷ 전환의 이유 찾기 ▷ 설득하기
_〔준비〕 지피지기면 백전불태
▷ 프로젝트 로드맵 작성하기 ▷전환 전략 수립과 도메인 파악
▷ API 정리와 기술 선정 ▷ 패키지 구조 선정과 작업 생성
_〔과정〕 묻고 더블로 가!
▷ 프로젝트 환경설정 ▷ 코드 기여 규칙 설정 및 테스팅 전략
▷ 그외 실천항목
_〔이슈〕 위기를 기회로
▷ 운영 이유, 기술 이슈 ▷ 작업 생산성과 이슈 공유
_〔종료〕 하얗게 불태웠어
▷ QA 준비 ▷ 테스트케이스 및 배포
_〔회고〕 회고합시다

_먼저 읽어보았습니다.
언어 전환? 처음엔 무슨 소리인가 하고 원고를 읽어내려 갔다. 그런데, 너무 재미있다. 언어 전환이기는 하지만, 다른 프로젝트를 하면서 겪게 되는 다양한 이슈들을 만나고 나 또한 이 책에서 너무 많은 아이디어를 얻었다.
_이수연(여행 서비스 관련 백엔드 개발자)

개발자 K가 등장한다. 서비스 기술 스택을 갈아엎자고 주장하고 실제로 실행에 옮겨버려 보기좋게 프로젝트를 성공시키는 인물이다. 개발자들의 마음 속에 K의 심장 하나씩은 갖고 있을 것이다. 실제 실행은 하지 않더라도 이 책으로 간접 경험이라도 해본다면 개발자로서 한단계 성장하는 데 큰 도움이 될 것이다.
_김동희(쇼핑몰 서비스 총괄 PM)

작가정보

저자(글) 남경호

https://veluxer62.github.io/
현) 요식업 플랫폼 스타트업 백엔드 챕터 리드
전) 온라인 클래스 플랫폼 스타트업 백엔드 개발
전) 여행 플랫폼 스타트업 백엔드 개발
전) 보안 솔루션 백엔드 개발

소프트웨어 장인정신을 참 좋아합니다. 소프트웨어 장인 정신 선언문에 선언된 다음의 가치들을 실천하기 위해 노력합니다.

_동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을
_변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
_개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
_고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

코드를 좀 더 잘 작성하기 위한 나의 노력이 같은 팀의 개발자가 미래에 나의 코드를 수정할 때 좀 더 손쉽게 코드를 수정할 수 있도록 해줄 것이고, 내가 만든 제품에 지속적으로 가치를 부여하는 모습이 동료들에게 동기부여를 제공할 수도 있으며, 모두가 효율적으로 일할 수 있도록 하려는 나의 노력이 팀의 생산성을 높여주면서 제품의 가치 전달에 좀 더 집중할 수 있도록 해줄 것입니다.

이 책은 구체적인 코드 이야기는 자세하게 다루고 있진 않지만, 언어 전환 프로젝트를 준비하고 있거나 혹은 제품 개발 프로세스를 어떻게 정하면 좋을지 고민하고 계시는 여러분에게 필자가 경험한 제품 개발을 위한 전반적인 개발 프로세스 및 협업과 관련한 내용을 소개하고 있습니다.

이미 이러한 프로젝트를 하고 있거나 필자의 가치관에 공감하는 분이라면 재미있게 읽을 수 있으리라 생각합니다.
이 책을 통해 언어 전환 프로젝트를 간접적으로나마 경험해보고 필자의 가치관들을 함께 나누었으면 하는 바람입니다.