[Azure] 클라우드를 몰랐던 스타트업 개발자의 실수

나는 대학생때 클라우드를 공부하지 않았다.

모두가 클라우드를 찍먹 해봐야 하지 않겠냐며, 프로젝트를 클라우드에 올리고 그랬던 때이다.

 

그때의 나의 생각은, '모두가 클라우드를 한다고? 어차피 클라우드는 빌리는 거고, 본질은 네트워크, 인프라 등에 있는 거 아니야? 나는 클라우드 공부 안하고, 온프레미스를 공부해야지'

라는 마인드 였다.

조금 덧붙이자면, 클라우드의 경험은 회사에서 할 수 있으니, 그 클라우드의 근간이 되는 기술들을 학습하는데 시간을 쓰겠다는 소리였다.

 

나는 극초기 스타트업의 첫번째 직원으로 합류하게 되면서, 클라우드를 처음 접하게 되었다.

 

문제는 여기서 발생했다.

회사 내의 그 어떤 사람도 클라우드에 대해서 알고 있는 사람이 없었기에, 신입인 내가 모든 부분을 관리해야 했다.

서비스 일정은 다가오니, 주먹구구식으로라도 하려고 했던 나의 의도와는 다르게, 후회 가득한 시간들로 만들었다.

 

오늘은 나의 실수 회고 해볼까 한다.

 

1. 클라우드를 충분히 공부하지 않았다.

클라우드를 공부하는 방법을 몰랐다고 봐야겠다. 처음에는 클라우드를 만만히 봤다. 나는 그 동안 온프레미스 환경에서 네트워크 환경을 전부 세팅하면서 프로젝트를 해왔고, 집의 인터넷 구조도 바꾸고 그랬으니까, 똑같이 하면 된다고 생각했다.

 

하물며, virtualbox, vmware등을 이용해서, 해킹 공부도 했으니까. 접근법은 나쁘지 않았다. 그런데, 다른 점이라면, 클라우드를 사용하는 순간, ping 같은 것도 쉽게 사용할 수 없는 구성이 되기 때문에, 마치 블라인드 테스트를 하는 것만 같았다. 네트워크 통신이 되어야만 할 것 같은데, 통신이 되질 않으니 미치고 팔딱 뛸 내용이였다. 

 

심지어, 로그마저 어디있는지 찾아다녀야 하는 상황이 되니, 아키텍처의 규모에 비해서, 엄청난 시간을 사용하게 되었다. 끝내, VM instance 몇개 띄워서, virtualbox를 쓰는 것 마냥 구성을 하긴 했으나, 이루어 낸 것 들에 나의 기회비용을 너무 많이 태워서 놓친 것 들이 많다.

 

2. Azure를 선택했다.

클라우드를 처음 접하고, 그것이 AWS가 아닌 Azure였다. 사실 Azure를 선택하게된 이유는 큰 이유가 있는 것이 아니였다. 회사가 이미 스타트업 패키지로 Azure를 선택했기 때문이다.

 

2년전 Azure는 사람들이 "뜨고 있는 클라우드다" 라는 말이 한참 나오고 있을 때였다. 그런 것 같긴 했다. OpenAI와 계약을 통해서, 마이크로 소프트는 영업이익을 잘 내고 있었으니까.

 

그런데, 이제 와서 느끼는 점은, Azure가 돈을 잘 버는 이유를 알면서도, 모르겠다. 2년전의 Azure에는 Azure Function에서 vnet에 접근하려면, Premium plan을 사용해야했다. 문제는 이 premium plan이 월 $200라는 점이다. 그러니 울며 겨자 먹기로, premium plan을 선택했다.

즉, 초기 비용이 어마어마 하게 나온다. AWS에서 월 $200? 웬만한 초기 스타트업이면 이정도면 충분한 리소스를 쓸 수 있을 것이다. Azure에서 $200는 Azure Function(AWS의 lambda 비슷한) 하나 돌리는데 사용된다. (고정 초기 비용이 이러니까, Azure가 돈을 잘 벌지)

이 문제를 해결한 Flex consumption plan이 2025년에 처음 나온 걸로 알고 있다. 한 마디로, 클라우드 기능이 빈약했다.

 

Azure의 또 다른 문제점은 업데이트가 너무 잦았다. Azure가 업데이트를 자주 하니, 문제가 발생하면, 도대체 어느쪽이 문제인지, 신입 개발자로서는 예상되는 모든 문제점을 직접 확인해야하는 문제가 있었다. 또한, 문서의 업데이트가 느렸으며, callout으로 "이 서비스는 2025 X월 X일로 부터 사용되지 않을 예정" 과 같이 서비스 종료나 마이그레이션을 요구하는 문서도 많았다.

 

