좋은 개발자의 3요소, 테스트·리팩토링·디버깅

개발자의 능력이 평가되는 요소는 참 많다. 그런데 정말 좋은 개발자는 어떤 것이 좋을까? 내가 생각하는 좋은 개발자의 3요소는 아래와 같다.

1. 테스트 코드를 잘 작성하는 개발자

개발자의 경우 리뉴얼할 때도 있고 협업할 때도 있고, 여러 상황에서 버그가 발생될 확률이 높다. 그런 때에 일일이 하나씩 눌러보며 테스트하기란 시간과 노력이 많이 아깝다. 잘 짜놓은 테스트는 10명의 테스터보다 낫다.

덧붙이면

테스트 코드의 진짜 가치는 버그를 잡는 것보다 변경을 두렵지 않게 만드는 것에 있다.

테스트가 없으면 잘 돌아가는 코드를 건드리기가 무섭다. "이거 고치면 어디가 깨질지 모르는데"라는 생각이 들면 결국 손대지 않게 되고, 그렇게 방치된 코드가 레거시가 된다. 테스트가 있으면 고치고 나서 돌려보면 되니까 개선을 시도할 수 있다.

그리고 테스트는 실행되는 문서이기도 하다. 이 함수가 어떤 입력에 어떤 결과를 내는지, 예외 상황은 무엇인지가 테스트에 다 적혀 있다. 주석은 낡지만 테스트는 낡으면 실패해서 알려준다.

전부 테스트할 필요는 없다. 커버리지 100%를 목표로 하면 오히려 지친다. 우선순위는 이렇게 잡는 게 현실적이다.

• 돈·권한이 걸린 로직 — 결제, 정산, 인증
• 복잡한 계산·조건 분기 — 사람이 실수하기 쉬운 곳
• 한 번 터진 적 있는 곳 — 버그를 고칠 때 재현 테스트를 먼저 쓴다

2. 리팩토링을 잘하는 개발자

아무리 잘 설계된 개발이라도, 혹은 급하게 하느라 엉망인 개발 코드도, 언젠가는 코드가 지저분해지고 혹은 설계의 결함이 생긴다. 그럴 때마다 처음부터 다시 만들까? 개발이 복잡해졌다고 무조건 다 리뉴얼하면 개발 기간이 남아나지 않는다. 리팩토링을 통해서 깔끔하고 성능 좋은 개발이 될 수 있다.

덧붙이면

리팩토링에서 중요한 건 동작을 바꾸지 않는다는 원칙이다. 기능 추가와 구조 개선을 같은 커밋에 섞으면 문제가 생겼을 때 원인을 가릴 수 없다. 둘은 반드시 분리한다.

그래서 1번(테스트)과 2번(리팩토링)은 사실 한 세트다. 테스트 없이 하는 리팩토링은 리팩토링이 아니라 그냥 코드를 고치는 것이다. 동작이 같다는 걸 증명할 수단이 없기 때문이다.

언제 리팩토링할지도 판단이 필요하다.

• 같은 곳을 세 번째 고칠 때 — 두 번까지는 참고, 세 번째면 구조가 잘못된 것이다
• 기능을 추가하기 직전 — 추가하기 쉬운 구조로 먼저 바꾸고, 그다음에 추가한다
• 코드 리뷰에서 설명이 길어질 때 — 설명해야 이해되는 코드는 구조에 문제가 있다

반대로 건드리지 않는 코드는 지저분해도 놔둔다. 몇 년째 아무도 안 고치는 코드를 예쁘게 만드는 건 가치가 없다.

3. 디버깅을 잘하는 개발자 (혹은 디버깅 툴을 잘 쓰는 개발자)

가끔 초급 개발자들의 문제점 하나는, 에러가 빵 터지면 전에 했던 작업을 다 지우고 하나씩 다시 넣으면서 "아 여기가 문제구나" 하는 경우가 있다.

하지만 대부분의 에러는, 아니 모든 에러는 에러 메시지에 에러 내용이 담겨 있다. 또한 에러는 안 나지만 원하는 값이 나오지 않을 때 console.log를 다 찍어도 되지만, 디버깅 툴을 이용하면 많은 시간을 절약할 수 있다. 꼭 이용해보시라.

덧붙이면

디버깅은 사실 가설을 세우고 검증하는 과정이다. 잘하는 사람과 못하는 사람의 차이는 지식이 아니라 접근 방식에서 갈린다.

• 에러 메시지를 끝까지 읽는다. 스택 트레이스에서 내 코드가 나오는 첫 줄이 대개 출발점이다
• 재현 조건을 좁힌다. "가끔 안 돼요"를 "이 데이터로 이 순서로 하면 항상 안 됨"으로 만들면 절반은 끝난 것이다
• 이분 탐색으로 범위를 줄인다. 중간 지점에서 값을 확인해서 앞인지 뒤인지 가른다. git bisect도 같은 원리다
• 바꾼 것을 하나씩만 되돌린다. 여러 개를 동시에 바꾸면 무엇이 원인인지 알 수 없다
• 안 되는 이유가 아니라 되는 조건을 찾는다. 되는 케이스와 안 되는 케이스의 차이가 곧 원인이다

그리고 브레이크포인트를 쓸 줄 아는 것과 아닌 것의 생산성 차이가 정말 크다. 조건부 브레이크포인트를 걸면 "1000번째 반복에서만 멈춤" 같은 것도 가능한데, 이걸 console.log로 하려면 코드를 계속 고쳐야 한다.

그리고 하나 더 꼽자면

세 가지를 적어두고 몇 년 지나 다시 보니, 하나를 더 넣고 싶어졌다.

모른다고 말할 수 있는 개발자.

기술적 역량은 시간이 해결해준다. 그런데 모르는 걸 아는 척하고 넘어가면 그 부채는 나중에 훨씬 큰 형태로 돌아온다. "이 부분은 확인해보고 답변드리겠습니다"가 "아마 될 거예요"보다 훨씬 신뢰를 준다.

일정 산정도 마찬가지다. 안 될 것 같으면 미리 말하는 사람이 팀에서 가장 편한 동료다.

정리

• 테스트 — 버그를 막는 것보다 변경을 두렵지 않게 만드는 게 본질
• 리팩토링 — 동작은 그대로, 구조만. 테스트와 한 세트다
• 디버깅 — 에러 메시지를 끝까지 읽고, 재현 조건을 좁히고, 하나씩만 바꾼다
• 모른다고 말하기 — 기술보다 오래 가는 신뢰의 문제