Microservice architecture에 관한 잡생각

이 포스트는 수 많은 억측과 상상과 착각으로 버무린 소설임을 밝힙니다. 이 소설을 있는 그대로 믿었을 경우 생길 수도 있는 부끄러움은 당신의 몫입니다.

C 프로그래밍을 거의 하지 않았기 때문에, 아는 바 거의 없는 시대이지만, 어쨌든 과거에 Procedure 프로그래밍이 있었다. 물론 어셈블리나 기계어의 시대도 있었지만 그건 거의 선사시대에 메머드 똥침놓던 시절의 느낌이니 빼자. 손바닥 터져라 비벼서 불피우던 시절처럼 하는 건 재미나 어쩌다보니 어쩔 수 없이 하는 거지 일상 생활은 아니다.

어쨌거나 프로시듀어 프로그래밍이 있었고 개발과 개선의 결과, 많은 소스코드가 요즘 우리가 OOP가 뭔지도 모르는 자가 써갈긴 거라고 욕하는 바로 그 스파게티 메서드 처럼 무수한 분기문과 반복문의 합체를 C&P 해놓은 그런 괴물이었을 것이다. 개발자를 덮쳐 악취를 풍기며 퇴근을 잡아먹으며 과로사를 일으키는 괴물.

IT 업계가 성장하면서 소프트웨어의 수도, 하나의 소프트웨어의 크기도 커졌고 개발의 복잡성은 더더욱 커졌다. 이런 복잡성은 직접 개발한 당사자가 아니면 손댈 수 없는, 도움을 구할 수도 인수인계를 할 수도 없는 상태로 돌진했고, 아마도 순진했던 개발자는 급여와 계약에 묶여 수명을 팔다가 생명력을 팔아야 하는 처지가 됐다. 실무에 파뭍혀 정치질을 할 수 없었으니 상황의 악화를 막을 기회도 잡지 못했다. 그러다 더러는 생명력이 바닥나고 말았다. 개발자는 살아야 했다.

소프트웨어 개발이란 기본적으로 어려운 일이다. 인간의 방식이 아닌 기계의 방식으로 생각해야 할 수 있는 일이니까. 사고방식을 바꾸는 것은 정말 어렵다. 천동설의 사고방식은 지동설의 사고방식으로 바꾸는 것은 성공했어도, 나이가 몇 살 많거나 적은 사람의 가치기준은 이해하지 못한다. 저 우주 너머의 별의 일생은 이해할 수 있어도, 저 새끼가 왜 저따위로 코를 푸는지 이해할 수는 없다고 하더라.

재사용성

어쨌거나, 그런 어려움을 조금이라도 줄여보고자 무수한 노력을 기울였다. 그리고 그 노력은 한 마디로 “재사용성을 높이려는 노력”이라고 정리할 수 있다.

그렇다. 우리는 재사용성을 조금이라도 끌어올려보고자 무수한 삽을 푸는 것이다. 변수와 함수를 재사용 해보고자 OOP 개념을 개발했고, SOLID나 DRY 같은 원칙을 만들고, 여러 단계와 분기와 반복을 정해진 방식으로 재사용 해보고자 모듈과 라이브러리를 만들고, 다른 소프트웨어를 재사용 하고자 컴포넌트(CBD)륾 만들고, 서버 단위로 재사용 해보고자 SOA를 만들었다.

그리고 그동안 개발 프로젝트의 수도 늘었고, 각 프로젝트의 소스코드 크기도 늘었다. OOP를 조금이라도 안다면 모듈과 타입을 만들었으니 이것도 늘었고, 라이브러리도 늘었다.

그렇다. 급여 빼고 다 늘었다.

복잡성

소프트웨어란 복잡하다. 그거 뭐 별거 아닌데 왜 죽는 소릴 하냐고 하는 소리를 들으면 그건 그냥 무식한 거 숨겨보고자 하는 처량한 몸부림이다. 아니면 당신에게 일폭탄을 떨구려는 가증스러운 짓거리일 뿐이다. 그것도 아니라면? 축하한다. 당신은 천재를 만났다. 그리고 그 천재에겐 애도를 보낸다. 말귀를 못 알아듣는 당신을 만나고야 말았으니까.

