항해99 프로그램은 프론트와 백엔드 개발지망자를 나누어 학습시키고, 이들 사이에 협업하는 커리큘럼을 포함하고 있다. 지난 주, 수 주간 각자 사이드에 훈련받은 뒤, 그룹별로 사이드간 팀을 이루게 되었다. 우리 팀은 nodejs로, 상대 프론트엔드 사이드는 React를 공부하신 팀이었다. 기존의 서버사이드 내 커뮤니케이션과 달리, 첫 협업은 매우 신선했다.
대망의 첫 미팅날, 1주일 내로 개발할 수 있는 스코프의 작은 프로젝트의 기획을 시작하게 되었다. API 명세서를 짜고 변수 이름이나 모듈을 통일한 다음에, 프론트사이드에서 제안한 협업 주제는 놀랍게도 홈페이지의 대표색상을 정하는게 좋겠다는 것이었다. 아직 협업 프로젝트에 디자이너가 붙지 않기 때문에, 프론트단에서 이것을 결정해야 할 필요가 있었는데, 이것을 서버사이드도 같이 정했으면 좋겠다는 말씀이셨다.
와우.. 나는 여태껏 ORM 다루고 Validation을 정의하다가 색상을 정하는 문제를 공유하게 되었다. 물론 실제로 이런 문제를 서버사이드에서 고민할 일은 앞으로 거의 없지 않을까 싶다(풀스택 개발자가 되는 날이 온다면 모르겠지만). 그럼에도 나는 이 질문이 백엔드 개발자에게 작게나마 가치있을 수 있다고 생각했는데, 그들이 사용하는 언어나 맥락을 이해하는 것이 이들과의 커뮤니케이션을 더 낫게 만들어 줄 수 있다고 믿기 때문일 것 같다. 설사 그것이 양질의 서버 기능을 구성하는 것과 관련이 없더라도, 이들이 고민하는 것을 같이 고민해보는 것은 나를 아주 즐겁게 만들었다.
우리가 만들 프로젝트는 환경보호를 위한 동참을 유도하기 위해 (1) 유저가 일종의 퀘스트(환경보호 목적을 위한 챌린지)를 만들고, (2) 퀘스트에 동감하는 한정된 수의 유저들이 이 퀘스트 포스팅에 참여하여, (3) 포스팅 후 공유하도록 하는 것이었다. 지속적인 행동 강화를 위해 퀘스트 보상으로 챌린지를 처음 시작한 유저가 일종의 Score를 거는 시스템, 강화 체계(단발성 보상을 줄지, 지속적으로 수행했을 때 가중치를 줄 지)를 어떻게 챌린지에 따라 어떻게 정할지 등을 첫 날 정의하였다. 너무 큰 스코프는 결국 죽도 밥도 안된다는걸 알고 있으면서도, 기획 자체가 주는 재미는 서로 다른 view를 가지고 있는 두 팀이 만나면서 폭발했던 것 같다 :). 1주일 동안 모두 구현하는 것은 결국 실패했고, HTTPS로 배포된 프론트와 HTTP로 구현된 Express 서버간 쿠키를 주고받지 못하는 문제(CORS 모듈을 사용할 때 withCredential option이 제 기능을 수행하지 못하는 것 같다)가 발생했고, 결국 JWT 방식으로 구현된 로그인/로그아웃 서비스를 어떻게든 살리기 위해 서버를 HTTPS로 바꾸어 배포하려다 타임아웃이 되버렸다. 원래 목표로 잡았던 기능을 제공하기 위해 만들어두었던 정상적인 API들이, 배포 단계에서 실제로 사용도 못해보고 사장되버렸다. 이미 구현했던 것들이 아쉬운건 아니었다. 알고 있으면 언제든 또 만들 수 있다. 그러나 만들고 싶었지만 만들지 못했던 것, 반드시 필요하지만 필요한지 알지도 못했던 것들(배포 단계에서 생길 수 있는 문제들 등)에 대해 팀원들 간 고민하고 공유하지 못했던 것이 날 짜증나게 만들었다. 무능한 나.. 흑흑 ㅜㅜ 다만 이제 할일은 이번에 필요성을 체험한 것들과 실패를 잘 기록하고 다음엔 같은 실수를 안하도록 하는 것이다.
기록 첫 번째, 기획을 하루만에 끝내고 남은 6일간 수정하는 것 보다 3일동안 기획하고 끝내는게 낫다. 우리 조는 첫 날, 수 시간만에 기획 단계를 끝내고 바로 코딩에 들어갔지만, 처음 API 명세서를 작성할 때와 프로젝트가 끝나고 나서 API 명세서는 내용물이 상당히 차이가 났다. 중간중간 변수 이름이 바뀌거나, 서버에서 response로 돌려주는 값이 달라지거나 추가되기도 했다. 이러다보니 프론트와 서버 사이에 자잘한 질문-응답이 여러 번 추가되었고, 담당 개발자가 자리에 없으면 진행이 딜레이되는 경험을 하기도 했다. 기획 단계에서 요구되는 것에, 조금 더 시간이 들더라도 완벽에 가깝게 만들었다면, 불필요한 단계였을 것이다.
두 번째, 기획은 크게 잡더라도, 개발 단계에서의 스코프는 아주 작아야 한다. 기능 가능한 최소 단위만 구현한 뒤, 배포하고 서버-클라이언트 사이의 연결이 의도한 대로 이루어지는지 파악할 필요가 있다. 최소 단위의 기능이 제대로 구현된다는 확신이 있다면, 그 뒤에 하나하나 새로운 기능을 쌓아가는 것이 새로운 에러를 찾기 용이하다. 지난 주에는 넉넉히 이틀만에 필요한 API 대부분을 구현했는데, 상기했듯 제대로 쓰지도 못하고 사장되었다. 이런 실수는 다시 없어야한다.
세 번째, 잘하는 한 사람만 모두 떠안는 건 바보같은 일이다. 만약 내가 팀에서 약간이나마 더 나은 점이 있다면, 즉시 그리고 정확한 내용을 공유해야 한다. 팀이 성장하면 업무가 분담될 수 있고, 믿을 수 있는 팀원들이 받쳐주면 도전적인 사람은 비로소 도전적인 작업에 몰두할 시간이 생긴다. 팀을 키우는 것은 그 소속원 개인을 키우는 것과 크게 다르지 않을 것이다. 문제는 어떻게 팀을 의도한 수준까지 키울 수 있는가 일것이다. 여러 알지 못하는 방식이 존재하겠지만, 우선 팀원 개인과 친해질 필요가 있다고 믿는다. 팀원이 무엇이 관심이 있는지, 무엇을 싫어하는지, 무엇은 잘하고 못하는지 알면 어떤 역할을 분배할 수 있을지도 알 수 있을 것이다. 최근 그 사람을 사로잡고 있는 일이 있다면(여친하고 헤어진 나처럼.. 흑흑), 비록 사소하더라도 그 일에 집중할 수 있도록 배려해줘야 한다. 그 사람만 할 수 있는 일이라면 내가 배워야 한다. 이런 상호작용 속에서 공통의 목표를 공유할 수 있다면 성공일 것이다.
네 번째, 뭐든 즐겁게 하자. 즐거우면 길게갈 수 있고, 길게 가려면 여유도 필요할 것이다. 1일 13시간, 1주일 내내 하나만 붙잡고 있으면 아무리 그것이 재밌어도 지칠 수 있다. 아무리 바빠도 내 삶, 여유, 내 주변 사람들에게 관심을 끊어선 안될 것이다. 나중엔 그게 너무너무 아플 수 있다... ㅜ
오늘은 잠실 석천호수에서 산책도 하고, 겸사겸사 근처 카페에서 Next.js를 공부하고 있다. 오늘도 거의 끝나간다. 부디 훗날 돌이켜 봤을 때 오늘을 후회하지 않기를 빌며...
