소프트웨어 장인

소프트웨어 장인은 로버트 C 마틴이 추천한 책이라고 한다. 이 책은 산드로 만쿠소의 개인적인 일화와 조언으로 채워져 있으며 소프트웨어 장인의 모습은 어떠해야 하는가에 대한 내용으로 구성되어있다.

1부: 이념과 태도

우리는 프로페셔널 개발자일까? 왜 애자일만으로는 부족할까?

1부는 애자일과 소프트웨어 장인정신에 대해 주로 설명한다. 소프트웨어 장인으로서 저자의 부끄러운 아픔과 나름의 성공을 간접적으로 경험할 수 있었다. 프로젝트 실패에 대해 개발자 본인의 프로페셔널하지 못했던 점에 대해 반성하는 모습이 인상깊었다. 저자는 실패를 통해 나아가고자 하는 의지를 발산하며 같은 실수를 반복하지 않는다는 느낌을 받았다.

많은 기업, 개발팀들이 애자일 전환 전에도 있던 문제들이 전환 후에도 여전하다. 여전히 과거의 기술적 부채에 허덕인다.

애자일을 도입하여 모든 절차를 뒤바꾸는 궁극적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다.

저자는 "많은 기업들이 표면적으로 애자일을 도입하려고 했지만 그 노력은 애자일스럽지 못했다." 라고 말한다. 가장 큰 원인으로 기술적 탁월함보다 절차가 더 중요해진 현실을 지적한다. 실행 관례에 대한 거부감 등 여러가지 다른 원인들도 소개한다. 나는 애자일에 대한 개념정도만 알고 애자일을 경험해보지 못해서 딱히 느껴지는 바는 없다. 다음 커리어의 여정에서는 애자일을 만나볼 수 있기를 기대한다.

애자일 방법론들은 기업의 반응속도를 높이고 기민하게 하며, 기업이 올바른 일을 하도록 돕는다.

소프트웨어 장신정신은 소프트웨어 개발에 있어서의 프로페셔널리즘이다. 소프트웨어 장인정신은 개발자로서 일을 더 잘하기 위해 가슴에 품는 일종의 이념이다. 소프트웨어 장인정신은 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.

위처럼 애자일과 장인정신의 차이를 언급하기도 하는데, 뭔가 말 장난 같다는 느낌을 받았다. 하지만, 각각의 메니페스토를 보면서 차이점을 확실히 이해했다.

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

이 책에서 한 가지만 알아야 한다면 이 문장을 기억하라고 저자는 말한다. 저자 주관으로는 소프트웨어 장신정신은 마스터가 되어가는 긴 여정이라고 한다. 개발자 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이라고 한다.

고객과의 파트너쉽

1부를 계속 읽다보면 고객과의 쌍방향 파트너쉽을 강조한다. SI에서 일하는 나는 고객을 만날 일이 거의 없다. SI 개발자들은 책에서 등장한 예시와 마찬가지로 방대한 양의 문서를 내려받고 문서에 의존하여 개발을 진행한다. 테스트를 작성하려고 해도 요구사항이 명확하지 않거나 혹은 시간이 없어서 (책에서는 핑계라고 하지만 조금 억울하다.) 작성하지 못한다. 결국, 코드를 수정할 때마다 수동으로 모든 테스트를 진행한다.

그렇게 만들어진 나쁜 코드는 계속해서 나쁜 코드를 생성하고 일정을 지연시키며 기업의 목표인 투자대비 이익을 감소시킨다. 프로젝트가 드랍되기도 한다. 이러한 SI의 현실에서도 쌍방향 파트너쉽이 가능할까? 이런 종류의 책들을 읽다보면 SI에서도 필수적이지만 현실상 도입할 수 없는 조언들이 많다는 생각이 든다.

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

책에서는 소프트웨어 장인이 되고싶은 개발자 본인이 변화를 주도하라고 한다. 하지만 나의 커리어 여정에서 SI는 제외되었다. 2년이면 충분히 경험했다고 생각한다. 개인적으로 다음 내용이 가장 인상깊었다.

