📚 소프트웨어 장인 - 산드로 마쿠소를 읽고...

소프트웨어 장인이라는 책을 읽게 되었는데, 이전에 유명한 개발 서적 중 하나인 ‘클린 코드’를 읽었을 때와 나의 개발 경험이 많이 달라져서, 또 다른 시야로 개발 서적을 읽게 되어 인상 깊었던 부분이나 느낀 점을 기록해두고 싶어졌다.

---

애자일 방법론에 관하여

우선 이 책의 초반 부분에는 애자일 방법론에 대해 깊이 이야기한다.

애자일 방법론을 많이 들어보기도 했고, 공부하기도 했는데 이 책에서는 내가 생각하지 못했던 부분과 학교 수업에서 언급하지 않은 부분들을 언급한다.

요즈음 기업들이 일만 하는 값싼 코더가 아니라 프로페셔널 개발자를 원하고 있는 것은 애자일 방법론이 유행하면서이다.

라는 문구가 있다.

한 번도 애자일 방법론의 유행과 기업이 원하는 개발자를 연관지어 생각해 본 적은 없었는데, 생각해보니 빠르게 프로젝트를 완성하기 위해서는 단순한 코더가 아닌 생각할 수 있는 개발자가 필요하겠다는 생각을 하게 되었다.

고객들은 절차가 많고 계층 구조가 복잡한 관료적인 서비스 회사에서, 작지만 더 기민한 서비스를 제공하는 회사로 갈아타고 있다. 폭포수 모델을 전통적인 관리 형태와 결합하여 사용하면 오늘날처럼 빠르게 변하는 시장에 더는 대응할 수가 없다.

기조에는 섣부른 과잉 설계와 방대한 문서 작업, 관료체계에 의존했다면, 애자일에서는 프로젝트 시작 첫 주부터 동작하는 소프트웨어를 만든다.

라는 문구도 있는데, 옛날과 달라진 요즘의 개발 문화를 확실히 느낄 수 있었다.

---

소프트웨어장인정신 ? 공예 ?

그리고 글쓴이는 소프트웨어장인정신을 소개하면서 공예 작품을 빗대었다.

소프트웨어를 공예품으로, 개발자를 장인으로 표현한 것인데, 어떤 사람들은 사업, 엔지니어링, 과학이라고 하기도 한다고 한다.

소프트웨어 장인 정신이라는 용어 자체를 처음 들어보았는데, 공예, 사업, 엔지니어링, 과학 모두 적절한 비유이지만 작가와 비슷하게 공예라는 비유에 가장 공감이 간다. 나는 항상 개발을 하면서 진심으로 작품을 만든다는 생각을 해왔었다. 작품을 만들기 위해 어떻게 만들지 설계하고, 한땀한땀 코드를 짜고, 완성된 결과물을 보며 뿌듯해하는… 이 과정과 매 순간 느끼는 감정이 정말 공예와 유사하다고 생각하였다. 내가 항상 느끼던 감정을 ‘공예’라고 비유하니 ‘이거였구나!’ 하며 속이 뻥 뚫리는 느낌을 받았다.

---

그리고 로버트 마틴의 ‘클린코드: 애자일 소프트웨어 장인 정신을 위한 핸드북’이라는 책을 언급하는데, 역시 가장 유명한 개발 서적이구나 하는 생각이 들었고, 개발에 대한 시야가 달라진 지금 한번 더 읽어봐야겠다고 생각하였다.

다 읽으면 또 후기를 작성할 것이다. (언젠가 읽겠지…?)

---

프로답게 행동하기

또 인상 깊었던 부분이, ‘프로답게 행동하기’ 부분에서, 대안 제시라는 방법을 알려준다.

빠듯한 일정과 부딪히는 상황에서 개발자들은 보통 “노력하겠다”라고 이야기 한다. 그런데 이 말은 “그렇게 되게 하겠다’는 의미를 가지고 있을 수도 있고, 평소에는 일을 열심히 하지 않는다는 이야기로 전해질 수도 있다.

또, ‘안된다’, ‘할수없다’라는 부정적인 말을 꺼리기 때문에 ‘네’라고 대답하는 경향이 있는데, 이는 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이라고 언급한다.

