06-hexagonal-developer

육각형 개발자

📝 목차

• 1장. 들어가며
• 2장. 구현 기술과 학습
• 3장. 소프트웨어 가치와 비용
• 4장. 코드 이해
• 5장. 응집도와 결합도
• 6장. 리팩터링
• 7장. 테스트
• 8장. 아키텍처 · 패턴
• 9장. 업무 관리
• 10장. 정리하고 공유하기
• 11장. 리더와 팔로워
• 💬 느낀점

---

1장. 들어가며

p18. 또 다른 문제도 있었다. 뜬금없이 중간 관리자 역할을 맞게 되었다. 이때의 관리자는 개발에 참여하지 않았다. 🐧🌵

• 튜브: 이런 상황을 잘 헤쳐 나갈 수 있는 방법을 이 책에서 배울 수 있지 않을까?
• 샐리: 중간 관리자가 코드를 짜진 않아도 구조는 알아야한다고 생각한다.
• 펭귄: 확실히 관리자 직책을 맡으신 분들은 많이 바쁘신 것 같다.

p22. 회사 업무를 하면서 성장한다는 느낌을 받지 못한 이유 중 하나는 개발(다양한 구현 기술 사용)과 성장을 동일시했기 때문이다. 🐧🐤

• 펭귄: 확실히 특정 기술 스택을 아는 게 성장이 아니고 코드를 볼 때 나무가 아니라 숲을 보게 되는 안목을 기르는 것을 성장이라 본다.
• 샐리: 회사 내에서의 성장을 하려면 어떻게 해야할지, 이젠 고민해봐야할 때!

p23. 상황이 이렇다 보니 유지보수 업무나 기존 코드를 확장하는 일을 주로 하다 보면 새로운 기술을 접할 기회가 줄어들고 개발자로서 성장하지 못한다는 생각을 가질 수 있다. 하지만 언젠가 기회는 온다. 오래된 서비스라도 일부 또는 전체를 새로 만들어야 하는 상황이 발생한다. 이때를 노리면 된다. 🐧

• 펭귄: 기회는 온다!

p28. 경력과 무관하게 많은 개발자가 업무 관리를 중요하지 않게 여기는 경향이 컸다. 🌵

• 펭귄: 업무 관리는 업무를 하는 개발자 뿐만 아니라 일정 조율 및 리소스를 파악하는 조직장의 능력도 중요한 것 같다.

p28. 지금 생각해보면 가장 큰 문제는 개발 리더 부재였다. ... 신입 개발자 2명이 기능 요구 사항을 분석한다는 것은 버거운 일이다. 🐧

^{⬆️ 위로 이동}

---

2장. 구현 기술과 학습

p34. 당장 해결해야 할 문제든 가까운 미래에 발생할 문제든 눈앞에 닥쳤을 때 알맞은 구현 기술을 찾는 건 쉽지 않다. 그래서 문제 해결 능력을 향상하기 위해 평소에 구현 기술을 탐색하고 학습해야 한다. 🌵🐧

p37. 일단 처음 접하는 기술을 익힐 때는 핸즈온이나 동영상 강의 또는 튜토리얼 문서로 빠르게 감을 잡아야 한다. 🐧

• 펭귄: 초기에는 확실히 “핸즈온 > 동영상 > 튜토리얼 문서" 순으로 좋고, 나중에 어느 정도 궤도에 오르면 문서나 책을 보는 게 좋은 것 같다.
• 샐리: 책보다는 영상매체로 먼저 입문하는게 좋을 것 같다!

p37. 예전에는 내가 사용하는 기술의 내부 동작 원리에 대해서도 미리 알아야 한다고 생각했지만 지금은 그렇지 않다. ... 어떤 기술을 깊게 이해해야 하는 순간이 있고 이때 시간을 더 들여 깊은 지식을 학습하고 연습하면 된다. 🌵🐤

• 샐리: 학교 다닐 때 첫 장부터 마지막 장까지 세세히 훑어보던 내가 생각이 난다. 미련한 방법이었던거 같기도..
• 튜브: 내부 원리를 알아야 제대로 공부했다는 느낌이 들기는 하지만, 처음부터 너무 오래 걸리고 어려워지는 단점이 너무 큰 것 같다. 일단 쓰다 보면 자연스럽게 원리를 생각하게 된다.
• 펭귄: 처음에 급하게 땜빵을 하더라도 기록해두면 나중에 또 쓰여서 더 깊게 배우게 되는 것 같다.

p42. 미리 탐색하고 핸즈온을 해보면서 왜 주목받는지 이해하려 노력하면 언젠가 내가 그 기술을 적용하려 할 때 수월해질 것이다. 또한 이러한 노력으로 개발자로서 미래 경쟁력을 유지할 수 있다. 🌵🐧

