웹 서비스 백엔드 바닥부터 개발한 후기

어쩌다 보니 제가 창업 초기 멤버로서 같이 일하게 되었습니다. 백엔드 개발을 부탁받았는데, 솔직히 이미 스타트업을 다니고 있는 입장에서 시간 빼기가 굉장히 쉽지 않았지만 그래도 괜찮다면 도움을 줄 수 있겠다고 이야기하여, 상호 합의하에 작업을 시작하게 되었습니다.

문제는 제가 오래전에 웹 서비스를 개발해본 바닥부터 경험은 있지만, 클라우드 플랫폼을 기반으로 제대로 된 웹 서비스 백엔드를 구축해 본 것은 처음입니다.

그래서 쉽지는 않겠지만, 이때가 아니면 못해볼 경험이라고 생각되어서 한번 도전해보게 되었습니다. 아직 진행중이기는 하지만, 어느 정도 모양은 갖추어졌기 때문에 고로 인프라 포함 백엔드를 처음부터 개발을 해보며 겪은 경험들을 한번 정리해 보았습니다.

기초 설계

으레 기업들 기술 면접을 보다보면 설계에 대한 질문이 들어오기 마련입니다. “유저수 n명의 서비스가 있는데, 이거 어떻게 설계할래?” 하는 질문들이 오면 동시 접속자수는 몇이고, 초당 TPS는 얼마이며, 병목 포인트는 어디고, 서비스 분리는 어떻게 하며, 데이터베이스 설계를 어떻게 할지, 확장성과 장애상황 대처는 되는지 등을 모두 생각할수 있는 능력을 테스트하는 거죠.

이제 그걸 직접 해 볼 때가 왔습니다. 당시 설계가 정답이라는 보장도 없고, 벤처기업 특성상 초반에는 일단 프로토타이핑이 중요해서 먼저 만들고 봤지만 (심지어 당시와 요구사항 자체가 많이 바뀌어서 설계 초안이 더이상 의미가 없을지도 …) , 적어도 이런 점들을 먼저 파악하려고 했고 거기 맞춰 설계를 했던 것 같네요.

플랫폼 선정

• AWS가 역시 강합니다. 가격 문제를 떠나서 Firebase, API Gateway, EKS, RDS 등 많은 것들을 서비스로 제공해주고 있는 점이 너무 커요. 인프라 까느라 낑낑대며 고생할 필요가 없다는 것은 시간이 부족한 상황에선 너무 큰 이점입니다.
  • 물론 예전 같았으면 EC2 수준의 인스턴스 하나만 있으면 되니까 어디를 가든 별 상관이 없었을 겁니다. python + django pip로 설치하고, yum install로 mysql 깔고, 올리고…

아키텍쳐 설계, 그리고 현실

• 아키텍쳐 설계시에는 병목이 일어날만한 부분, 메시지 유실 가능성과 중요도에 맞춰 서비스를 분리해 놓았습니다.
• 하지만 현실은 사이드 플젝이라 개발할 시간은 많지 않은데 당장 릴리즈가 급하고… 일단 덩치 큰 하나의 서비스에 몰아서 개발하게 되네요 (…)
• 그래도 차후 분리가 가능한 구조가 될 수 있도록, 데이터베이스/테이블 분리 등은 모두 철저하게 하고 있습니다.
• 개발하다 보니 아무래도 Go가 Node.js에 비해서 너무 괜찮더라고요 (…). 그래서 예정보다 빠르게 중도 변환해서, Node.js + Go + gRPC로 서비스 분리를 했습니다. 세팅이 힘들어서 그렇지, 막상 하니까 꽤 깔끔하게 되네요. (세팅만 잘 해 주면 많은 부분이 autogen 됩니다)
  앞으로의 플랫폼 확장에 대한 걱정은 덕분에 덜었습니다 ㅎㅎ.

강타입 언어로의 코딩

• 사실 Golang이 경험이 있어 더 무난하지만, 이참에 Node.js + typescript를 한번 써 보고자 모험을 감행했습니다.
  • 근데 쓰면 쓸수록 리소스 효율 측면에서 고랭이 압도적이라는 느낌이… 언어 변환을 해야 할 것 같지만 뒷사람에게 남겨두고 갑니다. 미안하다!
