Waylog Blog

"이 커밋 왜 여기 있어요?" — 로그가 지저분해지는 순간 팀은 신뢰를 잃는다 필자가 일 평균 주문 8만 건을 처리하는 커머스 프로젝트에서 결제 모듈을 담당하던 시절, 어느 배포 이후 특정 할인 쿠폰 조합에서만 최종 결제 금액이 미세하게 틀어지는 회귀 버그가 접수된 적이 있습니다.

API는 계약이다, 그런데 우리는 왜 매번 같은 실수를 반복할까 "/v1/users"를 만들고, 에러가 나면 { error: "메시지" } 를 대충 반환하고, 나중에 필드 하나를 지웠다가 모바일 클라이언트가 크래시 나는 경험. 이건 특정 팀만의 문제가 아닙니다.

비밀번호를 없애는 일이 왜 이렇게 오래 걸렸을까 로그인 폼에 아이디와 비밀번호를 입력하는 방식은 인터넷 초기부터 지금까지 거의 변하지 않았습니다. 그동안 우리 프론트엔드 개발자들은 비밀번호 강도 검사, 2단계 인증, CAPTCHA, 로그인 시도 제한 같은 방어막을 겹겹이 쌓아 왔지만, 근본 원인인 "사용자가 매번 같은 비밀 문자열을 타이핑해서 서버에 전송한

커넥션이 많다고 다 좋은 게 아니다 애플리케이션 서버를 오토스케일링으로 늘렸는데 갑자기 데이터베이스 응답이 느려지는 상황을 겪어본 적이 있다면, 원인이 CPU나 디스크가 아니라 "커넥션 수 자체"였던 경험도 있을 것입니다.

월 800만 원짜리 API 청구서를 받아든 날 2025년 4분기, 우리 팀의 LLM API 청구액이 처음으로 800만 원을 돌파했습니다. 서비스가 성장하고 있다는 신호이기도 했지만, 동시에 "이대로 두면 스케일이 두 배가 될 때 비용도 두 배가 되는 구조"라는 사실을 직시해야 했습니다. 애플리케이션 코드를 뜯어보니 문제는 명확했습니다.

벡터 DB를 고르는 일이 왜 이렇게 어려운가 — 선택 실수가 운영비로 돌아오는 이유 필자가 속한 팀이 처음 RAG 파이프라인을 도입했을 때, 선택은 빨랐습니다. 이미 PostgreSQL을 운영 중이었고, pgvector 익스텐션 하나면 벡터 검색을 바로 붙일 수 있었기 때문입니다. 초기 문서 수 40만 건, 쿼리 QPS 20 수준에서는 완벽했습니다.

토큰은 변수 파일이 아니라 의사결정 체계다 디자인 시스템을 만들 때 색상, 간격, 폰트 크기를 변수로 분리하는 일은 비교적 쉽습니다. 어려운 부분은 시간이 지나도 그 값들이 일관된 의미를 유지하게 만드는 것입니다. 프로젝트가 커지면 임시 색상, 예외 spacing, 화면 전용 font-size가 조금씩 늘어납니다.

파인튜닝은 하고 싶은데 GPU가 없다는 딜레마 사내 도메인 특화 LLM 도입을 검토하던 2025년 말, 팀이 처음 맞닥뜨린 벽은 "7B 모델 풀 파인튜닝에 H100 4장이 필요하다"는 사실이었습니다. 클라우드 GPU 비용을 계산하는 스프레드시트가 점점 붉게 물들었고, "그냥 RAG로 갈까요?"라는 말이 슬랙에 올라왔습니다. 하지만 RAG가 만능은 아닙니다.

Date 객체가 터뜨린 버그, 한 번쯤은 겪어봤을 것이다 예약 시스템 QA를 마치고 배포한 다음 날 아침, 고객 센터에서 "3월 8일 오전 2시 30분 예약이 사라졌다"는 제보가 들어옵니다. 코드를 열어봐도 논리 자체는 멀쩡합니다. 문제는 2026년 미국 동부 시간대 DST(서머타임) 전환 순간에 있었습니다.

!important 가 무한 증식하는 순간, 뭔가 잘못된 것이다 디자인 시스템을 운영하다 보면 어느 순간 CSS 파일 전체에서 !important 가 조용히 번식해 있는 광경을 목격하게 됩니다. 처음에는 단 한 줄이었습니다. "Tailwind 유틸리티 클래스가 컴포넌트 스타일을 덮어쓰지 못하네, 일단 !important 붙이자.

LLM 보안은 왜 우리가 알던 웹 보안과 완전히 다른가 엔지니어링 팀이 처음으로 내부 RAG 챗봇을 프로덕션에 올린 것은 2025년 초였습니다. 사용자가 PDF를 업로드하면 임베딩 파이프라인을 거쳐 벡터 DB에 저장되고, 이후 대화에서 관련 청크를 꺼내 GPT-4o에 컨텍스트로 주입하는 전형적인 RAG 구조였습니다.

통합 테스트만으로는 배포 타이밍을 막기 어렵다 프론트엔드와 백엔드가 독립적으로 배포되는 팀에서는 API 변경이 가장 흔한 장애 원인 중 하나입니다.