p44. 코드를 살펴보니 문서를 조회하려는 사용자 아이디를 받아 필드에 저장하고, 다른 메서드가 그 필드에 담긴 값을 사용자 아이디로 사용하고 있었다. 여러 스레드가 같은 필드를 사용하다 보니 사용자 요청을 처리하는 스레드에서 설정한 사용자 아이디가 다른 스레드에 의해 변경된 것이다. 🐧

p45. 주니어 개발자라면 유행과 상관없는 지식을 1년에 1개 이상 학습하자. HTTP 프로토콜, 네트워크 프로그래밍 기초, 동시성 처리, 프로그래밍 언어 등 유행에 상관 없이 개발의 기초가 되는 중요한 내용이 많다. 이러한 기초 지식을 꾸준히 학습해야 기본기가 튼튼한 개발자로 성장할 수 있다. 🌵🐧

p47. 어떤 기술을 도입할 때는 보수적으로 고민하고 다음과 같은 내용을 신경 써야 한다.

• 신뢰 구축
• 함께 할 동료
• 타당성
• 점진적 적용
• 시장 상황 🌵🐤🐧

• 샐리: 동료에게 신뢰를 받아둬야 어떤 기술이나 아키텍처를 도입할 때 용이할 것이다.

p49. 하지만 왜 도입하려고 하는지 이유를 물어보면 단지 웹플럭스가 성능이 좋다고 들어서라는 답을 들을 때가 많았다. 🐤

• 샐리: 스스로도 이걸 왜 하는지 인지하고 있어야, 남을 설득하기 편할 것이다.

^{⬆️ 위로 이동}

---

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

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

• 샐리: SI 회사에서도 기존 동작을 유지할 뿐만아니라, 차세대 작업과 같이 이후에도 유용하게 이 프로그램을 유지할 수 있도록 노력하는 작업을 포함하는 것 같다!

p60. 세상의 변화에 맞춰 소프트웨어도 함께 변해야 가치를 유지할 수 있는데 변경 비용이 많이 들면 소프트웨어를 변경하기 어렵다. 소프트웨어를 바꾸지 못하니 소프트웨어 가치를 유지하기도 어려워진다. 🐧

p60. 개발자는 흔히 "기존 코드를 바꾸는 것보다 다시 만드는 게 더 빨라요"란 말을 한다. 🐤

• 샐리: 반은 맞고 반은 틀린 것 같다. 코드를 새로 짜는게 더 빠를 순 있지만, 그 코드를 검증하고, 그 코드로 보직장을 설득하는 것은 오래걸리기도 하고 쉽지도 않다!

p62. 또한 유지보수를 하면서 얻는 역량과 신규 프로젝트를 할 때 얻는 역량이 다르다고 본다. 신규 프로젝트를 진행할 때는 새로운 기술을 사용할 기회가 생긴다면 유지보수를 할 때는 소프트웨어 운영 과정에 필요한 역량을 쌓을 기회가 생긴다. 🐧

• 펭귄: 확실히 유지보수를 하면서 “좋은 코드란 무엇인가?”라는 나만의 기준이 생기고 객체지향 프로그래밍과 같은 패러다임이나 계층 분리, DDD 등을 공부하게 되는 것 같다.

p65. 유명한 패러다임과 패턴, 프로세스, 아키텍처 등은 빠른 변화에 어떻게 대응할지에 초점이 맞춰져 있다. 세상의 변화에 소프트웨어가 어떻게 변경되는지에 따라 소프트웨어 가치가 달라진다는 점을 생각하면 당연하다. 🌵

• 튜브: 유명한 방법론들이 그렇다는 것은 그만큼 소프트웨어 가치가 중요하다는 것을 보여주는 것 같다.

p66. 소프트웨어 전달 성과가 올라가면 버그 수정, 패치같이 예정에 없던 작업이나 재작업 비율이 줄고 새 작업에 더 많은 시간을 투입할 수 있기 때문에 소프트웨어 가치를 높이는 데 집중할 수 있게 된다. 🌵

• 튜브: 차이가 점점 누적된다!

p68. 잘 돌아가면 건들지 마! 🐤

• 샐리: 보수적인 회사에서 자주 듣는 말!
• 튜브: 계속 잘 돌아가는 걸 보장하면서 고칠 수 있는 방법은 없을까?

p68. 잘 돌아가는 코드라 해도 세상에 맞춰 변화할 수 있도록 더 나은 코드, 더 나은 구조로 변경할 수 있는 용기가 우리에게 필요하다. 🐧

^{⬆️ 위로 이동}

---

4장. 코드 이해

p77. 그러니 다이어그램을 그릴 때는 어떤 정보를 제공하기 위해 다이어그램을 그리는지 분명히 하고 목적에 맞는 요소만 포함하도록 하자. 🐧

