Study for./Engineering Culture3 SQL에 월세 내던 비즈니스 규칙, 도메인으로 이사했습니다 부제: 오늘, 비즈니스 규칙이 SQL에서 탈출한 비율이 0.03퍼센트 늘었습니다"오늘 전 세계 극심한 빈곤 상태에 있는 사람의 수가 0.01퍼센트 줄었습니다!"이 문장을 뉴스 속보로 내보내는 방송국은 없을 것이다.하지만 이 0.01퍼센트가 매일 쌓이면, 10년 뒤에는 수억 명의 삶이 달라진다.최근에 코드를 다루면서 비슷한 감각을 느끼고 있다.하루하루의 변화는 눈에 보이지 않지만,그 변화들이 모두 하나의 질문을 향해 쌓이고 있다는 감각이다.비즈니스 규칙은 어디에 살아야 하는가?서울 전셋값만큼 어려운 질문은 아니지만,잘못된 곳에 살게 두면 매달 월세를 내야 한다는 점에서는 비슷하다.쉬는 날 오후의 장애 대응, SQL과 Java를 오가며 원인을 추적하는 디버깅,"이걸 수정하면 다른 데 영향 없나요?"라는 질문.. 2026. 2. 27. 지루하고 현학적인 설계문서가 필요한 이유 슬랙 100건의 쓰레드가 알려준 것들- 급한 작업일수록 설계가 먼저였다그 긴 이야기의 시작. 대충 그 긴거..이번 주에 꽤 인상적인 경험을 했다. 한마디로 요약하면 "급한 작업일수록 설계를 먼저 해야 한다"는 것인데, 사실 이 문장은 누구나 알고 있고, 어디서든 한 번쯤은 들어봤을 이야기다. 그런데 막상 현장에서 촉박한 일정과 마주하면, 설계를 건너뛰고 코드부터 치는 자신을 발견하게 된다. 이번에 내가 딱 그랬고, 그 대가로 기획자와 나 사이에 슬랙 쓰레드 메세지 100건이 넘는 소통 괴물을 만나게 되었다.그리고 그 쓰레드 괴물을 바라보면서 이 블로그 포스팅의 아이디어를 얻었다. 이건 기회야..! 글로 남겨야만해..! 이 글은 그 경험을 돌아보면서, 비슷한 상황에서 어떤 도구와 방법론이 도움이 될 수 있.. 2026. 2. 13. Ktlint가 선명하게 코드를 핥고 있었다 Kotlin 프로젝트에서 팀 전체의 코드 품질과 커밋 규칙을 자동으로 통일하는 방법 이 글을 쓰게 된 계기부터 이야기하려고 한다.회사에서 같은 팀원분과 함께 Kotlin 스터디를 하고 있다. 그중에 프론트엔드 한 분이 계신데, 그분이 Kotlin 코드를 처음 작성하면서 자연스럽게 물어본 질문이 있었다. "Kotlin에는 ESLint 같은 거 없어?" JavaScript나 TypeScript 생태계에서 ESLint는 코드 스타일 검사와 자동 수정을 담당하는 도구인데, 프론트엔드 개발을 해본 사람이라면 프로젝트 초기 세팅에 당연히 포함시키는 도구다. 그 질문이 꽂혔다. Kotlin에도 당연히 비슷한 도구가 있는데, 정작 우리 회사 내부에서는 이런 기본 설정이 프로젝트마다 통일되어 있지 않았다.그때.. 2026. 2. 6. 이전 1 다음
