육각형 개발자 - 시니어 개발자로 성장하기 위한 10가지 핵심 역량 | 최범균

최근에 진행하게 된 스터디에서 읽게된 책인데 편하게 잘 읽히고
기억하고 싶은 내용이 있어 기록으로 남겨보고자 합니다.

 

---

1장 들어가며

1) 개발이란

✔️ 서비스 기업에서의 개발은 사용자에게 기능을 제공하는 일이다.

✔️ 고객의 요구를 파악하고 원하는 것을 충족하는 기능을 만드는 것이 개발이다.

✔️ 개발은 단순히 경력을 쌓거나 관심 있는 기술을 사용하기 위한 과정이 아니었다.

✔ 개발은 회사와 나에게 돈을 벌어주는 기능을 만드는 과정이기도 했다. 내가 만든 결과물은 직간접적으로 회사의 수익과 연결된다.

✔️ 회사 규모가 작을수록 개발 결과물이 회사가 생존하는 데 큰 영향을 준다.

✔️ 코딩과 구현 기술은 개발의 일부이지 개발의 전부는 아니다.

✔️ 개발자가(저자가) 성장한다는 느낌을 받지 못한 이유 중 하나는 개발과 성장을 동일 시 했기 때문이다. (프로젝트 일정관리, 요구 사항 분석, 위험 관리 등)

🍀 언젠가 기회는 온다. 책임감을 가지고 맡은 일에 최선의 결과를 내도록 노력하자 🍀

---

2) 개발에 필요한 것

✔️ 주니어 개발자가 시니어로 성장하기 위해 필요한 것

• 구현기술
• 설계 역량
• 업무 관리와 요구 분석, 공유, 리드&팔로우

✔️ 일정관리 == 공유

• 작업의 진척도를 개인들만이 알고 있다면, 프로젝트 전체의 진척도는 아무도 알지 못한다.
• 공유하고 파악하고, 큰 그림을 그려 차근차근 프로젝트 진척도를 완성해 나가는 노력을 해보자

🍀 다양한 경험을 쌓고 연습하자 🍀

---

2장 구현 기술과 학습

1) 구현 기술

✔️ 개발자는 당연하게도 구현 기술을 능숙하게 다뤄야 한다.
✔️ 기술을 선택하는데는 이유가 있어야한다.
✔️ 기술을 선택하는데 두려움을 갖지말자
✔️ 역할에 따라 선택해야하는 기술이 달라져야한다.

---

2) 학습 대상

✔️ 개발자가 익혀야 할 구현 기술이 너무 많다. 잘 선택하자
✔️ 학습하고자하는 구현 기술을 정할때 기준으로 삼으면 좋은 2가지

1. 현재 사용중인 기술
2. 문제를 해결하기 위한 기술
   • 당장 해결하기 위한 문제일 경우 빠르게 찾아서 기본 사용방법을 익히고 적용해야 한다.
     • 가까운 미래에 해결해야할 경우, 위험신호가 관찰되고 있다면 머지않은 미래에 큰 장애가 발생할 가능성이 높다. → 파악하고 대비하자

✔️ 기술의 유명세에 휘둘리지 말자

---

3) 기술 파기

✔️ 개발자가 익혀야 할 기술이 많기 때문에 하나의 기술을 처음부터 끝까지 깊게 학슴하는 것은 물론 여러 기술을 일정 수준만큼 빠르게 학습해야 하는 것은 쉬운 일이 아니다.

1. 먼저 핸즈온 & 동영상 강의 & 튜토리얼 문서로 빠르게 감을 잡아보자
2. 필요할 때마다 기술을 조금씩 더 깊게 학습하자

✔️ 문제를 해결하기 위해 더 나은 방법을 찾으려고 노력해야한다. → 더 나은 방법이 있는지 항상 찾아보자

