글 목록으로 이동

봄가을 블로그

회고2023년 06월 04일--views

사내 IT 프로젝트 공모전 후기

자리배정시스템 3주 만에 만들어보기. 기술과 전략과 느낀 점들. 힘들었지만 보람찼다. 모두들 고생하셨습니다.

지금 회사에 다닌지 여엇 2년이 다 되어가는 중입니다. 시간이 정말 빠릅니다. 회사 이야기도 이것저것 많이 하고 싶지만 일단 지금 생각나는 것부터 적으렵니다. 가장 최근에 사내 공모전이 있었습니다. 꽤 고생했습니다. 3주 정도 동안 피똥쌌습니다. 다행히 결과는 좋았습니다. 그 후기를 적겠습니다.

사내 공모전은 저희 회사에서는 종종 합니다. 회사의 매출은 대부분 SI로 이루어져 있지만, 자체 먹거리를 만들어가야 하기 때문에 자체 프로젝트에 투입되는 자원이 좀 있습니다. 인력도 그렇고, 돈도 그렇구요. 본래는 신규사업 "아이디어" 공모전을 종종 했었는데, 개발자가 대부분인 조직에서 설득력있는 사업 아이템을 만들어내는 건 아주 어려워서, 의미는 크게 없었던 것 같습니다. 이번 공모전은 "어떠한 문제를 해결해주는 제품"을 실제로 만든다는 점에서 기존과 달랐습니다. 눈에 좀 더 확실하게 보이는 걸 만든달까요.

공모전의 주제는 "자리배정시스템"을 만드는 것이었습니다. 그 배경에 외부적인 요인이 있던 건 전혀 아닙니다. 그 시스템은 그냥 우리에게 필요했습니다.

최근에 사무실 이사를 가면서, 재택근무가 제도화 되었습니다. 매일 출근해야 하는 몇 사람을 제외하고, 대부분의 인원은 일주일에 두 번 정도 재택근무를 하게 됩니다. 만약 대면근무일이 잘 분배된다면, 사무실 전체 자리가 회사 총원보다 적더라도, 자리는 부족해지지 않습니다. 잘 분배되어야 하는 게 문제지요. 잘 분배하기 위해서 자리배정시스템을 만들어야 하는 것이구요.

문제는 명확합니다. 만약 어떤 날짜에 사람들의 대면근무가 몰리게 된다면 일부 사람들은 자리가 부족해 앉을 수 없습니다. 그러한 참사를 막는 것이 목적입니다.

멋진 사무실 모습
사무실의 자리가 충분하던 시대는 끝났다...!

공모전 진행

공모전 진행은 다소 삐걱댔습니다. 회사 차원에서 진행되며, 회사의 임원진들이 운영하는 거긴 하지만, 명확한 역할이 나뉘어져서 스무스하게 운영되는 게 아니었습니다. 조금 아쉬운 부분들을 나열해보자면,

  • 최초 공지 ~ 실제 제출까지 3주라는 아주 긴 시간이 생겼습니다. 정식 공지 전에 찌라시가 돌아다닐 때에는 해커톤 수준으로 예상했는데(하루나 이틀 동안 밤을 새는… ), 3주라니… 상금이 걸려있는 만큼 다른 팀들도 열심히 할 텐데, 엄청난 경쟁 구도가 생겨버렸습니다.
  • 공지가 있고 며칠 뒤에 인사팀으로부터 기획안이 다시 공지되었습니다. 앞서 언급한 "누군가 자리에 앉지 못하는 사태를 방지"하는 큰 방향성 외에, 세부적인 기능이 설정되었죠. 조금 저항심이 생겼습니다. 하고 싶은 걸 하는 게 더 맞지 않나 하는 생각이 들었어요.
  • 회사 사람들이 사용할 수 있는 서비스인 만큼, 데이터나 방법이 좀 제공되어야 했는데, 뭐, 예를 들어 사람들의 간단한 정보(이메일, 이름)라든지 로그인할 수 있는 수단(OAuth2.0 등등…)이 있었으면 좋았을 텐데, 이 부분이 조금 부실했습니다.
  • 3주라는 긴 기간 때문에 생기는 또 다른 문제점이기도 한데요, 이번에 총 5팀이 참여를 했는데, 입상하지 못한 팀은 그 3주 동안 고생한 걸 다 날려야 하는 판이었습니다. 너무 리스크가 크댜…

이런 부분들은 임원진이 공모전을 기획했을 때 미처 생각하지 못한 상황들이라고 생각합니다. 전체적으로 나쁘지는 않았습니다.

새로운 사람들, 힘들고 피곤한 나날들, 어려운 기획.

저는 뭔가 잘 해보고 싶어서, 찌라시를 열심히 듣고 물밑에서 멤버들을 미리 포섭했는데요, 좋은 전략이었습니다. 프론트엔드 5명, 디자이너 1명으로 이루어진, 비주얼을 극강으로 살릴 수 있는 조합이었습니다. 다른 팀들에 프론트가 부족해진 건 안비밀~

