내 프로젝트 맞춤 개발자 찾기 : ②프로젝트를 좌우하는 기술 스택

[내 프로젝트 맞춤 개발자 찾기] 이전 글 보러 가기

내 프로젝트 맞춤 개발자 찾기 : ① 개발자라고 다 같은 개발자가 아니다?

오늘은 지난 글에 이어, IT서비스의 유형과 받아보고 싶은 결과물의 종류에 따라 어떤 부분을 챙겨야 할지, 개발팀을 꾸릴 때 감안해야 하는 부분을 소개하겠습니다.

얼마 전, 규모가 그리 크지 않은 병원 프랜차이즈에서 자신들만의 '고객용 사전 문진 서비스'를 만들어 진료에 활용하고 싶다는 내용을 전달받았습니다. 사전에 관리자가 질문을 설정해두면 고객이 온라인으로 답변하고, 병원 방문 시에 의사가 해당 내용을 참고해 진료하는 '온라인 보조차트'를 만드는 것이었습니다. 질문 유형에 따라서는 초민감정보에 해당될 수 있는 의료 기록이니 보안이 철저해야 했지만 개발 난이도는 높지 않은 상황이었는데, 개발사 섭외 과정에서 문제가 발생했습니다. 

무려 예산의 3배에 달하는 견적이 산정된 것입니다. 깜짝 놀라 직접 연락해보니 재미있게도 '개발사 대표님의 전공'이 원인이었습니다. 인공지능과 머신러닝 분야를 전공해 '의료업종'과 '의료차트'라는 것에 집중한 나머지, '환자의 사전 설문만으로도 대강의 처방내용이 산출되는' 엄청난 시스템을 생각한 것입니다. 다행히 빠른 시기에 방향을 재설정할 수 있었고, 예산 내에서 프로젝트를 마칠 수 있었습니다. 사실 이런 문제는 현장에서도 흔하게 일어납니다. 개발사의 전문분야와 성향에 따라 고객의 요구사항들이 다르게 받아들여질 수 있기 때문입니다. 이런 경우 프로젝트를 의뢰하는 쪽에서 기본적인 방향성을 가지고 있다면, 훨씬 깊이 있고 효율적인 결과를 만들어낼 수 있습니다. 

IT서비스를 구성하는 또 다른 요소, 하드웨어 스택

지난 화에서 말씀드린 프론트엔드와 백엔드는 '소프트웨어 스택'이라고 합니다. 이와 달리 손으로 만질 수 있는 물리적인 기기 자체는 '하드웨어 스택'이라고 합니다. CPU의 속도나 하드 드라이브의 용량, 네트워크 방식 등의 스펙을 선택하실 수 있습니다. 하나의 IT서비스가 세상에 선을 보이기 위해서는 어느 하나 소홀히 할 수 없는 필수적인 부분이며, 일반적으로 이 둘을 합하여 '기술 스택(Tech stack)'이라고 합니다. 예전에는 개발사의 선택에 맡기는 것이 일반적이었지만, amazon의 AWS 또는 MS의 Azure와 같은 클라우드 서비스가 인기를 얻게 되면서 목적에 맞는 선택을 할 수 있게 된 것입니다. 

1) 서버와 데이터베이스

백엔드 개발자가 담당하는 부분은 소프트웨어적인 서버/DB 관리 언어입니다. 물리적인 기기 그 차체로서의 서버와 데이터베이스(DB)를 말하는 하드웨어 영역을 담당하는 것은 인프라 엔지니어입니다. 쉽게 말해, 화재나 홍수 등으로 해당 기기가 피해를 입었을 때, 컴퓨팅 파워의 부족으로 램이나 저장장치(하드 드라이브 등)를 확장해야 할 때 또는 사용하는 운영체제(OS)나 보안 업데이트가 필요한 경우에 필요한 것은 백엔드 개발자가 아니라 인프라 엔지니어입니다. 

만약 회사 내에 서버나 DB를 두었다면 안정적인 서비스를 제공하기 위해 인프라를 전담하는 직원이 반드시 필요합니다. 이 때문에 어떤 언어로 어떤 시스템을 구축할지만큼 중요하게 고려해야 하는 것이 해당 기기를 어디에 둘 지에 대한 부분입니다. 예전에는 회사 내에 두는 것이 일반적이었지만, 요즘은 구글이나 아마존 등에서 제공하는 클라우드 서비스를 이용하는 경우도 증가하고 있습니다.

2) 온프레미스(On-premise)

회사 내에 자체적으로 서버와 DB를 구성하는 전통적인 경우입니다. 대개 예상되는 최대치의 사용량에 맞춰 기기를 장만하게 되기 때문에 초반에 적지 않은 비용이 소요될 수 있습니다. 하지만 데이터 관리에 대한 독점적인 권한을 가질 수 있다는 장점이 있습니다. 다만 시스템 규모를 유연하게 변경하는 것이 힘들고, 패치 또는 업데이트가 필요한 경우에 자체적으로 해결해야 하므로 신중하게 고민할 필요가 있습니다. 

