소프트웨어 장인

책을 읽으면서 단순히 마음에 드는 내용들을 적었습니다.

---

소프트웨어 장인 - 산드로 만쿠소 지음

권오인 옮김

길벗

“오늘 정말 멋지게 일 했어” 라고 스스로 읖조리는 그런 프로그래머..가 될 수 있을까?

요즘 개발자들은 다음과 같은 여러가지를 할 수 있어야 한다.

• 고객과 대화하기
• 테스트/배포 자동화하기
• 전체 비즈니스에 영향을 미칠 기술 선정하기
• 지리적으로 분산된 팀들과 협업하기
• 고객을 도와 필요한 작업을 정의하기
• 우선순위 선정하기
• 진척 상황 보고하기
• 변경사항과 기대일정 관리하기
• 잠재 고객 및 파트너에게 제품 소개하기
• 사전 영업 활동 지원하기
• 개발 일정과 비용 산출하기
• 채용 면접하기
• 아키텍처 설계하기
• 비기능적 요구사항과 계약조건(SLAS) 검토하기
• 사업 목표 이해하기
• 주어진 여건에서 최적의 결정하기
• 새로운 기술 주시하기
• 더 나은 업무 방식 찾기
• 고객에게 가치 있는 상품이 전달되고 있는지 고민하기

그러면 소프트웨어 장인정신이란 무엇일까? 우리는 프로페셔널 소프트웨어 개발자일까? 왜 애자일만으로는 부족할까?

소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다. 소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

소프트웨어 장인정신은 시켜야만 일하는 역량 미달의 노동자가 아니라 소프트웨어 프로페셔널의 수준을 높여, 프로의 모습으로 일하는 소프트웨어 개발자를 지향힌다.

동작하는 소프트웨어뿐만 아니라, 정교하며 솜씨 있게 만들어진 작품을..

동작하는 소프트웨어라고 해서 잘 만들어진 애플리케이션이라고 할 수 있을까? 좋은 소프트웨어라면 그 애플리케이션이 얼마나 오래되었든 간에 개발자가 쉽게 이해할 수 있어야 한다. 소스 코드는 예측가능하고 유지보수될 수 있는 상태여야 한다. 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안된다.

변화에 대응하는 것뿐 아니라, 계속해서 가치를 더하는 것을

계속해서 가치를 더하는 것은 신규 기능을 추가하거나 버그 수정만을 말하는 것은 아니다. 코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고, 테스트 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것이다.

코드도 처음 발견했을 때보다 더 깨끗하게 관리해야 한다.

개별적으로 협력하는 것뿐만 아니라 프로페셔널 커뮤니티를 조성하는 것을

항상 열정적으로 자기발전을 추구한다. 그리고 다음 세대의 장인을 준비시킨다. 소프트웨어 장인은 항상 다른 사람에게 배우려 하는 겸손한 사람이어야 하고 경험이 적은 개발자와 지식을 공유하기를 주저하지 않는 사람이어야 한다. 나는 아직 누군가를 가르칠만한 실력이 아니지만, 이런 마음을 항상 가지고 있어야겠다.

고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

업무 우선순위를 정하고 계획하는 것을 돕는 일 또한 프로젝트의 성공을 위해 코딩만큼 중요한 일이다. 생산적인 동반자 관계는 어떤 순간이든 고객에게 가치를 제공하는 것을 의미한다.

예전 내 자소서를 보면 어떤 순간에서든 사용자 입장에서 생각하여 불편한 점이 무엇인지 고려하여 개발하겠다고 썼던 것 같다. 이 말도 여기서 말하는 생산적인 동반자 관계가 아닐까?

소프트웨어 장인정신은 소프트웨어 개발자의 프로페셔널리즘을 말한다. 항상 최선을 다하고 고객에게 좋은 서비스를 제공하려는 개발자에 관한 이야기다.

내 커리어의 주인은 누구인가

고객을 만족시키기 위한 투자는 스스로 해야 한다. 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 나 자신의 커리어의 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다.

