[개발자 원칙 : 테크 리더 9인이 말하는 더 나은 개발자로 살아가는 원칙과 철학] - 요약

01 덕업일치를 넘어서 - 박상철 님

“저는 개발자를 두고 공장에 자기만의 생산 설비를 들고 들어가서 일하는 노동자라고 표현합니다.” - 39p

평소 개발자들한테 전문가라는 의미는 변호사, 세무사, 의사 같은 전통적인 전문가들과 달리 정의가 다르다는 느낌을 받아왔었는데 이 문구 하나로 개발자라는 직업적인 특수성에 대한 깔끔하게 확립되었다.

전문가에 대한 정의 - 44p

전문가 = (전문 역량 + 일반 역량) * 동기 * cosθ * 연대

“저는 아직도 우리 개발자가 전문가로 인정받지도, 그렇게 행동하고 있지 않다고 생각합니다” - 46p

다른 직군들과 비교했을 때 미미한 사회적 책임감, 낮은 수준의 개발자 양성 과정등에 자유롭지 못하기에 스스로를 되돌아보게 된다

02 오류를 만날 때가 가장 성장하기 좋을 때다 - 강대명 님

“오류가 발생하면 소스 코드 레벨에서 이해하자” - 53p

사용하고 있는 툴에 문제가 발생하면 소스 코드 레벨에서 문제를 찾아내고 해결해 보는 경험을 하면 깊은 지식을 얻을 수 있다는 것에 공감이 된다.

“알아낸 지식을 글로 공개하라” - 56p

지식을 끝까지 탐구하는 과정을 재밌게 풀어냈고 비슷한 상황이 생기면 단순 git issue나 스택 오버 플로우만 찾아서 해결방법만 적용하는 거에 멈추지 말고 소스코드 레벨에서 탐구해보고 싶은 욕심이 생긴다. 또한 그 과정을 글로 남기고 재야에 숨겨진 개발 고수들에게 피드백받을 상상만 해도 즐거울 거 같다.

03 소프트웨어 디자인 원칙 - 공용준

“우리는 소프트웨어 설계에 관한 한 정말 잘못 배웠습니다” -73p
“소프트웨어 제품이 잘 완성될 수 있게 하는 ‘디자인 원칙’이 반드시 필요합니다 - 78p

지금까지 우리는 KISS, DRY, YAGNI, SOLID와 같은 프로그래밍에 필요한 디자인 원칙을 잘 따르면 반드시 훌륭한 소프트웨어 제품으로 연결된다는 생각이 잘못되었다고 알려주고 있다. 또한 디자인 악취를 제거하기 위해서는 원칙을 따르는 것이 아니라 소프트웨어 제품을 만들 때 즈음에 발생하는 다양한 가정(또는 상수)들을 고려해야 된다는 것이 인상 깊었다.

💡 소프트웨어의 다양한 가정
- ‘제대로’ 디자인하고 만들기에는 늘 시간과 사람과 돈이 부족합니다.
- 한 사람이나 팀이 처음부터 끝까지 개발하지 않고, 언젠가는 전혀 히스토리를 모르는 사람이 개발을 맡게 됩니다.
- 한번 만들어지고 나면 아주 오랫동안 사용됩니다. 이미 릴리즈 된 소프트웨어는 다음 버전이나 개선 때 더 빨리 만들 수 있다고 믿습니다.
- 소프트웨어에 세계에서 변하지 않는 건 ‘시가/사람/돈에 대한 결핍’ 외에는 아무것도 없습니다.
- 소프트웨어에 대한 요구사항은 의도적이든 아니면 자연적이든 시간이 지남에 따라 늘 변합니다.

“소프트 웨어 제품은 아직 설계와 제작과 관련된 표준이 없습니다.” - 83p

90년대 초반에 UML이 설계의 역할을 대신해줄 것 같았지만 다음과 같은 이유로 보편화되지 않았다.

• UML로 소프트웨어 설계를 해서 결과물을 만들었다 하더라도 실행 가능한 소프트웨어를 구현하려면 또 다른 과정이 필요하다
• 하나 이상의 조직이나 회사에 같은 UML 설계 자료를 제공해 위탁 개발했을 때 같은 소프트웨어 제품을 만든다는 보장을 할 수 없다

2017년 대학교에서 UML을 처음 접했을 때 과연 이게 설계의 기능을 완벽히 대체할 수 있을까?라는 의문이 있었는데 역시나 아니었다. 이렇듯 같은 설계를 넣으면 동일한 결괏값이 나오는 소프트웨어 디자인은 아직까지 없으므로 현재 소프트웨어 설계 수준은 2000년대 초반에 머물러 있는 것에 동의한다.

