A-1: 의미 있는 이름·주석·포매팅 — 코드를 읽는 사람을 위한 첫 배려

안녕하세요, 여러분의 개발 안목을 길러 드릴 홍순구 튜터입니다. 오늘부터 우리는 클린 코드라는 새로운 여정을 시작합니다. 지금까지 언어 기초에서 "문법을 읽고 쓰는 손"을 만들었다면, 이 과목은 그 손으로 "오래 살아남는 코드를 쓰는 안목" 을 기릅니다.

동작하는 코드를 짜는 것과, 6개월 뒤 다른 사람이(혹은 내가) 열어 봐도 이해되고 마음 놓고 고칠 수 있는 코드를 짜는 것은 전혀 다른 일이에요. 실무 코드는 한 번 쓰고 버리는 게 아니라 몇 년을 두고 수십 명이 고쳐 가며 삽니다. 회사가 주니어와 미들을 가르는 가장 큰 잣대도 바로 "이 사람 코드를 다른 사람이 이어받을 수 있는가"입니다. 처음엔 지저분한 코드가 더 빨라 보이지만, 기능이 쌓일수록 고치는 비용이 폭발해요. 클린 코드는 그 폭발을 막으려고 미리 조금 더 들이는 투자입니다.

너무 부담 갖지 마세요. 객체지향(클래스·상속·인터페이스)을 한 번 떼었으면 따라올 수 있게 준비했습니다. 거창한 설계 이전에, 오늘은 가장 작은 단위인 변수 하나의 이름, 숫자 하나, 주석 한 줄, 줄 간격부터 손봅니다.

코드 리뷰를 받아 본 분이라면 이런 말 한 번쯤 들어 보셨죠?

• "변수명만 봐선 이게 뭔지 모르겠어요."
• "이 주석, 코드랑 따로 노는데요?"
• "여기 10이 대체 무슨 숫자예요?"

오늘 수업이 끝나면, 여러분은 이 세 마디를 듣지 않는 코드를 쓰게 됩니다. 자, 출발해 볼까요?

 A-1 의 여정 — 한 줄 한 줄을 읽기 좋게

 이름       →  의도를 드러내고 · 발음되고 · 검색되는 이름
 매직 넘버   →  10, 0.1 같은 숫자에 이름을 달아 준다
 주석       →  거짓말하는 주석을 걷어내고, 코드로 말하게 한다
 포매팅      →  읽는 리듬을 만들고, 팀의 약속에 맡긴다

💡 오늘 수업의 핵심 — "코드는 컴퓨터가 아니라 사람이 읽는다"

같은 동작을 하는 코드라도, 이름과 형식에 따라 읽는 사람의 시간은 10배까지 차이 납니다. 오늘은 그 차이를 만드는 네 가지 — 이름, 매직 넘버, 주석, 포매팅 — 을 지저분한 Before와 깨끗한 After로 나란히 보면서 익힙니다.

🎯 학습 목표

• 의도를 드러내고, 발음·검색이 되는 이름을 짓고, 매직 넘버를 이름 있는 상수로 바꾼다.
• 거짓말하는 주석을 걷어내고, 설명은 주석이 아니라 코드(이름)로 옮기되 꼭 필요한 좋은 주석은 남긴다.
• 코드 포매팅이 읽는 리듬임을 알고, 개인 취향이 아니라 팀의 약속과 자동 포매터에 맡긴다.

Step 1: "이름 하나에 6개월이 걸린다"

코드 리뷰에서 가장 자주 듣는 말이 "변수명만 봐선 뭔지 모르겠어요"입니다. 회원 목록에서 활성 회원만 골라내는 코드를 한번 볼게요.

❌ Before

public List<Member> f(List<Member> l) {
    List<Member> r = new ArrayList<>();
    for (Member e : l) {
        if (e.isActive()) {
            r.add(e);
        }
    }
    return r;
}

