[개발자 원칙] 정리

https://product.kyobobook.co.kr/detail/S000200381165

개발자 원칙 | 박성철 - 교보문고

읽은 기간 : 2022.12.26 ~ 2022.12.27

인상깊었던 구절들

덕업일치를 넘어서

사람은 저마다 자기만의 동기를 가지고 살고 있고 외부에서 부여하거나 제어할 수 없다. 각 개인의 동기를 이해하고 이 동기에 맞게 일을 주어야 한다.

지식 근로자는 스스로 성과의 방향을 설정해야 하기 때문에, 자신에게 어떤 성과가 기대되고 있는지 그리고 자신에게 그러한 성과가 기대되고 있는 이유가 무엇인지를 이해하지 않으면 안 된다.

많은 회사가 단위 조직을 팀이라고 부르지만 사실 팀워크가 올바로 동작하는 팀은 많지 않다. 
흔히 좋은 팀워크는 좋은 분위기를 의미한다. 그래서 회식이나 대화를 많이 하는 것이 팀워크를 좋게 만드는 방법이라고 한다.
물론 좋은 분위기는 중요하다. 하지만 팀워크는 그 이상이다. 1 + 1 이 2 이상이 되도록 만드는 것이 팀워크다.
팀워크가 좋은 팀은 의미 있는 성과를 지속적으로 내며 늘 더 높은 목표에 도전한다. 공동의 목표를 위해 협력하고, 서로 배우고 가르치며, 개인과 팀 모두 성장한다

오류를 만날 때가 가장 성장하기 좋을 때다

첫 번째 원칙은 '오류가 발생하면 소스 코드 레벨에서 이해하자'
서비스를 운영하다 보면 많은 툴을 사용하고, 많은 에러를 마주친다.
이때 해당 오류를 스택오버플로에서 검색하면 대부분 손쉽게 해결책을 얻을 수 있다.
하지만 여기서 끝내버리면 실제로 깊은 지식을 얻기 힘들다.
한 발 더 나아가서 해당 툴의 소스 코드를 확인하는 것으로 관련 에러가 왜 발생하는지 해결하려면 어떻게 해야 하는지 같은 깊은 지식을 얻을 수 있다. 비슷한 문제를 예방할 수도 있게 된다.

두 번째 원칙은 알아낸 지식을 글로 공개하라는 것이다.
소스 레벨을 이해했다면 결과물로 남기는 것이 중요하다.
사람의 기억력을 믿을 수 없고, 때로는 제대로 이해했다고 생각하지만 제대로 이해하지 못했을 수도 있다.
블로그나 오픈 소스에 기여하여 결과물을 남기자. 
공개하기 꺼려질수 있는데, 개발자로서 성장하는 데 좋은 정보를 뇌에 입력하는 것도 좋지만, 제대로 이해하고 잇는지 확인받는 것도 중요하다.
아예 모르는 것보다 잘못 아는 것이 더 위험하다.

소프트웨어 디자인 원칙

디자인 이란 무엇인가?
디자인을 한국말로 하면 설계이다. 그렇다면 설계는 무엇인가?
목적에 따라서 실제적인 계획을 세우고 구체적으로 도면을 그려 명시하는 일이 설계다.

제품 관점에서 설계를 다시 정의해보면 '설계란 제품이 요구사항을 만족시키는 것을 증명하는 조건을 정의하는 행위' 로 볼 수 있다.
그래서 설계 전에 요구사항을 잘 정의해야 한다.

소프트웨어를 설계할 때 최대한 많은 정보를 기반으로 요구사항을 정리해야 한다. 
기획 부서에서는 제품과 관련된 전략적 목표를 기반으로 아주 상세히 최대한 꼼꼼하게 요구사항을 기술해야 한다.
기획서 작성을 설계에서 가장 중요한 단계이자 방법이다.

나의 메이저 버전을 업그레이드하는 마이너 원칙들

성장을 목표로 한다면 먼저 방향과 나만의 속력을 알아야 한다.
낯선 목적지를 찾아갈 때 방향을 정확하게 인지하지 못하면 방황하거나 더 먼 길로 돌아갈 수 있으므로 이동할 방향을 알아야 한다.
그런데 현실에서는 목표가 있는 방향으로 일직선으로 나아가는 일은 불가능하다.

속도의 정의는 속력x방향이다.
얼마나 빠른지 나타내는 속력만큼이나 방향도 중요하다. 처음에는 출발점에서의 거리가 멀지 않기 때문에 방향에 별로 신경 쓰지 않는다.
하지만 계속 가면 방향에 따라 목적지와의 거리가 더 멀어질 수도 있다.
그러므로 개발 과정에서도, 성장 과정에서도 목적지로의 방향을 계속해서 확인하고 다시 조정해야 한다.
시대와 상황에 따라 더 나은 결과를 이끄는 도구나 방법론이 달라질 수 있으니 옳곧게 한 방향으로만 고집할 필요는 없다.

위에서 다룬 '나만의 속도'는 '메타 인지' 라는 용어와 맞닿아있다.
어떻게 나만의 속도를 인지 할수 있을까? 속도를 인지하려면 기준점과 변곡점이 필요하다.
두 번째 원칙은 나만의 속도를 인지하는 데 유용한 '낯선 방식으로 해결하기' 다.

