손가든 개발일지

오랜만에 블로그를 쓴다. 어제 막 최종 지원 결과를 받게되서 지원 기간동안 느끼고 얻은 모든 감정들과 후회,그리고 얻어가는 경험들을 남기기 위해 이번 글을 쓰게 됐.이직을 생각하게 된 배경올해 초, 조금 더 고객과 맞닿아 있는 계층이 내게 더 동기부여가 된다고 결론을 내리고,SW의 어플리케이션 계층을 구현할 수 있는 솔루션 SW 포지션으로 이직했다. 회사 초반엔 목적성이 뚜하고, 몰입할 수 있는 프로젝트성 개발을 하는것 자체가 기뻤다.또한 여러 패키징된 라이브러리, 프레임워크 기술들을 새로이, 다양하게 경험하면서 만족스러운 커리어를 기대했다. 하지만 AI로 바뀌어가고 있는 코딩의 세계는 내 예상보다 더 빠르게 내 업무에 영향을 끼쳤다. 회사에서 AI를 적극 활용하는 방식으로 개발 프로세스가 바뀌었다.나 ..

AI 코딩 도구를 쓰다 보면 반드시 마주치는 벽이 있다.오늘 열심히 설명하고 설계한 내용을 내일 다시 처음부터 설명해야 한다는 것. 이 글은 그 문제를 실제 프로젝트에서 해결한 방법을 공유한다.이 글에서 얻어갈 것: CLAUDE.md 기반 컨텍스트 관리 구조, 세션 프로토콜 설계, 실제 운영 경험담.목차AI가 기억을 잃는다는 문제해결 전략 — 프로젝트 문서화로 AI를 "온보딩"하기파일 구조 설계세션 프로토콜 — /start와 /checkpoint파일 로딩 가이드 — 항상 전부 읽지 않는다실제 운영 후기마무리1. AI가 기억을 잃는다는 문제나는 약 3개월 전부터 Claude를 실제 프로젝트의 코딩 파트너로 사용하고 있다. 사용하는 시스템은 인터페이스 관리 문서(ICD)를 웹으로 편집·관리하는 내부 SaaS..

지난 포스팅 보고 오기LiveKit Python SDK로 STT 봇 서버 만들기 (1) — 오디오 스트림 포워딩부터 Docker 자동화까지목차들어가며버그 1 — 방 종료·재생성 동시 발생 시 인메모리 Race Condition버그 2 — STT 봇 오인 재접속버그 3 — 방 종료 후에도 봇이 남아 있는 좀비 봇마무리1. 들어가며초기 구현이 끝나고 실제로 부하 테스트를 돌려보니 눈에 보이지 않던 버그들이 하나씩 드러났다. 공통점이 있었다.하나씩 단독으로 실행하면 멀쩡하고, livekit 부하 테스트 시뮬레이터를 통해 동시에 여러 방이 빠르게 생성·삭제될 때만 재현됐다. 이 글에서는 그 과정에서 만난 버그 세 가지와 각각의 해결 방법을 공유한다.2. 버그 1 — 방 종료·재생성 동시 발생 시 인메모리 Rac..

목차왜 STT가 필요했나전체 구조 한눈에 보기봇 본체 구현 — bot.pySTT 인터페이스 설계 — stt_interface.py봇 생명주기 관리 서버 — manager.pyDocker 분리 운영과 Makefile 자동화결과 및 마무리1. 왜 STT가 필요했나 실시간 음성 통화 서비스를 운영하다 보면, 통화 자체가 끝나는 순간 그 안에서 오간 맥락은 사라진다.참여자들이 논의한 결정 사항, 공유된 정보, 합의된 내용이 모두 사람의 기억에만 남는다. 여기서 STT(Speech-to-Text)를 붙이면 이야기가 달라진다. 통화 중 발화된 모든 내용이 텍스트 스트림으로 변환되면, 이를 회의 요약, 키워드 추출, 액션 아이템 자동 분류와 같은 후처리 파이프라인에 연결할 수 있다.단순히 "무슨 말을 했나"를 기록하..

기업용 실시간 음성 통화 기능을 WPF 데스크탑 앱에 직접 구현했다.WebRTC 기반의 LiveKit SDK와 NAudio를 조합해서 마이크 캡처부터 스피커 출력까지전체 오디오 파이프라인을 C#으로 구성한 경험을 공유한다.목차왜 LiveKit을 선택했나전체 클라이언트 구조오디오 파이프라인 흐름서비스 클래스 설계LiveKitService — 핵심 오케스트레이터LiveKitDeviceService — 하드웨어 제어AudioDeviceNotificationService — 장치 변경 감지마이크 송신 구현원격 오디오 수신 및 믹싱USB 장치 핫스왑 대응VoiceCallViewModel ↔ LiveKitService 바인딩 구조마무리왜 LiveKit을 선택했나실시간 음성 통화를 구현하는 방법은 여러 가지가 있다...