만약 업계 사람이라면 블랙리스트에 올리고, 그런 사람이 회사에서 요직을 차지하고 있다면 회사도 블랙리스트에 올려라. 그럼에도 불구하고 회사가 흑자이고 적자전환할 것 같지 않고 당신이 매우 지친 상태라면, 이빨을 잘 가다듬어라. 당신을 위해 준비되어있는 꿀보직, 땡보의 자리가 그안 어딘가에 있다. 알흠다운 이빨로 그 자리를 차지하라. 아니면, 도망쳐라. 어물쩡거리는 사이 먼저 도망친 자들이 자신의 블랙리스트를 까고 난 뒤면 늦는다.

소프트웨어는 복잡하다. 불평하지 말아라. 원래 타고 나기를 그런 거다. 만약 쉽다고 느낀다면 당신은 이거 읽고 있을 시간에 개발을 하는 게 인류의 행복을 위해 나은 선택일 천재란 뜻이다. 사기치지 말고 정의와 소소한 삶의 행복에 대한 애정을 잃지 말길 바란다. 당신이 천재가 아님에도 불구하고 개발이 쉽다면, 당신이 잠든 사이애 X뺑이 친 개발자가 존나게 많고 그들이 박애주의자라 자기 코드를 오픈했다는 뜻이다. 앞서 간 이들에게 감사하라. 아니면? 당신은 당신 필요에 딱 맞는 유료 라이브러리를 가지고 있다는 뜻이다.

소프트웨어는 개발은 복잡하다. 그리고 운영하는 것도 복잡하다. 개발과 운영은 일반적으로 트레이드오프 관계이다. 개발이 편하면 운영이 힘들고, 개발이 힘들면 운영이 편하다. 단적인 예가 의존성 관리다. 개발이 힘들게 다 개발하면 의존성 관리 필요없다. 반대는 길고긴 텍스트로 의존성을 관리해야 한다. 어떤 의존성 관리 시스템을 쓰는진 몰라도 전용 에디터가 있다면 감사하라.

운영이 처음 시작될 때, 스케일업(HW 성능 향상)을 먼저 했다 - 아마도. 당장 애플리케이션 하나 돌리는 것도 버거워하는 컴퓨터란 성능 향상이 급하니까. SLI든 크로스파이어든 GPU가 어느 수준은 나온 다음의 소리인 것처럼. 그 후에 하드웨어를 실행할 애플리케이션에 따라 수직으로(티어) 나누고 기능에 따라 수평으로 나눠서(모듈 아니면 뭐 어쨌든 그런 단어) 이들을 네트워크로 연결했다. 그냥 느낌적 느낌인 정도로 해두자. 나도 저 둘이 앞서거니 뒤서거니 한 거 안다.

개별 서버의 성능이 높아지고 네트워크의 성능도 높아졌다. 그런데 문제는, 네트워크 성능이 높아진다는 건 속도가 빠르다는 소리일 뿐만 아니라, 네트워크에 속하는 컴퓨터의 숫자도 늘어난다는 뜻이다. 네트워크 담당자가 관리해야 할 게 늘어났다. 그리고 이때 경영자 혹은 (자칭) 차기 경영자 혹은 실세가 나타나 외친다. 경!비!절!감!!!

그래서 부하가 큰 작업을 담당하는 애플리케이션은 성능이 좋은 컴퓨터에 할당하고, 역할에 맞게 네트워크 연결을 바꿔주면서, 적절하게 대역폭을 확보해야 한다. 그러니까, CPU vs Memory vs Storage vs 로컬IO vs 네트워크IO의 리소스 요구(경!비!절!감!)에 맞춰 최적화를 진행해야 한다. 아… 인프라 담당자의 생명력이 빠르게 갈려나갑니다. /애도

