개발9 비밀로그 아키텍처 구조 도메인으로 관심사를 나누고 이벤트기반으로 도메인간 통신을 하는 구조다.하지만 가장 중심인 엔티티간의 연결고리가 끊어지지 않아 아직 결합도가 있다.이벤트기반으로 많은 연결고리를 끊었음에도 불구하고 유저 엔티티에 어댑터를 통한 통신이 필요하다.이것은 엔티티간의 FK제약 때문으로 많은 엔티티가 유저 엔티티에 아웃어댑터로 통신을해야한다. 2026. 3. 11. 회원가입오류 원래는 브라우저가 직접 백엔드 API를 호출하는 방식이었음백엔드를 숨기고 프론트엔드에서 내부통신으로 백엔드를 호출하게 변경 중아직 완벽하게 변경되지 않아서 아직 변경되지 않은 부분은 프록시를 경유하게 했음백엔드 API를 받으면 Next.js 라우트 핸들러가 프록시 역할로 그걸 받아서 내부통신을 요청하는 것기존에는 브라우저에서 백엔드로 바로 쿠키를 줬는데 전환중에 프록시에서 전달해야하는 쿠키를 누락함 2026. 2. 2. Redis를 활용한 게시판 캐싱 커뮤니티 게시판의 인기글 목록 조회 시 다음과 같은 비효율적인 부분이 있었습니다.1. 반복적인 DB 조회 부담 : 자주 조회되는 실시간/주간/레전드 인기글 목록을 DB에서 조회하여 응답 시간이 증가했습니다.2. 실시간 인기도 반영의 어려움: RDB만으로 글의 인기도를 실시간으로 반영하려면 요청마다 복잡한 인기글 재선정 로직이 필요했습니다.따라서 자주 조회되는 요청은 캐싱을 하여 DB의 부담을 낮추고자 했습니다. 캐싱 요구 사항TTL이 만료되어도 집계 쿼리가 재실행되면 안됩니다.실시간 인기글은 사용자 활동(조회, 댓글, 추천)에 따라 동적으로 변화합니다.글이 삭제되거나 수정되었을 때 사용자는 이전 버전의 글을 보면 안됩니다.자주 조회되고 변하지 않는 인기 게시글 목록은 통째로 캐싱하여 반환해야 합니다.캐시.. 2025. 11. 2. 로그아웃 로직 Optional과 예외 처리 개선기 문제 : 과도한 예외 처리와 복잡한 흐름처음 작성했던 코드(1번 코드)는 로그아웃 프로세스를 하나의 큰 try-catch 블록 안에 넣고 있었습니다. // 1번 코드함수: 로그아웃을 시작한다 시도해본다: 소셜 계정에서 로그아웃을 요청한다 (이 과정에 사용자 인증 정보 확인도 포함) 로그아웃 완료 이벤트를 알린다 사용자 인증 정보를 모두 지운다 로그아웃용 쿠키를 반환한다 만약 오류가 발생하면: 로그아웃 실패 오류를 발생시킨다 이 방식은 얼핏 보면 안전해 보이지만, 다음과 같은 두 가지 큰 문제를 가지고 있었습니다.단일 책임 원칙 (SRP) 위반: 소셜 로그아웃 처리 메서드 안에서 사용자 정보 확인과 실제 로그아웃 요청이라는 두 가지 책임이 섞여 있었습니.. 2025. 9. 23. 비밀로그 개발 예정 기능 향후 추가기능탑재를 위한 버전2가 완성되어간다버전2라고하지만 준비한 기간에 비해서는 사용자가 느끼는 기능추가가많지않다버전2는 향후 추가기능 탑재를 위한 서버내부리팩토링이 주 목적이다사용자가 느끼기에는 디자인 친화적 변화 오류개선 정도의 개선만있다 (디자인 변화가 사용자가 느끼기에는 많이 변하게 느껴지려나..?)아키텍처변경이외의 기능은 보안강화 로깅강화 관리자기능강화가 주된 변화다향후 추가할 기능을 적어보려한다메인은 채팅기능추가다 (단체채팅,익명채팅,닉네임채팅)친구기능추가도 필요하다친구추천기능도 필요하다 (흔히말하는 2촌, 3촌등등 유니온파인드를 활용하는게 떠올랐지만 아무리 빨라도 데이터를 가져와서 지지고볶는건 아닌거같다 nosql쪽에 해답이 있으려나? 구현은 더 고민해야한다)실시간 인기 롤링페이퍼도 만들.. 2025. 9. 14. TestContainers로 MySQL + Redis 통합 테스트 이번 글에서는 CommentClosureQueryAdapter 통합 테스트와 PostCacheSyncAdapter 테스트를 TestContainers 기반으로 통합 테스트 환경으로 바꾸면서 겪은 삽질과 해결 과정을 정리해보겠습니다.1. 시작: 댓글 테스트에서 MySQL만 사용처음에는 댓글 테스트에서 MySQL 컨테이너만 사용했습니다.@Containerstatic MySQLContainer mysql = new MySQLContainer("mysql:8.0") .withDatabaseName("testdb") .withUsername("test") .withPassword("test");@DynamicPropertySourcestatic void dynamicPrope.. 2025. 9. 5. 헥사고날 아키텍처 리팩토링 (1) 배경소셜 로그인 흐름을 정리하는 과정에서 도메인 경계와 책임 배치가 뒤섞여 있었다. 인증 서비스가 사용자 도메인의 내부 포트를 직접 참조하고, DTO에서 쿠키를 만들거나, FCM 토큰 이벤트가 중간 계층에서 발행되는 등 응집도가 낮았다. 목표는 기능 안정성을 유지하면서 아키텍처 원칙을 지키고, 책임을 올바른 계층으로 되돌리는 것이었다.상황인증 서비스가 사용자 도메인의 인바운드 포트를 직접 호출해 계층 의존 방향이 어긋남.쿠키 생성이 DTO 내부에서도 이뤄져 책임이 분산됨.블랙리스트 확인 위치와 시점이 일관되지 않음.로그인의 결과를 담은 DTO에서 “기존/신규” 분기 정보가 빠지며 흐름 제어가 모호해짐.임시 데이터 저장 포트의 메서드 시그니처가 구현/호출부와 어긋나 빌드 오류 발생.인증 데이터 저장 포트의.. 2025. 8. 12. 서버 비상시 AI 분석 실시간 메시지 전송 시스템 구현 기존에는 Scouter APM을 통해 서버를 모니터링했지만, 24시간 상시 모니터링은 현실적으로 어려웠습니다. 예외가 터졌을 때, 이를 몇 시간 후에나 인지한 경험이 있습니다. 이러한 문제에 직면하며 단순한 서버 상태 알림을 넘어, 문제의 원인과 심각성을 즉시 파악하고 대응할 수 있는 지능형 모니터링 시스템의 필요성을 느꼈습니다. 이에 저는 GPT 기반의 서버 모니터링 AI를 개발하여 모니터링 부담을 줄이고, 신속하고 정확한 문제 해결을 돕고자 했습니다. 처음에는 서버 내부 API로 GPT를 호출하려 했으나 서버가 죽으면 응답을 할 수 없고 설령 서버가 죽지 않더라도 트래픽에 요청이 느려질 가능성이 있었습니다. 서버 진단 기능이 서버 내부에 있는 것은 잘못된 설계라고 판단하여 이 문제를 해결하기 위해.. 2025. 8. 7. 비밀로그 자체 스캐닝 및 공격 (2025년 8월 5일) ZAP을 이용한 스캐닝과 공격으로 비밀로그의 취약점을 진단했습니다.이 글은 취약점을 해결한 이후에 공개로 전환될 예정입니다. 1. 개요본 보고서는 ZAP(Zed Attack Proxy) 스캔 결과를 바탕으로 작성된 종합 보안 보고서입니다. 비밀로그의 현재 보안 상태를 평가하고 각 문제에 대한 상세 분석과 조치 사항을 작성했습니다.스캐닝 뿐만 아니라 파일취약공격, SQL 인젝션, XSS등 약 30가지 이상의 공격들을 총 2만번 시행했는데 모두 방어할정도로 기본 보안은 나쁘지 않았습니다.하지만 스캐닝에서 검출된 취약점을 보완하겠습니다2. 취약점 요약ZAP 스캔 결과, 총 11개의 경고가 감지되었습니다. 취약점의 리스크 레벨별 분포는 다음과 같으며, 정보성 리스크는 여기 적지 않았습니다.높음(High): 0건.. 2025. 8. 5. 이전 1 다음