끊임없는 훈련

일을 할 때의 방법은 그 실행 결과만큼이나 중요하다. 품질이 좋은 코드를 능숙하게 작성하고 싶다면 높은 품질의 코드를 작성하는 방법을 훈련해야 한다. 훈련 외에 다른 수단은 없다. 훈련을 할 때는 문제의 해결 자체가 아니라 해결에 사용한 테크닉에 집중해야 한다.

의도한 발견

모르는 것을 배우는 기회를 만들기 위해 항상 노력해야 한다. “내가 무엇을 모르는지 알지 못하는데 어떻게 그걸 배울 기회를 만들 수가 있나?” 라고 할 수 있다. 아무 동료나 붙잡고 최신 기술 동향을 따라가기 위해 어떤 노력을 하고 있는지 물어보자. 기술 커뮤니티나 사용자 그룹 이벤트에 참석할 수도 있다. 다른 사람에게 내가 작성한 코드를 보여주고, 특별히 도움이 필요하지 않더라도 코드에 잘못된 부분은 없는지 검토 요청을 해보자. 지금 하고있는 프로젝트에서 나와 내 동료들이 아직 시도하지 않은 부분, 더 알아보지 않은 부분이 무엇인지 찾아보고 그에 관해 토론하거나 코드를 작성해보자.

‘아니오’라고 말하는 방법 배우기

그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다. ‘안 된다’, ‘할 수 없다’ 라는 부정적인 말을 하길 꺼린다. ‘아니다’라고 말할 때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한 기분, 좋은 팀원이 되지 못한 듯한 기분이 든다. 우리는 같이 일하는 사람을 실망시키는 것을 가장 싫어한다.

이는 굉장히 이기적인 대처이다. ‘네’라고 말할 때 사람들은 그 말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억하자.

프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.

다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다. 정직하고 투명한 방법을 사용한다면 누군가 부당하게 피해를 입는 일은 없을 것이다.

‘아니오’라고 얘기 하면서 반드시 하나 이상의 대안들을 제시해주어야 한다. 대답하기 전에 문제를 분석해서 대안이 있어야 한다. 항상 실용적인 대안을 찾을 수 있는 것은 아니다. 그래도 최소한 브레인스토밍은 해보아야 한다.

일정 막바지에는 누가 제안한 해결책인지 따지지 말고, ‘문제 해결’에 집중해야 한다. - 범인찾기 하지말자

의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 ‘아니오’라고 답하는 것은 우리의 의무다.

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

테스트 먼저

아이디어를 생각 해내는 데도 도움이 되고 한 번에 하나씩만 집중할 수 있다. 모듈, 클래스, 함수를 구체적으로 정의하도록 강제하여 일을 점진적으로 진행할 수 있다. 피드백 루프가 상당히 빨라진다. 불필요하게 복잡해지거나 오버 엔지니어링을 하는 것을 줄여준다.

공식적인 작업 항목에 ‘단위 테스트 코드 작성’이라고 올릴 필요가 없다. 단위 테스트가 되지 않았다면 그 어떤 작업이건 간에 완료되었다고 말할 수 없다. 작업을 구현과 테스트로 나누어서는 안 된다. 한 시간은 서비스 클래스를 구현하고 다른 한 시간은 테스트를 작성하더라도 둘은 서로 독립된 작업이 아니다. 두 시간 분량의 한 가지 작업이다.

길고 긴 여정

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

스스로의 커리어를 가치있게 여기고 아끼고 보살펴야 한다. 커리어가 개인의 삶 전체에 이어지는 긴 여정이며 각자의 선택에 따라 마스터가 될 수 있음을 이해해야 한다. 어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 이것은 장기적인 목표이고 중간에 많은 것이 바뀔 수 있다.

어디로 가야 할지 모른다면.

