리드잇zine(ReadITZine) 7호 원고 작성, 2023-01-15(Sun) 마감

[jongfeel]

https://velog.io/@frozing/%EA%B0%9C%EB%B0%9C%EC%9E%90-%EB%A7%A4%EA%B1%B0%EC%A7%84-%EB%A6%AC%EB%93%9C%EC%9E%87zine-7%ED%98%B8-%EC%9B%90%EA%B3%A0%EB%A5%BC-%EB%AA%A8%EC%A7%91%ED%95%A9%EB%8B%88%EB%8B%A4

개발하는 마음
2023년 1월 15일 일요일 까지

---

안녕하세요.

19년이라는 오랜 기간 동안 소프트웨어 엔지니어의 삶을 살고 있는 김종필입니다.
이번 주제인 개발하는 마음에 대해 저는 좋은 소프트웨어를 만들어 나갔던 마음가짐에 대해 얘기해 보려고 합니다.

첫 사회 생활에 발을 딛고 만들었던 어설프고 오류가 많이 났었던 소프트웨어 제품 개발부터
현재 세상을 변화시키고 사람들의 마음을 움직이는 소프트웨어를 만들기 까지
단계적으로 가졌던 개발하는 마음의 대해서 어떤 변화가 있었는지 구체적으로 얘기해 보겠습니다.

나의 생각과 손 끝에서 나오는 코드

첫 사회생활을 했을 때의 개발은 많이 어려웠습니다. 개발해야 하는 제품에 대한 이해를 시작으로 작은 기능을 맡아서 구현하면서 정말 많은 문제들을 겪었고 그걸 해결해 나가면서 어떤 마음가짐이 생겨났던 것 같습니다.

제가 처음으로 개발했던 소프트웨어 제품은 형상관리를 지원해 주는 솔루션 제품을 개발하는 일이었습니다. 윈도우 프로그램이었고 C++로 개발해야 했으며 파일 업로드/다운로드를 위해 FTP라는 통신 프로토콜로 네트워크 프로그래밍까지 했었습니다. 지금 생각해 보면 신입이 할 수 있는 도전적인 개발이었다고 생각했는데, 눈 앞에 기능 구현에만 급급하다 보니 작은 기능을 완성도 있게 구현하는데도 꽤 시간이 오래 걸렸던 기억이 납니다.

몇 개월의 경험이 쌓인 후, 한번은 내가 개발한 기능이 왜 오래걸리고 버그가 많은지 문제의 원인이 뭔지 찾아보기 시작했습니다. 그런데 의외로 코딩을 잘 못해서 생긴 버그라기 보다는 만들어야 하는 기능에 대한 이해 부족, 즉 생각을 주의깊게 하지 않고 구현 그 자체에만 신경을 써서 발생한 문제들이 많았다는 걸 알게 되었습니다. 즉, 내가 생각하고 이해한대로 코드를 작성하지 못했던 부분을 파악하고 그 이후로는 조금 다른 마음가짐으로 개발을 하게 되었습니다. 즉 내가 이해한 생각 그대로 내 손 끝에서 나오는 코드가 올바른지 검토를 한번 하게 되는 습관을 조금씩 들이기로 마음을 먹고 개발을 하게 된 거죠.

예전보다 월등히 개발이 잘 되었다고 말하기는 어렵지만, 확실한 건 제가 사회 초년생 때 경험했던 오류와 버그들은 많이 줄어든건 사실입니다. 그리고 이쯤 후배 개발자들이 입사했는데, 그때 그 후배들한테도 이해하고 생각했던 것대로 코드가 작성됐는지 한번 검토하는 시간을 가졌습니다. 지금으로 치면 코드 리뷰를 한 셈인데, 그 때는 코드 리뷰라는 개념도 없었기에 그게 코드 리뷰를 하는 건지 모르고 코드를 보고 이해하고 이해한대로 다시 코드가 나왔는지 검토하는 시간을 가진 것이 큰 변화 중 하나였던 것 같습니다.

