2019-09-05에세이

나는 어떤 마음으로 소프트웨어를 만들어야 하는가

최근 필자는 산드로 만쿠소의 소프트웨어 장인이라는 책을 읽게 되었는데, 이 책을 읽으며 느낀 점이 많았기 때문에 이번 포스팅에서는 산드로 만쿠소가 이 책을 통해 이야기하고자 하는 것이 무엇인지와 그에 따른 필자의 생각을 한번 편하게 적어보려고 한다.

표지가 깔끔하니 이쁘장하다

산드로 만쿠소가 이 책에서 계속 해서 강조하고 있는 것은 제목 그대로 프로페셔널리즘이다. 저자는 책의 초반에서는 내가 개발자로써, 또는 기술 전문가로써 비전문가인 고객들에게 어떠한 만족을 줄 것인지 혹은 고객이 진짜로 나에게 원하는 것은 무엇인지와 같은 질문을 통해 소프트웨어를 개발하는 장인으로써의 태도를 이끌어 내려고 하고 있다. 그러다가 후반에는 고객들이 원하는 바를 충족시켜주기 위해 개발자로써 어떤 방법들을 사용할 수 있는지 설명하고 있다.

사실 처음에는 아무 생각없이 읽기 시작했는데, 어느 샌가 그치, 이건 맞지, 이건 좀 아닌듯?하면서 빠져들고 있는 자신을 볼 수 있었다. 저자가 예시로 이야기하고 있는 상황들이 개발자로서 자주 경험하게 되는 상황들인 경우가 많고, 책 내에서 필자가 평소에 생각하고 있던 주제들도 많이 다루고 있다보니 더 빨리 빠져들었던 것 같다. 그만큼 재미있다 이 책.

그래서 필자는 이 책에서 재미있게 읽었고 많은 것을 느낄 수 있었던 주제 몇 가지를 한번 소개해보려고 한다.

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

많은 개발자들이 개발자의 성장에 대한 지원을 해주고 관심을 가지는 회사를 선호한다. 컨퍼런스 가고 싶다고 하면 돈도 내주고 책도 사주고 스터디를 하고 싶다고 하면 사무실도 빌려주거나하는 그런 회사 말이다. 간혹 조직 문화 차원에서 업무 시간에 공식적으로 공부할 수 있는 시간을 내어주는 회사도 있다.

이런 회사들의 특징은 조직원이 성장하는 것이 결과적으로는 회사의 성장이라는 것을 잘 알고 있다는 것이고, 실제로 이런 문화가 있는 조직에는 좋은 개발자들도 많이 몰릴 수 밖에 없다. 자신의 성장을 지원해주는 회사, 얼마나 좋은가?

하지만 이런 지원이 없는 회사를 다니고 있다면 이런 불만이 생길 수도 있다.

옆 동네 철수네 회사는 컨퍼런스 비용도 다 대주고 한다는데 우리 회사는 왜 안해주는거야…?

필자도 회사를 다니면서 우리 회사보다 더 좋은 혜택이 있는 회사 얘기를 들으면 이런 생각을 하긴 했다. 그러나 저자인 산드로는 이런 불만을 가지는 것에 대해서 옳지 않다고 이야기한다.

사실 개발자가 새로운 기술을 공부하거나 컨퍼런스에 참여하거나 하는 등의 자신의 기술을 갈고 닦는 행위는 고객들을 만족시키기 위한 일종의 투자이다. 우리가 만약 몸이 아파서 병원에 갔는데 의사가 환자들에게 자신의 연구 비용 명목으로 진료비의 10%를 추가한다면 기분이 어떻겠는가? 산드로는 이 예시가 개발자들이 회사에 자신의 자기 계발을 위한 배려를 해달라고 강요하는 것과 다르지 않다고 이야기한다.

회사는 고객으로써 나의 기술력을 얻기 위해 나에게 돈을 지불하고 있는 것이지 나의 성장을 위해 돈을 지불하고 있는 것이 아니다. 물론 회사에서 이런 것들을 지원해주면 결국 개발자들의 실력 향상이 되면서 회사에도 좋은 영향을 끼칠 수 있지만 이건 일종의 배려이지 의무가 아니다. 개발자의 자기 계발은 스스로를 위한 투자이기 때문에 회사에서 지원을 해주던 말던 간에 기본적으로 스스로 알아서 해야 한다.