• 펭귄: 주요 로직만 추상화해서 다이어그램만 그려놓아도 오류 분석이나 로직 추가할 때도 큰 도움이 되는 것 같다.

p81. 스크래치 리팩터링은 코드 개선이 아닌 코드 이해가 목적이므로 리팩터링한 결과는 반영하지 않고 다시 원래대로 되돌린다. 🌵🐧

• 펭귄: 용어가 있는 줄은 몰랐지만 리팩토링 시도하다가 롤백한 케이스가 종종 있었는데 그때마다 시스템에 대한 이해가 높아졌던 것 같다.
• 튜브: 저렇게까지 할 필요가 있을까 생각할 정도로 신기하다.

p86. 이름은 짧을수록 좋지만 사용 범위가 넓다면 서술적인 이름을 사용해야 한다. 🐤

• 샐리: 이름이 길어도 되니까 용도를 쉽게 알아볼 수 있는 이름이 더 좋다.
• 펭귄: 개인적으로 가독성이 좋은 이름이 최고라 생각하고, 혼자 결정하기 힘들다면 툴(ex. Copilot, ChatGPT)의 도움을 받는 게 정신적으로 좋다.

p88. if 구조가 복잡할 때 if 조건을 역으로 바꾸면 else가 없다는 사실을 빨리 알 수 있고, 그만큼 조건을 기억할 범위도 좁아진다. 또한 코드 들여쓰기(깊이)가 줄어들기 때문에 코드 복잡도가 낮아진다. 따라서 코드 분석을 쉽게 할 수 있다. 🐤

• 샐리: 많은 조건문으로 인한 들여쓰기가 가독성을 해칠때가 많다. 조건문을 줄이는 테크닉이 그 어떤 복잡한 구조론보다 유용했다.

p89. 일반적으로 변수가 사용되는 범위가 넓거나 변수 개수가 많을 때, 또 변수 변경이 빈번하거나 변수 용도가 중간에 바뀔 때 코드 분석 과정에서 기억해야 할 내용이 많아져 인지 부하 증가로 이어진다. 🌵

• 샐리: 규칙적인 위치에서 변수를 수정하거나, 아예 수정하는 함수를 파는 것도 괜찮은 것 같다. 한 변수에 들어갈 수 있는 값을 enum이나 const로 정해두는 것도 좋은 방법인 것 같다.
• 펭귄: 그래서 변수 선언은 보통 해당 변수가 쓰이는 로직 가까이에 선언하거나 중간 로직이 길면 별도 함수로 빼서 읽다가 흐름이 끊기지 않게 하는 것 같다.

p90. 어떤 의미를 부여하거나 새로운 타입으로 변환할 때 변수를 사용하면 코드를 분석하는 데 도움이 된다. 🌵

p98. 타입을 추가했을 때 올라가는 코드 복잡도보다 하나의 타입을 여러 매서드의 파라미터 타입으로 사용하면서 늘어나는 코드 분석 시간이 더 큰 문제다. 🌵

p102. 길지 않은 코드는 결국 추상화 수준을 맞추는 것과 연결된다. 🐤

^{⬆️ 위로 이동}

---

5장. 응집도와 결합도

p112. 응집도는 결국 수정 비용과 관련이 있다. 응집도가 높으면 관련 코드가 한곳에 모여 있게 되고 관련되지 않은 코드는 포함하지 않는다. 역할에 따라 클래스가 자연스럽게 클래스 길이가 줄고, 메서드 단위로 작성되기 때문에 가독성이 좋아진다. 따라서 코드 분석 시간을 줄여준다. 🐧

• 펭귄: 최근에 응집도를 높이는 방향으로 코드를 짰던 적이 있는데, 확실히 클래스 길이가 줄었는데 그만큼 파일 개수가 늘어서 장단점이 있는 것 같다.
• 샐리: 최근에 20000줄 되는 코드를 수정하려고 한 적이 있었는데, 생각보다 단일 책임 원칙을 지키기가 어려웠다.

p114. 변경할 이유가 적을수록 응집도가 올라간다. 🍋

• 샐리: 응집도라는 말이 조금은 안어울리는 것 같다. 오히려 ‘분리된 정도’ 쯤으로 볼 수 있지 않을까?
• 튜브: 어쩌면 번역의 문제일 수도 있을 것 같다. 역할이 응집된 정도로 이해할 수 있지 않을까?

p124. 결합도를 낮추기 위해 추상화 타입을 중간에 위치시키거나 이벤트를 사용하면 두 코드를 직접 연결하지 않고 간접적으로 연결하게 된다. 두 코드가 간접적으로 연결되어 있기 때문에 직접 연결된 코드에 비해 코드를 분석하는 데 더 많은 노력이 들어간다. 🐧🌵

