[책] 소프트웨어 장인

 

소프트웨어 장인

OKKY라는 소프트웨어 개발자 커뮤니티에서 '소프트웨어 장인'이라는 책에 대해 좋게 평가하는 글을 보고, 나도 읽게 되었다. '소프트웨어 장인'은 산드로 만쿠소라는 저자가 쓴 책이다. 나는 아직 컴퓨터 공학에 관해 기초적인 부분을 배우고 있고, 실제 현업에서 일해본 적이 없다. 그런 나에게 이 책은 어떤 식으로 개발이 이뤄지는지, 이를 개선하기 위해 어떤 원칙 및 정신이 사용되는지에 대한 정보와 학습 모임, 단위 테스트(TDD) 등 활동을 알게 해 주었다. 책을 읽으면서 생각한 것과 해보고 싶은 것을 잊지 않기 위해 간단하게 이 글을 적는다.

애자일, 소프트웨어 장인정신

책 첫 부분은 애자일에 관한 얘기였다. 애자일에 관해서 생각해보기 전에, 나는 아직 현업의 큰 프로젝트에서 프로그래머로 일해본 적이 없기 때문에 크게 와 닿지는 않았다. 옛날 어떤 웹툰에서 본 걸 기억하여, 나는 애자일 방법론을 빠르게 필수적인 부분만 구현하여 작동하는 걸 확인한 후 전체 프로그램을 만든다?라는 식으로 알고 있었다. 책 내용을 읽으면서 애자일은 작동되는 시제품을, 빠르게 주기를 반복하면서, 프로그램의 사용자에게 제공해 피드백을 얻는 것이라는 걸 알게 되었다. 그것에 소프트웨어 개발자와 프로그램의 사용자 사이를 비즈니스에 가로막히면서 개발자들은 왜 그것이 필요한지 고민하지 않고, 개발만 한다는 배경이 있다는 걸 알게 되었다. 개발자가 비즈니스에 참가하면서 단순 코더가 되기보다 기능에 대해 고민하는 역할도 해야 한다는 걸 깨달았다.

소프트웨어 장인정신이 정확히 무엇인지 적혀 있었는지는 기억나지 않지만, 프로그래머는 단순히 구현에 머무르지 말고 소스코드에 주인 정신을 가지고 좋은 코드(+ 주석)를 짜야한다 라는 말로 알아들었다. 소프트웨어 장인정신에 대해 읽으면서 내가 앱을 만들면서 짰던 코드가 계속 생각났다. 어쩌면 지금까지 내가 짠 코드는 완전히 구현에만 집중하고 있던 것은 아닐까? 맞는 것 같다. 앞으로는 남들이 봐도 좋아할 코드를 짜고, 지금까지 만든 것들도 리펙토링 하고, 주석을 달며 연습해야겠다.

소프트웨어 장인의 태도, 배움의 문화

4장에서는 소프트웨어 개발자가 가져야 할 태도에 관한 내용이었다. 그 내용이 얘기하는 것은 공부할 시간이 없다며 핑계하지 말고, 자기계발에 임해야 한다는 것이다. 기술 웹사이트, 소셜미디어, 블로그 그리고 커뮤니티 등 다른 개발자들과 소통, 소프트웨어 '카다', 토이 프로젝트, 오픈 소스 기여 등 많은 키워드가 기억난다. 페어 프로그래밍에 대한 얘기도 있었는데, 두 사람이 한 화면을 보면서 서로의 코드를 본다는 게 어색할 것 같기는 하지만, 옆에서 내 부족한 점을 알려준다면 정말 내 실력이 늘겠다고 느꼈다. 아직 직장에 일해본 적이 없어 모르겠지만, 실제로 사수와 신입이 할 것 같은 느낌이다.

