"소프트웨어 장인"을 읽고 느낀점

 

 

일을 어떻게 했느냐는 일을 해낸 것만큼이나 중요하다.

이 책의 저자 서문에 나와있는 내용이다. 이 말은 저자가 본인의 직장 상사에게 들었던 말이라고 한다. 결과보다는 과정이 중요하다는 말과 일맥상통하는 것 같다. 한때는 과정보다는 결과만을 중요시했던 적이 있었다. 눈앞에 보이는 당장의 것만 해결하려고 했고, 그 과정은 중요하지 않은 채 결과를 위해 수단과 방법을 가리지 않았던 것 같았다. 좀 더 편하고 쉽게 하려고만 했으며 어려운 문제는 피하기 급급했다.

 

Chapter 1. 21세기 SW 개발

저자는 말하기를 아무리 본인이 어떤 한 가지의 프레임워크에 전문가라고 하더라도, 해당 분야에 대해서는 고참 개발자일지라도 다른 부분에서까지도 고참 개발자라고 말하기는 힘들다. 즉, 상대적임과 동시에 고참 개발자는 일시적인 것이다.

과거에 대단한 개발자의 실력의 척도로 본인만이 작성할 수 있고, 읽기 난해한 코드를 매우 잘 작성하는 사람이었다고 한다. 또한, 과거 소프트웨어 프로젝트를 할 때 각 담당자가 해야 할 일이 구체적이었으므로 개발자는 애플리케이션의 디자인이나 아키텍처 혹은 비즈니스 모델에 관여하지 않았다고 한다. 또한 최종 유저와 접촉할 일도 없었으며 마찬가지로 비즈니스 분석가들도 개발자는 비즈니스를 아예 모른다고 하였다.

이 부분에서 과거에 조직 생활을 상상해보면 개발자뿐만 아니라 다른 분야의 전문가들은 매우 고립되어있다는 느낌을 받았다. 하지만, 이후 저자는 21세기에는 소규모 소프트웨어가 엄청난 변화를 주고 있기 때문에, 개발자는 단순하게 코드만 잘 작성하는 사람이 아니라는 것을 알려주었다. 계속해서 더 나은 업무 방식을 고안해 내거나, 최종 유저와 소통하여 필요한 작업을 정의하는 등 매우 다양한 능력치가 있어야 좋은 개발자라고 정의하고 있었다.

저자는 개발팀에 속해있다가 아키텍처 팀으로 소속을 변경하게 되었다. 아키텍처 팀에서 그는 향후 미래에 발생할 문제들을 미리 예견하고, 코드를 작성하는 것보다는 다이어그램을 그린다고 했다. 그때 당시 아키텍처 팀은 개발자들의 우상이었을 만큼 대단한 팀이었고 모두가 가고 싶어 하는 그런 팀이었는데, 저자는 새로운 팀에서 하고 있는 일이 즐겁지가 않아서 다시 개발팀으로 돌아와 코드를 작성하는 것에 즐거움을 느끼는 것을 선택했다고 한다. 과연 나라면 저자처럼 다시 개발팀으로 돌아갔을까? 아니면 속해있는 팀에서 어떻게든 새로운 재미를 찾으려고 하였을까? 쉽게 결정하기 어려운데 저자의 선택이 정말 대단한 것 같다. 빠르게 다시 개발팀에 합류한 덕분에 코드 작성하는 감을 잃어버리지 않았다고 한다. 정말 코드는 꾸준하게 작성해보고 보고 또 보아야 그 감을 잃지 않는다는 것은 백번 천 번 맞는 말이다.

 

Chapter 2. 애자일

기술을 이해하지 못하는 사람들이 의사 결정을 하는 것은 프로젝트를 재앙으로 이끄는 지름길이다.

 

스타트업들이 많이 생겨나면서 애자일 하게 일하고 있다는 말을 많이 들어본 것 같다. 그렇다면 과연 애자일 하다는 것은 무엇일까 많이 궁금했다. 애자일이라는 단어가 많이 들어보아서 나도 익숙했지만, 실제로 정확하게 무슨 의미인지는 모르는 채 아는 척했던 것 같았다.