학습은 익숙한 것을 의식하지 않고 반복하는 게 아니라, 낯선 것을 의도를 갖고 배우는 것이다.
나만의 속도가 있는 것처럼, 학습 방법 중에서도 자신에게 익숙한 방법이 있다.

나에게 익숙한 것은 내가 잘 알기 때문에 설명하기 쉽다고 생각하지만 상대가 누구인지에 따라서 상황은 달라진다.
무엇인가 안다고 생각할 때는 이미 알고 있는 것과 그렇지 않은 것을 이분법으로 구분한다.
그래서 이미 알고 있는 개념과 단어를 이용해서 그 개념을 설명하려고 시도한다.
심리학자들은 이럴 때 확증 편향과 지식 착각이 발생한다고 한다.
자기도 모르게 지식을 알고 있다고 착각하고 확신을 가지게 된다.

알고 있고 익숙한 것을 확인하는 가장 좋은 방법은 배경지식이 없는 사람에게 새로운 개념을 설명하는 것이다.
처음부터 100% 이해시키는 것을 목표로 하지 않아도 된다. 
진정으로 알고 있는 거라면 어떤 상황에도 다른 표현으로 다시 설명할 수 있지만, 그렇지 않다면 설명하다 막히게 될 것이다.

익숙한 것을 반복하면 더 오래 기억할 수 있게 되지만 성장하지는 못한다.
성장을 위한 더 효과적인 방법은 의도적으로 낯선 환경을 만들고, 제약사항을 추가해서 도전적이면서 살짝 어렵지만 재밌는 요소를 찾아 학습하는 것이다.

"개구리를 해부하지 말고, 직접 만들어라" 
개구리를 더 잘 이해하려면 개구리 해부보다는 개구리와 똑같다고 부를 수 있을 개구리를 직접 만들어보라는 의미다.
정말 개구리와 독같구나 싶을 정도로 만들려면 그만큼 개구리를 깊이 있게 이해하고 분석하고 설계해야만 가능하다.
구현 범위가 넓거나 무엇을 개발할지 구체적이지 않아서 실패할 가능성이 높다.
끝까지 해내는 팁은 우선은 함수 하나만 구현해보라는 것이다. 이어서 입출력을 바꿔보고 화면을 추가하는 식으로 구현 범위를 넓혀간다.
실제로 개구리를 해부하는 일이 자주 생긴다. 새로운 라이브러리를 검토하거나, 다른 사람이 작성한 코드를 리뷰하는 일 모두 개구리를 해부하는 일이다.
이런 분석 작업을 할때도 직접 구현하지는 않더라도, 내가 직접 구현한다면 어떻게 설계할 것인가 생각하고 비교해보자.

낯선 지식과 경험을 학습하는 일은 나와의 싸움이라 외롭고 반복하는 과정을 짜증 나고 지치게 한다.
세상에는 다보다 잘난 사람이 무조건 있다. 
나를 지키고 분연히 일어나서 성장하려면 자존심을 키워서 다른 사람과 비교하는 것이 아닌, 자존감을 키워서 과거의 자신과 비교해야 한다.
비교하는 대상을 다른 사람으로 향하지 말고, 스스로 내면을 향하도록 해야 한다.
다른 사람 피드백에 흔들리지 말고, 나에게 집중해서 나에게 맞는 방법으로 성취감을 얻어가자.
일희일비하지 말고 칭찬에는 겸손하고 비난에는 나를 돌아보자. 하루에 조금씩만 더 나은 성장을 이끌어내면 된다. 그러려면 지속적으로 성취감을 느끼는 것이 중요하다.

시간이 지날수록 개발 과정에서 경험하는 범위가 넓어져야 하고, 개발 측면뿐만 아니라 다양한 관점을 바라볼 수 있도록 시야를 넓혀야 한다.

사람이 완벽하지 않듯이 개발 과정 역시 완벽하지 않다. 개발자는 끊임없이 실수를 한다.
학습할 때도, 일을 할 때도 실수를 두려워하지 말자.
실수가 전혀 없을 수는 없겠지만 개발 과정에서의 실수가 결과에는 반영되지 않도록 해야 한다.
실수한 사람을 질책하기보다는 누구나 실수할 수 있다고 가정하고 최종 릴리즈가 되기 전에 실수를 찾아낼 수 있는 안정적인 흐름을 만들어야 한다.

구체적으로 지식을 학습하고 코드를 작성하는 단계에서는 책이나 블로그를 보면서 따라 하는 것으로 만족하면 안된다.
그건 사고하는 과정이 빠진 상태로 결과를 복사해서 붙여넣는 단순 노동일 뿐이다.
구현하는 과정은 익숙한 방법으로 쉽게 해결하기보다는, 낯선 환경에서 제약사항을 추가하면서 점진적으로 구현하자.
같은 문제를 제약사항을 바꾸거나 동작 환경을 바꿔서 다른 시각에서 해결해보는 것도 좋다.

 

여려명의 테크 리더들의 자신만의 원칙들에 대해 설명을 해주는 책이다.
개인적으로 공감이 많이 됐던 장도 있고, 단순히 본인의 경험을 풀어서 말해주는 정도여서 크게 공감이 안됐던 장도 있다.
대부분 내용이 좋은 책이긴 하지만 더 심도 있는 내용을 기대했었는데 '개발자 원칙' 이라는 책 이름의 기대에는 약간 미치지 못햇다.