2026/04 16

"잘 쉰다"는 것의 의미

무사히 배포를 마치고, 아주 잠깐의 여유를 가진다. 돌이켜보면, 나는 항상 무언가를 결정하고 있었다.이 방식이 맞는지, 저 방향이 타당한지, 이 사람의 제안을 따를지 말지. 문제는 이 결정들이 전부 내가 원해서 한 결정이 아니라는 것이다.판단의 시야가 좁아지는 문제일을 하다 보면 장벽을 느끼는 순간이 있다. 누군가 "이걸 하자"고 한다.하지만 난 힘들다.그래서 성취감을 느끼고 싶고, 뛰어난 결과를 낼 수 있는 선택지만을 밀어붙인다. 이러한 논리적인 기준은 흔들리지 않기 때문에, 자꾸 그쪽으로만 생각하게 된다. 기존에는 같이 하는 사람과 "왜 이걸 해야 하는지"에 대한 Sync를 충분히 맞추고 시작했다.그래서 그걸 기준으로 판단할 수 있었다. 현재는 다르다.내 의견을 설득할 시간이 없어 빠르게 다수결로 결..

동물원 - 어린이대공원 2, 중랑천

늦은 시간에 글을 올린다.근거는 이걸 보지 않으면 내일(오늘)의 일을 버틸 수 없기 때문. ㅋㅋ 지치지 말고 쉬면서 힘내보자.리프레쉬를 하지 않으면 생각이 좁아지니깐. "자신들만 올라올 수 있는 안전한 곳"에 모여있는 원숭이들.이때 좀 피곤해서 여러 잡생각이 들었는데,이내 생각을 접고 즐겼다. 난 쌈디같은 사람들의 성격이 참 좋다.너무 무거워져서 정신을 못차릴 때, 좀 가볍게, 행복해지게 만들어주는 이 감각.항상 큰 위로가 되어준다. 그러곤 중랑천을 갔다.

개인적 공간 2026.04.07

간섭이 아닌 시스템으로 관리하기

일반적으로, 난 모든 걸 문제 관점으로 확인한다.그래서 이 사람이 이 문제를 해결 가능한 사람인가?그래서 할 수 있는가 없는가?약속과 신뢰, 보고 체계를 잘 지키는가?마치 사람과 사람이 아닌, 로봇과 로봇으로 본다."돈 받고 일하는거면 문제에 집중해야지." 그렇게 믿지 못하는 사람이 있으면, 끝까지 파고들어 그 문제를 대신 해결해 버린다. 문제는 깊게 간섭하면 해결할 수 있다. 그런데 사람은 아니다.문제는 생물이 아니기에, 파고 든다고 "진짜 문제가 되는 원인"과 그 "영향 범위"가 능동적으로 무언가를 하려 하지는 않는다.그래서 마음껏 파고들어도 문제가 없다.사람은 생물이기에, 문제가 되는 원인을 숨기려 하고, 기존 문제를 다른 책임으로 옮긴다.이는 문제 해결을 늦추고, 더 큰 비효율을 만든다.명백히, ..

2026년 4월 1주차 회고

감사가 무너지면 꾸준함이 무너진다.조급해지기 전에, 대안을 찾기전에, 충분히 감사했나?이번 주의 상황에 대한 감사배포 프로세스를 타고 있음에 감사다들 열심히 해줌에 감사이번 주의 타인에 대한 감사A2: 언제든 바보같은 질문을 해도 잘 받아 주심에 감사B2"바보 같은 질문"에 대한 정당성을 부여해 주심에 감사"잘 동작하는" 프로세스와 효율을 깨는 것에 의미를 부여해 주심에 감사 A4: 사람이라는 새로운 관점을 제공해 줌에 감사B3: 내가 마이크로매니징을 하고 있을 가능성을 제공해줌에 감사C3: 나의 비언어적 소통의 문제점을 짚어줌에 감사항상 무언가를 수행하기.현재 수행하고 있는 구체적인 전술이 무엇인지 정리데이터 기반 전술 평가전략이 쌓이면, 실현 가능성에 대한 불안이 쌓인다. 결국은 전술이다.체계적인 상..

백엔드 개발자의 의사결정 티어: 어디에 고민을 쏟을 것인가

개발은 코딩이 아니라 의사결정의 연속이다. 변수명을 뭘로 할지, DB를 뭘 쓸지, API를 어떻게 설계할지.하루에도 수십 번의 선택이 쌓여서 하나의 시스템이 된다.그런데 이 선택들이 전부 같은 무게를 가지는 건 아니다.어떤 결정은 한번 내리면 2년 동안 팀 전체를 옥죄고, 어떤 결정은 내일 당장 뒤집어도 아무도 모른다. 문제는 많은 개발자들이 이 무게를 구분하지 못한다는 것이다.가벼운 결정에 이틀을 쓰고, 무거운 결정을 점심시간에 "일단 이거로 가죠" 하고 넘긴다.이 감각의 부재가 기술 부채의 진짜 원인이다. 그래서 백엔드 의사결정을 네 단계로 나누고, 각각에 얼마만큼의 에너지를 쓰는 것이 적정한지 이야기해보려 한다.Tier 1. 되돌릴 수 없는 결정어떤 결정들인가시스템의 뼈대에 해당하는 결정들이다. 잘..

테이블은 어디에 둘 것인가 - 객체의 책임 분리와 DB 배치 기준

들어가며새로운 도메인 개념이 등장했을 때, 개발자가 가장 먼저 마주하는 질문이 있다."이 테이블, 어느 DB에 만들지?" 얼핏 단순해 보이는 이 질문은, 사실 객체의 책임을 어디까지로 볼 것인가라는 설계 판단 그 자체다. 그리고 이 판단의 근거는 놀랍게도 코드나 ERD가 아니라, 비즈니스가 그 개념을 어떤 맥락에서 변경하고 싶어 하는가에 있다.상황: "단백질 초코바"는 어디에 속하는가기존 시스템에 두 개의 데이터베이스가 있다고 가정하자.DB관리 대상핵심 관심사식료품 DB과자, 음료, 초콜릿 등맛, 용량, 유통기한, 원재료영양제 DB비타민, 유산균, 오메가3 등성분 함량, 일일 권장량, 인증어느 날, PM이 말한다."단백질 초코바 상품을 새로 관리해야 해요."단백질 초코바. 이름을 뜯어보면 두 세계의 언어..