클린코드와 표준

협업에서는 사람이 읽기 좋은 코드를 중요시 여긴다. 그를 위해서 각종 컨벤션과 린터등의 코드 스타일링 도구들이 존재할 정도로 사실 좋은 코드와 읽기 좋은 코드 중 무엇을 중요시 여기는지 명확하진 않지만 좋은 코드와 읽기 좋은 코드의 차이가 거의 없어서 구분 짓기 힘드니 명확히 구분 짓는 것도 그다지 중요하지는 않는 것 같다.

개발자는 대부분 클린코드를 생산 하는 것을 지향한다. 물론 이에 동의하지 않는 사람들도 존재하겠지만 일정상의 이유나 클린코드는 좋은 코드가 아니다. 등의 이유는 리팩토링 기법에도 상반된 기법이 존재하듯이 클린코드 자체도 사실 이미 명확한 표준이 아니라 추상적인 지향점을 표현하는 단어다보니 의미가 없는 반박이다.

나는, 적어도 이글에서는 클린코드를 적절한 코드를 나타내는 단어로 사용한다.
클린코드를 위해서 미리 약속된 변수 네이밍 컨벤션 또 코딩 컨벤션 또 디자인패턴이나 아키텍처 등을 적절히 잘 적용해서 코드를 짜야한다. 또 코드리뷰를 통해서 서로 간의 약속된 방식으로 코드를 개선한다.

그리고 그보다 큰틀에서는 합의 된 RFC나 표준 같은 규약들을 지켜야한다. 예를 들자면 REST API가 있겠다.
그런데 클린코드에는 대부분의 사람들이 동의를 하지만 REST 등의 규약에는 신경쓰지 말자는 사람들이 꽤 보인다.
실제로 신경쓰지 않고 개발을 하는 사람들도 많이 보이기도 한다.

물론 나도 모든 규약이나 규칙을 충실히 지켜야한다고 주장하는 입장은 아니다.
애초에 표준이나 규약등은 고정된 정답이라기 보다는 발전 과정에 있는 가장 기본적인 것들을 추상화해서 정해놓은 규격에 가깝다보니 해당 표준이나 규약에서 벗어나서 특정 도메인에 최적화 된 구조나 또 해당 표준보다 발전한 표준이 될 수 있는 가능성을 가진 새로운 패러다임 일 수 있기 때문이다.

그렇다고 나는 그것들을 신경쓰지 않아도 된다는 주장 등에는 절대로 동의하지 않는다. 왜냐하면 해당 요소들 역시 클린코드를 구성하는 요소들에 해당하기 때문이다. 합당한 이유가 없는 표준의 무시는 사실 그냥 사내 코딩컨벤션 따위를 무시하는 행위와 다를바 없다. 즉, 협업에 도움이 되지 않는다. 또 전문성이 있는 행위도 아니다.

협업을 위해서는 당연히 클린코드를 지향해야한다. 즉, 다른 사람과 자신이 추후에 변경하기 쉬워야하고 그리고 그러자면 기본적으로 코드를 이해하기 쉬워야한다. 클린 코드들은 실력 있는 개발자들에게는 이해하기가 쉽다. 목적성이 뚜렷하고 익숙하기 때문이다. 반대로 그런 것이 없고 자의적으로 아무렇게나 짜여진 스파게티 코드는 누구나 이해하기 어렵다. 논리적이지도 않고 합당한 이유가 없어서 그 목적을 찾기 힘들기 때문이다.

잘못된 사례를 들자면 합당한 이유 없이 웹어플리케이션에서 REST 규약을 무시한 API등이다. HTTP 메소드를 POST만 쓴다거나, HTTP status를 200만 쓴다는 경우 등이다. 일반적인 환경에서 웹어플리케이션 API를 GET, POST, PUT, DELETE등의 메소드들을 사용하지 않고 설계 할 이유는 사실 거의 없다.

POST만 사용하는 이유로 GraphQL처럼 여러 요청을 합쳐서 네트워크 비용을 줄인다는 목적이라 할지라도 그 중심이 되는 행위는 CRUD중 하나로 정의 내릴 수 있다. 애초에 이같은 주장은 프로젝트 설계는 물론 REST 규약에 대해서 제대로 이해를 못하고 있다는 것을 나타낸다.(캐시 등) HTTP status를 200만 쓰는 경우도 서버에 장애가 났을 경우 등 예외 상황에 대한 에러처리를 추가적으로 해줘야한다. 이게 편리한가? 나는 모르겠다.

기본적으로 이에 대해서 잘 이해하고 있는 상식적인 입장에서 보았을때 해당 구조는 프로젝트를 이해하는데 장애로 작용한다. 해당 구조에 명확한 목적이 없기 때문이다. 보통 해당 경우 주된 이유가 자신들이 기존에 작업해오던 방식이라서 또 그게 편해서 정도가 이유이다. 다른 사람들 입장에서는 그 구조를 보았을때 해당 프로젝트의 어떤 특이점이 문제가 되어서 해당 구조를 가지고 있는지 고민하게 된다. 그리고 그 이유를 찾기 위해서 리소스를 사용하고 찾지 못한다.(없으니까)

그리고 자연히 그러다보니 프로젝트의 모든 구조를 분석 할때까지 (사실 이런 경우도 드문것 같다. 다른 사람들 사례를 보면) 그리고 분석이 끝난 이후에도 신중히(자신이 찾지 못했을 수 있으니) 해당 구조를 덜어낼때까지 리소스가 소모된다. 어쩌면 그 구조를 유지하기 위해서 적합한 구조를 포기 할 수 도 있다. 이를 기술부채라고 부르는데 이는 당연히 긍정적이지 않다.

해당 선택을 한 사람이 마음을 고쳐먹고 그 구조를 덜어내면 좋겠지만, 그럴 가능성은 알다시피 희박하다. 또한 해당 이유가 합당하지도 합리적이지도 않기에 보통 잘 전달 되지도 않는다. 그렇게 의미 없는 기술부채가 자연히 다른 개발자들의 리소스를 무의미하게 소모하고 실력 있는 개발자들이 꺼려하는 환경으로 변하고 악순환이 반복된다.

특정계기가 생길때까지 물론 보통은 그런 계기를 통한 변화가 일어나지 않는다.기술 부채에 대해서는 따로 글이 길어질거 같아서 따로 써봐야겠다. 나는 합리적인 기술부채는 좋다고 생각한다. 다만 위와 같은 이유로 합당한 이유가 없는 기술부채를 만드는 행위를 매우 싫어한다.