서론
며칠 전 알게 된 사람으로부터 하나의 영상이 왔다. 영상의 내용은 한 스타트업이 기술을 어떻게 선택했고, 그 결과로 겪게 된 좌충우돌의 성장기였다. 내가 스타트업 개발자로 들어가게 된 탓에, 그리고 여기의 유일한 백엔드 개발자인 탓에 이 영상을 보내준 것으로 보였다. 시간이 날 때 봤으면 좋겠다는 짧은 문구에 나도 가벼운 마음으로 답했다. 이 사람이 내가 잘 되길 바라고, 보고 배울 만한 걸 보냈구나 싶어 감사하다는 말과, 오늘 보겠다는 말을 했다. 적당히 할 일을 다 끝낸 밤 11시, 영상을 보니 2시간이 약간 넘는 길이였다. 오늘 다 보는 게 애당초 불가능했지만, 감사한 마음으로 영상을 보았다.
꽤 긴 시간이었지만, 영상은 무사히 잘 봤다. 기술 공부만을 하던 나로서는 모르는 내용이 많았다. 어떠한 이유로 기술을 선택해야 하고, 어떻게 발전시켜 나가야 하는지, 단순히 코드의 성능과 퀄리티만을 따져서는 모를 내용들이 수두룩 했다. 다만 기술 선택에 대해서는 마침 나도 고민하고 있던 참이라 참으로 값진 내용이었다. 생산성을 높이기 위해 고민하는 것은 당연하지만, 그 외에도 혹시나 회사가 잘 굴러갈 경우 개발자 인력 수급을 빠르게 할려면 커뮤니티의 크기도 고려해야 했고, 같은 이유로 내가 퇴사할 경우에 대한 도의적 책임도 고려해야 했다. 나만 아는 걸 썼다가는 대표와 개발자에게 너무 미안할 테니깐. 이러한 내용들에 도움을 준 기준들을 공유하고자 한다. 본 것은 많았지만, 나로서는 아직 경험하지 못한 부분, 또는, 그래서 이해할 수 없는 부분은 쓰지 않았다. 이해하지도 못하면서 영상 한 번 봤기로서니 내 경험인 양 쓰는 건 피하고 싶었다.
"이 글은 직접적인 기술을 언급하거나 비교 분석하지 않습니다."
"언제나 그랬듯이, 더 좋은 의견, 생각이 있으시면 기탄없이 말씀 부탁드립니다. 서로 아는 걸 공유하고, 배울 수 있는 기회가 더 많아지기를 바라고 있습니다."
기술을 어떻게 선택하는가?
1. 기본적으로, 기술은 익숙한 게 좋다.
어떤 언어를 골라야 할까, 그리고 어떤 데이터베이스 모델과 서버 프레임워크를 사용해야 할까. 각 프레임워크의 장단점과 성능을 비교한 글은 많고, 또 그 글들이 시사하는 바 역시 크지만 어느 것 하나 절대적이라고 말할 수는 없는 것 같다. 어떻게든 기술적 한계는 극복되거나 우회책이 있기 마련이고, 사용자 입장에서 차이가 없다면 그 수치들은 별 의미를 갖지 못한다. 그래서인지 내가 본 대부분의 팀은 팀원들이 공통적으로 잘 아는 기술을 선택했고, 또 주워 듣기로는 그 외 대부분의 팀들이 이런 방식으로 시작을 했다고 한다. 오히려 건너 듣기로는, 유행을 따라간 쪽이 부진을 겪고 있다고 했다. 물론 팀이 성장함에 따라 아예 처음 보는 기술을 다뤄야 할지도 모르지만, 그거야 그 기술의 전문가를 영입해와서 시작해야 할 일이지, 아무도 모르는 상태에서 무작정 시작할 일은 아니다. 기술적 도전도 좋지만 정도를 벗어난 도전은 그저 무책임한 것이라고 생각한다.
2. 스타트업은 빠르게 결과를 내는 게 중요하다.
기술의 선택은 사실 경영에 달려 있어야 한다. 스타트업 같은 경우는 빠르게 결과를 내는 게 중요한데, 이는 시장에서의 반응을 보기 위함이다. 어차피 안 될 거라면 아이템을 바꾸는 게 나은데 첫 작품부터 심혈을 기울여서 뭐하겠는가. 개발자들이 예술가 마냥 단 한 줄의 코드에 심혈을 기울이고 있으면 결과를 낼 수 없고, 조직은 유연성이 떨어진다. 개발자들이 늘상 말하는 "대표가 개발자여야 한다."는 말도, 이런 관점에서 보면 부적절할 수도 있겠다. 나도 어떤 부분에서는 매우 공감하고 있지만, 대표가 잘해야 하는 건 팀원들을 굶기지 않는 일이다. 개발자들을 하나 하나 이해하고 일을 맡기기에는, 대표에게 주어진 짐이 너무 무거울 수도 있겠다.
3. 그렇다고 코드를 개판으로 짜라는 건 아니다.
이미 제목에 다 써있다시피, 앞서 한 말들이, 코드를 개판으로 짜라는 의미는 아니다. 코드의 퀄리티는 당연히 유지되어야 한다. 물론 속도가 중요하다면서 동시에 퀄리티는 유지하라는 게 무슨 소리인가 싶을 수 있겠지만, 그거야 라이브러리나 프레임워크 선택 시에 고민할 문제이지, 코드를 작성하는 단계에서 다룰 게 아니다. 이는 어느 한 쪽을 포기하라는 의미가 아니다. 코드를 저품질로 유지하게 되면 다음 번에 들어올 팀원들은 심한 갈등을 겪을 것이다. 어쩌면 당신에게 타당한 이유가 있더라도,
'질문하자니 이 사람한테 왜 이것도 모르냐고 하는 것 같은데...'
이런 생각이나 하면서 질문하기를 포기할 것이다. 생각해봐라, 당신이 회사에 입사했는데 서버 개발자가 RESTful API가 뭔지도 모른다. URL 경로 상에는 BASE64로 인코딩할 수 없는 문자가 포함되어 있고, 코드는 몇 년이나 뒤처진 옛 방식을 고수하고 있다. 이 사람에게 질문을 하는 건, 이 사람의 실력을 비판하는 거나 마찬가지처럼 느껴지기 마련이다. 그렇다고 이걸 말 없이 고칠 수도 없으니, 결국에는 이야기를 해야 하는데 이 때 상당한 스트레스를 받게 될 것이다. 결국에는 의사소통 비용이 발생한다. 정말로 몰라서 그렇게 한 거라면 어쩔 수 없는 일이지만, 만약 알면서도 코드 품질을 떨어뜨리면 인력 수급에 차질이 생길 것이다. 어쩌면 그 사람이 회사 코드를 구경하다가 채용 프로세스를 박차고 나갈지도 모르겠다.
4. RDB vs NoSQL, 데이터베이스 모델 선택하기
서버 쪽은 각 언어마다 사실 상 프레임워크가 결정되어 있다 보니 그렇다 치지만, DB는 RDB와 NoSQL 중 무엇을 고를지, 그 특성이 달라 고민이 될 수 밖에 없다. 둘 중 하나 밖에 모른다면 고민할 것 없지만, 만약 둘 다 알고 있는 상황이라면 자신이 어떤 프로그램을 개발하고 있는지를 따져봐야 한다. 보통은 GET, POST 등의 요청 중 어느 쪽이 더 자주 일어나는가를 두고 고민한다. 예컨대 채팅 서비스를 구현해야 한다면 쓰기 성능이 중요하다. 이 경우에는 쓰기 성능의 무한한 확장이 가능한 NoSQL이 RDB보다 나을 수 밖에 없다.
- 트래픽이 증가할 때 문제가 없는지.
- 장애 발생 시 원인을 찾기 쉬운지.
- 이 부분은 커뮤니티가 얼마나 크고, 또 활성화되어 있는지에 달려 있다.
- 데이터 분석을 염두해두고 있는지.
당장 떠오르는 것은 이 세 가지이다. 하지만 비용적인 측면이 고민된다면, 그리고 아직 사용자가 적다면, 구글에서 제공하는 파이어베이스처럼 무료로 사용할 수 있는 것을 찾아봐도 좋겠다. 나는 이런 서버리스 도구들을 아무런 이유 없이 '별로' 라고 생각해왔는데, 찾아보니 생각보다 괜찮은 것들이 많았다. 실제 스타트업들은 자원이 매우 적기 때문에 관리 비용을 줄이는 데에 더 신경을 써야 하기 때문에, 이런 식으로 비용을 절감할 수 있는 방향으로 가는 것도 매우 좋다.
TCO (총 소유 비용) = 주 비용 + 관리 비용
5. 미래에 도입할 아키텍처를 대비하기
사업이 잘 굴러간다면 코드는 점차 커지게 된다. 이런 경우 코드의 가독성이 떨어지고, 새로운 기능을 추가하기가 무척이나 힘들어진다. 따라서 코드를 분리하고 모듈화할 필요가 있는데, 이런 경우를 대비해 나중에 분리할 부분을 미리 설계에 반영해두어야 한다. 나는 이걸 보고 종이의 절취선을 떠올렸다. 미리 표시해둔, 그리고 자르기 편하게 점선을 그어둔 부분이 있다면 종이를 일정하게 자르기가 수월해진다. 코드 역시 마찬가지라 미리 차근차근 단계를 밟아 준비해두지 않으면 나중에 그 비용이 커지게 된다.
하지만, 너무 미래적인 코드는 지양해야 한다. 기술을 도입하는 건 단기간에 이루어지는 게 아닐 뿐더러, 사실 초기에 생각한 것은 나중에 다 달라지기 마련이다. 생각한 것이 틀렸을 수도 있고, 더 나은 방법이 생각날 수도 있다. 또 아예 기획의 방향이 달라져서 도입할 필요 자체가 사라질 수가 있다. 어떤 기술을 도입할 것인지에 대한 생각은 미리 해두면 좋고, 또 꾸준히 고민해두면 더 좋은 결과가 나올 수 있지만, 그걸 미리 반영해두는 건 너무 위험하다. 아직 필요하지도 않은 코드를 미리 개발하는 건 복잡성만 늘릴 뿐더러 팀원 간의 협업을 망치는 주된 요인이다. 코드로 구현하는 것은 아이디어와 요구사항이 모두 확정될 때로 하자.
6. 때로는 노가다도 나쁘진 않다.
배달의민족이 어떻게 시작했는지는 유명하다. 그래서 나는 다른 비유를 들고자 한다. 예전에 내가 모 창업재단에서 하는 데모데이에 참석했다. 그 데모데이는 5개의 스타트업들이 나와서 사업에 대해 소개하는 시간을 갖는데, 신생 스타트업들임에도 불구하고 배울 게 많은 회사들이 즐비했다. 그 회사 중 하나의 이야기이다. 사업을 소개하면 대충, '소심한 사람들을 대신해서 인공지능이 접수를 받아 대신 식당을 예약해주는' 일을 하는 회사였던 것 같다. 신생 스타트업인데 인공지능이라니, 그 당시는 아직 인공지능이 지금처럼 당연시 되지 않았던 탓에 다들 의아해했다. 그래서 한 전문투자자 분께서 직접 질문하셨다.
VC : "아니, 어떻게 초기 스타트업이 인공지능을 개발했어요?"
대표 : "사실, 초기에는 다 사람이 처리했고 인공지능인 척 했고요, 나중에 수익화된 다음에는 확신이 생겨서 개발에 착수했습니다."
궁금해하던 차에 누군가 대신 질문했고, 대표는 대답했다. 솔직히 말하면 지금도 '어, 이래도 되는건가...' 싶긴 한데, 어쨌거나 이 대표의 전략은 성공적이지 않았나 싶다. 솔직히 말해서, 될지 안될지 모르는 사업에 큰 비용 투자해서 기술을 개발하고 싶지는 않을 것이다. 개발 측면에서도 마찬가지라고 본다. 어떤 페이지를 급히 만들어야 하는데, 이게 일회성 마케팅이 될지도 모른다고 한다면 굳이 React나 Vue 같은 프레임워크를 쓸 필요가 있을까. 그냥 HTML, CSS로 급조하는 것이 더 나을 것이다. 뭐든지 완벽함을 꾀하는 것도 좋지만, 딱히 프레임워크를 쓰지 않았다고 어수룩한 코드가 되는 것은 아니니깐.
결론
사실 기준이라기엔 너무 적고 모호하다고 느꼈을 수도 있다. 그래서 하나 더 기준을 제시하자면,
이전에 봤던 개발자 영상 중에 그런 내용이 있었다. 중요한 것은 비즈니스적인 생각이라는 건데, 우리가 어떤 기술 스택을 원하는지가 중요한 게 아니라 사업에서 요구하는 속도가 더 중요하다는 얘기였다. 결국 세밀하게 보면 이 또한 중요한 건 '돈'이라는 내용이었다. 당장 급하게 개발이 필요하면 멋진 기술 스택을 고민할 게 아니고 당장 써먹을 수 있는 걸 해야 한다는 것. 예컨대 JavaScript로는 jQuery가 가장 빠르다면 그냥 jQuery 쓰는 게 맞다는 게 요지였다. 또 LinkedIn에서는 그런 글도 봤다. 돈을 혐오하고, 또 돈에 관한 얘기를 하는 걸 혐오하는 사람들이 있는데 비즈니스에서 가장 중요한 건 결국 돈이라는 얘기였다. 이 또한 타당한 이야기였다. 사람에게 공기가 중요하듯, 기업에게 중요한 건 돈이니까. 각 일의 중요성에 대한 고저차는 없다고 생각하지만 개발보다 넓은 범위를 생각하는 사람들은 늘상 이런 조언을 건넨다.
"경영가 마인드로 생각해야 해요, 당신이 개발자든 디자이너든."
이런 말에는 백 번이고 동의한다. 사실 틀린 게 아니다. 하지만, 늘상 그 반대 측에 있는 사람들이 그래왔던 것처럼, 돈보다 중요한 것은 사람이고, 또 기업에 중요한 것은 가치라는 점 역시 진리이다. 이 의견들은 서로 대립하는 의견이 아니다. 사실 이 양 극단의 있는 사람들이야말로 서로의 의견을 충분히 이해하고 있을 것이다. 가운데 서서 돈을 혐오하거나, 이상(理想)을 추구하는 걸 무작정 과대망상증으로 여기는 사람들과 달리, 양극단은 어렴풋이 서로가 같은 걸 말하고 있음을 알고 있는지도 모르겠다. 사람이 있어야 돈을 벌 수 있다거나, 돈이 있어야 사람이 있다는 식으로, 서로 이해하고 있을 것이다. 이러한 관점 때문에 사실, 객관적인 수치를 통해 기술을 언급하는 건 무의미하다고 느꼈다. 개발을 하는 게 언뜻 예술같은 면이 있다고 치더라도 개발자는 예술가가 아니다. 자기만족이 아니라면 전체적인 시각, 경영자나 조직 관리의 시각에서 기술을 볼 필요가 있겠다.