하지만 이 챕터를 읽게 되면서 애자일에 대한 의미를 분명히 알게 된 것 같았다. 애자일 하다는 것은 소프트웨어는 기본적으로 변화가 내재되어있고, 그 변화에 빠르고 민첩하게 대응하며 동작하는 소프트웨어를 짧게 몇 주 몇 달만에 만들어 피드백 루프를 짧게 한다는 의미였다.

하지만, 분명히 해야 하는 것은 애자일 하게 일을 한다고 해서 무조건 결과가 좋다는 것은 아니다.

애자일을 통해서 좋은 소프트웨어 결과물이 나오게 하기 위해서는 기본적으로 개발자가 기술적인 탁월함이 전제되어 있어야 한다!

그렇다면 챕터 1에서 인용한 문구의 모순이 있다고 생각할 수 도 있지만, 애자일에서는 절차와 결과물이 둘 다 중요하다는 것을 강조한다. 좋은 절차임에도 사용자에게 좋은 결과물이 전달되지 않거나 반대로 최고의 개발자들이 있더라도 그들이 제대로 일할 수 있는 절차가 없다면 소프트웨어 프로젝트가 절대로 성공할 수 없다.

여기서 중요한 점은 어떤 문제가 있고 인지하며 빠르게 대응하는 것이다.

 

이 책에서 소개하는 소프트웨어 장인 정신은 다음과 같다.

1. 소프트웨어 개발에 있어서의 프로페셔널리즘이다.

2. 소프트웨어 개발자로서 일을 더 잘하기 위해 가슴에 품는 일종의 이념이다.

3. 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다.

4. 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.

이번 챕터를 읽으면서 애자일 하게 일을 하려면 기본적으로 개발자의 기술적인 탁월함이 있어야 한다는 점에서 스스로 아직 많이 부족함을 느낄 수 있었다. 계속해서 꾸준하게 시야를 넓혀가며 나의 기술적 탁월함을 개선하도록 하면서 소프트웨어 장인 정신을 키워봐야겠다.

 

Chapter 3. 소프트웨어 장인 정신

이번 장에서는 소프트웨어 장인 정신에 대한 정의에 대해서 다루는 내용이었다.

그리고 과거에 수 많은 다양한 개발자들이 모여서 끊임없이 토론하고 이야기하면서 소프트웨어 장인 정신이란 도대체 무엇일까에 대한 이야기를 나누었다고 한다.

이 책에서는 소프트웨어 장인 정신에서 가장 중요한 것은 아래와 같이 소개하고 있다.

소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.

그리고 메니페스토에 대한 내용의 일부를 발췌해보려고 한다.

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,
변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,
개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,
고객과 협업하는 것뿐만 아니라, 생산적인 동잔바 관계를,

왼쪽의 항목들을 추구하는 과정에서 오른쪽 항목들이 꼭 필요함을 의미한다.

이후에는 좋은 소프트웨어란 무엇인가에 대한 내용을 다루는데 여기서 조금 공감 간 부분이 있었다.

테스트 코드도 없고 동작은 하지만 어떻게 동작하는지 아무도 모르는 오래된 애플리케이션이 있다고 했을 때, 가장 큰 문제점은 바로 두려움이다. 게다가 테스트 코드를 작성하는 것 자체도 쉽지가 않을 것이다.

좋은 소프트웨어라면 얼마나 오래되었는지 상관없이 수정함에 있어서 쉬워야 하고 개발자가 이해하기 쉬워야 한다. 또한 애플리케이션이 진화하려면 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안 된다.

이번 장을 읽으면서 이전 회사에서의 경험이 떠올랐다. 처음 마주하는 거대한 프로젝트 소스들을 보고 시간대별로 나오는 로그들만 주구장창 바라보면서 흐름을 이해하기 바빴고, 테스트 코드는커녕 줄 바꿈 조차도 두려워서 아무것도 할 수 없었다. 내가 조금만 바꿔도 그 부분이 어느 곳에 영향을 미칠지 생각조차 할 수 없었기 때문이다.

계속해서 요구사항이 추가되고 기능 개발이 이뤄지면서 애플리케이션의 몸집은 날로 커져가는데 애플리케이션의 구조에 대해서 관리를 해주지 않는다면 그것은 좋은 소프트웨어가 아니라고 생각한다.