• 샐리: 회사에서 이벤트 대신 인터럽트를 쓰는 경우가 많다. 인터럽트 방식은 코드로 읽을 때 동작 방식이 직관적이지는 않아서 힘들다고 생각했었는데, 인터럽트가 이벤트와 비슷한 역할이라고 생각하면, 해당 구조가 결합도를 낮추는 데 도움이 되기 때문에 적용시켰구나 하고 이해가 갔다.

p125. 따라서 추상화나 이벤트를 적용할 때는 결합도 감소, 응집도 증가, 변경 비용 감소, 테스트 가능성 등 얻을 수 있는 이점을 따져봐야 한다. 이점이 별로 없다면 추상화 타입을 사용하지 않고 구현만 분리해서 응집도를 높이는 것도 좋은 선택이 될 수 있다.🌵

• 샐리: 추상화를 수행하지 않았을 때 보는 손해가 없다면 그냥 놔두는게 좋을지도! 코드짤 때 고려할 요소는 적을수록 좋은 것 같다.

p125, 127. 어떤 형태의 결합이 존재하는지 알면 결합도를 높이지 않는 방향으로 코드를 작성하는 데 도움이 된다. 공통결합은 여러 모듈이 동일한 글로벌 데이터에 접근할 때 발생한다. 시간적 결합은 단지 함께 실행해야 하므로 두 기능을 한 모듈에 묶을 때 발생한다. 만약 모듈/시스템 데이터를 변경할 때 다른 모듈/시스템 데이터도 함께 변경해야 한다면 논리 결합이 발생한다. 🍋

• 샐리: 결합의 종류에 대해 알게 되어서 좋았다.

^{⬆️ 위로 이동}

---

6장. 리팩터링

p131. 이 상태에서 새로운 요구가 들어온다. 요구를 충족하려면 기존 코드를 분석해야 한다. 하지만 항상 그렇듯 일정상 여유가 없다. 코드를 완벽하게 이해하지 못한 상태에서 코드를 수정해야 한다. 테스트 코드도 없어서 수정한 코드가 기존 기능에 어떤 영향을 끼칠지도 알 수 없다. 당연히 이런 상황에서 기존 코드 수정은 매우 두려운 일이 된다. 🐧

• 펭귄: 그럼에도 수정해야 한다고 생각한다.

p132. 이런 작업은 코드를 더 길고 복잡하게 만든다. 중복된 코드도 늘어나고 이상한 이름도 그대로 사용한다. 🐤

• 샐리: 기존 코드를 수정하는 것을 두려워하는 것이 중복된 코드를 늘리고, 이상한 이름도 그대로 사용하는 원인이 된다!

p132. 불과 몇 달 전에 내가 만든 코드도 레거시가 될 수 있다. 내가 만든 코드지만 수정하기 두렵다면 그게 바로 레거시다. 🌵

• 샐리: 코드를 짠 당사자가 잘 알아야하는 데, 그 당사자 조차 기억이 안나고 잘 모르겠다면, 다른 사람들은 오죽할까?

• 튜브: 수정하기 두렵다는 건 이해하기 어렵다는 것이기 때문에, 얼마 되지 않은 코드도 레거시가 될 수 있다.

p133. 복잡하고 수정하기 힘든 레거시 코드를 만나면 당연히 투덜댈 수 있다. 하지만 레거시는 폄하 대상이 아니다. 레거시가 있었기에 서비스가 굴러가고 수익이 난 것이다. 🐤🐧

• 펭귄: 다른 책에서도 봤었지만, 레거시가 나쁘다기 보다는 그 순간만큼은 최선이었고 그 이후로 잘 유지보수하는 게 중요한 것 같다.
• 샐리: 코드를 이렇게 짜 둔 이유가 분명 있을 것이라는 의견에 동의한다. 그래서 남의 코드에 함부로 수정을 제안하기 어렵게 느껴진다.

p135. 경우에 따라 코드를 수정하지 않고서는 테스트 코드를 만들 수 없을 때도 있다. 테스트 코드 없이 리팩터링을 하면 부담될 것이다. 하지만 리팩터링을 하지 않는 것보다 하는 게 낫다. 테스트 코드를 만들지 못해도 리팩터링을 시도해야 한다. 현재의 위험을 회피하다 보면 미래에 더 큰 위험으로 다가오기 때문이다. 🐧

• 펭귄: 실제로 경험해봤는데 테스트 코드 없이 리팩터링은 위험 부담이 컸지만 수정 후에 유지보수가 훨씬 수월해져서 확실히 안하는 것보다 나은 것 같다.

p135. 가장 쉽지만 가장 부담되는 리펙터링이 코드 삭제다. ... 왜 주석 처리했는지 몰라서... 나중에 다시 사용할지 몰라서... 🐤

• 샐리: 추가나 이동보다는 삭제가 확실히 부담된다. 그러나 요즘은 깃허브에 이력이 잘 남으니, 깃헙에 과감히 로그 남기고 지우려고 한다.
• 튜브: 잘 모른다고 남기지 말고 잘 알아보고 지우자

