작성자의 권한과 현재 사용자의 상태
글·댓글과 사용자 정보 로드 상태를 연결하고 수정·삭제 버튼이 작성자 조건에 맞게 반영되도록 구현·개선했습니다.
04 / 팀 프로젝트 · 웹 서비스
Bit-Hive
거래의 흐름, 사람들의 대화.
01 / MY CONTRIBUTION
게시글·댓글·사용자 반응·작성자 권한의 풀스택 구현
02 / EXPLORE HERE
커뮤니티 조작과 원본 UI, 가상 자금으로 체험하는 거래·자산
03 / EVIDENCE
사용자 전환·작성자 조건·CRUD·댓글·저장 복구와 텍스트 렌더링을 검사했습니다.
CONTEXT & CONTRIBUTION01 / 팀 프로젝트의 실제 담당 영역 02 / 포트폴리오 통합 설계
사용자의 상태가 달라져도, 커뮤니티의 권한은 일관될까?
모의 거래와 커뮤니티가 결합된 팀 프로젝트에서 Spring Boot·React 기반 커뮤니티 기능을 구현했습니다. 전체 거래 엔진이 아닌 게시글 CRUD·반응·카테고리와 인증 상태 반영이 실제 담당 범위입니다.
Spring Boot·React 게시글 CRUD, 카테고리, 좋아요·싫어요, 댓글 수, 작성자 권한 분기 및 인증 상태 반영 오류 수정.
DECISIONS & TRADE-OFFS어떤 판단을 했는가
가상 거래와 실제 인증의 경계
체험용 거래 엔진과 브라우저 사용자 전환은 모의 환경입니다. 실제 계정 인증처럼 보이지 않도록 표시하고 원본의 담당 범위와 새 체험 구현을 구분했습니다.
핵심 흐름
- 게시글·카테고리·댓글과 사용자 반응 상태
- 작성자 조건에 따른 수정·삭제 권한
- 사용자 정보 로드와 인증 상태 반영 오류 개선
기여 범위와 검증 한계
직접 체험 →원본 Spring Boot·React 저장소를 분석하고 로고·메뉴·종목 표·숫자 표시 등을 포트폴리오에 맞게 통합했습니다. 실제 담당은 커뮤니티 기능이며 전체 거래 기능의 단독 개발을 주장하지 않습니다. 거래 엔진·지정가 예약은 체험용으로 새로 구현했고 모든 가격·잔고·사용자는 모의 데이터입니다.
TROUBLESHOOTING / 문제 해결 과정
문제의 원인부터 확인한 결과까지.
개발 당시 기록을 기준으로 정리했습니다. 아래 결과는 이 웹사이트의 체험 기능에서 새로 측정한 값이 아닙니다.
01인증 상태 · 실행 시점로그인 사용자 로드 전 반응 기능이 실행된 문제
BEFORE / 문제 상태
Context의 user가 null인 동안 좋아요·싫어요 실행
AFTER / 변경 후
사용자 식별과 정보 로드 뒤 기능 실행
- 01
문제 상황
게시글의 좋아요·싫어요에 즉각적인 UI 반영을 시도했지만, 로그인 상태가 바로 반영되지 않아 반응 기능에 오류가 났습니다.
- 02
원인 분석
프론트엔드 Context에서 관리하는 사용자 객체가 늦게 로드됐고, 기능 실행 시점에는 user가 null로 인식됐습니다.
- 03
해결 방법과 기술적 선택
당시 로그인 사용자를 식별하는 처리를 수정하고 사용자 정보가 로드된 뒤 반응 기능이 실행되도록 순서를 조정했습니다.
- 04
검증 과정
초기 PDF p.10·개정2 p.27의 수정 전후 기록과 원본 React의 좋아요 조회 훅을 대조했습니다. 원본 훅은 사용자 로딩 완료와 사용자·게시글 식별자가 준비돼야 조회하도록 제한합니다. 과거 실제 서비스의 인증 API를 이번에 재실행하지 않았습니다.
- 05
결과와 검증 근거
개정 PDF에는 수정 후 신규 게시글에서도 좋아요·싫어요가 정상 동작했다고 기록돼 있습니다. 초기 PDF에는 짧은 로딩 틈이 남았다고 기록돼 있으며, Redux·로딩 분기로 더 개선할 수 있다는 학습을 실제 전환 완료와 구분합니다. 로딩 시간이나 오류 감소율은 측정 자료가 없어 제시하지 않습니다.
- 06
배운 점과 남은 한계
인증 상태를 전역으로 공유할 때도 로딩·미인증·인증 완료 상태를 구분해야 합니다. 이후 Redux를 학습하며 전역 상태와 로딩 분기 관리의 필요성을 확인했습니다.
근거 · 범위 초기·개정 포트폴리오 PDF의 문제와 수정 결과. 현재 사이트의 거래·잔고는 별도 모의 체험입니다.