[개안뽑] ㊲개발 의존도가 낮은 회사와 개발자 의존도가 낮은 회사의 차이

2
pabii research
일반적으로 워드프레스, 카페24, 고도몰 등의 솔루션을 개발 의존도, 개발자 의존도가 낮고 개발 부채가 많은 시스템으로 인식
그러나 끝까지 1개의 솔루션만 쓰고 있으면 개발 부채 높은 것 아냐, 오히려 개발 의존도가 높아지는 것
차라리 개발 의존도가 높은 상태에서 외주 업체를 구하기 쉬운 편이 더 효율적인 IT시스템 운영 방식
솔루션 기반 개발 뿐만 아니라, 고급 서비스도 사정은 크게 다르지 않아
외주 구하기 쉬운 서비스, 빠른 개발이 가능한 서비스로 개발 의존도 높이고, 개발자 의존도 및 개발 부채 낮추는 것이 최적 전략

사업하겠다고 열심히 VC들, 사업하는 친구들, 스타트업 C-level 친구들, 개발자, 디자이너 같은 사람들을 만나러 다니던 시절, 내가 자주 들었던 표현 중에

  • 개발 부채

라는 표현이 있다. 개발을 대충해 놓으면 나중에 그 시스템을 뜯어고치는데 많은 시간과 인력을 소비해야하는데, 그걸 ‘개발 부채가 쌓인다’고 표현하더라. 그래서 고급 개발자를 잘 뽑아서 회사를 시작해야 한단다.

지금와서 돌이켜보면 그냥 무시하고 개발 부채를 계속 쌓았어야 했다.

이유는 크게 두 가지다.

  • 누구를 뽑았건 상관없이 개발 부채는 쌓였을 것이다.
  • 어차피 우리 회사 사업 라인에 개발 부채는 의미가 없다

말을 좀 바꾸면, 우리 회사가 ‘개발 의존도’는 굉장히 높은 회사인데, ‘개발자 의존도’가 높아서는 안 되는 회사였기 때문이다. 무슨 뜻이냐고?

개발자-안-뽑음_202312
개발자-안-뽑음_202312

개발 의존도가 높은 회사, 개발자 의존도가 높은 회사

우선 워드프레스로 웹페이지를 만든다고 해 보자. 대부분의 사람들은 가볍게, 빠르게, 후닥닥 만들 수 있는 서비스라고 생각하고, 추후에 굉장히 많은 개발 부채를 낳을 것이라고 우려의 목소리를 낼 것이다.

그런데, 난 이제 그냥 끝까지 워드프레스로 갈려고 한다. 서비스가 아무리 커져도 Javascript로 서비스를 다시 만드는 법 없이, 그냥 끝까지 워드프레스로만 만들려고 한다. 그럼 개발 부채가 심각한 상태인가? 시스템을 완전히 뜯어고치면서 새로운 언어로 다시 만든다는 상황이 와야 개발 부채가 심각한거지, 끝까지 워드프레스로만 가면 개발 부채가 엄청난 건 아니잖아?

아마 기적같이 서비스들이 더 커져서 지금보다 1,000배의 트래픽을 감당하고, 글 쓰고, 댓글 달고, 서로 채팅하고 등등의 서비스들이 나온다고 해도, 워드프레스를 쓰면서 각종 효율화 작업을 꾸준히 하면 충분히 감당할 수 있는 상황이라는 확신이 있기 때문에 고집을 부리는 건데, 이렇게 되면 개발 부채는 크지 않은 상태로 유지할 수 있다.

기껏해야 시스템 효율화를 위해 플러그인을 바꾸거나, 테마를 바꾸는 정도에 그칠 가능성이 높기 때문이다.

정말 큰 욕심을 낸다면 DB를 워드프레스 기본 DB인 MySQL (이나 호환도는 MariaDB)가 아니라, 고성능으로 유명한 Oracle DB를 쓸 수 도 있겠지. 이렇게 썼다는 사람들이 없어서 모르겠는데, 아마 Oracle에서는 돈만 주면 워드프레스와 호환되도록 DB를 구성해서 상품으로 팔 것이다. 그게 어렵다면 DB를 Write 전용 DB와 Read 전용 DB로 구분하고, DB를 Scale out하면서 계속 서버가 감당할 수 있는 범위를 확대해가는 방식으로 대응할려고 한다.

