|

[개안뽑] ⑪모르는 걸 시킨 나는 악덕 기업주였다

Picture

Member for

4 months

Real name

Keith Lee

Bio

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

Input

2023-12-12 18:30

건설 현장, 조선소에는 이미 외국인 인력이 압도적 다수
IT프로젝트는 '리모트'로 시켜주면 너도나도 달려들어
굳이 한국 인력 말고 해외 인력에게 리모트로 업무 배정하면 효율성 극대화
연봉도 국내 인력 대비 1/10 ~ 1/5 수준에서 만족하는 경우 많아

기존에 운영하던 웹사이트가 무려 15개나 됐는데, 여러번 설명했던대로 서버를 엉망으로 해 놓은 상태에서 말 그대로 '돌아가기만 하는' 상황으로 서비스를 운영했었다. 이제 서버 수준을 한 단계 올려놓고 나니 예전에 도전했다가 포기했던 주제가 다시 생각이 나더라. 워드프레스 '멀티사이트'다.

워드프레스는 멀티사이트라는 방식으로 1개의 워드프레스 위에서 N개의 서비스를 돌릴 수 있도록 지원한다. 각종 문제를 피하기 위해 워드프레스가 정한 문법을 따라야하기는 하지만, 1개로 묶으면 그간 내 목을 조여왔던 보안 이슈가 아래의 장·단점으로 깔끔하게 정리된다.

XSS (Cross-Site Infection) 문제 해결 - 1개 밖에 없으니까
1개가 해킹 당하면 서비스 전체 다운

달걀을 한 바구니에 담지 않는 것이 내 전공인 Finance에서 101 급으로 받아들여지는 기초 지식이지만, 15개를 관리하는 것 자체가 너무 힘들었기 때문에 계속 만지작거렸던 서비스 방식이기는 하다. 방식을 변경하는 순간 수 많은 문제가 함께 따라오는 것도 사실이지만, 관리라는 측면에서 이보다 더 편할 수는 없기 때문에 고민이 많았다.

멀티사이트, 속도가 느려서 못 썼다

사실 멀티사이트 방식을 채택하지 못한 가장 결정적인 이유는 서비스 속도 때문이었다.

2019년 무렵에 워드프레스 멀티사이트를 도입해서 하나로 관리하고 싶다며 내 혼자 힘으로 서비스들을 묶었는데, 개발들을 뽑고나니 이렇게 묶어서 서비스하니까 무거워서 속도가 느린거라며 날 바보 취급하더라.

무거워지면 느려질 수밖에 없는 부분들을 파일 IO, DB의 Table별 로딩 속도 등으로 하나하나 설명을 들으면서, 내가 모자란 탓에 어리석은 결정을 내려서 미안하다며 기존에 썼던대로 분리 작업을 진행했다. 근데, 분리하는게 또 만만치 않은 일이었는지 개발팀이 온갖 짜증이 다 내더니 어정쩡한 상태에서 타협하고 그대로 쓰자고 하더라.

지금도 그 시절에 썼던 블로그 글 중에 이미지 파일들 중에 일부는 멀티사이트 방식으로 저장이 된 탓에 파일을 찾기가 힘들어서 이미지가 안 보일텐데, 이게 내가 겪은 멀티사이트 첫 경험담이다. 다시는 쓰지 말자고 생각했었다.

그러다 해킹을 연이어 당하면서 해외의 보안서비스들을 뒤져봤는데, 대부분 웹사이트 10개, 20개 이상을 묶으면 가격이 얼마나 더 뛴다는 방식으로 나와있고, 대부분은 가격 문제를 넘어서, 남의 회사 웹사이트를 대신 운영해주는 에이전시들에 맞춰진 상품 구조를 갖고 있었다.

난 에이전시 아닌데, 뭔가 달리 방법이 없나는 고민이 계속됐는데, Kadence 테마를 구매하면서 그 회사 대표가 인터뷰 해 놓은 내용을 보고 멀티사이트에 대한 내 기존의 이해가 완전히 잘못됐다는 것을 알게 됐다.

