대안없는 비판

모든 문제는 인식할 수 있는 것이 아니다. 문제는 반드시 발생해야만 인식된다.
그렇기에 문제를 인식했다는 것은, 그 자체로 책임이 수반되는 일이다.

 

대안 없는 비판은 문제를 인식한 것이 아니라, 문제 ‘자체’를 공격하는 것에 불과하다.
나 또한 개발 과정에서 수많은 문제를 겪었고, 그에 대해 비판도 했다. 하지만 늘 대안을 전제로 했다.

 

이전 글에서 인상 깊었던 두 명의 개발자에 대해 언급했었다.
그들의 공통점 중 하나는, 비판할 때 반드시 대안을 제시한다는 점이었다.
대안이 없으면 함부로 비판하지 않는다. 이것이 진정한 문제 인식자의 태도다.

 

나 역시 지금까지 글을 통해 "이건 하지 말자"고 비판할 때, 그에 상응하는 실질적 대안을 함께 제시해 왔다.
“하지 마라”는 말만 반복하는 것은 비판이 아니라 무책임한 소모다.

 

최근에는 문제를 인식하고도
“그건 내 일이 아니다. 네가 해결해라.”
하는 무책임한 태도를 자주 본다.
얼마나 몰상식하고 부끄러운 일인가.

 

문제를 인식했다면, 반드시 해결 방안도 제시해야 한다.

이것이 협업의 기본이며, 책임 있는 개발자의 태도다.

 

예를 들어, 내가 겪었던 브라우저 캐시 문제를 생각해보자.
브라우저 캐시는 GET 요청을 기준으로 동작한다. 따라서 요청 자체의 버전 관리가 필수다.

서버를 업데이트했음에도 캐시가 무효화되지 않는 경우,
응답 헤더 설정이나 URL 쿼리 파라미터가 캐시 무효화를 유도하고 있는지를 확인해야 한다.

처음에는 나 역시 이 원리를 잘 몰랐지만,
“캐시가 무효화되지 않는다”는 문제를 겪고 나서
그 메커니즘을 파악했고, 해결 방안을 찾았다.

 

이처럼 문제 → 인식 → 원인 분석 → 해결책 도출의 사이클이 있어야
비판은 생산적인 성과로 이어진다.

 

단순히 남 탓을 하거나, 내 일이 아니라는 식의 회피는
조직을 병들게 하고 협업을 망친다.

 

비판하려거든 대안을 가져라.

이것이 협업의 기본이며, 책임의 시작이다.