김연재

계층형 타이머 구조에서 하위 타이머 시간 변경 시 상위 부모 노드의 누적 시간도 함께 갱신해야 했는데, 초기엔 트리 깊이만큼 반복 UPDATE 쿼리가 발생했습니다. PostgreSQL 재귀 CTE로 부모 노드를 한 번에 조회한 뒤 단일 벌크 UPDATE로 처리하도록 최적화했고, 벌크 연산 후 JPA 영속성 컨텍스트와 DB 상태가 불일치하던 문제도 영속성 컨텍스트 초기화로 해결했습니다.

PWA 환경에서 네트워크가 끊겨도 기록이 유지되도록 실패한 요청을 IndexedDB에 저장한 뒤 온라인 복귀 시 재전송하도록 구성했습니다. 이후 캐시된 값을 즉시 표시하고 최신값은 백그라운드에서 재검증하는 방식을 도입해, 캐시 히트 시 첫 렌더 시작 시간을 약 5ms로 단축하고 사용자 체감 성능을 개선했습니다.

초기 위치 기반 검색은 전체 데이터를 조회한 뒤 애플리케이션 레이어에서 거리 계산을 수행해 데이터가 늘수록 응답 속도가 크게 저하됐습니다. PostGIS ST_DWithin + Bounding Box 기반 공간 쿼리로 공간 인덱스를 활용하도록 바꿨습니다. 또한 좌표를 장소 정보로 변환할 때마다 외부 지오코딩 API를 호출하던 부분을 좌표별 인메모리 캐시와 좌표 단위 락으로 중복 호출을 제거해, 캐시 히트 시 1,393ms → 6ms 수준으로 단축했습니다. 좌표→장소 매핑은 사실상 불변이고 DB가 원본이라 무효화 전파가 필요 없어, Redis 대신 인메모리 캐시를 선택했습니다.

이미지 변환·썸네일 생성을 요청 처리 스레드에서 동기적으로 수행해 응답이 지연되던 문제를 @Async 비동기 처리로 전환 — 원본 업로드 완료를 우선 응답하고 후처리는 백그라운드에서 수행해 업로드 응답 시간을 1,491ms → 450ms로 단축했습니다. 실패 건은 FAILED로 분류 후 스케줄러가 주기적으로 재처리합니다.

iOS에서 간헐적으로 발생하던 HEIC 업로드 실패를 분석해 Content-Type 검증을 Magic Byte 기반으로 바꾸고, 파일 검증 이후 변환을 수행하도록 처리 순서를 조정해 업로드 안정성을 높였습니다.

기존에는 Refresh Token 삭제, 신규 토큰 저장, 세션 정보 갱신을 순차적으로 수행했습니다. 그런데 "삭제할 구 토큰"을 판단하려면 현재 세션을 먼저 읽어야 하는 read-modify-write 구조라, 동시 요청 두 개가 같은 구 토큰을 읽고 각자 새 토큰을 저장하면 한 세션에 유효한 토큰이 둘 남는 문제(single-use rotation 붕괴)를 확인했습니다. 단순 MULTI/EXEC는 쓰기를 묶을 뿐 이 읽기 경합을 막지 못하므로, 세션 키를 WATCH로 감시한 뒤 MULTI/EXEC로 원자 커밋하는 CAS 방식을 적용했습니다. 커밋 직전 다른 요청이 키를 바꾸면 EXEC가 취소되므로 최신 값 기준으로 최대 3회 재시도하고, 소진 시 409로 재시도를 유도해 멀티 디바이스 환경에서도 세션당 유효 토큰이 정확히 하나만 남도록 보장했습니다.

초기 구현은 좋아요를 누를 때마다 게시글의 반응 기록 전체를 지우고 다시 저장하는 애그리거트 방식이라, 두 사람이 동시에 누르면 나중 요청이 앞선 요청을 덮어써 좋아요가 유실됐습니다. 설계상 @Version 기반 Optimistic Lock이 있었지만, 변경이 자식 테이블(반응)에서만 일어나 루트 엔티티의 버전이 증가하지 않아 충돌이 감지되지 않는 구조였습니다. 락을 강제로 작동시키는 대신, 좋아요는 본래 회원 1명당 1행이라는 점에 착안해 (post_id, member_id) 복합 PK 구조를 활용해 회원별 한 행만 갱신하도록 바꿔 충돌 자체를 제거했습니다. 공유되는 좋아요 총 개수만 DB가 원자적으로 증감하도록 하여 락·재시도 없이 정확성을 확보했고, Testcontainers로 실제 PostgreSQL을 띄워 4스레드 x 12라운드 동시 좋아요 48건이 모두 보존되고 카운트가 정확히 수렴하는지, 전환·취소·중복 요청까지 검증했습니다.