DB 전체 크기가 문제면 빅테크들은 어떻게 사업하나?

인터뷰 중 한 구절을 보면, 자기네 테마 웹사이트도 방문자들이 테마 소개 글 읽는 사이트, 가입자들이 다운 받는 기능 하는 사이트, 궁금할 때 찾아서 볼 수 있는 Knowledge base, 하루 수천 개 이상의 질문을 받아주는 포럼 사이트 등등으로 구분이 되어 있는데, 그 중 가장 무거워지는 포럼을 주기적으로 백업으로 옮기면서 관리하는 중이라는 답변이 있었다.

반면 워드프레스가 1개만 설치되어 있기 때문에 N개 설치된 상황보다 시스템 자원을 덜 활용해서 효율적이고, 각각의 서비스에 배정된 테이블들만 잘 관리하면 된다는 설명을 해 놨더라.

각종 테스트 끝에 2019년, 2020년에 내가 멀티사이트를 포기했던 이유는 당시에 서비스 효율화에 실패했기 때문이지, 멀티사이트라는 시스템 자체가 잘못된 것이 아니었다는 것을 알게 됐다. 구글링을 해 보면 수 많은 단점을 언급해놨지만, 결합한지 약 2달이 되어가는 이 시점에 나는 불만이 별로 없다. 아니 대만족인 상태다. 굳이 예전 개발팀이 고집했던 시스템을 유지하지 않은 덕분에 보안 이슈로 어이없는 추가 비용을 더 쓰지 않아도 됐기 때문이기도 하고, 멀티사이트라는 워드프레스의 고급 기능을 제대로 쓸 수 있는 길이 열리기도 했기 때문이다.

간단하게만 정리하면, 테마를 단 1개만 쓰면서 여러 테마에 대한 의존성을 확 낮췄더니, 호환성 문제도 깔끔하게 해결이 됐고, DB에서 데이터 테이블들 관리하기도 편해졌고, 하나의 시스템 안에서 적용된 효율화가 전체 시스템에 바로 적용되는 부분에서 시간 절감도 매우 큰 상태다. 하나의 웹사이트에 등록된 글을 다른 웹사이트로 옮기기도 쉬워졌고, 덕분에 웹사이트 접속해서 글을 쓰고 있는 기자, 연구원들의 업무도 훨씬 더 효율적으로 바뀌었다.

DB가 더 커지면 어떻게 하느냐? 무거워지게 만든 원인들을 제거하고, 더 심하면 '백업'이라는 형태로 웹사이트 방식을 아래 형태로 바꾸고, DB만 배정을 변경해주면 된다.

https://research.pabii.com
https://research.pabii.com/2023backup

기존 서비스를 새로운 URL(위의 서브 디렉토리인 2023backup)로 전체 복사하고, 2023년 콘텐츠가 들어오면 구글이 저쪽으로 찾아가도록 Redirection을 걸면 된다.

사실 더 좋은 방법은 DB를 비싼 오라클DB를 쓰고, 각종 네트워크 전문 지식을 동원하는거겠지만, 그렇게 큰 비용을 들이지 않더라도 충분히 서비스를 효율적으로 운영할 수 있겠더라.

가볍게 가볍게 vs. 하나로 하나로

한편에서는 워드프레스를 최대한 가볍게 유지하기 위해서 많은 분산 작업들을 진행했는데, 다른 한편에서는 최대한 하나로 묶는 작업을 하는 것이 아이러니 같게 느껴지긴 했지만, 가벼워진 덕분에 효율성을 최대로 뽑아낼 수 있는 멀티사이트 기능을 쓸 수 있게 된거지, 가볍게 만들지 못했다면 결국엔 그 시절 개발팀에 꾸중 듣고 갈아엎었던 예전 시스템을 그대로 유지해야 할 뻔 했었다.

