마무리 회고

3주라는 기간은 참 프로젝트로 따지면 짧은 시간이고, 해커톤으로 따지면 긴 시간인 것 같습니다.
저는 나름의 프로젝트라고 생각하고 임했는데요. 그래서 그런지는 몰라도 정말 짧은 기간동안 열정을 불태운 것 같아 재미있었지만, 아쉬운 점도 많았습니다.

해커톤

장소

해커톤은 성수에 있는 무신사 오피스에서 진행되었습니다. 인천에 살고 있는 저는 성수까지 올 일이 거의 없는데요...(거의 2시간 걸림...) 오랜만에 온 성수는 여전히 신기했습니다. (사실 본게 많지는 않지만..)
이 무신사 건물을 보고 무신사가 정말 큰 회사구나! 하는 생각이 딱 들었고, 지금까지 몇 번 해봤던 해커톤 중에 가장 좋은 시설이 아니었나 싶었습니다.

해커톤 진행

OT로 시작해서 바로 개발을 계속했습니다. 중간중간에 간식도 먹고, 야식도 먹어가면서 하는게 해커톤의 묘미니까 열심히 즐겼습니다. ㅎ

개발은 20시 30분부터 다음날 09시까지 진행을 하였고, 지난 3주간 열심히 구성하고, 개발한 것들을 바탕으로 실제 서비스를 연결하는 작업을 했습니다.

당일에 해커톤 시작했을 때에는 이전에 작업한 것도 많고 그래서 여유롭게 구성하고~ 테스트나 돌리자! 했는데... 생각보다 해결해야하는 문제가 시간이 오래 걸렸습니다.

1. CI/CD 과정에서 기존에는 Git Action을 통해서 모든 과정을 진행하였는데, ALB를 사용하게 되면서 시작 인스턴스를 구성하게 되었고 이 때문에 Git Action으로는 CI를 진행하고 / 시작 인스턴스의 User data로 스크립트를 통해 CD를 구성하고자 하였는데, 스크립트 내에서 계정 인증이 진행되지 않아서 정말 많은 시간을 사용하였습니다. (심지어 제가 맡은 부분...이었습니다...) 한 3시간? 걸린 것 같네요 ㅠㅜ
   여러 멘토님들께 도움을 요청하고, 해결하려고 계속 시도해서 결국 IAM Role을 EC2에 부여하면 로그인 정보를 직접 넣지 않아도 된다는 것을 듣고 해결할 수 있었습니다. (지식++)

2. Lambda에서 Redis에 접근하는데, 50%의 확률로 쓰기 작업이 성공하고, 나머지 50%의 확률로 실패하는 문제가 발생했습니다. 결국 끝까지 해결하지 못했는데, 해커톤 이후 가연이가 공유해준 정보에 따르면 ElastiCache의 Cluster 모드 때문에 해당 Cluster 모드를 사용한다는 설정을 추가해줘야 했다는 것을 알게 되었습니다.
   Cluster모드를 사용하면, R/W가 가능한 노드와 R만 가능한 복제 노드가 구분되기 때문에 트래픽을 자동으로 나누면서 발생한 문제였던 것 같습니다. (실제로는 좀 더 공부해봐야할 것 같긴 하지만... 그렇습니다.)

3. 전체 플로우 테스트 중 Push/Pull 구조에서 Pull 구조가 동작하지 않는다는 것을 발견해서 해당 부분을 해결하는데 또 시간을 사용하게 되었습니다. 저희가 프로젝트를 할 때 Redis 레포를 통일하지 않고 각자 작업을 해서 코드가 많이 중구난방으로 존재하는데, 이 때문에 해결에 시간이 많이 걸리게 되었습니다.

이외에도 몇몇 문제가 더 있었지만 모든 작업을 다 설명하기에는 너무 길어지니 결론만 말하자면 발표 시간이 되었을때 서버에서 에러가 발생해서 API 응답을 받아올 수 없는 상황이 되어버렸습니다. (다 했는데...)

그래서 일단 아키텍처를 중심으로 왜 썼는지, 어떤 점에서 적합하다고 생각되었는지를 집중적으로 설명하고자 노력했습니다. 아키텍처에 대한 설명은 여기 2주차 포스팅에 세세하게 설명하였고, 실제 아키텍처와 큰 차이는 없으니 넘어가도록 하겠습니다.

발표를 마친 후 로컬에서 Postman을 통해서 구현된 모습을 보여주고자 노력하였고, 그래도 기능이 동작을 한다는 것은 보여줄 수 있어서 다행이라고 생각했습니다.

포스트를 작성하고, push 모델, pull 모델로 삽입되는 피드 리스트를 보여주고, 피드를 조회하는 것까지 모두 보여줄 수는 있었고, 최악의 상황에서 최선의 결과를 이끌어내었다고 생각합니다.

기타 등등

1. 많은 과자! 몬스터! 이것보다 더 많음!
   