• 가장 큰 차이점이 Storage 데이터에 대한 접근 방법인 것 같습니다.
  • django에서는 ORM 으로 객체를 알아서 포팅해 주다 보니 신경 쓸 필요가 없었던 점도 큽니다.
  • 또 javascript 같은 경우는 굳이 attribute가 있는지 확인 안 해도 되죠. 일례로 그냥 아무 선언이나 준비 없이 process.env.CONF_THAT_I_WANT 해도 오류 안 나니.
  • 하지만 typescript는 강타입이라 속성을 확실하게 지정하지 않으면 바로 오류를 띄웁니다. golang도 마찬가지고, rust도 마찬가지고요.
  • 이러한 언어의 특징은 “Marshaling(serialization)” / deserialization 을 활용해야 한다는 것입니다. 미리 구조체를 만들어 놓은 뒤, 해당 구조체에 데이터를 쏟아 붓는 형태로 코드를 짜면 해결. marshaling 로직 자체는 미리 잘 만들어져 있어서 걱정을 하지 않아도 된다는 점이 꽤 좋은 점입니다.
    • 하지만 지원하지 않는, custom raw data라면 노가다의 향연이 있겠지요… 흑흑.

데이터베이스 선정에 대한 고민

• 예전 같았으면 mysql 하나에 온갖 조인 다 붙여서 느려터지고 메모리도 많이 먹는 데이터베이스를 썼을텐데… 이제 그러기에는 너무 많이 알아버렸습니다. RDB 만으로는 scale-out한 시스템을 절대로 짤 수가 없음을 알고 있습니다.
• 이젠 복잡한 자료구조에는 nosql, 그것도 종류에 따라 여러 종류를 사용하는 구조로 짜게 되었습니다. 확실히 효율적이고 빠릅니다.
• NoSQL도 통상적인 조인 기능 같은 것들을 안 쓴다 뿐이지, 용도에 따라 굉장히 다양한 형태로 읽고 쓰고 있어, 내부 동작 원리나 활용성을 공부하지 않고서는 절대로 쓸 수가 없더라고요.
• 괜히 mongoDB가 무적이 아닙니다. document 기반 nosql이라고 이야기하고 있는데, 대부분의 데이터는 document 형태인데다가 필드 확장까지 자유자재다? 치트키죠 ㄹㅇㅋㅋ.

• 물론 여기서 추가적으로 데이터 분석을 하겠다(파이프라인을 짜겠다) 하면 고려해야 할 것들이 더 생기지만, 일단은 그 과정까지는 다행히 가지 않았네요
  • 만약 한다면 kafka 및 key-value 형태 저장도 같이 해야 할 겁니다

웹 페이지를 내가 짤 필요가 없다니!

이전에 개인 프로젝트를 짤 때는 으레 어떤 식으로 사이트가 나오고, 어떤 UX를 제공할지에 대해 생각을 하고 이를 직접 짰던 기억이 있습니다. 왜냐면… 1인 프로젝트니까 결국 백엔드 프론트엔드 다 혼자서 짜야 했었으니까요. API 같은 걸 딱히 생각할 이유가 없었습니다. serve 하는 서버에서 바로 POST 요청을 처리하면 되니까요.

하지만 이제는 프론트엔드도 별개의 node.js 서버로 돌아가더라고요. 그게 백엔드에 api call을 날려서 통신하는 방식으로 동작합니다. 괜히 “React App” 이라고 부르는 게 아닌.

• 장고 시절때는 MVC 모델 기반으로 하나로 엮인 구조라, api 서빙도 html rendering도 장고가 다 했는데… 허허…

그래서, 사실상 백엔드는 API call에 대해서만 스펙 정의를 하면 되게 되더라고요. 물론, 그 합의는 프론트엔드와 함께 해야 할 필요가 있습니다. (즉 고민해야 하는 포인트가 UX에서 API로 옮겨감…)

본격 백엔드 개발

일단 서비스를 빠르게 프로토타이핑 해야 하니까, 최대한 간단한 구조에서 개발을 하기로 결정했습니다. 당연히 로컬 디플로이 / EC2 기반에서 돌리는 서비스로 시작하기로 결정했죠.

바닥부터 짜니 새로운 코드

최근의 확장 가능한 컨테이너 기반의 디자인을 이용한 아키텍쳐 및 DB를 사용하여 코드를 짜는 건 처음이었고, 그것들을 직접 만들다 보니 생각보다 낯선 부분들이 많았습니다.

• django 때는 MVC 튜토리얼이 있어서 그대로 그거 보고 따라했던 기억이 있고, golang 은 만들어진 코드 위에서 작업하다 보니 별 특이점이 없었는데, 갑자기 node.js 로 바닥부터 시작하려니 어지러워집니다.
  • api 경로마다 router, controller을 만들었는데, 이건 아닌거 같아요. depth도 너무 깊어지고…
  • controller 에서 SQL을 직접 쓰고있다 보니 코드가 너무 더럽습니다.
  • 테스트는 어떻게 넣어야 할지 앞날이 깜깜.
• 정신을 차리고 고민 후에 싹 다 갈아엎습니다.
  • Mocking을 위해 Store interface를 구성하고, Storage 관련된 객체들을 모조리 다 거기 집어넣기 ⇒ Model
    • store interface를 통째로 mocking하는 건 너무 unittest의 dependency를 독립적으로 만드는 탓에 의외로 기능단위에서 버그를 유발할 가능성이 높아서, fake store implementation 만드는 쪽이 더 나을 수 있습니다.
  • Model / Controller / Router(View?) 의 분리
    • 컨트롤러/스토리지가 너무 비대해지면 필요시 폴더를 하나 더 확장해서 만들어 넣기
      (이후에 이를 기반으로 서비스 분리 할 수도 있도록…)
  • Dependency Injection 도입
    • 앱이 시작할 때, 일종의 Context를 만들어서 통째로 넘겨주도록(injection) 만들었습니다.
    • 기존에는 명시적으로 Config, Model, Mysql, Moose 등 온갖 객체들을 초기화하고 넘겨주느라 진이 다 빠졌는데, 이렇게 만드니까 객체 초기화도 “Dependency 초기화"로 퉁칠수 있어서 편리하고, 런타임 때 Dependency 하나만 전달할 수 있어서 좋고, 불필요한 글로벌 상태 변수를 안 만들 수 있고, 라이브러리 변경시에도 충격이 적어서 자연스럽게 훨씬 깔끔하게 코딩이 됩니다. 의외로 간과하던 점인 듯.
    • 테스트 할 때도 아주 편리합니다. dependency를 테스트 용으로 초기화해서 넣으면 끝이니까요.
    • 이것도 마찬가지로 필요하다면 여러개의 dependency로 나누어서, 이후 서비스 분리의 기준이 되도록 합니다.
    • 이건 비단 웹 서비스 개발 뿐만 아니라 통상적인 개발시에도 고려해 볼만한 점.
  • (가능하다면) 파일마다 유닛 테스트 붙이기, 그리고 이를 위한 mock 폴더 추가
• 이렇게 코드를 짜니 코드가 한결 다시 안정적으로 되었습니다. 확장하기도 좋네요. 문제 해결.

컨테이너 기반 빌드 도입

백엔드 개발의 또다른 묘미 중 하나는 개발 환경 구축입니다. 특히 혼자 개발할때는 대충 막 (?) 개발하고 빌드해도 되지만, 여럿이서 작업하는 경우에는 그럴 수가 없습니다. 남들도 해당 세팅을 구성할 수 있어야 하고, 빌드할 수 있어야 하거든요.

그런 점을 신경쓰게 되면, 로컬에서 빌드 세팅을 하는 것은 결코 쉬운 일이 아닙니다. 다른 사람들이 빌드하려고 하면 “이거 하려고 하는데 안 돼요!” 라는 질문을 으레 받게 됩니다. 그럴 수밖에 없는 게, 빌드 환경이 유저별로 동일할 수가 없기 때문입니다. 또, 단순 로컬에서 테스트 서버가 올리고 싶을 뿐인 프론트 개발자에게는 빌드환경을 갖추는 것 또한 고역인 점도 있고요. 그리고, 가장 큰 이점으로 실행 환경에서의 업그레이드가 컨테이너 기반인쪽이 훨씬 쉽습니다.

그래서 언젠가는 컨테이너 기반으로 빌드가 될 수 있도록 구성을 해야 했고, 미루고 미루다가 구축을 했습니다. 여러 툴들을 연동하여 실행하는 스크립트를 짰는데, terraform output으로부터 deploy 할 주소를 전달받아 build 수행하고, 이를 docker push 하여 remote에 올리는 스크립트가 완성되었습니다.

컨테이너로 빌드하는 스크립트는 새로운 경험이라 역시 익숙하지는 않네요 😅 그래도 일단 컨테이너 빌드 스크립트를 만들고 나니 위 문제들은 확실히 해결되었고, 제 입장에서도 로컬테스트 하기 꽤 수월해 졌습니다. 그리고 단순 주력 백엔드 언어 외에도 빌드 관련 스크립트 (다중화된 유저에서의 python, shell, docker 명령어 등) 를 만들고 짜는 좋은 경험이 되었습니다.

인프라 개발

컨테이너(도커)는 그나마 좀 써 본적이 있다 쳐도, 인프라 쪽을 짜 보는건 정말 처음이었습니다. 어떤 일을 해야할지 잘 몰라서 방향도 이리저리 좀 바뀌었지만, 결국 CI/CD까지 짜고 나니까 꽤 안정적인 모습이 되어서 보기 좋네요. 여기까지 작업을 해야 “요즘의 웹 서비스 개발 환경이 되는구나" 생각이 들었습니다 ㅎㅎ.

시작은 On-Premise / EC2

빠르게 개발을 하기 위해서 일단 인프라쪽에 신경 하나도 안 쓰고 작업할 요량으로 로컬 개발을 하고, EC2 인스턴스에 이를 동기화하는 과정을 시작했습니다. 뭐, 다들 시작은 이렇게 하잖아요?

물론 이대로 쭉 갈 생각은 아니었고, 테라폼도 직접 배우고 써볼 계획이 있었기 때문에 초기 개발을 마무리짓는대로 본격적인 인프라 개발을 할 예정이었습니다. 그리고 그 때가 왔습니다.

처음으로 써보는 IaC

언제나 그렇듯이 인프라 짜는 일은 의외로 시간을 많이 차지하고 삽질을 동반합니다. 그래서 보통 개발자 사이에서는 기피(?) 업무중 하나기도 한데, 그 원인중 하나가 컴포넌트의 버전 충돌 문제, 미묘한 (통일되지 않은) 환경 차이 맞춰주기 등이 원인입니다. 덤으로 프로덕션 실행을 위해 관련 디펜던시를 뭔가 잔뜩 깔아줘야 하는 것도 아주 귀찮은 요소. 직접 삽질 플젝으로 만들면서 많이 겪어봤죠…

그런데 요즘은 IaC(Infrastructure as Code) 시대가 도래하면서 그러한 문제가 많이 줄었습니다. 이를테면 terraform이 있고, docker과 자동화된 CI/CD 들도 이에 한몫 합니다. 코드로 환경과 버전 및 프로세스를 확실하게 정의할 수 있어서 기존 인프라 구성을 기피하는 요소가 많이 줄었습니다.

그렇게 제 IaC 로서의 첫 도전이 시작되었습니다. 많이 쓰는 Github Action, Docker & k8s, terraform으로 구성하기로 정하고 작업했는데, 생각보다 배울 게 많았습니다. 단순 terraform만 공부하는 것을 넘어서 VPC / SG / LB 등 인프라 바닥부터 다 이해할 필요가 있었습니다. 막상 쓰더라도 인프라 쪽 오류 때문에 허덕이기도 했고요. 그리고 EKS 비싸서 ECS로 튼 것도 덤

만능일 거라고 생각한 제 예상과는 달리, 생각 이상으로 시간 및 노력이 소요되는 작업이었습니다. 그래도 그건 좋더라고요 — 코드로 짜 놓으면 적어도 인프라의 consistency는 유지된다. 이게 제일 좋은 점인 듯. 덤으로, AWS와 인프라 쪽에서 사용되는 개념(SG, VPC 등)들에 대해서 훨씬 친숙해 질 수 있었던 것 또한 아주 좋은 경험이었습니다.

Build/QA Automation: Github CI 구성

코드의 품질을 유지하기 위해 test automation도 상당히 중요한 작업 중 하나입니다. 그래서 유닛테스트를 만들어 놓고, Linter도 붙여놓고 매 push마다 돌리도록 하고 있는데 은근히 도움이 많이 됩니다. 덕분에 production 전에 버그가 발생하는 게 확 줄어서 긴급하게 대응할 일이 거의 없었습니다.

Github Linter 생각 이상으로 괜찮더랍니다. 몇개 과도할 정도로 민감하게 체크하는 린터만 끄고 쓰면 좋은 듯 😂

• Functional test도 같이 돌면 좋겠지만, 이건 나중에 Jenkins 같은게 붙거나 별도 pipeline으로 돌려야 될 것 같다는 생각이네요. 아무래도 외부 의존성이 있다 보니…

CD 구성도 생각중.

Deploy automation은 Auto deploy로 하기에는 위험하고 무리가 있어,구성을 어떻게 할지 고민 중에 있습니다 ㅎㅎ. Manual deploy가 가능하면 그렇게 하려고 하고, 이후에 기회가 되면 Jenkins로 만들면 좋을 듯…

팀 계정 관리: IAM 및 Team 기능 사용

아무래도 회사에서의 개발은 개인 단위의 개발과 달리 아래와 같은 특징이 생긴다.

• 특정 계정에 여러 사람이 접근할 수 있어야 한다.
• 단일 유저가 여러 계정(prod, dev1, dev2 ...)들에 접근할 수 있어야 함

보통 이런건 인프라 쪽에서 세팅을 다 해주기 때문에 그닥 자각하지 않는 점이지만, 이번에는 이야기가 다르다. 내가 이 인프라를 직접 구축해야 한다!

다행히도 참조할만한 글이 있어서 이처럼 인프라를 구성하기로 했다.

보면 알겠지만 Root 계정에서 각 유저(IAM을 이용하여)와 여러 AWS account(role을 사용하여)를 관리할 수 있는 구조이고, 이를 통해 root 계정을 직접 접근하지 않아도 된다는 큰 이점이 있었다. root 계정을 직접 접근하는 방식으로 관리해야 했다면, 해당 계정 정보를 모두가 공유해야 했을 테니 보안상으로 훨씬 위험했을 것이다!

terraform에서도 root 계정으로 role을 사용할 수 없도록 아예 정책상으로 못박아 놨다. 하려고 하면 `AssumeRole` 오류가 발생한다. 그만큼 root 계정 직접 사용은 위험하다는 것을 알려주는 건데, 인프라를 직접 구성하기 전까지는 몰랐단 사실이었다. 이전에 무신경했던 root 계정 관리에 대해서 앞으로는 신경 쓸 수 있는 좋은 계기가 되었다.

여기에 한 가지 더 덧붙여서 IAM Identity Center을 사용하는 방식으로 만들었는데, 이 방식을 사용하면 control center별 URL이 주어지고 이를 통해 접속하여 AWS 인프라에 접근할 수 있게 된다. 기존에는 AWS 사이트에서 root ID를 사용하여 직접 IAM 로그인을 해야 했다면, 이 방식은 회사 사내 인프라를 접근하는 것처럼 사용할 수 있어 훨씬 편리하고 친숙한 인터페이스를 보여준다는 데 장점이 있다.

이렇게 awsapps.com 으로 된 고유 주소를 가지게 되고, 여기에 해당되는 여러 계정을 묶어서 한번에 볼 수 있다! 한 번 써보면 매우 편리함.

DB로는 MongoDB Atlas를 사용하고 있었는데, 여기도 마찬가지로 Team 단위 organization 관리가 가능하기에, root organization에 team을 만들고 멤버를 초대하는 방식으로 root 계정을 이용하지 않고도 인프라 관리를 할 수 있었다.

프로젝트 매니징

원래 뭔가 나서서 하는걸 즐기지 않습니다. 누군가 매니징 해 준다면 땡큐고, 전 거기 따라가는 성향이거든요. 그런데 초창기 프로젝트 치고는 아무도 나서서 개발 설계를 하려고 하지 않습니다. 이러면 제가 하는 수밖에 없거든요 ㅎㅎ. 몇가지 문화를 만들어가며 프로젝트 매니징을 해 봤습니다.

살짝 매니저 트랙을 타는 CTO가 된 기분으로…

적용한 내용들 중 약간은 맨먼스 미신이나, 구글은 어떻게 일하는가 같은 외국 실벨 문화 서적에서 읽은 개발 문화에서 참고한 내용도 좀 있었습니다.

뭔가 답답하다

• 사이드 프로젝트를 여럿이서 하는 건 처음이네요~ 제가 벡엔드다 보니 프론트엔드와 같이 일하게 되겠습니다. 저는 열심히 설계와 개발을 하고, 모든것을 문서화
• 그런데 뭔가 답답합니다. 데이터베이스 구성하고 처리 로직을 짜야 되는데, 그러려면 요구사항을 알아야 하고, 그러려면 유저 시나리오나 인풋/아웃풋 데이터, 하다못해 API 라도 알아야 하는데 아무것도 없습니다. 요청할 창구도 딱히 없어 보입니다.
• 다들 문서와 일정 공유하는 상황을 보니 K 메신저로 가끔 생각날 때 주고받는 게 전부더라고요. 정보를 주고받는 시간도 오래 걸리고, 기본적으로 작업을 공유하질 않으니 전체적인 상황 파악이 어렵습니다. 답답함이 느껴지는 거 보니 이대로는 안 되겠습니다. 누군가 나서서 이 환경을 바꿔야 할 것 같습니다. 그래서 제가 나서 봅니다…

설계 우선 반드시 문서화하도록, 개발은 1 PR 1 issue

• 일단 해야겠다 싶은 일들을 싹다 이슈로 만듭니다. 이슈가 너무 크면 보는 사람도 이해하기 힘들고, 이슈 만드는 사람도 내역 공유하기가 힘든 점이 있어 “1PR, 1 issue” 를 신경써서 하는 원칙을 내세웁니다.
• 아무 내역없이 설계가 부족한 부분도 이슈로 만들어서 잊지 않도록 함과 동시에 공유하고, 일정은 대충 주 단위로 이슈 내역을 캘린더에 쿡쿡 찍어 두었습니다.
• 이를 통해, 굳이 내가 이런 일을 했다는 걸 매번 채팅창에 통보하는 것이 아니라 (카카오톡 채팅은 그만!!!), 팀원들이 언제든지 티켓을 통해 서로 확인할 수 있게 하고, 필요한 경우 소통창구로서도 역할을 할 수 있게 되니 소통의 답답함이 훨씬 줄었습니다. 정확히는 소통할 필요가 덜어지는 거죠. 모든것을 적어놓고 공유하면 상대가 물어보지 않아도 쉽게 파악할 수 있으니…
• 해야 할 일들을 이렇게 명확하게 찍어놓으니 사람들도 쉽게 이해하고, 이에 대한 의견을 좀 더 분명하게 많이 내놓는 모습이었습니다. 이렇게 보니, 역시 그동안 발표에 대한 질문이 적게 들어왔단 경우는 상대가 이해할 정보가 부족했던 게 아니었을까 하는 생각도 듭니다.

Short sprint, short meeting but often

• 잦은 미팅을 두려워하지 말자: 미팅을 일단 짤막하게라도 (할 말 없으면 5분컷) 자주 만나는 방식으로 하기로 정했습니다. 서로의 Blocking 요소를 알 수 있는 좋은 자리가 미팅입니다. 자주 만나서 그러한 요소를 없애는 것이 개발 효율을 올리게 합니다. 미팅 시간에는 내용 공유 및 개발 진행을 보고 받고(하고), 만약 진행이 느리다면 왜 느린지 blocking 요소를 파악할 수 있겠죠. 미팅을 기본적으로 꺼리는 이유가 길고 무의미한 시간 소모인데, 꼭 필요한 요소만 공유하도록 짧게 한다면 그런 문제는 없겠죠.
• 마찬가지로 sprint를 짧게 만들어서 (보통 2주 단위로 많이들 합니다), 단기적인 목표를 설정하고 거기 맞춰서 주도적으로 작업할 수 있는 환경을 만들고자 했습니다.

헙업 툴

• 아무래도 속도전으로 승부를 봐야 하는 상황이다 보니, 입문 장벽을 최대-한 낮추기 위해 JIRA 대신 Notion을 쓰기로 결정했습니다.
• 한가지 아쉬운게 Notion의 캘린더 기능은 좀 부족한 느낌이라는 것. JIRA의 Story Point나, 보드 화면, 자동 번호매김(이슈 고유 번호), issue간 dependency 같은 것들이 아쉬울 때가 있습니다.

물론 이 모든 걸 다 적용한다 한들...

팀원이 그만큼 잘 따라와 주지 않으면 힘듭니다. 이를테면 문서화 하라고 칸을 다 만들고 공유까지 해도 아무런 반응이 없는 팀원, 작업 내역을 티켓으로 안 만들고 PR없이 그냥 커밋 때리는 사람들 등등... 같이 일하면 무슨 일을 하는지도 알기가 힘듭니다. 그나마 짧은 스프린트 및 미팅을 통해서 어찌어찌 진행상황을 공유라도 해서 망정이지...

혼자하는 개발이었으면 상관이 없겠지만 같이하는 개발이라면 항상 공유할 수 있는 태도가 되어야 모두가 최대한의 성능이 나온다고 생각합니다. 괜히 회사에서 단순 개발 잘하는 사람을 넘어, 주도적이고 적극적으로 문서화 및 공유하는 핏을 가진 사람을 뽑고자 하려는 것이 아닐 것입니다.

그 외

본업 하면서 하려니 힘들다

제가 다니는 회사는 전형적인 IT기업답게 탄력근무지만, 그렇다고 할 일이 적은 편은 아닙니다. 이래뵈도 스타트업이기도 해서 자체적으로 일감이 많기도 하고, 오히려 근무시간 내에 부지런히 달리지 않으면 하려고 했던 일을 다 못 하는 경우가 부지기수입니다. 그래서 근무시간을 쪼개서 사이드 플젝을 하는것은 사실상 불가능입니다. 혹시라도 하면 그날은 밤까지 내내 밀린 작업 하기… 😭

그렇다고 집에 오면 시간이 많느냐? 그것도 아닌게, 헬스하고 좀 적당히 몸과 마음을 추스리고 나면 어느새 저녁 10시입니다. 슬슬 시작해서 작업좀 하다보면 새벽 1시, 2시 되기가 부지기수입니다. 이렇게 매일 살면 확실히 지쳐요. 그 와중에 회사도, 사이드 팀 플젝도 기껏 일 끝내놨더니 계속해서 이슈가 추가됩니다.

만고의 진리: 일을 열심히 하면 더 일이 생깁니다.

그래도 번아웃 오지 않게 하려고 스스로 철저한 관리를 하려고 노력했습니다. 이를테면 밤새는 일 없이 시간 되면 일 커트하고, 규칙적인 루틴 — 운동, 휴식 — 은 지키도록 노력했습니다. 그래도 여전히 제 인생 중 제일 바빴던 기간이 아니었나 싶네요. 딱히 외부 스트레스가 없음에도 불구하고, 스스로 느껴지는 스트레스 지수가 알게 모르게 있었던 것 같습니다.

창업의 시작은 변수덩어리

대기업, 스타트업 모두 다녀봤지만 창업의 완전 시작단계를 같이하는 건 처음이었습니다. 그래서 사업 아이템이 어떤 식으로 결정되고 자금 흐름이 어떤식으로 돌아가는지 보는 것도 처음이었습니다.

먼저 아이템이 나오기 전까지는 있는 자본을 사용해가며 프로토타이핑을 진행하는데, 이 과정에서 투자처의 영향을 굉장히 많이 받게 되어 아이템이 거의 뒤집어지는 수준으로 바뀌는 경우가 많습니다. 사실상 제품을 하나만 만드는 게 아니라 여러개를 만드는 정도의 작업을 해야 될 수도 있고요. 그리고 이 동안에 별도의 투자를 못 받고 비용을 순수 부담해야 해서, 빠르게 프로토타이핑을 만들어서 승부를 봐야 합니다. 사실상 이때가 창업에서 제일 힘든 시점이구나 생각이 들었습니다.

이후에 어느정도 프로토타이핑이 되면 본격적으로 투자를 받을 준비를 합니다. 자본을 빠르게 당겨오기 위해서 A 시리즈 이전에 Pre-A 시리즈 등의 별도 투자유치를 하는 경우도 있는데, 어느쪽이든 이 단계까지 오면 그래도 변동의 폭이 점점 적어지기 때문에 편해지는 것 같습니다. B/C 시리즈 정도 오면, 기대했던 자본흐름만 유지한다면 거의 안정적인 회사의 모습을 갖추게 되는 것 같네요.

가끔 보다 보면 이렇게 본업과 함께 부업이나 공부를 하면서 여자친구, 더 나아가서는 가정(!)까지 책임지시는 분들 존경스럽습니다. 전 아무것도 없어도 제 스스로 할일 하는것도 쉽지 않네요.