feat: 개발질문 게시판의 해시태그 기능 구현 완료

[mingmingmon]

Summary

#609

커뮤니티 게시판 중에서 개발질문 카테고리에 대해서 해시태그를 설정할 수 있는 기능을 개발했습니다.

Tasks

• 해시태그 등록 API 작성
  (해시태그를 먼저 등록하고, 개발질문 게시판에 해시태그id를 연결하는 형태입니다.)
• 게시글 requestDto에 해시태그id list를 전달하도록 수정
  (개발질문 게시판 전용으로 dto를 만드는 선택지도 있었지만, @Jeong-Ag 님과 회의 후에 결정했습니다. 모든 게시판의 요청 dto에 해시태그 id list를 담아서 전달할 수 있습니다. 이때 null이어도 괜찮습니다. 이는 현재 개발질문 게시판에서만 해시태그 기능을 사용할 수 있지만 추후 확장성을 고려한 선택이었습니다.)
• 게시글 수정 시 해시태그id list를 전달하도록 수정
  (게시글을 수정할 때 해시태그 수정도 함께 할 수 있도록 했습니다. 이때는 기존에 있던 해시태그 정보와 새로운 해시태그 정보를 비교해서 소프트 딜리티를 수정하거나 새롭게 등록할 수 있도록 로직을 작성했습니다.)
• 해시태그로 게시글 검색하기
  (해시태그를 여러개 전달하면 페이지네이션을 적용해서 해당 해시태그를 모두 포함하는 게시글을 반환합니다.)

ETC

리뷰 해주실 때 로직에 대한 피드백이나 성능 피드백 많이 해주시면 반영하겠습니다! 다만 수정된 API 연동이 최대한 빨리 진행되어야 해서, 성능 피드백은 PR 머지 후 다른 이슈에서 진행하고자 합니다.

SQL문

hashtag

CREATE TABLE hashtag (
    id BIGSERIAL PRIMARY KEY,                   
    name VARCHAR(255) NOT NULL,                
    is_deleted BOOLEAN DEFAULT FALSE NOT NULL,  
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP 
);

BoardHashtag

