brunch

You can make anything
by writing

C.S.Lewis

by 신현묵 Jan 18. 2017

IT기업이 만들지 말아야 할 12가지 제품들..

스타트업이나 IT기업이나 하지 말아야 할 기능과 제품, 솔루션

SaaS의 시대이고, 오픈소스의 시대이다. 기업은 자신들의 제품과 서비스를 통하여 비즈니스 모델상에서 동작 가능한 가치에 집중해야 한다. 

정말, 더 이상 만들지 말아야 할 제품들이 있다.


IT기업에서 가장 귀중하고 관리를 잘해야 하는 것은 '개발자'의 시간과 노력이다. 귀중한 이 개발자원을 기반으로 자사의 서비스를 강화하고, 마켓에서 반응을 일으키고, 고객의 호주머니를 여는 '곳'에 사용되어야 한다. IT조직의 개발 리소스는 정말로... 해당 기업의 서비스를 만드는 것에 집중해야 한다. 이것을 잊으면 안 된다.


하지만, IT조직이 비대화되면서 해당 조직이 '이미 만들어진 것'을 개선하겠다거나, '또 만들겠다'라고 주장하는 경우가 간혹 있다. 분명, 그 어떤 '이유'때문에 만들고자 고집하는 것인데... 대부분 그 '이유'는 그냥 '고집'일 경우가 대부분이다.


정말 만들지 말아야 할 것이거나, 이미 존재하는 것들의 가격이 충분히 의미 있는 가격인 경우에 '해당 제품'을 또 만드는 것은 정말 무의미한 행위와 행동들에 해당한다고 이야기를 하겠다.


그냥, 사서 쓰는 것이 간단하고, 편하고, 정확하다.


혹은, 오픈소스 형태나 솔루션의 형태로 GitHub나 SourceForge에서 손쉽게 구할 수 있다. 더 이상 만들지 말아야 할 솔루션들을 몇 가지 소개한다.


12. 화상회의 제품, 메신저 제품

대학교 졸업 발표회에 가장 많이 보이는 것이 1:1 의 화상회의이거나, 메시징을 교환하는 채팅 프로그램을 간단하게 만들고, 카카오톡을 뛰어넘는 서비스라고 열변을 토하는 '학생'들이 가끔 있다. 미안하지만, 수백만, 수천만의 사용자들이 메시징을 교환하는 서비스는 이제 또 도전한다는 것이 거의 무의미한 상황이다.

그냥, 공짜로 변해버린 메신저 시장이거나, 특정 화상회의 솔루션들의 가격에 맞는 제품들을 적당하게 구매해서 사용하면 된다. 이런 솔루션을 만든다는 스타트업이나 IT기업이 있다면.. 거리를 두자.

1:1의 화상회의나 메시징은 공개형이거나 오픈소스 형태로 너무도 많다. 오히려, 기업의 경우에 화상회의의 기록을 관리하고 PPT자료들을 공유하기 위한 기능들이 탑재된 기업형 제품들이 정말 많다. 선택하고, 고르면 된다. 만들려고 하는 '개발자'가 있다면.. 도시락 싸들고 다니면서 말리자.


11. 회계 관련 소프트웨어

ERP라고 불리거나, 회계관리 소프트웨어라고 불리는 제품들은 이제 월 4~10만 원 정도면 그냥 사용할 수 있는 제품들이 많다. 그냥, 적당한 제품을 적당한 수준으로 고르는 것이 좋다. S전자처럼 엄청 거대한 기업이라고 하더라도 기존에 투자한 ERP 제품들을 전사적인 규모에 맞는 SAP과 같은 솔루션을 도입한다.

아니면, SourceForge에 가면 오픈소스 형태의 ERP가 차고 넘친다. 심지어, 소스는 오픈하고, SaaS 형태로 저렴하게 제공되는 서비스들도 정말 많다. 인도의 업체들 중에 쓸만한 SaaS를 하나 골라서 사용하거나, 오픈소스 형태로 되어있는 것을 설치형태로 사용해도 된다. 그냥, 고르고 선택해서 사용하면 된다.

ERP를 혹시라도 2017년도에 신규 개발하겠다고 하면.. 도시락 싸들고 다니면서 말려야 한다.


10. PC OS?

설마. 아직도 PC용 OS를 개발하겠다는 무지몽매한 이야기를 하는 사람이 있거나 IT조직이 있다면, 조금은 거리를 두고 생각하기를 바란다. 차라리 그 개발 능력으로 새로운 디바이스나 네트워크 상황에 맞는 멀티 OS를 만든다면 모를까... PC용 OS를 만들겠다는 것은 마치, '바퀴'가 있지만, '세모형 바퀴'를 만들겠다는 소리에 가깝다. 뭐... 세모 모양의 도로가 만들어지면 모를까... 이것은 전혀 삽질에 가까운 목표이고 방향성이다.