내가 일하고 있는 회사에서 책을 사주지 않거나, 교육 프로그램이나 콘퍼런스에 전혀 보내주지 않는다면 어떻게 할 것인가? 우리가 새로운 것을 배우는 방법이 그것밖에 없을까? 이 때문에 그 회사는 나쁜 회사가 되는 것일까?

나는 좋은 회사라면 개발자가 업무 시간에도 역량을 키울 수 있는 시간을 의무적으로 제공해야 한다고 생각하고 있었다. 하지만 저자는 나에게 그 생각이 잘못되었다고 이야기한다.

자신이 일하는 회사가 새 지식을 가르쳐 주길 기대한다면 이는 프로페셔널 소프트웨어 개발자가 아니다. 개발자로 가장한 공장 노동자일 뿐이다.

이제는 기업이 직원에게 투자하는 일이 의무가 아닌 보너스나 상호 이득이 되는 배려임을 이해한다.

이외에도 1부에서는 개발자가 자기계발을 위해 할 수 있는 방법들, 아니오라고 말하는 방법, 커리어의 방향 등의 내용과 일화를 설명한다.

2부: 완전한 전환

2부에서는 주로 소프트웨어 장인정신의 커리어에 대해 설명한다. 회사 차원에서는 소프트웨어 장인을 채용하는 방법과 하지 말아야할 행동을, 면접자 차원에서는 회사가 개발자를 중요하게 생각하고 대우해주는 회사인지 파악하는 방법과 장인으로서의 마음가짐에 대한 내용을 확실하게 이해할 수 있다.

대학교를 졸업했을 때, 내가 생각하기에 나는 실력, 열정 등 모든 것이 평범했다. 같은 학교를 졸업한 학생들 중에서는 상위권이지만, 우물 안 개구리라는 것을 알고 있었기에 모험을 피하고자 상대적으로 입사하기가 편하다고 알려진 SI 회사에 지원했다. 중소기업 수준의 SI 회사에서 만큼은 잘하는 개발자라는 타이틀을 얻을 수 있을 것 같았고, 실제로 현재 사내 평판도 그렇다. 일종의 자기만족과 두려움으로부터의 도망을 위해 나는 소프트웨어 장인이 되기 위한 2년을 비효율적인 업무에 투자했다.

  • Github 계정
    • 계정이 있긴 하지만, 토이 프로젝트를 제외하고는 활동 없음
  • 블로그
    • 공부한 내용을 정리하는 블로그를 운영 중이며 전문적인 수준의 포스팅은 없음
  • 오픈 소스 활동
    • 회사에서 사용하는 paramquery에 이슈를 올리고 다른 이슈에 답변한 것 말고는 활동 없음
  • 기술 커뮤니티나 사용자 그룹 활동 내역
    • OKKY: 간간히 눈팅과 댓글
    • 스택오버플로우: 답변 3개가 끝
  • 펫 프로젝트 내용
    • 2019년 1월 첫 주 주말부터 vue pwa로 일정관리 프로그램 스터디를 진행할 예정
  • 트위터 계정
    • 있긴 하지만, 이력서를 관리하지는 않음
  • 좋아하는 기술서적 목록
    • 헤드퍼스트 디자인 패턴
    • 클린코드
    • 리펙토링
  • 참석했거나 발표했던 콘퍼런스
    • 없음

위 항목들은 저자가 생각하는 열정이 있는 개발자라면 해당사항이 있다고 생각하는 항목들과 해당 항목에 대한 나의 현황이다. 오픈 소스, 콘퍼런스, 커뮤니티 활동을 보완하면 열정을 강조할 수 있을 것 같다.

지금부터는 내가 흥미있게 읽은 부분들에 대해 적어본다. 먼저 잘못된 면접에 관련된 내용이다

지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보같은 면접 방법이다.

개발자 인터뷰에 관한 책이나 인터넷에 떠도는 글들에서 종이나 화이트보드 코딩은 메이저 기업에서 많이 요구하기 때문에 무조건 연습해야 한다고 한다. 그러나 나는 저자와 생각이 같다. 어째서 우리가 사용하는 도구들이 존재하지 않는 종이나 화이트보드로 코딩 능력을 테스트하는지 모르겠다. 정말로 종이에 코드를 작성하는 일이 중요한가?

