좋은 코드를 판단하는 건 주관이다.

좋은 코드를 판단하는 건 주관이다.

이 글을 읽으면 다음과 같은 내용에 대해 최소한 생각할 거리를 얻어갈 수 있기를 기대한다.

• 읽기 쉬운 코드란 무엇이고
• 왜 읽기 쉽게 작성해야하고
• 그런 코드는 어떻게 탄생하는지

가독성은 본질적으로 주관적인 것이며 그것이 정확히 무엇을 의미하는지 확실하게 정의하기는 어렵다. 가독성의 핵심은 개발자가 코드의 기능을 빠르고 정확하게 이해할 수 있도록 하는 것이다. 실제로 이렇게 하려면 다른 사람의 관점에서 보았을 때, 코드가 혼란스럽거나 잘못 해석될 수 있는지를 상상하고 공감해야 할 때가 많다.

위 내용은 좋은 코드, 나쁜 코드 : 프로그래머의 코드 품질 개선법이라는 책의 한 부분이다.

이 책에서 말하는 코드 품질의 핵심 요소가 여러가지 있는데 그 중 하나는 가독성이다.

즉, 코드는 근본적으로 읽기 쉬워야한다는 말이다.

읽기 쉬운 코드를 판단하는 건 주관이다.

그런데 코드는 읽는 사람의 주관에 따라 읽기 쉬울 수 있고, 읽기 어려울 수 있다.

그럼 이제 이쯤에서 이런 생각이 든다 그럼 누가 정답인데?

내가 생각하기에는 그건 팀 내에서 적절한 타협점을 찾아가는 과정이 필요할뿐 정답은 없다.

그리고 사실 우리는 애초에 읽기 쉬운 코드를 작성해서 해결하고자 하는 문제는 무엇인지 생각해볼 필요가 있다.

읽기 쉬운 코드를 왜 작성해야 하는가?

읽기 쉬운 코드를 왜 작성해야할까? 여러가지 이유가 있겠지만 내가 생각하는 건 이 정도다.

• 빠른 비즈니스 성장을 위해 언제 누가 작업하든 빠르게 온보딩하고 쉽게 코드를 수정할 수 있어야 한다.
• 안전한 비즈니스를 위해 프로그램의 버그를 최소화해야 한다.

빠른 비즈니스 성장을 위해 언제 누가 작업하든 빠르게 온보딩하고 쉽게 코드를 수정할 수 있어야 한다.

스타트업에서 일하면 특히 그렇겠지만 빠른 비즈니스 성장을 위해 코드는 자주 배포되어야한다.
이런 맥락에서 코드가 이해하기 쉽게 구성되어 있다면 누구든 코드를 쉽게 수정하고 배포할 수 있을 것이다.

반대로 안타깝게도 이런 기술력이 뒷받침되지 않는다면, 배포는 늦어지고 시장에서 밀려나는 매우 슬픈 상황이 펼쳐질 수도 있다.

또한 이건 슬픈 현실이지만 기업 입장에서 사람은 언제든 교체될 수 있다. 그래서 누가 오든 빠르게 온보딩할 수 있는 것도 중요하다. 그런 의미에서 알아보기 쉬운 디렉토리 구조 등도 도움이 된다.
기업에 남는 사람에게도, 새로 들어오는 사람에게도 말이다.

안전한 비즈니스를 위해 프로그램의 버그를 최소화해야 한다.

읽기 어려운 코드는 이해하기 어렵다는 걸 뜻하고 이는 곧 버그를 유발하는 코드를 발견하기 어렵게 만들 것이다.

당연하게도 돈이 오가는 프로그램의 버그는 한 순간에 비즈니스에 치명상을 입힐 수 있고
그래서 안전한 코드와 이를 도와주는 코드 리뷰도 중요하다.

프로그램의 버그를 모두 통틀어서 절대적으로 막아야한다는 말은 아니다.
버그가 없는 100% 가용성을 집착하다보면 팀 내의 리소스를 적절하게 사용하지 못하고 원하는 비즈니스 목표를 이루기가 어려워질 수 있다.

그리고 사실 실제로 서버에서 버그가 발생하더라도 유저에게 바로 큰 영향이 없는 경우도 있다.
심지어 앱에서 버그가 발생하더라도 그 서비스가 유저 마음 속에 이미 자리 잡았다면 유저는 다시 앱에 찾아올 것이다.

그래서 이 버그가 정말 치명적인지 판단할 수 있는 지표와 판단 능력도 중요하다.

결국 비즈니스 목적에 맞게 판단해야 한다

위에서 이야기 해본 바로는 읽기 좋은 코드를 작성해야 하는 이유는 비즈니스의 원활한 성장 때문이었다.

