소프트웨어 장인: 프로페셔널리즘, 실용주의, 자부심

April 19, 2020 · 9 mins to read

어느날 뜬금없이 백엔드팀의 정경업 (opens new window)님께서 이 책을 읽어보았냐고 지나가듯 물어보셨다. 그 물음에 아니라고 대답을 했는데, “당신이라면 당연히 읽었을 줄 알았다.”라는 다소 묘한 답을 들었다. 어느날, 내가 당연히 읽었을 것 같은 그 책이 무엇일까 궁금해졌다. “읽어보면 좋아할거다.”라는 마지막 말도 이 책을 망설임 없이 구매하게 된 이유다. 평소 개발자, 팀, 코드에 대한 이야기를 많이 하시는데, 저러한 주관을 갖게 되기까지 어떤 수련을 해야하는지가 궁금하기도 했고 말이다.

산드로 만쿠소 아저씨는 책의 초반부에 애자일을 소개하고 실천하는 방법에 대해 설명한다. ‘애자일하다는 것이 무슨 뜻이냐?‘라고 묻는 사람들에게 자신있게 설명해 줄 정도로 그것을 잘 알지는 못한다. 다만 회사의 동료를 통해 간접경험을 했을 뿐이다. 사실 팀의 동료중에 형식적인 애자일에 고통받다 오신분이 있는데, 경험담을 듣다보면 저절로 혀를 차게될 정도였다. 바뀌는 것이 없는 형식적인 스크럼, 상급자의 뜻대로 흘러가는 페어 프로그래밍 등 애자일에 대해 부정적인 생각을 가질 수 밖에 없게끔 만드는 나쁜 경험담이었다.

하지만 반대로 생각해보면, 이런 방법들이 형식적이지 않게만 돌아간다면 꽤나 괜찮을 것 같다는 생각이 들었다.

1. 기억에 남는 부분들

1. 동작하는 소프트웨어 만으로 괜찮은가?

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다.

팀 동료였던 김승호 (opens new window)님의 추천으로 the nature of software development (opens new window)라는 책을 읽고 흥미로운 사실을 깨닫게 되었는데, 바로 작은 단위의 동작하는 소프트웨어에 대한 것이다. 비즈니스 요구사항이 급변할수도 있고, 처음부터 거대한 프로그램을 설계할 수도 없으니 작은 단위의 동작하는 소프트웨어를 빠르게 업데이트하여 배포하자는 내용이 주요 골자였던 것으로 기억한다.

몇 달 전, 토이프로젝트를 하면서 테스트코드를 넣지 않고 빠르게 만드는 것에만 집중했었다. 그렇게 만든 프로그램이 일단은 잘 동작하였기 때문에 배포를 진행하였다. Github issue에 다음으로 진행할 업데이트 목록을 만들었고, 스스로 뿌듯해 했다. 문제는 시간이 지나 터졌는데, 복잡한 로직을 업데이트 해야했을 때 테스트코드가 없었기 때문에 오히려 시간이 더 걸리고 말았다. 결국 초반 몇 번의 이슈를 처리하는 것만 빨랐고 뒤로 갈수록 시간이 오래 걸릴수 밖에 없는 기술부채를 스스로 만든 것이다.

산드로 만쿠소 아저씨는 동작하는 소프트웨어를 만드는 것 만으로는 충분하지 않고, 동작하면서도 깨끗한 소프트웨어를 만드는 것을 강조하고 있다. 아마 <the nature of software development>에서도 강조한 내용이었겠지만, 스스로 알고 싶은 것만 취사선택 했을 것이다 듣고 싶은 것만 듣는 못된 버릇. 동작만 하는 소프트웨어는 기술부채라는 것이 필연적으로 쌓이게되고, 이러한 것들을 개선하지 않으면 어느 순간 사용자들의 요구에 기민하게 대응하지 못하게 된다 (회사의 오래된 프로젝트 하나가 떠오른다). 그렇기 때문에 (쉽지는 않겠지만) 소프트웨어를 항상 깨끗하게 유지하려고 노력을 해야하고, 개선이 필요한 부분에 대한 수정을 미루지 말아야 할 것 같다.

2. 나에게 필요한 수련들

자신이 하는 일에 프로페셔널하게 행동하고, 고객이 원하는 것은 무엇이든 달성할 수 있도록 돕는다. 다른 개발자들에게 배우고 자신의 지식을 나누며, 경험이 부족한 개발자들을 멘토링 하는 것이다.