13장에서는 배움의 문화에 대해 논하였다. 내부 학습 모임을 만들면 좋다는 내용이 기억에 남았는데, 일주일에 한번 시간을 정해놓고 서로서로 배운 것을 공유하는 시간을 가지라는 것이었다. "아무도 참여하지 않는다면"이란 소주제에서는 다른 구성원들이 학습 모임에 참가하려 하지 않을 때에 대해 다루었는데, 나는 남을 설득하는 능력이 매우 부족하다고 생각하기 때문에 이 내용이 정말 도움이 될 것 같다.

• 설득력을 갖출 수 있도록 신뢰감을 갖춘 사람되기.
• 관심 있는 사람들끼리 잘 이끌어가면 다른 사람도 따라온다.
• 사람의 수 늘리기보다 내용의 질에 집중하기
• 남들에 강제하기 말기
• 시간을 무슨 요일 몇 시로 고정하면 일정 조율이 필요 없다.

이번 학기는 늦은 감이 있고, 다음 학기부터는 군 휴학을 하기 때문에 기회가 없지만, 복학한 후 기회가 된다면 우리 학과나 동아리에서도 학습 모임을 만들어봐야겠다고 느꼈다. 평소에 나서는 사람이 아니라서 용기를 낼 수 있을지 고민되지만, 역량을 늘리는 데는 큰 도움이 될 것 같다.

'아니오'라고 말하는 법

개발자는 잘못된 지시, 불가능한 일정에는 '아니오'라고 말할 수 있어야 한다. 단, 그 말을 할 때는 상대방의 입장에서 이유를 설명(Ex. 소스코드의 개선이 필요하다 -> 제품의 품질에 문제가 생길 수 있기에 시간이 필요하다)하고, 대안을 제시할 수 있어야 한다. 무조건적인 '아니오'는 안된다.

단위 테스트

단위 테스트는 개별적인 코드 단위가 정상적으로 동작하는지 시험하는 것이라 한다. 프로그램의 일부분을 만들었을 때, 전체 프로그램 없이도 만든 부분을 테스트하고, 프로그램의 유지보수 및 기능 추가로 수정하였을 때, 정상 작동을 확인하는 것 같다. 프레임워크를 사용하여 이런 행위를 대신해주는 코드를 짜는 것은 개발 시간을 지체시킬까? 전체적으로 보면 단위 테스트 코드를 만드는 것이 이득이라고 한다. 물론 잘못된 테스트가 작성되고, 수정되지 않으면 걸림돌이 되겠지만, 저자는 단위 테스트 작성은 개발자의 업무 시간에 들어있는 행위라고 주장한다.

나는 사실 단위 테스트를 사용해본 적이 없다. 잘 생각해보니 Visual Studio로 빌드할 때 그런 게 있기는 했던 것 같다. 플랫폼에 따라서 단위 테스트를 어떻게 작성하는지 공부해봐야겠다. 앞에서 내가 만든 앱의 특정 부분을 리펙토링 해야겠다고 느꼈는데, 당장 여기서 리펙토링 전과 리펙토링 후가 동일하게 동작하는지 확인할 때 사용해야겠다. 어쩌면 그 내용은 이 블로그에 올릴지도 모른다.

낮은 사기의 대가

나와 같이 일하는 사람이 일에 대한 사기가 낮다면 어떨까? 업무 하나하나가 고될 거 같다. 짧은 경험이지만 대학교 입학 전에 했던 동아리 활동 기억이 났다. 낮은 사기는 좋지 않은 결과물을 만들어 낸다고 한다. 저자도 이에 대한 명확한 해결책을 내놓지는 않았지만, 다른 사람을 열정을 갖고 일하도록 설득하는 능력이 중요하지 않은가 생각한다.

이렇게 보니 소프트웨어 개발자로서 일하는데(어쩌면 생애 전체가?) 다른 사람을 설득하는 능력은 중요한 것 같다. 그 능력은 어떻게 기를 수 있는지 막막하지만, 남들과 얘기하다 보면 알 수 있지 않을까 생각한다. 그런 생각에서 남들과 소통하는 능력을 길러야겠다.