코드는 멀쩡히 돌아갑니다. 그런데 f는 무슨 일을 할까요? l, r, e는 각각 뭘까요? 메서드 이름이 아무것도 알려 주지 않아서, 안을 한 줄 한 줄 따라 읽어야만 "아, 활성 회원을 거르는구나"를 겨우 압니다. 게다가 r 같은 한 글자 이름은 검색이 안 돼요. 나중에 이 변수만 찾으려고 r을 검색하면 코드 전체의 수천 군데가 걸립니다.

✅ After

public List<Member> findActiveMembers(List<Member> members) {
    List<Member> activeMembers = new ArrayList<>();
    for (Member member : members) {
        if (member.isActive()) {
            activeMembers.add(member);
        }
    }
    return activeMembers;
}

메서드 이름만 읽어도 "활성 회원을 찾는다"가 바로 들어옵니다. 주석 한 줄 없이 이름이 의도를 설명하죠. 여기서 좋은 이름의 세 규칙을 뽑아 볼게요.

• 의도를 드러내는 이름: findActiveMembers는 "무엇을 하는지"를 말한다. f는 아무것도 말하지 않는다.
• 검색 가능한 이름: activeMembers는 검색하면 딱 그 변수만 걸린다. r은 못 찾는다.
• 의미 있는 구분: list1, list2처럼 숫자만 붙여 구분하지 말 것. 무엇이 다른지가 이름에 담겨야 한다.

이름만 바꿨을 뿐 거르는 결과는 한 군데도 안 변합니다. 동작은 똑같은데 읽는 속도만 빨라지는 거예요.

⚠️ 언제 깨나 — 짧은 이름이 무조건 나쁜 건 아닙니다. 세 줄짜리 반복문의 i, 람다의 짧은 인자처럼 스코프가 아주 좁고 의미가 자명하면 한 글자도 괜찮아요. 핵심은 "길수록 좋다"가 아니라 "스코프에 맞는 이름"입니다. 멀리까지 살아남는 변수일수록 이름이 또렷해야 합니다.

💡 한 줄 정리

이름은 곧 문서다 — 의도를 드러내고, 검색되고, 의미로 구분되는 이름을 지어라.

Step 2: "발음할 수 있나요? — 헝가리안 표기법의 몰락"

옛날 코드에는 변수 이름 앞에 타입을 붙이는 관습이 있었습니다. 문자열이면 str, 정수면 i, 이런 식으로요. 이걸 헝가리안 표기법이라고 부릅니다. 태그 목록에 #을 붙이는 코드로 보겠습니다.

❌ Before

public List<String> buildLabels(List<String> strList) {
    List<String> strResultList = new ArrayList<>();
    for (String strItem : strList) {
        strResultList.add("#" + strItem);
    }
    return strResultList;
}

strList, strResultList, strItem — 앞에 붙은 str이 "이건 문자열이야"를 알려 줍니다. 그런데 문제가 둘 있어요. 첫째, 요즘 IDE는 변수에 마우스만 올려도 타입을 바로 보여 줍니다. 타입 접두사는 이미 아는 정보를 또 적는 노이즈예요. 둘째, 나중에 이 변수의 타입이 바뀌면(문자열에서 리스트로) 이름은 str 그대로 남아 거짓말을 하게 됩니다. 발음도 안 돼요. "스트리절트리스트"라고 읽히죠.

✅ After

public List<String> buildLabels(List<String> tags) {
    List<String> labels = new ArrayList<>();
    for (String tag : tags) {
        labels.add("#" + tag);
    }
    return labels;
}

tags, labels, tag — 타입이 아니라 무엇을 담는지(의미) 를 말합니다. 타입은 IDE와 컴파일러에게 맡기고, 이름은 의미에 집중하는 거예요.

헝가리안 표기법은 1980~90년대, 에디터가 빈약하고 타입 검사가 약하던 시절에 생긴 관습입니다. 그땐 이름에 타입을 적어 두는 게 도움이 됐어요. 하지만 현대 IDE가 타입을 즉시 보여 주고 안전하게 이름을 바꿔 주면서, 접두사는 거추장스러운 군더더기가 됐습니다. 그래서 지금은 거의 사라졌어요.

