제가 다니는 스타트업 회사도, 이런 회사에서의 경험이 처음인 저도 매 순간이 새로운 일들의 연속입니다. 그래서 이번 분기에도 그동안의 일들을 되돌이켜보며 적어 봅니다.
클라우드는 무안단물인가?
회사 서비스가 클라우드를 쓰고 있다 보니 관련 이야기를 많이 할 수밖에 없는데, 그 중 근본(?)을 흔드는 주제의 이야기를 한번 한 적이 있었다. “과연 클라우드는 정말로 만능인가?”. 분명히 클라우드 또한 단점이 있고, 사용하는 입장에서 분명 그것을 알고 있지만, 사실 그게 잘 드러나지 않기도 하고 인지하지도 않는다. 어째서 그럴까.
분명 클라우드는 여러 가지 장점이 있다. 가격이 싸고, 확장성 좋고, 인프라 구축에 투자 안 해도 되고… 그래서 오늘날 많은 기업들, 혹은 개인들도 클라우드 서비스를 이용하곤 한다.
먼저, 클라우드의 잘 알려진 장점중 하나는 “비용이 절감된다” 이다. 과연 그렇기만 할까? Peak가 없이 24시간 제공되는 서비스(ex. 스마트홈 같은 인프라)와 같은 경우에는, 동일 비용으로 클라우드를 쓰는 것보다 고전적인 방식으로 인프라를 구축하는 것이 더 저렴한 것이 잘 알려진 사실이다. 또한, AutoScaling이 켜져 있는 경우, 자신도 모르는 사이에 무지막지한 비용이 청구될 수도 있다.
실제로 우리 회사와 같은 경우에도 꾸준히 클라우드 리소스가 낭비되고 있는지, 혹은 절감할 수 있는 부분이 있는지 확인한다. 어떤 직원이든 이러한 절차는 가차 없다. 테스트용으로 오픈한 EC2 머신 1개라도 일주일 뒤에 쓰지 않는다면 빠르게 반납당한다.
한도를 잘 정해놓지 않고, 꾸준한 모니터링 없으면, 비용 절감은 절대로 클라우드의 장점에 해당하지 않는다고 생각한다.
또 하나의 관점은, 과연 세팅에서 자유로울 수 있는가? 이를 테면 Lambda처럼 쉽게 인스턴스 설정이 가능하지만 램 용량의 제약이 있다. 이는 위의 비용 절감 이유와 맞물려서 tight하게 리미트가 걸려있는 경우가 있는데, 한도를 넘어가는 입력이 들어올 경우 OOM에 맞닥뜨리기도 한다. 혹자는 Auto scaling이 답이라고 하지만, 이미 돌아가는 인스턴스의 메모리를 맘대로 확장하기 쉽지 않을 뿐더러, 비용 문제 또한 맞물리게 된다. 결국 근본적인 인프라 세팅에서 자유로울 수만은 없는 것이다.
그럼에도 불구하고 분명한 장점이 있기는 하다. 다각화된 Region이나 빠른 scaling 특징으로 Failover에 대처하기는 아주 좋다는 것. 그래서 결국 클라우드가 나름의 필요는 있다. 다만, 잘 알고 써야겠지…
그리고 또 한가지 간과해서는 안 될 것은, 보통 기업 스케일의 거대한 스케일의 서버를 사용하는 경우, 혹은 스타트업/벤처와 같은 경우 암암리에 세일해주는 경우가 많다는 거다. 거기 까지 고려한다면, 클라우드는 꽤 비용적으로도 생각보다 나쁘지 않은 선택지가 될 수도 있다.
중요한 건 제한된 리소스
위에 썼던 Lambda OOM 사례에서 이야기를 다시 시작해보면, 우리의 알고리즘 상에는 별 문제가 없었다. 하지만 새로 들어온 고객이 일반적인 규모와는 다른 어마어마한 데이터를 쏟아붓는 바람에 문제가 발생한 것이다.
보통 알고리즘에서 이러한 경우의 문제라면 알고리즘의 기본 접근 방식이 잘못되었을 경우가 많다. 뭐 대충 이를테면, 위상정렬을 할 때 Memory complexity를 O(N) 으로 잡을 수 있는 걸 O(N^2) 꼴로 해서 터진다던가 … 말이다. 하지만 이 경우는 N 자체의 한계치에 대해서 별로 생각해보지 않은 것이 문제이다. 뭐, 위상정렬 할 때 끽해봐야 1000개의 노드가 들어오겠지, 그럼 100MB 머신이면 충분하겠다, 이렇게 생각할 것이다. 그러다 1000만개가 들어오면 죽는 것이다.
이게 로컬에서 작업할 때는 그닥 티가 나지 않는다. 데이터 양이 터무니없기도 하지만, 저런 마이크로 머신에서 돌아가는 코드를 개발하는 머신은 정작 보통 빵빵한 경우가 많기 때문이다. i7에 32GB 머신에서 개발하고 테스트한걸 꼴랑 100MB 머신에서 돌린다고 상상해보면 왜 이런 이야기를 할 수 있는지 알 것이다.
그러한 수준의 스트레스 테스트를 왜 해보지 않느냐고 반문할 수도 있는데, “클라우드”에서 이걸 돌리기에는 테스트라도 너무 비싸다. 그리고 일반적인 범주의 사용자가 입력할 거라고 생각되는 데이터 양도 아니고. 여기서 또 한번 클라우드의 단점이 드러난다. 아니, 단점이라기 보다는 클라우드를 위한 개발을 할 때 조심해야 할 점이 아닐까 싶다. 어째 임베디드 하는 기분이랑 살짝 비슷하네
그러한 연유에서, 근래 (기출) 면접 문제들에서 보이는 “Max input”에 대해 고민하는 게 역량을 보는데 있어 꽤 좋은 주제라는 생각이 들었다. 정작 나도 잘 못하지만 😇
Partitioning & Parallelism
알고리즘 최적화에는 한계가 있다. 아무리 Sort 를 최적화를 시켜 O(nlogn) 같은 최적의 알고리즘을 도입한다 하더라도, 말도 안되게 큰 데이터 셋에서는 결국 n 에 비례하는 시간이 걸리게 되어서 절대 요구하는 시간 안에 끝낼 수 없는 작업이 되기도 한다. 알고리즘 최적화만으로는 해결이 안 되는 부류의 문제이다.
근래 멀티코어 시대가 도래하면서, 작업의 “병렬화”가 최적화의 한 변수가 되고 있다. 그런데 이 병렬화를 활용할 수 있는 알고리즘이 하나 있는데, 바로 “분할정복”이다. 분할정복 자체는 O(nlogn) 알고리즘이지만, 분할정복이 가지는 장점 중 하나가 병렬화가 가능하다는 것이다. 따라서 작업을 수행할 시스템 자원을 더 많이 할당해줄 수 있다. 이것이 멀티코어 시대와 맞물려서, 저렴한 Scale-out 의 장점을 취할 수 있는 것이다. 그러니까 현실적으로는 O(nlogn/m) 같은 게 아닐까 싶다.
좋은 알고리즘과 자료구조를 쓰는 것도 당연히 중요하지만, 그 외의 저런 상수적 요인에도 신경쓰는 게 상당히 재미있다는 걸 요즘 더욱 느끼고 있다. 이번 기회에 그러한 일을 할 수 있어서 즐거웠다 😄
23년도에 투자받기란
잘 알려져 있다시피, 스타트업은 투자를 받아가며 성장합니다. 회사 설립 초창기에는 얻는 수익 대비 지출이 월등히 크거나, 심지어는 아예 수익을 내지 못하는 경우도 있기 때문에 당연한 것입니다. 그리고 이러한 투자를 받을 수 있도록 투자자의 마음을 움직이게 하는 몇 가지 지표들이 있는데, 그 중 하나는 아마 회사의 "매출"입니다. 더 정확히는, 매출의 "성장" 지표입니다. 그래서 딱히 당장 수익이 나지 않더라도, 회사가 성장하고 있다는 것을 증명할 수만 있다면 투자받기는 그렇게 어렵지 않았습니다. 적어도 21년도 까지는요.
22년도 말이 접어들면서 전세계 경제가 급속도로 악화되기 시작하고, 이에 따라 투자자들은 이전보다 훨씬 보수적으로 접근하기 시작했습니다. 상장을 준비하던 회사는 급속히 떨어져버린 회사 가치에 중도 철회를 선언하고, 마찬가지로 다음 시리즈 투자받을 준비하던 회사들도 그 시기를 늦추게 되었습니다. 받을 수 있는 투자금이 택도 없이 줄었기 때문입니다.
그뿐만 아니라 투자에 대한 조건도 훨씬 깐깐해져서, 단순 기업의 성장률만 보는 것이 아니라 "그 기업이 (언제) 흑자를 낼 수 있는가"까지도 확인하게 되었다는 이야기가 있습니다. 순이익을 늘리는 방법은 알다시피 두 가지가 전제가 있습니다. 하나는 더 많은 매출과, 다른 하나는 더 적은 비용 소모입니다. 그리하여, 지금 회사도 비용 절감을 위해서 안쓰는 리소스를 해제한다던가, 출장을 최소화한다거나, 양해를 구해가며 복지도 일부 줄이는(!) 극단적인 조치도 취하고 있습니다. 생존을 위한 온갖 몸부림 중인데, 다른 스타트업 회사도 비슷하게 돌아갈 거라고 생각합니다. 아니 어쩌면 저희보다 상황이 안 좋았던 회사는 진작 역사의 뒤안길로 사라졌을지도요. 한창 Cash burning해가며 공격적으로 성장해가야 하는 시기에 비용까지 관리해야 하다니, 정말 어려운 일입니다. 아이러니하게도 그 와중에 새로 생겨나는 스타트업이나 일자리들도 많긴 하던데, 뭐 이건 이 내용이랑 관련없는 잡소리입니다.
비단 우리 회사, 스타트업뿐만이 아니라, 모두에게 힘든 23년도가 아닐까 싶습니다. 내년에는 좀 더 나아지길 바래봅니다.
어렵지만 적응해가는 영어
Engineering 연관된 교훈은 아니지만… 그래도 업무를 영어로 하니깐 밀접한 연관이 있어서 짜투리로 넣었습니다 😅
어언 외국 회사에서 일한지도 1년입니다. 그닥 변화가 없었던 것 같아도 뒤돌아 보면 정말 영어 리스닝과 스피킹 실력은 훨씬 일취월장 해졌습니다. 적어도 이제 미팅에 들어가면 상대가 말하는 건 알아듣고 답을 할 수는 있게 되었습니다. 처음에는 도대체 상대가 뭐라고 하는지 모르겠고, 머리속 해석 속도도 못 따라와서 듣고서 멍~ 하고 있었던 걸 생각하면 천지차이입니다.
그럼에도 불구하고 그대로 야생의 외국 기업에 들어가서 100%의 성능을 발휘할 수 있겠는가? 라고 묻는다면… 잘 모르겠습니다. 아직도 자유롭게 말하는 게 쉽지가 않은 것도 있습니다. 특정 상황이나 감정을 표현할 적절한 단어가 떠오르지 않아서 um… hmm… 같이 한참을 버벅거린다던가, 깔끔한 문장이 안 나와서 주어 전치사 빙빙 둘러서 말 한다던가, 아예 문장 끝을 못 맺어 버린다던가, 단어 대신 숙어 혹은 전치사 활용이 아직 좀 자유롭지 못한다던가 하는 게 아직도 느껴집니다. 특히 한국어로도 설명하기 어려운 내용을 영어로 설명하려면 속이 다 터집니다. 발표도 대화도 하는데 있어서 1.5 ~ 2배 정도의 시간과 노력이 더 소요되는게 느껴집니다. 읽는 것도 쉽지는 않습니다. 장문복마냥 몇십줄 짜리 슬랙 메시지 올라오면 본능적으로 뇌가 셧다운 되는게 느껴지거든요. 근데 한국말로 써 있어도 그랬을지도…?
또 하나 느끼는 것은, 영어 단어보다도 어구(phrase)를 모르는 게 더 어렵다는 것입니다. 다시 말해 문장을 구성하는 단어는 다 아는데, 그것들이 모여서 구성하는 뜻이 해괴한 경우가 종종 있는데 그걸 알아채는 게 꽤 고통스럽다는 것입니다. 왜냐하면 첫째로는 문장을 열심히 해석해도 뜻이 이상해서 머리를 가우뚱하는 데 큰 자원을 소모하게 되고, 둘째로는 그걸 깨닫고 찾는 것도 단어에 비해서 보다 까다로운 편이기 때문입니다 (그래도 요즘은 인터넷 치면 거의 다 나오네요. 좋은 세상.) 이를테면 “may as well” 같은 단어는 “may”와 “well”을 다 알아도 뭔가 문법적으로도 이상하고, 뜻도 살짝 꺼림칙합니다. 찾아보면 “~ 하는게 낫다” 정도의 어구로서 기능하는 걸 알 수 있는데, 이런 것들 알아내고 역으로 써먹기까지 하려고 하니 힘이 듭니다. 하지만, 이를 반복하면서 훨씬 나아지는 기분이 듭니다. 지금도 유튜브 채널을 찾아 본다던가, 영어 엔지니어링 문서(혹은 에세이)를 읽으면서 그러한 처음 보는 표현들을 익혀나가려고 애쓰고 있습니다. 상대가 문장을 어떻게 구사했는지 살펴보고 그 스타일을 배껴본다던가, 또 모르는 단어를 기억해 둔다던가 하는 식으로 조금씩 연습하는 것들 말입니다.
그렇게 부단히 노력하다 보니, 이제는 한국말로 하던 걸 다 영어로 어찌어찌 할 수는 있게 됐구나 생각을 합니다. 좋은 일입니다. 근 몇달간 사내 직원들에게 엔지니어링 발표도 영어로 몇 번 했었고, 그럭저럭 나쁘지 않은 반응이었습니다. 인도식 특유의 악센트가 섞여 들어간 영어도, 동부식 랩하듯이 하는 영어도 이제는 어느정도 들립니다. 마치 머릿속 L3 캐시가 커진 기분입니다. 1년이 좀 넘어가니 까마득했던 언어나 회사 문화에 적응하는 거 보면, 역시 Time solves everything.