<완전히 똑같다고 할 수는 없지만, filezilla ftp 프로그램과 비슷한 기능을 하는 프로그램을 개발 했었습니다. 사진출처: FileZilla wikipedia>

더 잘하기 위한 마음

몇 년의 시간이 흐른 후, 이제 개발하는데 있어서 어려움은 없다는 생각을 많이 하게 됐습니다. 더 개발을 잘 하기 위해서는 남들 보다 더 언어에 대한 경험과 이해도가 높고 코딩을 빠르게 잘 하는 게 좋다고 생각했습니다. 물론 그 때 시절 그렇게 생각했다는 것이지, 지금은 그렇지는 않습니다.

그래서 몇 년 동안 주력으로 했던 C++ 언어를 뒤로 하고 새롭게 윈도우 프로그램 시장에 발표된 .NET Framework와 함께 WPF라는 게 나왔고 이 새로운 프레임워크가 기존 윈도우 프로그램을 대체하는 프레임워크가 될 거라는 걸 직감했습니다. 같이 개발하는 팀원 들과 새로운 프레임워크에 대한 컨셉도 공유하고 따로 공부하는 시간도 가졌습니다. 나름 학부 시절 부터 C# 언어를 썼었고, 틈틈히 C# 공부를 해 왔다고 생각해서 팀장님한테 새로운 프로젝트를 WPF로 하자고 제안했고 새롭게 진행하는 프로젝트가 극적으로 WPF 라는 걸 써서 개발하는 걸로 채택이 됐습니다.

평소에 하고 싶었던 언어로 프로젝트를 하면 좋겠다는 생각은 했지만, 이런 기회가 오게 되니 더 잘할 수 있다는 마음가짐도 생기고 동기 부여도 됐던 것 같았습니다. 잘 모르는 xaml이라는 걸 배우면서 하는데 어려움도 있었고, 실무 프로젝트에서 처음 썼던 C#이 그렇게 만만한 언어가 아니라는 것도 알게 될 때 쯤 무력감이 찾아 왔습니다. 개발이라는게 하려고 하는 의지만으로는 잘 되는 게 아니고 기술적인 이해도와 경험이 어느 정도 필요하다는 걸 알게 됐습니다.

해당 프로젝트는 어찌어찌 해서 고객사에 납품이 되었고 잘 사용하는 소프트웨어 개발 사례로 남긴 했지만, 제가 생각했던 더 잘할 있는 기대치까지는 잘 만들어 내지 못한 프로그램으로 기억합니다.

<휴대폰 요금 컨설팅 프로그램, 이 프로그램을 실무에서 한번도 쓴적 없는 프레임워크와 언어로 개발했는데, 그 자신감이 어디서 나왔는지 신기할 정도입니다. 사진출처: 메가존 포트폴리오 페이지>

어디까지 해야 만족할 수 있을 것인가?

한번도 해본적이 없는 언어와 프레임워크로 첫 개발을 한 이후 계속해서 비슷한 개발 프로젝트를 많이 진행하게 되었습니다. C#으로 뭔가 개발한다 그러면 못할 건 없다는 생각을 또 가지고 있었으니까요.

하지만 계속 비슷한 프로젝트를 진행하면서 같은 언어 같은 프레임워크를 사용하는 것도 어느 정도 익숙해질 때 쯤 또 다른 언어와 프레임워크에 대한 경험을 해보고 싶다는 욕망(?)이 생겼습니다. 그때가 개발 8년차 때 쯤이었는데 안정적인 개발 프로세스를 원할 떄도 되었지만, 마음속 한켠으로는 또 다른 언어로 프로젝트를 해보고 싶다는 생각을 하고 있었습니다.

하지만 예전과 같이 회사쪽에 하자고 제안은 하지 못했고 그런 프로젝트를 할 기회가 오면 좋겠다고 생각했는데, 그 기회가 왔습니다. 기존에 계속 해왔던 윈도우 환경에서의 프로그래밍이 아닌 웹 프로그래밍을 할 수 있는 기회였고 그 프로젝트를 리딩하며 진행하게 되었습니다.

