글을 쓰는 방식이 변하면 세상도 변할까? 아니면 세상이 변하면서 글쓰기 방식이 강제되는 걸까? 이 질문은 마치 닭이 먼저냐 달걀이 먼저냐 묻는 것만큼이나 답하기 어렵다. 하지만 한 가지 분명한 것은, 우리가 지금 어떤 방식으로 글을 소비하고 생산하는지가 우리의 사고방식까지 바꿔놓고 있다는 사실이다. Axios가 주창한 ‘스마트 간결함(Smart Brevity)’은 그 변화의 극단적인 사례다. 이 방식이 뉴스레터와 비즈니스 커뮤니케이션을 넘어 소프트웨어 개발 현장까지 스며들고 있다는 사실은, 기술과 언어의 경계가 얼마나 모호해졌는지를 보여준다.
스마트 간결함의 핵심은 ‘최소한의 단어로 최대한의 의미를 전달한다’는 것이다. 글머리 기호, 짧은 문장, 굵은 글씨 강조, 그리고 핵심 메시지를 맨 앞에 배치하는 방식은 분명 효율적이다. 이메일 한 통을 읽는 데 30초면 충분하고, 회의록을 검토하는 데 1분이면 된다. 하지만 이런 방식이 보편화되면서 우리는 점점 더 복잡한 사고를 회피하게 된 것은 아닐까? 개발자가 코드를 작성할 때 ‘간결함’을 추구하는 것과 기자가 기사를 쓸 때 ‘간결함’을 추구하는 것은 근본적으로 다르다. 전자는 시스템의 안정성과 유지보수성을 높이기 위한 기술적 결정이지만, 후자는 독자의 주의력을 고려한 상업적 결정이다.
문제는 이 두 가지 간결함이 서로 혼동되면서 발생한다. 개발자가 API 문서를 작성할 때 스마트 간결함의 원칙을 적용하면 어떤 일이 벌어질까? “이 엔드포인트는 사용자 인증을 요구하며, POST 메서드로 JSON 형식의 데이터를 받습니다. 응답은 성공 시 200, 실패 시 400 또는 500 상태 코드를 반환합니다.” 이 문장은 분명 간결하다. 하지만 이 문장만으로는 ‘어떤 데이터 스키마를 사용해야 하는지’, ‘실패 시 구체적으로 어떤 에러 메시지가 반환되는지’, ‘인증 토큰은 어떻게 전달해야 하는지’와 같은 세부 사항을 알 수 없다. 개발자에게 이런 정보는 필수적이다. API 문서가 Axios 스타일의 뉴스레터처럼 작성된다면, 그 결과는 버그와 오해의 연속일 것이다.
“간결함은 지식의 적이다. 지식은 불확실성 속에서 자라나며, 불확실성은 길고 복잡한 설명을 요구한다.”
소프트웨어 개발에서 ‘간결함’은 종종 ‘우아함(elegance)’과 동의어로 사용된다. 하지만 우아함은 결코 단순한 생략을 의미하지 않는다. 우아한 코드는 읽기 쉽고, 이해하기 쉽고, 확장하기 쉬운 코드다. 여기에는 적절한 주석, 명확한 변수명, 그리고 필요한 경우의 상세한 문서화가 포함된다. 반면 스마트 간결함은 ‘읽기 쉽다’는 목표를 ‘빨리 읽힌다’는 목표로 대체한다. 이 차이는 미묘하지만 결정적이다. 빨리 읽히는 글은 독자의 사고를 멈추게 만들고, 읽기 쉬운 글은 독자의 사고를 확장시킨다.
기술 문서의 세계에서 스마트 간결함이 가져온 가장 큰 문제는 ‘맥락의 상실’이다. 예를 들어, 클라우드 서비스의 보안 가이드가 “IAM 역할을 적절히 설정하세요”라는 문장으로 끝나는 경우, 개발자는 ‘적절히’가 무엇을 의미하는지 알 수 없다. 이 단어는 조직마다, 프로젝트마다, 심지어 개발자마다 다르게 해석될 수 있다. 기술 문서는 모호함을 허용하지 않는다. ‘적절히’ 대신 “IAM 역할은 최소 권한 원칙에 따라 설정해야 하며, 다음과 같은 정책을 포함해야 합니다: [정책 목록]”이라는 문장이 필요하다. 이런 상세함이 없으면 보안 취약점은 필연적으로 발생한다.
더욱 우려스러운 것은 스마트 간결함이 기술 커뮤니티의 토론 문화까지 잠식하고 있다는 점이다. GitHub 이슈나 스택 오버플로우에서 “이렇게 하면 됩니다”라는 답변이 점점 더 많아지고 있다. 이 답변은 문제 해결에 도움이 될 수 있지만, ‘왜’ 그렇게 해야 하는지에 대한 설명이 빠진 경우가 많다. 초보 개발자는 이 답변을 맹목적으로 따라 하게 되고, 결국 근본적인 이해 없이 표면적인 해결책만 반복하게 된다. 기술의 발전은 ‘왜’라는 질문에 대한 답을 찾는 과정에서 이루어지는데, 스마트 간결함은 그 질문을 생략하게 만든다.
그렇다면 우리는 어떻게 해야 할까? 스마트 간결함의 장점을 완전히 부정할 수는 없다. 바쁜 현대인에게 짧은 글은 분명 매력적이다. 하지만 기술 분야에서는 ‘간결함’과 ‘불완전함’을 혼동하지 말아야 한다. 개발자가 문서를 작성할 때는 독자가 무엇을 알고 싶어 하는지를 먼저 생각해야 한다. “이 기능을 사용하려면 이 코드를 복사하세요”라는 문장보다 “이 기능은 이러한 원리로 동작하며, 이 코드를 사용하면 이러한 결과를 얻을 수 있습니다. 단, 다음의 제한 사항에 주의하세요”라는 문장이 훨씬 더 가치 있다.
기술 커뮤니케이션의 목표는 정보를 전달하는 것이 아니라 이해를 돕는 것이어야 한다. 이해는 간결함만으로 이루어지지 않는다. 때로는 길고 복잡한 설명이 필요하다. 때로는 예시와 비유가 필요하다. 때로는 실패 사례와 그 원인을 상세히 다뤄야 한다. 스마트 간결함이 우리에게 가르쳐준 것은 ‘효율성’이지만, 기술의 세계에서는 ‘효율성’보다 ‘명확성’이 더 중요하다.
결국, Axios 스타일의 글쓰기가 지옥이라면, 그 지옥은 우리가 스스로 만든 것이다. 우리는 더 빨리, 더 많이 소비하기를 원했고, 그 결과 더 적게 이해하게 되었다. 하지만 기술의 세계에서 이해하지 못하는 것은 곧 실패를 의미한다. 이제 우리는 선택해야 한다. 더 빠른 소비의 유혹에 굴복할 것인지, 아니면 더 깊은 이해를 추구할 것인지. 그 선택은 우리의 글쓰기 방식에 그대로 반영될 것이다.
이 글의 원문은 여기에서 읽을 수 있다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
