[개안뽑] ㊸완벽한 IT시스템은 구글 개발자도 못 만든다. 타협해라

Picture

Member for

4 months

Real name

Keith Lee

Bio

Head of GIAI Korea
Professor of AI/Data Science @ SIAI

Input

2024-01-29 18:30

서비스 개발, 운영 개발 등으로 구분하지 않고, 완성도를 높인다는 관점으로 개발을 봐야
그러나 완벽한 시스템 개발은 불가능, 하드웨어와 소프트웨어는 지금도 계속 진화 중이기 때문
서비스 고급화를 위한 각종 고민들을 하나씩 풀어내며 내공 쌓인 시스템을 만드는 것이 가장 근본적인 도전

예전에 어느 운영 개발 위주로 돌아다니던 회사를 그만두고 나온 개발자를 면접 본 일이 있었는데, 운영 개발만 계속하다가는 시스템을 어떻게 만드는지를 모르는 반쪽짜리 개발자가 될 것 같아서 그만두고 나왔다고 표현하더라. 그 문제 의식 자체에는 공감을 하는데, 다른 한편으로는 시스템을 만드는 것이 얼마나 큰 스트레스인지, 하나하나의 시스템 수정, 보완 작업이 오랜 기간 쌓인 서비스가 얼마나 완성도가 높아지는지를 이해 못하는 것 같아서 고개를 갸웃 거린 적이 있다.

그 분께 그 때도 물어봤고, 앞으로 비슷한 고민을 하는 분들께도 물어보고 싶은 내용인데, 과연 처음부터 서비스를 만들면서 똑같이 할 수 있겠나, 똑같이 못 한다면 어떤 과정을 거쳐야하고, 그 회사는 어떤 문제를 겪으며 어떤 고민을 했길래 그런 시스템이 나오게 됐는지 짐작되는 바가 있냐는 내용들이다.

말을 바꾸면, 그 회사가 서비스 개발을 끝내고 운영 개발로 넘어와서 몇 년동안 쌓은 내공이 담긴 서비스에서 당신은 얼마나 내공을 뽑아냈느냐는 질문으로 표현할 수 있을 것 같다.

운영 개발과 서비스 개발은 다른 개발이다?

남들에게 자랑처럼 들린다는 것을 인지하고는 있지만, 딱히 자랑하려는 목적은 아닌, 나의 어린 시절 직장 경험들을 떠올려보자. 난 글로벌 회사들이 어떤 방식으로 팀을 나눠서 운영하는지, 각 지사별로 어떤 보고 체계, 어떤 지원 체계를 이용해서 글로벌 조직이 운영되는지를 실제로 경험했다. 그러나 최상위 권력자의 입장에서 그걸 겪은 것이 아니라, 말단 직원 수준에서 같은 문제를 겪었기 때문에 지식과 별개로 내 시야는 굉장히 제한적이었다.

운영 개발이 서비스 개발만큼 밑바닥에서부터 모든 걸 하나하나 다 만드는 개발 작업은 아니지만, 완성된 대형 시스템이 작동되는 것을 보면서 아마 엄청난 경험치를 간접적으로 얻을 수 있을 것이다. 물론 지식과 별개로 시야가 제한적인 탓에 그 지식이 모두 몸에 흡수된 내공으로 바뀌지는 않겠지만, 본인이 얼마나 열심히 노력하느냐에 따라서 회사의 수십, 수백명의 인재가 몇 년동안 만든 그 시스템에서 많은 것을 흡수할 수 있다.

많은 서비스들이 매우 조잡한 상태에서 회사가 억지로 굴러가고 있고, 그런 시스템을 대대적으로 뜯어고치기에는 말단 직원 입장에서 한계가 있기 때문에 불평이 있을 수 있다는 점은 공감하지만, 그 정도 시스템을 굴리는 회사로 성장한 곳도 찾아보기 쉽지 않다.

가장 쉬운 예시로, 워드프레스가 지난 20년 이상 쌓아놓은 지식 내공을 따라가기만 해서 구글 페이지 스피드 전 영역 100점을 받을 수 있는 웹페이지를 만든 우리 회사 상황을 들어보자. 우리 회사가 역량이 부족한 현실을 인정하지 않고 고집스레 고급 언어로 제대로 된 개발을 하겠다고 달려들었다면, 워드프레스가 20년 동안 쌓은 내공을 추격하는데 적지 않은 시간을 써야 했을 것이다. 직접 시스템을 만들다보면 시장에서 살아남은 서비스들이 얼마나 많은 고민과 시련의 시간을 거쳐가며 완성된 제품인지 넘겨 짚는 순간들이 종종 찾아오고, 그걸 내가 넘어서야 우리도 살아남을 수 있겠구나는 압박도 다가온다.

즉, 운영 개발이 눈으로 보기에는 서비스 개발과 다르게 보이지만, 생존을 목표로 끊임없이 진화하고 있는 있는 서비스의 운영 개발이라면 사업 초창기 서비스 개발과는 현격하게 다른 수준의 고민을 담고 있는 난이도 높은 도전이 된다.

완벽한 IT시스템? 어제는 완벽했겠지. 오늘도 완벽할까?

많은 개발자들이 자기는 다니던 회사처럼 조잡한 시스템 만들고 싶지 않고, 시간에 쫓겨가며 급하게 대충 붙여넣은 시스템을 만들고 싶지도 않다고 한다. 자기가 완벽한 IT시스템을 만들어서 그걸로 자랑하고 싶다고 그러는데, 정말 완벽한 IT시스템이 있을까?