사실 필자도 첫 직장을 다닐 때는 개발자들의 발전을 지원해주고 컨퍼런스비나 도서 구입비를 지원해주는 것이 일종의 의무라고 생각했던 적이 있었다. 이런 지원을 해주지 않는 회사는 조직원의 성장에 별로 관심이 없는 회사이기 때문에 이런 회사에서는 더 이상 내가 성장할 수 없다고 생각했다. 기본적으로 퇴근 후에 따로 토이 프로젝트를 하거나 새로운 기술을 공부하기는 했지만 회사에서 지원을 해주면 더 빨리 성장할 수 있을 것이라고 생각했기 때문에 이런 불만을 가졌던 것이다.

하지만 이 생각은 굉장히 어리고 부끄러운 생각이였다. 회사에서 이런 지원을 해주면 좋긴 하지만, 혹여 저런 지원이 없더라도 필자는 소프트웨어 프로페셔널로서 고객에게 항상 최고의 결과물을 제공해야한다.(그래도 안해주면 아쉽긴 하다)

저자인 산드로는 직장에서 이런 불만을 가지고 있는 팀원에게 당신의 커리어의 주인은 누구인가?라는 질문을 던졌다고 한다. 위에서 구구절절히 이야기한 것들을 단번에 관통하는 명쾌한 질문이다. 결국 내 커리어를 만들어 가는 것은 자기 자신이고, 내가 성장함으로써 가장 큰 이익을 받는 것도 자기 자신이기 때문이다.

프로답게 행동하자

산드로는 고용과 피고용의 관계는 창조적인 업무를 할 때 방해되는 모델이라고 이야기한다. 단, 여기서 저자가 이야기하는 고용과 피고용의 관계는 단어 자체가 아니라 고용과 피고용의 관계에서 오는 상명하복 시스템을 의미한다. 쉽게 말하면 아무리 아닌 것 같아도 대표가 까라면 까야하는 그 시스템이다.

사실 이 상명하복 시스템은 아무리 수평적인 문화를 지향하는 기업이라고 하더라도 어느 정도는 암묵적으로 존재하기 마련이다. 직원이 회사에 이건 좀 아닌 것 같다라고 말할 수 있는 기업은 우리나라 뿐만 아니라 세계적으로도 생각보다 많지 않다.(대표와 HR 담당자는 바로 우리 회사가 그런 회사라고 이야기하지만, 이건 직원 얘기를 들어봐야한다.)

하지만 잘 생각해보면 우리는 사실 회사와 계약을 한 것이다. 이 계약은 내가 너의 노예가 되겠다라는 계약은 아니였을 것이다. 회사는 나의 기술력을 원하고, 나는 기술 전문가로서 회사에 나의 기술력을 제공하는 일종의 동반자 관계인 것이다.

결국 전문가는 자신의 전문성을 파는 사람이다

그렇기 때문에 산드로는 회사도 개발자의 고객이라고 이야기한다. 우리는 소프트웨어를 만드는 전문가로서 회사에 나의 기술력을 팔고 있는 것이기 때문이다. 우리가 몸이 아프면 병원에 가서 의사를 찾거나 하수구가 막히면 배관공을 찾는 것과 마찬가지다. 회사가 소프트웨어를 만들고 싶으면, 개발자를 찾는다.

그리고 이러한 전문가들은 자신의 고객이 손해를 볼 것을 알면서도 어떠한 일을 해주기를 원한다고 해도, 그 일이 자신의 소신에 어긋난다면 그것을 쉽게 해주지 않는다. 간단한 예로 수술이 끝나고 마취가 풀리면서 고통이 찾아오면 환자는 의사에게 진통제를 더 투여해달라고 할 수 있다. 이때, 환자의 몸 상태가 진통제를 받아들일 수 없는 상태라면 의사는 진통제를 더 투여하지 않을 것이다. 환자는 그 진통제가 자신에게 어떤 영향을 끼칠지 모르는 상태이지만 의사는 확실하게 알고 있다.

