코드를 고친다는 말로 판단을 덮어버릴 때
리팩토링은 소프트웨어의 겉으로 드러나는 기능,
즉 외부 동작은 바꾸지 않으면서
내부 구조를 개선해 코드를 더 이해하기 쉽고,
수정하기 좋게 만드는 과정을 말한다.
정의만 보면 늘 그럴듯하다.
하지만 현장에서 이 말은
거의 그대로 쓰이지 않는다.
나는 보통
어딘가 문제가 생겼을 때 투입되는 일이 많았다.
문제가 있을 때 투입된다는 건
이미 개발이 꽤 진행됐고,
프로그램을 돌리다 고치고, 또 고치는데도
잘 안 되는 상황이라는 뜻이다.
요청은 단순하다.
“이거 좀 되게 해 주세요.”
그런 상황에 들어가면
비슷한 장면이 거의 빠지지 않고 반복된다.
나뿐만 아니라 대부분의 개발자는
남의 코드를 보는 걸 좋아하지 않는다.
그리고 남의 코드를 보면
하나같이 비슷한 말을 한다.
“이건 쓰레기다.”
“이걸로는 개발 못 한다.”
“차라리 처음부터 다시 만드는 게, 훨씬 생산성 높다.”
이 말 자체가
아주 틀렸다고 보긴 어렵다.
문제는
이 말이 너무 쉽게 나온다는 데 있다.
개발을 잘 모르는 대표나 팀장이
이 말을 들으면
대개 이렇게 반응한다.
“그래요? 그럼 개선 부탁드립니다.
사실 기존 멤버는 좀 문제가 있었어요.”
이 순간부터 이야기는
코드에서 사람으로 옮겨간다.
나도 예전에 저랬다.
여러 코드를 심고, 수정하면서
리팩토링을 하다가
어딘가 구조적인 문제 하나가
눈에 걸리기 시작하면,
모든 문제가 꼭
그 구조 때문인 것처럼 보이기 시작한다.
이상하게도 그 순간부터는
버그도, 성능 문제도, 일정 지연도
전부 그 구조 하나로 설명이 된다.
문제는 복잡한데,
원인은 하나로 단순화된다.
그러다 보면
리팩토링을 하러 들어간 게 아니라,
그 구조를 없애기 위해
들어간 사람이 된다.
고친다는 명목으로
부정하고 싶은 대상을
하나 정해버리는 셈이다.
결국 리팩토링을 한다고 들어가서는
리팩토링이 아니라
프로그램을 그냥
처음부터 다시 짜버린다.
다 짜고 나서야 깨닫는다.
결과적으로 그 구조는
기존이랑 크게 다르지 않았다는 걸.
나는 왜
그걸 처음부터 다시 만들었을까.
그 이후로 나는
다른 사람의 코드에 대해
쉽게 말하지 않게 됐다.
이상한 걸 보면
이상하다고 말은 하지만,
“이건 쓰레기다”라는 말은
거의 하지 않는다.
그 말은
코드 평가로 끝나지 않고,
사람 평가로 번지기 때문이다.
이 장면을 다시 보면,
대표나 팀장은 이미
기존 개발자에 대해
안 좋게 쌓인 감정이 있었을 가능성이 크다.
일정을 못 지켰다거나,
버그를 오래 못 잡았다거나,
프로젝트의 사활을 두고
강하게 주장했다거나.
거기에 새로 투입된 사람이
“이건 구조적으로 잘못됐다”라고 말해버리면,
언짢던 마음에
명분이 붙는다.
안 되는 조직의
전형적인 모습이다.
그렇다면 새로 투입된 개발자는
왜 그렇게 말하게 될까.
첫째, 프로젝트의 도메인을
충분히 알기 전에
코드만 보고 판단하게 된다.
둘째, 그 코드가 거쳐온
수많은 기획 회의와
개발 과정의 고민들까지는 보지 못한 채,
결과물만 놓고 평가하게 된다.
셋째, 내가 짠 코드가 아니기 때문에
전체 흐름과 의도를 파악하는 데
시간이 더 걸린다.
넷째, 문제를 크게 규정할수록
새로 투입된 사람의
존재감은 커진다.
이 중 하나만 해당돼도
판단은 쉽게 거칠어진다.
아이러니하게도
큰 규모의 프로젝트에
갑자기 투입된 사람이
몇 군데 손봐서
바로 나아지는 경우는
실제로 흔하다.
그런데 이게 꼭
기존 개발이
전부 잘못됐다는 뜻은 아니다.
오히려 한두 군데만
제대로 짚으면 나아질 만큼,
전체는 이미 균형을 잡고
돌아가고 있었다는 뜻일 때가 많다.
그 몇 군데를 잡아낸 사람은
영웅이 된다.
대신 기존 개발자는
쓰레기가 된다.
아주 긍정적인 사람이 아닌 이상,
마음에 상처를 입는다.
그리고 자기 실력을
의심하기 시작한다.
반대로 정말
잘못된 경우도 있다.
잠깐 손본다고
해결되지 않는 프로젝트.
열 군데, 스무 군데를
동시에 건드려야 하는 상황.
이럴 때는
새로 투입된 사람도
곧 쓰레기가 된다.
그리고 기존 개발자는
속으로 이렇게 생각한다.
“봐라,
당신이 믿고 데려온 사람도
못하지 않나.”
누군가는 상처를 받고,
누군가는 위안 아닌 위안을 얻는다.
문제는
그대로 남아 있다.
사실 원인은
하나가 아닐 수 있다.
일정이 말도 안 됐을 수도 있고,
잦은 야근으로
판단력이 무뎌졌을 수도 있고,
실력이 부족했을 수도 있다.
대부분은
복합적이다.
그런데 이런저런 핑계와
“어쩔 수 없었다”는 상황은
항상 만들어진다.
그럼 언제까지
핑계만 댈 건가.
이런 상황은
언제든
나에게도 닥칠 수 있다.
그래서 결국
남는 건 하나다.
공부해야 한다.
더 많은 기술을
아는 게 아니라,
이게 리팩토링인지,
재개발인지,
지금 내가 고치고 있는 게
코드인지, 사람인지
구분할 수 있을 만큼.
“이만하면 됐다”고?
아니다.
그만하면 안 됐다.
더 해라.
#이개발자의사고방식 #리팩토링 #재개발 #기술부채 #프로젝트 #코드리뷰 #개발현실