코드를 좋다고 말할 때 우리는 무엇을 보는가

좋은 코드는 단순히 동작하는 코드가 아니에요.
우리는 코드를 볼 때 세 가지를 동시에 평가합니다.
첫째, 의도가 명확한가입니다.
코드를 읽는 사람이 "이 코드는 무엇을 하려는 거지?"라고 묻지 않아야 해요.
둘째, 변경이 쉬운가입니다.
요구사항이 바뀔 때 고쳐야 할 곳을 바로 찾을 수 있어야 해요.
셋째, 예상 가능한가입니다.
비슷한 상황에서 비슷한 방식으로 동작해야 혼란이 없어요.
예를 들어 "사용자 정보 저장"이라는 함수가 있다면, 그 이름만 봐도 무엇을 하는지 알 수 있고, 나중에 저장 방식을 바꿔도 호출하는 쪽은 그대로 둘 수 있어야 합니다.

왜 같은 결과를 만드는 코드도 품질이 다른가

결과가 같아도 과정이 다르면 코드의 운명이 달라져요.
두 개의 계산기 프로그램이 있다고 상상해보세요.
하나는 덧셈, 뺄셈, 곱셈을 각각 명확한 함수로 나눴고, 다른 하나는 모든 로직이 한 덩어리로 뭉쳐있어요.
지금은 둘 다 "2 + 2 = 4"를 정확히 보여줍니다.
하지만 내일 나눗셈 기능을 추가하려면 어떨까요?
첫 번째 코드는 나눗셈 함수 하나만 추가하면 되지만, 두 번째는 전체를 다시 읽고 이해해야 해요.
코드 품질의 차이는 미래의 변화를 얼마나 편하게 받아들이느냐에서 나타납니다.
좋은 코드는 오늘의 결과뿐 아니라 내일의 수정까지 고려한 선택의 결과예요.

코드가 읽히고 고쳐지는 과정을 단계로 나누기

코드를 읽는 사람은 세 단계를 거쳐요.
1단계: 찾기 - "내가 고쳐야 할 부분이 어디지?"
파일 구조와 이름만 보고도 목적지를 찾을 수 있어야 해요.
2단계: 이해하기 - "이 코드는 지금 무엇을 하고 있지?"
주석 없이도 변수명과 함수명만으로 로직을 파악할 수 있어야 해요.
3단계: 수정하기 - "여기를 바꾸면 다른 곳이 망가지지 않을까?"
변경의 영향 범위가 예측 가능해야 안심하고 고칠 수 있어요.
예를 들어 "할인 계산" 로직을 고친다면, discount 폴더 안의 calculate 함수를 열어서, 명확한 변수명을 따라 읽고, 독립적인 구조 덕분에 다른 기능 걱정 없이 수정할 수 있어야 합니다.

좋은 코드를 떠올릴 때 기억해야 할 기준들

좋은 코드를 판단하는 기준은 몇 가지 질문으로 정리할 수 있어요.
"6개월 후의 나도 이해할 수 있을까?" - 시간이 지나도 명확한 코드인지 확인하세요.
"새로운 팀원이 하루 만에 수정할 수 있을까?" - 맥락 없이도 읽히는지 점검하세요.
"한 곳을 고칠 때 세 곳을 함께 고치진 않는가?" - 변경이 연쇄적으로 퍼지지 않는지 살펴보세요.
"비슷한 일을 하는 코드가 비슷하게 생겼는가?" - 일관성이 있으면 학습 비용이 줄어요.
이 기준들은 완벽을 요구하는 게 아니라, 개선할 지점을 찾는 나침반이에요.
코드를 작성할 때마다 이 질문들을 떠올리면, 자연스럽게 읽기 좋고 고치기 쉬운 코드에 가까워집니다.