개발자도 마찬가지다. 우리는 기술 전문가이기 때문에 기술적으로 우려되는 부분이 있다면 회사에 전부 이야기 해야한다. 회사는 바로 그런 기술적인 부분을 알고 싶어서 우리를 고용한 것이다. 그 중 대표적인 예는 바로 프로젝트 기간이다.

만약 대충 봐도 한달 이상 걸릴 것 같은 스펙의 프로젝트를 PO나 대표가 와서 2주 안에 끝내달라고 부탁하면 어떻게 해야할까? 많은 개발자 분들이 한번 노력해볼게요. 달려봅시다!라고 말할 것 같다. 왜냐면 저 상황에서 대표가 와서 간곡히 부탁하는데 딱 잘라서 안되는데요?라고 하면 왠지 내가 능력이 없는 것 같기도 하고 나쁜 사람이 되는 것 같기도 하고 그런 느낌?

자, 그럼 우리가 한달 이상 걸릴 프로젝트를 2주 안에 끝내려면 어떻게 해야할까?

네 야근입니다. 저녁 배달 시키실 분?

기본적으로 이런 상황에서 개발자들은 야근을 택할 수 밖에 없다. 또 다른 것으로는 문제가 생길 것 같은 부분을 일단 대충 때우고 넘어가는 등 일을 빠르고 대충 처리하는 방법도 있다. 문제가 생길 것을 뻔히 알면서 일단 끝내고 보자라는 마인드로 하드 코딩을 하거나 스키마 설계를 제대로 하지 않고 모델을 구현한다거나 하는 것들 말이다.

그러나 산드로는 개발자들의 이런 행위에 대해서 프로페셔널하지 못하다라고 이야기한다. (뜨끔)

사실 필자도 회사에서 이런 마음으로 몇번 프로젝트를 진행한 적이 있다. 당연히 제 기간 안에 프로젝트를 끝내는 게 제일 중요하다고 생각했고, 문제가 생길 수 있는 부분을 제대로 해결하지않고 어떻게든 작동하게만 만들어놓고 정신없이 다음 구현사항으로 넘어갔다. 물론 개발에 내공이 쌓이신 분들이라면 대충 하더라도 어느 정도 퀄리티가 나오겠지만 아쉽게도 필자는 그 정도 내공이 있는 개발자는 아니기 때문에 진짜 개판으로 짠 적도 있다.

하지만 이렇게 프로젝트를 진행하는 경우, 나중에 어플리케이션이 커질수록 이런 기술 부채들이 계속 쌓여서 분명히 문제가 발생할 것이라는 또한 우리 모두 알고있는 사실이다. 게다가 아무리 야근을 한다고 해도 프로젝트의 배포 일정을 맞출 수 있으리라는 보장도 없고, 어찌어찌 일정을 맞췄다고 하더라도 이런 상황에서 작성된 코드의 질이 높을리가 없고, 질낮은 코드는 결국 버그를 발생시킬 확률이 높아진다.

아무리 프로젝트 일정에 맞춰 배포를 했다고 해도 버그로 인해 사용자들이 좋지 않은 경험을 하게 만들었다면 그 프로젝트는 제대로 완료되었다고 할 수 없다. 산드로는 이런 상황에서 개발자가 프로페셔널로서 회사에 이렇게 프로젝트를 진행하면 안된다라고 강력하게 말해야 한다고 이야기한다.

즉, 개발자만이 지금 이 코드가 나중에 어떤 문제를 가져올 지 가장 정확하게 알고 있는 사람이고, 우리는 프로페셔널로서 프로젝트를 이렇게 진행하면 추후에 이런 문제점이 발생할 수 있다는 것을 고객인 회사에게 이야기할 의무가 있다는 것이다. 뭐, 이 상황을 어떻게 개발자가 아닌 사람들에게 이해시킬 것인지는 또 다른 문제지만 필자도 일단 이야기를 해야하는 것 자체는 맞다고 생각한다.

이렇게 이야기함으로써 PO나 CEO 등 개발자가 아닌 다른 팀원들이 문제 상황을 제대로 인지하게 되면 새로운 해결 방법이 나올 수도 있기 때문이다. 뭐 스펙 아웃을 해준다던가, 일정을 약간 늘려준다거나 하는 등의 여러 가지 해결책이 있을 것이다.