💡 같은 원리, 다른 표기: Java는 buildLabels처럼 단어를 붙여 쓰는 camelCase를, Python은 build_labels처럼 밑줄로 잇는 snake_case(PEP 8)를 씁니다. 표기 관습은 언어마다 다르지만, "타입 접두사(strTag) 없이 의미를 드러낸다"는 원리는 똑같습니다.

⚠️ 언제 깨나 — 살아남은 인코딩도 있습니다. 일부 팀은 멤버 변수에 _ 접두사를, 인터페이스에 I 접두사(주로 C#)를 약속해 씁니다. 팀이 합의해 일관되게 쓴다면 괜찮아요. 규칙의 본질은 "타입을 절대 붙이지 마라"가 아니라 "이름이 거짓말하게 두지 마라" 입니다.

💡 한 줄 정리

이름엔 타입이 아니라 의미를 담아라 — 타입을 표시하는 접두사는 IDE 시대에 거짓말의 원천이 된다.

Step 3: "10이 대체 무슨 숫자예요?"

리뷰에서 숫자를 보면 꼭 나오는 질문이 "이 10이 무슨 숫자예요?"입니다. 구매 횟수에 따라 할인해 주는 코드를 볼게요.

❌ Before

public int finalPrice(int price, int purchaseCount) {
    if (purchaseCount >= 10) {
        return price - (int) (price * 0.2);
    } else if (purchaseCount >= 3) {
        return price - (int) (price * 0.1);
    }
    return price;
}

10, 0.2, 3, 0.1 — 코드만 봐선 정체를 알 수 없습니다. 이렇게 의미 설명 없이 코드에 그대로 적힌 숫자를 매직 넘버라고 불러요. 더 큰 문제는, 같은 10이 여러 곳에 흩어져 있을 때입니다. 단골 기준이 10에서 15로 바뀌면, 흩어진 10을 하나라도 놓치는 순간 버그가 됩니다.

✅ After

private static final int LOYAL_CUSTOMER_THRESHOLD = 10;
private static final int REPEAT_CUSTOMER_THRESHOLD = 3;
private static final double LOYAL_DISCOUNT_RATE = 0.2;
private static final double REPEAT_DISCOUNT_RATE = 0.1;

public int finalPrice(int price, int purchaseCount) {
    if (purchaseCount >= LOYAL_CUSTOMER_THRESHOLD) {
        return price - (int) (price * LOYAL_DISCOUNT_RATE);
    } else if (purchaseCount >= REPEAT_CUSTOMER_THRESHOLD) {
        return price - (int) (price * REPEAT_DISCOUNT_RATE);
    }
    return price;
}

이제 10은 "단골 기준", 0.2는 "단골 할인율"이라고 이름이 설명합니다. 정책이 바뀌면 맨 위 상수 한 곳만 고치면 되고, 흩어진 숫자를 찾아 헤맬 일도 없어요. 숫자에 이름만 달았을 뿐, 어느 구매 구간에서도 계산 결과는 똑같습니다.

⚠️ 언제 깨나 — 모든 숫자를 상수로 빼면 오히려 과합니다. 첫 인덱스 0, i + 1의 1, 반으로 나누는 / 2처럼 의미가 자명한 숫자는 그대로가 더 잘 읽혀요. ZERO = 0 같은 상수는 코드를 어지럽힐 뿐입니다. 기준은 딱 하나 — "이 숫자가 왜 하필 이 값인지 설명이 필요한가?" 입니다.

💡 한 줄 정리

설명이 필요한 숫자엔 이름을 달아라 — 단, 자명한 0·1·2까지 상수로 빼면 과하다.

Step 4: "주석은 대개 실패의 신호다"

리뷰 단골 지적 두 번째, "이 주석 코드랑 따로 노는데요?"입니다. 주석을 무조건 나쁘다고 보는 건 아니지만, 솔직히 말하면 대다수의 주석은 "코드로 설명하지 못한 것의 변명"이에요. 그중에서도 가장 위험한 건 거짓말하는 주석입니다.

❌ Before

// 무료배송 기준: 3만원 이상 구매 시
public boolean isFreeShipping(int totalPrice) {
    return totalPrice >= 50_000;
}

주석은 "3만원"이라는데, 코드는 50_000, 즉 5만원입니다. 누군가 배송 정책을 바꾸면서 코드는 고치고 주석은 안 고친 거예요. 주석은 컴파일러가 검사하지 않아서, 시간이 지나면 이렇게 코드와 따로 놀게 됩니다. 그리고 이 주석을 믿은 사람은 틀린 정보로 일하게 돼요. 실제로 30_000원을 넣어 보면 무료배송이 안 됩니다. 주석이 거짓말을 하고 있는 거죠.

✅ After

private static final int FREE_SHIPPING_THRESHOLD = 50_000;

public boolean isFreeShipping(int totalPrice) {
    return totalPrice >= FREE_SHIPPING_THRESHOLD;
}

주석을 지우고, 상수 이름이 같은 말을 하게 했습니다. 이름은 코드의 일부라서 거짓말을 하면 컴파일러나 사용처에서 바로 들통나요. 주석과 달리 코드와 따로 놀 수가 없습니다.

그렇다면 좋은 주석은 뭘까요? 코드로 표현할 수 없는 것만 남기면 됩니다.

// 이벤트 시작 0시에 트래픽이 몰리므로, 이 시간대만 캐시 TTL을 짧게 둔다. (의도/배경)
static final int EVENT_CACHE_TTL_SECONDS = 5;

// ⚠️ 이 순서를 뒤집으면 외래 키 제약으로 삭제가 실패한다. 순서를 바꾸지 말 것. (경고)
// TODO: 배치 분리 후 이 메서드는 스케줄러로 옮긴다. (JIRA-1234)

"왜 이렇게 했는지(의도·배경)", "건드리면 안 되는 이유(경고)", "나중에 할 일(TODO)", 그리고 공개 API의 사용법 문서나 법적 고지 — 이런 건 코드만으로는 못 담아서 주석이 제값을 합니다.

⚠️ 언제 깨나 — "주석은 무조건 나쁘다"는 말은 맹목적인 규칙 추종입니다. 좋은 주석(의도·경고·법적 고지·공개 API 문서)은 살려야 해요. 나쁜 건 두 종류 — 코드를 그대로 옮긴 주석(i++; // i를 1 증가)과, 낡아서 거짓말하는 주석입니다. 지울 주석과 남길 주석을 가리는 안목이 실력이에요.

💡 한 줄 정리

거짓말하는 주석은 없느니만 못하다 — 코드와 따로 노는 주석을 걷어내되, 의도·경고 같은 좋은 주석은 남겨라.

Step 5: "설명은 주석이 아니라 코드로"

Step 4가 "거짓말하는 주석을 걷어내라"였다면, 이번엔 한 걸음 더 나아갑니다. 주석으로 설명하려던 내용을 아예 이름으로 옮기는 거예요. 회원이 탈퇴할 수 있는지 판단하는 코드를 볼게요.

❌ Before

public boolean canWithdraw(Member member) {
    // 가입한 지 7일이 지났고, 정지 상태가 아니며, 보유 포인트가 0인 회원만 탈퇴할 수 있다.
    return member.daysSinceJoined() >= 7
            && !member.isSuspended()
            && member.point() == 0;
}

조건 세 개가 한 줄에 뭉쳐 있어서, 위에 달린 주석이 없으면 무슨 판단인지 한눈에 안 들어옵니다. 주석이 있어야만 읽히는 코드는, 사실 코드가 스스로 설명하는 데 실패한 거예요.

✅ After

private static final int WITHDRAW_COOLDOWN_DAYS = 7;

public boolean canWithdraw(Member member) {
    boolean passedCooldown = member.daysSinceJoined() >= WITHDRAW_COOLDOWN_DAYS;
    boolean notSuspended = !member.isSuspended();
    boolean hasNoPoint = member.point() == 0;

    return passedCooldown && notSuspended && hasNoPoint;
}

주석이 하던 설명을 이제 변수 이름이 합니다. passedCooldown(쿨다운 지남), notSuspended(정지 아님), hasNoPoint(포인트 없음) — 이렇게 의미를 담은 변수를 설명 변수라고 불러요. 마지막 return은 "쿨다운 지났고, 정지 아니고, 포인트 없으면 탈퇴 가능"으로 영어 문장처럼 읽힙니다. 7도 상수로 빼서 의미를 달았죠. 주석을 지웠는데 오히려 더 잘 읽히게 됐습니다.

이걸 더 밀고 가면, 이 세 조건을 아예 isEligibleToWithdraw() 같은 작은 함수로 뽑아낼 수도 있어요. 다만 그 "함수로 쪼개기"는 다음 시간(함수 설계)에서 본격적으로 다룹니다. 오늘은 이름으로 의도를 드러내는 데까지입니다.

⚠️ 언제 깨나 — 설명 변수도 과하면 독입니다. 딱 한 번 쓰고 의미가 이미 자명한 식까지 변수로 빼면, 줄만 늘고 읽는 흐름이 끊겨요. 설명 변수는 "주석을 달고 싶을 만큼 복잡하거나 의도가 안 보이는 식"에만 씁니다.

💡 한 줄 정리

주석으로 변명할 코드라면, 그 설명을 이름에 담아라 — 이름은 코드와 함께 늙는다.

Step 6: "코드도 읽는 리듬이 있다"

포매팅은 그냥 취향 문제 같지만, 실제로는 읽는 속도를 바꿉니다. 합계와 최댓값을 구하는 같은 코드를, 형식만 다르게 두 번 보겠습니다.

❌ Before

public int sum(int[] numbers){int total=0;
    for(int number:numbers){
    total+=number;}
    return total;}
public int max(int[] numbers){
    int maxValue=numbers[0];for(int number:numbers){if(number>maxValue)maxValue=number;}
    return maxValue;}

연산자 양옆에 공백이 없고, 줄바꿈이 제멋대로고, 두 메서드 사이가 딱 붙어 있습니다. 눈이 어디서 끊어 읽어야 할지 몰라 한참을 헤매게 돼요.

✅ After

public int sum(int[] numbers) {
    int total = 0;
    for (int number : numbers) {
        total += number;
    }
    return total;
}

public int max(int[] numbers) {
    int maxValue = numbers[0];
    for (int number : numbers) {
        if (number > maxValue) {
            maxValue = number;
        }
    }
    return maxValue;
}

형식만 정리했을 뿐 계산 결과는 그대로인데, 읽는 부담이 확 줄었죠. 여기엔 두 가지 원리가 깔려 있습니다.

• 수직 밀집도: 서로 관련 있는 코드(변수 선언과 그 사용)는 가까이 붙인다.
• 개념적 거리: 관련 없는 것(sum과 max라는 별개의 메서드)은 빈 줄로 띄워 구분한다.

가로로는 연산자 양옆에 공백을 두고(total += number), 들여쓰기를 일관되게 맞춥니다. 가까운 건 모으고 먼 건 띄우는 것 — 글의 문단 나누기와 똑같아요.

⚠️ 언제 깨나 — 포매팅엔 절대적인 정답이 없습니다. 중괄호를 같은 줄에 둘지 다음 줄에 둘지, 들여쓰기를 4칸으로 할지 2칸으로 할지는 옳고 그름이 아니라 합의의 문제예요. 정말 중요한 건 일관성 하나입니다. 한 파일 안에서, 한 팀 안에서 같기만 하면 됩니다. 그 "합의"를 어떻게 지키느냐가 바로 다음 Step입니다.

💡 한 줄 정리

가까운 건 붙이고 먼 건 띄워라 — 포매팅은 코드를 읽는 리듬이고, 핵심은 일관성이다.

Step 7: "내 취향 말고 팀의 약속"

Step 6 끝에서 본 질문들(탭이냐 스페이스냐, 중괄호 위치)엔 정답이 없습니다. 그래서 이런 건 개인이 정하지 않아요. 팀이 한 번 정하고, 도구가 강제합니다.

코드는 여러 명이 함께 읽고 고칩니다. 한 사람이 자기 스타일을 고집하면, 코드 변경 이력이 포매팅 변경으로 뒤덮여서 정작 중요한 진짜 변경이 안 보이게 돼요. 그래서 "내 방식이 옳다"보다 "우리가 같다"가 먼저입니다.

그리고 그 약속을 사람이 일일이 지키는 게 아니라, 자동 포매터에게 맡깁니다. 저장하는 순간 도구가 합의된 규칙대로 형식을 자동으로 맞춰 줘요. Java에는 google-java-format이나 Spotless, 자바스크립트엔 Prettier, Python엔 black이 있습니다. 저장소에는 이렇게 규칙을 적어 둬서, 누가 어떤 IDE를 쓰든 같은 형식이 나오게 합니다.

[*.java]
indent_style = space
indent_size = 4
max_line_length = 120

🌟 Python의 black은 "타협 없는 포매터"를 표방합니다. 설정 옵션을 거의 주지 않아서, "이건 이렇게 하자 저건 저렇게 하자"는 논쟁 자체를 없애 버려요. 포매팅 회의를 없애려고 만든 도구인 셈입니다. 새 프로젝트라면 이런 자동 포매터를 처음부터 켜 두는 걸 추천합니다.

⚠️ 언제 깨나 — 자동 포매터가 만능은 아닙니다. 포매터는 공백과 줄바꿈은 맞춰 주지만, "좋은 이름"이나 "작은 함수"는 못 만들어요. 형식은 도구에 맡기고, 사람은 그 위에서 이름·구조 같은 진짜 설계에 집중하라는 뜻입니다. 또 오래된 코드베이스에 갑자기 포매터를 돌리면 거대한 변경 덩어리가 생기니, 도입 시점은 팀이 합의해서 정해야 합니다.

💡 한 줄 정리

포매팅은 개인 취향이 아니라 팀의 약속 — 한 번 정하고 자동 포매터에 맡겨, 논쟁이 아니라 설계에 집중하라.

마무리

오늘은 거창한 설계 이전에, 코드를 읽는 사람을 배려하는 가장 작은 기본기를 익혔습니다. 핵심을 세 가지로 정리할게요.

오늘 배운 핵심 세 가지

• 💡 하나 — 이름이 곧 문서다. 의도를 드러내고, 발음·검색이 되는 이름을 짓고, 매직 넘버엔 이름을 달아라. 타입을 표시하는 접두사는 거짓말의 원천이다.
• 💡 둘 — 주석은 코드가 못 한 설명의 보충일 뿐이다. 거짓말하는 주석을 걷어내고, 설명은 이름으로 옮기되, 코드로 표현 못 하는 의도·경고만 주석으로 남겨라.
• 💡 셋 — 형식은 읽는 리듬이고, 그 리듬은 팀의 약속이다. 가까운 건 붙이고 먼 건 띄우되, 탭이냐 스페이스냐 같은 논쟁은 자동 포매터에 맡겨라.

그리고 오늘 내내 한 가지를 반복했습니다 — 오늘 배운 규칙도 절대 법칙이 아니라는 것. 짧은 이름이 나을 때, 주석이 꼭 필요할 때, 포매팅이 합의의 문제일 때를 매번 함께 봤죠. 규칙을 외우는 건 주니어, 규칙의 이유를 알아 언제 적용하고 언제 느슨하게 둘지 판단하는 게 미들입니다. 이 안목이 이 과목 전체를 관통하는 척추예요.

다음 시간 예고

다음 시간엔 함수 설계로 갑니다. 오늘 Step 5에서 살짝 본 "복잡한 조건을 작은 함수로 뽑기"를 본격적으로 다뤄요. 함수를 작게, 한 가지 일만 하게, 인자를 줄이고, 숨은 부수 효과를 걷어내는 법. 오늘 이름을 잘 짓는 법을 배웠으니, 이제 그 좋은 이름이 붙는 함수 자체를 다듬을 차례입니다.

과제

오늘 배운 이름·매직 넘버·주석을, 직접 손으로 고치며 익혀 봅시다. 머리로 아는 것과 손으로 고치는 것은 다릅니다.

[기초] 정체불명 코드에 이름 붙이기

아래 코드는 동작은 맞지만 이름이 아무것도 설명하지 않습니다. 의미 있는 변수·메서드 이름으로 바꿔 보세요.

public int c(int[] a) {
    int n = 0;
    for (int x : a) {
        if (x >= 60) {
            n++;
        }
    }
    return n;
}

힌트: 이 코드는 점수 배열에서 합격 점수 이상을 받은 사람 수를 셉니다. 메서드 이름, 매개변수, 지역 변수를 각각 의미가 드러나게 바꾸고, 60도 처리해 보세요.

[응용] 거짓말하는 주석과 복합 조건 정리하기

아래 두 메서드를 고쳐 보세요. 첫째는 주석과 코드가 어긋나 있고, 둘째는 주석이 없으면 안 읽히는 복합 조건입니다.

// 성인(만 20세 이상)만 구매 가능
public boolean canPurchase(int age) {
    return age >= 19;
}

public boolean canGetCoupon(Member member) {
    // 가입 30일이 넘었고, 이번 달에 구매한 적이 있는 신규 알림 동의 회원
    return member.daysSinceJoined() > 30
            && member.purchasedThisMonth()
            && member.agreedToNotification();
}

힌트: 첫 메서드는 주석과 코드 중 무엇이 맞는지 결정하고 둘을 일치시키세요(매직 넘버도 처리). 둘째는 주석을 설명 변수로 옮겨 주석 없이도 읽히게 만드세요.

[심화] 매직 넘버 정리 + 도그마 판단

아래 함수에는 여러 숫자가 그대로 들어 있습니다. 상수로 빼야 할 숫자와, 그대로 두는 게 나은 숫자를 구분하고, 그 이유를 한 줄씩 적으세요.

public int rankPoint(int score, int rank) {
    int point = score * 2;
    if (rank == 1) {
        point += 100;
    } else if (rank <= 3) {
        point += 50;
    }
    return point / 1;
}

힌트: 100, 50, 3은 정책 값이라 이름이 필요할 수 있습니다. 반면 1(1등)이나 * 2, / 1 같은 숫자는 상수로 빼는 게 과할 수 있어요. "이 숫자가 왜 이 값인지 설명이 필요한가"를 기준으로 판단하고, / 1처럼 의미 없는 코드는 정리해도 됩니다.

생각해볼 주제

규칙을 외우는 데서 멈추지 말고, "언제 이 규칙을 따르고 언제 느슨하게 둘까"를 스스로 판단해 봅시다. 정답이 하나가 아닌 질문들입니다.

1. 좋은 이름에 드는 시간은 낭비일까?

변수 이름 하나를 정하느라 5분을 고민하는 건 과한 일처럼 보일 수 있습니다. 당장은 진도가 안 나가니까요. 하지만 그 이름이 앞으로 몇 명에게, 몇 번이나 읽힐지를 생각하면 어떨까요? 좋은 이름에 쓰는 시간이 비용인지 투자인지, 변경 비용 관점에서 토론해 보세요.

2. 주석을 0으로 만드는 게 목표일까?

"주석 없는 코드가 진짜 깨끗한 코드"라는 말을 종종 듣습니다. 일리가 있지만, 이 말을 곧이곧대로 밀어붙이면 어떤 위험이 있을까요? 좋은 주석(의도·경고·배경)까지 지워 버린 코드는 정말 더 나은 코드일까요? "주석 0"이라는 목표 자체의 함정을 생각해 보세요.

3. 팀 컨벤션이 '틀렸다'고 느껴질 때

내 기준엔 들여쓰기 2칸이 분명히 더 낫다고 생각하는데, 우리 팀 컨벤션은 4칸입니다. 이때 나는 일관성을 위해 4칸을 따라야 할까요, 아니면 더 낫다고 믿는 2칸을 고집해야 할까요? "개인의 옳음"과 "팀의 일관성"이 부딪힐 때 무엇을 우선해야 하는지, 그리고 컨벤션을 바꾸고 싶다면 어떻게 해야 하는지 이야기해 보세요.