개발도 결국은 상품을 만드는 일 — 기술 스택 선택이 납품과 유지보수를 결정한다

사이드 프로젝트로 모던 스택, 최신 버전을 가지고 신나게 만들어놓고, 정작 이것을 클라이언트에게 판매한다고 가정하니 이것저것 추가적으로 고려해야 할 부분이 생긴다는 것을 알았습니다. 어떻게 하면 코드의 품질을 일정하게 유지할 수 있을까, 어떻게 하면 생산성 있게 코드를 만들고 편하게 배포할 수 있을까, 배포된 코드가 무사히 돌아가고 있는지, 서버 자원은 적당한지. 이런 기술적 고민 이외에, 기술과 현실의 경계선에서 고민해야 할 것이 더 있다는 걸 알게 된 것입니다.

대부분의 웹서비스는 고급 기능이 필요하지 않다

소스코드라는 것도 그렇고, 데이터베이스라는 것도 그렇고, 웹서비스라는 수단을 이용해서 해결하고자 하는 문제는 모든 고급 기능을 다 수행할 필요가 없을 가능성이 높습니다. 쉽게 말해서, 대개의 소규모 웹서비스는 MongoDB가 필요 없을 가능성이 높고, 웬만한 로직은 PHP로도 충분히 구현할 수 있다는 것입니다.

제가 이 얘기를 왜 드리냐면, 클라이언트가 원하는 시스템을 만들어놓고 그 뒤의 관리에 대해서도 고민이 필요하기 때문입니다.

웹서비스에서 발생할 수 있는 문제들

웹서비스는 여러 가지 이유로 문제가 발생할 수 있습니다. 대용량 트래픽 부하로 서버가 크래시 날 수도 있고, 보안 취약점이 제때 패치되지 않아 해킹을 당할 수도 있고, 데이터베이스 용량이 다 차서 데이터 처리가 불가능할 수도 있습니다. 천재지변으로 클라우드 인프라가 불능 상태가 되는 경우도 있고, 소스코드 레벨에서 버그나 결함이 발견될 수도 있습니다.

소스코드의 치명적인 버그가 아닌 이상, 나머지는 큰 이벤트가 발생하지 않는 한 문제가 생기지 않을 것이므로, 고도화 계획이 없는 한 매일같이 상태를 들여다볼 필요는 없다고 생각됩니다. 물론 매일 확인할 여력이 있다면 좋겠지만요.

납품 후 취할 수 있는 두 가지 전략

클라이언트에 의해 홈페이지를 다 만들고 나면, 취할 수 있는 전략은 두 가지인 듯합니다.

첫 번째는 유지보수를 통해 주기적으로 비용을 받고 계속 신경 쓰는 것, 두 번째는 어느 정도 매뉴얼을 제공하고 더 이상 신경을 쓰지 않는 것입니다. 두 방법 중 누가 더 옳다고 판단할 필요 없이, 자신의 상황에 맞춰서 전략을 취하면 됩니다.

다만, 여러 사이트를 계속 개발하여 각 사이트마다 유지보수 비용을 받는 형식으로 사업을 영위할 생각이 없다면, 대개는 두 번째 방법이 더 낫다고 생각합니다. 웹사이트에서 발생할 만한 문제는 빈번하지 않으니 적당히 신경 써주고 보수를 받는 것도 좋은 전략이지만, 꾸준하게 관리를 해야 한다는 것은 때에 따라서는 번거로워질 수 있기 때문입니다.

매뉴얼 제공 방식이라면, 개발 단계부터 달라져야 한다

두 번째 방법, 어느 정도 매뉴얼을 제공하고 더 이상 신경을 쓰지 않는 방법을 고려하고 있다면, 개발 단계에서부터 신경 써야 할 부분이 있습니다.

이 블로그 시스템의 스펙을 예시로 들어보겠습니다. 해당 블로그는 Oracle Cloud를 이용하고 있고, Node.js로 개발되었고, Coolify로 CI/CD를 구성했고, 데이터베이스는 MongoDB를 사용하고 있습니다. Google Gemini AI API도 사용하고 있습니다. 도메인과 SSL을 제외하고서라도, 서버 유지를 위해 지출해야 할 비용의 채널이 Oracle, MongoDB Atlas, Google — 이렇게 3개입니다.

클라이언트 입장에서 생각해보기

저는 이 부분이 클라이언트의 입장에서는, 안 그래도 복잡한 웹서비스 관리에 혼란을 더할 것이라는 생각이 들었습니다. 클라이언트는 Oracle Cloud인지, MongoDB인지 하는 개념을 알 필요가 없습니다. 그리고 이렇게 지출되는 비용이 불필요하게 느껴질 것이라고 생각했습니다.

서버를 유지하는 데 들어가는 비용이 고정적으로 몇만 원씩 한다는 게 이해가 안 될 가능성이 있다는 것입니다. 해외 회사에 비용을 지출하는 것이니 세금계산서 발행도 어려울 수 있고, 된다고 하더라도 이 역시 복잡함으로 다가올 수 있습니다.

서버 유지 비용 최적화라는 해법

돈을 벌어야 하는 입장에서는 클라이언트를 설득해야 할 필요가 있을 것입니다. 그래서 좀 더 고민해보면, 서버 유지 비용은 최적화할 수 있습니다.

Node.js는 PHP로, 데이터베이스는 MySQL로 바꾼다면, 국내 호스팅사에 가장 저렴한 상품으로 사이트를 구축할 수 있습니다. 대개의 클라이언트가 만들고자 하는 사이트는 꼭 Node.js를 이용할 수밖에 없는 비즈니스 로직이 필요하다거나, MongoDB를 써야 하는 데이터 처리가 필요하지 않을 가능성이 높습니다.

최적화를 하고 나면, 클라이언트는 이후 서버 유지 비용을 더 저렴하게 관리할 수 있게 되고, 국내 호스팅사에 지불하는 방식으로 좀 더 간편해질 수 있습니다.

목적에 따라 기술 스택을 선택하는 관점

팔려고 만드는 서비스인지, SaaS를 위한 서비스인지, 취미를 위한 서비스인지에 따라, 개발할 때부터 어떤 언어를 쓸 것인지, 어떤 데이터베이스를 쓸 것인지를 미리 고민해보면 좋겠다고 생각했습니다.

아직까지도 PHP와 MySQL이 많이 사용되는 이유는 어쩌면, 초기 탄생부터 시간이 흘러서 인프라가 제일 많이 구축되어 있어서 비용이 저렴하기 때문에, 클라이언트를 설득시킬 수 있는 요소가 더 많기 때문일지도 모르겠다고 생각했습니다.

팔려고 만드는 서비스인데 모던 스택이 좋다고 개발해놓고 나면, 정작 외주 요청을 받아서 그 시스템을 납품하려고 할 때 작업을 두 번 세 번 더 할 수도 있습니다. 어떤 시장에서 개발을 할 것인지에 따라 자신이 어떤 스택을 활용해야 할지 고려해보고 방향성을 정해보는 관점도 꽤 괜찮다고 느꼈습니다.