그럼 풀고자 하는 문제는 비즈니스이니까 사실 위 조건을 만족한다면 읽기 좋은 코드가 필요없을 수도 있다. 이건 문제를 해결하기 위한 수단 중 하나이니까.

대표적으로 일주일 뒤에 사라질 코드들은 잘 짜둘 필요가 없을 수 있다는 말이다.

하지만 좋은 개발자가 되고 싶은 개발자라면 누구나 좋은 코드(=읽기 쉬운 코드)를 작성하고 싶어한다.

그래서 읽기 쉬운 코드는 어떻게 탄생할까?

보통 코드를 처음 작성할 때면 작성자 본인의 생각으로 읽기 쉽다고 판단되는 코드를 작성할 것이다.

이 과정에서 개개인의 주관이 펼쳐지고 이후에 보통 협업을 하고 있다면 코드 리뷰 과정을 거친다.

아래의 주관들이 펼쳐지고 이런 리뷰들이 달릴 수도 있다.

(실제로 내가 남긴 리뷰거나 받아본 리뷰를 예시로 가져왔다.)

• 1. 이 변수명은 이 컨텍스트 안에 있으니 좀 더 줄여도 되겠다.
  • 리뷰어) 컨텍스트를 유지하면서 변수명을 바라보기 어려워요. 변수명을 좀 더 자세하게 적으면 어때요?
• 2. request dto에서 뽑은 데이터를 좀 더 위쪽에 미리 선언해두면 어떤 데이터를 사용하는지 보기 쉽지 않을까?
  • 리뷰어) 위쪽에 미리 변수를 선언해두는 것의 효과가 잘 공감되지 않아요. 아래에서 바로 사용해도 큰 문제는 없을 것 같은데, XX님이 어떤 문제를 느끼셨는지 말해주실 수 있을까요?
• 3. 클린 아키텍처, DDD에서 이렇게 하라고 했으니까 나도 그렇게 해야지.
  • 리뷰어) 다른 리포에서는 이런 방식을 사용하고 있지 않은데, 팀원분들이 혼란스러울 수 있을 것 같아요. 클린 아키텍처, DDD 보다는 다른 리포와 일관된 형태를 유지하는 게 어떨까요?
• 4. Java에서는 이렇게 개발했으니까 golang에서도 이렇게 하면 좋은 코드들이 나올 거야.
  • 리뷰어) 음.. 이건 golang스럽지 않은 것 같아요.

위 내용을 보면서 느꼈을 수 있지만, 논의가 길어졌을 때 리뷰 과정에서 시간이 오래 걸릴 수도 있다.
그리고 어쩌면 끝까지 파고들어서 align을 완벽하게 맞추고 싶을 수도 있다.

하지만 비즈니스가 올해 안에 망할지 모르고 다급한 상황이라면 그런 상황에서도 그렇게 하겠는가?

조직 상황에 맞게 현실적으로 고민하고 공감하는 개발자가 되어야 하지 않을까?

읽기 쉬운 코드를 결과물로 내놓는 건 결국 팀 내에서 적절한 타협점을 찾는 과정이다.

그래서 현재 조직의 상황을 충분히 인지하고 크게 문제되지 않는 적정선에서 멈추는 것도 중요하다.

결국 개발자는 비즈니스를 잘 이해하고 비즈니스를 위한 개발을 해야한다.

하지만 종종 개인 욕구를 채우려는 개발자들도 있다. 물론 그들의 욕구를 존중한다. 나도 그런 욕구가 있고 최대한 절제하는 편이고, 개발자라면 누구나 좋은 코드, 혹은 내가 생각하기에 멋진 코드 그리고 내가 쓰고 싶은 기술들이 존재한다.

그렇지만 적어도 조직에 소속되었다면, 팀으로 일한다면 좀 더 현실적으로 고민하고 다른 개발자들의 상황을 공감하며 함께 align을 맞춰가는 시간 정도는 필요하지 않을까?

그렇기에 사내 컨벤션이 생기고 자연스럽게 그 컨벤션을 지키는 개발자들을 선호하기도 하는 것 같다.

Action item

실행해볼만한 action item을 적어보자

• 좋은 코드에 대한 생각을 팀원에게 질문하기
  (투명하고 명확한 맥락 공유와 공감대 형성 필수)
  • 저는 가끔 이런 코드들로 머리가 아플 때가 있어요. xx님은 그런 경험이 있으신가요? 좋은 코드는 뭐라고 생각하시나요?
• 좋은 코드라고 생각되는 코드를 발견하면 기록해두고
  왜 그렇게 생각했는지도 기록하기
  • 나중에 누군가를 설득하기에 좋은 자료가 될 수 있음