책에서 말하는 소프트웨어 장인의 이상적인 모습을 한치의 오차도 없이 달성하기란 쉽지 않아 보인다. 하지만 그분 2가 늘 말하듯 긴 시간을 담금질 하며 저 목표들을 향해 달려갈 가치는 충분히 있을 것 같다. 이것에 대하여 산드로 만쿠소 아저씨가 말했던 몇가지 방법중 인상깊었던 것들이 몇 가지 있다. 앞으로 이것들을 꾸준히 수련하고 유지하기 위해 노력하면 좋을 것 같다.

독서, 토이프로젝트

펫 프로젝트는 매우 안전한 환경에서 시험하고, 발견하고, 배우고, 즐길 수 있는 기회를 만든다.

말해서 무엇하나, 싶은 주제이다. 개발을 처음 시작했을 때부터 그분들이 토이프로젝트의 중요성을 상당히 강조했었기 때문에, 나는 토이프로젝트를 진행하는 것을 자연스럽게 받아들이고 있다. 예전과 바뀐것이 있다면, 조금 진행하고 끝내버리지 않고 어찌되었든 결과물을 만들어 내는 것을 목표로 하고있다. 결과물은 배포한 작은 프로그램이 될 수도 있고, 블로그의 글이 될 수도 있다. 요새는 주로 배포를 하기 위해 많이 노력하고 있다.

독서 역시 마찬가지이다. 개발에 대한 책이라면 일단 가리지 않고 읽고 있는데, 최근에는 문화나 개발자의 행동양식에 대한 책을 많이 읽고 있다. 또한, 옆자리 동료의 영향으로 개발 외적인 분야의 좋은 책도 읽으려고 노력하고 있다. 결국 개발자도 세상의 문제를 해결하는데 기여를 해야하기 때문이다.

이 두 가지의 활동은 짧지만 3년정도의 개발자 생활을 하면서 덕을 많이 보았기 때문에 주변 사람들에게도 개인적으로 많이 추천하고 있는 것들이다.

커뮤니티 활동

새로운 사람들을 만나고 의견을 주고받는 것 만으로도 많은 것을 배우거나 나눠줄 수 있다. 너무나 잘 알고있는 사실이지만 그동안 실천하지 못했다. 개인적인 성향탓인지 모르는 사람들이 많은 자리에 가면 아무 이유없이 불편하고, 무언가 무시를 당할까봐 입을 다물고 있는 편이다. 매년 목표는 커뮤니티 활동을 하는 것인데, 자꾸 주저하게 되는 원인이다.

하지만 올해부터는 용기를 내 볼 생각이다. 컨퍼런스에 가서 참가자들 혹은 발표자들과 이야기를 먼저 나누어보고, 그들의 경험에서 교훈을 찾을 것이다. 반대로, 내가 그들에게 도움이 될 수 있는것이 있다면 적극적으로 나눌 생각이다.

실용주의

누군가가 이야기했기 때문에, 또는 그 실행 관례 도입을 위한 도입을 해서는 안된다. 우리는 지속적으로 일하는 더 나은 방법을 찾고 고객을 만족시켜야 한다.

작년 DevC Seoul에서 발표했을 때, 같이 발표했던 진겸 (opens new window)님의 말씀중에 굉장히 공감이 되는 부분이 있었다. 사람들은 어차피 우리가 함수형 프로그래밍으로 구현했든, rxjs를 썼든, TDD를 했든 아무 관심도 없다. 그들은 그저 좋은 서비스를 원한다.는 말이다. 결국 역설적으로, 우리의 모든 행동들은 좋은 서비스를 만들기 위한 목표를 가져야한다는 뜻이다. TDD나 애자일을 도입하는것도 결국 우리가 더 좋은 서비스를 만들어야하고, 그러기 위해서 현재 안고있는 문제를 해결할 수 있다는 확신이 있을 때 도입해야한다는 것이다.

지난날의 모습을 돌이켜보면, 이 책에서 이야기하는 실용주의와는 거리가 있는 일을 많이 했던 것 같다. 리팩토링을 위한 리팩토링, 최적화를 위한 최적화 등등. 그 작업들이 전부 쓸모가 없었다는 말은 아니지만, 사실 정말 필요했을때 그 작업을 하고 남는 시간을 다른곳에 돌렸으면 조금 더 많은 것들을 할 수 있었을 것 같다.

다른 것들도 마찬가지다. 아무것도 몰랐을때는 그저 ‘우리팀도 TDD 해봐요’ 라고 철없는 말을 많이 했었다 그분 1이 살려둔것이 다행이다. 이유는 간단했다. 다른 힙한 스타트업에서 하고 있으니까. 당연한 이야기지만 근거가 부족한 내 이야기는 먹혀들지 않았고, 그것에 대해 딱히 생각해 본적도 없었다. 그저 내 건의를 들었던 상대가 고리타분하다고 생각했다. 하지만 조금씩 경험이 쌓이고, 이 책을 읽어보니 애초에 말도 안되는 말이었다는 것을 느꼈다.