모든 문들을 열어보기 시작해야 한다. 우리에게 기회가 나타날 수 있는 상황들을 만들어낼 필요가 있다. 밖으로 나가서 교류를 해야 한다. 세상이 나에게 접근할 수 있어야 한다. 직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다. 스스로를 낯선 환경에 노출 시켜서 새로운 것을 배우고, 일을 수행하는 다른 방법들을 알게 되는 것도 좋다.

커리어에서 옳고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다. 어떤 이유에서든 직장을 떠날 때 남는 것은 오로지 지식과 경험뿐이다.

우리의 커리어는 매우 긴 계단이고 특정 직업이나 직장은 한 계단에 지나지 않는다.

성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다.

생각해볼 것

1. 잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?
2. 소프트웨어 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까?
3. 잘못된 테스트는 아예 테스트가 없는 것보다 못하다.

배움의 문화 만들기

1. 북 클럽 가입하기
   1. 책을 하나 선택해서 동료들에게 그 책을 읽기 시작할 거라고 공표하자. 관심이 있으면 여유 시간에 모이자고 하자.
2. 테크 런치 진행하기
   1. 팀원들에게 일주일에 한 번 정도 점심 시간에 기술과 관련된 난상 토론회를 가지는 것을 제안해보자.
3. 그룹 토론회에 참여하기
4. 업무 교환하기 - 페어 바꾸기
   1. 기존 결정들에 대한 재검증
   2. 지식의 공유
   3. 개선
   4. 공동 학습
5. 얼마 동안만 업무 교환하기
6. 그룹 코드 리뷰 하기
   1. 리뷰에서 이루어진 결정에 책임감을 느끼고 어떤 것이 품질을 만들어내는지 되새기게 된다.
7. 내부 학습 모임을 만들기
8. 회사에서의 토이 프로젝트 시간을 허용하기
9. 외부 기술 커뮤니티와 교류하기

다른 사람을 설득하려면

1. 단순함을 추구해야 한다.
   1. 아이디어나 제안은 아주 명료하고 단순해야 한다. 누구든지 이해하기 쉽게 만들어야 한다.
   2. 가능하면 예제를 이용하는 것이 좋다.
2. 상대방의 언어로 말해야 한다.
3. 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다.
4. 상대방을 존중해야 한다.
5. 경청하는 법을 배운다.

실용주의

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

1. 모든 테스트를 통과해야 한다.
2. 명료하고, 충분히 표현되고, 일관되어야 한다. - 명료성의 최대화
3. 동작이나 설정에 중복이 있어서는 안 된다. - 중복의 최소화
4. 메서드, 클래스, 모듈의 수는 가능한 적어야 한다. - 구성요소의 최소화

당장의 합당한 이유 없이 단지 ‘미래를 대비해야 한다’는 모호한 전제로 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화를 적용해버린다. 애플리케이션이 진화 및 변경할 수 있도록 모든 가능성에 대비하는 것을 똑똑한 대응이라고 생각할 수도 있다. 진실은, 반대로 매우 바보같은 짓이다.

아직은 잘 모르겠다

특히 생각을 많이 한 부분이 테스트 관련한 부분과 ‘아니오’라고 말하는 방법 배우기, 내 커리어의 주인은 누구인가의 내용이다.

특히 ‘아니오’라고 말하는 방법 배우기는 현재 내가 느끼고 있는 감정을 표현하고 있는 것 같아서 공감이 되었다.

그 외에 면접이나 채용시에 어떤 태도를 가지고 기업의 입장에서 나와야 하는지, 이해는 되지만 현재 내 입장에서는 공감이 되지는 않는 부분들도 있었다.

책 내부에 소프트웨어 장인이라면, 기술적인 역량뿐만 아니라 주니어 개발자들을 위한 롤 모델 역할도 할 수 있어야 한다. 라는 부분이 있다. 내가 주니어 개발자 딱지를 떼고 언젠가 더 성장하게 된다면 이 책에서 말하는 소프트웨어 장인의 모습이 될 수 있을까? 그런 시기가 온다면 다시 한 번 이 책을 읽어봐야겠다.

사람이 이해하는 코드를 짜자.