asyncio로 최대 20개 HTTP 요청을 동시 처리하도록 구성했지만 실제 처리량은 분당 12건에 그쳤습니다. 원인은 aiohttp 기본 DNS 리졸버가 동기 getaddrinfo를 스레드풀에서 처리해 병목이 됐던 것 — 비동기 리졸버(aiodns)와 DNS 캐시로 교체해 실질적 동시 처리를 가능하게 했고 12개/분 → 35개/분으로 개선했습니다.

초기엔 호출 횟수를 줄이려 한 프롬프트에서 약 50개 JSON 필드를 동시에 추출했는데, 출력이 길어질수록 후반부 필드 누락·정확도 저하가 발생했습니다. 대학명·국가 같은 정형 정보와 후기·생활 경험 같은 서술형 정보를 분리한 다중 프롬프트 구조로 데이터 유형별 추출 책임을 나눠 필드 누락을 줄였습니다.

토큰 refresh 실패를 전부 로그아웃으로 처리했더니, PWA 콜드 스타트 시 첫 refresh가 실패하면서 앱을 실행할 때마다 재로그인해야 하는 문제가 있었습니다. 인증이 확정적으로 실패한 경우와 네트워크·타임아웃 같은 일시적 실패를 구분하지 않은 것이 원인이었습니다. 이를 액세스 토큰 만료(401)는 먼저 refresh를 시도하고, refresh 요청 자체가 401로 실패한 경우에만 로그아웃하도록 좁혀 로그인이 불필요하게 풀리지 않도록 했습니다. 또한 refresh token이 single-use rotation이라 동시 401 요청이 각자 갱신을 호출하면 뒤늦은 요청이 이미 삭제된 토큰으로 다시 401을 받게 되므로, 단일 플래그와 대기 큐로 갱신을 한 번만 수행하도록 처리했습니다.

기존 평면망 구조에서는 모든 내부 시스템이 동일 보안 영역에 있어, 서비스 서버가 침해되면 스토리지·관리 시스템까지 접근 가능성이 있었습니다. 별도 물리 네트워크 없이 보안 영역을 분리하기 위해 VLAN + OPNsense로 서비스·관리·스토리지·IoT·로컬망을 나누고 모든 VLAN 간 통신이 방화벽 정책을 거치도록 재설계했습니다. 그 결과 서비스 장애·침해 발생 시 관리·스토리지 영역으로의 확산 범위를 제한할 수 있었습니다.

로컬 RAG(Khoj + Ollama)가 노트에 있는 내용을 찾지 못하고 일반 지식으로 답하는 문제가 있었습니다. 검색은 알맞은 참조를 모델에 넘겼지만 답변 생성 단계에서 무시되는 것을 대화 로그로 확인했고, 원인은 num_ctx가 모델에 baked되지 않아 런타임 기본값 4096으로 동작해 검색 결과 포함 프롬프트(~6K 토큰)가 잘려 참조 블록이 누락된 것이었습니다. num_ctx=16384를 모델에 baked하고 Khoj의 max_prompt_size를 그보다 낮게 맞춰 VRAM 스필 0을 확인, 동일 질문으로 해결을 검증했습니다.

벡터 검색이 정확한 용어 검색엔 약할 것이라 보고 하이브리드(BM25+벡터) 검색 도입을 검토했지만, 구현 전 근거를 확인하려 노트 작성 시 강제했던 정답셋(555개 질문/165개 노트)으로 recall@5를 측정한 결과 exact-token 0.92, semantic 0.87로 exact-token 검색이 오히려 더 강했습니다. 불필요한 구현을 하지 않기로 결정했습니다. 다만 골든셋에 bare-token 조회 케이스가 없어 별도 골든셋으로 재측정하는 과제가 남아 있습니다.