노력해서 시간버리기

내 메모장에는 '읽어 볼 책' 이라는 메모가 있다. 추천받거나 주변에서 언급되는 책들을 메모하는데, 읽지는 않고 계속 쌓여만 간다 ㅎㅎ

그러던 중 추석연휴에 드디어 '인스파이어드' 라는 책과 함께 보냈다. 기억에 남는 내용과 함께 지극히 주관적인 후기를 시리즈로 남겨본다.

우리는 밤과 주말을 희생해 가며 1년도 넘는 오랜 기간 열심히 일했다. (...) 우리 제품을 구매하는 사람이 아무도 없었다. (...) 만들 만한 가치가 있는 제품이 아니라면 엔지니어 팀이 얼마나 훌륭한지는 아무 의미가 없다는 것이다..

책에 위 내용이 있는데, 나도 비슷한 경험이 있다.

내가 주니어로 개발할때는 사실 고객을 생각하며 개발하지 않았다. 왜냐면 너무 많은 조직과 협력업체가 있었고 엔드유져도 거의 같은 그룹사인 경우가 많았다. '어떻게든 사용하려니깐 이런 프로젝트를 시작한거겠지' 라는 생각을 가지고 개발에만 집중했다.

개발을 하다보면 '노력해서 폭탄을 만드는 경우'가 있다 그건 바로 배려없는 코드로 동료에게 피해를 주는 행위고, 하루를 일주일로 만드는 행위고, 누군가의 주말을 없애는 실수다. 나는 그런것을 상당히 싫어했다. 유지보수가 가능하며, 다양한 대응에 반응할 수 있는 그런 배려있는 코드를 짜는 것이 중요한데.. 그러나 이건 정말 별거 아니었다.

이후 회사에서 나와 팀으로 일하면서, 팀원간 아예 필요하지도 않는 기능을 개발하거나 말도안되게 다른 명세로 개발하는 경우가 있었다. 회사다닐 때 코드 퍼포먼스에 왜 그렇게 민감하게 반응했는지.. '최선의 노력해서 폭탄도 아닌 것을 만드는 경우' 도 있다는 것을 알았다. 폭탄이라고 부르기도 민망한 화약도없는 그냥 검은색 동그란 물건을 만드는 경우가 있다

그런데 사업, 시장, 스타트업, 마케팅 쪽에 몸을 담굴수록 위에서 폭탄을 만들었다고 초기에 느끼는 것이 차라리 다행이라고 느꼈다. 우여곡절 끝에 다 개발했는데 시장의 반응이 없다면 그것은 정말 지옥이다. 심지어 스타트업이라면 '인생을 걸고 아무도 원하지 않는 걸 만든 경우' 다. (그래서 빠르게 검증해야한다)

내가 고려한 확장성, 에러났을 때 회복성, 타인을 배려한 코드와 몰입해서 더 빠른 알고리즘으로 만든 코드, 비교해서 선택한 개발 스택, 코드에 녹인 개발철학. 고객과 비지니스를 모르면 다 의미없는 단어의 조합이다.

의미있으려면 내가 비지니스와 시장에 대해 알아야했고 머리속에 들어있던 개념자체가 달라져야했다. 개발도 중요하지만 개발할만할 가치가 있는지 판단하는것 역시 중요하다.