원칙과 융통성 균형
약 90초
갈등 상황 사례 중심
팀 규칙상 모든 코드에 리뷰가 필요했는데, 배포 당일 오후 긴급 버그가 발견됐습니다. 리뷰어가 외부 미팅 중이라 기다리면 배포 마감을 넘길 수 있는 상황이었습니다. 저는 원칙을 무시하기보다 리뷰어에게 5분 짜리 화상 통화를 요청해서 핵심 변경 부분만 빠르게 확인받았습니다. 이후 정식 리뷰 기록은 슬랙에 남겼습니다. 원칙은 깨는 게 아니라 형식을 적응시키는 것이라고 생각했기 때문입니다. 이 경험을 팀에 공유하며 긴급 경로 절차를 문서화했고, 이후 비슷한 상황에서 팀이 일관되게 대응할 수 있는 기반이 됐습니다. 이 경험을 팀에 공유한 뒤 긴급 코드 리뷰 경로가 생겼고, 이후 유사한 상황에서 팀원들이 동일하게 대응하는 걸 보면서 원칙이 운영 가능한 형태로 정착하는 과정이 중요하다는 걸 실감했습니다.
이 결의 특징
원칙과 융통성이 충돌했을 때 코드에 단일 예외를 추가한 경험에서 원칙을 깨기보다 제한된 예외를 명시하는 방식이 구조를 유지하는 방법임을 인식한 흔적이 있습니다.
이 결이 통하는 자리
원칙·융통성 충돌을 명시적 예외 추가로 설명할 수 있을 때 통합니다. 원칙 무너뜨리기보다 구조 내 예외 설계가 있는 자리에서 신뢰가 생기는 결이 보입니다.