남의 코드를 고치기 무서운 개발자에게

by 그릿 | GROWTH_ESSAY | 2026-07-28

수정 버튼을 누르기 전 손가락이 멈칫합니다. 내가 건드린 한 줄 때문에 잘 돌아가던 결제 로직이 터지면 어쩌나 지레 겁이 납니다. 그래서 기존 코드는 건드리지 않고 옆에 비슷한 함수를 하나 더 만듭니다.

멘토링을 하며 만난 3년 차 백엔드 개발자의 이력서와 코드를 볼 때마다 자주 마주치는 장면입니다. 왜 남의 코드를 고치는 일이 이토록 두려울까요?

지뢰밭이라고 생각하기 때문입니다

남의 코드를 지뢰밭으로 바라보면 아무것도 바꿀 수 없습니다. 밟으면 터지는 폭탄이 아니라, 전임자가 당시 맥락에서 최선을 다해 남긴 흔적일 뿐입니다. 지뢰를 피하려고 옆에 새 길을 자꾸 내면 시스템은 누더기가 됩니다.

실력 있는 개발자는 코드를 고치기 전에 테스트 코드부터 작성합니다. 동작을 보장하는 울타리를 먼저 치면 두려움은 확신으로 바뀝니다. 안 터지길 기도하며 배포하는 행위는 개발이 아닙니다.

이해하지 않고 고치려 하기 때문입니다

코드의 맥락을 읽지 않고 결과만 바꾸려 할 때 사고가 납니다. 왜 이 위치에 조건문이 들어갔는지, 어떤 장애를 막으려고 짠 구조인지 이전 커밋 로그를 3분만 뒤져봐도 답이 나옵니다.

문맥을 파악한 사람은 코드 한 줄을 수정하더라도 확신이 있습니다. 멘토링에서 200명 넘는 주니어들을 관찰한 결과, 남의 코드를 무서워하는 사람의 90%는 Git 히스토리를 제대로 읽지 않는 습관을 갖고 있었습니다.

책임이 자기에게 온다고 착각하기 때문입니다

내가 고친 코드가 문제를 일으키면 모든 비난이 나에게 쏠릴 것 같아 무섭습니다. 하지만 개인에게 모든 책임이 돌아가는 조직이라면 시스템과 검증 프로세스가 부실한 것입니다.

동료에게 질문하고 PR(Pull Request)에서 리뷰를 요청하세요. 혼자 떠안는 대신 리뷰어와 검증 과정을 나누는 습관이 필요합니다.

남의 코드를 자신 있게 고칠 수 있을 때 비로소 남의 코드에 얹혀가는 개발자에서 시스템을 주도하는 개발자로 올라섭니다.