“제품을 종합적으로 설계하는 방법은 명시적 설계와 암묵적 설계로 나눌 수 있습니다” - 89p

명시적 설계 4가지

• 기능 설계: 요구한 기능이 동작해야 한다.
• 성능 설계: 원하는 성능을 보장하고 성능과 관련된 부분들도 기록해야 된다. IaC나 오 케스트레이터가 발달하여 이 부분이 편리해졌다.
• 유지보수 설계: 도커 같이 작동 환경까지 공통화하는 서비스가 생겨나 편리하고 안전하게 서비스를 유지보수할 수 있다.
• 미적 설계: 사용자에게 물리적으로 심리적으로 즐거움과 편리함을 줄 수 있도록 제품을 미적으로 설계해야 합니다. IA와 UI/UX는 피그마 같은 도구들을 이용하고 있다.
• 사용성 검증: 화면이 가져야 하는 요구사항이나 성능 요구사항을 평가하는 기준을 만들어야 한다. ISO 9241-112 미적 설계 수치적 평가 예시를 참고하면 좋다. - 100p

암묵적 설계 4가지 항목의 13가지 요소

• 서비스 지속성 설계: 가용성, 용량, 연속성, 보안
• 서비스 전환 설계: 변환, 릴리즈, 설정 관리
• 서비스 운영 설계: 장애 대비, 요구 수행, 문제 대응
• 서비스 개선 설계: 서비스 리포팅, 측정, 레벨

저자는 암묵적인 요소를 고려하지 않고 소프트웨어를 설계하는 것을 조심하라고 알려주고 있다. 소프트웨어 설계방향성과 구체적인 요소들을 접하니 코드와 객체지향 수준의 원칙을 넘어 설계 원칙을 익혀야 하는 이유를 알 거 같다.

 

04 나의 메이저 버전을 업그레이드하는 마이너 원칙들 - 김정님

• 두리번거리면서 속력과 방향을 자주 확인하기
  “시대와 상황에 따라 더 나은 결과를 이끄는 도구나 방법론이 달라질 수 있으니 올곧게 한 방향으로만 고집할 필요는 없습니다.” - 123p
• 낯선 방식으로 해결하기
• 개구리를 해부하지 말고, 직접 만들기
• 남을 향한 자존심을 버리고, 나를 향한 자존감 채우기
• 결과를 향하면서 과정을 기록하기
• 의도한 실수를 반복하면서 작은 부분을 개선하기
• 기준을 정하기 전에 여러 답을 찾아서 공유하기
• 배포하기 그리고 다음 버전 준비하기

개발뿐만 아니라 다른 직군에서 일하더라도 항상 되새겨야 될 문구들 같다.

05 이직, 분명한 이유가 필요해 - 박미정 님

“개발자는 경험이 쌓일수록 필요한 기능을 개발하는 역할에서 필요한 일을 찾아내는 역할로 시야를 확장해가야 합니다” - 158p

대기업에서 스타트업 그리고 다시 대기업으로 이직하는 과정을 일목요연하게 설명해 줘서 면접 질문이나 자소서를 쓸 때 큰 도움이 될 거 같다. 또한 회사를 떠나는 이유가 오로지 자신의 성장을 위한 것이고 이성적인 판단이 앞선다는 것이 존경스럽다.

“기존 환경에서 변화 모색하기 먼저, 그리고 책임감 있는 마무리가 중요해” - 164p

이직에서 가장 중요한 것은 기존 환경에서 책임을 다하고 마무리하는 태도를 강조해, 다시 한번 만나고 싶은 동료로 기억되어야 한다는 내용이 인상 깊었다. 다시 한번 일에 대한 열정과 책임감을 되돌아보는 파트였다.

06 목표를 달성하는 나만의 기준, GPAM - 박종천 님

"Goal을 정하고 Plan을 만들고 Action을 하고 Measure를 진행해 결과를 확인하면 됩니다." - 170p

목표 설정 방법 - S.M.A.R.T
- Specific: 개선이 필요한 영역에 대한 구체적인 목표
- Measurable: 진행 상황에 대한 수치화가 가능한지
- Actionable: 실행이 가능한지
- Realistic: 현재 리소스로 현실적으로 가능한지
- Time-related: 결과가 언제 나올지 기한이 있는지

박종천 님의 GPAM 적용 사례를 보고 깊이 감명받아 나도 목표를 설정해 봤다.

• Goal: 업무 능률 향상을 위한 나만의 프론트엔드 레퍼런스 자료 만들기
• Plan: MAU 디자인 시스템을 기반으로 Atomic 한 React 컴포넌트 구현
• Action: jest와 story book을 사용해 테스트 코드가 포한된 컴포넌트를 구현하고 작업 과정 중에 나왔던 고민과 결과를 문서화
• Measure: 코드는 github에 올리고 문서는 개인 블로그에 기재