이걸 내가 직접할 수도 있겠지만, 이미 글로벌 시장에는 나보다 10년 이상 먼저 워드프레스로 그런 고지에 오른 서비스를 하는 분들이 많은 탓에, 관련된 서비스들이 많이 나와있고, 답답하면 그 분들을 외주로 쓰면 된다. 워드프레스가 워낙 일반화된 서비스라, 그 분들의 ‘솔루션’도 그리 어렵지 않게 적용할 수 있을 것이다.

이런 회사는 개발자 의존도가 높은 회사일까? 아마 개발자를 1명도 안 쓰면서, 나처럼 비개발자가 어줍잖게 아는 지식만 갖고 있어도 Oracle이 됐건 DB Scale out 전문 회사가 됐건, 그런 회사들과 세일즈 미팅을 통해 적절한 시스템 업그레이드를 할 수 있을 것이다. 말을 바꾸면, 이런 회사들은 개발 의존도는 높은데, 정작 개발자 의존도는 낮은 회사다.

누구를 뽑는다고 개발 부채가 줄어드는 것이 아니다

한 때는 초A급, 초S급 개발자를 뽑으면 개발 부채가 줄어든다고 생각했던 시절이 있다.

내가 B급 이하 개발자들을 뽑아놓고 이런 식으로 이야기한다고 지적하면 달게 받아들이겠지만, 미루어 짐작컨데 초A급, 초S급이라고 해도 한국인 개발자들이 과연 개발 부채를 줄이면서 개발할 수 있는 경우가 얼마나 있을지, 한국인이 아니라고 해도 개발자가 개발 해 놓고 난 다음 떠나고 나면 그 개발 부채를 어떻게 감당할 수 있을지에 대해서 긍정적인 답변을 내놓기 어렵다.

개발자들이 자기네 방식으로 시스템을 다 만들어놓고 회사를 떠나면, 아무도 그 시스템을 건드리질 못하게 된다. 그럼 개발 부채는 둘째 문제고, 개발자 의존도가 굉장히 높은 회사가 된다.

카페24, 고도몰 등의 국내 외주 솔루션을 좀 뜯어 고쳐서 만들었다고 생각해보자. 이런 경우에는 그나마 좀 낫다. 국내에 카페24, 고도몰 ‘전문 개발자’라는 분들도 은근히 많고, 그 분들을 못 구하더라도 카페24, 고도몰에 직접 문의하면 비용이 들어서 그렇지 회사 시스템의 문제를 깔끔하게 해결해준다.

방향을 살짝 바꿔서, 만약 초S급인줄 알고 뽑았는데 그간 내가 비판했던 것처럼 과거 프로젝트 하듯이 그대로 복붙에만 집중하고, ‘최신 코드’, ‘검증된 코드’를 썼다고는 하지만 정작 워드프레스로 해외에서 6개월 코딩 부트캠프 다니다 온 애들보다 더 체감 서비스 수준이 낮은 서비스가 나왔다고 해 보자. 이런 경우에 개발 부채는 어떻게 될까?

워드프레스로 만든 그 시스템은 가만히 내버려 둘 경우엔 빠르면 1~2년, 길면 3~4년 안에 망가질 가능성이 높다. 계속 업데이트가 있고, 이게 때로는 플러그인의 호환성을 망가뜨리고, 테마가 이상하게 작동하게 되기도 하고, 그 외 우리가 모르는 여러 문제가 계속 발생하기 때문이다. 아예 업데이트를 하나도 안 하고 있으면 이번엔 해킹을 당하게 된다. 이미 3번이나 당해봐서 너무 뼈 아프게 안다.

반면 그 ‘최신 코드’, ‘검증된 코드’로 만든 시스템은 워드프레스로 만든 것보다 좀 안 좋아도 3~4년 이상 해킹 걱정없이 쓸 수 있을 가능성이 높다. 아예 업데이트를 막아놨는데 굳이 문제가 생길 이유가 없으니까. 특별히 뭔가 사건이 터지지만 않으면, 행정안전부가 15년간 썼던 정부2.0 시스템처럼 문제없이 쓰게 될 수 있을지 모른다.

대신, 이런 서비스는 15년 후에는 엄청난 개발 부채가 쌓이게 되고, 개발 의존도, 개발자 의존도가 상상할 수 없는 수준으로 올라간다. 새로 시스템을 다시 만들면서 기존 시스템과 호환성을 유지해라고 하면 도망가는 IT기업들이 대부분일 것이다. 100층짜리 건물도 남들이 짓던거 이어서 지으라고 하면 도망간다던데, 15년된 IT시스템을 어떻게 업그레이드 해 줄 수 있을까?