다음은 개발자의 열정에 관련된 내용이다.

열정의 부재 자체가 열정적인 개발자들을 화나게 하는 것은 아니다. 열정적인 개발자들을 화나게 하는 것은 열정을 다해서 애플리케이션을 더 나아지게 하고 일하는 방식을 개선하려고 온갖 노력을 쏟는 동안 다른 개발자들이 그저 뒤에서 팔짱만 끼고 구경하거나 심지어 방해하는 것에 화가 날 뿐이다.

상당히 공감되는 부분이다. 나는 아직까지는 프로그래밍에 열정적인 사람이라고 장담할 수 있다. (가끔 2~3 달씩 슬럼프가 오긴한다.) 열정이 부족한 동료와 일한다는 것은 정말 고통이다. 그에게 프로젝트의 요구사항을 주입시키려면 같은 내용을 과장해서 10번은 알려줘야 했다. 물론 나는 그에게 동기를 부여하는데 충분한 노력을 가하지 않았고 배움의 문화를 형성하려고 노력하지 않았다는 사실에는 반성한다.

다음은 실용주의 장인정신에 관련된 내용이다.

당장의 합당한 이유 없이 단지 '미래를 대비해야 한다'는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 돤다.

품질은 비싼 것이 아니다. 스킬 부족이 잘 작성된 코드를 비싼 것으로 만드는 원인이다.

장인으로서 우리의 역할은 특별히 이슈가 되지 않을 정도까지 품질 비용을 낮추는 것이다.

그렇게 하기 위해서는 좋은 실행 관례들을 마스터하고 실용주의적인 입장을 취할 필요가 있다.

여기서도 다시 한번 반성하게 된다. 나는 과잉 설계나 과잉 엔지니어링을 잘 사용하고 디자인 패턴에 능한 개발자가 장인이라고 생각했다. 그러한 능력들만이 높은 품질과 유연성에 관련있다고 생각했다.

이제는 실용적인 관점에서 적시 설계를 통한 이득이 무엇인지 알고, 필요한 상황이 생겼을 때만 추상화를 도입하는 것이 유지보수 비용을 낮춤을 이해한다. 중요한 것은 단순한 설계와 SOLID 원칙에 따른 리펙토링이고, 그 다음이 필요에 따른 디자인 패턴의 도입임을 이해한다.

이외에도 2부에서는 바람직한 면접 방법들, 낮은 사기의 대가, 배움의 문화, 회의론과 회의론자를 대하는 방법, 열정을 불어넣는 방법, 상사를 설득하는 방법, 장인으로서의 커리어 등의 내용과 일화를 설명한다.

마치며

2017년 2월에 입사한 나는 소규모의 SI 업체에서 근무하고 있으며 이 책을 읽은 2019년을 기준으로 만 2년 차이고 아직 소프트웨어 장인이 아닌 새내기이다. 그럼에도 불구하고 이 책을 집어든 이유는 가상으로라도 소프트웨어 장인이 되고 싶어서였다.

내가 아는 장인의 모습은 "소설처럼 읽히는 프로그램" 을 작성하는 개발자가 전부였다. 처음에는 그냥 장인은 ~을 잘해야 한다와 같은 뻔한 내용들로 구성돼있을 거라고 생각했다. 그러한 생각은 로버트 마틴의 추천사를 읽는 순간부터 내가 겪은 2년 동안의 아픔이 위로받을 수 있을 거라는 기대감으로 바뀌었다.

실제로 책을 읽으면서 열정을 강조하고 열정적인 팀원들과 일했을 때의 일종의 성공 신화를 접하면서 더 잘하고 싶다는 열정을 얻었고, 회의론자들에게 열정을 불어넣으려고 노력했지만 실패한 일화들을 접하면서 공감대를 느꼈다.

마지막으로 이 책은 애자일, XP의 실행 관례들에 대한 개념을 정리하는데도 상당한 도움을 준다. 열정있는 개발자라면 개념을 정리하는데 도움을 줄 뿐만 아니라 철학과 커리어에 대해 고민해볼 수 있는 이 책을 읽어보길 추천한다.