뭔가 잘못됐다는 걸 알지만 이유를 말할 수 없을 때 — Jesse Pinkman 에너지

본문

코드 리뷰를 하다 보면 특정 줄을 가리켜 '이게 깨졌다'고 말할 수는 없지만 뭔가 이상하다고 느끼는 순간이 있습니다. 저자는 이를 미드 'Breaking Bad'의 Jesse Pinkman에 빗대어 'Jesse Pinkman 에너지'라고 부릅니다. Jesse는 화학을 설명하지 못했지만 배치가 망가지기 전에 알아채곤 했습니다. 마찬가지로 시니어 엔지니어도 깊은 아키텍처 논리를 항상 설명할 수 있는 것은 아니며, 그 감각은 비슷한 것들이 프로덕션에서 깨지는 것을 수년간 지켜보며 쌓인 패턴 인식인 경우가 많습니다. 문제는 '마음에 들지 않는다'가 PR 코멘트로 적절한 피드백처럼 들리지 않아 이 감각이 계속 무시된다는 점입니다.

찜찜함은 아직 번역되지 않은 데이터입니다

저자의 핵심 재해석은 이것입니다. 코드 리뷰 중의 모호한 불안감은 데이터이며, 다만 아직 말로 번역되지 않았을 뿐이라는 것입니다. 이런 감각은 보통 몇 가지 매우 구체적인 상황에서 나타납니다. 기술적으로는 동작하지만 시스템 전체를 테이프로 억지로 붙들고 있는 것처럼 느껴지는 함수, 오늘의 문제를 해결하면서 다음 분기의 문제 세 개를 조용히 만들어내는 아키텍처 결정, 머지되는 순간 영구화될 것이 분명한 '임시 수정', 그리고 해피 패스만 커버하는 에러 처리 — 회의실의 모두가 조용히 알고 있는 그런 코드입니다. 이 중 어느 것도 컴파일 에러를 내지 않고 테스트를 실패시키지도 않습니다. 그저 불편한 채로 앉아 있다가, 누군가 말을 꺼내거나 꺼내지 않은 채 코드가 배포될 뿐입니다.

침묵의 두 가지 경로와 같은 결말

'뭔가 잘못됐다'는 감각을 느낀 엔지니어는 보통 두 가지 중 하나를 합니다. 아직 완전히 언어화하지 못했기 때문에, 그리고 팀 앞에서 불확실해 보이고 싶지 않아서 침묵하거나, 깔끔하고 구체적인 이유 없이 반대하는 것이 작성자에게 불공평하게 느껴져서 — 특히 상대가 더 시니어이거나 데드라인 압박을 받는 경우 — 어쨌든 승인합니다. 두 경로 모두 같은 곳에 도착합니다. 코드는 배포되고, 감각은 맞았고, 3주 뒤에는 장애 보고서나 롤백, 혹은 매우 어색한 회고가 되어, 원래 리뷰에서 누군가가 이미 절반쯤 알고 있었던 것을 모두가 복원하려 애쓰게 됩니다.

확신 없이 우려를 꺼내는 템플릿

저자는 명확하고 실행 가능하고 자신감 있는 피드백을 최적화하는 문화 자체는 좋은 조언이지만, 가장 이른 경고 신호는 깔끔하게 포장된 채 도착하지 않는다고 말합니다. 흐릿하게, 감각으로 먼저 도착하고 이유는 나중에 옵니다. 문제를 일찍 잡는 엔지니어는 항상 기술 지식이 가장 깊은 사람이 아니라, 배포되기 전에 '왜인지는 아직 모르겠지만 이것을 다시 확인할 수 있을까요'라고 말할 의지가 있는 사람인 경우가 많습니다. 완성된 논거 없이 우려를 제기할 수 있는 템플릿으로 세 가지를 제시합니다. '이 부분이 취약해 보이는데, X가 실패하면 어떻게 되는지 설명해 주실 수 있나요', '아직 구체적인 반대 근거는 없지만 예전에 깨졌던 것을 떠올리게 합니다. 이야기해 볼 수 있을까요', '문제인지 그냥 제게 낯선 것인지 솔직히 모르겠지만 일단 표시해 둡니다'. 이 중 어느 것도 확실성을 요구하지 않습니다.

3단계 실천법 — 감각을 대화로 바꾸기

'직감을 믿으세요'보다 구체적인 것을 원한다면 다음 세 단계를 시도해 볼 수 있습니다. 첫째, 수정안이 아니라 감각에 이름을 붙입니다. 무엇을 바꿔야 한다고 생각하는지가 아니라 무엇을 느끼고 있는지를 말합니다. '이 부분이 과도하게 결합된 것 같습니다' 정도면 대화를 열기에 충분합니다. 둘째, 비난하지 말고 질문합니다. '이건 실패할 겁니다'와 '이게 실패하면 어떻게 되나요'는 완전히 다르게 받아들여집니다. 셋째, 대화가 진단을 하도록 둡니다. 정답을 가지고 도착할 필요가 없으며, 논의 자체가 혼자 생각하는 것보다 빨리 답을 만들어냅니다.

옳을 필요는 없고, 유용하면 됩니다

이 접근이 작동하는 이유는 너무 자주 뭉개지는 두 가지 — 옳은 것과 유용한 것 — 을 분리하기 때문입니다. 리뷰에서 유용하기 위해 옳을 필요는 없으며, 무엇을 느끼고 있는지 솔직하게 말하면 됩니다. 절반의 경우 모호한 것을 소리 내어 말하는 것만으로 해소됩니다. 작성자가 근거를 설명하면서 감각이 가라앉거나, 설명하는 과정에서 둘 다 이름 붙이지 못했던 진짜 문제가 드러나거나 합니다. 어느 쪽이든 이기는 결과이며, 유일하게 지는 수는 침묵입니다. 저자는 장애 보고서의 근본 원인으로 '자기 직감을 무시함'이라고 적는 사람은 없지만, 충분한 수의 포스트모템을 행간으로 읽어 보면 그것이 생각보다 자주 있다고 말합니다. 누군가 느꼈고, 누군가 말하지 않았고, 시스템이 힘든 방식으로 알아낸 것입니다. 이 글은 모든 PR을 사소한 지적으로 무덤에 보내라는 주장이 아니라, 반대로 흐릿한 것을 완성된 비판으로 꾸미기 전에 표시해도 된다는 허락이며, 좋은 엔지니어링 문화는 '정확히 뭐가 잘못됐는지'뿐 아니라 '확실치 않지만'에도 자리를 만들어 준다는 이야기입니다.

원문: dev.to / 번역·요약: Trawling