개발자 원칙 - 을 읽고

개요

알라딘: http://aladin.kr/p/ez6sj

 

같은 시대, 같은 문화를 배경으로 살아가는 개발자들의 목소리를 듣고 배우고 싶었다. 여러 저자들의 이야기를 하나의 책으로 묶는 것에 대해서 실망할지도 모른다는 걱정이 없지 않았다. 하지만 이 책은 훌륭하게 다양한 관점의 이야기들을 저자 각각의 원칙이라는 이름으로 묶어내었다.

 

이 책을 읽는 사람들은 저마다 와닿는 부분이 다를 것이다. 9개의 장 모두 좋은 이야기들을 담고 있지만 나 자신에게 인상적이거나 특히 좋았던 부분과 문장을 메모해본다.

1장. 덕업일치를 넘어서

"지식 노동자는 시대적 소명임과 동시에 지식 사회인 현대의 가장 기본적인 생산 요소" - 피터 드러커, 프로페셔널의 조건

"개발자는 그 자신이 생산 시설의 일부입니다." 39p

 

개발자라는 직업의 특수성에 대한 통찰이 인상적이었다.

 

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

"무엇보다 개발자를 양성하는 교육 과정과 개발이라는 행위는 여전히 흑마법 같습니다." 46p

 

전문가로서의 수준을 인정, 검증할 수준이 미비한 점, 우리 자신이 전문가라 인식하고 행동하고 있지 못한점, 심지어는 개발자가 되기위에 무엇을 공부하여야 하는지 명확하지 않은 점을 날카롭게 지적하고 있다.

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

"첫 번째 원칙은 '오류가 발생하면 소스 코드 레벨에서 이해하자'입니다." 53p

"두 번째 원칙은 알아낸 지식을 글로 공개하라는 겁니다." 55p

 

첫 번째 원칙은 임백준님의 "개발자의 평생공부 https://zdnet.co.kr/view/?no=20170616090644 "와 통하는 부분이다. 현업에서 마주친 무언가를 끝까지 정확히 파헤치는 것이 진짜 공부이다. 두 번째 원칙은 알게 된 것을 나누는 호혜적인 기쁨도 있겠지만 무엇보다 자기 자신에게 가장 좋은 것이라 생각한다. 배운 것을 나의 것으로 만드는 과정인 것이다.

3장. 소프트웨어 디자인 원칙

"하지만 이런 원칙이 반드시 훌륭한 소프트웨어 제품으로 연결되는 것은 아니므로(...중략...) 소프트웨어 제품이 잘 완성될 수 있게 하는 '디자인 원칙'이 반드시 필요합니다." 78p

 

이 장을 가장 감탄하며 읽었다. 처음에 나오는 "이런 원칙"이란 가장 작은 단위와 그 다음 단계에서의 KISS, DRY, YAGNI, SOLID, 소프트웨어 악취, 디자인 패턴 등을 말한다. 하지만 "이런 원칙"만으로는 좋은 소프트웨어 제품을 만들 수 없다고 말하는 것이다.

 

"이런 설계/제작 도구의 표준화 및 단일화 측면으로 보았을 때, 소프트웨어 제품은 아직 설계와 제작과 관련한 표준이 없습니다." 83p

 

다른 업계에서는 같은 설계를 넣으면 같은 결과를 기대할 수 있다면 소프트웨어는 그렇지 못하다는 현실을 말하는 부분이다.

 

"이제부터는 소프트웨어 제품을 만드는 원칙을 이야기합니다."

"설계란 제품이 요구사항을 만족시키는 것을 증명하는 조건을 정의하는 행위" 85p

 

두 번째 문장이 와닿는다. 만든 제품이 설계에서 말한 조건을 만족시키는지 여부가 중요하다. 그렇지 않으면 설계대로 만들지 않은 것이다.

 

저자는 우선 소프트웨어 요구사항 명세(SRS)를 만든 다음에 이를 바탕으로 명시적 설계와 암묵적 설계를 해야 한다 말한다. SRS나 기본 요구사항과 직접 연결되는 것이 명시적 설계이다.

 