전략을 세우는 것도 중요했지만, 그냥 같이 하는 사람들 자체도 좋아서 결과까지 좋을 수 있던 것 같습니다.

같이 지내본 적이 없는 사람들, 그리고 앞으로도 함께할 일이 크게 없는 사람들이라서, 이번 기회에 같이 프로젝트를 진행했던 게 재밌고 새롭고 좋았습니다. 이번 공모전을 하면서 재미를 찾는다면, 제품을 완성시켜나가는 뿌듯함도 좋지만, 낯설지만 생각이 맞는 새로운 사람과의 티키타카가 정말 좋았어요. 그냥 더 친해질 수 있어서 좋은 거 같기도 하구요. 마지막 발표일(금요일)에 우연히 시간이 다 되서 그날 바로 뒤풀이를 하러 갔는데, 그 때 마시는 술 맛이 참 꿀맛이었더랍니다.

우리 팀원들
우리 팀원들. 정말 다들 고생 많으셨습니다 ㅠㅠ

그나저나 프로젝트가 진행될 때에는 정말 힘들긴 했습니다. 새벽 3~4시까지 코딩 몇 번 하니 정신이 좀 혼미해졌어요. 무슨 군대 훈련 나갔던 때가 떠올랐어요. 너무 힘들어서… 흑흑… 수면부족에 허덕이고 정신 나간 사람처럼 히히 웃었습니다. 본래 운동도 일주일에 세 번 꼬박꼬박 갔었는데, 프로젝트 진행할 때에는 거의 가지 못했습니다.

우리는 개발에 앞서 기획적인 부분, UX/UI 부분을 신경 썼습니다. 사용자를 먼저 좀 생각해봤습니다.

  • 사람들의 불만이 없게 시스템을 잘 돌려야 하는 인사쪽 사람들.
  • 근태를 관리하거나, 회의 날짜를 잡거나 (기왕이면 모여서 얼굴보며 회의하는 게 좋으니까…) 등등 다른 팀원들의 대면근무를 관리해야 하는 사람들.
  • 자신의 계획된 대면근무일에 그냥 째깍째깍 사무실에 잘 오기만 하면 되는 사람들.
  • 본래 재택근무였는데, 갑자기 대면근무를 해야 하는데, 사무실 자리가 꽉차있을까봐 걱정하는 사람들.
  • 기타 등등…

아니, 왜 이렇게 이해관계자들이 많은지 모르겠습니다. 흐흐… 그래서 기획하는 데 한 세월이었습니다. 이 모든 사람들을 만족시켜야 하는 서비스라니. 정말 어려운걸?

그리고 또 일을 키웠습니다. 메인 문제점 외에도 다른 문제점을 더 도출했습니다.

  • 이미 누군가 앉은 공유석인지 알기 힘듬 / 남은 공유석을 찾기 위해 온 사무실을 돌아다녀야 함
  • 어떤 사람과 할 이야기가 있는데, 그 사람이 어디에 앉아있는지 몰라 찾아다녀야 함.

위 문제점들을 추가 설정하여 "체크인시스템"과 "대면근무관리시스템" 두 가지 큰 방향을 나누었습니다.

어차피 백엔드가 없으니 백/프론트로 인원을 나누는 건 무의미했고, 화면별로 나눴습니다. "굳이 무슨 브랜치야" 하면서 모든 작업은 메인에서 이루어졌습니다. 자주 풀 받고 자주 푸쉬 날리고. 아아, 이것이 바로 그 유명한 Trunk Based Development? 음, 아닌 것 같습니다.

어떻게든 완성시킨다! 라는 마인드, 오랜만에 느껴봤습니다. 옛날에 씨네소파 사이트 만들 때가 떠올르네요… 코드 퀄리티 따위는 개나 줘라~

시도해본 기술

짧은 시간에 대단한 걸 만들어야 합니다. 기술 스택도 익숙한 것 위주로 좀 골랐지만 약간의 새로움을 더했습니다.

Hasura + Neon

Hasura 는 기존에 있는 DB에 GraphQL 식으로 접근할 수 있도록 하는 미들웨어입니다. DB 에 접근하기 위해 쿼리를 칠 필요가 없다는 것이 특징입니다. 중간에서 적당히 최적화도 많이 해주구요. 오픈소스이고 나의 시스템에 설치하는 것은 완전 무료라 좋습니다. 클라우드 서비스도 제공합니다.

Hasura 구조
Hasura 구조

문제는 DB가 별도 있어야 한다는 건데요, 저는 Hasura Cloud 에서 뭔가 DB도 그냥 주는 게 아닐까! 하고 상상의 나래를 펼쳐보았습니다. 근데 들어가서 보니, Neon 이라는 서버리스 Postgres 가 있고, 그걸 이용하더라구요. 결과적으로는 뭐 공짜로 잘 진행했습니다.

Hasura + Neon
Hasura + Neon

참조: https://hasura.io/blog/introducing-a-native-postgres-integration-to-hasura-cloud-in-partnership-with-neon/

