콘텐츠로 바로가기

Seongwon

  • 기술 블로그
  • 영어
  • 기록
  • About
  • Editorial
  • 문의
Seongwon

소프트웨어 엔지니어의 기록

Categories

  • 개인 기록(Personal)4
    • 계획(Plan)0
    • 분석(Analysis)0
    • 일기(Diary)3
    • 작업 일지(Work Log)0
  • 기술 블로그113
    • AI13
      • 결과 판단(Evaluation)3
    • Architecture3
    • Backend37
      • 설계 판단13
    • DevOps6
    • Games0
    • Infra17
  • 기타0
  • 성과4
    • 아키텍처 의사결정 (ADR)4
  • 영어(English)48
    • 개발 영어 (Developer English)13
    • 어원(Etymology)16
  • 자기계발 (Growth)8
    • 독서 (Reading)2
    • 방향과 가치 (Direction & Values)3
  • AI, 아키텍처 의사결정 (ADR)

    [AI 음성 상담] 데이터 플로우 5단계 — 각 단계의 실패 모드와 fallback

    결론 먼저 — 5단계 × 실패 모드 × 복구 가능성 단계 핵심 동작 대표 실패 복구 1. 사용자 요청 인증·세션 토큰 발급 토큰 만료 /…

    2026.05.09
    정성원
  • AI, 결과 판단(Evaluation)

    [음성 파이프라인] STT → LLM → TTS 전체 latency 분해 — 4구간 절단법

    결론 먼저 — 음성 파이프라인 latency는 4구간으로 쪼개야 줄일 수 있다 구간 이름 대표 단축 전략 1 VAD → STT 종료 (사용자 발화 끝 인식)…

    2026.05.09
    정성원
  • 어원(Etymology), 영어(English)

    [어원] permanent — per(끝까지) + man(머무르다) + ent(~하는) = 영구적인

    permanent 는 한국어 번역으로는 “영구적인” 한 줄이지만, storage 공식 문서 에서 만나 보면 결이 다르다 — PersistentDisk / persistent storage 가 permanent 와 같은 man-…

    2026.05.08
    정성원
  • AI, 기술 블로그

    [문서 탐지] 시험지 OCR에서 TP/FP/FN 계산 기준 — 전체 객체 수 보존 관점

    결론 — “전체 객체 수 보존”이 핵심 기준이다 시험지 OCR에서 TP/FP/FN을 계산할 때 가장 중요한 원칙은: “총합 문제 수가 일치되어야 정확하다” 부분 검출을 성공으로 인정하고,…

    2026.05.08
    정성원
  • Backend, 설계 판단

    [설계 판단] RPC를 언제 쓰는가 — 라이브러리 통합 시 7가지 결정 기준

    RPC를 언제 쓰는가, 그리고 이 프로젝트는 왜 RPC를 쓰는가 이 글은 두 가지를 정리한다. RPC가 무엇이고 어떤 문제를 해결하기 위한 도구인가 detection-mvp/image-extract가 PDFium 호출 방식으로…

    2026.05.07
    정성원
  • 어원(Etymology), 영어(English)

    [어원] transfigure — trans(넘어) + figure(형태) = 완전히 변모시키다

    transfigure 의 사전 정의는 “완전히 변모시키다”. 그런데 그 뒤에 숨은 형태소/어원 이미지가 더 흥미로워서 메모. 책 · 종교·문학 텍스트 에서 만났을 때 transfiguration 의 종교·문학적…

    2026.05.07
    정성원
  • 영어(English)

    더 잘 이해하고 싶을 때 — 천천히 / 다시 설명 / 이해 확인 / 발음

    더 잘 이해하고 싶을 때 — 천천히 / 다시 설명 / 이해 확인 / 발음 상대방 말을 놓친 건 아닌데, 좀 더 정확하게 이해하고 싶을…

    2026.04.30
    정성원
  • 일기(Diary)

    결과 중심에서 문제 중심으로 — ‘내가 이 문제를 더 나은 구조로 만들 수 있는가’

    내가 잘난 점을 생각할 수록 고통은 줄어들고 성장이 더뎌진다는 걸 알게 되었다. 그러면서 본질에 집중하기로 결심했다. 나는 이 문제를 더 나은 구조로 만들 수 있는가?…

    2026.04.29
    정성원
이전 페이지
1 … 7 8 9

Popular

  1. 1[아키텍처 #3] Event-Driven Architecture(EDA) — 브로커로 서비스를 느슨하게 잇기
  2. 2[백엔드 운영] 커넥션 풀이 막히는 순간을 숫자로 읽는 법 — Hikari와 pgxpool은 같은 고갈을 다르게 보여준다
  3. 3[백엔드 운영] 커넥션을 얼마나 기다리고 얼마나 오래 살릴까 — timeout과 lifetime을 Hikari·pgxpool로 비교
  4. 4[백엔드 운영] Hikari가 공짜로 해주던 것 — 커넥션 누수 추적을 직접 만들어 보다
  5. 5[백엔드 운영] 긴 작업이 짧은 요청을 잡아먹을 때 — 풀 격리와 읽기/쓰기 분리

Recent

  • [아키텍처 #3] Event-Driven Architecture(EDA) — 브로커로 서비스를 느슨하게 잇기2026.07.18
  • [아키텍처 #2] Hexagonal(Ports & Adapters)와 MessageQueue — Consumer·Publisher는 어느 레이어에?2026.07.18
  • [아키텍처 #1] Go로 이해하는 Clean Architecture — 의존성 규칙과 레이어2026.07.17
  • [OKE 인프라 학습 시리즈] 상시 가동 OKE에서 채팅 싱크 테스트 — 자기 에코 제거와 게스트끼리 붙여 보기2026.07.17
  • [홈랩] 리눅스 배포판, 뭐가 다른가 — Debian·Ubuntu·Mint·RHEL 계열 비교 분석2026.07.16

Tags

architecture backend chat connection-pool database developer-english DevOps etymology GKE golang hikaricp infra Ingress kubernetes latin oke performance pgxpool rabbitmq spring sre webrtc websocket 시리즈-쿠버네티스

Visitors

Today27
Total8,426

Calendar

2026 7월
월 화 수 목 금 토 일
 12345
6789101112
13141516171819
20212223242526
2728293031  
« 6월    
LessMore

© 2026 Seongwon. All rights reserved.

About · 개인정보처리방침 · 이용약관 · 문의
Top ↑

Designed with WordPress · Theme by Seongwon