2. 멘토님이 요아정을 사먹으라고 배달의 민족 쿠폰을 주셨습니다! (엄청난 거금..!)
   
   덕분에 새벽에 맛있는 아이스크림을 사먹을 수 있었는데, 오피스가 에어컨이 계속 켜져있어서 추운 상황이었습니다. 덕분에 입에 한입 넣고, 밖에 나가서 따뜻함을 즐기고... 하는 웃긴 상황이 있었다는...

3. 새벽에 운영진 중 한 분이 VPC에 대한 강의를 해주셨습니다. 대부분 헷갈려해서 정리하는 겸 해주신 것 같은데, 진짜 들었던 VPC 강의들 중 손에 꼽을정도로 정말 세세하고 이해할 수 있게 들을 수 있었습니다. (감사합니다..ㅎ)

진짜 회고

이제 이번 해커톤을 통해 느낀점을 정리하고, 마무리하려고 합니다.

좋았던 점

• 모든 팀원이 이렇게까지 열성적으로 하는 사람들로 구성된 적은 처음이었습니다.

• 멘토님께도 이것저것 여쭤보면서 많은 질문을 해소하고, 다양한 정보를 알 수 있어 좋았습니다.

• 아키텍처에 대해서 어떻게 구성해야하는지에 대해 생각해볼 수 있었으며, 정말 다양하게 구성할 수 있겠다는 생각을 했습니다.

• 여러번 만나면서 회의는 모두 존댓말을 사용하였는데, 당일에는 반말을 사용하면서 팀원들과 더 친해지고 좋았던 것 같습니다. 아마 저희 팀이 해커톤 참가팀 중 가장 화기애애하지 않았나 싶네요. ㅎㅎ

아쉬운 점

• 아키텍처 설계 과정이 너무 길었다는 생각입니다. 이전에 했던 프로젝트 중 기획에 너무 힘을 쓴 나머지 기한 내에 기능 구현을 하지 못해서 터진 적이 있었는데, 비슷하게 시작을 하기 전 준비과정이 너무 길었던 것 같습니다.
  그 결과 해커톤 당일에 VPC를 세팅하고, ALB, Auto Scaling을 포함해서 남은 기능 구현까지 시간이 촉박하게 진행되었습니다.

• Redis를 너무 마구잡이로 썼다는 생각을 지울수가 없습니다. 한정된 자원에서 메모리는 소중할 수밖에 없는데, 데이터를 일단 다 넣어버리게 되면서 아마 실제 테스트를 돌리고 1000명 규모로 진행했다면 메모리가 버티지 못했을 것 같기도 합니다.
  좀 더 계산적으로 처리하고, 사용했어야 했을 것 같습니다.

보완할 점

• "일단 저지르고 보자" 요즘 저의 생활에 핵심이 되는 문장입니다. 할까말까 고민만 하던 저의 삶을 좀 더 바쁘고, 많은 경험을 할 수 있도록 도와주었는데요. 이것을 프로젝트 진행에서도 적용해야할 필요성을 느꼈습니다. 이런 생각이 좀 더 빠른 추진력을 가지도록 도와줄 것이고 아키텍처를 좀 더 빠르게 결정하지 않았을까 싶습니다.

• 아키텍처를 설계할 당시 "Redis에 들어갈 데이터의 목록과 대략적인 양을 계산해보자" 라는 생각을 한 적이 있었습니다. 아마 개발 시간이 좀만 더 있었으면 실제로 해봤을지도 모르죠.(변명이지만) 비록 해커톤은 끝났지만, 좀 더 개선하기 위해서 이 작업을 지금이라도 진행해보고자 합니다. "왜" 이 데이터를 넣고, "왜" TTL을 이정도 수준으로 정했는지를 명확하게 하기 위해서이기도 하죠. 이렇게 미리 대략적인 양을 파악하고 진행했다면 좀 더 풍부한 발표를 할 수 있지 않았을까 싶습니다.

마무리

이번 해커톤을 통해서 정말정말 많은 것을 얻을 수 있었습니다.

우선 지식을 얻었습니다. 아키텍처 설계에 대해 공부하면서, 여러 AWS 서비스를 비교해볼 수 있었으며 어떻게 사용해야하는지, 어느 수준으로 설계해야하는지에 대해 대략적인 감을 잡을 수 있었습니다. Redis에 대한 사용 경험도 마찬가지고요.

또 인맥과 인연을 얻었습니다. 정말 소중한, 값어치를 헤아릴 수도 없을 정도의 인연이죠. 많은 열정을 가진 팀원들과 계속 연락을 주고받으며, Spring 스터디를 진행하게 되었습니다. 멘토님도 이번 해커톤이 아니라 이후에도 궁금한 점이나 도움이 필요하면 연락하라는 말도 들었습니다.(아마 스터디도 좀 도와주시지 않을까 싶긴 한데...)
제가 취업을 할 때까지, 이후에 IT라는 업계에서 활동할 때에도 이 인연은 저에게 아주 큰 가치를 가지게 될 것 같습니다.

이렇게 저의 소중했던 해커톤은 마무리가 되었습니다.