지금이야 웹 개발이라고 하면 프론트엔드, 백엔드의 구분이 정해져 있었지만 제가 웹 개발을 할 당시만 해도 앵귤러js가 한국에 유행하기도 전이었고 플래시가 유행하던 시절이라 프론트엔드 개발이라는 말 대신 rich internet application이라는 용어를 썼던 것 같습니다.

또 해보지 않았던 자바스크립트 언어와 해보지 않았던 extjs라는 프레임워크를 사용해서 프로젝트를 진행했고, 결과는 잘 개발이 진행되어서 예전보다는 많이 성장한 개발 능력을 객관적으로도 느낄 수 있었던 경험이었습니다. 이때까지 제가 개발을 잘 하기 위한 마음은 계속해서 새로운 언어, 프레임워크를 사용하고 시도하면서 그 성과를 보여주는 걸 생각했었던 것 같습니다.

<지금도 크게 어색하지 않은 extjs의 웹 화면, 제가 개발했던 당시에는 이 기술로 개발하는 사람이 많이 없었습니다. 사진 출처: sencha>

좋은 품질의 소프트웨어를 향해

지금 까지의 개발에 대한 마음가짐은 '다양한 경험을 해서 개발에 어려움이 없는 개발자' 였었습니다. 하지만 개발을 잘 하기 위한 프로세스나 방법, 문화 이런 것들에 대해서는 많이 생각해 보지는 못했던 것 같습니다. 개발자는 실력으로 보여줘야 하고 여러 언어와 프레임워크를 다룰 줄 안다면 그게 증명이 된 거라고 생각했었으니까요.

하지만 회사에서 개발하고 판매하는 솔루션 제품의 경우는 개발 실력도 뛰어나야 하겠지만, 그 제품을 잘 유지시키고 계속 업데이트 해서 만들기 위한 노력은 다른 능력을 요구한다는 걸 알게 되었습니다. 마침 시니어 개발자의 길을 걷게 되기 위한 팀원들도 정해지고 팀장이라는 역할을 하게 되면서 조금 더 생각을 많이 하게 됐던 것 같습니다.

좋은 품질의 소프트웨어를 만들기 위해 다양한 방법을 많이 시도했던 것 같습니다. 애자일 방식, 익스트림 프로그래밍 방식, 페어 프로그래밍, 테스트 기법 등은 이전에는 제가 인지하고 경험해보지 않았던 시도여서 이런 걸 도입하고 잘 실천하면 좋은 품질의 소프트웨어를 개발할 수 있을 것이라는 믿음도 있었습니다. 여러 시도를 했던 방법 중에 항상 다 잘 된 건 없었습니다. 어느 정도 정착되서 성과를 보일 수 있었던 방법도 있었지만, 이런 걸 한다고 해서 소프트웨어가 잘 만들어지는 것 하고 상관 없다는 느낌을 받았던 방식도 있었습니다.

저는 팀장이고 모범을 보여야 한다는 마음을 가지고 좋은 품질의 소프트웨어를 만들기 위해 많은 시도를 했는데, 가장 마지막에 깨달았던 중요한 원칙은 바로 '개발 프로세스나 규칙을 정할 때 팀원들의 동의를 구하고 합의가 이루어질 때 비로소 좋은 품질의 소프트웨어를 만들기 위한 마음도 생기게 된다' 였던 것 같습니다.

<익스트림 프로그래밍 방법 소개 그림, 여기 소개한 내용을 실천하고 따르면 소프트웨어가 잘 만들어질 것이라는 믿음을 가졌던 때가 있었습니다. 사진출처: extremeprogramming.org>

고객의 의견을 반영하는 유연한 소프트웨어

