수습과제 게시판 구현하며 나는 무엇을 배웠나?

수습기간 4주 동안 '게시판 만들기' 과제를 부여받았다. 이 글은 과제를 진행하며 나는 1달이라는 긴 시간 동안 무엇을 배웠는지 정리하고자 한다.

 

프로젝트 기술 스택

• 프론트엔드: 퍼블리싱에 JavaScript를 덧붙여 Ajax 요청
• 백엔드: Spring Boot, Spring Security, JDBC Template, Thymeleaf
• DB: MySQL
• 빌드: Maven
• API 문서: Rest Docs

구현한 기능은 크게 다음과 같다.

• 사용자, 게시글, 댓글/답글, 관리자 CRUD 
• 게시글 페이징, 검색, 출력 건수 조건

동영상 1과 2는 결과물이다.

동영상 1. 게시판 홈 화면

 

동영상 2의 로그인한 사용자는 관리자 권한을 가진 사용자로 다른 사용자의 모든 댓글/답글을 삭제할 수 있지만, 수정은 불가하다.

동영상 2. 게시글 상세 화면

1. 코딩은 예술이 아닌 문제 해결의 수단

“댓글과 답글이 가능하게 해주세요.” 과제의 요구사항은 간단했지만, 나는 여기에 ‘무한 Depth 대댓글’을 구현해보고 싶었다. 구현하기 가장 어려울 것 같았기 때문이었다.

 

그래서 댓글 테이블에 parent_id 컬럼을 추가하고, 해당 게시글에 포함된 댓글을 가져온 뒤 애플리케이션 단에서 트리 구조로 만든 후 재귀적으로 탐색하여 대댓글을 구현했다.

 Map<Integer, List<CommentResponse>> commentTreebyParentId = comments.stream()
                .collect(Collectors.groupingBy(
                        rep -> rep.replyParentId() == null ? TREE_ROOT : rep.replyParentId(),
                        LinkedHashMap::new,
                        Collectors.toList()
                ));

private static void visitCommentTree(List<CommentTreeResponse> treeResult, Map<Integer, List<CommentResponse>> byParentId, List<CommentResponse> comments, int depth) {
        if (comments == null) return; // 다음 노드 없으면 종료
        comments.forEach(each -> {
            treeResult.add(CommentTreeResponse.of(each, depth));
            visitCommentTree(treeResult, byParentId, byParentId.get(each.commentId()), depth + 1);
        });
    }

 

그렇게 기능을 완성한 후, "무한 Depth 로 댓글을 만들었는데 괜찮겠죠?" 라고 물어봤다.

“이 게시판에 무한 Depth의 대댓글이 정말 필요한가요?”. 그제서야 나는 '하고 싶은 대로' 구현했지, 실제로 필요한 것을 구현하지는 않았다는 것을 깨달았다.

요구사항이 모호했던만큼 자율성이 컸지만, 나는 "요구사항이 변경되더라도 유연하게 변경되는 코드"가 아닌 흡사 "학교 과제"를 만들었구나를 깨달았다. 즉, 과제를 잘하기 위해 가장 어려운 것을 택한 것이었고, 본질을 잊고있었다.

 

요구사항으로 “답글이 2 depth였으면 좋겠어요”로 바뀐다면, 이 무한 Depth는 유지보수성과 협업 측면에서 불필요한 구현이었다.

후에 답글이 1 depth 이도록 리팩토링 하였고, depth가 더 커질 수 있게(확장성을 고려해) 추가로 댓글 테이블에 depth 컬럼을 추가하며 마무리 했다. 코딩은 예술이 아닌 문제 해결의 수단이었고, 나의 마음가짐을 바꾸게 된 경험이었다.

댓글(comment) 테이블

 

2. 기초 체력 CS

회사 내부망에 게시판을 배포하면서 여러 오류를 해결하고, 내부망 구조에 대해 설명을 듣는 과정에서 네트워크 지식이 큰 도움이 되었다. 또한, 회사의 주력 제품이 Elasticsearch 기반이라 이를 학습 중인데, Elasticsearch의 JVM 힙 메모리/GC 튜닝, 디스크 구조, 고가용성을 위한 클러스터 구성 등 기술을 응용하려면 종합적인 CS 지식이 요구되었다. 이 과정에서, 파일시스템에 대해 부족함을 느껴 공부할 리스트에 추가하게 되었다.

3. 개념 객체란 무엇인가?

