튼튼발자 개발 성장기🏋️

아주 예전에는 쇼핑몰에서 며칠 있다가 쿠폰 알림이 와도 그런가 보다 했는데, 이 블로그 글을 읽고 나니까 이제는 실시간으로 맞춤 알림이 오지 않으면 뭔가 이상하다고 느끼게 된 이유를 알겠다. 요즘 사용자들은 서비스에 더 민감하고 빠른 반응을 기대하는 것 같다. 그래서 이 글에서 강조하고 있는 ODI의 한계와 CDC로 마이그레이션하는 과정이 재미졌다. 나도 2년 전에 Kafka CDC 기반으로 데이터베이스 싱크를 맞춘 경험이 있는데, 그 때 삽질(?)했던게 새록새록 떠올랐다.CDC와 OGG, Kafka 조합의 의미나도 데이터 동기화 프로젝트를 했던 적이 있었는데 역시 배치는 데이터 일관성 맞추기가 참 힘들었고 사용자의 행동이 서비스에 바로바로 반영이 안 돼서 불편한 부분이 존재한다. 그런데 여기선 OGG로..

오늘은 올리브영 기술 블로그에서 소개된 자체 sLLM 구축기를 읽고 느낀 점을 자유롭게 적어보려고 한다.나는 작년 4분기에 비슷한 구축기를 시도했었다. 팀 내에서 사용할 Ollama를 구축했었고 그 뒤에 여러 요청사항을 통해 vLLM을 새로 구축하였다. 이와 같은 경험을 했던 터라, 제목만 보고서도 호기심이 자극되었다.소형 LLM, 진짜 실용의 길을 찾다요즘 LLM이 핫하긴 한데, 대부분 서비스들은 상용 API나 엄청 비싼 GPU 자원을 쓰는 구조가 많다.그런데 올리브영 팀은 Tesla T4 16GB, 그러니까 렌탈비도 저렴하고 진입장벽이 낮은 하드웨어 환경 하나로 95% 상용 품질을 만들어냈다.LLM은 거대한 리소스가 필요하다고만 생각했었는데, 작은 모델과 현장 맞춤화로 실제 서비스까지 연결되는 과정을..

오늘은 올리브영의 오늘드림 서비스 관련 백엔드 개발 블로그를 읽었다. 일단 당일배송, 심지어 1시간 이내 도착까지 목표로 한다는 점에서 굉장히 빠른 라이프스타일의 변화를 체감할 수 있었다. 사용자 입장에서는 간단한 버튼 클릭 한 번이지만, 그 뒤편에서는 수많은 시스템과 API가 실시간으로 연동되는 게 인상적이다.API 연동과 장애처리, 작은 디테일올리브영이 여러 배달대행사와 연동하면서 각각 다른 API를 통합해 관리 효율성을 높였다는 점이 크게 와닿았다. 예전에 나도 정산 ERP 시스템을 구축할 때 여러 파트너사 API를 다뤄본 적 있는데, 파트너마다 규격과 로직이 다르면 관리 난이도가 기하급수적으로 올라가는 것을 체감한 적이 있다. 기능 한 번 고치면 여러 군데 다 뜯어야 하니, 이걸 하나로 묶는 게 ..

오늘은 당근페이팀의 백엔드 아키텍처 변화 과정을 다룬 긴 블로그 글을 읽어봤다. 사실 나 같은 백엔드 개발자라면 한 번쯤 "지금 우리가 쓰는 구조가 진짜 최선인가?"라는 고민할 때가 있다. 심지어 나는 첫 회사가 PG사였기 때문에 더더욱 호기심이 생겼다. 이 글은 실제 도메인의 빠른 성장과 아키텍처 변천사가 확실하게 묘사되어 있어서 공감도 되고 배울 점도 많았다.계층형 -> 헥사고날 -> 클린 아키텍처기반의 모노레포로나는 솔직히 아키텍처가 비즈니스 성장과 팀의 규모 변화에 따라 명확하게 진화했다는 점이 흥미로웠다. 단순한 계층형 구조로 시작해서 업무와 팀의 확장에 따라 헥사고날 아키텍처 도입, 이후 클린 아키텍처와 모노레포 전략까지 도달한 과정이 디테일하게 적혀 있어서 너무 좋았다. 흔히들 '우리 서비스..