고객이 원하는 소프트웨어 제품을 만들어야 한다는 사실에 동의하지 않는 분들은 없을 겁니다. 크게 두 단계로 보면 하나는 개발 단계에서 요구사항을 반영해서 개발을 해 내는 단계가 있을 것이고, 다른 하나는 개발 완료 후 유지보수 단계에서 고객에게 추가 요구사항을 받거나 의견을 수렴해서 요구사항을 만들어서 개발을 하는 단계가 있게 됩니다. 저는 유연한 소프트웨어를 만들어야 개발 완료 후 유지보수 단계에서 고객의 의견을 반영하는 소프트웨어를 만들 수 있다고 생각합니다.

그러려면 어떤 마음으로 개발을 해야 할까요? 일단 기능 구현하고 동작하는 걸 확인하면 바로 배포해서 쓰게 만드는 소프트웨어는 초기에 그럭저럭 쓸만한 소프트웨어긴 할 겁니다. 하지만 소프트웨어는 처음부터 없는 상태에서 기능을 구현하는 경우 외에 기존에 구현된 코드 기반 위에 더 구현해야 하는 경우가 더 흔합니다. 이미 복잡도가 있는 상태에서 더 복잡한 코드를 만드는 일이 더 많다는 것입니다. 제가 얘기하고 싶은 건 유지보수가 가능한 소프트웨어 제품을 만들기 위한 마음을 가지기가 정말 쉽지 않다는 것입니다.

개발도 하고 이후 유지보수 개발을 추가로 했던 분이라면 항상 이런 마음일 것입니다.

아 처음부터 설계도 잘 하고 클린 코드로 만들고 리팩터링도 잘 해놨었어야 해!

그런데 처음 개발할 때 이런 마음으로 개발하면 좋은데 그러기가 쉽지 않은 게 현실입니다. 저는 계속해서 고객이 사용하고 또 의견도 내고 새로운 요청도 하는 소프트웨어를 개발하려면 정말 유연한 소프트웨어를 만들려고 하는 마음가짐이 필요하다고 생각합니다. 유지보수가 쉬운 코드는 많은 방법과 사례가 있고 많은 책에서 이론을 접할 수 있습니다. 개발을 잘 하는 능력에 유지보수 개발 능력이 포함되려면 소프트웨어를 잘 만들려는 마음가짐과 더불어 좋은 소프트웨어의 조건을 만족시키는 이해할 수 있는 코드 작성이나 테스트 단계를 거치게 하는 실천 능력도 필요하다고 생각합니다.

세상을 움직이는 소프트웨어

오랜 기간 동안 소프트웨어를 개발하면서 느꼈던 건, 소프트웨어 개발은 쉽지 않다 입니다. 그래도 또 개발을 할 것인가? 라고 하면 만들때의 고통 보다는 만들고 난 이후에 느꼈던 성취감 때문에 계속해서 하게 될 것 같습니다.

세상을 움직이는 정말 좋은 소프트웨어는 많습니다. 마이크로소프트 엑셀 같은 프로그램은 많은 사람들이 사용하고 계속해서 업데이트 버전이 만들어지는 훌륭한 소프트웨어입니다.

세상을 움직이는 소프트웨어는 사용자들이 쓰고 만족하고 계속 쓰게 만들 수 있게 생명력을 불어 넣는 일이라고 생각합니다. 그런 마음을 가지기 위해서는 좋은 품질의 소프트웨어를 만들 수 있는 능력이 필요하고 소프트웨어 생명 주기가 중단되지 않도록 각 단계 프로세스마다 소홀히 하지 않도록 능력도 필요하고 노력도 필요합니다.

저는 되도록 제가 개발하는 소프트웨어는 세상을 움직일 수 있는 소프트웨어라는 마음을 가지고 만듭니다. 그런 마음을 가지고 하루 하루 최선을 다해 개발한다면, 꼭 좋은 품질의 소프트웨어가 만들어진다고 생각합니다.

<소프트웨어 생명 주기, 어느 하나만 잘 해서는 안되고 각 단계별로 잘 할 수 있는 방법을 찾아서 적용할 수 있는 능력이 필요합니다. 사진 출처: bigwater consulting>

[jongfeel]

1월 16일 회신