IT업계의 하드웨어, 소프트웨어 진화, 그런 진화를 발 빠르게 응용하는 각종 프로그래밍 언어들의 변화들을 보면, 오늘은 완벽해보이는 시스템이 내일도 완벽해보이기는 대단히 어려워 보인다. 굳이 따지자면 버전 7에서는 완벽했겠지만 버전 8이 되면, 아니 버전 7.5만 되어도 전혀 완벽하지 않은 시스템이 될 수 있는 곳이 IT업계인 것이다.

예를 들어, 2000년대 초반에 만든 코드로 무거운 계산을 돌릴 때는 Scalar 값이 아닌 Vector 값을 기반으로 계산이 돌아가도록 프로그래밍을 하면 고급 프로그래밍이었다. 그러다 Vector보다 한 차원 더 많은 Matrix를 기반으로 계산이 돌아가도록 소프트웨어가 진화됐고, 고급 프로그래밍의 정의가 바뀌었다. 최근에는 그래픽 카드를 이용해서 Matrix보다 한 차원 더 많은 Tensor를 계산할 수 있게 됐고, 그런 하드웨어를 활용할 수 있는 라이브러리를 어떻게 만들고 변형하느냐에 따라 적절한 프로그래밍 구조도 바뀐다. 하드웨어가 업그레이드 되어서 바뀌는 부분만 있는 것이 아니라, 소프트웨어 적으로 그 하드웨어를 어떻게 쓰느냐에 따라서도 고급 프로그래밍의 기준이 달라지는 것이다.

이렇게 쉴새없이 진화하는 영역에서 완벽한 시스템은 과거 완료형일 뿐, 미래 진행형 표현일 가능성은 매우 낮다.

완벽한 IT시스템? 그런건 구글 개발자도 못 만든다. 타협해라

시스템을 처음 만들면 온갖 곳에서 문제가 발생한다. 예상치 못했던 문제들이 '버그'라는 이름으로 정리되고, 이걸 수정하는 작업을 몇 차례 거치면서 완성도가 높은 시스템이 된다. 그렇게 어제의 기준에 맞춰 버그가 사라진 시스템을 오늘 완성하고 나면, 오늘은 또 새로운 기준이 나오고, 거기에 맞춰 또 새로운 버그 수정을 해야한다. 이걸 막고 싶으면 IT 업계의 모든 하드웨어, 소프트웨어 진화를 막고, 2024년에 고정된 상태로 2124년까지 살면 된다. 인류가 멸망의 길을 걷고 있지 않는 이상, 이런 일은 일어나지 않을 것이다.

어차피 완벽한 IT시스템은 없다. 어느 유명 기업들은 그런 시스템도 완벽하게 만들 것이라고 생각하는 경향이 있던데, 큰 회사라고 해서 2024년 오늘의 시점에 딱 맞는 시스템을 갖고 있지 않고, 실시간으로 바뀌는 현장 상황에 바로바로 맞춰서 진화하는 시스템을 갖고 있는 경우는 더더욱 드물다.

지난 2022년 11월, 한국 IT업계에서 1등 회사인 네이버가 국내 플랫폼 최초로 HTTP/3을 도입했다는 보도가 나왔다. 그런데 검색 페이지에서는 HTTP/2로 돌아가는 경우가 자주 보고됐고, 아직도 구형 스마트폰이나 업데이트 안 된 브라우저로 접속하면 HTTP/1.1로 접속되는 것을 볼 수 있다. 나중에 검색 페이지는 아직도 HTTP/3을 지원하지 않는다고 공식 보도하는 것도 봤고, HTTP/3이 제한적으로 적용된다고 솔직하게 말하더라.

우리 회사도 웹페이지를 완전히 뜯어고치던 10월, 11월에 HTTP/3을 적용시키기 위해서 여러 작업을 했고, 지난 12월부터 전체 방문자의 80% 정도가 HTTP/3으로 접속되는 것을 확인할 수 있다. 나머지 20%는 여전히 HTTP/2, 혹은 HTTP/1.1로 접속한다. Nginx의 서버 기록에 HTTP/1.1이 보일 때마다 속이 타는 심정으로 개선해보려고 했는데, 아직도 구형 스마트폰에서 구형 브라우저를 쓰고 있으신 분들에게 강제로 HTTP/3을 적용하면 웹페이지가 뜨질 않는 것을 보고 마음을 비웠다. 같은 문제는 구글 검색 페이지에서도 그대로 나타나더라. 차라리 그 시간을 아껴 좋은 콘텐츠를 더 만들고, 웹사이트의 다른 버그들을 수정하는 편이 낫겠다 싶었다.

일련의 경험을 겪으며 '완벽한 시스템'을 만드는 개발자의 도전이 매우 과거 지향적인 도전이라는 것을 알게 됐다. 개발자가 정말로 해야하는 도전은 새롭게 나오는 지식이 우리 회사 서비스에 어떻게 적용되고, 어떤 문제를 개선시켜줄 수 있고, 그래서 방문자가 얼마나 더 우리 서비스를 잘 쓸 수 있도록 지원해 줄 수 있는가에 대한 도전이다. 이것이 타협인지, 미래지향적인 사고 방식인지에 대한 해석은 당신들의 몫이다. 해석을 어떻게 하느냐와 별개로, 나는 HTTP/3을 100% 적용하는 욕심을 버리고 다른 버그 수정에 집중하는 것을 선택했다.