Skip to content
Published on

마찰이 사라지면 안목이 남는 게 아니라 안목을 기를 길이 사라집니다

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
필사 모드✨Start Quiz
공유하기
Authors

리뷰 큐에 올라온 PR 열두 개가 전부 괜찮습니다

월요일 아침, 리뷰 대기열에 PR이 열두 개 있습니다. 전부 테스트가 붙어 있고, 이름이 단정하고, 주석이 성실합니다. 하나하나 보면 반려할 이유가 없습니다.

그런데 다 합쳐 놓고 보면 이 열두 개 중 다섯 개는 애초에 만들지 않았어야 하는 기능입니다. 옵션이 하나 더 늘었고, 설정 키가 세 개 늘었고, 앞으로 이걸 유지할 사람이 늘었습니다. 반려 사유를 쓰려고 하면 "코드는 괜찮은데 이걸 왜 만드는지 모르겠다"는 문장밖에 안 나오고, 그 문장은 리뷰 코멘트로 쓰기에 무례해 보입니다.

마찰은 필터였고, 필터는 사라진 뒤에야 보입니다

2026년 8월 6일에 공개된 Taste Is All That Is Left는 이 상황을 정면으로 다룹니다. 글의 핵심은 노력이 필터였다는 관찰입니다. 그리고 모든 필터가 그렇듯, 그것은 제거되기 전까지 보이지 않았습니다.

예전에는 어떤 기능을 만들려면 사흘이 들었습니다. 사흘이라는 비용은 그 자체로 심사였습니다. 사흘 쓸 만한 일인가를 스스로에게 묻게 만들었고, 애매한 아이디어의 절반은 그 질문에서 죽었습니다. 지금은 같은 기능이 40분이면 나옵니다. 40분은 심사를 통과시키기에 너무 싼 값입니다.

그래서 만들지 말았어야 할 것들이 만들어집니다. 그리고 그것들은 나쁘게 만들어지지 않았기 때문에 반박하기가 더 어렵습니다.

안목이 만들어지던 경로의 모양

같은 글이 더 중요하게 짚는 것은 다음 대목입니다. 안목은 느리고 멍청하고 창피한 방식으로 만들어진다는 것입니다. 나쁜 것을 만들고, 그것과 함께 살아야 하고, 사람들 앞에서 실패하는 과정입니다.

이 순서를 뜯어보면 각 단계가 왜 필요한지 보입니다. 나쁜 것을 만드는 단계에서 "이렇게 하면 이렇게 된다"는 인과가 몸에 새겨집니다. 그것과 함께 사는 단계에서 유지보수 비용이 감각으로 바뀝니다. 실패하는 단계에서 자기 판단과 현실의 차이가 측정됩니다.

셋 다 시간이 걸리고 셋 다 불쾌합니다. 그리고 셋 다 결과물이 나쁠 때만 발생합니다.

지금 신입에게 벌어지는 일

여기서 문제가 생깁니다. 원문의 관찰대로, 지금 시작하는 사람들은 나쁜 버전을 내보내고 그 안에 앉아 있어 볼 기회를 갖지 못합니다. 도구가 무난한 버전을 공짜로 주기 때문입니다.

이건 능력의 문제가 아닙니다. 오히려 반대입니다. 지금 신입은 3년 전 신입보다 훨씬 빨리 동작하는 것을 만듭니다. 다만 그 과정에서 "이 선택이 6개월 뒤에 어떤 대가를 요구하는가"를 배울 사건이 발생하지 않습니다. 유창함은 얻고 견습은 건너뜁니다.

그리고 이 간극은 지표에 잡히지 않습니다. 처리량, 리드 타임, PR 수 어디에도 나타나지 않다가, 2년쯤 지나 아무도 구조를 결정하지 못하는 팀으로 나타납니다. 회의에서 두 안 중 무엇을 고를지 아무도 강하게 말하지 못하고, 결국 둘 다 만들거나 가장 최근에 말한 사람의 안으로 갑니다.

한 가지 덧붙이면, 이건 세대에 대한 이야기가 아닙니다. 경력 10년 차도 똑같이 겪습니다. 익숙하지 않은 영역에서 도구가 주는 무난한 결과를 받아들이기 시작하면, 그 영역에 대한 판단력은 거기서 성장을 멈춥니다. 다만 이미 다른 영역에서 쌓은 감각이 있어서 스스로 눈치채기가 더 어려울 뿐입니다.

"안목이 전부"라는 결론이 위험해지는 지점

원문의 마지막 주장은 강합니다. 무엇을 만들 가치가 있는지 말해 줄 수 있는 사람은 거의 없고, 그것이 언제나 더 어려운 기술이었으며, 이제는 그것만 남았다는 것입니다.

