소셜 기반 이벤트 공유서비스_01

---

본 서비스는 개인 프로젝트로 기록용으로 작성.

🐤 게시판 기능

게시판 프로젝트를 처음엔 간단한 구조로 만들었다가, 실제 현업에 가까운 방식으로 리팩토링했다.
실무를 직접 해 본 경험이 없어, 정보를 검색하여 실무의 방식을 최대한 습득하려 노력했다.

---

🐤 Entity 변경 – 작성자 구조 개선

예전 코드

private String author;

바뀐 코드

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id", nullable = false)
private User author;

이유 & 효과

• 문자열로 저장하면 조작 가능성 있음 → 보안 취약

• 실무에서는 작성자(User)를 외래키로 연결해 관리

• JPA 연관관계를 통해 작성자 정보, 히스토리 관리가 용이해짐

---

🐤 DTO 변경 – User → String 추출

예전 코드

public record PostResponseDto(..., String author, ...) {
    this(post.getAuthor(), ...)
}

바뀐 코드

public record PostResponseDto(..., String authorName, ...) {
    this(extractAuthorName(post.getAuthor()), ...)
}

private static String extractAuthorName(User author) {
    return author.getUsername();  // 또는 getNickname()
}

이유 & 효과

• 클라이언트에 User 객체 직접 노출

• 필요한 정보만 추출해서 가볍게 전달

• User 구조가 바뀌어도 DTO는 영향 적음

---

🐤 Service 변경 – 작성자 저장 방식 개선

예전 코드

public Long create(PostRequestDto dto) {
    PostEntity post = PostEntity.builder()
        .author(dto.author())  // String

바뀐 코드

public Long create(PostRequestDto dto, User author) {
    PostEntity post = PostEntity.builder()
        .author(author)  // User 객체        

이유 & 효과

• 작성자 조작 위험 제거

• DTO에는 입력값만 받고, 작성자는 세션에서 직접 주입하는 게 실무 패턴

• Service는 DB 저장에만 집중

---

🐤 Controller 변경 – 본인만 수정/삭제 가능하게

예전 코드

@PutMapping("/{id}")
public void update(...) {
    postService.update(...);  // 아무나 수정 가능
}

바뀐 코드

@PutMapping("/{id}")
public void update(...) {
    PostEntity post = postService.getEntityById(id);
    if (!post.getAuthor().getId().equals(userId)) {
        throw new ResponseStatusException(HttpStatus.FORBIDDEN, "작성자만 수정할 수 있습니다.");
    }
}

이유 & 효과

• 작성자 본인만 수정/삭제 가능하도록 강력한 권한 체크

• Controller에서 권한 체크 → Service는 순수 로직만

---

🐤 리펙토링 전 후 비교

항목	개선 전	개선 후
작성자 처리	String 저장	User 연관관계
권한 체크	없음	본인만 수정/삭제
보안성	조작 가능	신뢰성 ↑
유지보수	DTO/Entity 결합	계층 분리 명확
확장성	낮음	추후 JWT, OAuth 대응 용이

개선 전 문제점

항목	문제점 설명
작성자 저장 방식	게시글 작성자의 정보를 단순히 String author = "user-" + userId 형태로 저장함. → 세션 ID 없이도 아무 문자열로 작성자 지정이 가능하여 위조 위험 존재
권한 제어 없음	게시글 수정/삭제 시 작성자 검증이 전혀 없음. → 로그인만 하면 누구나 다른 사용자의 글을 수정/삭제할 수 있음
DTO 책임 과다	작성자의 ID까지 DTO에서 받아 처리함. → DTO가 원래 맡지 않아야 할 인증/권한의 일부까지 처리하게 되어 역할이 불명확
보안 취약성	세션 기반 인증 구조를 쓰고 있음에도 불구하고, 작성자 검증이 String 비교로만 되어 있어 세션과 데이터 간 연결이 불안정
확장성 부족	작성자 정보를 문자열로만 저장하고 있어서, 추후 댓글, 좋아요, 알림 등의 기능 추가 시 User 연관 기능으로 확장 불가능
테스트/유지보수 어려움	작성자 권한 검증이 없거나 비표준 방식으로 되어 있어, 테스트 케이스 작성이 어렵고 코드의 신뢰성도 낮음

• 사용자가 POST /api/posts에 "author": "user-1"을 포함해서 요청을 보내면, 실제 user-1이 아니어도 글을 등록할 수 있음.

• 사용자가 다른 사람의 글 ID를 알고 있으면, PUT /api/posts/{id}로 내용을 수정할 수 있음.

---