개발자 원칙을 읽고

"개발자 원칙"은 테크리더 9명이 더 나은 개발자로 살아가기 위한 원칙과 철학을 9챕터로 나누어 담은 책이다.

덕업일치를 넘어서 - 박성철

챕터에서 기억하고 싶은 내용

동기 벡터에서 기대되는 성과와 내가 일하는 동기 그래프가 가장 기억에 남는다. 결국 내가 일하는 동기를 기준으로 나의 성과를 만들어낼 수 있다면, 지금 내가 옳은 방향으로 잘 일하고 있다는 측정 도구로 사용해볼 수 있을 것 같았다.

소감

나는 어떤 일을 하고 어떻게 살 것인가에 대해 나온 많은 책이 있지만 개발자로서의 고민이 담긴 글은 처음이었다. 같은 개발자여서 더 당연히 더 흥미가 갔다. 무슨 일을 하면 행복할지 그리고 개발자가 되면 정말 행복할까에 대해 취준생 때 많이 고민 했지만 직장인 개발자가 되고나서는 이러한 고민들에 대해서 소홀했었다. 이 글을 읽은 뒤 부터 조금씩 더 고민하려고 한다. 고민하다보면 박성철 본부장님 처럼 아주 훌륭한 개발자 까지는 아니더라도 최소한 어떤 방향으로 가야하는지 알 수 도 있지 않을까라고 느꼈다.

궁금한점

가치 있는 일을 하기 위해 창업하였다고 했는데 그 과정에서 어떤 느낌을 받았는지 더 알고 싶었다. 내가 하는 일이 어떤 의미가 있는지에 대한 고민이 많이 담긴 글인데 개인의 감정 표현과 힘들었던 점들에 대한 묘사 더 많았으면 좋겠다. 챕터가 짧으니 어쩔 수 없을 수도 있겠다. 그리고 궁금한 점과는 다른 맥락이지만 박성철 본부장님께서 기본적으로 사회에 기여를 하고 그러한 행위에 많은 가치를 느끼시는 분이기에, 이분이 사회적 기업을 운영하시면 참 잘할 것 같다는 생각이 들었다.

 

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

챕터에서 기억하고 싶은 내용

• 설계 제작 도구의 표준화 및 단일화 측면으로 보았을 때, 소프트 웨어 제품은 아직 설계와 관련된 표준이 없습니다. 제품 개발을 작가가 소설을 쓰듯이 자유롭게 그리고 민첩하게 만들면 모든 문게가 해결된다고 근거 없는 주장의 영향~(소프트웨어 설계에 대한 미숙한 인식)
• 제품이 소프트웨어든 아니든 설계의 결과물이 바로 제작 가능한 형태의 무엇이어야 한다고 생각합니다.
• 화성 드론 인제뉴이티 개발 사례
  • 화성에서 비행할 수 있어야 한다 단순한 요구사항. 하지만 이것을 만족한다는 것을 증명할 수 있는 조건을 정의하는 것에서부터 시작해야 문제를 풀 수 있다. 그 시작으로 대기압와 대기질을 구성하는 종류를 알아야 한다. 그래야 추력을 비교해서 계산할 수 있어야 한다. 그래야 프로펠러의 분단 회전수와 크기를 계산할 수 있다로 이어지며 문제를 해결할 수 있다.
• SOBOM

소감

설계 지식을 처음 접하는 지금 단계에서 모든 설계의 원칙을 이해하기는 꽤 어렵다. 어떠어떠한 설계의 원칙들이 있고 아 중요하긴 하겠다는 생각이 들은 정도다. 게다가 책에서 설명하는 대부분의 원칙들을 의식하면서 개발 해본 적이 없다. 내 경험에 빗대어 읽을 수 없기에 이 챕터가 더 어렵게 느껴졌다.

하지만 화성 드론 사례를 통해서는 설계가 왜 중요하고 문제 해결에 어떤 역할을 하는지 이해할 수 있었다. 설계 원칙에 대해 설명할 때도 이처럼 예시를 들어 오히려 더 길게 서술하는 식으로 되어 있었다면 상상해보며 이해하기 쉬웠을 것 같다.

다음번 프로젝트에서 이 책에서 설명해준 설계의 원칙을 다시 훑어보려고 한다. SRS를 구체화 시키는 작업을 할때 이 책을 잊지 말고 참고하자

궁금한점

통합설계의 미래에 대해서는 저자의 생각을 제시한 것이 없다. 소프트웨어 디자인 도구의 변화만 다시 제시했다. SOBOM이 그 역할을 다 할 수 있다는 건지.. 그래서 어떻게 흘러갈 것인지 모르겠다.

 

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

챕터에서 기억하고 싶은 내용

