Topic
협업
지속 가능한 협업을 만드는 커뮤니케이션, 엔지니어링 문화와 팀 실천을 다룹니다.
AI 변경을 동료가 리뷰할 수 있는 PR로 쪼개기
AI가 만든 코드도 작업자가 책임질 수 있도록 범위를 줄이고, 커밋과 PR을 동료가 이해하고 검토할 수 있는 단위로 나눕니다.
AI 생산력과 엔지니어링 생산성은 같지 않다
AI 에이전트가 생산량을 높여도 복잡한 실무에는 맥락, 메모리, 판단, 좋은 동료의 자발적인 사고 확장이 왜 필요한지 살펴봅니다.
프론트오피스와 백오피스는 언제 분리해야 할까
목적, 생명주기, 기능 중복, 팀의 작업 방식과 운영 비용을 비교해 프론트오피스와 백오피스의 분리 여부를 판단합니다.
과도한 업무와 리더십 문제를 조직에 드러내기
과도한 개발 업무를 작은 단위와 공동의 증거로 가시화해 자원을 협상하고, 반복되는 리더십 문제를 맥락에 맞게 드러내는 방법을 다룹니다.
애매한 개발 경력을 정직한 면접 강점으로 바꾸는 법
전체 경력은 정직하게 유지하되 지원 역할마다 프로젝트 강조점을 바꿔, 인접 경험을 채용할 만한 근거로 만듭니다.
팀이 믿을 수 있는 최소 문서만 최신화하라
정책, 핵심 개념, 시스템 흐름과 API 계약을 소수의 신뢰할 문서로 관리하고 온보딩 피드백으로 계속 최신화합니다.
신뢰와 작은 성공으로 개발 문화를 바꾸는 법
새 조직을 먼저 이해하고 일로 신뢰를 얻은 뒤, 테스트와 정책 공유의 작은 성과를 보여 개발 문화를 확산합니다.
조직 현실까지 고려한 데이터 관계 설계
단순한 관계에서 시작하되 실제 요구사항 변경, 의사결정 습관과 일정 제약을 관찰해 데이터 관계 설계에 반영합니다.
암묵지를 살아 있는 팀 컨벤션으로 만드는 법
팀원의 머릿속에만 있는 개발 규칙을 이유와 함께 기록하고, 팀별 재정의와 리뷰·온보딩으로 살아 있게 관리합니다.
회사 규모를 넘나들며 개발자 경험의 폭을 넓히는 법
장기 목표에 맞춰 작은 조직의 넓은 책임과 큰 조직의 깊은 전문성 중 필요한 경험의 폭을 의도적으로 선택합니다.
개발 리더십은 직함을 받기 전에 시작된다
리뷰, 장애, 넓은 문제와 동료의 신뢰를 먼저 책임지며 직함이 붙기 전부터 개발 리더십을 준비하는 기준입니다.
강점과 실험으로 개발자 커리어를 설계하는 법
자신의 강점을 구조화하고 여러 개발 경험을 직접 시험하며, 막연한 포부 대신 근거로 미래 방향을 계속 고치는 방법입니다.
코드 리뷰 품질은 댓글 수보다 줄어드는 추이로 본다
자동화와 드래프트 PR로 초기에 합을 맞추고, 공통 규칙이 자리 잡으며 반복 피드백이 줄어드는지를 확인합니다.
긴 레거시 개편을 작은 배포로 나누는 법
지치는 레거시 개편을 작은 개발·검증·배포로 나눠 빠르게 피드백을 얻고 완벽주의의 함정을 피하는 방법입니다.
QA 전달 전에 개발자가 먼저 검증해야 하는 이유
QA 전달 전 개발자가 정상 동작을 검증해 반복 수정 비용을 줄이고 QA가 경계 조건과 제품 품질에 집중하도록 만드는 방법입니다.
새 프로그래밍 언어 도입의 전체 비용을 계산하는 법
기술 적합성만 보지 않고 채용, 학습, 관측성, 공통 라이브러리, 통합과 유지보수 비용으로 새 언어 도입을 판단합니다.
도메인 지식을 실무 문제 해결로 증명하는 법
운영, 정책과 부서 간 문제에서 도메인 지식을 쌓고 용어가 아니라 실제 판단과 해결 과정으로 역량을 증명하는 방법을 다룹니다.
애자일은 문서화를 하지 말라는 뜻이 아니다
애자일을 문서화 거부의 핑계로 삼지 않고 팀의 연속성, 보안, 규제와 운영에 필요한 문서를 판단하는 기준을 다룹니다.
회사가 아닌 개발자가 자신의 성장을 책임지는 법
회사, 책, 프로젝트와 커뮤니티의 경험을 자기 판단으로 바꾸며 개발자 성장을 스스로 책임지는 관점을 다룹니다.
시니어 개발자가 다음 개발자에게 남겨야 할 유산
연차가 아니라 유지보수 가능한 코드, 테스트, 가이드와 팀의 지속가능성으로 시니어의 책임을 살펴봅니다.
개발자 성장은 맡은 일을 끝내는 데서 시작한다
최소 품질선을 지키며 가치 있는 일을 완수하고, 이후 리팩터링과 학습으로 다음 성장을 준비하는 태도를 다룹니다.
아키텍처 규칙 자동화보다 팀의 판단이 먼저다
레이어 규칙 자동화를 리뷰 여력, 저장소 규모, 개발자 성장, 팀의 아키텍처 토론과 함께 판단합니다.
바꾸기 전에 먼저 팀의 사람이 되어라
제때 묻고 진행 상황을 공유하며 빠르게 리뷰받고, 신뢰를 쌓은 뒤 근거 있는 작은 변화로 새 개발팀에 적응하는 방법을 다룬다.
운영 이슈를 팀의 공통 도메인 지식으로 바꾸는 법
운영 이슈 리뷰, 작업 기록, 개념도, 운영 교대를 활용해 소프트웨어 팀의 도메인 지식 격차를 줄이는 방법을 다룬다.
의견보다 작은 실험으로 기술적 설득을 시작하라
제안이 막힌 이유를 진단하고, 작은 증명과 내 근거, 상대 논리의 이해를 준비하며, 새 기술 도입은 회사가 부담할 위험으로 다루는 방법입니다.
Git 이력은 개인 작업일지가 아니라 팀의 자산입니다
커밋을 다듬기 전에 작업부터 나누고, 동료가 검토하기 좋은 PR과 다음 사람이 변경 이유를 추적하고 릴리스를 복구할 수 있는 이력을 남깁니다.
만든 개발자가 떠나도 살아남는 소프트웨어
좋은 회사 소프트웨어는 부채를 줄이고 팀의 운영 능력에 맞으며, 처음 만든 개발자가 떠난 뒤에도 이해하고 고칠 수 있어야 합니다.
개발 용어보다 자기 생각과 운영 경험을 선택하기
이론과 패턴은 유용한 참고 자료지만, 개발자는 코드와 트레이드오프, 운영 결과를 자기 언어로 설명할 수 있어야 합니다.