기능 개발하기 바빠죽겠는데 인프라 또 또 또 신경써야 하는 것이다.

 

마지막으로, 개발자 풀과 커뮤니티이다.

나는 Azure와 Azure 관련된 SDK를 사용하면서, 전세계에서 내가 처음으로 발견 했다고 느낀 문제점이 지금까지 2번 있었다.

아무리 검색을 해도, reddit에서 조차 이야기 하지 않은 버그 들을 발견했다. 이틀째 검색하다가 더 이상 버그를 해결 할 수 없다고, 생각할 때 쯤, 누군가가 처음으로 내가 겪은 버그를 리포트 한 글을 봤다. (그리고, 몇 주 후 버그가 pre 버전으로 fix되어 github에 올라왔다)

 

한국 개발자들이 AWS에 익숙하다보니, 그들의 리소스를 활용할 수 없는 문제도 컸다. 회사에 새로운 개발자를 뽑더라도, AWS 기반의 백엔드 개발자인 경우가 많아서, 그들의 경험과 능력을 십분 활용하기도 힘들었다.

회사든, 개발자든, 이익이든, 성장이든 전부 손해를 보고 있던 것이다.

 

3. 아키텍처 설계를 충분히 하지 않았다.

네트워크, VM, 서버리스 서비스, storage 등 어떤 것을 언제 어떻게 사용할지 제대로 설계하지 않았다.

되기만 하면, 넘어가니, 서비스의 견고함이 떨어지고, 결국에는 뭐.. 생략하겠다.

설계를 하지 않으니, 알게 모르게 계속해서 부족한 부분을 채우기 위해서 클라우드 구성에 시간과 비용이 들어가기 시작했다.

이는 곧, 비용 산정, 트래픽, 용량 등 숫자들을 예측을 하기 힘드니, "보고"의 차원에서도 문제고, 가치를 판단하는데에도 문제가 발생했다.

 

4. 크래딧을 맹신했다.

스타트업은 클라우드 업체들로 부터 크래딧 혜택을 받을 수 있다. 기간제 1억원에 가까운 크래딧을 받게 되니, 구성원 전체적으로 "공부하는데 사용해도 좋으니까, 서비스 들을 구성하고 비용은 천천히 줄이죠? 무료잖아요" 라는 마인드가 된다.

크래딧을 맹신한건데, 사실 이 마인드는, "크래딧이 종료되면, 망하죠!" 라는 마인드와 같다.

비용을 줄이는 것은 정말 쉽지 않다. 맨 처음부터 비용을 계산하고 그것에 맞는 아키텍처를 설계 했어야 한다.

 

예를 들면 단순히 매 1분마다 연산해야하는 값이 필요하다면, 비용이 적게 드는 VM내에서 직접 Crontab 프로세스를 띄워서 관리할 건지, 아니면, lambda같은 것을 이용해서 관리는 위탁을 할건지 등을 선택했어야 했다.

 

서비스가 잘 되지만, 비용을 줄일 수 없는 가불기에 걸렸다. 혹은, 줄이려면 다시 작업을 해야하는데, 그렇게 다시 시간과 기회비용과 회사 구성원의 리소스가 들어가기 시작한다.

인당 200만원만 받는다고 해도, 5명이 한달동안 이 업무만 한다고 하면... 회사의 입장에서는 한달치 기능이 밀린 거고, 한달치 수익이 사라졌고, 한달치 인건비가 청부된 것이다.

 

5. 오지 않을 미래를 계획했다.

지금은 클라우드를 이대로 두고(기술 부채로 하고), 일단 구성하고, 일정을 맞추자.

기술부채(tech debt)는 투자를 받고, 처음부터 갈아치우듯이 새로 개발하면 되겠지 라는 생각을 했다. 생각해보면 정말 멍청한 생각이였던게, 지금도 시간이 없는데, 투자를 받았다고 시간이 여유롭다고? 투자사는 이 회사가 더 확장될 거라고 생각했는데, 처음 부터 개발한다고 하면 과연 좋아할까? 이런 생각을 해봤어야 했다.

 

"나중에 갈아 치우면 괜찮아" 라는 마인드로 기술부채를 만들면, 추후에, 기획에 따라서, 이도 저도 못하는 상황이 반드시 온다.