결국 시간의 차이, 경험의 차이일 뿐이지, 누굴 뽑는다고 해서 개발 부채가 줄어들지는 않는다. 오늘 개발부채가 없더라도 내일은 개발 부채가 생길 수밖에 없기 때문이다. 물론, 오늘 당장 쓰는 서비스마저도 엉망으로 만드는 실력없는 개발자를 뽑으면 개발 부채가 심각한 상태로 시작하게 되니 좀 다른 문제일 것 같기는 하다.

가장 합리적인 것은 쉽게 개발 인력을 구할 수 있는 시스템을 고른 다음, 꾸준히 관리 인력이 붙어서 시스템을 운영해주는 것이다. 15년간 비용을 안 쓰다가 한꺼번에 15년 후에 비용을 쓰는 것만큼 큰 비용이 들지는 않겠지만, 꾸준히 나가는 비용을 무시할 수 있는 수준은 아닐 것이다.

개발 의존도는 높으면서 개발자 의존도, 개발 부채가 낮은 IT시스템 만들어야

몇 년 동안 개발자들에게 돈을 갖다 부으면서 알게 된 건, 회사의 일반적인 웹사이트들은 개발 의존도가 높더라도 개발자 의존도, 개발 부채는 낮은 시스템을 만들어야 한다는 것이다.

내가 워드프레스를 고집하는 것도, 해외 주요 워드프레스 게시판에 글 1개만 올려도 다음 날이면 20명 이상의 전문가들이 자기한테 외주 달라고 할만큼 개발자 집단이 잘 갖춰져 있고, 업데이트가 주기적으로 있어서 해킹을 당할 위험도 낮고, 15년 후에 한번에 업데이트 하는게 아니라 평소에도 꾸준히 관리가 가능한 시스템인데, 전체 구조를 뜯어고치질 않으니 개발 부채가 낮은 상태를 오래 유지할 수 있기 때문이다.

하나하나 찾아가며 직접 만들어보니 개발 의존도는 높아도 어지간해서는 외주 개발자를 찾지 않아도 되겠다는 생각도 들었고, 워드프레스 전용 해외 호스팅 서비스들을 보면서 ([개안뽑] ㉟’클라우드1.0’=Serverless, ‘클라우드2.0’=개발자less) 아예 서버 개발자를 뽑지 않아도 된다는 것도 알게 됐다. 위에 쓴대로 Scale out 전용 담당자도 외주를 쓰게 되면, 인력 문제, 비용 문제, 서버 관리 문제가 모두 해결이 된다.

사실 워드프레스가 개발 의존도가 높은 것도 아니고, 플러그인을 붙여서 쓰는 센스와 간단한 개발 기초 지식을 통한 관리 이슈가 더 많은 서비스인만큼, 개발 의존도, 개발자 의존도, 개발 부채가 모두 앉은 시스템이다. 다만 워드프레스 자체가 가진 각종 문제들을 모두 감당해야하는 것이 문제일 뿐이다.

고급 시스템을 만든다고 해도 고민은 크게 다르지 않아

워드프레스로 만드는 ‘단순한’ 웹사이트 말고, 고급 기능을 담고 있는 웹사이트는 어떨까?

빅데이터 서버 시스템, 광고 타게팅 시스템 같은 경우는 고민이 단순하지 않다. 오늘 최적의 기술 스택이라고 나온 것이 1년만 지나고 나도 더 이상 최적 기술 스택이 아닐 수 있는 가능성이 높고, 그렇게 바뀌는 상황에 맞게 시장은 매우 빠르게 업그레이드 되는데, 나는 가만히 있으면 뒤쳐질 수밖에 없는 구조이기 때문이다. 즉, 개발 부채가 굉장히 빠른 속도로 쌓인다.

그렇다고 외주를 쉽게 줄 수도 없는 것이, 이런 시스템을 필요로 하는 기업들이 별로 없기 때문에 저렴한 서비스를 찾기도 어렵다. 사실 고급 지식 시장은 언제나 이렇게 공급이 적어서 수요자가 많은 비용을 지불해야 한다.