명시적 설계 4가지

• 기능 설계: 요구한 기능이 동작해야 한다.
• 성능 설계: 원하는 성능을 보장해야 한다. 시험 절차로 대체한다. IaC나 오케스트레이터가 발달하여 이 부분이 편리해졌다.
• 유지보수 설계: 호환의 측면에서 컨테이너, 오케스트레이터가 생겨나 한결 편해졌다.
• 미적 설계: 정보 아키텍트. UX/UI적인 측면. 피그마나 오븐 같은 도구들이 도움이 되고 있다.

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

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

소프트웨어 개발을 하면서 위에 언급된 몇몇 항목들에 대해서 챙겨본 적이 있었지만 이렇게 종합적이고도 체계적으로 접근해본 적이 없다 싶다.

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

"성장하는 나를 만들려면 형식지에 속하는 프로그래밍 지식을 나만의 암묵지로 만들어야 합니다." 127p

 

여기서 말하는 형식지가 배워서 기억해두는 것이라면 암묵지는 자전거 타기와 같이 몸에 체화되는 것을 말한다.

 

"개구리를 해부하지 말고, 직접 만들어라" 129p 니콜라스 네그로폰테 박사

 

소프트웨어도 직접 만들어보아야 제대로 이해할 수 있다는 것이며, 형식지가 암묵지가 된다는 이야기이다.

 

"비교하는 대상을 다른 사람으로 향하지 말고, 스스로 내면을 향하도록 해야 합니다." 133p

"일희일비 하지 말고, 칭찬에는 겸손하고 비난에는 나를 돌아봅시다." 134p

 

항상 공감하는 말이다. 그럼에도 한 번씩 잊고는 한다. 되새기자.

5장. 이직, 분명한 이유가 필요해

흘러가는 대로 살아온 나에게는 가장 뼈 아픈 장이다. 항상 자신의 현재 상태를 메타인지하고, 바라는 다음 상태를 그려볼 수 있어야 한다. 그 현재의 인지나 미래상이 정확한지 최선인지보다 중요한 것은 꾸준히 그려보려는 노력이다.

 

"'환경의 변화'는 학습과 성장을 위한 효과적인 계기가 됩니다. 그리고 '이직'은 이러한 환경 변화 중 하나임을 부인할 수 없죠." 153p

 

컴포트 존에서 정체되어 한다거나, 의욕을 되살리기 힘들때에 이직과 그 결과로서의 환경변화는 확실히 의미있는 학습과 성장의 계기가 되었다.

 

"일을 하면서 주인의식을 가질 수 있는 길은 내가 만드는 제품의 의사결정에 참여하는 겁니다." 156p

 

삶의 목적을 다양하게 이야기하지만 결국은 권력의지이고, 의사결정이며, 존엄이다. 고리타분한 이야기로 들릴지 모르지만 주인의식을 가지고 일하는 것이 개개인의 성장에 중요하며, 회사가 주인의식을 가질 수 있도록 해주는 방법은 의사결정권을 나누어주는 것이겠다.

6장. 목표를 달성하는 나만의 기준, GPAM

항상 많이 배우는 박종천님의 글이다.

 

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

 

저자는 이를 GPAM이라 이름붙였다. 목표를 세우고 달성을 위한 계획을 짠 다음에 행동하고 그 결과를 측정하는 것의 반복. 너무나 단순하고 당연해 보이지만 닥치는 상황에 대해 이러한 프레임워크를 가져다가 적용하면 그 효과는 상당하리라.

 

여기에서 목표를 세우는 방법으로 S.M.A.R.T를 이야기한다. SMART에 대해서는 구글링을 해도 다양한 단어들의 조합이 나오는데(특히 A와 R) 여기 박종천님의 해석이 마음에 든다.

 

Specific: 구제척인 목표

Measurable: 측정이 가능해야 한다. 아내를 아껴주자(x), 매 달 쓰레기통을 10회 버려주자(o)

