짧은 코드를 보면 나도 전체를 이해할 수 있겠다는 마음이 들 때가 있다. 하지만 몇 줄 안 되는 표현을 오래 들여다봐도 어디서 시작하는지 모를 때도 있다. 작은 프로그램의 매력을 줄 수 하나로 설명하기는 어렵다. 읽는 사람이 입력에서 결과까지 따라갈 수 있는 크기인지가 함께 중요하다.
Dave Gauer의 Small Programs and Languages는 작은 프로그램과 언어를 바라보는 개인적 생각을 담고 있다. 원문은 2026년 7월 28일 글이며 오늘의 새 발표로 소개하는 것은 아니다. 이 글에서도 짧은 코드가 언제나 쉽다는 법칙을 주장하지 않는다. 프로그램 하나를 끝까지 읽어보는 연습의 범위를 생각해보려 한다.
한 화면에 있는 것과 이해되는 것
가상의 과제는 로그에서 정상 항목과 잘못된 항목의 수를 세는 일이다. 입력은 줄마다 상태 단어 하나가 있는 텍스트로 제한한다. 빈 줄은 제외하고, 허용한 상태가 아니면 오류로 센다. 실제 운영 로그를 모으거나 개인정보를 읽은 예제는 아니다. 독자가 흐름을 따라갈 수 있도록 입력을 직접 만든 작은 모형이다.
이 과제에는 읽기, 분류, 출력이라는 끝이 있다. 파일 감시나 네트워크 전송, 대시보드는 넣지 않는다. 나중에 필요할 수 있는 기능을 빼는 이유는 작은 것을 미덕으로 삼기 위해서가 아니다. 지금 읽으려는 동작의 시작과 끝을 놓치지 않기 위해서다.
짧게 줄이려고 여러 연산을 한 줄에 넣을 수도 있다. 그러나 빈 줄을 어디서 거르고 알 수 없는 상태를 어디서 세는지 찾기 어려워지면 읽기의 목표와 멀어진다. 코드를 쓰는 데 든 시간과 다른 사람이 이해하는 데 드는 시간은 같지 않다. 연습에서는 이름을 붙이고 중간 값을 남기는 편이 더 유용할 수 있다.
틀린 입력을 범위 안에 두기
예제의 규칙을 더 구체적으로 정해보자. 허용한 상태는 ok와 error이고 대소문자는 구분한다. ok는 정상으로, error와 다른 단어는 오류로 세되 알 수 없는 단어의 수도 따로 보인다. error 자체와 형식을 모르는 입력을 구분하고 싶다면 결과에 서로 다른 항목을 둘 수 있다.
가령 입력이 ok, 빈 줄, ERROR, error라면 무엇을 기대할까. 대소문자를 구분한다고 정했으므로 ERROR는 알 수 없는 상태다. 이처럼 아주 작은 입력도 규칙을 숨기면 해석이 달라진다. 코드가 짧아도 동작의 약속이 길어지는 이유다. 처음부터 모든 경우를 지원하기보다 지원하는 범위를 정확히 적는다.
이는 실제로 실행한 로그 분석기의 성능 결과가 아니라 설명용 입력과 기대값이다. 실용 도구로 바꾸려면 파일 읽기 실패, 인코딩, 큰 입력과 처리 중단도 검토해야 한다. 연습 예제를 복사한 뒤 운영에 쓸 수 있다고 이름만 바꾸어서는 안 된다. 작은 모형의 경계가 남아 있어야 다음 작업도 정할 수 있다.
실패를 예외 하나로 감추지 않는 것도 방법이다. 알 수 없는 줄이 있었다면 개수나 위치를 보여줄 수 있다. 다만 원문 전체를 출력하면 민감한 자료가 섞일 수 있는 실제 환경도 있다. 어떤 정보까지 남길지는 자료의 성격에 따라 달라진다. 예제의 편의와 운영의 기록 정책은 분리해야 한다.
읽고 나서 바꿀 수 있는 질문
프로그램을 다 읽었다면 문법을 외웠는지보다 작은 규칙을 바꿀 위치가 보이는지 물어볼 수 있다. ERROR도 error와 같게 보고 싶다면 어디를 바꿀까. 빈 줄을 오류로 세고 싶다면 어느 조건이 달라질까. 입력과 분류의 경계가 보이면 변경의 의미도 설명할 수 있다.
이때 한 번에 여러 규칙을 바꾸면 결과의 이유를 놓치기 쉽다. 한 조건만 바꾼 뒤 같은 가상 입력을 따라가면 무엇이 달라지는지 알 수 있다. 속도 향상이나 코드 축약을 먼저 시도할 필요는 없다. 지금의 목적이 실행 시간을 줄이는 것인지, 흐름을 이해하는 것인지 구분한다.
다른 사람이 작성한 예제를 읽는다면 전제부터 찾아보는 것도 좋다. 어떤 입력을 받는다고 가정하는지, 어느 함수가 시작점인지, 결과를 누가 사용하는지다. 문장마다 주석을 붙이는 대신 이 세 가지를 자신의 말로 적어보면 모르는 부분을 발견할 수 있다. 설명이 막히는 곳이 다음에 볼 위치가 된다.
작은 프로그램을 모두 작은 도구로 남겨야 하는 것은 아니다. 필요한 행동이 늘어나면 라이브러리나 더 큰 구조가 적절해질 수 있다. 다만 확장하기 전에 지금의 모형으로 무엇을 이해했는지 정리해두면 새 구조에서도 지켜야 할 규칙을 옮기기 쉽다. 짧은 코드에 머무르는 것과 이해 가능한 경계를 보존하는 것은 다르다.
더 큰 프로그램을 검증하는 질문을 다룬 글과도 연결된다. 이번에는 프로젝트의 규모를 정하는 대신 읽기 연습의 단위를 정한다. 실제 제품을 작게 만들라는 결론이 아니라, 한 동작을 스스로 설명할 수 있을 때까지 따라가보자는 제안이다.
한 화면에 들어오는 코드가 아니라, 읽고 나서 입력 하나의 여정을 말할 수 있는 코드를 골라보면 좋겠다. 빈 줄은 어디로 갔고 모르는 상태는 어떻게 남았는가. 그 질문에 답한 뒤에는 한 줄을 줄이는 것보다 한 가지 규칙을 분명하게 바꾸는 연습이 더 재미있을 수도 있다.
공개 원문을 참고해 AI의 도움으로 구성·작성한 글입니다. 가상 예시는 실제 수행 결과와 구분했으며, 표지는 Google Gemini로 만든 개념 일러스트입니다.