p135. 이런 이유로 삭제하기 두렵다면 해당 코드에 TODO 주석을 추가하자. 🐤🌵

• 튜브: TODO 주석을 어떻게 남기고 언제 지울지 약속이 필요한 것 같다.

p140. 보이는 이름과 실제 의미가 일치하지 않으면 코드를 분석할 때 혼란을 겪게 된다. 🐤

• 샐리: 처음에는 그 역할이 아니었는데, 코드 수정 시 역할이 바뀌는 경우에 종종 이런게 생기는 것 같다.

p158. 루프를 한 번만 돌면 되는데 여러 번 돌게 되면 성능이 느려진다고 걱정하는 개발자도 있다. ... 대부분 성능에 문제가 없다. ... 그리고 복잡한 코드보다 이해하기 좋은 코드가 주는 이점이 훨씬 크다. 🐤🌵

^{⬆️ 위로 이동}

---

7장. 테스트

p164. 개인적인 경험으로 볼 때 테스트 커버리지는 70~80% 수준이면 적당하다. 테스트 커버리지가 높을수록 좋지만 90% 이상을 목표로 하면 만들지 않아도 될 테스트 코드를 작성하는 일이 벌어지기 때문이다. 🌵🐧

• 튜브: 테스트는 개발을 도울 뿐 그 자체가 목적이 되어서는 안된다.
• 펭귄: 쉬운 함수도 테스트를 짜는 것을 매우 비효율적인 것 같고 코어 로직만 테스트하는 게 테스트를 하는 근본적인 이유라고 생각한다.

p164. 자동화된 테스트가 있으면 회귀 테스트를 쉽게 진행할 수 있다. 소프트웨어를 수정했을 때 수정한 기능 외에 다른 기능에 영향이 없는지 검증하는 테스트를 회귀 테스트라고 하는데, 자동화된 테스트 자체를 회귀 테스트로 사용할 수 있기 때문에 테스트 효율성을 높일 수 있다. 🐧

p170. 이렇듯 TDD에서 테스트 코드 작성 과정을 설계와 밀접한 관련이 있다. 🐤

p174. 테스트 코드를 작성하면 처음에는 개발 시간이 늘어나는 것처럼 느껴지지만 시간이 갈수록 반복되는 테스트 시간을 줄여줘서 오히려 개발 시간이 줄어든다는 것을 알 수 있다. 🌵🐤

p174. TDD는 기능을 구현하자마자 테스트를 실행한다. 테스트 직전에 코드를 작성했기 때문에 테스트가 실패해도 원인을 빨리 찾을 수 있다. 그만큼 디버깅 시간이 줄어든다. 🌵

• 펭귄: 매번 디버거를 사용하면서 디버깅하는데, 테스트코드가 있으면 그것만 돌리면 되니까 시간이 많이 줄어들 것 같다.

p175. TDD는 리팩터링을 포함한다. 리팩터링은 코드 구조와 가독성을 개선하는 작업이다. 리팩터링으로 나중에 하게 될 코드 수정과 추가 작업을 쉽게 할 수 있게 된다. 즉 미래의 디버깅 시간과 코딩 시간을 줄여준다. 🐧

p179. 테스트 가능성을 높이면 복잡한 계산 로직도 분리된다. 🌵

p180. 앞에서 언급한 것처럼 테스트 가능성을 높이는 과정에서 자연스럽게 역할에 따라 타입이 분리되면서 응집도가 올라가고 전반적인 설계 품질이 좋아진다. 🐤

p181. 하지만 기존 코드를 검증하는 테스트 코드를 작성하기가 쉽지만은 않다. 테스트 가능성을 염두에 두지 않고 작성한 코드가 많기 때문이다. 🐧

^{⬆️ 위로 이동}

---

8장. 아키텍처 · 패턴

p186. 주니어 개발자와 중간·시니어 개발자를 구분 짓는 요소 중 하나로 아키텍처 설계 역량을 꼽을 수 있다. 🐤

• 펭귄: 시니어의 다른 조건으로는 문제를 쉽게 해결할 수 있고 주니어의 폭주를 막을 수 있는 사람인 것 같다.
• 샐리: 직급이 높아진다는 것은 아키텍처 설계에 대한 역량을 쌓아간다는 것 같다. 단순히 연차만 쌓인다는 개념이 아닌 것을 느낀다!

p189. 하지만 당연하다고 생각하는 품질 속성도 경험이나 역량에 따라 놓칠 때가 많다. 🐤🌵

• 샐리: 내가 개발할 때 부족함이 느끼는 이유가 이런 이유구나 하며 공감했다.