(개인적인 생각)
→ 사진을 보았을 때 당연히 동그란 바퀴가 좋아보인다.
→ 하지만, 현재의 기술을 냉철하게 바라볼만 시야를 가지긴 쉽지않다. 나는 쉽지 않았던 것 같다.
→ 이런 상황에서 지금 내가 채택한 방법이 네모인지, 어떤 기술이 동그라미인지 어떻게 파악할 수 있을까?
→ 📌 고민끝에, 그것에 대한 기준점은 "주어진 시간안에 문제가 해결되느냐" 로 판단하기로 했다. 비지니스적인 관점에서 주어진 시간안에 문제를 해결할 수 있고, 목표치를 달성했다면 그자체로 동그라미가 아닐까?? (아닐까요..?)

---

4) 학습 전략

✔️ 기술은 한순간에 사라진다. 과거에 머물지 말고 과감하게 포기하자
✔️ 유행에 상관없는 기술을 익히자

• HTTP 프로토콜
• 네트워크 프로그래밍
• 동시성 처리
• 프로그래밍 언어 등등

✔️ 답이 아닌 질문을 따라하기 - "Copy the question, not the answer"

• 왜 유명한 기업이 특정 기술을 도입했는지 이유를 찾아보고 현재 상황과 비교해보자
  ✔️ 기술 적용 전략에는 유연함이 필요
  
  
  

---

3장 소프트웨어 가치와 비용

1) 소프트웨어의 가치

✔️ 소프트웨어를 출시하려면 큰 노력이 필요하지만 → 출시 후 부터가 시작이다.

✔️ 출시된 서비스가 반응이 없다면, 반응을 얻기위해 기능을 추가하고 수정해야한다. → 즉, 소프트웨어를 유지보수 해야한다.

✔️ 소프트웨어의 유지보수는 이전과 동일한 동작을 유지하는 것이 아니다. 변화하는 세상에서 "유용함"을 유지하는 것이다.

✔️ "세상이 변해도 소프트웨어는 쓸모 있어야 한다."

✔️ 그러기위해서는, 세상의 변화에 맞춰 소프트웨어도 함께 변해야한다.

✔️ 고객에게 유용함을 제공하지 못한다면 결국 망한다(쓰레기다).

 

🍀 소프트웨어의 유용함을 유지하기위해서는 🍀
변경에 대한 유연성을 가지는 것이 가장 적합한 대응이다.
언제나 개발 비용을 줄일 수 있는 방법을 염두해 두고 고민하면서 개발하자!

---

4장 코드 이해

1) 코드 변경

✔️ 개발시간을 줄이고 싶다면 코드를 작성하는 시간 못지않게 코드를 이해하는 시간을 줄여한다.
✔️ 시간을 줄이기 위해 필요한 2가지 역량

1. 코드를 제대로 이해할 수 있는 역량
2. 이해하기 쉬운 코드를 작성하는 역량

---

2) 코드 이해 도구

✔️ 코드 분석에 도움이 되는 다양한 수단을 활용하자 (시각화, 코드 출력, 스크래치 리팩터링)

1. 코드 시각화 (UML) → 링크 대체 : https://thalals.tistory.com/469
2. 코드 출력(종이에) → 직접해보니 레거시 흐름 분석에 도움이 됨
3. 스크래치 리팩터링 → 수정변경해보고 다시 돌려놓기
4. 함께 모여 보기

---

4, 5, 6, 7장 생략

✔️ 좋은 코드를 작성하기 위한 노력, 테스트 코드, 리팩토링 기법 등의 내용을 다룸

---

 

8장 아키텍처, 패턴

1) 아키텍처가 중요한 이유

✔️ 주니어 개발자와 - 중니어, 시니어를 구분 짓는 요소 중 하나! 아키텍처 설계 역량!!

✔️ 소프트웨어 아키텍처는 "소프트웨어 시스템의 추상적인 구조" 이다.

✔️ 아키텍처를 결정할 때는 크게 2가지를 고려해야한다.

1. 기능 요구 사항
   • 소프트웨어로 해결하고자 하는 문제
2. 품질 속성 또는 비기능 요구 사항
   • 품질 속성 : 성능, 확장성
   • 요구사항에 들어남 : 사용자 수, 최대 트래픽 등과 같은 형태
   • 업무 도메인에서도 도출됨 : 법률 조건
   • ✔️ 품질 속성 대부분은, "요구 사항에 없더라도 경험을 토대로 자연스럽게 도출된다"
     • ex) 가용성, 인증고 인가, 유지보수성

 