3) 클라우드 서비스(Cloud Service)

말 그대로 '구름 위의 어딘가'에 서버와 DB를 구축하는 것입니다(실제로는 어느 한적한 산속이나 시골 벌판일 확률이 높습니다). amazon의 AWS 또는 MS의 Azure와 같은 클라우드 서비스를 이용하는 경우 가장 큰 장점은, 사용한 만큼만 비용을 지불할 수 있다는 점입니다. 기본적으로 시스템의 규모를 매우 유연하게 변경할 수 있고, 원한다면 전 세계 각지에 데이터를 백업해둘 수도 있습니다. 하지만 이러한 기능을 이용하기 위해서는 생각보다 비싼 비용이 들어가는 것이 사실이고, 기업의 핵심 경쟁력인 데이터를 외부에 보관을 한다는 것 자체를 불안하게 바라보는 시각도 존재합니다.

프로젝트에 따른 기술 스택 선택의 요령

지금까지 IT서비스의 ‘기술 스택' 전반의 개념에 대해 설명했습니다. 그래도 여전히 막연한 분들을 위해 프로젝트의 목적과 상황에 따른 기준을 알려드리려고 합니다.

1) 비즈니스 단계에 따른 스택 선택하기

프로그래밍 언어에도 트렌드가 있습니다. 우리나라에서는 자바(Java)라는 언어를 사용하는 비율이 가장 높습니다. 파이썬(Python)의 인기도 높아지는 추세지만, 개발 측면에서 봤을 때 이 언어들은 결코 가볍지 않습니다. 단순한 PoC(아이디어의 콘셉트를 설명하는 것)를 위해서 MVP 제작만을 원하는 경우, 이러한 언어로 시작하는 것은 과잉 개발(Over Engineering)로 빠지는 지름길이 될 수 있습니다. 또한 해당 언어에 따르는 개발 방식 때문에 중간에 어떻게 진행되고 있는지 파악하기가 쉽지 않다는 단점도 있습니다. 따라서 프론트엔드와 백엔드 모두 자바스크립트(Javascript)를 사용하는 것이 효율적입니다. 예를 들면 다음과 같은 구성을 생각해볼 수 있습니다.

2) 비즈니스 목적에 맞는 언어 선택하기

서비스를 구축해 운영되고 있는 상태라면 여러 가지 요구사항이 발생하고, 개발팀은 최대한 운영팀의 요구에 맞추기 위해서 노력할 것입니다. 하지만 서비스 구축 시에 사용된 언어의 특성 때문에 때로는 우회적인 방법을 쓰거나, 억지로 끼워 맞추는 방식으로 해당 기능을 구현하는 경우도 있습니다. 이렇게 해당 언어의 특성에 반하는 적용 방식은 시간이 흐를수록 시스템 전체의 효율성을 저하시키게 되는데요. 이것을 '기술 부채(Technical debt)'라고 합니다. 그렇기에 비즈니스 목적에 맞는 언어를 선택하는 것이 중요합니다. MVP를 지나 정식 론칭을 준비한다면, 다음을 참고하여 적합한 언어를 선택해보세요.

3) 비슷한 서비스를 제공하는 마켓리더의 기술 스택 참고하기

완전히 똑같은 서비스가 아니더라도 마켓에는 이미 수많은 리더들이 있고, 이들은 시행착오를 거쳐 자신들만의 기술 스택을 구성하고 있습니다. 자신들의 기술 스택을 공개하는 'Open stack'이 세계적으로 유행하고 있어 해외뿐만 아니라 국내 IT리더들의 기술 스택을 쉽게 엿볼 수 있습니다. 이를 참고하면 주로 어떤 기술이 함께 사용되는지 대략적으로 파악할 수 있으며, 가급적이면 많이 쓰이는 언어와 입증된 스택을 따라가는 것이 여러모로 유리합니다.

마치며

서비스에 꼭 알맞은 기술 스택을 선택하는 것은 쉽지 않은 문제입니다. 하지만 모든 것을 개발사의 선택에 맡겨버리면 당초에 원했던 것과는 다른 비용, 다른 목적을 가진 결과물을 전달받을 수도 있습니다. 우리나라처럼 워터폴(Waterfall) 방식의 프로젝트 진행이 일반화된 환경에서는 더더욱 그렇습니다. 서비스, 시스템의 유형이나 프로젝트의 규모에 따라 달라지는 부분이기에 절대불변의 정답은 찾을 수 없겠지만, 이 글이 보다 나은 선택을 위한 가이드가 되기를 바랍니다.