이젠 일주일 동안 뭘 했는지를 팀 블로그의 회의록을 통해 돌아보고 있다. 일과 후에는 팀 활동을 하지 않는데도 불구하고 참 시간 잡아 공부하는 게 어렵게 느껴진다. 이번 주는 특히 월-화 해커톤, 수목금 프로젝트에 시간을 다 써서 남아있는 기록이 없는 게 참 아쉽다. 기억을 더듬어서 글을 쓰지만 글이 어렵다면 사진으로라도 남기자! 쑤쑤가 저번 주에 찍은 우리 조 사진을 벽에다 붙여줬는데, 밋밋한 벽이 사진으로 채워지는 게 참 보기 좋았다. 남는 게 있어야 다시 돌아봤을 때 기억이 선명하게 날 테니까. 그게 매주 글을 쓰는 이유이기도 하다.

🎈 UCPC 2024 예선

우테코 크루들 중에서 대학교를 졸업하지 않은 크루들을 데리고 UCPC에 나갔다. 망쵸 레디 아루 셋, 폭포 리니 포케 셋 두 팀이 출전하게 됐다. PS 놓은 지 정말 오래돼서(케이가 정말 놓을 수밖에 없다고 했는데 이해가 되었다…) 감을 잡기도 어려울 것 같았는데, 실제로 문제를 마주하니 어지러웠다ㅋㅋㅋ

예선은 주말에 열렸기에, 주말에 두 번째로 잠실에 출현(?)했다. 3시간동안 여러 문제를 보면서 막막..한 기분을 오래간만에 느꼈다 ㅋㅋㅋ 몇몇 문제는 정말 풀 수 있을 것이라고 생각했는데 (나중에 티어를 보니 골드이기도 했고), 문제를 접근하는 방법에 있어서 꽤나 어려움을 겪었다. 이제 다시 시작해야하나 싶다 🐍

머리 쓰느라 대회 끝나니 배가 너무 고팠다. 5시였는데 바로 밥 먹으러 갔고, 6명이서 낙곱새를 맛있게 먹었다. 식당이 높은 층에 있었는데, 에스컬레이터 안 타고 엘리베이터 타려고 했다가 한참 걸린 건 비밀…

알고리즘 문제해결은 내가 정말 애정하는 분야라, 이번 년도 동아리도 그렇고 잘 진행되었으면 하는 마음이 크다. 비단 코딩 테스트를 위한 일회성 공부로 끝나는 것이 너무나 아까워서.. 꾸준히 다른 사람이나 크루들에게라도 이야기하면서 다져나가는 중이다. 이제는 본질보다는 활용이나 아이디어 도출에 힘을 써야겠다 !

👩‍💻 제1회 우테코 해커톤

6기에는 처음 시행되는 게 많다. 이런저런 커리큘럼은 물론이고 코치도 크루도 다양한 시도를 하고 있다. 그 과정에서 서로 피드백도 활발하게(?) 주고받으면서 잘 성장하고 있겠지? 이번 해커톤도 마찬가지였다. 기존에는 안전상의 이유로 심야에 캠퍼스를 열지 않았는데, 딱 하루 동안 캠퍼스를 열고 24시간 무박 해커톤을 진행했다.

여느 해커톤처럼 주제가 주어졌지만, 이번 프로젝트의 기능 하나를 잡아 구현하는 것이 목표였다. 쉬운 일은 아니고 배포까지 진행해야 했기에, 우리 팀에서는 난항이 예상됐다. 나도 그렇고 다른 팀원들도 잠에 민감한 크루들이 있어서 밤을 새우며 개발하는 것은 하지 않기로 했다.

우리 팀의 핵심 기능인 ‘리뷰 작성/제출/상세 보기’를 하나로 묶어 구현하기로 했다. 24시간도 안 되는 시간이라 머리가 빠질 것만 같았고, 마감 기한이 다가올수록 모두 급급해져가는 것이 느껴졌다. 결국 프론트와 백이 함께 연동하는 것에도 실패해 어떻게 보면 우테코에서 내어 준 목표에는 달성하지 못했다.

🎞 빠지지 않는 회고

해커톤에서 느낀 게 많았던 터라 회고도 길게길게 진행했다. 어떤 점이 아쉬웠고, 어떤 점이 좋았고, 무엇을 얻어가야 했을지를 적어나갔다. 포비가 이야기한 ‘프론트와 백의 진-한 협업’을 이루지 못한 아쉬움이 첫째였다. 각자의 기능을 구현하는 데 바빠 API를 서로 맞추는 데에 시간을 쓰지 못했고, ‘알아서 해~’의 느낌이 강해 아쉬움이 컸다.

회고를 진행하면서 느꼈던 감정이나 느낌을 모두 털어놓는 게 제일 중요하다고 느꼈다. 더불어서 이런 환경을 제공해주거나, 크루들이 함께해준다는 점이 크게 다가왔다. 이런 문화가 퍼지면 정말 좋겠다 싶으면서도, 실제 현업이나 학교 동아리에서 이런 일을 이끄는 것으로 충분할까? 싶기도 하다.