Hasura Cloud 공짜의 단점은 api 요청 제한이 빡빡하다는 것입니다. 1분에 60회 밖에 안 돼요… 정말 크지 않습니다.

Next.js App Router + tRPC

본래 Next.js 에 다들 좀 익숙한 상태였는데, 그래서 Next.js App Router 으로 진행해보자! 했건만 정말 힘들었습니다. app router 문서가 pages router를 제치고 기본값으로까지 갔는데, 힘들었어요.

이제는 파일 이름까지 정해진 대로 써야 합니다! (layout.js, page.js 등등…)
이제는 파일 이름까지 정해진 대로 써야 합니다! (layout.js, page.js 등등…)

여러가지 어려움이 있었지만 정리하면 다음과 같습니다.

  • 아직 기술이 성숙하지 않은 느낌이었습니다. 잘못 사용했을 때 에러메시지가 명확하지 않고 갑자기 브라우저가 멈춘다는 등의 비정상적인 동작이 자꾸 발생했습니다. 문제를 해결해나기가 좀 어려워서, 문제의 소지가 최대한 적도록 하는 방어적인 코딩을 할 수 밖에 없었습니다.
  • 다른 라이브러리와 호환이 뭔가뭔가 잘 안 됩니다. 특히 tRPC가 좋다길래 한번 써봤는데, 뭔 뭔가 자꾸 삐걱댐… 그래서 뭔가 기존과 비슷한 느낌으로 client 컴포넌트에서 Provider 제공해주고 useQuery 사용할 수 있는 방향으로 진행했습니다. 이쯤 되니 App Router 를 굳이 쓸 필요가 없다 느껴졌습니다. (async 컴포넌트나 Suspense 는 구경도 못했습니다.)
삐끗 잘못하면 떨어지는, 아슬아슬한 다리 위에 서있는 기분.
삐끗 잘못하면 떨어지는, 아슬아슬한 다리 위에 서있는 기분.

제 생각에 App Router 는 딱 1년 정도 지나면 쓸만한 수준으로 갈 것 같습니다. 최근에 Server Actions 라는 게 새로 등장했고, 이번 프로젝트에서 시험삼아 한번 테스트해봤는데, DX 관점에서는 정말 전 좋았습니다. 빨리 안정화되었으면 좋겠습니다.

tRPC 는 첫 시도하기에 쉬워서 괜찮았습니다. tRPC 에서 사용하는 스키마 유효성 검사 라이브러리인 zod 도 쉬웠습니다. 꽤 괜찮더라구요.

framer-motion

framer-motion 은 애니메이션 라이브러리입니다. 지금까지 나온 애니메이션 관련 라이브러리 중에 제일 맘에 듭니다. 넘 조아~ 비주얼 점수에서 많이 딸 수 있었던 일등 공신이었습니다. 사용하기도 많이 어렵지 않습니다.

기존에 ease 함수를 직접 설정하던 감각에 익숙해서, framer-motion 식으로 애니메이션 조정하는 게 처음엔 좀 와닿지 않았는데, Visualizer 등의 툴을 이용해서 극복했습니다.

가장 좀 기대했던 부분은, 페이지간 전환 애니메이션을 framer-motion 으로 구현할 수 있지 않을까 했는데, 현재(2023년 6월 3일) 기준으로는 구현이 불가능합니다. 이유는 대충 요약하면, Layout 와 Page 사이에는 사실 보이지 않는 컴포넌트가 존재하여, 직속 자식 노드의 애니메이션만 책임지는 AnimatePresence 가 Layout 에서 Page에 영향을 줄 수 없다 내용입니다.

PWA

PWA(Progressive Web App)는 앱스토어를 통하지 않고도, 웹앱을 앱처럼 디바이스에 설치할 수 있는 방법입니다. manifest.json 파일을 적절히 잘 만들면 됩니다. 실제 아이폰으로 띄워봤습니다. 알림은 실제로 활용하지는 않았고 테스트까지는 진행했습니다. 시연할 때 실제로 앱처럼 뜨게 하니 호응이 좋았던 것 같습니다.

PWA 구조
PWA 구조

Figma

Figma는 디자인 툴입니다. 특히 웹/앱 디자인에 특화되어 있고, 컴포넌트 시스템 등등 개발자 친화적인 개념도 많습니다. 피그마의 큰 강점 중 하나는 협업 기능이 좋다는 겁니다. 이번에 하면서 좀 즐겁게 진행했습니다. 댓글을 왕창 달고, 피드백이 왔다갔다 하고, 실시간 채팅도 하고, 카메라 따라가기 기능도 써보고... 피그마는 정말 좋은 툴이에요. 제가 개인적으로 하는 프로젝트도 그냥 Figma 로 끼적되며 시도해보렵니다.

다음에 또 한다면

  • 처음부터 즐길 마음으로 진행하기. 상은 생각도 하지 말기.
  • 기획을 더더욱 최소화. 기능을 빼고 또 빼기.
약 한달간 커밋 480개 후덜덜~
약 한달간 커밋 480개 후덜덜~