• 물리 원칙은 아주 단순한 규칙의 조합으로 세상을 움직입니다.
• 결국 측정이 있어야지만 중간에 모든 가설을 확인하고 목표와 계획을 업데이트해서 계속 진행이 가능하기 때문입니다.
• 준비 없이 실천하면 불로 향하는 불나방 꼴이 납니다.
• 어려운 일일 수록 작은 목표, 작은 계획으로 시작하자.

소감

gpam의 룰이 단순하다는 점이 가장 마음에 들었다. 데개북도 규칙이 간단하지만 독서의 습관을 길러주는 것을 목표로 하고 있는것 처럼 gpam도 간단하지만 목표달성에 꼭 필요한 것들로만 채운 컨셉 같았다. 너무 단순한 규칙들이어서 어라 이게 겨우? 라는 생각이 들수도 있다. 건강의 비결이 뭐에요 라고 의사들에게 물어보면 항상 듣는 “균형잡힌 식단과 충분한 숙면”이라는 조금 싱거운 답변을 들었을때와의 느낌과도 같다. 건강에 특별한 비결이 없듯이 글쓴이도 목표달성에도 특별한 비결은 없다고 말하고 싶은것 같다. 눈을 혹하게 하는 솔루션을 제시하는 것이 아니라 목표달성에 꼭 필요한 것들만 고려하여 gpam이라는 도구를 만든점을 기억하고 싶다.

평가를 받는 것이 어떤 것인가에 대해서도 한번 생각해 보았다. 평가 받지 않으면 느낌으로만 남는 경우가 많았다. 내가 완전히 이해했다고 생각했던 개발 지식들도 조금만 시간이 지나면 흐릿하게 없어지는 경우가 있다. 학생때 분명히 교수님의 말씀들이 다 이해 되었지만 막상 중간고사 서술형 시험 때 글로 잘 못풀어 냈던 적도 많았었던 것 같다. 이해를 했다고 생각했지만 사실 내가 이해하지 못했던 것 같다. gpam은 나의 방향이 맞는지 한번 더 확인받을 수 있는 시스템 같다. 글에 적힌데로 평가를 통해 내가 가진 확증편향을 이겨내야 한 단계 더 앞으로 나아갈 수 있다고 생각한다.

또 계획과 목표는 작아야 한다고 말하는 것도 공감이 갔다. 진짜 어려운 일일 수록 이거 시작하면 언제 끝나지? 실패하면 시간 낭비 아닌가? 등등 한 발자국이 안떨어지는 경우가 있었다. gpam을 이용해서 작은 목표와 계획부터 수립하고 평가를 기록해 나간다면 용기와 성장 둘 모두를 얻을 수 있지 않을까하는 생각도 들었다.

궁금한점

궁금한 점은우선 gpam을 이용해보고 적어보려고 한다.

 

제어할 수 없는것에 의존하지 않기 - 이동욱

소감

개인적으로 제어할 수 없는 것을 선택하는 용기도 필요하다고 생각한다. 이동욱님이 제시한 원칙 자체를 부정하는 것이 아니라 삶 전체로 이 원칙을 확장 시킬 수는 없다는 것이다. 그냥 이 챕터를 읽고 드는 생각이다. 제어할 수 있는 일에만 집중하는 태도는 문제해결 관점에서 좋은 원칙이라고 생각한다. 이동욱님도 그점을 말하려고 한것 같다. 다만 왜 제어할 수 없는것들에도 리스크를 가져야 한다고 생각하는지 이동욱님의 몇몇 선택과 엮어서 정리해 보았다.

첫째로, 투자는 본인이 제어할 수 없기에 투자가 없어도 생존 가능한 회사를 이직 기준으로 둔 점이다. 안정적인 환경에서 개발을 하고자 하는 욕구에는 이 원칙이 부합할 수 있겠지만, 더 리스키 하지만 리턴이 큰 회사에 이직하는 데는 방해가 될 수도 있을 것 같다. 예를 들어 투자금 없이 성공한 자수성가 스타트업에는 초기에 조인하여 스톡옵션을 받을 기회조차 얻지 못할 것이다.

둘째로 이동욱님이 성장의 열망이 없는 팀원을 바꾸기 힘들다고 한 점이다. 정확히는 성공시켜 본적이 없다고 적혀있다. 그래서 신규채용은 내가 제어할 수 있으니 이때 성장의 열망이 있는 사원을 채용해야 한다고 말한다. 나는 제어할 수 없는 사람에게도 최선을 다 해야 한다고 생각한다. 성장에 대한 열망을 바꿀 수 없더라도 회사다니는 재미를 더 느끼게 해준다던가 복지를 바꿔서 더 만족스럽게 해준다던가 하는 방향으로 생산성을 올릴 수 있을 것이다. 무엇보다 제어할 수 없다고 미리 예단하면 안 된다. 그리고 그사람이 성장에 대한 열망이 없다고 어떻게 판단 했다는 것인가? 이동욱님처럼 좋은 CTO가 인프랩 와서 성장에 대한 열망이 생겼을지도. 그러니 더 기다려 보라고 말해주고 싶었다.

