드디어 GDG 코리아에서 주최한 defFest의 WTM해커톤이 끝났다. 길고도 짧은 여정이 끝난 오늘(실제 블로그에 배포할 시간은 하루가 지나겠지만) 그 짧은 후기를 남겨본다.
온라인 + 여성 개발자만 참여할 수 있는 해커톤이라 신청했다. 신청할 당시엔 온라인 해커톤이 내 상황에 딱 맞다고 생각했다. 첫 해커톤이라 부담이 덜 갈 수 있다고 판단했고, 일정도 2주나 주니까 일에 지장가지 않을 수 있다고 생각이 들었다. 체력적으로도 1박 2일 꼬박 밤을 새서 만드는 게 아니라(내가 아는 해커톤의 개념이 맞다면) 편할 것 같기도 했다.
이번 WTM해커톤에서 제시한 주제는 다양했는데, 코로나블루를 이기는 방법/환경/공공api/금융 등등..
크게 다섯가지 주제를 줬던 기억이 난다.
물론 제시한 주제가 다 싫으면 자율적으로 원하는 주제를 선택해도 되었다.
우리 팀의 주제는 개발자만을 위한 스터디/프로젝트 찾는 커뮤니티였다.
이 주제를 선택한 이유에 이번 해커톤 초반부의 경험이 컸다. 짧게나마 이번 해커톤에서 느꼈던 ‘팀원 구하기’의 어려움이 컸어서 그런지, 우리 팀 4명 모두 이 주제로 해커톤을 하자고 빠르게 결론을 내었다.
처음엔 자기소개 하고 바로 팀이 만들어져서 좋았는데, 프론트엔드 한 분이 빠지겠다고 하셔서 다른 한 분을 찾기가 굉장히 어려웠다. 이러다가 나 백엔드랑 프론트엔드 둘 다 해야하는 거 아니야? 하며 엄청 고민을 많이 했었다. 백엔드로만 해보고 싶었는데, 프론트랑 같이하면 하나에 제대로 집중할 수 없어져서 결과물이 원하는 만큼 나오지 않을 것 같은 예감이 들었기 때문이다. 다행히 해커톤 시작 전날이었나.. (2주 전인데 왜 기억이 안날까 ㅋㅋ) 프론트엔드 할 팀원을 구했다.
언제나 그렇듯, 대학교 조별과제를 할 때도 그랬고 이번 해커톤도 그렇고 팀 짤 때 타이밍이 중요한 것 같았다.
처음에 이 조에 들어간 것도 먼저 같이 하자는 제의를 받아서 들어갔는데,
대학 수업시간에 교수님이 니들이 알아서 팀 짜~ 하시면 인싸 동기한테 빌붙었던 추억아닌 추억(…)이 생각나 웃음이 났었다.
3D의 유래?누구한테 들었는지 기억은 안나는데 “개발자가 3D 직업중 하나라고요”라는 말은 아직도 기억에 남는다. 팀명을 정하는 시간에 장난스레 이 얘기를 꺼냈었는데 다른 분들의 만장일치로(!!) 팀명을 3D로 했다. 깃헙 계정이나 구글 계정도 3ddd가 들어간다 ㅋㅋㅋ 은근 아이디가 귀여움.
이번 해커톤에서 얻고싶은 최소한의 목표는 ‘경험’이었다. 아니 회사도 다니면서 무슨 경험 타령이야? 할 수도 있다. 나는 이런 모임에 참여하는게 처음이었고 개발자들끼리 사이드 프로젝트를 하면 어떻게 일하는지, 다른 사람들은 어떻게 일하는지 그걸 관찰하고 내 것으로 만들고 싶었기 때문에 진부하지만 추상적인 말인 ‘경험’이라는 말로밖에 표현할 길이 없다.
처음에 팀원들과 각자 생각하는 ‘이번 해커톤에서 얻고자 하는 목표’를 공유할 때, 프로젝트를 다 완성하지 못해도, 참여에 의의가 있어요~ 했는데 역시나 나란 사람의 성격은….🤥 완벽하게 만들려는 마음이 자라기 시작했다. 한번 개발하기 시작하면 내 새끼(ㅋㅋ) 같은 마음이 커서 그런지, 애착이 커져서 좀 더 완벽하게, 더 많은 기능을 만들고 싶다!! 하며 전날까지 수정하고 추가했었다.
메인 주제가 스터디/프로젝트 구하기라서 한 주제당 백엔드1+프론트엔드1로 짝을 정하고 개발을 했다.
나는 스터디와 회원가입관련 부분을 맡았고, 백엔드라서 일단 기본적인 DB구조나 API 설계, 문서제작을 했다.
오늘 하루 목표 분량을 다 완성하면 노션링크를 공유했다.
같이 일한 프론트엔드 분에게서 많은 걸 배웠는데, 이런게 애자일한 방식이구나~ 싶은 순간이 많았다. 내가 작성한 문서를 보고 피드백을 바로 주셔서 설계하기가 한결 편했었다. 오류가 나면 여기 오류가 나요! 해주시고, 뭔가 흐름이 이상하거나 헷갈리면 해결 될 때까지 슬랙으로 의견을 나누었다. 처음 기획부터 자유롭게 짤 수 있는 상황이라 수평적으로 의사소통을 할 수 있었다. 회사가 아니라 개인적으로 하는 사이드 프로젝트라 그런지 심적 부담도 덜했다 :)
정말 신기했던게, 프론트엔드만 하시는 분이라 그런걸까 구현 속도가 정말 빠르셨다.
나는 회사에서 한 화면만 구현하는데 최소 4일은 걸리는데😨
(호불호가 확실한 취향이라서 프론트 업무를 할 때마다 스트레스 지수가 확 올라가고 효율성이 떨어진다)
팀원분들도 다 좋으신 분들이라서 둥글게 얘기해주시고 문제가 생기면 내 일인양 같이 해결해 나가서 이런 태도를 배워야겠다 싶었다. 또, 판단력이 빠르신 분들이 계셔서 이런 부분은 꼭 노력을 해서라도 가져야 할 프로그래머의 자질인가보다, 느꼈다.
사실 초반에는 스터디/프로젝트를 나눠서 구현하고, 시간이 남으면 회원가입관련/마이페이지도 나눠서 구현하기로 했는데
어쩌다 보니 회원가입 관련 부분과, 마이페이지 중 스터디 관련 파트를 추가로 맡게 되었다. 껄껄껄.
수정사항이 오면 하나만 고치면 되던게 두개, 세개를 같이 고쳐야 해서
아…또 설계 거지같이 했네, 나💢💢 하고 나를 욕했다.
다행히 문제가 생기면 개발자들끼리라 그런지 일의 우선순위를 합의하기가 쉬웠다.
빠르게 피드백을 주고받을 수 있다는 게 아니었으면 이 정도로 구현할 수 있을까? 싶더라. 온라인의 장점👍
문제는 온라인이다 보니까 각자 이해하는 포인트가 달라서 합의점을 찾는 데 걸리는 시간이 조금 더 걸린다는 점이다. 예를 들어 ‘지원자의 지원글 보기 / 지원자의 모집글 보기’ 가 다른 뜻인데 은근 헷갈려서 서로 뜻을 전달하는데 어려웠다. 비슷한 단어를 각자 지칭하는 말이 달라서… 회사에서도 겪는 일이라 그런지 그냥 음~ 그럴수있지~ 하고 넘어갔었다. 오프라인에서 했어도 달랐을까? 아닐걸. 오프라인은 글이 남지않아서 더 오해가 생겼을 수도 있겠는데 싶더라.
언제나 그렇듯 첫 삽, 즉 처음 설계할 때가 가장 힘들다. 잘못 설계하면 다시 뒤집어 엎고 만드는게 나을테니까…!
그리고 그런 사고를 제가 쳤습니다.
동적 쿼리(검색)을 구현할 때 많은 시간이 투여되었는데, db 접근 방식을 jdbc-template으로 사용하자고 한 내 탓이 가장 크다.
최소한 mybatis2로만 가자고 했어도 이렇게 개고생하지 않았을 텐데.
회사에선 jpa_queryDSL만 쓰다보니 mybatis / jdbc template의 구현속도 차이를 잊고 있었다.(변명…😭) 같이 백엔드를 맡은 분께도 엄청난 똥투척을 한거였고, 중간에 mybatis로 바꾸자고 할까도 싶었는데 또 일을 크게 만드는 것 같아서 그냥 안고 가버렸다. 개인적인 일이 끝날 12월말 쯤, jpa로 바꿔서 구현해 봐야겠다. jpa설정하는게 매우 까다로운 걸로 알고있는데, 어떻게 할지 ㅎㅎㅎ 뭐 어떻게든 되겠지! 구글신이 날 도와줄 거야😇
거의 10팀이 발표를 하셨는데, 다들 아이디어가 톡톡 튀고, 실제로 서비스를 내놓는다면 ‘나부터 찾아서 쓰겠다!’ 라는 마음이 들 정도였다. 디자인적으로도 이쁘게 구현한 팀도 있었는데 이 짧은 기간동안 저런 걸 어떻게 생각해내지? 싶더라. 이번 프로젝트서 개인적으로 목표로 한 기능+@에, 기초적인 예외처리 기능들을 구현했는데, 우리팀 발표가 끝나고 진행자분께서 실서비스에서 내놓은 것처럼 예외처리가 잘 되어 있다고 하셔서 내심 뿌듯했다. 노력한 걸 잘 봐주신 것 같아서ㅎㅎ
아쉬운건 aws로 배포를 하지 않고 로컬로 시연했다는 점. 디비 구성에 많은 힘을 안들이려고 h2를 썼던 탓도 크고, aws 배포 세팅에 시간을 들일 시간에 더 많은 기능을 구현하고 싶어서 한 선택인데, 나름 아쉽긴 하다. gradle을 처음으로 실사용했는데 제 기능을 알지도 못하고 사용해서 아쉽다. 이동욱님의 스프링부트 책을 초반만 봐서 gradle설정까지는 어찌어찌 하겠는데, 그레이들 설정은 maven 보다 좀 더 세분화되었달까.. 알고 쓰면 좋을텐데, 급하게 필요한 부분만 서칭해서 붙여넣기를 했다. 스프링 시큐리티를 못 쓴 점. 이 기능을 넣었으면 좀 더 탄탄하게 만들었을 텐데… 아직 뽀시래기라 그런지 스프링시큐리티 구현은 어려웠다. 빨리 공부를 해야할 텐데, 할 건 참 많다 :(
해커톤에서 구현한 3D 백엔드부분 깃허브 :
바로가기