p191. 품질 속성을 높이면 복잡도와 비용이 증가하고 서로 상충하는 품질 속성도 존재하기 때문에 아키텍처를 선택할 때 높이고자 하는 품질 속성 간의 절충이 필요하다. 🐤

p191. 모든 게 완벽한 아키텍처가 아닌 가장 나쁘지 않은 아키텍처를 선택해야 한다. 🌵

• 튜브: 하나의 치명적인 약점이 있으면 다른 게 완벽해도 더 이상 좋은 아키텍처가 아니다.

p192. 게임 서비스와 HR 시스템의 비교에서 봤듯이 개발하는 모든 시스템에 획일적으로 동일한 품질을 추구해서는 안 된다. 시스템마다 추구해야 하는 품질 속성이 다르므로 아키텍처도 달라져야 한다. 🐧

• 펭귄: 프로젝트의 아키텍처를 선택할 때 제일 쉬운 아키텍처를 고르고 이슈가 생길 때 더 복잡한 아키텍처로 가는 게 좋은 것 같다. 이걸 적용할 프로젝트가 아닌데 적용하려는 사례를 본 적이 있어서..

p194. 시스템이 커질수록 전체 시스템 설계가 개별 구현보다 중요해진다. 🐤

• 샐리: 아무래도 플랫폼 부서에 있다보니 설계의 중요성이 크게 느껴진다. 개별 구현은 주니어든 누구든 잘 돌아가고 조건만 맞추도록 짜면 기본은 하니까!

p195. 시스템 복잡도만 높아지고 이득이 없는 결정을 한 개발 책임자를 전문가라고 할 수 있을까? A 씨는 아마추어 같은 결정을 내렸다. 이런 식으로 특정 아키텍처를 적용해서 자아실현을 해서는 안 된다. 🐧🌵

• 펭귄: 강조 백만번!!!

p199. 이렇게 비동기 연동을 도입하면 연동하는 서비스에 문제가 생기더라도 영향을 최소화할 수 있다. 🐤

p201. 개발자는 우발적 복잡성에 빠지지 않도록 경계해야 한다. 물론, 흥미로운 기술을 만나면 사용해 보고 싶고, 유명한 회사에서 썼다는 기술도 써 보고 싶기 마련이다. 심할 때는 어떤 기술을 쓰지 못하게 막는 상사한테 화가 날 때도 있다. 하지만 그럴수록 우발적 복잡성의 유혹에 빠지지는 않았는지 곱씹어보자. 🐧

• 펭귄: 내 이야기라서..

p203. 따라서 문제를 완전히 없애기보다는 문제가 생겼을 때 알맞게 대처하는 방법을 찾아야 하는데 이때 사용할 수 있는 패턴이 결함 허용 패턴이다. 🐤🌵

p204. 한 번에 모든 패턴을 학습할 수는 없지만 주기적으로 새로운 패턴을 익혀보자. 설계와 소통하는 데 큰 이점을 누리게 될 것이다. 🐧

• 펭귄: 최근에 어떤 디자인 패턴을 적용한 코드를 봤는데 배웠으니까 그 패턴이 보였다. 아는 만큼 보이는거라 꾸준히 공부하면 좋을 것 같다.

^{⬆️ 위로 이동}

---

9장. 업무 관리

p208. 일은 하루에서 수일 이내에 끝낼 수 있는 크기로 나누면 좋다. 필요에 따라 수시간 내에 끝낼 수 있는 크기로 나누기도 한다. 🐧🐤

• 샐리: 일자별 목표를 세세히 짜야겠다는 생각을 했다.
• 펭귄: 확실히 큰 업무라면 작게 나누고 위임하는 게 좋은 것 같다.

p212. 코드를 만들고 기능을 확인했을 때 비로소 "거의 다 했어요"라는 표현을 할 수 있다.🌵

• 튜브: 항상 예상치 못한 일이 생긴다.

p214. 본인이 느끼기에 뭔가 잘 진행되지 않거나 모르는 게 있을 때 또는 명확하지 않은 점이 생겼다면 위험 신호라고 여겨야 한다. 위험 신호를 감지하면 빠르게 공유해야 한다. 어떻게 개발해야 할지 감을 못 잡고 있으면서 어떡해서든 혼자 해보겠다고 발버둥 치면 안 된다. 오히려 문제를 더 키울 뿐이다. 🐧🌵🐤

• 샐리: 혼자 해보겠다고 발버둥 치다가 일정이 미뤄진 경험이 많았다.
• 펭귄: 학교 다닐 때는 혼자서 고민을 많이 하는 시간을 가졌어서 질문을 하는 게 많이 어색했고 지금도 어색하지만 많이 해보려 노력하고 있다.

p215. 위험 상황을 관리하기 위해 미리 위험 목록을 작성해보자. 위험 요소는 어떤 게 있는지 검토해보고 5개 이상 찾아서 목록을 만들어보자. ... 위험 목록을 만들 때 등급을 함께 정리하면 더 좋다. 🐤

