1. 기대 관리(Expectation Management)

창업 동아리에 가입했을 때, 조원들 중에 내가 제일 나이가 많았다. 자연스럽게 조장의 역할을 수행하면서 내가 조원들에게 물어봤던 질문 중 하나는 다음과 같다. 자신이 "창업" 동아리에 왔다고 생각하는지, 창업 **"동아리"**에 왔다고 생각하는지. 같은 팀으로서 이런 align이 맞지 않으면 분명히 우리의 사이가 틀어지게 되니, 만약에 우리가 전부 "동아리"로써의 활동을 기대하고 온것이라면 매주 나오는 숙제를 쳐내기 쉬운 창업 아이템을 잡고, 맛집과 술집에서 "동아리" 활동을 하는 것이 맞지 않겠냐고. 그렇게 우리조는 한마음 한뜻으로 열심히 술을 마시면서 즐거운 동아리 생활을 했다. 👏

2.Worst Case 술게임

술 얘기를 해서 생각난, 신입생이 막 Binary Search를 배웠을 시기에 정말 잘 먹히는 Worst Case 술게임을 소개한다. 개강파티 쯤이 아주 적격이다. 신입생에게 번호를 주기 위해 술 먹이는(!) 자리에서 내가 아파트 몇층 사는지를 맞춰보라고 하고, 내가 사는 아파트가 총 몇층인지 알고 싶으면 한 잔 먹으라고 한다. 그럼 이제 신입생들은 한 잔을 먹고 up-down 게임에서 이진 탐색을 수행한다. 하지만 아쉽게도 나는 학교다닐 때 1층에 살았다.

3. 데이터베이스 테이블명으로 Service를 쓰지 말자

조금 더 정확하게 표현하자면, RoR에서 예약어로 등록된 단어들을 데이터베이스 테이블명으로 사용하지 말자. 이 테이블에 연관된 Service 레이어를 만든다면 정말 귀찮아질 수 있다. 코드 레벨에서 자주 사용하는 단어 (Thread 등) 또한 비슷한데, 이런 케이스를 잘 모아놓은 것이 위에 링크를 건 RoR Reserved Keywords라 생각한다. 조금 더 나아가서, 서비스 기획 레벨에서 사용하는 용어에서도 이 예약어 목록을 피하자.

4. 통계 API의 time은 utcTime이 아닌 localTime으로

hourly 데이터를 요청할 때는 utcTime이 자연스러워 보인다. 굳이 타임존을 생각해야할까? 클라이언트가 어떤 시간대인지 굳이 신경쓸 필요 없는 utc를 기준으로 생각하는게 편하지 않을까?

하지만 daily, weekly, monthly 통계 데이터를 넘겨주는 API를 생각해보자. 이때는 utcTime이 매우 부자연스럽다. startTime 기준, "2023-02-27"으로 weekly 데이터를 뽑을 때, 당연히 2023년 2월 27일의 자정부터 24 * 7시간의 데이터를 받기를 기대한다. 여기에서 "자정"은 utc로 생각하면 tz에 따라 계속 달라지게 되는데 이것이 부자연스럽다고 느끼면 꼭 localTime으로 구현하자.

여기서 front-end 개발자라면 한 번 더 생각해볼 부분은, localTime이 현재 브라우저의 로컬타임으로 잡을지, 아니면 조회하고 있는 서비스의 로컬타임으로 잡을지이다. 미국 서부에서 접속한 클라이언트(브라우저)가 미국 동부에 위치한 서비스의 통계 데이터를 원하는 경우, localTime으로의 now()를 미국 서부 시간을 기준으로 맞출지, 동부 시간을 기준으로 맞출지를 고민해보자.

5. 건강한 몸매를 유지하기 vs. 스타트업 운영하기

살찐 사람이 있다. 건강한 몸매를 원한다. 이때 이 사람에게 필요한 능력은 크게 두 가지다. 살을 빼는 능력, 그리고 뺀 살을 유지하는 능력. 이것을 스타트업 경영자에게도 똑같이 적용할 수 있을까? 투자를 받아오는 능력, 그리고 그 돈으로 회사를 경영(생존)하는 능력.