프로페셔널한 개발자라면, 한가지 기술이나 생각에 얽매이지 말고 언제나 필요에 의해 방법을 선택해야한다. 회사의 비즈니스를 도와야하고, 품질은 선택사항이 아니라는 마음가짐으로 개발을 해야한다. 그렇기 때문에, 산드로 만쿠소 아저씨가 실용주의 없는 장인정신은 장인정신이 아니다 라고 말한 것 같다.

3. 동료와, 상사와, 회사와, 고객과 일하기

“아니오”라고 말하는 방법 배우기

이미 불가능하다고 알고 있는 것에 대해 ‘해보겠다’라고 말하지 말았어야 했다. (…) 우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 ‘아니오’라고 말할 수 있어야 했다.

나는 누군가가 제일 자신없는것이 무엇이냐고 물어보면 일정산정이라고 대답한다. 그만큼 내 생산성이 꾸준하지 않은 탓도있고, 아직 감이 잡히지 않은 탓도 있다. 오죽하면 같이 일하던 시니어 개발자분이 ‘지금 당신 머릿속에 떠오른 날짜에 3을 곱해보세요.’ 라고 하셨을까.

생각해보니, 이 책에 써있는대로 무언가 영웅심리에 취해있던 것 같다. 짧은 기간안에 요구사항을 만족시키는 것을 만들어 내는게 멋진 일이라 생각했고, 다소 힘들어 보이는 요구도 무조건 OK했다. 이런식으로 일을 진행하다보니 당연히 몸은 힘들지만 요구사항이 충족되지 않았고, 결국 기한을 미루거나 스펙을 축소해야 했다. 스스로 ‘거짓말쟁이’가 된 것이다.

결국 ‘아니오’라고 말하는 법을 배워야한다는 말에 크게 공감하는 이유는, 비즈니스 담당자들이 적절한 계획을 세울 수 있게 도와주고 서비스를 단단하게 만들어야 하기 때문이다. 산드로 만쿠소 아저씨는 대신 정말 중요한 말을 덧붙였는데, ‘아니오’라고 말할때에는 적절한 대안이 있어야한다는 것이다. 특히 개발자들은 서비스를 직접 만들고 있기 때문에 가장 현실적인 제안을 할 수 있는 위치에 있다. 그동안으로 경험으로 보았을 때 그저 안된다고만 하면 같이 일하기 싫은, 답답한 거절쟁이가 될 수도 있다.

동료에게 좋은 영향 주기

책에 직접적으로 이런 이야기는 없었지만, 여러 사례들이나 예시들을 보았을때 좋은 개발자들은 언제나 주변에 좋은 영향을 주는 것같다. 그것은 평소의 행동, 작성하는 코드, 코드 리뷰, 페어 프로그래밍, 회의 등등 여러 소스를 통해 발산된다. 스터디를 계획하여 적극적으로 참여를 유도하게 할 수도 있고, 책을 추천해 주는것도 해당된다. 우리회사의 문화중 하나인 LTE(Lighting Talk of Engineer)도 포함된다고 생각한다.

최근 그분 2의 Q1 피드백을 통해 고민이 늘었는데, 나 뿐만 아니라 팀을 위한 고민을 해줬으면 좋겠다는 말을 들은 탓이다. 사실 이 부분도 조금씩 연습해야겠다고 생각했기 때문에 꽤나 적절했던 피드백이었다고 생각한다 드디어 관심법도 쓰신다. 사실 최근 새로 들어오신 분들과 페어 프로그래밍이나 코드 리뷰를 하면서 더 큰 책임감이 생겼다. 내가 아무 생각없이 한 말, 크게 고민하지 않고 쓴 코드 등 내 패턴들을 고스란히 따라하는 것을 보았기 때문이다.

결국 산드로 만쿠소 아저씨의 말마따나, 좋은 동료를 원하기 전에 내가 먼저 좋은 사람이 되어야하는 것 같다. 너무 극단적인 생각에 빠지지않고, 수련을 거듭하다보면 언젠가 좋은 동료로 인정받는 날이 올거라 생각한다.

2. 최근의 나는 어땠는가

