글 목록 · 4 / 6
-
비동기 협업이 실패한 5가지 케이스
원격·비동기 협업을 시도하면서 우리 팀이 반복적으로 마주쳤던 실패 패턴 다섯 가지와 그 뒤에 바꾼 것들을 정리했다.
-
monorepo vs polyrepo — 작은 팀의 결론
3인 풀스택 팀이 monorepo와 polyrepo를 모두 써보고 내린 현실적인 결론을 공유한다.
-
사이드 프로젝트가 제품이 된 순간
취미처럼 시작했던 사이드 프로젝트가 실제 운영 서비스로 바뀌는 과정에서 우리 팀이 겪은 전환점을 돌아본다.
-
정적 사이트와 동적 페이지 — 같은 서비스에서 분리하는 기준
한 서비스 안에서 정적 사이트와 동적 페이지를 어떻게 구분하는지, 우리 팀이 실제로 적용한 기준과 그 이유를 정리했다.
-
비밀번호를 채팅에 흘렸다 — 그 후 30분 룰
자격증명이 채팅이나 로그에 노출됐을 때 우리 팀이 따르는 30분 이내 처리 절차와, 그 절차를 만들게 된 실제 경험을 공유한다.
-
신뢰 vs 권한 — 작은 팀의 보안 모델
세 명짜리 팀에서 "모두를 믿으니 모두에게 권한을"이 얼마나 위험한지, 그리고 신뢰와 권한 분리가 왜 모순이 아닌지를 정리한다.
-
type-safe 를 어디까지 강제할 것인가
타입 안전성을 코드베이스 전체에 강제하는 것이 항상 이득인지, 우리 팀이 어떤 기준으로 강도를 조절하는지를 실제 경험 기반으로 정리한다.
-
작은 팀의 retrospective — 격주에 30분
세 명이 격주로 30분짜리 회고를 꾸준히 유지하기 위해 설계한 형식과, 지키기 어려웠던 부분들을 기록한다.
-
on-call 없는 회사는 가능한가
소규모 팀이 on-call 로테이션 없이 운영하는 것이 현실적으로 가능한지 검토하고, 우리가 그 대신 선택한 접근 방식과 그 한계를 솔직하게 정리한다.
-
신규 입사자 첫 7일 체크리스트 v3
작은 풀스택 팀에 새로운 구성원이 합류했을 때 첫 7일을 어떻게 설계하는지 세 번째 버전을 공개한다. 이전 버전에서 무엇이 잘못됐는지도 함께 기록한다.
-
Postgres extension 을 도입할 때 우리가 검토하는 5가지
PostgreSQL extension을 프로덕션에 추가하기 전에 팀이 확인하는 다섯 가지 항목을 정리한다. 편의 기능 하나 때문에 운영 부담이 생기는 상황을 줄이기 위해 만든 기준이다.
-
AI 가 작성한 문서를 사람이 다시 손보는 시간 측정
AI가 생성한 기술 문서를 팀원이 검토·수정하는 데 실제로 얼마나 걸리는지 측정해보고, 생산성 주장이 어느 조건에서 맞고 어느 조건에서 틀리는지 정리한다.
-
디자인-개발 핸드오프를 줄이는 우리의 흐름
세 명이 디자이너와 개발자를 겸하는 팀에서 핸드오프 비용을 줄이기 위해 우리가 시도하고 정착시킨 실용적인 방법들을 공유한다.
-
swap 2GB 를 켰더니 일어난 변화
메모리 2GB 서버에 swap 2GB를 추가한 뒤 실제로 달라진 것들을 측정해 기록한다. 설정 한 줄이 서비스 안정성에 미치는 영향을 솔직하게 정리했다.
-
AI gateway 라는 추상 레이어
여러 LLM 공급자를 하나의 인터페이스로 통일하는 AI gateway 패턴을 도입하면서 얻은 것과 주의할 점을 정리한다.
-
tool 호출 디버깅 — 100번 중 5번 망가지는 이유
LLM tool use 파이프라인에서 간헐적 오류가 발생하는 원인을 추적하고 안정성을 높인 경험을 공유한다.
-
음성 모달리티 — 고객센터 상담 요약 실험
음성 통화 데이터를 텍스트로 변환하고 LLM 으로 요약하는 파이프라인을 실험한 과정, 그리고 예상보다 어려웠던 부분들을 기록한다.
-
cron 이 사라진 자리에 들어온 것
단순한 cron 스케줄러를 걷어내고 이벤트 기반 워크플로우로 전환한 과정과, 그 과정에서 배운 것들을 공유한다.
-
fine-tuning 은 정말 필요한가, 우리 케이스에서는
LLM fine-tuning 도입을 검토하면서 우리 팀이 실제로 따진 조건과, 결국 선택하지 않은 이유를 솔직하게 기록한다.
-
Spring Boot 와 FastAPI 사이에서 — 우리 팀의 분기점
새 서비스를 시작할 때 Spring Boot 와 FastAPI 중 무엇을 쓸지 고민했던 과정과, 그 결정을 이끈 실제 기준을 공유한다.