해커톤에서의 경험이 나쁘지는 않았다. 기능 구현에 집중하면서 마감 기한에 쫓기는 경험도 하고, 포비가 야단한 대로 ‘프론트와 백의 연동’도 이루어지지 않아 분하기도 했다. ‘다음 해커톤 때에는 두고보자’와 비슷한 느낌이 들기도 했는데, 그래서 회고를 진행할 때 아래와 같이 작성했다.

해커톤 때 했던 것처럼, 기능 하나를 잡아두고 2-3일 안에 관통하는 기능을 구현하는 방식이 좋다고 생각한다. 포비가 이야기했던 ‘진한 협업’을 위해 이런 방식이 꽤 도움되는 것 같다. 실제로 우리 팀에서도 프-백이 따로 구현했었으니, 기능을 둘이 협업해 짧은 주기로 가져가면 좋지 않을까? 해커톤을 2-3일로 늘여놓은 것처럼 하나의 스프린트를 여러 개의 기능으로 나눠 구현하면 좋겠다.

이번 주에는 해커톤 때 구현한 것에 대한 예외 처리 및 도메인 로직 구현, 프론트-백 연동, 가능하다면 EC2 배포까지를 목표로 해보고 싶다. 코드는 고칠 수 있다. 최선의 코드는 한 번에 나오지 않는다. 지금 배포되고 있는 이전 기수의 레포들은 우리가 겪은 걸 한 번은 겪었다. 왜 주저하는가? 커밋 한 번이면 코드가 바뀌는데 과한 책임감을 가질 필요는 없다.

회고 일부

이런저런 이야기를 나누고 2주의 스프린트를 쪼개자는 나의 제안이 받아들여졌다. 서로의 협업이 중요하다는 것은 공감하면서, 2주라는 시간동안 자주 만나기 위한 하나의 약속인 셈이다. 작은 단위를 하나의 해커톤처럼 보고 기능 구현을 하나씩 진행하기로 했다. 잘 되려나? 해 보아야 알겠다 😁

🥔 연관관계 어려워요

처음에 백엔드에서 먼저 한 것은 ERD 문서 작성이다. 지금 돌아보면 꽤나 잘못된(?) 방향이지 않을까라는 생각도 들었다. 도메인을 충분히 분석한 다음에, 역할에 따라 이를 순수한 자바로 표현하고, 여기에 JPA를 입히는 방향으로 가야 한다고 생각했다. 반대로 DB 구조를 먼저 짜고, 역할을 강제로 부여한다면 어색한 코드가 될 것이 뻔했다. 실제로 우리 코드에서 역할을 올바르게 가지고있다는 느낌을 크게 못 받았다.

JPA에서는, 혹은 여타 객체 구조를 짤 때에도 그렇고 양방향 연관관계를 피하라고 한다. 가령 ‘리뷰어 그룹’을 만들어 그룹의 크기와 같은 것을 검증하려고 한다면, 리뷰어 그룹에 회원 리스트를 가지게 하는 식으로 구현할 것이다. 그리고 생성할 때에 검증하고. 얼마나 단순하고 직관적인가? 일대다 연관관계고 다(N)쪽에 외래 키를 부여하니 서비스에 그 책임이 고스란히 전달됐다. 서비스 메서드의 길이가 30줄에 육박했고 모든 검증이 서비스에서 이루어졌다.

정말 이러한 방식의 @OneToMany를 무조건적으로 피하는 것은 좋은 방법이 아니라고 생각했고, 우리는 JPA의 도움을 받으려는 것이지 JPA에게 휘둘리려는 것이 아니었다. 팀원들끼리는 다시 연관관계를 생각해보자는 이야기로 의견이 모아졌다.

테코톡을 진행하게 된 것도 이와 같은 맥락이었다. 너무 높은 계층에서 자세하게 알고 있으니, 중간 계층에 해당하는 객체를 도출해 역할을 부여하는 것. 보다 객체지향적으로 설계하고 이를 이루는 것을 목표로 해야한다고 생각했다. 다음 주에는 해커톤 진행한 것을 꾸준히 리팩터링하면서, 기능을 덧붙여 나가자~! 우리 팀 아자아자 화이팅 😎

🙄 이번 주는요

바쁘다 바빠. 다음 주부터는 (글을 쓰고 있는 시점에는 이미 왔지만) 더 심해진다. 2차 스프린트 데모데이도 있고, 우리 팀에서 정한 스프린트도 있고 하다. 이런저런 걸 많이 해보는 것도 중요하지만, 목표 내에 기능을 구현하는 것을 우선으로 열심히 달려야겠다. 밤에 남는 시간이 잦은데, 자투리 시간을 어떻게 활용했는지를 기록해두는것도 좋겠다. 한 발짝씩 나가보자 👏