소프트웨어 장인 by 산드로 만쿠소 share
[p.316] 나는 일을 선택하기 전에 아래와 같은 질문들을 스스로에게 던졌다.
- 나의 커리어로부터 나는 무엇을 원하는가?
- 그것을 성취하기 위한 다음 단계는 무엇인가?
- 이 일은 나의 커리어 방향과 합치하는가?
- 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
- 그러한 투자에 대한 이익은 무엇인가?
- 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
- 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?
- 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?
- 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치를 얻고 행복할 수 있나?
[p.308] 장인의 길
열정. 이 단어 하나가 모든 것을 요약한다. 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다. 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다. 그들의 코드를 공유하고, 초보 개발자들을 멘토링하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다. 기술 커뮤니티 활동에도 열정적이다. 뿐만 아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.
향후 10년 간 계속해서 소프트웨어에 대한 수요가 늘어나고 세상이 더욱 더 소프트웨어에 의존할 것임은 누구도 부정하기 어렵다. 그러한 수요에 대응하기 위해 소프트웨어 장인은 다음 세대의 장인을 키우는 데 사회적 의무감을 느껴야 한다. 그렇게 함으로써 소프트웨어 산업을 더욱 성숙하고 프로페셔널해지도록 만들어야 한다.
단순히 좋은 코드를 작성하고 비즈니스 가치를 전달하는 것만으로는 좋은 개발자는 될 수 있지만 장인은 될 수 없다. 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다. 항상 최고의 코드를 만들도록 다른 것들을 희생해서라도 계속해서 배우고 남을 도우리라는 각오를 하는 것이다. 소프트웨어 장인으로서의 삶은 아름다운 코드를 작성하기 위한 일생에 걸친 헌신과도 같다. 소프트웨어를 통해 가치를 창출할 수 있는 더 나은, 더 효과적인 방법을 찾는 끊임없는 노력의 길이다.
장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다. 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다. 특정 도구를 종교적으로 신봉하지는 않더라도 최선이라고 알려진 몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다. 마스터한 도구들이 없다면 장인이라고 할 수 없다.
진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는 데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는데 집중한다.
장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다. 엉망인 코드, 작성자 본인 외에는 아무도 이해할 수 없는 코드로 하여금 남아 있는 개발자들의 지탄을 받을 일을 만들지 않는다. 반대로 장인은 긍정적인 일들로 연상되는 존재여야한다. 통찰력 있는 기여, 열정, 지식, 훌륭한 동료로서 인정받는다면 더할나위 없다.
[p.324] 소프트웨어 장인과 소프트웨어 개발자
모든 장인은 개발자이지만 모든 개발자가 장인은 아니다. 많은 사람들의 생각과 상충되는 부분으로, 업무 연차나 보유 기술에 따라 장인이 되는 것도 아니다. 보통의 개발자와 장인의 차이점은 스스로 직업을 대하는 태도에 있다. 누구든 자기 자신을 장인이라고 부를 수는 있지만 그것만으로는 장인이 되었다고 할 수는 없다. 특정한 가치를 말하는 것과 그것을 실천하는 것은 완전히 별개의 이슈다. 추구하는 가치는 말이 아니라 행동에 의해 규정된다.
적은 수였지만 스스로를 장인이라고 부르길 원치 않는 개발자들도 만나볼 수 있었다. 그들은 뭔가 이름 붙이는 것 자체를 싫어했고 ‘장인정신 따위’에 신경을 쓰고 싶어 하지 않았다. 그럼에도 불구하고 그들이 소프트웨어 개발을 대하는 태도, 자신의 일에 대한 관심, 매일 같이 활용하는 실행 관례들, 자기계발을 위한 열정, 고객에 대한 존중은 분명 좋든 싫든 장인이라 부르기에 충분했다.
장인이 된다는 것은 다른 개발자들보다 우월하거나 더 낫다는 의미는 아니다. 누군가가 스스로를 장인이라고 부른다면 그가 추구하는 가치와 프로페셔널한 태도를 지칭하는 것이지 능력을 지칭하는 것이 아니다. 반대로 누군가가 스스로를 장인이라 하지 않는다고 해서 그가 장인이 추구하는 가치와 태도를 가지지 않았다는 의미도 아니다.
[저자서문] 장인을 찾아서, 그리고 장인이 되기 위한 긴 여정
첫 업무일은 월요일이었다. 그날 아침 나무르는 업무 할당에 대해서 이야기했다. 그는 내가 작업해야 할 애플리케이션의 한 부분에 대해 설명했고 금요일에 작업 결과를 같이 보자고 했다. 나는 흥분했다. 내 실력을 보일 절호의 기회였다. 내가 팀원으로서 자격이 있다는 것을 보여주고 싶었다. 그날 밤 12시가 다 되도록 사무실에 남아 있었고 몇 시간 밖에 자지 못했다. 화요일 아침 일찍 출근해 그날 오후 2시에 작업을 마쳤다. 주어진 시간의 절반도 안 되는 시간에 일을 끝낸 거이다. 정말 신이 났다. 물론 자신감이 있기는 했지만 바로 그 팀에서, 전혀 모르는 코드 베이스에서 작업한 것이었기 때문에 나로서는 아주 큰 성과였다. 흥분을 감추지 못하고 나무르의 사무실로 가서 “다 끝냈습니다. 동작도 합니다”라고 외치자, 그는 타이핑을 멈추고 나를 돌아봤다. “코딩이 직업인 사람이 동작하는 코드를 만드는 건 기본이에요.” 그는 조용히 말했다. “일을 끝냈다는 말에는 제대로 동작한다는 것이 당연히 포함되어 있죠.” 시비를 거는 듯한 말투였다. 내 얼굴에서 웃음기가 조금 사라졌지만 원래 그의 말투가 그런 걸로 치부했다. 어쩌면 오늘 그에게 다른 나쁜 일이 있었을지도 모르는 거였다. 절대 일부러 험악한 말을 하는 것은 아닐터였다. “여기 앉아서 작업한 코드를 같이 봅시다.” 나무르 옆에 앉았다. 그가 소스 컨트롤 시스템에서 내 작업 내용이 들어 있는 .pas 파일을 편집기에서 여는 것을 지켜 보았다. 검은 배경에 초록색 글자가 표시되는 끔찍스러운 커맨드 라인 편집기를 사용했다. 그때 vi(Unix의 문서 편집 툴)를 처음 보았다.
우리는 그 당시 매우 유명한 델파이 IDE를 사용하고 있었다. 델파이 IDE는 매우 강력하고 편리한 통합 개발환경을 제공했다. vi로 델파이 소스 코드를 열어보는 것은 정말 생경했다. “코드를 같이 볼 거니까 가까이 오세요.” 그가 말했다. 내가 작성한 코드는 200줄 남짓이었다. 나무르는 첫 번째 라인으로 커서를 옮기고 한줄 한줄 보기 시작했다. 다섯 줄마다 잠시 멈춰서 “여기서 메모리 할당/해제를 하면 무슨 일이 일어나는 지 알고 있나요? 이 부분을 보세요. 한 메서드에서 메모리를 할당하고 다른 메서드에서 해제하고 있어요. 이런 코드는 잠재적으로 메모리 릭을 일으켜요. 여기 이 코드를 보세요. 좀더 생각해보면 이 여덟 줄은 두 줄로 줄일 수 있어요. try/catch 블록이 이렇게 크면 어떤 일이 일어날 수 있는지 알고 있나요? 이 변수와 메서드의 이름은 적절해요? 원래 의도한 의미가 뭐죠? 다른 동료가 이 코드를 수정할 일이 생기면 어떻게 될까요? 정보도 부족하고 이 코드가 작성된 맥락을 전혀 알 수가 없어서요. 이 코드에 대한 전후 정보가 아무것도 없는 상태에서 당신이 이 코드를 유지보수해야 한다면 어떻겠습니까? 여기에 하드 코딩된 비트들은 뭐죠? 이 값들을 수정할 때마다 소스 코드를 열어서 수정하고 다시 컴파일하고 전체 애플리케이션을 재배포해야만 하나요? 왜 여기저기 똑같은 코드들이 있죠? 으음… 이 메서드는 너무 기네요. 메서드마다 이렇게 코드가 길면 코드를 해석할 때 머릿속에 한번에 담고 있어야 할 정보가 얼마나 많아지는지 알고 있어요? 좀더 단순하면서도 작게 만들고 동작 내용에 맞춰서 네이밍을 하면 어떨까요?” 그는 계속 말을 이어갔다.
어떤 부분에서는 잠깐 멈춰서 몇 줄의 코드를 가만히 살펴보기 시작했다. 몇 분 후, 커서를 한 페이지 위로, 또 다시 한 페이지 아래로 옮겼다. 1990년대에는 다른 사람이 알아볼 수 없는 난해한 코드를 짤 수 있는 사람이 실력있는 개발자로 통했다. “와우! 그는 똑똑한 개발자가 틀림없어. 그 사람 코드는 무엇을 하는 코드인지 전혀 감을 잡을 수가 없거든.” 나 역시 내가 얼마나 똑똑한지 보이려고 난해한 코드들을 조금 집어 넣었다. 나무르는 순간, 그 코드가 무엇을 하는지 알아냈다. 나는 내 기분을 띄워줄 말을 기대했다. “이 코드가 얼마나 무례한지 알고 있습니까?” 그는 조용히 말했다. “많은 팀과 개발자들이 같은 코드 베이스에서 아주 큰 시스템을 만들고 있습니다. 모든 개발자들이 이런 식으로 으스대려고 난해한 코드를 만들면 코드를 이해하기가 얼마나 어려워질지 생각해봤나요? 수천 라인, 아니 수백만 라인의 코드가 이런 식이라고 상상해보세요” 그의 말은 이제 시비가 아니라 공격이었다.
코드는 겨우 200라인 남짓이었다. 나무르가 제기한 문제들에 답을 하지도, 적당히 되받아치지도 못했다. 그는 코드 라인마다 문제를 지적했고 어덯게 하면 더 나아지는지 설명했다. 코드의 마지막에 이르렀을 때 얼굴이 화끈거리고 마음은 불편했다. 나무르는 제3자가 작성한 코드에 대해 말하는 것처럼 차분했다. “내가 한 말들을 다 이해했나요? 모두 동의합니까?” 나는 아무 말도 하지 않고 고개만 끄덕였다. “이 코드들을 더 나은 쪽으로 바꿀 수 있겠어요?” 그를 보지 않고 나는 고개만 끄덕였다. “오늘 이야기한 것들을 앞으로도 계속 적용할 수 있겠지요?” 다시 한번 고개를 끄덕였다. 그는 키보드를 몇 번 두드려서 내가 작성한 모든 코드가 들어 있는 파일을 삭제했다. “좋습니다. 아직 3일이나 남았으니 다시 해보세요.”
충격에 휩싸였다. 어떻게 반응해야 할지 몰랐다. 아무 말도 없이 천천히 일어서서 문쪽으로 걸어갔다. “산드로.” 문에 다다랐을 때 그가 나를 불렀다. 나는 멈춰서서 그를 돌아봤다. “일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다.” 이 말을 끝으로 나무르는 자신의 컴퓨터로 돌아앉아 그 끔찍한 검은 배경에 초록색 글자가 나오는 편집기에 다시 타이핑을 시작했다.
낙담했다. 아니 사실 화가 났다. 나무르의 사무실을 나와서는 바로 계단을 내려가 건물 밖으로 나왔다. 도대체 그가 뭐길래 나에게 이런 말을 할 수 있나? 형편없는 사람이다! 그런 사람을 위해서 일할 수는 없다. 이제 됐다. 이 회사와는 끝이다. 그만둘테다. 담배 몇 개비로 다음을 안정시킨 후 무슨 일이 일어난 건지 되새겨보았다. 나무르는 1시간 넘게 나의 코드를 보면서 어떻게 하면 더 나은 코드를 만들 수 있는지 설명했다. 어떤 부분에서는 내 의견을 경청했고 틀린 점과 더 개선할 수 있는 방법을 이야기했다. 코딩을 시작한 이후 처음으로, 내게 시간을 들여 좋은 코드를 만드는 방법을 보여 주는 사람을 찾았다는 사실을 깨달았다. 다른 사람들이 성장할 수 있도록 진심으로 도와주는, 나보다 더 나은, 훨씬 다양한 경험이 있는 누군가를 찾았다. 더 훌륭하고, 더 높은 품질의 소프트웨어를 만드는 데 가치를 두는 사람을 찾았다. 나를 가르치는 데 기꺼이 시간을 투자하는 사람을 만났다. 무엇보다도 나의 첫 번째 멘토를 찾았다.
몇 개비의 담배를 더 태우고 몸을 추스른 후, 나는 내적으로 다른 사람이 되었다. 그날 나는, 나 자신이 그렇게 잘난 사람이 아니라는 것과 배워야 할게 아직 많음을 알았다. 그리고 겸손해져야 한다는 것도. 일을 끝내는 것 자체로는 부족하다는 것, 그 일을 어떻게 하느냐가 더 중요하다는 것, 특히 팀에서 일할 때는 더욱 그러하다는 것을 배웠다. 나의 동료와 클라이언트를 존중하고, 형편없는 코드를 남겨서는 안된다는 것을 배웠다.