7주간의 공통 프로젝트 회고
고생 끝에 회고 온다
원래 이걸 제목으로 하려고 했었다
들어가는 말
오늘은 짧게만 느껴졌던(실제로도 짧다) 7주 간의 프로젝트를 마치고, 프로젝트 회고를 해보도록 하겠다.
이번에 시도한 것
사실, 나에게 이번 프로젝트 자체가 큰 도전이고 시도였다. 하우에버! 개발자로서 성장하는 데 도움이 됐던 우리의 팀 문화! 특별한 시도들을 정리해보겠다.
1. TDD
TDD로 프로젝트 개발해본 것은 누가뭐래도 자랑스럽게 얘기할 수 있는 경험이었다.
처음에는 적응하는 데만 엄청 오래 걸릴 줄 알았는데, 생각보다 빠르게 TDD 프로세스에 녹아들 수 있었던 데에는 세 분의 큰 도움이 있었기 때문이다.
TDD 안하면 범죄라고 가스라이팅(막이래ㅋㅋ) 해주신 팀장님, TDD 기초 레퍼런스 자료 찾아주시고 공부 도와주신 두 개발 슨배임들..
매우 very much 감사하다!
TDD 경험은 곧바로 자소서의 양분이 되었다.
안정적인 서비스를 요구하는 기업에서 테스트를 꼼꼼하게 해봤다는 경험은, 안좋게 볼래야 안좋게 볼 수가 없더라..
아쉬웠던 점은, 테스트 커버리지가 생각보다 많이 낮았다는 것?
70%정도 나왔던 것으로 기억하는데.. 테스트코드를 짠다고 짰지만 완벽하지 못했던 것 같다.
2. 딥다이브 🏊
이건 개인적으로 도움이 정말정말 많이 되었고, 이야기를 들어보니 현업 개발자분들도 칭찬해주셨던 부분이라고 한다.
그날그날 프로젝트 구현만 하지 않고 내가 사용하고 있는 기술에 대해서 공부 하고 진행한 것.
Java는 오랜만이고(길가다가 졸업 이후 처음 보는 초등학교 동창 마주쳐서 어쩌다 서로 인사는 했는데 하필 가는 방향이 같은 어색한 사이) Spring은 처음이었던 나는, 처음엔 기술에 대한 이해없이 구현에 들어갔다.
그랬더니 이 어노테이션은 뭐고, 저 어노테이션은 뭐고, 빈은 뭐고, ASP는 뭐고 등등.. 계속해서 DFS식 공부(a.k.a. 나무위키식 탐색)가 되어버렸다.
그런데 오전 데일리 스크럼 이후 시간을 할애하여 지금 사용하는 언어, 프레임워크, 기술의 기초에 대해 공부하다보니(심지어 꽤 딥하게), 어느샌가 개발 도중에 정보탐색을 위해 이탈하는 시간이 줄었다.
이번 프로젝트에서도 개발 방향이 구체화되면, 사용할 기술부터 짚고 넘어가야겠다 싶다!
이래서 기업에서 다양한 경험을 좋아하는구나 싶다.
뭐든지 해본 놈이 잘 알고, 잘 하겠지!
3. 기술블로그 작성
처음에 기술블로그 작성하라는 얘기를 듣고 속으로는 아차차 헉 에구머니나가 절로 튀어나왔다.
하지만 애써 침착한 나..(까라면 까야지)
처음에 기술블로그라는 게, 내가 아는 지식을 공유하는 창구로 생각했다.
하지만 쓰고 피드백 받다보니 그런 게 아니더라!
기술블로그는 나의 좌충우돌 얼렁뚱땅 얼레벌레 프로젝트 시행착오 모음집이 되어야 좋은 것 같다.
팀장님이 해주신 말씀 중에 되게 와닿았던 것이
"구글링 할 때 기술블로그? 다 너네같은 주니어가 쓴거야~ 그거 다 모래성이야 모래성~ 갖다 버려~(다소 의역)"
라는 말씀이었다.
'아니 그럼 기술블로그는 왜 쓰는거지?' 라고 생각하는 찰나, "너만의 스토리를 써라" 라는 전언이 있었고 나는 그저 "Yes, sir"..
프로젝트를 진행하면서 내가 어려움을 겪었던 부분, 극복한 방법 혹은 극복 못했더라도 고민한 부분, 흔적을 남기는 것이 엄청 중요한 것 같다.
그런 의미에서 기술블로그는 상당한 의미를 가지고, 되돌아 볼 때도 도움이 많이 되는 것 같다.
프로젝트 일기나 앨범같은 느낌 아닐까 싶다..
기술적 도전
사실 초심자가 TDD만 해도 난 스스로 엄청 대견하다고 생각했다.
그런데 팀장님 왈 "프로젝트를 통해 얻어가는 게 있어야지"
암~! 까라면 까야지!
웹소켓 재연결 로직 구성
이전 포스트에서 다뤘지만, 서버에서 웹소켓 연결 끊김을 감지하는 건 꽤 시간이 걸린다.
Heartbeat를 5초 간격으로 보낸다고 해도, 실시간 면접 연습 중에 5초? 상당히 긴 시간이다.
그래서 고안한 것이 클라이언트 주도 재연결 되시겠다! (VJ특공대 말투로)
클라이언트는 웹소켓 연결이 끊긴 걸 바로 감지하기에(이벤트 기반), 비정상 종료의 경우 서버로 재연결 요청을 보내도록 했다.
사실, 우리의 면접 파이프라인이 상당히 단순했기에 시도할 수 있었던 방법이었다.
서버와 클라이언트의 ping and pong 이랄까..
이벤트 기반이지만 마치 HTTP 요청 같달까..
클라이언트는 서버에서 발생시킨 이벤트를 받아 자신의 상태를 변화시키고, 사용자의 다음 동작을 유도한다.
그럼 연결이 끊겼을 때 클라이언트가 알아야 할 정보는?
서버측에서 발생했던 마지막 이벤트!!
그 중에서, 잡다한 곁가지 이벤트를 제외하고 면접 파이프라인에 핵심이 되는 이벤트들만!
추가적으로, 면접 단계별 UI를 위해 클라이언트에서만 관리, 사용하던 status의 복원도 필요하여, 클라이언트의 status가 변할 때 서버에서 받아서 저장해두었다.
따라서 클라이언트가 재연결 요청을 보냈을 때 서버는 마지막 핵심 이벤트와, status만 보내주어 재연결 구현이 성공했다.
다음에 해보고 싶은 것
이번 프로젝트에서 아쉬웠던 부분을 보강하고, 경험하지 못했던 부분을 시도해보고 싶다.
1. Redis 캐싱
이미 다음 프로젝트에서 도입이 예정되어있는 상태이다!
다음 프로젝트는 모의투자 서비스로, 실제 종목별 호가 데이터를 빠르게 가져와야 한다.
하지만 많은 사용자가 동시다발적으로 보내는 요청마다 API를 호출할 순 없지 않은가..
따라서 종목의 실시간 정보를 캐싱하되, TTL을 짧게 가져가는 방식으로 API요청을 최대한 줄이고 사용자가 느낄 latency도 줄일 수 있을 것이다.
2. 부하 테스트
이번 프로젝트에서도 처음에는 해보고 싶었으나, 시간이 촉박하여 시도하지 못했다.
다음 프로젝트는 동시 사용자 1000명일 때 안정적인 서비스 제공을 목표를 하고 있으므로, 서비스 구조 설계 시부터 확장 가능하게(어떻게 하는지 모름) 설계할 수 있도록 공부를 열심히 해야 할 것 같다.
3. 시계열 DB
금융 데이터 처리의 꽃..
시계열 데이터를 가공하는 것 까지는 아니지만, 저장/관리 경험도 없는 나에게는 이 정도도 미래를 위해 큰 도움이 될 것 같다.
맺는 말
서비스의 목표를 정해두고 하는 프로젝트도 좋지만, 내가 얻어갈 수 있는 것을 중심으로 진행하는 것도 아주 좋았다.
뭔가.. 프로젝트를 하면서도 포폴 컨설팅도 동시에 받는 느낌?
다음 프로젝트는 고수 슨배임들이 없으니 슨배임들이 뼈 깎으셨던 만큼 이번에는 내가 깎아보도록.. 노력해.. 봐야지..
제목 후보들
너는 학생이고 나는 회고
아이고 포켓몬고 레츠고 회고
"ㅎ고자라니.." "네?" "회고잘하니?"
고민 말고 회고
후회(고)~ 하고 있어~요~
고생 끝에 회고 온다