• 샐리: 위험 목록을 써두지 않으면, 나중에 코드 다 짜고 나서 위험 상황을 감지하기 어려운 것 같다. 미리미리 위험목록이나 주의해야할 사항들을 적어두는 것이 좋을 것 같다.

p217. 왜 그런 요구가 생겼는지 고민하기 시작하면 구현하기 전에 이해관계자가 실제로 원하는 결과에 가까운 산출물을 얻을 가능성이 커진다. 즉 정확한 요구사항의 이해는 기능을 구현하는 도중에 요구 사항이 바뀔 수 있는 가능성을 낮춰 재작업할 양을 줄여준다. 🐧

• 펭귄: 요구사항은 제대로 파악해야 나중에 롤백하는 일이 없기 때문에 요구사항이 이해될 때까지 물어보는 편.

p217. 예를 들어 스크럼에서 스프린트를 진행할 때 앞으로 진행할 2~3번의 스프린트에서 개발할 요구 사항만 자세하게 도출한다. 다른 요구 사항은 상세하게 기술하지 않고 이름과 개요 정도만 도출한다. 이렇게 필요한 시점에 세부 요구 사항을 만드는 방식은 불필요한 시간 낭비를 줄여준다. 🐤

• 샐리: 필요한 시점에 세부 요구 사항을 만드는 것도 속도나 효율을 위해서 중요한 부분이라고 생각한다.

p218. 결국 우선순위 문제다. 요구사항을 제시한 관계자는 모든 요구 사항이 중요하다고 말하기도 하지만, 일정과 비용을 맞닥뜨리면 얘기가 달라진다. 🐤

• 샐리: 일정이나 비용을 생각하면 저절로 우선순위가 정해질 수 밖에 없는듯하다.

p221. 일단 목표 일정이 최상위 임원에게 보고되면 일정을 변경하기가 매우 어려워진다. 완료하기로 한 날짜가 다가오면 더 그렇다. 일정에 맞춰 여러 조직이 함께 움직이기 때문이다. 직속 팀장이 혼나게 될까 봐 임원에게 일정 변경이 필요하다고 보고하지 못할 수도 있다. 그러니 일정 변경이 필요하다면 미리미리 상급자에게 보고해야 한다. 🐧

p227. 코드 중복이 세 번 이상 발생하면 중복을 제거하라는 말이 있는데 일반 작업에도 이 원칙은 적용된다.🌵

• 튜브: 업무 자동화도 중요한 능력

p230. 일을 맡길 때도 마찬가지다. 단순히 만들어야 할 결과물만 알려주면 안 된다. 이유와 목적을 함께 알려줘야 한다. 그래야 불필요한 반복 작업을 줄일 수 있다. 🐧

• 펭귄: 업무할 때 목적과 이유를 알면 업무의 이해도가 높아져서 훨씬 잘할 수 있는데 이런 것을 설명하는 것이 기본이 되면 좋을 것 같다.

^{⬆️ 위로 이동}

---

10장. 정리하고 공유하기

p237. 장기적으로 봤을 때 코드를 작성하는 사람보다 코드를 읽는 사람이 더 많다. 🍋

• 샐리: 코드를 짤 때나 문서를 작성할 때 항상 이런 마음가짐을 가지고 써야겠다고 생각했다.

p239. 문장이 길어진다 싶으면 문장을 둘 또는 그 이상으로 나눠야 한다. 개인적인 경험으로는 문장이 길어지면 길어질수록 마무리 짓기 어려웠다. 짧은 문장 여러 개 쓰는 게 그나마 덜 힘들었다. 🐧

• 펭귄: 문장이 글을 적는 곳의 너비를 넘어가면 문장의 호흡이 길어진다고 판단하고 글을 잘게 자르는 편이다.
• 샐리: 요즘은 다들 메신저를 쓰다보니 긴 문장에 대해 신경을 못쓰는 경우가 많은 것 같다. 메일을 쓸 때 이런 습관이 독이 되는 것 같다.
• 튜브: 문장을 자르다 보면 글 내용이 정리되는 경우도 있는 것 같다.

p244. 주제를 못 찾겠다면 최근에 읽은 책에서 중요하다고 생각한 문장을 정리해보자. 내가 직접 생각하고 쓴 문장은 아니지만 책의 문장을 그대로 따라 쓰기만 해도 좋은 글을 쓰는 연습이 된다. 🌵

• 샐리: 어휘력을 늘릴 수 있는 책을 좀 읽어야겠다는 생각을 한다…
• 펭귄: 관심사(ex. 방탈출, 커피)에서 시작하거나 간단한 후기 쓰는 것부터 시작하면 조금 시작하기 수월한 것 같다. 물론 에디터 키는 것조차 귀찮아서 문제지만…

