『리더블 코드』 3장 읽고, 오해받지 않는 이름 지어내기

『리더블 코드(The Readable Code)』 3장의 주제는 좋은 이름의 첫 번째 조건은 모호함이 없다는 것입니다. 읽는 사람의 입장에서 어떤 오해가 발생할 수 있을지를 미리 상상한 후 이름을 결정해야 합니다.

지금까지의 독서 감상은 다음과 같습니다:

3장은 8개의 절로 나뉘어 있으며, 각각 실제 코딩 장면을 다루고 있습니다.

3.1절은 filter()이 소재입니다. filter는 조건에 맞는 데이터를 남긴다고도 읽히고, 조건에 맞는 데이터를 제거한다고도 읽힐 수 있습니다. 서적에서는 이 모호한 이름을 버리고, 실제 의미에 맞춰 select() (남기기) 또는 exclude() (제거하기)로 변경할 것을 권장합니다.

3.2절은 Clip(text, length)의 문제입니다. Clip에는 끝에서 N 문자를 삭제하는 것과, 최대 N 문자가 되도록 자르는 것, 두 가지 해석이 있습니다. 인자 length가 바이트 수인지 문자 수인지 단어 수인지도 알 수 없습니다. 서적에서는 이를 Truncate(text, max_chars)로 변경했습니다. 이름으로 '자르기'라는 동작을 표현하고, 인자에 단위를 붙여서 모호함을 없앱니다.

3.3절은 경계를 나타내는 상수 이름입니다. XXX_LIMIT와 같은 이름으로는 그 경계값을 포함하는지 여부가 읽는 사람에게 알 수 없습니다. 상한과 하한을 나타내는 상수에는 max_와 min_을 접두사로 사용한다는 규칙을 정하면, 경계의 의미가 한눈에 보이고 오프바이원(off-by-one) 계열 버그도 피하기 쉬워집니다.

3.4절은 시작점과 끝점을 모두 범위에 포함하는 닫힌 구간입니다. start와 stop으로는 모호해지므로, first와 last를 우선적으로 사용하는 것이 좋습니다. 의미가 맞는 상황이라면 min과 max도 괜찮습니다.

3.5절은 시작점은 포함하고 끝점은 포함하지 않는 반개방 구간입니다. 이 상황에서는 begin과 end를 사용하는 것이 업계 관례입니다. end는 글자 그대로만 보면 모호하지만, C++ 표준 라이브러리 등에서 널리 사용되는 방식이므로 현재로서는 이것이 최선의 선택입니다.

3.6절은 참/거짓(boolean) 값 변수와, 참/거짓 값을 반환하는 함수의 이름에 관한 것입니다. 의미가 명확하지 않은 단어는 피하고, is, has, can, should를 접두사로 붙이는 습관을 들이는 것이 좋습니다. 부정형의 이름도 가능한 한 피하고, 예를 들어 disable_ssl보다는 긍정형인 use_ssl로 만듭니다.

3.7절은 프로그래머가 이미 가지고 있는 기대를 배신하지 않는 것입니다. get*()이라고 쓰여 있다면 가벼운 값의 획득을, size()라고 쓰여 있다면 O(1)의 빠른 호출을 누구나 예상합니다. 실제로는 비용이 큰 메서드라면 이런 이름은 사용하지 않아야 합니다. 사용해 버리면, 호출하는 쪽이 선입견을 가지고 비효율적인 코드를 작성하게 됩니다.

3.8절은 A/B 테스트 실험 설정이라는 실제 업무 예시를 통해, 이름을 결정하는 사고의 흐름을 보여줍니다. 개발자는 먼저 template, reuse, copy, inherit와 같은 후보들을 제시하고, 업무를 모르는 이용자의 입장에서 각각이 어떤 오해를 일으키는지 순서대로 생각합니다. 그 위에, 모호함이 가장 적은 copy_experiment와 inherit_from_experiment_id를 선택합니다.

읽고 나서 생각해 본 것은, 이 장이 AI 구동 개발에서 어떻게 적용될 수 있느냐 하는 것입니다. AI는 처리의 내용을 읽어서 각 함수가 무엇을 하고 있는지 판단할 수 있습니다. 그래서 이름은 그렇게 중요하지 않다고 생각하기 쉽습니다. 하지만 이해의 실수를 줄이고, 이해의 차이를 줄이며, 토큰 소비를 줄인다는 점에서, 오해받지 않는 함수 이름을 작성하는 것은 지금도 중요하다고 생각합니다. 특히, 이름이 모호하면 AI는 의미를 확인하기 위해 함수의 본문이나 호출원 등 더 많은 문맥을 읽어 내려가게 됩니다. 거기에 비용(cost)이 발생합니다.

인간은 모호한 이름에 만나면 망설이며 확인합니다. AI는 좀 더 있을 법한 해석으로 그대로 진행하는 경향이 있습니다. 한번 오해가 생기면, 그 뒤에 생성되는 코드는 오해 위에 쌓여갑니다. 이것이 이해의 차이입니다.

또 다른 문제는 리뷰에 있습니다. 인간이 AI가 작성한 코드를 리뷰할 때, 사전에 어느 정도 제약을 두고 있지 않으면, AI는 오해를 불러일으키기 쉬운 이름을 붙일 수 있습니다. 위험한 것은 명백히 이상한 이름이 아닙니다. 그런 이름은 한눈에 알아차릴 수 있습니다. 위험한 것은 언뜻 보기에는 그럴듯하지만 의미가 조금 벗어난 이름 쪽입니다. 예를 들어 get_user_data

만약 실제로 네트워크 요청을 보내고 있다면, 이는 3.7절의 원칙에 정면으로 위배된다. 이런 이름들은 대충 봐서는 놓치기 쉽고, 리뷰하는 사람에게도 부담을 가중시킨다.

그렇다면 AI 자체에게 '읽는 사람 입장에서 추론하게' 함으로써 해결할 수 있을까? 효과는 제한적이라고 생각한다. AI는 모든 문맥을 가지고 있기 때문에, 정말로 '업무를 모르는' 상태가 되기 어렵기 때문이다. 더 현실적인 방법은 규칙을 프로젝트 규약에 명시해 두고, AI의 판단력에 의존하기보다 규칙을 실행시키는 방식이다. 예를 들어, 참/거짓(boolean) 변수에는 is, has, can, should를 반드시 붙인다. 구간(range)은 begin/end로 통일한다. 단위가 있는 인자(argument)는 단위를 이름에 포함시킨다.