어쨌든 결론적으로 이 책의 저자가 이야기하고 싶은 것은 우리는 소프트웨어를 만드는 프로페셔널로서 회사에 기술력을 제공하고 있는 것이라는 것이다. 우리는 무리한 일정이 가져올 수 있는 문제를 회사에 이야기해주고 다른 합리적인 대안을 제시할 수 있어야 한다. 단순히 돈 주니까 받는 만큼 시키는대로 해야지라는 생각으로 일하지 말자는 것이다.

또한 회사 입장에서는 개발자가 이런 주장을 한다면 일 쉬엄쉬엄하려고 하네?라고 생각할 것이 아니라 뭔가 켕기는 부분이 있어서 하는 말이라는 것을 확실히 인지하고, 이런 상황에서 프로젝트를 강행하면 얻을 수 있는 것과 잃을 수 있는 것을 잘 판단해야한다.

개발자가 코드를 대하는 태도

필자도 저번에 애자일이 도대체 뭐길래? 라는 포스팅에서 한번 다룬 적이 있지만 애자일이라는 방법론은 애자일 선언에서 출발했고, 그 애자일 선언에는 이런 항목이 있다.

포괄적인 문서보다 작동하는 소프트웨어를 만들자

이때 이 작동하는 소프트웨어라는 정의의 범위는 개개인마다 조금씩 다르다. 어떤 개발자는 일단 돌아가기만 하면 됐다고 생각할 수도 있고 어떤 개발자는 설계가 군더더기없이 깔끔하고 유닛 테스트까지 모두 작성되어야 한다고 생각할 수도 있다는 것이다. 하지만 사실 대부분의 경우 애자일 == 기민하게 움직여야한다라는 개념에 사로잡혀서 전자를 택하게 된다.

그러나 잘 생각해보면 일단 돌아가게만 작성된 코드, 그러니까 제대로 된 설계나 추상화나 패턴이 없이 작성된 코드는 지금 당장 작성하기엔 쉬울 지 몰라도 새로운 기능이 추가될 때마다 문제가 발생할 것이다.

한번 우리가 엉망진창인 레거시 코드와 만났을 때 느끼는 감정들을 떠올려보자.

코드를 파악하기가 힘들어서 잘못 수정하면 어디가 어떻게 망가질 지 몰라 손을 대기도 무섭다. 그래서 작은 수정을 할 때마다 전체 기능을 전부 테스트해야지 안심이 된다. 그마저도 자동화가 되어있지 않아서 일일히 손으로 테스트 해야한다. 일단 이런 경우도 작동하는 소프트웨어의 범주에는 들어간다.

자, 이제 이런 레거시 코드에 어떤 기능을 새로 추가하거나 기존의 기능을 개선해야 한다고 생각해보자. 우리가 처음에 애자일을 도입하면서 의도했던 것처럼 기민하게 움직일 수 있을 것인가? 필자는 아니라고 생각한다.

처음에는 기능 개발이 빠르기 때문에 기민하게 움직이는 것처럼 보일지 몰라도 점점 누적되는 기술 부채들 때문에 결국 나중에는 기민하게 움직일 수 없게 될 것이다. 게다가 애자일에서 기민하게 움직인다는 것은 빠르게 개발을 끝낸다가 아니다. 자주 변경되는 요구사항에 유연하게 대처할 수 있는 기민함을 말하는 것이다.

산드로는 소프트웨어를 만들어내는 프로페셔널이라면 단순히 작동하는 소프트웨어가 아니라 정교하며 솜씨있게 만들어진 소프트웨어를 추구해야 한다고 말한다. 정교하며 솜씨있게 만들어진 소프트웨어란, 오래 전에 작성한 코드라도 새로운 신입 개발자가 바로 이해할 수 있을 정도의 명료하고 단순한 디자인, 새로운 기능을 추가 및 수정하는 일이 처음 개발할 때와 비슷한 수준의 개발 공수로 완료될 수 있는 소프트웨어를 말한다.

