제 7회 D2 CAMPUS FEST mini 후기
이번 글에서는 지난 7월 한 달동안 진행한 D2 CAMPUS FEST mini 타임라인 만들기 프로젝트에 대한 회고를 정리할 생각이다. 관련 코드는 여기, 보고서는 여기서 확인 할 수 있다.
이번 대회에서 우수상을 수상했다. 수상을 전혀 기대하지 않았기에 깜짝 놀랐고, 한 달동안의 경험들을 기록으로 남겨야 겠다고 생각해 회고를 작성하게 되었다.
주제 선정
운이 좋게도, 지난 학기 실험때 했던 프로젝트와 같은 주제가 있었다. 마침 실험 때 진행한 프로젝트는 기간에 쫓겨 코드품질이 매우 좋지 않아 방학 때 리팩토링을 진행해야지 생각하고 있던 참이었다. 해서 타임라인 만들기를 선택하게 되었다.
Team Building
공고를 보고, 팀을 꾸려서 나갈지 개인으로 참가할 지 고민했다. 이미 만들어 본 경험이 있는 주제고, 화면 단 코드는 지난 프로젝트 때 코드를 그대로 사용해도 괜찮아 보였다. 다만 혼자서 참가할 경우, 신경이 온전히 한 곳에 집중 될 수 없고 혼자만의 생각에 갇히게 될 우려가 있다 생각했다.
해서 팀을 구하기로 마음 먹었다. 이왕 구하는거 코드 품질을 관리하면서 프론트 전체를 맡을 수 있고, 서버 쪽에도 조언을 줄 수 있는 팀원이면 좋겠다 생각했다. 이러한 인재가 주변에 흔할리가... 있더라도 나의 어떤 점을 믿고 같이 하겠다고 하겠는가? 또한 유능한 인재는 항상 바쁘기 마련이다. 각 자의 여러가지 이유들로 팀 제안은 좋은 대답을 듣지 못했고, 혼자 가야하나 망설이던 찰나에 지난 학기 프로젝트 팀원들이 생각이 났다.
이미 같이 협업을 진행해봤으니 호흡면에서는 문제가 없고, 이전에 했던 프로젝트를 리팩토링 하는 관점에서 참여동기가 충분해 보였다. 다만 한 가지 고민 됬던 점은 대학원생들도 참가하고, 네이버에 주관하는 대회인만큼 단순 기능구현에만 포커스를 두면 안될 거 같은 불안감이었다. 이 때문에 이번에는 내심 앞에서 이끌어 줄 수 있는 팀원을 원하고 있었다. 그러나 역시 혼자서 뚝딱뚝딱 만들어내기에는 나를 너무 과대평가하는 것 같았다. 그렇게 이전 팀원들에게 같이 나가자 제안을 했고 고맙게도 제안을 받아 주었다.
Week 1
누구나 그렇듯 초반에는 다들 의지가 불타오른다. 마치 어릴 때 장래희망란에 거리낌없이 대통령 또는 세계정복이라고 쓰는 것과 같다. 더해서 우리는 이미 같은 주제를 구현해봤다는 자신감에 전의가 가득 차있었고, 우리는 아래 두가지를 목표로 잡았다.
- 교내에서 Spring 및 JPA 만큼은 최고가 되자
- 수상해서 겨울 해커톤 출전
첫 주에는 앞으로 코드를 작성 할 때 어떤 네이밍기법을 적용하고 어떻게 OOP 원칙들을 지켜가며 가독성과 유지보수가 쉬운 코드를 만들지에 대한 고민으로 보냈다. 이전까지 학교에서 진행 했던 프로젝트에서는 볼 수 없었던 관경이었다. 이러한 고민들에 대해 서로 의견을 나누며 팀을 꾸려서 나가기를 참 잘했다는 생각이 들었다. 팀을 꾸리면서 얻는 많은 이점중 하나는 팀원들의 생각뿐만 아니라 서로가 막히던 부분에 대해 각 팀원들의 지인들에게도 의견을 구할 수 있다는 점이다.
Week 2
두 번째 주에는 가장 핵심인 타임라인을 어떻게 구현 할 것인가에 대한 고민을 하며 보냈다. 이 부분에 대해서는 주변에 뛰어난 지인들에게 계속해서 질문하고 의견을 공유했다. 더해서 인터넷에 참고할 만한 자료들을 수집하고 여러 오픈카톡방에서도 조언을 구했다. 처음 생각했던 것 보다 훨씬 어려운 과제임을 깨달았다. 심사기준에 친구 목록이나 친구 소식을 빠르게 가져오는데 유리한 데이터 구조 라는 문구가 있었는데, 이 문구가 사람을 미치게 만들었다.
많은 사람들이 사용하고 엄청난 트래픽을 처리하는 네이버답게, 그들은 대용량 아키텍처에 대한 솔루션을 우리에게 요구하고 있는 듯한 느낌이었다. 단순한 기능일지라도 대용량 서비스라는 접두어가 붙으면 개발자는 긴장해야 한다. 언제 어디서 문제가 발생할지 모르고, 발생하는 문제에 따른 손실이 압도적으로 증가한다. 이 전에는 한번도 이런 고민을 해본 적이 없던 나는 막막하고 지레 겁을 먹었다.
다행히도 인터넷에는 참고할만 자료들이 꽤나 있었다.(그 중 D2의 게시된 내용들이 많은 도움이 됬다.) 그러나 문제는 이 내용들을 소화하기에는 내가 너무 부족했다. 때문에 같은 내용의 글들을 이해가 될 때까지 계속 읽어보았다. 수상하지 않더라도 이러한 고민을 하는 것에서 부터 이번 프로젝트를 통해 많이 성장하는 느낌이었다.
Week 3
세 번째 주에는 개발에 집중하고, Test Code를 작성하는데 조금 더 신경쓰기 시작했다. 특히 나는 로그인 구현에서 Spring Security 와 JWT를 처음 도입 해보았다.
여기서 굉장히 많은 시행착오가 있었다. 항상 그렇듯 오류를 해결하고 나서야 무엇이 잘못 되었는지 깨닫는다. 이번에는 그 과정이 생각보다 많이 복잡하고 어렵게 느껴져 별도의 Repository를 만들어 만났던 시행착오들을 정리하였다. 앞으로는 도입이 어렵거나 복잡한 기술들은 별도의 튜토리얼을 진행 한 후 프로젝트에 도입하는 것이 좋아보인다.
Week 4
네 번째 주에는 타임라인을 빠르게 가져오기 위한 방법과 구현에 대해 계속 고민했다. 이 고민이 계속 될 수록 차라리 처음부터 NoSql 이나 graphSql 로 시작했으면 어떨까 하는 생각이 많이 들었다. 그러나 이미 꽤 많은 부분에서 개발이 진행되었고, NoSQL이나 graphSql에 대한 경험이 거의 없어, 지금까지의 개발을 뒤엎고 다시 시작한다면 도저히 기간 내에 완수 할 자신이 없었다. 개발 초기, 즉 설계단계에서 우리는 아래와 같이 단순한 두가지 이유로 RDB를 사용하기로 했다.
JPA(ORM Spec)을 보다 더 활용해보고 싶다.이전 프로젝트에 RDB로 진행했다.
결국 성능은 전혀 고려하지 않은 채로 사용할 DB를 결정한 것이다. 물론 방법이 전혀 없는 것은 아니었다. DB 튜닝이나 캐시 저장소등을 활용해 성능향샹을 기대 할 수 있다. 다만 설계시에 성능적인 부분을 고려하지 않은 채로 DB를 결정한 것은 좁은 선택지에서 시작한거 같다 여전히 아쉬웠다. 더해서 개발 중간에 피봇팅을 수행하기 위한 리스크가 얼마나 큰지 몸소느껴, 개발 초기 단계에서의 설계가 중요함을 깨달았다.
Week 5
마지막 주에는 타임라인 구현과 발생 할 수 있는 예외들에 대한 로직을 처리했다. 심사기준에 시스템 안전성이 포함되어 있기때문에 예외처리는 반드시 필요하다고 생각했다. 문제는 타임라인 구현이었다. 생각보다 처음 사용하는 기술들은 어려웠고 능수능란하게 사용하기에는 시간이 부족해보였다.
개발자의 중요한 자질 중 하나는 일정관리라고 생각한다. 마지막 주에는 다른 일정들도 겹치고, 다른 팀원들과 시간을 맞추기도 쉽지 않은 상황이었다. 여기서 새로운 기술들을 덧붙이기에는 시간적인 리스크와 더불어서 오히려 더 많은 허점이 생길거라 판단되었다. 때문에 아쉽게도 메시지 큐잉이나 캐시 저장소, 분산처리 같은 기술 구현들은 우선순위를 낮추고 시스템 안전성 부분에서 점수를 챙기고, 보고서 이러한 고민들을 녹여내는 전략으로 갔다. 운이 좋게도 전략이 꽤나 잘 들어맞아 수상 할 수 있었 던 것 같다.
What is to learn
이번 프로젝트를 진행하면서 참 많은 걸 배웠다. 대용량 아키텍처에 대한 고민을 해보았고, 이를 통해 단순한 기능 하나조차도 많은 유저들이 사용한다면 뒤에서 얼마나 복잡하고 많은 일들이 처리되는지 조금은 공감 할 수 있었다. 이로 인해 서버개발자 또는 인프라 구축에 대해 더 큰 매력을 느끼고 그들을 더 존경하게 되었다. 그리고 나도 많은 유저들과 트래픽을 처리하는 회사에서 업무를 맡아 진행해보고 싶다는 생각이 들었다.
다른 한편으로는 혼자보다 여럿이 훨씬 좋다는 것을 배웠다. 팀원들과 함께함으로서, 혼자만의 생각에 갇히지 않게 되고 유연하게 사고 할 수 있게 된다. 더해서 그들의 지원군이 곧 나의 지원군이 된다. 또 혼자서는 무리하게 자신을 과신하게 되고 제대로 된 일정관리가 어려우며, 얼마 못가 자기합리화를 통해 포기하기 쉽운 환경에 노출된다.
이 밖에도 여러 배운점들이 많아 전부 나열하기가 어렵다. 여기서 글은 이만 줄이도록 하고, 배움의 기회를 제공한 naver D2와 팀원들, 그 밖의 조언을 주신분들에게 감사한 마음을 전하고 싶다.
시간이 된다면 최우수상을 수상한 작품 코드리뷰를 간단하게 나마 진행해보고 싶다.