✔️ 품질속성을 높이면 [시스템의 복잡도] 가 증가한다. → 트레이드 오프

✔️ 모든 품질 속성을 높이면 이상적이 겠지만 "불가능 하다"

✔️ 주요 품질 속성

✔️ 아키텍처 변경은 흥미롭지만 단순히 재미삼아 해서는 안된다. → "품질 속성의 변화가 없다면 아키텍처를 함부로 변경해서는 안된다."

🍀 모든게 완벽한 아키텍처가 아닌 가장 나쁘지않은 아키텍처를 선택해야 한다!!!! 시야를 넓히는 연습을 하자 🍀

---

9장 업무 관리

1) 처음부터 끝까지 (일정관리)

✔️ 하나의 일을 맡으면 [처음부터 끝까지 책임지는 것이 기본이다]
✔️ 업무를 관리할 때 기초가 되는 것

• 업무 나누기
• 위험 관리
• 요구 사항 이해 및 변경 대응
• 일정관리(또는 계획)

---

2) 업무 나누기

✔️ 일의 규모가 커지면 생각나는 대로 하면 안된다. 업무의 크기에 따라 일하는 방식을 배워야 한다.
✔️ 업무 나누기

1. 초반에 해야할 일 정리하기
2. 일의 덩어리가 크다면 더 작게 나누기
3. 개발 계획 세우기
   • 계획이 있어야 진행 상태를 파악하고 변화에 대응하며 조정할 수 있다.
   • 계획을 세울려면 규모를 파악 해야한다. → 작업 목록이 필요하다.
4. 코드가 기대한 대로 동작할 때 비로소 완료된다. (테스트와 수정 기간 포함)

(개인적인 생각)
🍀 일정관리를 잘하는 것은 나에게 너무 어려운 일이었다.
🍀 스터디원 분중은 한 분은 "항상 생각했던 기간의 3배수를 부른다(흥정을 위해)" 고 하셨다
🍀 이상적인 기간 설정은 처음 생각했던 기간의 2배수라고 하셨다.
🍀 이 애기는 즉, 스스로를 믿지말고.. 항상 위험관리를 잘해야한다는 것을 의미하는 것과 동시에, 비지니스에서 시간 약속은 칼과 같아야하기 때문이 아닐까??

---

3) 위험관리

✔️ 본인이 느끼기에 뭔가 잘 진행이 되지않는다면 위험신호이다.

✔️ "반나절을 고민했는데도 모르겠다면 물어보자!!"

---

4) 요구사항은 바뀐다.

✔️ 요구사항 변경은 막을 수 없다. 막지도 말자. 비지니스 성공이 우선이다. 제발!! 기억해!!
✔️ 왜 이런 요구사항을 요구하는지 이해할려고 노력하고 대화하면, 변경을 최소한으로 막을 수 있다.
✔️ 일정과 비용을 처음부터 언급하지 말자

🍀 개발자는 소프트웨어를 만들어 요구사항을 해결해주는 사람이다. 당연히 요구를 최대한 들어주기 위해 노력해야한다.🍀
🍀 착각하지 말자! 🍀
🍀 일정과 비용은 최후의 최후의 최후에 언급하자

✔️ 그렇지만 "개발자는 안된다고 말할 수 있어야한다." → 무리한 요구를 한다면 단호하게 "NO!" 를 외치데, 할 수 없는 이유를 함께 설명하도록 노력하자 (설득)
✔️ 안된다고 말하지말고 대안 제시하기 (동료간의 신뢰도를 높일 수 있는 가장 좋은 방법이라고 생각한다.)

---

5) 수작업 줄이기

✔️ 코드 중복이 세번 이상 발생하면 중복을 제거하라
✔️ 일반 작업도 3번 이상 발생하면 자동화 하자

6) 이유와 목적 생각하기

✔️ 단순히 시키는 일만 하지 말자, 일에는 이유와 목적이 있다.

 

---

기억하고 실천해보자
자주 와서 다시 기억할 수 있는 글이 되었으면 좋겠다.

끝!