서비스 출시 준비 중 발견한 치명적인 문제점 지난 시간 에 이어 sleuth의 백엔드 서버(FastAPI & Cloud Run) 로직을 프로덕션 환경을 위해 고도화하는 작업에 집중하고 있다. 평소처럼 로컬 환경에서 새로운 기능을 테스트해 보니 매끄럽게 잘 동작하기에, 큰 고민 없이 main 브랜치에 코드를 직접 푸시하고 배포를 진행했다. 팀에 개발을 담당하는 인력이 많이 없기도 하고, 백엔드 서버를 지금은 혼자 구축하고 있기에 편의를…
지난 글들에서는 Sleuth의 코어 로직을 클라이언트에서 분리하여 FastAPI로 백엔드를 구축하고, 이를 GCP Cloud Run이라는 서버리스 인프라에 안착시킨 과정을 정리했다. (Cloud Run의 Scale-to-Zero와 콜드 스타트 최적화에 대한 내용은 이전 포스팅 을 참고하길 바란다.) 내부 아키텍처가 갖추어졌으니, 이제 실제 운영 환경의 쏟아지는 트래픽을 견뎌낼 수 있는지 검증할 차례다. 하지만 테스트를 시작하자마자 코드가 아닌…
앞서 다룬 FastAPI 는 LLM serving을 최우선 목표로 삼은 서비스에서 파이썬의 AI 생태계를 완전히 활용할 수 있다는 점에서 최적의 기술이었다. 코드가 준비되었으니 다음은 '이 서버를 어디에 띄울 것인가'라는 물리적인 인프라 고민으로 넘어갈 차례다. 이 챕터에서는 FastAPI 기반의 Sleuth 백엔드가 어떻게 클라우드 네이티브의 이점을 활용할 수 있었는지 정리해보고자 한다. Cloud Run과 Scale-to-Z…
Firebase Storage의 편리함 속에 숨겨진 Latency 개발 중인 프로덕트에서 이미지 로딩 속도가 눈에 띄게 느리다는 것을 발견했다. 사실 처음 원격 파일 저장소를 활용할 때도 "왜 이렇게 로딩 속도가 느릴까" 생각은 하고 있었지만 지금껏 미뤄오다 드디어 해결하고자 한다. (연구에 따르면 지연시간이 1초 증가할 때마다 이탈률이 무려 10% 증가 한다고...!) 네트워크 탭을 열어 프로파일링을 해보니, 이미지 한 장…
창업을 준비하며 AI 기반의 인터랙티브 추리 게임 'Sleuth(슬루스)'를 개발하고 있다. 유저가 용의자와 직접 대화를 나누며 단서를 찾아내는 것이 핵심 코어 로직이다 보니, 자연스럽게 LLM(거대 언어 모델)과의 통신이 서비스의 척추 역할을 하게 되었다. 초기 프로토타입에서는 개발 속도를 위해 클라이언트(프론트엔드)에서 직접 API를 호출하는 방식을 택했었다. 당장의 결과물은 눈에 보였지만, 게임의 룰이 복잡해지고 출시가 다…
물리적 거리라는 장벽 속 협업에 대한 고민 지난 회고 의 마지막 부분에서 언급하였듯, 1년 동안 팀을 이끌어가며 가장 큰 고민 중 하나는 '팀의 Alignment'이었다. 우리 팀원들은 모두 물리적으로 떨어져 작업한다. 각자의 공간에서 몰입하는 것도 좋지만, 서로가 지금 무엇을 고민하는지, 어떤 작업을 하고 있는지 실시간으로 체감하기 어렵다는 점이 늘 발목을 잡았다. (학교의 창업 사무실에 있으면서 다른 팀들이 옆에서 곧바로 …
2025년 회고, 끊임없이 Goin' Up, up, up 했던 순간들 어느덧 2025년이 얼마 남지 않았다. 어째 매년 시간이 점점 빠르게 흐르는 기분인데, 1년 전의 나보다 훨씬 성장한 기분이라 느낌이 다르다. 항상 블로그를 시험 공부용, 정보 전달용으로 작성해왔지만 이번만큼은 내 경험을 온전히 반추해보고자 한다. 올해 있었던, 해왔던 일들을 정리해보면 크게 창업 과 학업 으로 나눌 수 있다. 세부적으로 보면 1년 동안 이렇게 많은…
Application Layer, 인터넷 세상은 어떻게 소통할까 TCP/IP라는 튼튼한 도로와 배송 시스템을 이해하고 나니, 이제 그 위를 달리는 '화물'의 정체가 궁금해졌다. 우리가 매일 마주하는 인터넷 세상은 크게 세 가지 축으로 움직인다. 정보를 탐색하고 보여주는 HTTP(웹) , 비동기적으로 소식을 전하는 Email(이메일) , 그리고 복잡한 숫자 주소 대신 친숙한 이름을 쓰게 해주는 DNS(도메인 시스템) 이다. 오…
전송 계층, 호스트를 넘어, 정확한 프로세스에 데이터를 전달하는 법 지난번에 우리는 Network layer(IP)에 대해 깊이 파고들었다. 수많은 라우터를 거쳐 패킷이 목적지 호스트(컴퓨터)에 도착하는 과정은 여러 물류센터를 거쳐 택배가 아파트 단지 앞까지 도착하는 것과 같았다. 하지만 여기서 이런 의문이 든다. "아파트 단지(IP)까지 도착한 건 알겠는데, 이 패킷이 101동 202호의 철수(특정 앱)에게 가야 하는지, 505호…
디스크의 물리적 한계를 극복하는 순차 쓰기 전략 지난번에 FFS(Fast File System) 를 통해 디스크의 물리적 구조(Cylinder Group)를 고려한 배치가 성능을 어떻게 개선하는지 확인했다. 하지만 여전히 해결되지 않은 문제가 있다. "데이터를 덮어쓴다(Update-in-place)"는 기존의 방식은 필연적으로 탐색 시간(Seek Time) 과 회전 지연(Rotational Latency) 을 유발한다. …
파일 시스템의 Persistence 우리가 프로그램을 사용할 때 가장 아찔한 순간은 저장하지 않았는데 갑자기 프로세스가 죽어버리는 상황일 것이다. 마찬가지로 OS에서 데이터를 저장하는 도중에 전원 플러그를 뽑으면 어떻게 될까? 메모리(RAM)에 있는 데이터가 날아가는 건 당연하지만, 하드 디스크에 쓰고 있던 데이터마저 깨져버린다면? 파일 시스템은 그 거대한 모순을 어떻게 견뎌내는 걸까. 오늘은 파일 시스템의 영속성(Persistence)을 …
파일 시스템의 성능을 높이자 지난번 VSFS(Very Simple File System)를 공부하며 파일 시스템의 논리적인 뼈대를 세웠다. 하지만 '구현 가능하다'는 것과 '잘 동작한다'는 것은 완전히 다른 문제다. 초기 유닉스 파일 시스템은 단순했지만, 성능은 처참했다. 디스크를 마치 RAM처럼 임의 접근(Random Access) 가능한 장치로 취급했기 때문이다. (Random Access가 안되는 건 지난번…
파일 시스템, 디스크에 데이터를 구조화하는 방법 매일 코드를 짜면서 수없이 많은 파일을 생성하고 저장한다. open() , write() 시스템 콜을 호출할 때마다 하드웨어 레벨에서 어떤 일이 벌어지는지 깊게 고민해 본 적이 드물다는 생각이 들었다. 이번 계기에 파일 시스템의 구현(File System Implementation)을 파고들면서, 우리가 당연하게 여기는 '파일 저장'이라는 행위가 실제 디스크 상에서 어떻게 구조화…
Storage Virtualization 지난 시간까지 우리는 HDD와 SSD라는 하드웨어 자체에 대해 알아보았다. 회전하는 플래터, 전자를 가두는 셀, 그리고 이들을 제어하기 위한 하드웨어적인 컨트롤러들의 이야기였다. 하지만 우리가 실제로 컴퓨터를 사용할 때 "3번 트랙 5번 섹터에 데이터를 써줘"라고 명령하지 않는다. 대신 "보고서.docx를 저장해 줘"라고 말한다. 여기서 나오는 개념이 바로 운영체제…
SSD, 빠르지만 존재하는 의외의 단점 SSD(Solid State Drive)와 관련한 이번 글에서, SSD가 우리가 평소에 자주 사용하는 전자기기들(스마트폰, 태블릿, 노트북, ...)에 들어가는 저장장치이지만 모르고 있던 진실에 대해 파헤쳐보고자 한다. "SSD는 하드디스크보다 빠르지만, '덮어쓰기(Overwrite)'가 안 된다는 치명적인 단점이 있다." 덮어쓰기가 안 되는데 어떻게 우리가 매일 파일을 …
컴퓨터 주변 장치들 컴퓨터 구조를 공부하다 보면, CPU나 메모리처럼 눈에 보이지 않는 전자적 신호의 흐름보다, 실제로 소리를 내며 돌아가는 하드디스크(HDD)나 키보드 같은 입출력(I/O) 장치들이 더 흥미롭게 다가올 때가 있다. 특히, "빛의 속도로 연산하는 CPU가 왜 거북이 같은 하드디스크를 기다려줘야 할까?"라는 질문은 시스템 설계자들에게 오랫동안 골치 아픈 문제였을 것이다. 오늘은 운영체제 수업에서 다룬 I/O 시…
가상 메모리의 백스테이지 지금까지 우리는 페이징과 TLB 를 통해 '메모리 가상화' 개념에 대해 알아왔다. 하지만 여기엔 치명적인 물리적 제약이 있다. 바로 RAM 용량의 한계 다. 내가 실행하려는 프로그램들의 합이 32GB인데, 내 컴퓨터의 물리 메모리가 16GB뿐이라면? OS는 이 불가능한 상황을 해결하기 위해 메모리 계층 구조의 더 아래쪽, 즉 디스크(Disk) 를 빌려오기로 했다. 당장 쓰지 않는 페이지를 디스크의 창고(…
Our website uses cookies to improve your experience. Learn more
확인