진단으로는 설득력이 있는데, 이 문장을 처방으로 바꿀 때 조심해야 합니다. "이제 안목만 있으면 된다"로 읽으면 곤란합니다. 안목은 만드는 경험의 부산물이지 대체물이 아니기 때문입니다. 만들어 본 적 없는 사람의 판단은 안목이 아니라 취향이고, 둘의 차이는 틀렸을 때 드러납니다.

더 정확한 정리는 이쪽입니다. 안목의 가치가 올라간 동시에 안목의 공급 경로가 막혔다. 두 가지가 같이 일어났기 때문에 이건 좋은 소식이 아니라 문제입니다.

판정을 관측 가능하게 만들기

그래서 개인이 할 수 있는 첫 번째 일은 판정을 밖으로 꺼내는 것입니다. 안목은 원래 말없이 작동하는 능력이고, 말없이 작동하는 것은 검증도 전수도 되지 않습니다.

구체적으로는 이렇습니다. 무언가를 만들기 전에 두세 줄을 씁니다. 무엇을 만들지, 왜 지금인지, 만들지 않으면 어떤 일이 벌어지는지. 그리고 만든 뒤에 그 메모를 다시 읽습니다. 6개월쯤 쌓이면 자기 예측이 어느 방향으로 틀리는지가 보입니다. 대부분의 사람은 "만들지 않으면 벌어질 일"을 과대평가하는 쪽으로 일관되게 틀립니다.

이 메모가 설계 문서일 필요는 없습니다. 오히려 길면 안 씁니다. 커밋 메시지 본문이든 이슈의 첫 코멘트든, 나중에 다시 찾을 수 있는 곳에 세 줄이면 충분합니다. 중요한 것은 분량이 아니라 판정이 내려진 시점에 기록되었다는 사실입니다. 결과를 알고 나서 쓴 회고는 자기 판단을 재구성해 버려서 학습 자료로 쓸 수 없습니다.

마찰을 의도적으로 복원하는 세 가지 습관

두 번째는 사라진 마찰을 인위적으로 되살리는 것입니다. 전부 되살릴 필요는 없고, 학습이 일어나던 지점만 고르면 됩니다.

습관구체적 행동되살아나는 것
먼저 혼자 답을 정한다도구를 부르기 전에 설계를 한 문단으로 쓴다자기 판단과 무난한 기본값의 차이 측정
대안을 강제한다첫 결과를 받고 나서 다른 접근 두 개를 더 만들어 비교한다선택지가 여럿일 때만 생기는 판단
내가 만든 것과 함께 산다만든 기능의 운영과 장애 대응을 최소 한 분기 직접 맡는다유지보수 비용이 감각으로 바뀌는 경험

세 번째 항목이 가장 효과가 크고 가장 자주 생략됩니다. 만든 사람과 유지하는 사람이 분리되어 있으면 안목은 어느 쪽에도 쌓이지 않습니다. 만든 쪽은 대가를 치르지 않고, 유지하는 쪽은 선택의 맥락을 모릅니다. 조직도가 그렇게 그려져 있다면 개인이 바꿀 수 없는 경우도 많은데, 그럴 때는 최소한 자기가 만든 것의 장애 알림만이라도 계속 받는 편이 낫습니다.

두 번째 항목에도 한 가지 함정이 있습니다. 대안 세 개를 도구에게 한 번에 만들어 달라고 하면 대체로 서로 비슷한 세 개가 나옵니다. 같은 기본값 주변을 맴돌기 때문입니다. 그래서 최소한 하나는 손으로, 그리고 가능하면 정반대 제약을 걸고 만들어야 비교가 성립합니다. 예를 들어 "설정을 하나도 추가하지 않고 푼다"는 제약을 걸어 보는 식입니다.

팀에서 바꿀 수 있는 것은 리뷰의 질문입니다

마지막은 조직 차원입니다. 지금의 코드 리뷰는 "이 코드가 맞는가"를 묻도록 설계되어 있고, 그 질문은 도구가 이미 상당히 잘 대답합니다. 리뷰가 계속 그 질문만 하면 리뷰에서 배울 것이 남지 않습니다.

질문을 하나 앞으로 옮기면 됩니다. PR 템플릿에 "고려했다가 버린 대안과 그 이유" 칸을 넣고, 그 칸이 비어 있으면 리뷰를 시작하지 않는 규칙을 두는 식입니다. 이 한 칸이 하는 일은 두 가지입니다. 작성자에게 선택을 언어화하게 만들고, 리뷰어에게 코드가 아니라 판단을 볼 자리를 줍니다.

첫머리의 PR 열두 개로 돌아가면, 그중 다섯 개는 이 칸에서 걸립니다. 버린 대안이 없다는 것은 대개 대안을 생각하지 않았다는 뜻이고, 대안을 생각하지 않았다는 것은 만들지 않는다는 선택지도 검토되지 않았다는 뜻이기 때문입니다.

참고 자료

Discuss on Twitter • View on GitHub