좋은 프로그램은 빨리 끝나는 코드보다 읽히고 수정되는 코드에 가깝다
좋은 프로그램이 무엇이냐고 물으면 흔히 두 가지 답이 나온다. “버그가 없으면 좋은 프로그램”이라는 답과 “빠르면 좋은 프로그램”이라는 답이다. 둘 다 맞는 말이지만 절반만 맞다. 실무에서 더 오래 살아남는 코드는 대개 다른 사람이 읽고, 믿고, 고칠 수 있는 코드다.
이 기준은 특히 게임 개발에서 더 중요하다. 시스템이 서로 촘촘히 연결되어 있고, 기획 변경이 많으며, 한 코드 조각이 UI, 데이터, 전투, 연출에 모두 영향을 줄 수 있기 때문이다. 그래서 좋은 프로그램을 만든다는 것은 성능을 높이는 일만이 아니라, 변경 비용을 낮추는 구조를 만드는 일과도 같다.
1. 이름이 설명을 대신해야 한다
의미 있는 이름은 좋은 코드의 가장 싼 보험이다. 함수와 변수 이름이 무엇을 하는지 설명하지 못하면, 나중에 코드를 읽는 사람은 주석과 문맥, 디버깅으로 의미를 복구해야 한다.
나쁜 예:
int a;
void Process() {}조금 나은 예:
int currentHealth;
void ApplyDamageAndUpdateUi() {}Microsoft의 C# 코딩 컨벤션도 이름은 의도를 드러내야 하고, 쉽게 읽히는 쪽을 택하라고 권장한다. 짧은 이름보다 설명 가능한 이름이 유지보수에는 더 강하다.
2. 함수는 작을수록 좋은 게 아니라, 한 가지 일을 할수록 좋다
함수가 짧은 것만으로는 충분하지 않다. 중요한 것은 한 함수가 몇 가지 책임을 동시에 떠안고 있는가다.
예를 들어 로그인 함수가 인증, 프로필 로드, 사용자 인터페이스(UI) 초기화, 분석 이벤트 전송까지 모두 처리하고 있다면, 길이가 짧아도 변경에 약하다. 반대로 함수가 조금 길더라도 책임이 하나로 모여 있으면 읽고 수정하기가 훨씬 쉽다.
즉, 좋은 코드는 “짧은 코드”보다 경계가 분명한 코드에 가깝다.
3. 주석은 설명이 아니라 보충이어야 한다
주석이 많다고 코드가 친절한 것은 아니다. 오히려 코드가 스스로 설명하지 못하는 것을 주석이 억지로 덮고 있는 경우도 많다.
이런 주석은 보통 힘이 약하다.
// 값을 증가시킨다
score++;반대로 좋은 주석은 코드만으로는 알기 어려운 이유나 맥락을 적는다.
// 보스전에서는 일반 점수 배수 대신 별도 랭크 계산을 사용한다.즉, 주석은 “무엇을 하는가”보다 왜 이렇게 했는가를 설명할 때 더 가치가 크다.
4. 일관성은 개별 기교보다 더 중요하다
좋은 프로그램을 읽기 쉬운 이유 중 하나는 예측 가능성 때문이다. 변수명 규칙, 예외 처리 방식, 함수 분리 기준, 파일 구조가 일정하면 코드를 처음 보는 사람도 빠르게 적응할 수 있다.
반대로 이런 불일치는 작은 혼란을 계속 만든다.
- 같은 의미인데 함수명이
Get,Load,Fetch로 제각각인 경우 - private 필드 규칙이 파일마다 다른 경우
- 비슷한 예외 상황을 어떤 곳은 반환값으로, 어떤 곳은 예외로 처리하는 경우
일관성은 디자인 패턴보다 먼저 체감되는 품질이다.
5. 좋은 코드는 미래의 수정에 덜 겁난다
결국 좋은 프로그램의 핵심은 여기로 모인다. 이 코드를 3개월 뒤에 다시 열었을 때, 혹은 다른 개발자가 이어받았을 때 어디를 바꾸면 되는지 감이 오는가다.
이 기준을 통과하는 코드는 대개 이런 특징을 가진다.
- 이름이 의도를 드러낸다
- 함수와 클래스의 경계가 선명하다
- 중복이 줄어 있다
- 숫자와 규칙이 한곳에 모여 있다
- 테스트하거나 검증하기 쉬운 단위로 나뉘어 있다
즉, 좋은 프로그램은 단순히 “지금 잘 돈다”가 아니라 나중에도 손을 댈 수 있다는 신뢰를 준다.
실무에서 바로 쓰기 쉬운 체크리스트
코드를 제출하거나 PR을 올리기 전에 이런 질문을 해보면 도움이 된다.
- 함수 이름만 보고도 역할이 떠오르는가
- 한 함수가 두세 가지 일을 동시에 하고 있지 않은가
- 주석이 코드의 부족함을 억지로 메우고 있지는 않은가
- 비슷한 역할의 코드가 다른 방식으로 중복되어 있지 않은가
- 다음 기능 추가가 어디에 들어갈지 예상 가능한가
이 질문에 대부분 “그렇다”고 답할 수 있다면, 그 코드는 이미 많이 좋아진 상태일 가능성이 크다.
핵심 정리
좋은 프로그램은 성능만 좋은 코드가 아니다. 다른 사람이 읽고 이해하고 수정할 수 있는 코드에 더 가깝다. 의미 있는 이름, 한 가지 책임을 가진 함수, 이유를 설명하는 주석, 일관된 규칙, 낮은 변경 비용이 그 핵심이다.
특히 게임 개발처럼 변경과 확장이 잦은 환경에서는 “미래의 수정에 덜 무서운가”가 좋은 코드의 중요한 기준이 된다.
마치며
좋은 코드는 똑똑해 보이려고 쓰는 코드가 아니다. 동료와 미래의 자신이 덜 헤매도록 쓰는 코드에 더 가깝다.
빠르게 쓴 코드가 당장은 편할 수 있다. 하지만 오래 남는 코드는 대개 설명 가능한 코드다. 좋은 프로그램의 기준도 결국 거기서 갈린다.
참고 자료
- Microsoft Learn, C# Coding Conventions: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/coding-style/coding-conventions
- Martin Fowler. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley.
- Robert C. Martin. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall.
- Robert Nystrom, Game Programming Patterns: https://gameprogrammingpatterns.com/