Actionable: 위와 통하는 부분이 있다. 행동할 수 있어야 한다.

Realistic: 현실적으로 가능한가?

Time-related: Time-bounded라는 표현이 나을 수 있겠다. 기한이 있어야 한다.

 

"목표는 S.M.A.R.T. 에 부합하도록 작게, 계획은 실천과 측정 가능하도록, 실천은 빠르게, 평가는 즉시, 그리고 앞선 단계에 그 결과를 반영하는 것이 GPAM입니다." 187p

 

이 한 줄을 이해하는 것은 어렵지 않다. 하지만 이를 오래도록 실천하는 것은 매우 어렵다.

7장. 프로덕트 중심주의

"제가 오랜 기간 동안 유지한 목표이자, 가장 기본이 되는 제1 원칙은 바로 '프로덕트에 집중하자'입니다." 191p

 

회사는 무언가를 만들어내어 돈을 벌어야 한다. 회사 활동의 모든 것은 프로덕트에 기반하여야 한다. 저자는 이러한 원칙을 기반으로 하여 반복, 디테일, 협업이라는 방법론을 이야기한다. 반복은 민첩한 애자일을 떠올리게 한다. 반복으로 요구사항을 만족하면 디테일에 집중해야 하는데 이를 위해서는 다시금 프로덕트 중심주의, 또는 프로덕트에 대한 주인정신, 집착이 필요하다.

8장. 제어할 수 없는 것에 의존하지 않기

"기준과 원칙에 따라 빠르게 결정을 내리면, 정말 중요한 설계와 선택이 필요할 때 더 깊게 사고할 수 있는 시간을 확보하고 사용하게 됩니다." 208p

 

올바른 원칙을 찾았다면 그것을 내 것으로 만들고 한결같이 적용해야 한다. 자포스의 토니 셰이의 책에서 저자는 포커가 생각보다 원칙만 따르면 승률이 보장된 게임으로 이야기한다. 그런데 왜 사람들은 돈을 잃는가? 사람들이 그 원칙을 깨기 때문이다.

 

"제가 가장 애정하는 원칙은 "제어할 수 없는 것에 의존하지 않기" 입니다." 210p

 

기도문이 떠올랐다. 저자가 말하는 바는 다음의 기도문과 뜻을 같이한다.

 

"하느님 저에게 허락하소서.

내가 바꾸지 못하는 것을 받아들이는 평정심과,

내가 바꿀 수 있는 것을 바꾸는 용기와,

늘 그 둘을 분별할 수 있는 지혜를"

9장. 달리는 기차의 바퀴를 갈아 끼우기

밥값에 대하여

 

"제약조건을 극복하고 제대로 동작하는 코드를 제때 만들어야 합니다." 231p

 

커뮤니케이션 능력이 부족하여 오해를 사기도 했지만 최근 주위에 비슷한 말을 했었다. 제약조건을 수집하는데 시간을 들이지 말자. 그 제약조건에도 불구하고 결과를 제때 만들어내어야 한다.

 

"어떤 코드가 더 좋은 코드일까요? (중략) 바로 가독성, 성능, 유연성입니다." 232p

"유연성이 있고 어려운 코드보다는 유연성이 없더라도 쉬운 코드가 더 좋은 코드입니다." 236p

"잘못된 추상화보다 중복이 낫다" 236p

 

기술 부채에 대하여

 

"언제나 발견했을 때보다 깨끗하게 해놓고 캠핑장을 떠나라" 238p

 

처음 작성할때 완전히 깨끗하게 만들면 좋겠지만 여러 상황과 제약사항으로 그렇지 못한 경우가 많다. 기술 부채가 생긴다. 이에 대해서는 위의 보이스카우트 캠핑 규칙이 그나마의 해법이라 생각한다. 새로이 기능을 변경하거나 오류를 수정하려 해당 코드를 다시 마주치면 이때 최대한 보이스카우트 캠핑 규칙을 적용하는 것이다.