GPAM의 이해와 활용은 쉽지만 계획을 실천하는 것은 개인의 의지에 달린 거 같다.

07 프로덕트 중심주의 - 이동욱(네피림)님

“실제 프로덕트를 목표로 삼는 계획과 그렇지 않은 계획은 적지 않은 결과의 차이를 만들어 냅니다” - 193p

‘모바일 개발에서 주목받는 플러터 프레임워크를 공부하겠어’와 ‘플러터로 여행 기록용 모바일 어플을 만들어 보겠어’의 결과의 차이를 비교해 보면 프로덕트 중심으로 목표를 설계해야 예상하지 못한 부분에서 더 깊은 고민을 하게 되고 이는 개인과 회사의 성장에 중요한 영향을 끼친다는 것을 알려주고 있다.

반복적으로 완성하고 디테일하게 만들고 항상 협업 모드로 작업하는 것과 망설일 바에는 실패하는 것을 권유해 궁극적으로 더 많은 개발자들이 더 오랜동안 개발을 즐길 수 있으면 좋겠다는 바람이 진심으로 다가왔다.

08 제어할 수 없는 것에 의존하지 않기 - 이동욱(향로)님

“프로그래머에게 요구되는 것은 100점이 아닌 80~90점짜리 프로그램을 기한 내에 완성하는 일이다 - 나카지마 사토시” -207p

어떻게 하면 아무리 급해도 항상 80~90점짜리 소프트웨어를 개발할 수 있는지를 강조하고 있다. 그러기 위해서는 자신만의 기준 원칙을 확립해야 된다는 말에 나만의 기준 원칙이 있는지 생각해 봤다

또한 코드 설계 과정에서 제어할 수 없는 것에 의존하지 않기의 원칙을 적용한 것과 배달의 민족에서 다른 회사를 이직할 때 인프런을 고른 이유 또한 동일한 원칙을 적용해 이직할 회사를 선별한 사례를 읽고 나도 무언가를 정할 때 제어할 수 없는 것에 의존하지 않기의 원칙을 적용하면 굉장한 도움이 될 거 같다.

“제가 폭발적으로 성장할 수 있던 것은 스타트업이었던 조직이 빅테크로 성장하는 그 과정을 그대로 겪었기 때문입니다. 여기 계신 분들도 그 경험을 꼭 했으면 좋겠습니다” -224p

인프런이 빅테크의 사관학교로 포지션이 변경되는 위기를 높은 연봉 테이블이나 회사 복지 같은 요소로 회유하기보다는 이 회사가 빅테크로 성장하는 회사가 될 수 있고 그 경험을 통해 폭발적으로 성장할 수 있는 개발자가 될 수 있다는 근거 있고 자신감 넘치는 말 한마디가 제어할 수 있는 것에 의존하고 집중해야만 앞으로 전진할 수 있다는 것을 강력하게 전달되었다.

09 달리는 기차의 바퀴를 갈아 끼우기 - 장동수 님

1. 일단 동작하게 만든 다음 더 좋게 만들어라. 지금 제대로 동작하는 코드를 만들어야 미래에 더 좋은 코드를 만들 수 있다. 그 후 더 좋게 만들려면 가독성, 성능, 유연성을 챙겨야 한다.
2. 언제나 발견했을 때보다 깨끗하게 해 놓고 캠핑장을 떠나라. 기술 부채로 생기는 문제점을 보이스카우트 캠핑 규칙을 통해 조금이라도 문제를 해결할 수 있을 것이다.
3. 바퀴를 새로 발명하는 일의 좋은 점은 둥근 바퀴를 얻을 수 있다는 점이다.
   ”굴러가는 바퀴를 만드는 일이 (지금의) 밥값을 하는 일이라면, 더 잘 굴러가는 바퀴를 다시 발명하는 과정은 (미래의) 몸값을 만드는 일입니다. - 246p
   
4. 많이 읽고, 많이 쓰고 많이 생각하자
   당연하지만 가장 어려운 말이다.

최종

9명의 테크 리더들의 관점이 비슷한 것도 있고 다른 경우도 있다. 그래서 자신이 좋아하는 리더의 글이나 문구만 자신의 개발정신에 적용하는 것은 위험해 보인다. 모든 직업이나 업무들이 그러하겠지만 개발도 문제의 상황마다 적용해야 되는 해결 방법이 다르다고 생각한다. 즉, 어떤 상황에 누구의 정신을 활용할지는 우리의 몫인 거 같다.