코드를 사랑하지 마세요

2022.09.04.

코드에 대한 애정

개발자는 코드에 많은 애정을 쏟는다. 코드도 일종의 글이라 저마다의 개성이 묻어나기 때문에 그 애정이 커지는 경향이 있다고 생각한다. 자기 모습이 투영된다고 해야 할까.

그래서 변수명 하나에도 엄청난 공을 들이고 줄 바꿈과 띄어쓰기 하나에도 치열하게 고민한다. 코드의 깔끔함도 중요하게 여긴다. 실생활에서 다소 자유분방한 깔끔의 기준을 가진 사람도 코드만큼은 객관적으로 깔끔하게 만들려고 노력한다. 이에 따라 개발 일정에 부정적인 영향을 주기도 한다.

삭제하기 쉬운 코드

하지만 코드에 과도한 애정을 쏟아선 안 된다. 읽기 좋은 코드를 작성하는 노력이 무의미하다는 것은 아니지만 모든 일이 그렇듯 코드에도 균형이 필요하다.

우리가 서비스를 위해 작성하는 코드는 영원하지 않고 당장 내일 사라질 수도 있다. 삭제하기 쉬운 코드를 짜야한다는 의견이 있을 정도다. 이처럼 삭제되기 쉬운 것에 지나치게 많은 에너지를 쏟을 필요가 있을까. 현명한 개발자라면 상대적으로 오래 존속되는 것에 집중하고 투자해야 한다.

코드보다 중요한 것

코드는 서비스를 위해 존재한다. 서비스가 코드보다 중요하며 오래 유지된다. 코드가 서비스를 지탱하고 있는데 무슨 말인가 싶지만 여기서 말하는 건 '고객의 경험'이다. 적절한 타이밍에 고객에게 서비스 경험을 전달하는 것이 만족스러운 코드를 작성하는 것보다 중요하다.

개발자의 역량

개발자의 역량이란 서비스를 타이밍에 맞게 고객에게 전달할 수 있는 능력이기도 하다. 개발 속도를 포기하지 않으면서 코드 복잡도도 유지할 수 있는 개발자가 능력 있는 개발자라는 의미다. 코드의 퀄리티와 서비스 개발 속도의 적절한 선을 찾아가는 건 개발자의 몫이자 역량이다.

오늘 강조하고 싶은 건 코드의 퀄리티에 너무 많은 애정과 쏟지 말라는 것이다. 대충 해도 된다는 의미가 아니다. 과도한 코드 완벽주의를 경계하라는 의미다. 코드를 너무 사랑하지 말자.

코드와 거리두기

주변의 도움으로 알게 된 코드와 거리를 두는 몇 가지 노하우를 공유해본다.

1. 코드는 회사의 자산이라고 생각하기

PR을 올린 순간부터 팀의 코드라고 생각하자. 내가 작성한 코드는 나 자신도 아니고 나의 것도 아니다. 회사의 자산이다. 구성원으로서 회사의 자산을 잘 지켜낼 책임은 있지만 회사의 자산이 부족하거나 망가졌다고 해서 내가 부족하다는 의미는 아니다.

2. 기계처럼 단순하게 일하기

한 번에 하나씩 처리하며 기계처럼 단순하게 일하자. 기능을 넣는 PR이면 기능만 넣고 끝내야 한다. 구조 개선, 파일/변수 이름 변경은 과감하게 포기하자. 필요하다면 백로그 티켓을 남기고 만들기로 한 기능만 만들고 끝내자.

보이스카웃 규칙이 생각난다. "분명 더 깨끗하게 만드는 게 개발자의 덕목이라고 배웠는데...?" 맞는 말이다. 하지만 두 가지 이상의 일을 동시에 할 필요는 없다. 일단 하려던 일을 먼저 끝낸 다음 깨끗하게 만들면 된다. 감정이 없는 기계처럼 나눠서 한 번에 하나의 일만 처리하면 코드에 대한 지나친 애정이 생기는 걸 막을 수 있다.

3. 개발자의 업무 범위를 다시 정의하기

개발자의 업무 범위를 코드 작성 그 이상으로 이해하자. 코드를 작성하는 일이 개발자의 일에 전부라고 생각하면 코드에 집착하게 된다.

하지만 개발자의 업무 범위는 훨씬 광범위하다. 박미정님의 인프콘 발표 내용처럼 요구 사항 분석 단계, 설계 단계, 구현 단계, 테스트 단계, 배포 단계, 장애 발생 상황 등 신경 쓰고 관심을 가져야 할 업무가 많다. 구현 단계에만 매몰되면 더 나은 개발자가 될 수 없다.