홈 화면(동영상 1)을 구성하다 보니 점점 코드가 복잡해졌다. 비즈니스 요구사항을 코드로 표현하면서도, 유지보수 가능한 구조로 만들고 싶었다. 그래서 제미니님의 ‘소프트웨어를 지속 성장시키는 방법’의, '개념 객체' 를 도입하고 불필요한 import 를 제거하려 노력 했지만 잘 와닿지 않았다. 특히 뷰(View) 영역이 복잡할 때 개념 객체를 어떻게 활용해야 하는지가 잘 떠오르지 않았다. 앞으로도 계속 공부하면서, 언젠가 개념 객체처럼 유지보수와 확장이 쉬운, 지속적으로 성장할 수 있는 코드를 만들 수 있기를 바란다.

4. Maven 빌드 툴 학습

이전에 진행했던 프로젝트에서는 Gradle을 사용해 Rest Docs를 배포한 경험이 있어 “나 Rest Docs 할 줄 알아!”라고 생각했지만, 막상 Maven으로 하려니 낯설었다. 그래서 이번에는 Maven 문법과 Asciidoctor 문법을 공식 문서 중심으로 학습했다. 강의에 의존하지 않고, 직접 설정하고 공식문서를 읽고 적용하기 위해 노력했고, 그 결과 Maven pom속성값들과 Asciidoctor 에 대해 필요한 값들을 custom 할 수 있게 되었다.

5. 페이지 객체 구현하기

순수 JDBC Template을 사용했기 때문에, 페이징 정보를 담는 Page 객체를 직접 구현해야 했고, 아래와 같은 코드가 처음 버전이었다.

public class Page

public static Page of(int totalPages, int currentPage) {
        if (totalPages == 0) {
            return empty();   비즈니스 요구사항이 내부에 숨겨져 있음
        }
        return new Page(
                ...
        );
}

private static Page empty(){
	...
}

 

처음엔 이 방식이 간단해 보였지만, 문제는 Page를 생성하는 쪽(Service)에서 Page.of(0, 0)처럼 '0'이라는 매직 넘버를 직접 다뤄야 했다는 점이다. 하지만 이 '0'은 서비스의 책임이 아니었다.
“페이지가 없다”는 의미는 Page 객체의 책임이어야 한다고 생각했다. 그래서 리팩토링을 통해 Page.empty() 메서드를 별도로 정의하고, 내부에 상수 NO_PAGE를 선언을 통해 SRP를 준수하고자 노력했다.

private static final int NO_PAGE = 0;

public static Page empty() {
        return new Page(NO_PAGE, NO_PAGE, false, false, NO_PAGE, NO_PAGE, false, false);
}

public static Page of(int totalPages, int currentPage) {
    return new Page(
            totalPages,
            currentPage,
            hasPrevPage(currentPage),                 // '<' 모양
            hasNextPage(totalPages, currentPage),     //  '>' 모양
            getStartPageOfCurrentBlock(currentPage),  //  10n + 1 페이지
            getLastPageOfCurrentBlock(totalPages, currentPage),  // 10(n+1)페이지
            hasPrevBlock(currentPage),                //  '<<' 모양
            hasNextBlock(totalPages, currentPage));   //   '>>' 모양
}

 

6. 그 외의 것들

JavaScript를 공부하면서 자연스럽게 HTML 구조에도 익숙해졌고, 전반적으로 개발자 도구 사용에도 익숙해졌다. 이미 하나의 언어를 알고 있는 상태에서 새로운 언어를 배우는 것이 크게 어렵지는 않다는 점도 체감할 수 있었다. 다만, 중복 없이 가독성 좋은 JavaScript를 작성하기까지는 아직 갈 길이 멀다.

 

Security의 내부 동작 원리를 이해한 뒤 사용하고 싶었지만, 시간이 부족해 일단은 필요한 부분만 찾아서 적용하는 방식으로 구현했다. 내부 동작 원리를 중요하게 생각하고 이를 알고자 하는데, 이번에는 시간이 부족해서 구현을 먼저 해야했다. 내부 원리를 알고 사용하면 코드의 품질이 달라진다고 생각하지만 개발 속도가 느려진다. 역시 개발은 trade-off 의 연속이다.   

 

순수 JdbcTemplate을 사용하며 DB 테이블의 필드명이 바뀔 때마다 모든 쿼리를 직접 수정해야 하는 불편함이 있었다. 

 

게시판을 구현하면서 많은 고민을 했고, 그 과정들을 글에 담고 싶었지만 다 담지 못해 아쉬움도 남고, 막상 쓰고 나니 별 것 없는것 같기도 하다.. ㅎ 그래도 정리라도 해야 나중에 후회를 안함을 알기에 정리~