이 줄을 읽고 일단 ‘네’라고 대답하고 보는 나의 인턴 생활을 되돌아보게 되었다. ‘네’라고 대답하고 기간 내에 완료하지 못했을 때 발생하는 일들이 얼마나 뒷감당이 힘든지 직접 느꼈기 때문에, 이 문장이 정말 와닿았던 것 같다.

‘네’라고 대답하는 것은 긍정적인 사고방식이라고 생각될 수 있지만, 실제로는 같이 일하는 사람을 실망시키고 싶지 않은 이기적인 욕구가 숨어있는 것

이라고도 이야기한다.

‘네’라는 말은 다른 팀, 상사, 고객들에게 약속한 것과 같다. 그렇기 때문에 개발자들은 협상 기술을 익힐 필요가 있다. 프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.

그렇기 때문에 무작정 ‘네’라고 대답하는 것은 좋지 않은 습관이다. 아니, 나쁜 습관이다.

그럼 상사가 무언가를 시켰을 때 나는 어떻게 해야할까?

이 질문에 대한 답이 바로 다음에 언급된다.

대신 모든 ‘아니오’에는 반드시 하나 이상의 대안들이 따라와야 한다

고 이야기한다.

항상 실용적인 대안을 찾아 낼 수 있는 것은 아니고, 최소한 브레인스토밍은 해보아야 한다고 언급한다.

예를들어, 한 상사가 오렌지 주스를 사오라고 지시했을 때, 어떤 부하직원은 5분만에 돌아와서 주스 가게에 들러 오렌지 주스가 있는지 물어봤지만 없다고 했다라고 바로 보고하고, 어떤 부하직원은 ‘오렌지 주스는 없었지만 파인애플 주스와 사과 주스는 있습니다. 파인애플 주스는 신선한 상태이지만 사과 주스는 병에 보관된 상태입니다. 주변 정보를 더 알아보니 좀 덜어진 곳에 큰 슈퍼마켓이 있습니다. 거기서 오렌지를 사면 오렌지 주스를 만들 수 있습니다. 다만 시간이 걸릴 것이고, 파인애플이나 사과 주스도 괜찮으면 5분안에 가져다 드릴 수 있습니다.’라고 답변했다.

위 상황에서 두번째 직원은 대안을 제시했고, 상사는 그 중 하나를 선택할 수 있었기에 ‘아니오’라고 답해야 하는 상황에서도 ‘네’라고 말할 방안을 탐색하고, 대안을 제시할 수 있어야 한다.

---

단위 테스트 작성의 중요성

그리고 공감되었던 것이, 단위 테스트 작성에 대한 내용이었다.

사실 그 전까지는 단위 테스트를 사용해본 적이 없어서 만약 이전에 이 책을 읽었다면 전혀 공감되지 않는 그저 글에 불과했겠지만, 단위 테스트를 경험해보고 난 뒤 이 부분을 읽으니 저자가 하는 말이 너무 공감되었다.

단순히 단위 테스트는 중요하다는 이야기만 하는 것이 아니라, 어떤 식으로 작성해야 하는지 등을 아주 잠깐 언급하는데 직접 단위 테스트를 해본 사람만이 이 부분을 매우 공감하며 읽을 수 있을 것 같다.

---

소프트웨어 장인이 되는 길

이후부터 본격적으로 좋은 개발자, 소프트웨어 장인이 어떤 사람인지에 대해 이야기한다.

기억하고 싶은 문구가 있었는데, 마리 엥겔브레이트와 요기 베라의 말이었다.

무언가가 마음에 들지 않는다면 바꾸어라. 그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라. - 마리 엥겔브레이트

마리 엥겔브레이트가 불평불만만 하지 말고, 바꾸려고 노력을 하라고 이야기 한 것인데, 개인적으로 뼈를 맞게(?) 되었다. 이 말을 통해 나를 되돌아보게 되었는데, ‘좋지 않은 상황에 대해 불평만 하고 그걸 핑계 삼아 회피하지 않았는가?’는 질문을 스스로에게 던져보았다. 이 질문에 대한 답을 생각하다보니 상황을 핑계로 회피한 기억들이 하나둘 떠올라서 부끄러워졌다.

어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다. - 요기 베라

그리고 다음은 요기 베라의 말이었다. 취업 준비를 앞두고, 내가 단순히 취업을 하고 싶었던 건지, 무엇을/왜 하고 싶은 것인지를 잠시 잊고 있었다는 생각이 들었다.

