좋은 개발 문화란? - (1) 실패

과거의 애플리케이션은 아마도 충분한 계획을 기반으로 개발되었으며, 변경점도 비교적 많지 않았습니다.

그리고 대부분 SI 식 개발로 비즈니스가 분리되었기에, 지속성보다는 요구 사항 충족과 납기일이 우선 되었었습니다.

이때에는 단어조차 생소한 개발 문화는 중요하지 않았으며, 위에서 내려온 계획에 맞는 개발을 하나라도 더 하는 게 미덕이었습니다.

 

하지만 현대의 애플리케이션은 긴 생명 주기와 모호해진 개발과 운영의 경계로 개발보다는 운영하면서 더 많은 이슈를 만나게 됩니다.

그러다 보니 자연스럽게 개발의 지속성에 대해 생각하게 되고 그것들을 아우르는 것으로 개발 문화가 나오게 되었습니다.

이제는 개발이 비즈니스의 성공에 직결적인 요소가 되었기에 개발 문화의 중요성이 업계 전반에 퍼져 있고 채용에도 중요한 화두가 되곤 합니다.

 

이 글에서는 개발 문화에 대한 제 생각과 경험을 기록합니다.

아래에서 말하는 비즈니스는 업무 영역만이 아닌,
새로운 일 -> 기획 -> 개발 -> 시장 검증 -> 운영까지의 일련의 프로세스를 말합니다.

저는 비교적 늦게 개발을 시작했지만 그 덕분에 최신의 개발론을 배울 수 있었고, 그것들을 회사에 적용하고 싶었습니다.

원활한 비즈니스를 위한 전반적인 프로세스 작성부터 PR리뷰, 레이어 관리, 메타 단어, 배포 전략 등 코드 레벨까지를 문서화하여 팀에 공유하고 도입하려고 노력했습니다.

하지만 제가 작성한 문서들은 잘 관리되지 못했고,
개선안들은 대부분 공감을 얻지 못했습니다.

무엇이 문제였을까 생각해봤습니다.

무엇을 위한 개선인지를 잃어버렸습니다.

개발과 비즈니스가 직결되어 있다고 말해놓고, 비즈니스를 고려하지 않은 개선을 하려고 했습니다. 

제가 다니던 회사는 아직 상용화된 프로덕트를 개발하지 못했고, 총원 10~15명, 백엔드 개발자 2~3인으로 구성원 대부분이 2년 차 이하의 스타트업이었습니다.

당면한 회사의 비즈니스 목표는 상용화된 프로덕트였고 그렇기 위해서는 빠른 개발이 우선이었는데, 단기적인 상황에서 제 개선안은 걸리적거릴 뿐이었습니다.

더 큰 문제는 경험 부족이었습니다.

처음에는 '이미 검증된 방법을 왜 수용하려고 하지 않지?'라는 생각이 들었지만, 조금만 운영해봐도 허점이 드러났고 심지어 만든 저 조차도 누락하고 실수했습니다.

이런 상태로 팀을 설득하려고 했으니 제대로 적용했더라도 제가 먼저 떨어져 나갔을 것입니다.

아마 제가 더 경험이 풍부했다면 팀원 모두의 경험치와 의견을 수용해서 좀 더 완화된 개선안을 제안했겠지만 부족했습니다.

결국 제가 작성한 개선안들은 대부분 폐기됐고 처음으로 돌아갔습니다.

생각해보니 제가 했던 방법은 레이싱 경기 중에 엔진을 교체하는 것과 같았습니다.

더 좋은 엔진을 사용하는 것이 장기적으로는 좋지만, 그것을 레이싱 경기 중간에 해서는 안됐습니다.

최소한 경기가 끝난 후, 좀 더 많은 레퍼런스로 팀을 충분히 설득해서 교체했어야 했죠.

 

다행히 문제를 찾는 과정에서 저의 부족함을 깨닫고, 제가 찾은 개선안들이 부채로서 해결되어야 한다는 것은 팀에 공유할 수 있었습니다.

아마 개선안을 다시 준비할 때는 조금 더 나은 공감을 얻을 수 있겠죠.

 

무엇보다도 제 마음의 안정을 찾을 수 있었습니다.

만약 이런 시도를 하지 않았다면 일을 하면서도 한편으로는 '왜 이런 낙후된 방법으로 일하는 거지? 왜 개선하려 하지 않는 거지?'라는 불만이 가득했을 것입니다.

하지만 시도해봤기에 간과한 점과 부족한 점을 알 수 있었고, 지금 내가 해야 할 일에 대해 완전히 공감하고 몰입할 수 있었습니다. 

---

좋은 개발 문화의 좋은 적용 사례는 이미 회사 소개나 블로그, 책 등에 정답에 가까운 내용들은 많이 있습니다.

하지만 앞선 실패에서 일반적인 정답보다는 '지금 내가 속한 조직에 적합한지? 구성원들의 합의를 이끌어 낼 수 있을지?'가 더 중요하다는 것을 경험했습니다.

 

그러기 위해서는 지금을 분석해야 되고 경험과 신뢰가 쌓이는 시간이 해결해줄 것 같습니다.

 

하지만 지금까지의 경험을 돌이켜 볼 때 그렇지 않았습니다.

업무 경험이 쌓이면 당연히 개선에 대한 아이디어가 떠오르지만, 의도적으로 그것을 구체화시키고 설득하는 일은 완전히 다른 영역입니다.

 

또한 회사의 개발자로 일하는 이상 다양한 요구 사항을 빠르게 개발해야 되는 강박과, 리팩터링에 대한 죄책감이 조금씩은 있습니다. 그리고 그 중간 어디쯤을 찾는 것이 개발자의 역량 중 하나입니다.

 

이렇게 보면 개발자가 알아서 그 중간 어디쯤을 잘 찾고 잘 조율하면 될 것 같습니다.

 

하지만..

---

이 글을 쓰게 된 이유는 회사에 있던 '소프트웨어 장인'을 읽으면서 '14장. 기술적 변화의 실행'에서 영감을 얻어서입니다.

이미 아는 내용이고, 너무나도 당연한 내용이지만 정작 실무에서는 제대로 활용하지 못했었습니다.

 

다음 글은 개발 문화를 '준비' 하는 것에 대해 기록해보겠습니다.