그렇다고 한국 개발자들처럼 공부 안 하고, 학습 속도가 느린 인력들을 뽑아봐야 그 시스템 변화 속도를 따라가는 것도 불가능하고, 언뜻 보면 답이 없다는 생각이 들더라.

그러다 요즘 Julia로 빅데이터 시스템을 만들면서 생각이 조금 바뀌었다.

지금은 Julia가 C와 비슷한 계산 속도를 보여주는 최적 언어 중 하나지만, 2~3년 후에도 같은 선택이 최적 선택일지 알 수 없다. 그럼 내 입장에서 최적 선택은 일반 웹사이트에 워드프레스를 고르던 것처럼 쉽게 만들 수 있는 시스템으로 비용을 최소화해서 빠른 작업을 하는데 초점을 맞추는 게 되더라.

많은 개발자들이 엄청난 대형 시스템, 완벽한 시스템을 만드는 프로젝트에 들어가고 싶어한다. 근데, 위에 쓴대로 그런 프로젝트는 없다. 시장은 하드웨어가 바뀌고 소프트웨어가 계속 바뀌면서 끊임없이 변화하기 때문이다. 오늘은 완벽한 보안이지만 내일은 더 이상 완벽한 보안이 아닐 수 있다.

그럼 만드는 비용이 별로 들지 않는 시스템으로 오늘의 결과물을 만들어놓고, 시스템 각각을 분리해서, 하나의 시스템을 갈아 끼우더라도 다른 시스템에 큰 영향을 주지 않는 상태로, 빠르고 기민하게 대응할 수 있도록 만들어야 한다.

Julia는 R과 코드 문법이 비슷해서 내 입장에선 학습 시간을 최소화할 수 있다. 수학적 이해도를 갖고 있는 사람들이 계산 속도최적화에 용이하도록 만든 언어이기도 하다. Genie Framework라는 걸 붙여서 쓰면 그래프가 들어간 웹페이지 구성하기도 쉽다. 그래프들은 D3.js와 Amchart를 갖고 와서 의존도를 분리해 버렸다. 나중에 Julia를 버리게 되더라도 다른 언어로 D3.js에 계산 값을 던져주면 같은 그래프를 유지할 수 있다. 여기에 DB까지 분리되어 있으면 D3.js가 아닌 다른 그래픽 툴을 쓰더라도 적응하기 쉽다.

아마 같은 서비스를 Python의 Django로 만들어 놨었다면, Julia의 Genie로 바꾸는 작업만 하면 될 것이고, 마찬가지로 R의 Shiny를 쓰고 있었다고 해도 상황은 크게 달라지지 않는다. 보안, 연동 등의 기본 문제가 해결되어 있다면, 그냥 자기 손에 맞는 프로그래밍 언어로 최단 기간에 서비스를 만들고, 꾸준히 관리하겠다는 관점으로 접근하는 편이 가장 합리적이라는 결론을 내리게 된 것이다.

개발 의존도, 개발자 의존도, 개발 부채

모든 것을 최대한 빠르게 학습하고, 시장 상황에 맞게 기민한 대응을 요구하는 내 관점이 지나치게 반영된 것 같기는 하지만, 그렇다고 개발 비용이 막대하게 들어가는 시스템도 아니다. 개발자 의존도도 낮고, 개발 부채도 낮은 윈-윈 시스템에서 유일하게 비용을 지불하는 구간이 시스템 총괄 관리자인 나 자신이 좀 더 적극적으로 학습하고 손을 쓰는 건데, 회사 전체로 보면 비용은 0원에 수렴하게 된다. 그런 직접 관리가 가능한 인력을 구할 수 있으면 0원은 아니겠지만 그래도 굉장히 효율적인 시스템을 운영할 수 있다.

주말 중 하루를 더 일하면서 살래, 개발자들 인사 관리, 조직 관리, 성과 관리, 불만 관리….를 하면서 살래라고 묻는다면, 나는 하루를 더 일하면서 사는 편을 택하고 싶다. 거기에다가 하루 덜 일하도록 만들어주는 최적 서비스가 있으면 그걸 쓰는 편이 더 합리적인 선택이 아닐까?

어느 쇼핑몰 중심 기업이 불경기가 다가오니까 개발자 다 내보내고 고도몰 솔루션으로 돌아갔다는 이야기가 기억난다. 그 대표님도 매우 적절한 선택을 하셨다고 생각한다.

Similar Posts