[CHAPTER 6] 동작하는 소프트웨어

소프트웨어 프로젝트가 실패하는 원인은 아주 다양하다.
잘못된 비즈니스 의사 결정, 우월한 경쟁자, 잘못된 프로젝트 관리 등 매우 많다.
소프트웨어 프로젝트에는 중요한 일들이 많아서 덜 중요해 보이는 것들이 있다.

어떤 조직에서는 유능한 관리자, 깊은 계층구조, 마이크로 매니지먼트, 엄격한 절차, 대량의 문서들이 프로젝트의 성공을 좌우한다고 생각한다.
많은 조직들이 소프트웨어 개발을 공장 라인으로 취급한다.

직접 경험한 SI 업계가 대다수 이런식으로 많이 진행한다.

 

이러한 조직에서 훌륭한 개발자를 끌어들이고 유지할 수 있는 경우는 거의 없다. 그저 그런 개발자들의 손에 전체 비즈니스를 맡기게 된다.

어떤 프로젝트에서는 개발자만 70~80명 있었는데, 대다수가 그저 그런 개발자였다.

함수선언도 못하던 10년차 개발자도 있었고, 일도 안하고 시간만 보내다 짤리는 개발자도 여럿 있었다.

그저 그런 개발자들의 정치질에 정상적인 개발자들은 한두명씩 사라져갔다.

이런 프로젝트는 개발자를 쉽게 구한다. 면접 질문도 단순하다. "이 업무를 해봤나요? 어떻게 해봤나요?" 이러고 프로젝트에 투입시킨다. 머릿 수 채우는 형태가 많다.

프로젝트 중간에 투입되는 개발자 중에는 첫출근 이후 잠수타는 경우가 많았다.

저자의 말 처럼 그저 그런 개발자들 손에 프로젝트를 맡기고 안 좋은 결과만 반복된다.

 

소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다.

소스코드가 엉망인 프로젝트가 많다.

원인은 다양했지만 말도 안되는 일정에 품질을 포기하고 결과중심으로 진행하는 개발자도 있었고,

코드 품질이 무엇인지 모르는 개발자도 있었다... 운영 인력이 알아서 하겠지라는 마인드가 많았다.

운영하는 개발자 입장은 오픈하면 잘못된게 많아서, 기능마다 처음부터 코딩하는 경우가 많다고 한다.

 

 

동작하는 소프트웨어만으로는 부족하다

매니페스토에서 광범위한 문서보다 동작하는 소프트웨어를 강조한다.
'동작하는 소프트웨어'를 자주, 몇 주나 2개월 단위로, 가능하면 짧은 주기로 전달한다.
'동작하는 소프트웨어'는 진척도를 가늠하는 주된 기준이다.

문제는 시간이 흐르면서 동작하는 소프트웨어에 대한 개념이 '고품질의 동작하는 소프트웨어'로 옮겨가고 있다
엉망진창인 레거시 코드들도 동작하는 소프트웨어의 범주에 포함된다.

사용자는 소프트웨어의 내부구조를 신경쓰지 않고 이용한다. 원하는 대로 동작하니깐 정상이라 생각한다.

소프트웨어의 내부가 이해할수 없는 로직과 비지니스 용어가 없는 작명으로 이뤄져있다면 개발자의 입장에서는 정상이라 생각할까?

 

'동작하는 소프트웨어'의 의미는 무엇일까?
동작하는 소프트웨어로서 충분한 조건을 갖춘 것일까?
뭔가 하나를 수정하면 오랜 기간 빌드와 수동 테스트, 버그 수정을 거쳐야 한다는 것을 용납할 수 있나?

 

 

정원 돌보기

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 가깝다. [실용주의 프로그래머]

코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다.
1년 내내 정원이 아름다우려면 지속적인 돌봄이 필요하다.
기본적이고 정기적인 유지보수만으로도 정원을 훌륭하게 가꿀 수 있다.
짧은 기간이라도 돌보기를 게을리하면 다시 가꾸는 데 훨씬 더 많은 노력을 해야 한다.

코드도 정기적으로 살피지 않으면 변화가 있을 때 마다 상태가 나빠진다.
잘못된 설계, 테스트 부족 등은 코드를 더 빨리 썩게 만든다.

정원을 가꾸는 개발자의 역량도 중요하다. 단순하게 채용한 그저 그런 개발자라면 겉모습에만 신경쓰는 경우가 많을 것이다.

오죽하면 유지보수 어렵게해서 평생 먹고 살자라는 책까지 나왔을까 생각해본다.

 

 

보이지 않는 위협

프로젝트를 시작할 때는 모든 것이 훌륭하다. 얽매여야 할 레거시 코드 베이스가 없어 개발자들은 기존 코드를 깨드릴 걱정 없이 새로운 기능을 개발 할 수 있다. 테스터들도 편하다.

이력서 키워드 검색과 희망 급여 조건만으로 채용된 그저 그런 개발자들로 이루어진 팀이라면, 개발 업무가 공장 라인처럼 취급되는 환경이라면, 시간이 갈수록 상황이 악화된다.