^{⬆️ 위로 이동}

---

11장. 리더와 팔로워

p254. 리더십이 반드시 상사와 부하 직원 사이에서만 형성되는 게 아니다. 주변에 영향을 주고 있다면 그게 바로 리더십이다. 🐧🌵🍋

• 펭귄: 리더랑 보스는 다르니까.

p256. 주의할 점은 내가 제시한 아이디어가 최고라는 자만에 빠지지 않는 것이다. 🍋

• 샐리: 혼자서만 일을 한다면 내 아이디어가 최고라는 생각에 빠지기 쉽다. 리뷰하고 협업하는 것이 이런 함정에서 빠져나올 수 있는 방법이지 않을까?

p258. 변화가 필요하다면 사람이 아닌 프로세스와 시스템에 집중하자. 🌵🍋🐧

• 펭귄: 사람이 아닌 프로세스와 시스템을 집중할 수 있다는 것 자체가 리더가 아닐까? 그런 사람을 본적이 있는데 정말 경의로웠다.

p259. 주니어를 벗어나야 할 개발자가 이런 다양한 역량을 성장시키는 데 소홀하고 구현 기술만 파고 있으면 오히려 문제가 될 수 있다. 🍋

• 샐리: 스터디를 했기 때문에 개발자가 키워야할 다양한 역량에 대해 배울 수 있었던 것 같다. 포기하지 말고 얇고 길게 갑시다!

p260. 직원의 성장을 바란다면 일을 대신하지 말고 마음의 여유를 갖자. 위기 순간에는 바른 조치를 위해 직접 나서야 할 때도 있지만 위험한 상황이 아니면 대신하고 싶다면 유혹을 견뎌야 한다. 🐧🌵

p261. 일을 맡겨 놓고 작은 것까지 하나하나 지시하는 마이크로 매니저는 직원의 자율성을 뺏는다. 자율성이 없는 직원은 주도성을 잃는다. 어차피 상급자가 시키는 대로 해야 하기 때문이다. 괜히 내 생각대로 했다가 욕을 먹느니 수동적으로 시킨 일만 하는 게 낫다고 생각하게 된다. 🐧🍋

• 샐리: 마이크로매니징을 하게되면 딱 시키는 일까지만 하게 되더라.
• 펭귄: 마이크로매니징을 받는 입장, 하는 입장 모두 되어봤는데 많이 반성하게 되었다.

p263. 지연된 프로젝트에 개발자를 추가로 투입하면 일정이 더 늦어진다는 것이다. 이것을 브룩스의 법칙이라고도 한다. 이 법칙에 따르면 진행 중인 프로젝트에 인력을 추가로 투입하면 소통 비용과 부하가 늘어나면서 개발 시간이 줄기는커녕 오히려 증가한다. 소프트웨어 개발에서 규모의 비경제를 이겨내는 방법은 대규모 프로젝트를 여러 개의 작은 프로젝트로 나누는 것이다. 🐧🍋🌵

p264. 반대로 리더가 조직 내에서 성과를 내지 못하면 팔로워 역시 성과를 내기 어렵다. 리더와 팔로워는 공생 관계이다. 🐧

p266. 나쁜 리더를 쉽게 막을 수 있었다면 히틀러 같은 최악의 독재자가 탄생하는 일도 없었을 것이다. 🐧

p269. 예를들어 내가 작성한 코드의 부족함을 지적당해도 코드에 나를 대입할 필요가 없다. 코드는 코드고 나는 나다. 🍋

• 샐리: 좋은 코드를 만들기 위해서 모인거니, 코드를 지적당한다고 해서 기분 나빠할 필요는 없다!
• 펭귄: 같이 협업하는 사람이기에 서로 기분 상하지 않도록 쿠션어가 필요하고 이 코드가 이상하다면 그에 대한 충분한 근거가 있어야 된다고 생각한다. 결국 같이 만들어가는 코드이기 때문에 더 좋은 코드를 만들기 위한 의견을 주고 받는 것은 매우 좋지만 단순히 “이거 별로에요"는 싸워야 된다.

^{⬆️ 위로 이동}

---

💬 느낀점

팀원	느낀점
펭귄	스터디하기에 가장 좋았던 책이었다. 개발 뿐만 아니라 업무, 협업 그리고 리더까지 다양한 내용이 나와서 이야기를 나누기가 정말 좋았다. 책에서 중간 중간에 저자의 경험을 적어놓은 부분이 있었는데, 3년 가까이 일하면서 내가 겪었던 일과 비슷한 일이 있었어서 많이 공감되었다. 특히 11장은 많은 깨달음을 얻을 수 있었고 나중에 내가 리더가 된다면 다시 읽어보면 좋을 것 같다.
샐리
튜브

^{⬆️ 위로 이동}