9. 성능 관련 솔루션과 성능 프레임워크

한두 대의 Was의 가용성과 웹서비스 트랜잭션, 데이터 수집을 위해서는 Scouter면 충분하다. 하지만, 기업의 경우에는 선택할 수 있는 제품이 시장에 넘치고 있다. 하이브리드나 클라우드 형태의 APM솔루션들은 이미 시장에 차고 넘치고 있다고 간단하게 설명하겠다. 

각 회사의 형태에 맞추어서 APM을 선택하면 된다. 미국에서 서비스를 한다면 New Relic의 SaaS 형태의 서비스로 충분하다. 비록, 실시간은 아니지만 장애 상황 이후에 데이터 분석을 위해서는 AppDynamics제품을 선택할 수 있다. 

또한, 국내에는 설치형에서 오래된 전통을 자랑하는 제니퍼소프트와 클라우드 형태를 고려하고 있다면 와탭랩스의 제품을 선택할 수 있다.

만일, 국내 IT회사나 집중해야 할 서비스가 있는 IT기업이라면 '적절한 APM 제품이나 서비스'를 고르면 되는 것이지, APM솔루션을 굳이 개발하겠다고 하는 조직이 있다면... 쓸데없는 작업이 될 가능성이 크거나, 오픈소스 기반으로 만들어진 것을 대규모의 형태에서 서비스 관리를 하겠다는 것은 전혀 맞지 않는 구성이 될 가능성이 높다고 하겠다. ( 물론, BizOps를 고민할 수 있지만, BizOps는 단언컨데 APM에서 해야할 일이 아니다. 이 내용은 따로 정리할 생각... )

더 중요한 것은 그렇게 만들어진 제품이 지속적으로 운영될 것이라고는 큰 기대하지 않는 것이 좋을 것이다.


8. 분산 캐시

분산 캐시도 빅데이터의 이슈와 같이 이야기되던 분야다. Scale-Up과 Scale-Out은 언제나의 화두였다. 그냥, Resource를 Scale-Out 하는 방법은 비용으로 해결 가능하고, 대부분 많이 사용하는 읽기나 쓰기를 분산하는 방법을 사용할 때에 분산 캐시를 사용한다.

돈만 많다면 Oracle도 이 기능을 지원한다. MySQL도 유료버전을 사용하면 된다. Replication은 이제 '돈'내고 사용하는 서비스로 충분하다. DBMS의 가용성도 그냥 '분산 캐시'의 형태로 사용할 수 있다.

이 분산 캐시 관련 상용 솔루션, 오픈 소스도 차고 넘친다. 그냥 잘 고르면 된다. 오히려, 도메인 지식이 부족해서 적당한 제품과 서비스를 고르지 못할 뿐이다.

고로... 분산 캐시 뭐를 만든다는 개발자나 개발팀이 있다면... 흠... 음... 저는 도시락 싸들고 다니면서 말립니다.


7. 검색엔진

elasticsearch만으로도 충분합니다. 제2의 페이스북이나 제2의 구글이 목표가 아니라면, 그 정도가 적당하다. 대표적 사용례로써 골드만삭스는 매일 5TB가 넘는 데이터를 저장하고 검색하는 용도로 엘라스틱을 사용한다. 자바언어 기반으로 만들어진 루씬을 기반으로 구성된 엘라스틱은 그 자체로 이미 완성형이다.

사용자 위치정보, 다국어, 자동완성, 미리보기, 철자 수정 기능 등의 기능은 둘째이고, 이미 여러 개의 노드로 구성된 분산형에, 단위 프로세스로 부분 색인과 검색 기능, 새 노드를 확장하는 것이나, 각 노드 분산 저장 기능과 복사본을 분산하여 저장하는 보호 기능과 Discovery 기능도 내장해서 이미 시스템 관리자도 필요 없다.

엄청난 가용성과 높은 안전성으로 엘라스틱의 기본 기능을 넘는 '요구사항'을 찾기도 어렵다.

그냥, 엘라스틱을 사용하면 된다.

누가 만들겠다면... 저는 도시락 싸들고 다니면서 말립니다.


6. 워크플로 엔진

BPM도 이제는 더 이상 그 누구도 만들지 않는다. 상태가 변화하고 상태를 표시하고, 그 상태를 사용하는 것은 인터넷을 조금만 검색해도 오픈소스가 엄청나게 많다. BPM은 더 이상 '고성능'이 그다지 필요한 상황이 아니다. 그냥, 가져다 쓰면 된다. 

누가 만든다고요? 흠...


5. 쇼핑몰 엔진

제2의 아마존을 꿈꾸거나, 제2의 알리바바를 꿈꾸는 정도가 아니라면, 굳이 생각할 이유고, 고려할 이유도 없다. 엄청난 비용과 엄청난 시간을 들여도 비슷하게 만들기 어려울 것이다. 