몇 개월 또는 몇 년에 걸쳐 이렇게 모든 것이 서서히 느려지기 때문에 관리자가 눈치채지 못한다.

프로젝트가 안 좋은 결말을 맞이하는 조건이라 생각된다. 역량보다는 값싼 개발자로만 채용된 프로젝트라니... 끔찍하다.

 

저자는 한 문장으로 요약한다.

자신이 만든 소프트웨어에 인질이 되는 상황

 

해결 방법은 무엇일까?

평범한 개발자가 아닌 장인을 고용하라.
장인은 꾸준히 코드 베이스를 돌보고 두려움 없이 빠르게 리팩토링을 한다.

 

 

레거시 코드

소프트웨어 장인정신 토론회 중 하나에서, 백지상태에서 시작하는 그린필드 프로젝트를 선호하는 사람이 있냐는 질문에 거의 모두가 손을 들었다.
반면에 레거시 코드에서 작업해야 하는 프로젝트를 선호하는 사람은 아무도 없었다.

기존 코드를 이해할 필요 없이 코드를 작성할 수 있다는 것은 대단히 큰 이점이다....
오래 전에 떠나버린 개발자가 남겨놓은 코드 위에서 일하는 상황이라면 개발자가 위축될 수밖에 없다...

백지상태에서 시작하면 즐겁게 코딩을 할 수있다. 제약하는 상황이 아무것도 없기 때문이다.

하지만 레거시 코드가 제약사항으로 존재하는 프로젝트는 어떨까...? 작업을 진행하려면 레거시 코드부터 파악해야하는 문제가 있다.

수정도 함부로 할 수가 없다. 어디서 무슨 문제가 생길지 모르기 때문이다. 관련 담당자가 없다면 파악하기 더 어려울 것이다.

 

레거시 코드로 일하는 것은 거대한 직소 퍼즐을 푸는 것과 비슷하다...
모서리나 경계선부터 시작해야 한다...
각각의 작은 그룹들에 대해서 조금씩 조각을 맞춘다. 즉 점진적으로 기존 코드에 대한 테스트 코드를 작성하면서 코드에 대한 이해도를 높이고 리팩토링을 해나간다...

이어 붙인 조각들이 많아질수록 남은 조각들을 이어붙이기가 더 쉬워지고, 전체 직소 퍼즐의 완성 형태가 보이기 시작한다...
이정도까지 진행되면 그린필드 프로젝트를 맡고 있는 다른 개발자를 부러워할 필요가 없어진다.

지금도 인력 공고를 보면 이런 레거시 코드를 리팩토링하는 프로젝트가 간간히 보인다.

대부분 초기 사업을 시작하면서 레거시 기반으로 시작했다가 매출이 많이 성장하거나 투자를 받으면서, 새로운 인력 모집과 함께 사업을 더 크게할 수 있도록 레거시 코드를 리팩토링하는 경우가 많다.

초기부터 장인정신을 가진 개발자가 '처음부터 만들면 되지 않을까?' 라고 생각해본적이 있다.

 

남이 작성한 코드를 엉망이라고 그냥 말하기는 쉽다. 심지어 비웃을 수도 있다. 하지만 나라면 더 잘 만들 수 있는가?

처음부터 신경쓸 수 있는 것은 매우 희박하다고 생각한다. 초기 스타트업이 장인정신을 가진 개발자를 고용할 여건이 안되기 때문이다.

초기 스타트업에 돈이 어디있겠는가? 값싼 인력으로 시작하는게 대부분이다. 심지어 신입에게 팀장 직급을 주고 시작하는 경우도 많다.

극소수의 스타트업만이 자본을 가지고 제대로 된 팀을 꾸리고 시작한다.

그런 수 많은 스타트업 중에서 극소수만 살아남아 성장하여, 레거시를 리팩토링할 기회를 갖게 된다. 

 

 

---

후기

이번 챕터는 동작하는 소프트웨어에 대한 내용이다

겉모습만 봐서 작동하는거부터 꾸준히 관리가 잘된 소프트웨어까지 모두 '동작하는 소프트웨어'에 포함된다.

하지만 개발자와 사용자의 관점에서 보면 서로 다른 생각을 볼 수가 있다.

 

무작정 레거시 코드라고 비웃을게 아니다.

메이저회사도 처음엔 레거시 코드였다는 이야기는 많다.

성장하여 살아남아 장인을 고용할 여력이 생기고, 리팩토링할 기회를 얻게 된것이다.

또한 레거시의 경험을 기록하여 발전하는데 사용할 수도 있다.

 

그리고 기술적 부채를 백로그에 남기는 것은 죄책감 없이 잘못된 코드를 반영했다는 이야기와

왜 나쁜코드를 작성하고 핑곗거리를 찾게 되는지에 대한 공감되는 이야기 등 언급을 안한 소주제가 있다.

직접 책을 읽는걸 추천합니다. 생략한 좋은 내용이 많아요.