어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 내가 왜 개발자가 되고 싶었는지, 어떤 개발자가 되고 싶은지를 명확하게 다시 생각해보아야 할 것 같다.

12장에서는 개발자들의 낮은 사기 (동기)에 대해 이야기한다. 그러면서 개발자들이 회사가 조금 더 나아지기 위한 노력을 하지 않는 이유를 나열하였다.

자신에게 아무런 권한이 없다고 생각한다.

그런 일을 이끌어가야 할 당사자가 되고 싶지 않다.

그렇게 되기에는 복잡한 장애요인이 너무 많다.

뭔가 바뀌는 것이 가능하다고 믿지 않는다.

무엇이 더 나은 일인지 사람들의 동의를 받기 힘들다.

아무 상관 없다. 그냥 출퇴근만 하면 된다.

이 글을 보고 정말 부끄러웠다. 솔직히 인턴 생활을 하면서, 초반에는 정말 이렇게 생각했어서 딱히 내가 무언가 적극적으로 하지 않았었다. 물론 다니면서 이런 생각이 줄고 열정이 생기긴 했지만, 이런 생각을 잠시나마 해봤던 사람으로서, 이런 생각을 가지고 회사를 다니면 나에게 성장이 없을 뿐더러 회사를 다니는 것이 그다지 행복하지 않다. 이 책을 읽으면서 스스로를 돌아보는 일이 많았던 것 같다.

다음은 소프트웨어 장인에 대해서 본격적으로 이야기한다.

소프트웨어 장인은 고객에게 가치를 전달하고 자신을 둘러싼 사람들에게 영감을 불어 넣기 위해 모든 노력을 아끼지 않는다. 방향을 제시하고 변화를 이끄는 데 두려움이 없다. 여러 개발자들의 멘토로서 행동하는 데 주의를 기울인다. 항상 소프트웨어에 대해서 이야기하고 자신의 자기 계발 활동을 다른 사람들과 공유하려 한다.

이 문구를 읽고, 마지막 문장이 마음에 걸렸다. 스스로 생각하기에 나에게 가장 부족한 부분이 나의 자기 계발 활동을 다른 사람과 공유하는 것을 어려워한다는 것이기 때문이다. 이런 걸 공유하고 싶어도, ‘저 사람들은 굳이 궁금해하지 않으면 어떡하지?’, ‘별로 궁금해하지 않을 것 같은데.’하는 생각을 하면 계속 망설이게 된다.

이런 고민을 선배 개발자에게 털어놓았던 적이 있었는데,

‘공유하지 않는다고 나쁘거나 잘못된 것은 아니다. 하지만 네가 남들과 공유하길 원하는 거면 노력하면 되고, 굳이 원하지 않으면 그러지 않아도 된다.’

라고 들었던 적이 있다.

그런데 솔직히 나는 아직 잘 모르겠다. 내가 남들과 공유하고 싶은데 어려워하는 것인지, 그냥 굳이 공유를 하고 싶지 않고 필요성을 느끼지 못하는 것인지. 이 글을 쓰고 있는 지금도 사실 답을 찾지 못했다. 내가 어떤 마음가짐인지를 먼저 판단하고 노력을 하던지 하지 않던지 해야할 것 같다.

---

개발자의 동기 부여

개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다. 실력있는 개발자, 본받고 싶고 영감을 일으키는 개발자, 바로 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다.

이 부분을 읽으면서, 나도 이렇게 다른 개발자들에게 동기를 부여할 수 있는 개발자가 되어야겠다고 생각했다.

---

부당한 요구라면 거절할 수 있을까?

어느 유명한 투자 은행에서 저자가 일하던 컨설팅 회사에 일을 맡긴 기억을 공유한다.

고객사의 요구는 “우리의 레거시 코드 베이스에 단위 테스트를 역으로 끼워 맞춰 (현재 동작 상태가 올바르다고 가정하고 현재 상태대로 동작하는지 검증하는 테스트) 만들어 줄 개발자들이 필요하다”는 것이었다. 이상한 요구기는 했지만 고객사의 요구였기에 저자는 이게 맞는 과정인지도 모른채 요구사항을 충족시켜주었고, 한참 뒤에 그 프로젝트의 정체를 알게 된다. 바로 그 해에 고객사의 고위 기술 담당이 테스트 커버리지를 70%로 올리는 것을 팀 당해년도 목표로 설정했고, 팀의 보너스가 그 목표를 달성했느냐 여부에 다라서 달라지는 것이었다.