여전히 멀티사이트의 많은 약점들을 그대로 갖고 있기는 하지만, 일단 확실한 것 하나는 '성능' 때문에 멀티사이트를 쓰지 말아야 한다는 개발팀의 당시 주장이 완전히 틀렸다는 것을 알게 됐다.

멀티사이트 중 하나의 웹사이트만 데이터가 많이 쌓여있어도 전체 시스템을 모두 느리게 한다고 했는데, 이건 분리를 해 놔도 상황이 다르지 않더라. 오히려 하나로 뭉쳐놓으니 어느 테이블에서 문제가 생겼는지 즉각 찾아내서 그 테이블을 최적화 프로세스에 넣어버리니 관리가 더 편해졌다.

몇몇 플러그인들 중에 DB내의 테이블 별로 만들어내는 Overhead를 감시해서 알려주는 기능들이 있던데, 처음에는 접속이 느려지면 찾아가서 해당 테이블에 손을 댔다가, 아예 이것도 그들이 좋아하는대로 '자동화' 작업에 넣어버렸다. 평균 4~8MB 사이의 Overhead 밖에 만들어내지 않는 테이블이 갑자기 20MB 이상으로 치솟으면 효율화 작업이 즉시 돌아간다. 많은 사이트들을 하나로 묶어놓으니까 관리하는 프로그램도 1개만 있으면 되고, 궁금할 때마다 그 1개의 프로그램을 바로 찾아가면 된다.

이렇게 좋은 걸 왜 그 때는 몰랐을까? 열심히 찾아보지 않은 내 탓이다.

모르는 걸 시킨 나는 악덕 기업주였다

사실 아무것도 모르는 상태에서 그냥 시작했었으면 그 시절과 비슷한 문제를 겪으며 결국 멀티사이트를 포기했을 것이다. 이번에 상황이 크게 달라진 것은, 새로운 '기술'(Read '기능', 'Library', 혹은 '플러그인')들을 써서가 아니라, 그 때 잘못했던 것들을 반복하지 않을 수 있는 경험치가 쌓였기 때문이다.

여러 테마를 써서 호환성 이슈가 생기는 것을 피하기 위해 딱 1개의 고급 테마를 고르는데 상당한 검색 비용, 시간 비용을 허비했고, 쓰고 싶은 플러그인 중에 충돌이 일어날 것 같은 경우들은 사전 테스트를 거치면서 시스템에 영향을 주지 않도록 관리를 했다.

그 외에도 분산 서버 작업을 어디에서 어떻게 해야한다, 결합할 때는 뭘 결합해야한다는 것 같은 부분들에 대해서 경험치가 쌓였던 부분 때문에, 최소한 뭘 찾아봐야하는지는 알게 됐다.

무조건 개발자들을 욕할게 아닌게, 그 분들도 처음 들어보는 이상한 시스템으로 웹사이트 운영하자는 대표 때문에 짜증이 많이 났을 것이다. 한국에서 흔히 쓰는 제로보드, 카페24 같은 솔루션을 쓰던가, 아니면 자기들이 원하는대로 Node.js, React.js로 처음부터 시스템을 만들었으면 굳이 또 다른 학습 비용을 쓰시지 않았어도 됐다는 주장에 동의한다.

난 한편으로 생각하면 직원들이 모르는 걸 갖고와서 하겠다고 우기고, 학습 속도가 느리다며 짜증나는 악덕 기업주였던 것이다.

그런데, 다른 한편으로는 계속 이런 생각이 든다. 우리 회사에 과연 그 개발자들이 필요했을까? 그냥 워드프레스만 조금 더 효율적으로 만들고, 아예 더 고급 전문 개발자들로 내가 원하는 타게팅 알고리즘을 돌릴 수 있는 서버를 만들 인력들을 뽑았어야 하는게 아니었을까?

나같은 욕심이 없는 수 많은 기업주들이라면 그런 '중급' 개발자 없이 단순한 워드프레스 서비스를 조금씩 뜯어고쳐주는 해외의 저렴한 외주 서비스들을 쓰는 것이 더 합리적인 전략이 아닐까?