궁금한점

내가 제어할 수 없는 것들로 넘쳐나는 환경 속에 내 몸을 던져 놓고 온몸으로 부딪히는 것 또한 나를 성장시키지 않을까? 예를 들어 초,중,고등학교는 제어할 수 없는 것 투성이다. 군대는 더더욱. 내가 원하는 과목을 선택해서 들을 수도 없고, 내가 원하는 사람을 만날 수도 없다. 내가 원하는 장소로 이동도 할 수 없다. 하지만 우리 모두 그러한 환경속에서 적응하고 성장해 가며 살아왔다. 제어할 수 없는 환경을 통해 얻는 장점들에 대해서도 생각해 볼 점들이 많다.

 

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

기억하고 싶은 내용

CTO님이 제시한 원칙 3가지는 이것이다. 첫째, 일단 동작하게 만든 다음 더 좋게 만들어라. 둘째, 기술 부채를 적절하게 가지는 것을 허용해 가며 새로운 자산을 늘려나가라. 셋째, 바퀴를 다시 발명해 보는 과정을 통해 성장하라. 그리고 글쓰기도 많이 읽어야 좋아지는 만큼 코딩하는 능력도 기르려면 많이 읽고 써보라는 것이다. 그중에서도 컨텍스트의 중요성에 대해 강조하신게 기억에 남는다.

코드만으로는 부족하다 작성자의 의도와 배경 등 코드의 해석에 필요한 부가적인 정보인 컨텍스트가 필요하다

 

소감

우리 회사 장동수 CTO님의 글이어서 동수님의 목소리로 상상하며 글이 읽어졌다.ㅎㅎ CTO님이 평소에 회사 발표 때 강조하셨던 내용들도 있었고 이번 챕터를 통해서 새롭게 알게 된 CTO님의 생각도 있었다. 새롭게 알게 된 장동수님의 생각은 컨텍스트에 대해 중요하게 생각하시는 것이다.

컨텍스트는 한마디로 텍스트(코드) 해석에 필요한 모든 것이다. 커밋, 주석, 코드 스타일 등 모든 것이 컨텍스트가 될 수 있다. 그동안 코드를 만들며 컨텍스트에 대해서 많이 고려하지 않았다. 단순히 중복을 제거하고 모두에게 인증된 디자인 패턴을 잘 활용하면 좋은 코드라는 생각이었다. 개발 공부를 할 때도 더 좋은 라이브러리와 패턴은 뭘까 등 코드 퀄리티 자체에 대한 고민을 많이 했지, 어떻게 하면 다음 사람이 더 쉽게 내 코드를 해석할 수 있을지 컨텍스트에 대한 고민은 많이 안한 것 같다.

하지만 동수님 말씀대로 글쓰기뿐만 아니라 개발에서도 컨텍스트는 중요한 것 같다. 나의 코드를 보게되는 다음 개발자는 나와 완전히 다른 사람이다. 기술적으로 다른 백그라운드를 가지고 있을 수도 있고, 다른 사업부에 오래 있어서 비즈니스에 대한 이해도도 다를 수 있다. 그래서 이 코드는 중복도 없고 클린한 코드니 잘 해석 되겠지라고 생각하는 것은 좋지 않은 것 같다. 오히려 충분한 컨텍스트를 코드상에 녹여 낸다면 그 자체로 가장 좋은 코드라는 타이틀을 붙여 줄 수 있지 않을까 생각해 보았다.

지금 내가 컨텍스트를 코드에 반영한다면 이렇게 할 것 같다. 우선 커밋 메세지를 더 자세하게 쓸 것이다. 요즘 깃 렌즈를 안쓰는 사람이 없는 것 같다. 코드와 함께 커밋 메세지를 읽을 수 있으니 커밋 메세지가 분명할 수록 컨텍스트가 잘 전달되지 않을까? 필요하다면 주석에 이 컴포넌트가 하는 역할에 대해서도 넣어줄 것이다. 또한 비즈니스 로직에 대한 설명도 필요하다면 쓸 것 같다. 우리 팀은 jira를 활용하고 있으니 커밋 메세지에 jira 이슈번호를 넣는 것도 해당이 되겠다.

궁금한점 / 이해되지 않는 점

• 개발을 하며 앞으로 더 많은 컨텍스트를 표현하려면 어떻게 해야할까?
• 바퀴를 다시 발명해 보는 노력을 업무 차원에서도 해볼 수 있는 것일까?