[스터디 회고] 게시판 구현하기

---

서론

클린코드 스터디 이후로 잠시 중단되었던 스터디가 이번에 오프라인으로 진행되었다.

현재는 나를 포함해 현직 개발자 3명으로 구성되어 있고 추가로 증원할 계획이다.

이 글에선 왜 '게시판 만들기'로 진행하게 되었는지에 대해 얘기를 풀어나가려 한다.

또한, 단순히 무언가 만드는 것이 아닌 이번 과정을 통해 무엇을 배우려고 하는지

어떤 궁금증을 갖고 있는지에 초점을 맞춰 글을 작성해 보겠다.

---

스터디 회의

1주차

처음엔 각자 아이디어를 가지고 만났다.

내가 갖고있던 마이너한 아이디어가 하나 있었는데, 채팅 서비스를 주력으로 개발해보려 했다.

흔한 토이프로젝트처럼 각자 공통된 목표를 가지고 한 Repository에서 PR을 날리고 Merge하는 그림을 그렸었다.

2020년에 SSAFY에서 진행했던 프로젝트 하나에서 채팅 서비스를 직접 개발했었는데 너무 아쉬운 부분이 많았고, 채팅 서비스 설계에서 고려할 부분이 굉장히 많아서 이 부분을 함께 개발하면서 더 깊은 고민을 나누면 재밌겠다! 라는 생각이었다.

또한 아키텍처 설계부터 사용자가 점진적으로 증가할 때 어떻게 대응할 수 있는지, 어떤 설계를 해야 하는지, 동시성에 문제는 없는지 등을 고려해서 구현해보면 좋겠다고 생각했다.

2주차

팀원들에게 양해를 구하고, 위의 아이디어를 뒤집어버렸다.

 

현재 회사에서 게시판 관련된 작업을 하고 있는데, 충격에 빠져버렸다. 그리고 이는 곧 스터디 주제를 바꾸는 계기가 되었다.

"게시판 그거 CRUD가 끝아닌가?"라고 생각했던 내가 부끄러울 정도로 고려할 부분이 많았다.

 

스터디 카페에 모여 1시간 가량 내 머릿속에 있는 것들을 하나씩 끄집어내고 이 주제로 변경했을 때 우리는 최종적으로 어떤 스택들을 경험할 수 있으며, 내가 생각하는 프로세스는 이러하다! 를 화이트 보드에 하나씩 그려나갔다.

 

고민할(재밌는) 게 꽤 많았다.

 

조회수(hit) 테이블은 게시물(post) 테이블과 같은 테이블에 있어야할까?

어? 뭔가 떨어져 있어야 할 것 같은데,,, 왜일까?

 

조회수가 어떻게 동작할까?

접근할 때마다 1씩 증가한다. 즉, UPDATE 쿼리가 발생한다.

이 UPDATE가 발생할 때 DB에 부담이 없을까?

인덱스? 그거 말곤 없을까? 쿼리 캐시? 이건 또 뭘까?

이게 성능에 얼마나 큰 영향을 미칠까?

 

조회수 그거 UPDATE가 끝 아닌가? 유튜브에선 왜 실시간으로 안보여주지?

엄청난 트래픽이 발생했을 때 UPDATE 쿼리를 하나씩 실행할까?

이걸 DB에다 하나씩 입력한다고?

앞 단에 캐시를 두는건 어떨까?

그리고 특정 시간마다 DB에 업데이트 해주는 방식으로 하면 괜찮지 않을까?

 

그럼 Redis Cache는 실시간 반영에 문제 없나?

다시 생각해보자. 유튜브 개발자들이 이걸 못해서 안했을까?

실시간으로 반영하는데 뭔가 문제가 있진 않았을까? 내가 지금 뭘 놓치고 있을까?

 

한 게시글 당 수 만, 수십만 개의 댓글이 등록되면
이걸 모두 댓글(Comment) 테이블에다 모조리 넣을건가?

이게 맞을까?

한 게시글에서 INSERT 되는 댓글이 10만개라고 가정하면 1000개 게시글이라면 1억개의 ROW가 삽입된다.

인덱스 테이블의 크기도 어마어마하게 커질텐데 괜찮을까?

댓글을 삭제하게 되면 DELETE 쿼리를 쓸까? 아니면 enabled 필드만 변경할까?

댓글 갯수를 불러올 때 COUNT 함수는 써도 괜찮을까..?

 

비로그인한 유저의 조회수는 어떻게 올릴 수 있을까?

IP 수집을 통해 조회수 처리를 할까?

그럼, 공인 IP 하나에 사설 IP 여러개인 경우 공인 IP가 등록될 테니까 한 유저로 인해 다른 사설 IP는 무의미한 조회수가 될텐데?

그럼 각 유저마다 고유한 키를 생성하는건 어떨까? Local Storage? Session Storage?

---

결론

신기하게도 몇 년 전에는 절대 생각 못했을 만한 것들을 고려하기 시작했다.

이번 스터디 과정에서는 단순히 구현에 초점에 맞춰진 것이 아닌 데드라인을 두지 않고 깊이 있는 학습을 하려고 한다.

• 구글링으로 열심히 따라치기 바빴던 Spring Security의 동작 원리
• Spring AOP 로그 기능 구현
• 모니터링 툴 써보기
• 쿠버네티스를 이용한 무중단 배포와 그 원리
• 분산 처리 환경에서 동시성을 제어하는 방법
• 점진적으로 증가하는 서비스의 아키텍처 개선
• 수정이 용이한 코드 퀄리티 유지
• 테스트 코드 작성
• 코드리뷰

한 줄 요약하자면 하고 싶은거 다 한다. 그리고 스터디원과 함께 한다. 또한 각자 진행한다.

무슨 말이냐면 각자가 동일한 목표를 갖고 개인 Repository에서 진행하게 된다. 스터디원의 역할은 PR에 리뷰어로 등록되어 아주 냉철한 리뷰를 주고 받게 될 것이다.

 

단순히 목록만 보면 아주 타이트한 일정일 수 있으나, 이번엔 일정을 아주아주 넉넉하게 천천히 진행하려고 한다.

이 스터디는 그 동안 데드라인에 쫓겨 미처 돌아보지 못했던 스택들을 조금 더 깊게 살펴보고, 이해하며 개발할 것이다.

 

스터디원 모두가(나를 제외하고) 이 스터디 외에도 다른 스터디를 병행하고 있기도 하고,

나도 준비중인 것이 있어서(좋은 소식이 있다면 블로그에 포스팅 하겠다) 이 스터디가 메인 스케줄에 크게 영향이 없도록, 대신 얼렁뚱땅 지나가지 않도록 코드리뷰하고 정기적으로 모여 피드백 하는 시간을 가질 예정이다.