즉, 예측가능하고 유지보수할 수 있는 소프트웨어인 것이다. 산드로는 이런 소프트웨어를 작성하기 위해 필요한 개념으로 단위 테스트, 페어 프로그래밍, 지속적인 통합 등을 제시하고 있다. 하지만 저자가 제시한 방법들을 전부 실행하지 않더라도 사실 코드 리뷰만 잘 되어도 어플리케이션의 코드가 진짜 막장으로 가는 최악의 사태는 어느 정도 방어할 수 있긴 하다.

작동하는 코드를 작성하는 것은 개발자로서 당연히 해야하는 것이고, 프로페셔널한 개발자는 거기에서 더 나아가서 정교하며 솜씨있는 코드를 작성하는 것이다.

시간이 없어서 어쩔 수 없었다

필자는 개인적으로 이 주제에 대해서 많은 반성을 했는데, 사실 필자가 회사에서 자주 했던 말이기 때문이다. 프로젝트의 막바지에 다가갈수록 더 이런 얘기를 하는 경향이 있었던 것 같다.

여기서 필자가 반성했던 것 중 하나는 단위 테스트 작성과 비즈니스 로직 작성을 완전 별개의 업무로 생각했다는 것이다. 그리고 유닛 테스트보다 비즈니스의 개발을 끝내는 것이 중요하다고 생각했다. 그렇기 때문에 시간이 없어서 테스트 작성은 다음에 한다라는 핑계도 댈 수 있었다.

저자인 산드로는 유닛 테스트 작성을 굉장히 강조하는 편인데, 처음에는 직접 손으로 테스트를 해도 할만하지만 나중에 어플리케이션이 거대해지면 거대해질수록 이 테스트에 소요되는 시간도 함께 늘어나기 때문이다.

상용 환경에서 갑작스럽게 발생하여 원인을 쉽게 파악하기 힘든 버그의 상당 수는 유닛 테스트를 작성함으로써 간단하게 개발 중에 잡아낼 수 있다. 산드로는 이렇게 유닛 테스트를 통해 소모적이고 반복적인 작업을 줄일 수 있고, 이는 곧 생산성의 증대로 이어진다고 이야기한다.

그러면 여기서 이런 의문이 들 수도 있다.

단위 테스트를 작성하게되면 절대적으로 작성해야 할 코드의 양도 늘어나고, 명료한 기능의 정의를 해야 하니까 이에 대해서 고민하는 시간도 늘어날테고… 그럼 결국 개발 기간은 더 길어질텐데?

이 이야기도 맞는 말이다. 그냥 짜는 것보다는 확실히 오래 걸릴 것이다. 그러니까 애초에 일정 산정을 테스트를 작성하는 것까지 모두 포함해서 해야한다. 비즈니스 로직과 테스트 작성은 별개의 업무가 아니라 그냥 기능 개발하는 과정 중 하나이다.

그리고 유닛 테스트말고도 시간이 없어서라는 변명을 또 하는 경우가 있는데, 바로 구조적이지 않은 코드를 작성할 때이다. 쉬운 말로 날림 코딩이다. 솔직히 말해서 일단 이렇게 해놓고 나중에 고치자라는 이야기는 필자도 많이 했다. 버그가 발생할 것 같지는 않지만 가독성이 떨어지거나 구조가 명료하지 않은 상황에서 시간이 없다는 이유로 일단 넘어간 경우는 필자 뿐만 아니라 다른 개발자들도 겪어봤으리라 생각한다.

산드로는 이런 행위를 한다는 것은 개발자가 질 나쁜 코드를 아무런 죄책감 없이 어플리케이션에 끼워넣었다는 그 이상 그 이하도 아니다라고 비판했다. 이 형 가만보면 사람 명치를 되게 잘 때리는 스타일이다.

필자는 다른 주제들보다 이 주제가 머릿 속에 오래 남았던 것 같다. 나도 모르게 시간 없어서, 프로젝트를 끝내는 게 더 중요해라는 말로 자기 합리화를 하면서 질 나쁜 코드를 작성하고 있던 게 아닌가라는 생각이 들었기 때문이다. 다른 주제들은 뭔가 깨달음을 주는 주제였다면 이 주제는 필자를 굉장히 부끄럽게 만든 주제였다.