여기서 저자는 부도덕한 일을 했던 것이라고, 어떤 사람은 그 테스트를 믿고 시스템이 신뢰성이 있어 상용 릴리즈를 해도 된다고 판단할 수도 있다고, 그 고객사의 요구는 받아들이지 않았어야 했다고 언급하지만, 나는 이 에피소드를 읽으며 나는 과연 이런 상황에 처하면 어떻게 할 것인가를 생각해보게 되었다.

실제로 만약 내가 처음부터 이 고객사의 요구가 어떤 의미인지를 알고 있었더라도, 과연 나는 이 프로젝트는 못한다고 이야기 할 수 있었을까. 솔직히 이야기하지 못할 것 같아서 이 부분에 대해 한참을 생각하고 고민했다.

---

커뮤니티 활동

또, 13장에서는 배움의 문화를 만들라고 이야기한다. 예를 들면 북 클럽에 가입하기, 테크 런치 진행하기, 그룹 토론회에 참여하기, 업무 교환하기, 그룹 코드 리뷰하기, 내부 학습 모임을 만들기, 회사에서의 펫 프로젝트 시간 가지기, 외부 기술 커뮤니티와 교류하기 등 다양한 방식으로 배움의 문화를 조직 내에서 만들라고 이야기한다.

이 부분을 읽으면서, 나는 먼저 누군가에게 이런걸 같이 하자고 잘 이야기하지 못하는 편이기도 하고 해 본적도 많이 없는 것 같은데 책에서 말하는 것처럼 아무도 참여하지 않을 때를 걱정하지 말고 자신 있게 시도해볼 용기가 필요하겠다고 생각하였다.

다만 위에서 언급했던 것처럼 ‘저 사람들은 굳이 궁금해하지 않으면 어떡하지?’, ‘별로 궁금해하지 않을 것 같은데.’하는 생각에 계속 망설이는 편이라 ‘나에게는 용기를 내는 것이 정말 큰 용기겠구나’ 하고 생각했다.

---

논쟁하기

14장에서는 동료 개발자, 관리자, 기술 리더와 언성이 높아지는 논쟁을 두려워해서는 안 된다고 이야기한다. 의견 충돌이 없는 마음 편한 대화만을 기대할 수는 없다고, 싸울 준비가 되어 있어야 한다고 이야기한다.

돌이켜보니 어느 순간부터는 질문이나 제안을 할 때에도 한참을 고민하고 상대방의 마음을 헤아리느라 제대로 제안하지 못한 경우가 많다는 생각이 들었고, 내가 생각하는 내용이 어떤 것이든 말할 수 있는 용기를 키워야겠다고 생각하였다.

다만 조금은 웃기고 공감할 수 없었던 부분이, [상사를 설득하는 방법]에서 나의 상사를 어떻게 하면 설득할 수 있을까?에 대한 답은 ‘설득할 수 없다’라고 이야기한다. 용서를 구하는 것이 허락을 구하기보다 쉽다고, 그냥 가서 하고 싶은 것을 하면 된다고 이야기한다.

그런데 앞에서는 소프트웨어장인이 되기 위해서는 신뢰성을 키우라고 했으면서 이렇게 얘기하는 것을 보고.. 물론 이유가 다 있기는 했지만…. 이 책에 대한 믿음이나 현실 가능성에 대해 처음으로 고민해보게 되었다.

이전까지는 이 책을 그냥 물 흐르듯 공감하며 읽었다면, 처음으로 이 책을 비판적으로 읽어보았다.

이 부분까지 읽은 지금, 만약 다시 이 책을 읽는다면 솔직히 앞 부분도 조금은 비판적으로 읽게 될 것 같다는 생각이 든다.

---

단순한 설계를 위한 네 가지 원칙

이 책에서는 좋은 코드에 대해서는 많이 설명하지 않지만, 마지막에 이 네 가지 원칙을 언급한다.

기록해두면 좋을 것 같아서 첨부하였다.

단순한 설계를 위한 네 가지 원칙 by. 켄트 벡, J.B.레인스, 버거

1. 모든 테스트의 통과
2. 중복의 최소화
3. 명료성의 최대화
4. 구성요소의 최소화