부하 테스트 도중 서버가 터졌다. 원인을 찾아가는 과정에서, 더 근본적인 문제를 마주쳤다.목차서버가 터지다RoomComposite는 뭘 하고 있었나TrackEgress는 뭐가 다른가Webhook은 믿을 수 없다신뢰성 확보 전략 3가지마무리1. 서버가 터지다실시간 음성 통화 서비스에 부하 테스트를 돌리던 중이었다. 방이 13~14개를 넘어가는 순간 CPU 사용률이 2000% 를 찍었다. 사용자들이 방에 참여하지 못하거나, 녹음이 아예 안 됐다.처음엔 API 서버 문제인 줄 알았다. 로그를 뒤져봤는데 API 서버는 멀쩡했다. 주범은 Egress 컨테이너였다.2. RoomComposite는 뭘 하고 있었나당시 구현은 RoomCompositeEgress를 쓰고 있었다. 이름처럼 "방 전체를 합성해서" 녹음하는 ..

부하 테스트 자동화 스크립트를 작성하다가 docker stats | awk & 패턴이 좀비 프로세스를 남기는 문제를 만났다.원인을 파악하고 Windows(MSYS2) 환경에 맞는 프로세스 관리 방식을 찾기까지의 과정을 정리한다.목차문제 상황원인 분석 — 파이프와 $! 의 함정Windows Git Bash의 PID 문제해결 방법 — 서브쉘 + wmic 종료최종 코드마무리문제 상황실시간 음성 서비스 인프라의 부하 테스트 스크립트에서, 컨테이너 CPU/메모리를 실시간으로 CSV에 기록하기 위해 아래 코드를 사용하고 있었다.start_stats_collection() { local out="$RESULT_DIR/phase${1}_stats.csv" echo "timestamp,container,cpu..

LiveKit 부하 테스트 자동화 파이프라인 구축기 — Phase별 Ramp-up 테스트부터 HTML 리포트까지WebRTC 인프라를 운영하다 보면 "실제로 몇 명까지 버티지?"라는 질문이 반드시 나온다.LiveKit 기반 실시간 음성 서비스의 동시 접속 한계를 검증하기 위해Phase별 Ramp-up 부하 테스트 파이프라인을 처음부터 자동화한 과정을 정리한 글이다.목차왜 자동화가 필요했나테스트 구조 설계핵심 구현 — Bash 스크립트결과 분석 — Python 리포트 자동 생성운영 중 마주친 문제들마치며1. 왜 자동화가 필요했나LiveKit SFU 위에 구축한 서비스의 서버 스펙을 결정해야 했다.단순히 "n명 접속 테스트"를 한 번 돌리는 건 의미가 없다.부하를 단계적으로 높여가며 CPU / 메모리 / 네트..

음성이 텍스트가 되기까지 — STT 변환 원리 완전 정리마이크에서 입력된 소리가 텍스트로 출력되기까지, 아날로그 신호 → PCM → WebRTC → Whisper 추론에 이르는 전 과정을 단계별로 파헤칩니다.파이프라인 한눈에 보기아날로그 음파 → ADC/PCM → 오디오 프레임 → Opus 압축 → RTP/UDP → LiveKit SDK → VAD → Whisper 추론 → 텍스트목차아날로그 → 디지털 변환 (ADC / PCM)샘플링과 나이퀴스트 정리양자화와 PCM 데이터 구조오디오 프레임과 네트워크 패킷WebRTC 오디오 파이프라인VAD — 음성 구간 검출faster-whisper 추론 프로세스용어 정리1. 아날로그 → 디지털 변환마이크로 입력되는 음성은 공기 압력의 연속적인 파동, 즉 아날로그 신호입..

오늘은 오랜만에 예전에 사내에서 세미나 했던 UWB 와 Bluetooth 기술 간의 비교 분석한 내용을 다룰 예정이다. 열정적으로 연구했고 분석했던 내용이라 회고를 위해 남긴다. 1. What is UWB?UWB는 Android 13에 처음으로 AOSP 모듈로 베타느낌으로 제공되었고, 이 이후인 Android15~16단계에서 칩셋 제조사들이 UWB를 지원하는 칩셋을 납품하면서 Device들에 점점 기능이 탑재되고 있다. 그렇다면 UWB 기술이 무엇이고 어디에 사용되는지 한번 알아보자. UWB 통신 기술은 1960년도부터 미국 국방부에서 군사용 정밀 탐사 기기에 사용되었다. 이는 1990년도부터 상용화의 얘기가 나오기 시작하면서 2002년도에 처음으로 저전력 신호 규제와 함께 상용 기술로 허용되었지만..