그러나 인프라 담당자는 살 길을 찾았습니다. 인프라 기술자의 높아진 몸값을 다른 저렴한 기술자로 땜빵치려는 경영자와 인프라 기술자가 불쌍해 보였거나 잉여력이 넘친 소프트웨어 개발자가 서버 한대에 이런 저런 서비스를 해보겠다고 이런 저런 프로토콜을 지원하는 이런저런 시스템 서비스를 만듭니다. HTTP, FTP, gopher 등등등. 그리고 이것들은 서로 다른 포트를 사용하면서 한 대의 서버에서 동시에 여러 서비스를 제공할 수 있었고, 서버가 줄어든 만큼 네트워크도 단순해지면서 인프라 기술자는 꿈과 희망을 되찾는다.

그런데… 인터넷이 발달하면서 어째서인지 프로토콜이 HTTP와 FTP로 대동단결 해버렸다. 인프라가 외친다. 포트가 충돌해버려어어어어!!!!!

여기서 다시 장잉력을 발휘한 개발자가 숨구멍을 뚫어줍니다. 바로 vhost와 Servlet Container 같은 거. 오오오… 한 대의 서버에서 하나의 포트로 여러개의 서비스를 운영할 수 있게 되었다! 만세!!! 인프라가 활로를 찾았습니다! 잘 부탁해, 시스템!!!

삽질 토스

한대의 서버에서 표준 포트로 여러 서비스를 운영할 수 있는 기술이 보급되자 그 여러 개의 서비스를 관리해야 할 책임은 프로세스를 관리하는 시스템 엔지니어의 몫이 되었다. 그리고 이들은 인프라가 하던 것을 거의 똑같이 하게 된다. 각 서버의 리소스에 맞게 서블릿을 재분배 하는 노가다. 문제는 약간 가상화 비슷한 그 무언가가 일어났는데 그게 물리적인 현실 세계의 벽은 아니잖아? 보!안!사!고!

아아, 님은 갔습니다. 리소스 분배도 머리아픈데 보안사고도 막아야 하고 경비절감 압박도 받아야 하는데다가! 프로세스를 재기동 하려면 죽는 서비스가 하나가 아니게 되었다. 서버 하나에 서비스 하나만 돌리면 좋겠다. 그냥 재부팅 해버리게… 어… 어라? 이거다!

사장님, 이렇게 발전이 빠른 시대에는 업데이트를 자주 해야 합니다. 보안 업데이트는 물론이지요. 그런데 프로세스 재기동 하려면 서비스를 여러개 내려야 하는데 이게 또 언제 끝난다는 보장이 없어요. 저기 보니까 가상머신이라는 좋은 기술이 있던데, 이거 어때요?

가상머신입니다, 가상머신. 머신이라구요. 인프라 어딨어!!! 그때, 눈치없는 애플리케이션 개발자가 옵니다. 사장님, 서버 한대만 더 사주세요. 어, 그래. 마침 잘 왔네. 뭐, 눈치가 없으면 몸뚱이를 갈아넣는 수 밖에요. 인프라 조금 시스템 조금 애플리케이션 왕창 모아서 가상머신 관리 조직을 만듭니다. 인프라는 그대로 물리적 서버와 네트워크를 관리합니다. 시스템은 가상머신 데몬프로세스를 관리합니다. 애플리케이션은… 서버를 필요할 때마다 받을 수 있는 걸로 착각하고 있습니다. 모두가 해피해피. 하아…

하드웨어의 가동률을 끌어올려서 싸장님이 좋아하고 하드웨어가 비교적 줄어들어 편해진 인프라가 좋아하고 관리할 시스템 서비스가 줄어 시스템이 좋아하고 늘어난 서버 인스턴스가 반가운 애플리케이션 개발자 모두가 행복의 해피를 외치는 와중에, 사장님이 생각합니다. 가상화 좋네? 그리고 외칩니다. 경!비!절!감! 가상머신이 당연해지면서 인프라에게 넘어갑니다 가상머신도 OS 깔렸잖아 하면서 비교도 안되게 많은 게스트OS가 시스템에 넘어갑니다 애플리케이션이 말합니다 나는 아직 서버가 더 필요해! 그리고 어느 날 어느 개발자의 잘 보이고자 하는 욕구 혹은 잉여력 아니면 둘 다에 어른의 사정 같은 기타 등등이 만나서 폭발합니다. 그리고 LXC가 탄생합니다.