오늘 읽은 토스페이먼츠의 `수천 개의 API/BATCH 서버를 하나의 설정 체계로 관리하기`는 꽤나 인상적이었다. 인프라와 운영 자동화에 관심이 많아서 예전부터 설정 관리나 대규모 환경에서 발생하는 문제와 패턴에 대해 고민했었던 내게는 공감가는 부분과 아직 잘 모르는 부분이 동시에 있었던 것 같다.설정 관리는 왜 중요한가?나는 현업에서 조차 적은 서버 수를 다룰 때에는 복붙으로도 그럭저럭 돌아가는 게 현실이라고 느꼈다. 근데, 글에서처럼 2000개, 3000개, 심지어 그 이상이 되면 오타 하나가 엄청난 서비스 장애로 이어질 수 있다는 점은 너무 무섭고 현실적인 경고였다. 엄청난 금액의 트랜잭션이 실리는 환경에서는 작은 실수가 수십억, 수백억의 돈을 날릴 수도 있다는 점에서, "설정도 코드 개발처럼 바라..

요기요 채널링 서비스, 생각보다 훨씬 복잡하고 멋지다!예전에는 그냥 카카오톡이나 G마켓 같은 데서 요기요로 주문이 되는 게 무슨 “딥 링크” 정도로 시스템이 돌아가는 줄 알았다. 그런데 실제로 이걸 위해 “채널링 서비스”라는 별도 마이크로서비스 레이어가 존재하고, 그걸 위해 API Gateway 패턴부터 파트너별 기능 제어, 캐싱/장애 관리까지 신경 쓴다는 걸 보니, 확실히 스케일 있는 기업의 백엔드 아키텍처는 차원이 다르다고 느꼈다.API Gateway 패턴과 기능 분리의 중요성API Gateway를 단순 라우팅 정도로만 생각하기 쉬운데, 이 글에서처럼 “보안+인증+파트너별 기능 제어+캐싱+장애 관리”까지 담당한다는 점이 인상적이었다. 특히, 파트너 요구사항이 다 다르니까 내부 MS(마이크로서비스)엔 ..

내가 느낀 레저 채널링 구조의 핵심 가치블로그 글을 읽으면서 일단 “채널링”이라는 용어가 신선하게 다가왔다. 평소엔 티켓을 샀을 때 문자나 QR이 어디서 오는지 신경도 안 썼는데, 알고 보면 그 뒤에 이렇게 복잡한 구조와 시스템이 있다는 게 재미있었다.특히 NOL이 ‘중재’ 역할을 하면서 백엔드에서 이 모든 복잡도를 담당하고 있다는 점이 인상적이었다. 한마디로, 현장이나 소비자 입장에서는 정말 단순하게 보이지만, 실제로는 API 연동, 실시간 재고 동기화, 표준상품 관리 등 수많은 뒷단 로직이 맞물려 돌아간다는 게 참 대단하게 느껴진다.채널링 구조의 장점과 중요성에 대한 생각효율성과 확장성: 대형 커머스(쿠팡, 네이버 등)와 개별 레저 시설이 직접 여러 번 연동하는 대신, NOL이 한 번만 연결에 집중해..

우아한형제들 기술블로그에서 "AI와 함께하는 테스트 자동화: 플러그인 개발기"를 보았다. 평소에 테스트 코드 자동화, 그리고 AI가 개발 실무에서 어떤 역할을 할 수 있을지에 대해서 많이 궁금했던 탓인지 재밌게 보았다.AI 자동화의 장점과 마주친 한계AI, 특히 Amazon Q, Copilot 같은 도구들을 이용해 테스트 코드를 자동 생성하는 건 업무 효율 측면에서 정말 매력적으로 보인다. 단순히 코드 몇 줄을 대신 써주는 게 아니라, 팀 컨벤션까지 반영해서 실제로 돌아가는 테스트 코드를 빠르게 만들어준다는 점이 참 고무적이다.하지만 역시 현실은 만만치 않다는 게 느껴졌다. 100% 자동화의 환상은 생각보다 쉽게 깨진다고 느꼈다. 클래스 의존성, 멀티모듈 구조, 비슷한 클래스명, 누락되는 엣지케이스 등 ..