CREATE TABLE board_hashtag (
    id BIGSERIAL PRIMARY KEY,                   
    board_id BIGINT NOT NULL,                   -
    hashtag_id BIGINT NOT NULL,                
    is_deleted BOOLEAN DEFAULT FALSE NOT NULL,  
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, 
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Screenshot

1. 해시태그 생성 API
   

2. 개발질문 게시판이 아닌 경우 해시태그 등록 시 예외처리. 해시태그가 없다면 정상 등록 가능.
   
   

3. 게시글 상세조회 API에서 해시태그 정보를 함께 반환하도록 수정함. 해시태그가 없는 경우는 빈 리스트를 반환. 다른 게시글 조회 관련 API도 마찬가지로 수정완료.
   
   

4. 게시글 수정 API에서 해시태그 정보를 받도록 수정. 이때 카테고리가 개발질문인 것만 해시태그 정보를 수정가능하도록 예외처리
   

5. 해시태그가 모두 포함된 게시글 조회
   [자료구조 해시태그]
   
   [JAVA, C++ 해시태그]
   

[SongJaeHoonn]

작업량이 정말 많으셨을 것 같은데, 빠르게 진행해주신 것 같아 놀랐습니다! 고생하셨습니다.

일단, 저는 해시태그에 대해 그냥 List<String>으로 관리하고, Board를 저장할 때에도 String으로 받아 개발 질문 게시글에 대해서만 반환하도록 하는 걸로 간단하게 생각했었는데, Hashtag라는 새로운 도메인을 만드실 줄은 몰랐습니다..!
HashTag 엔티티를 사용하는게 아니라 그냥 String으로만 관리하면 간단할 것 같은데 Hashtag 도메인을 새로 구현하신 이유가 있으신지 궁금합니다.

[SongJaeHoonn]

이전에 코드베이스 전반 검토할 때, findBy는 예외처리를 하지 않고 조회하는 메서드, getBy는 예외처리까지 포함되어 조회하는 메서드에 적용하기로 했어서, 작업하신 메서드 이름들을 올바른 이름으로 바꾸는 작업이 필요할 것 같아요.

[mingmingmon]

@limehee @SongJaeHoonn 두 분의 피드백 감사합니다!

• 코드 컨벤션 부분은 특이사항 없이 수정하도록 하겠습니다.

• 두 분께서 해시태그 설계에 대해서 좋은 의견을 내주셔서 프론트엔드 담당자 @Jeong-Ag님과 이야기 나눠보고, 제 나름대로 내린 설계 방향에 대해서 추가로 설명 드리도록 하겠습니다. 아래의 내용 읽어보시고 또 의견 주시면 감사하겠습니다!

---

1. @SongJaeHoonn님이 제안해주신 HashTag 엔티티 대신 List<String>으로 Board 마다 저장을 한다면 해시태그를 저장하고 조회하는 행위는 구현이 쉬워지는 것이 맞습니다. 이 방법을 작업 초반에 고려를 해보았는데요. 결국 HashTag 엔티티를 추가하는 쪽으로 결정된 이유는 아래와 같습니다.

• 같은 해시태그의 중복 저장 가능성
  List<Stirng>을 사용할 경우 같은 해시태그가 중복해서 저장될 가능성이 존재합니다. Set<String>을 사용할 수도 있다고 생각이 들었지만, Set도 아래의 문제를 해결하기 부족하다고 생각해서, 테이블 설계를 선택했습니다.

• 해시태그별 게시글 조회 성능의 비효율성
  이번 해시태그 기능으로 개발 질문 게시판에 한해, 1개 이상의 해시태그를 선택하게 되면 그 해시태그가 모두 포함된 게시글을 반환하는 기능이 추가됩니다. 만약 List<String>으로 Board에게 hashtag 들을 관리하도록 한다면, 해시태그 기준 조회 시 전체 게시글을 순회하면서 각각의 List<String>을 살펴봐야 합니다.
  이 방식보다는 HashTag 엔티티를 두고, BoardHashTag 테이블에서 게시글과 해시태그 간의 매핑을 확인해서 조회하는 것이 효율적이라고 판단했습니다. 이러한 RDBMS 활용의 장점을 극대화하기 위해서 제가 적용하지 않았던 인덱싱을 추가 하도록 하겠습니다.

• blue-green 배포 시 데이터 손실의 위험성
  우선 저는 List<String> 방식이나 Set<String> 방식으로 해시태그를 저장한다는 것을, DB에 저장을 하지 않는 것으로 이해했습니다. 이렇게 되면 우리 서비스에서 사용하고 있는 무중단 배포 시에 어플리케이션 메모리에 저장된 데이터 (List<String>, Set<String>으로 저장한 board들의 해시태그들)은 서비스가 종료될 때 소멸할 것입니다. 이러한 문제를 해결하기 위해서는 결국 @ElementCollection이나 해시태그 정보를 JSON으로 칼럼에 저장하는 등의 방식을 사용해야할 수 있을 거에요. 그렇게 되면 결국 DB에 저장한다는 행위가 필수적이기에 HashTag와 BoardHashTag 엔티티를 사용하는 것이 좋다고 생각했습니다.

---

2. @SongJaeHoonn 님이 Board 도메인에서 해시태그 등록을 바로 처리할 수 있지 않을까? 라는 설계적 조언을 해주셨어요. 지금 제가 구현한 상태는 이해하신 것처럼 BoardHashtag 등록을 external로 분리해서 BoardRegisterService에서 참조하도록 하고 있는게 맞습니다! 제가 external로 추출한 이유는 아래와 같습니다.

• 도메인 객체를 분리? 도메인을 분리?
  저는 external 패키지를 다른 도메인 객체에 작업을 시도해야 할 때 external로 필요한 부분을 뽑아서 참조할 수 있는 것으로 이해했어요. 따라서 BoardHashtag와 Board도 다른 도메인으로서 독립적으로 처리를 해야 된다고 생각했답니다. 그렇지만 @SongJaeHoonn 님의 제안과 external의 다른 usecase들을 참고해 보니, 도메인 객체가 아닌 context bound에 해당하는 도메인이 다를 경우 external로 뽑아서 처리하더라구요. external에 대한 정확한 이해가 이게 맞을까요? 그렇다면 제가 Board 내에서 boardHashtag를 등록하도록 수정하는 것이 맞는 것 같습니다!
  (비교대상으로 hashtag의 경우는 board 도메인과 분리되어 있기 때문에 external로 빼야하고, boardHashtag는 board에 종속되어 있기 때문에 external로 빼지 않아도 된다고 이해했습니다.)

---

3. @limehee님께서 짚어주신 해시태그 자율 생성과 보안 문제에 대해서 궁금한 점과 @Jeong-Ag 님과 이야기했던 내용을 바탕으로 추가적으로 구성해본 설게 방식에 대해 설명드릴게요!

• 보안 위협에 대한 궁금증
  해시태그를 사용자가 필요에 따라 자유롭게 생성하는 것이 공격표면을 넓힐 수 있다고 이야기해주셨어요. 제가 예상한 범위는, 기본적인 SQL Injection이나 Xss, 대량의 스팸 데이터 정도 였습니다. 만약 이러한 부분이 공격 지점이 될 수 있다면, 다른 POST 형태의 API도 위협이 될 것으로 생각했어요. 해시태그 자율 등록이 가지는 새로운 보안 위협이 있을까요? 보안 공격을 대처할 수 있는 방식으로 구현할 수 있는 방법은 없는걸까요?
  보안 위협을 예방하기 위해 새로운 기능이나 시도가 제약되는 것 같아서 혹시 예방법이 있다면 그런 쪽으로 풀어나가는 것도 좋을 것 같아서 여쭤봅니다! 제가 아직 보안적 관점이 부족해서 @limehee 님이 짚어주신 보안 취약점에 대해서 조금 더 설명 부탁드립니다!

• 고정된 해시태그를 사용할 경우 Enum으로? 또는 테이블로?
  제가 위의 질문을 가지면서 한편으로는, @limehee 님이 짚어주신 사용자의 해시태그 자율 생성이 아닌, 해시태그를 정해놓고 등록할 수 있는 방안에 대해서도 @Jeong-Ag 님과 이야기 했었습니다. 그 결과 아래와 같이 선정이 되었는데요.

(C, C++, Java, Javascrip, Python, Assembly, Kotlin, Typescript)
(Front-end, Back-end, AI, Game, Android, IOS)
(DB, Devops, Infra, framwork, algorithm)
(기타)

이러한 해시태그를 고정으로 둔다면 Enum으로 관리하는 것이 가장 먼저 떠올랐습니다. 그렇지만 만약, 해시태그를 추가적으로 등록하거나 삭제하는 경우에서는 프론트와 백에서 매번 Enum을 수정해야 된다고 생각했어요. 그래서 저는 위에서 선정된 해시태그들을 지금 구현된 HashTag 테이블에 저장하고, 추가 삭제의 경우는 ADMIN 권한만 가능하도록 하면 유지보수가 편하다고 생각했습니다. 이 설계에 대해서 어떻게 생각하시는지 궁금합니다!

---

설계 부분을 고민하다보니 글이 많이 길어졌습니다,, 부족한 부분 있으면 바로 피드백 주세요!

[limehee]

@mingmingmon

• 보안 위협에 대한 궁금증
  해시태그를 사용자가 필요에 따라 자유롭게 생성하는 것이 공격표면을 넓힐 수 있다고 이야기해주셨어요. 제가 예상한 범위는, 기본적인 SQL Injection이나 Xss, 대량의 스팸 데이터 정도 였습니다. 만약 이러한 부분이 공격 지점이 될 수 있다면, 다른 POST 형태의 API도 위협이 될 것으로 생각했어요. 해시태그 자율 등록이 가지는 새로운 보안 위협이 있을까요? 보안 공격을 대처할 수 있는 방식으로 구현할 수 있는 방법은 없는걸까요?
  보안 위협을 예방하기 위해 새로운 기능이나 시도가 제약되는 것 같아서 혹시 예방법이 있다면 그런 쪽으로 풀어나가는 것도 좋을 것 같아서 여쭤봅니다! 제가 아직 보안적 관점이 부족해서 @limehee 님이 짚어주신 보안 취약점에 대해서 조금 더 설명 부탁드립니다!

프론트 팀과 별도로 진행된 논의 내용은 제가 공유받지 못하여 정확히 알지 못합니다. 그러나 제가 이해한 바에 따르면, 해시태그 기능은 사용자가 카테고리 게시판에서 해시태그를 선택하면 해당 해시태그로 등록된 게시글 목록이 표시되는 방식입니다. 이 경우, 일부 사용자가 권한 관리가 적절히 이루어지지 않는 점을 악용하여 다량의 해시태그를 생성할 수 있으며, 이로 인해 더미 해시태그가 페이지에 노출될 수 있습니다. 또한, API 요청에 제한이 없을 경우 시스템 부하가 증가하여 서비스에 영향을 미칠 수 있으며, 최악의 경우 무작위로 생성된 데이터로 인해 저장 공간이 부족해지는 등의 문제가 발생할 수 있습니다.

물론, 민주님께서 언급하신 대로 다른 POST 메소드의 API도 유사한 문제가 발생할 수 있다는 점은 일리 있지만, 적절한 권한 제어를 통해 공격 가능성을 최소화하고 서비스 이용자에게 미치는 영향을 줄이는 것이 중요하다고 생각합니다. 따라서 해시태그 자율 생성으로 인한 보안 취약점을 예방하기 위한 추가적인 방안이 필요하다고 판단됩니다.

---

• 고정된 해시태그를 사용할 경우 Enum으로? 또는 테이블로?
  제가 위의 질문을 가지면서 한편으로는, @limehee 님이 짚어주신 사용자의 해시태그 자율 생성이 아닌, 해시태그를 정해놓고 등록할 수 있는 방안에 대해서도 @Jeong-Ag 님과 이야기 했었습니다. 그 결과 아래와 같이 선정이 되었는데요.

(C, C++, Java, Javascrip, Python, Assembly, Kotlin, Typescript)
(Front-end, Back-end, AI, Game, Android, IOS)
(DB, Devops, Infra, framwork, algorithm)
(기타)

이러한 해시태그를 고정으로 둔다면 Enum으로 관리하는 것이 가장 먼저 떠올랐습니다. 그렇지만 만약, 해시태그를 추가적으로 등록하거나 삭제하는 경우에서는 프론트와 백에서 매번 Enum을 수정해야 된다고 생각했어요. 그래서 저는 위에서 선정된 해시태그들을 지금 구현된 HashTag 테이블에 저장하고, 추가 삭제의 경우는 ADMIN 권한만 가능하도록 하면 유지보수가 편하다고 생각했습니다. 이 설계에 대해서 어떻게 생각하시는지 궁금합니다!

초기 논의된 방향을 그대로 적용할 경우, 해시태그를 Enum 또는 String 타입으로 관리하는 것 모두 큰 문제는 없을 것으로 보입니다. Enum을 사용하면 안정성과 관리 측면에서 분명한 장점이 있지만, 가까운 미래에 velog 서비스와 유사한 형식으로 변경되거나 해시태그가 자주 변경될 예정이라면 마이그레이션 과정과 부수적인 코드 수정이 번거로울 수 있습니다. 반면, String 타입을 사용할 경우 프론트 팀과의 협업 하에 고정된 해시태그를 사용하는 경우, 잘못된 해시태그 요청에 대한 모니터링이 필요할 것입니다. 또한, 중복되는 해시태그의 관리와 더 이상 사용되지 않는 해시태그의 체계적인 관리가 필요합니다.

저는 민주님께서 언급하신 대로 현재 구현된 HashTag 테이블에 고정된 해시태그를 저장하고, 추가 또는 삭제가 필요할 경우 ADMIN 권한을 통해서만 가능하도록 하는 방안이 유지보수 측면에서 효율적이라고 생각합니다. 이러한 설계는 프론트와 백엔드 간의 Enum 수정 없이 유연하게 해시태그를 관리할 수 있으며, 필요 시 관리자의 권한 하에 해시태그를 체계적으로 관리할 수 있는 장점이 있습니다.

[SongJaeHoonn]

• 같은 해시태그의 중복 저장 가능성
  List<Stirng>을 사용할 경우 같은 해시태그가 중복해서 저장될 가능성이 존재합니다. Set<String>을 사용할 수도 있다고 생각이 들었지만, Set도 아래의 문제를 해결하기 부족하다고 생각해서, 테이블 설계를 선택했습니다.

이 부분은 서비스단에서 게시글 저장시 해당 게시글에 대한 중복 검증 절차를 거치면 괜찮을 것이라고 생각했습니다.
그러나,

• 해시태그별 게시글 조회 성능의 비효율성
  이번 해시태그 기능으로 개발 질문 게시판에 한해, 1개 이상의 해시태그를 선택하게 되면 그 해시태그가 모두 포함된 게시글을 반환하는 기능이 추가됩니다. 만약 List<String>으로 Board에게 hashtag 들을 관리하도록 한다면, 해시태그 기준 조회 시 전체 게시글을 순회하면서 각각의 List<String>을 살펴봐야 합니다.
  이 방식보다는 HashTag 엔티티를 두고, BoardHashTag 테이블에서 게시글과 해시태그 간의 매핑을 확인해서 조회하는 것이 효율적이라고 판단했습니다. 이러한 RDBMS 활용의 장점을 극대화하기 위해서 제가 적용하지 않았던 인덱싱을 추가 하도록 하겠습니다.

이 부분에서 제가 해시태그 기반 게시글 반환 기능이 있다는걸 인지하지 못했네요. 말씀해주신대로, 조회 시 전체 게시글을 순회하는 패턴은 효율이 많이 떨어지고, HashTag도메인 없이 단순 String으로 저장하는 방식은 DB를 효과적으로 이용할 수 없고 @ElementCollection의 사용보다는 새로운 엔티티 설계가 더 좋았을 것 같네요! 자세히 설명해주셔서 감사합니다.

---

• 도메인 객체를 분리? 도메인을 분리?
  저는 external 패키지를 다른 도메인 객체에 작업을 시도해야 할 때 external로 필요한 부분을 뽑아서 참조할 수 있는 것으로 이해했어요. 따라서 BoardHashtag와 Board도 다른 도메인으로서 독립적으로 처리를 해야 된다고 생각했답니다. 그렇지만 @SongJaeHoonn 님의 제안과 external의 다른 usecase들을 참고해 보니, 도메인 객체가 아닌 context bound에 해당하는 도메인이 다를 경우 external로 뽑아서 처리하더라구요. external에 대한 정확한 이해가 이게 맞을까요? 그렇다면 제가 Board 내에서 boardHashtag를 등록하도록 수정하는 것이 맞는 것 같습니다!

패키지로 나뉘어진 도메인(Board, Member, Comment)에서 다른 도메인을 참조해야 하면 external로 빼는 것은 현재 아키텍처 구조에서는 당연한 것 같습니다. 그러나 같은 도메인 내에서 각 도메인 객체(entity)를 다룰 때에는 해당 도메인 안에서 처리를 하는 것이 맞다고 생각해요.

(비교대상으로 hashtag의 경우는 board 도메인과 분리되어 있기 때문에 external로 빼야하고, boardHashtag는 board에 종속되어 있기 때문에 external로 빼지 않아도 된다고 이해했습니다.)

정확하게 이해하셨습니다!

[mingmingmon]

1. external로 빠져있던 boardHashtag 관련된 로직을 board 패키지 아래로 옮겼습니다.

2. 해시태그를 사용할 수 있는 카테고리인지 확인하는 로직을 보충했습니다.

3. Hashtag 테이블에 해시태그를 저장하고 조회할 수 있는 API를 작성했습니다. 이때 boardUsage라는 필드를 통해서 해당 해시태그가 게시글에서 몇 번 쓰였는지 알 수 있도록 했습니다. 아래 사진처럼 뷰를 만들기 위해 추가된 필드입니다.
   
   [해시태그 조회하기]
   

4. service가 아닌 도메인 객체에서 처리할 수 있는 검증 로직을 DDD에 맞게 수정했습니다.

5. 복잡한 로직과 stream 사용으로 인한 가독성 저하를 메소드 추출로 개선했습니다.

[mingmingmon]

최종 SQL문 입니다.

CREATE TABLE hashtag (
    id BIGSERIAL PRIMARY KEY,                
    name VARCHAR(255) NOT NULL,                  
    is_deleted BOOLEAN DEFAULT FALSE NOT NULL,  
    board_usage BIGINT DEFAULT 0 NOT NULL,     
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, 
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL 
);

CREATE TABLE board_hashtag (
    id BIGSERIAL PRIMARY KEY,                  
    board_id BIGINT NOT NULL,                   
    hashtag_id BIGINT NOT NULL,                  
    is_deleted BOOLEAN DEFAULT FALSE NOT NULL,  
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL, 
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL  
);

CREATE INDEX idx_board_hashtag_board_id ON board_hashtag (board_id);
CREATE INDEX idx_board_hashtag_hashtag_id ON board_hashtag (hashtag_id);

INSERT INTO hashtag (name, is_deleted, board_usage, created_at, updated_at) VALUES
('C', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('C++', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Java', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Javascript', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Python', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Assembly', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Kotlin', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Typescript', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Front-end', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Back-end', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('AI', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Game', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Android', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('IOS', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('DB', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Devops', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('Infra', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('framework', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('algorithm', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP),
('기타', false, 0, CURRENT_TIMESTAMP, CURRENT_TIMESTAMP);

[SongJaeHoonn]

제안했던 내용 잘 반영해주셔서 감사합니다! 추가적인 코멘트 남깁니다.

[limehee]

재훈님이 추가로 남겨주신 코멘트만 해결하면 될 것 같습니다. 긴 시간 작업하시느라 고생 많으셨어요.