아아… 시스템은 그나마 편해졌습니다. LXC는 컨테이너OS를 쉘스크립트로 관리할 수 있을 것 같이 생겼습니다안써봐서 모름. 오오, 애플리케이션이 날뜁니다 더더욱 가상화된 컨테이너 덕분에 쓸 수 있는 서버 인스턴스의 수가 늘어났습니다. 이제 개발환경에서도 운영환경과 거의 같은 아키텍처를 만들 수 있을 것 같습니다. 싸장님도 좋아하는 것 같습니다아마도. 인프라는 이젠 털었습니다.

그리고 그 날이 왔습니다.

자, 다 해줬지? 어서 만들어. 빨리. 당장. 롸잇나우. - 싸장님

인프라는 손 털고 시스템에 요청하라고 합니다. 시스템은 너네 필요한대로 구성해서 알려달라고 합니다. 애플리케이션이 생각합니다.

LXC로 OS컨테이너를 만들어도 그 안에선 시스템을 다뤄야 합니다. 그런데 시스템이 바로바로 해주는 건 아닙니다. 할 일은 늘었는데 그렇다고 필요한 게 바로 다 되는 것도 아닙니다. 그래서 애플리케이션이 빡이 칩니다.

그런데… LXC 이거 물건이네..?

태초에는 히어로너드가 한둘 있었다

아… 씨… 오일러 너 이… 형이 왜 여기서 나와?

– 어느 이공대생

태초에 히어로너드가 있어 혼자 다 해먹었다. 정말이다. 정말로 혼자서 다~ 해드셨다. 그것도 잘.

그래서인가. 설계고 뭐고 없었다. 그냥 혼자 다 했다. 다 해서 굴리고 자랑하고 팔아먹고 그랬다. 그런데 한계가 왔다. C&P는 어둠속의 한줄기 빛 처럼 처음부터 있어 공도리의 발 밑을 비췄다. 뭐… 고출력 대형 레이저라 놔두면 싸그리 몽땅 불싸지른다는 게 문제지.

어쨌든 이래선 안되겠다 싶어 자료구조가 보급되고 그래도 안되니까 OOP가 나오고 코드만 가지고 아무리 지지고 볶아봐야 안되니까 폭포수가 나오고 그래도 안되니까 모듈이 나오고 라이브러리가 나오고 그래도 안되겠다 컴포넌트도 나오고 그랬다. 그런데, 아무리 설계를 잘 하고 코드를 돌려 쓰고 바이너리를 돌려 써도, 안되더라. 한번엔 안되더라.

조금씩 만들어보자고 애자일이 나오고 스크럼이 나오고 린스타트업이 나오고 그랬다. 그런데도 안됐다.

그 와중에도 옛 시스템은 계속 살아 남았고, 개발자는 이고 지고 한 짐도 많고 죽겠는데 레거시가 발목을 잡는다. 그 와중에 경영자가 외친다. 경!비!절!감!

레거시를 안전하게 처리하고 지금 코드가 레거시가 되지 않도록 해보겠다고 단위테스트를 만들고 통합테스트를 만들고 왜 빨리 안되냐고 닥달하는 싸장님 상납용으로 TDD라고 멋들어진 말도 만들었다.

가뜩이나 처리량 몰리는 DB를 좀 쉬게 해주고 어디서 뭐가 어떻게 돌아가는 건지 알 수가 없는 PL/SQL 좀 걷어내보자고 이런저런 트랜잭션 매니저를 만들고 겸사겸사 C&P의 늪을 벗어나고자 OM도 만들었다. 그런데 그걸로는 택도 없더라 해서 ORM을 만들었다.

그런데 ORM을 만들고 나자 너무나도 편해졌다. 오오오… 메모리에 있는 인스턴스만 만들면 DB 동기화는 ORM이 다 해줘! 오오오오오오!!!! 이거 좀 더 어떻게 어? 이렇게 저렇게 어? 잘 좀 어? 걍 툭 좀 어?

그리고 그렇게 DDD가 나왔다. 모든 것을 도메인 오브젝트를 중심에 놓고 개발하겠다면서.

… 다른 할 게 많았지만, 이러다간 끝이 안날 것 같아서 급 마무리.