에도 썼지만, 연봉통보 기간 동안 멘탈이 나가버려 팀에 아무 기여도 못한것이 마음에 걸린다. 30살이 넘어서도 아직도 애처럼 행동하고 있다니. 더군다나 최근 받은 동료의 피드백중에 ‘연봉통보 기간동안 리뷰를 안해주셔서 아쉬웠다’가 있어, 더욱 후회가 된다. 개발자도 사람인지라 감정에 아예 휘둘리지 않을 수는 없겠지만, 100번을 생각해봐도 프로페셔널 하지 않았다고 생각한다.

팀에서는 주로 PoC와 관련한 업무를 맡아서 진행하고 있는데, 먼저 만들어보고 팀원들에게 전파하는 재미가 있었다. 그분 2가 상관없다고 한다면 조만간 PoC한 프로젝트에 대해 글을 쓸 생각인데, 팀원들에게 PoC한 내용을 전파한 일도 포함할 생각이다. PoC 프로젝트는 그 정도로 재밌게 했다 덕분에 frontend쪽 코드는 얼마 못봤다. 큰 의미가 있던 것은 PoC 프로젝트를 진행하면서 여러사람들의 의견을 들을 수 있었고, 옆자리 동료 (opens new window)와 페어 프로그래밍을 하면서 초기 세팅에 많은 도움을 받을 수 있었다는 것이다.

또한, 최근 회사의 JIRA board에서 리팩토링과 관련한 티켓들 중 몇개를 close 처리 했다. 당장 진행할 필요가 없었고, 리팩토링을 위한 리팩토링이라는 생각이 들었기 때문이다.

3. 무엇을 해볼 것인가

1. XP?

산드로 만쿠소 아저씨는 이 책의 처음부터 끝까지 세 단어를 반복한다. 애자일, 린 스타트업 그리고 XP(eXtreme Programming)이다. 사실 XP는 이야기만 들어보았지, 제대로 알아보려고 한 적이 없었다. 그저 빠르게 변하는 요구사항에 맞춰 기민하게 대응할 수 있는 방법론 정도로만 알고있는 수준이다. 하지만 책을 읽으며 계속 이 단어가 반복되자, 산드로 만쿠소 아저씨가 강조하는 XP가 무엇인지 궁금해졌다. 그래서 XP에 대한 책을 한 권 구매했고 바로 읽어볼 생각이다.

2. 팀 문화에 대한 고민

위의 XP에 대한 고민과 연결되는 고민인데, 그분 2를 포함한 팀원들과 팀의 퍼포먼스에 대해 논의해 볼 생각이다. 만약 그때, XP를 도입하면 좋을것 같은 진단이 나온다면, 적극적으로 나서서 도입해 볼 생각이다. 만약 XP가 팀에 필요없다면? 당연히 XP에 미련을 가질 필요가 없을 것이다. 대신 토이프로젝트를 할 때 적극적으로 실천해 볼 것 같다.

3. 소프트웨어 장인을 향한 여정을 준비

그동안 스스로가 모호하게만 행동했다고 생각한다. 그리고 늘 ‘나는 주니어니까’라는 생각에 갖혀 자신의 한계를 결정지은 것 같다. 이제는 더 이상 주니어가 아니기도하고, 언제까지 그러한 자기보호의 울타리 아래 놓여있을 수는 없다고 생각한다. 산드로 만쿠소 아저씨가, 그분들이 이야기하듯 수없는 담금질과 수련을 본격적으로 해야할 때가 왔다고 생각한다.

지난 3년간 해왔던 수련의 목표가 ‘생존’이었다면, 이제부터는 본격적으로 ‘잘 하기 위해’, 다시 말해 ‘장인이 되기 위해’ 목표를 수정해야겠다.

4. Conclusion

서평에도 써있듯, 무언가 위로받은 느낌이 든 책이었다. 모두가 비슷한 고민을 하고, 비슷한 좌절을 겪고, 비슷한 실수를 한다는 것에서 위안을 얻었다. 그동안 무언가 혼란에 쌓인 느낌이었고, 제대로 하고는 있는지 늘 걱정이 되었었는데 어느정도 길을 제시해준 책이라고 생각한다.

또한, 이 책은 가볍게 읽을 수 있지만 읽고나면 무거워 지는 것 같다. 지난 3년간의 실수들과 프로페셔널하지 못했던 순간들이 주마등처럼 스쳐지나가고, 얼굴이 화끈거릴 만큼 부끄러운 감정이 치밀어 올를 때도 있었다. 하지만, 잘못을 인정하지 않으면 성장할 수 없다는 개인적인 신념을 갖고 살아가는 만큼, 큰 울림이 있는 책이었다.

와이프에게 이 책을 추천해 주었는데, 와이프가 다 읽고나면 동료들에게도 추천해 주고 싶다.


© 2021, Built with Gatsby