사업의 본질에 집중하고 아마존이나 알리바바에 들어가는 것이 현명하다. 물론, 독자적인 e-커머스를 별도로 구성하겠다는 야망이 있다면 도전을 하는 것은 말리지는 않는다.

하지만, 아는가? 온라인 쇼핑몰 엔진은 이제 만드는 것이 아니다. 그냥, 사다 쓰는 것이다. 아니면, 적당한 오픈소스 가져다가 쓰세요.


4. 레포팅 엔진

아직도, 레포팅 엔진을 만들겠다는 사람이 있다는 것이 놀라울 뿐이다. 그냥, 적당한 레포팅 엔진을 구매하는 것이 현명하다. 뭐랄까... MS-Office의 엑셀을 구매해서 사용하면 되는 것이지, 엑셀을 만들 필요는 없다. 똑같다. 레포팅 엔진은 만드는 것이 아니다. 구입해서 사용하는 것이다.

아! 하긴.. 가끔 MS-Office를 넘는 제품을 만들겠다는 욕심을 부리는 경우가 있지만, 오픈형태의 오피스들도 이미 차고 넘치고 있다. 적당한 것 골라서 사용하는 여유를 부려보자.


3. 큐 엔진

ActiveMQ와 RabbitMQ로 충분했는지도 모른다. 이미 강력한 큐 엔진은 오픈소스로도 충분하게 존재한다. 물론, 상업용 큐 엔진들도 충분하고, 특정 목적에 맞는 서비스들도 있다. ( 제한적이기는 하지만, 대학 수강신청이나, 수능 이후에 모집 시에만 적용되는 솔루션이 한국에도 있기는 하다. )

대부분의 큐 기능들을 가진 무거운 것부터, 작은 기능들로 무장한 작은 큐까지 엄청나게 많다. 그냥, 적당한 큐 엔진을 사용하면 된다. 개인적으로 생각하기에... 큐 엔진을 SaaS 형태로 제공하는 기능은 곧 출시될 것으로 보인다.

큐 엔진은 이제 만드는 것이 아니다. 골라서 사용하는 것이다.


2. 기업형( 폐쇄형 ) 협업 서비스

슬랙의 성공을 기반으로 엄청나게 많은 스타트업과 기업들이 기업형과 폐쇄형 협업 서비스를 만들겠다고 꽤 많은 도전을 하고 있다. 미안하지만, 이미 기업들의 분화가 많이 이루어지고 있으며, 슬랙이나 텔레그램으로 충분한 경우가 많다.

슬랙이면 충분하고, 텔레그램으로도 충분하다. 이 두 가지를 넘어설 정도의 Open-API체계나 혁신적인 연계방법을 제공하는 것이 아니라면, 특정업체나 특정 도메인에 맞는 구성으로는 페이스북의 기업용 서비스를 넘어서기도 힘들것이다.

이런 프로젝트의 미래는 불투명하다. 아! 아주 혁신적인 아이디어로 슬랙을 넘어선다면 모를까...


1. 전자 콘텐츠 관리 시스템

정말, 넘쳐나는 시스템이다. 워드프레스를 이용해서도 충분하게 구현 가능하며. 오픈 소스로 제공되는 형태들도 있다. Alfresco와 같은 솔루션은 이미 그 존재만으로도 충분하며. 의료영상정보시스템인 PACS를 만들 수 있는 수준까지 근접한 수준이다.

혹시라도, CMS를 구현하려고 하는 사람이 있다면, 조직에서 격리해야 한다.


저는 도시락 싸들고 다니면서 말립니다. 물론, 제가 생각하는 것이 전부가 아닐 수 있습니다만, 32 core BOX들이 사용되는 시대가 아니라, 2~4 core용 VM으로 동작되는 AWS가 대세인 현재의 시대에서는 이미, Cloud와 SaaS가 대세입니다.


본질적인 '웹 비즈니스'에 집중해야지, 더 이상 '도구'를 만든다는 것 자체가 무리인 것으로 생각됩니다.


하지만, 또 다른 기회는 분명 있을 것입니다. 시장은 언제나 돌도 돕니다. 클라우드로 모든 것이 올라가고 있지만, 네트워크는 분명 한계가 있습니다. 그리고, AI가 도입되고 로봇이 중요시되는 상황으로 변화되면서 클라이언트에서 많은 것이 동작되고, 멀티 디바이스에서 동작되는 환경들을 고려하는 시대로 돌입한다면, 또 기회가 올 것입니다.


그런 수년 후의 '미래'를 위해서 투자한다는 것은 말리지는 않습니다.


어차피, 미래의 예언은 누구나 다 할 수 있으니까요.

이전 08화 여전히, 40대의 삶은 드라마틱하다. #2
brunch book
$magazine.title

현재 글은 이 브런치북에
소속되어 있습니다.

작품 선택

키워드 선택 0 / 3 0

댓글여부

afliean
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari