[Start up] 스타트업 개발자의 허심탄회한 이야기 (시작)

5. 프릭스 헬스케어 개발자들과의 미팅

킹밥(기획자)과의 연락을 시작으로 프릭스 헬스케어의 개발자 두 분과 토토로(대표)와 구글 meet를 사용한 미팅이 잡혔다. 킹밥이 서비스에 대한 설명이 작성된 노션 페이지 링크를 전달해줘서 전체적인 서비스에 대한 설명은 미리 알 수 있었다. 간단하게 소개하자면 프릭스 헬스케어는 영유아 건강관리 서비스로 아이의 건강관리를 한 앱에서 모두 처리할 수 있게 하는 서비스이다. 그 때 당시에는 버전 1이 배포된 상태여서 현재 버전 2와는 다르지만 일단 소개하자면 여기를 눌러서 확인할 수 있다.

미팅이 시작되고 우선 먼저 우리들이 해왔던 프로젝트들에 대한 질문을 받았고, 이해하기 쉽게 포트폴리오를 정리해둔 노션 페이지 링크를 전달하며 대화를 나눴다. 그 후에는 현재 프릭스 헬스케어에서 사용하고 있는 기술 스텍들에 대해 이야기를 나눴다.

당시 웹 페이지는 react, typescript 기반으로 작성되고 상태 관리에는 MobX를 사용하고 있었고, 앱은 react native, typescript 기반과 상태 관리에 MobX를 사용하고 있었다. 백엔드는 Go와 python으로 작성되고 docker와 docker swarm, aws로 서버를 관리하고 있었다.

기술 스택 이후에는 회사의 비전과 성장 방향을 공유했고, 다음에 회사를 방문해서 시스템 구조와 코드들을 구경하기로 했다.

가벼운 미팅이었지만 프로그래밍에 대한 사랑과 열정이 느껴졌고 우리도 매우 재밌는 미팅으로 느껴졌다.

6. 프릭스 헬스케어 방문

미팅 이후에 약속을 잡고 회사에 방문했다. 회사에 도착한 후 토토로와 셋이서 회사의 방향성에 대해 좀 더 깊게 이야기를 나눌 수 있었다. 첫 미팅 이후에 나와 친구가 회사의 방향성에 대해 우려스러웠던 부분에 대해 질문을 했고, 토토로는 그 또한 많이 고려해봤다는 듯이 자연스럽게 대처 방안 등을 말해줬다. 이 때 '여기서 개발해도 되겠다.'라는 생각이 들었던 것 같다. 하지만 안타깝게도 그 날이 공휴일이어서 다른 개발자들은 출근하지 않았고, 따로 약속을 잡고 회사를 다시 방문했다.

두 번째 방문에 개발자들을 직접 만날 수 있었다. 함께 간단하게 저녁을 먹고 나서 시스템 구조와 코드들을 대략적으로 구경했다. 시스템 구조와 코드 부분에서 왜 이런 방식으로 작성했는 지 이해가 안 가는 부분이 다소 있었지만 아직 전체 구조를 완전히 파악한 게 아니었기 때문에 크게 신경쓰진 않았다.(이 부분은 추후 리팩토링 부분에서 다루도록 하겠다...)

그렇게 시스템 구조와 코드 구경까지 마친 후에 입사에 대한 이야기를 했다. 나와 친구는 모두 백엔드 개발자였기 때문에(나는 프론트 관련 언어도 공부해오긴 했지만 백엔드가 더 자신있었다.) 둘 다 백엔드로 입사하기를 원했지만, 프론트 개발자들이 업무량에 힘듦을 느끼고 있다고 하여 둘 중에 한 명은 프론트 개발자로 입사했으면 한다는 말을 들었다. 쉬운 결정은 아니었지만 우선 내가 프론트 개발자로 입사하기로 했고, 추후에 투자를 유치하며 개발 인력을 늘릴 때 백엔드로 넘어가기로 했다.

그렇게 우리는 프릭스 헬스케어의 개발자가 됐다. (그 때 우리를 포함해서 개발자는 총 5+1(인턴)명(프론트 3 + 1(인턴)명 + 백엔드 2명)이었다.)

7. 첫 출근

5월 31일 나는 처음으로 출근을 했다. 사무실은 서울대입구역 스프링캠프였다. 집에서 1시간 30분 정도 걸리는 거리여서 다소 멀긴 했지만 그래도 새로운 시작이니만큼 그다지 힘들지는 않았다. 도착 후에 우리는 회사에서 제공해주는 맥북을 받고 초기 세팅을 시작했다. 그 외에도 회사 이메일 계정을 만들고, Github, sentry, slack 등 업무에 필요한 여러가지 툴에 합류했다.

슬랙에는 각자의 닉네임을 적여야했는 데 우리는 애니메이션 캐릭터 닉네임으로 정하는 게 룰(?)이어서 나는 주토피아의 나무늘보인 플래시로 이름을 정했다. 정한 이유는 딱히 정할 이름이 없기도 했고...음 그냥 그 나무늘보가 운전할 때만큼은 빨라서 나도 코딩할 때 만큼은 빠르게 하겠다는 의미(?)로 정하게 됐다. 참고로 내 친구는 포비다. 뽀로로에 나오는 곰이다. 이유는 나도 모르겠다.ㅋㅋ...

첫 출근이라 기존 코드들과 시스템 구조를 파악하기 시작했다. 일단 앱이 중점인 서비스이기 때문에 앱부터 보기 시작했는 데, 앱의 전체적인 시스템 구조는 아토믹 디자인 형태였다. 아토믹 디자인이란 UI를 Atom(원자)-Molecule(분자)-Organism(유기체)-Template(템플릿) 단위로 쪼개서 코드의 재사용성을 최대화 시키는 시스템 구조다. 8개월간 사용해본 결과를 먼저 말하자면 프로젝트 크기가 작을 때는 사용할 필요가 없을 것 같다. 크기가 작은 경우에 사용한다면 오히려 어떤 부분까지 atom이고 어떤 부분까지 molecule인지가 헷갈리는 경우가 생길 수 있기 때문이다. 그걸 정하느라 구조를 짜기가 힘들다면 오히려 배보다 배꼽이 더 커지는 격이기 때문에, 크기가 어느 정도 있는(파일 갯수가 많은) 프로젝트에서 사용하면 폴더별 정리가 조금은 수월해질 것 같다.

상태 관리에는 MobX를 사용하고 있었는 데, 리덕스에 비해서 러닝 커브가 완만해서 사용했다고 한다. 사용 경험이 엄청나게 나쁜 편은 아니었지만... 리덕스 툴킷으로 얻을 수 있는 장점이 더 많아서 추후에 리덕스 툴킷으로 대체했다. 이 얘기도 추후 리팩토링에 관해 이야기할 때 자세히 알아보도록 하자.

코드를 쭉 리뷰하면서 노트에 회의 때 이야기해야할 부분을 정리해두고 프론트 회의 날짜를 잡았다.

다음 이야기

입사 후 첫 프론트엔드 개발자 회의에 대한 이야기를 이어가보도록 하자.