클린코드에 대한 단상

휴대폰으로 커뮤티니 앱에서 발견한 글이다. 읽어 보면서 나와 생각이 조금 다를 수 있다 판단하여 내 생각을 옮겨본다. 저분의 글에 대해서 댓글을 달고 토론을 할 수 있었으면 좋겠는데 그게 가능하지 않아서 여기에 남겨본다.

"누군가 프로토타이핑 코드는 엔지니어링 가치를 포기하고 비지니스 가치를 선택한다고 판단할지 모르겠다. 하지만 내 생각은 다른다. 내가 아는 모든 엔지니어링의 정의는 제한된 자원을 목적에 맞게 가장 효율적으로 사용하는 것이라고 말한다. 상황에 따라선 프로토타이핑 코드가 최선의 엔지니어링일 수 있다" 라는 의견에 대한 반대 생각이다.

일단, '프로토타입코드'의 범위가 어디까지인지에 따라서 나는 반대가 될 수도 저 의견에 찬성이 될 수 있다고 생각한다.

탈고의 과정을 거친 코드인가?

 개발자가 코드를 작성할 때는 경력이나 경험에 따라서 몇가지 과정을 가지고 있다. 경험이 적은 개발자 일수록 기능이 작동여부를 중요하게 생각하는 경향이 있다. 그래서 자신이 짠 코드가 작동하면 그것으로 문제 해결이라고 보는 것이다. 하지만 숙력된 개발자는 글쓰기와 같은 과정을 코드에도 적용하게 된다. 자신이 본 문제를 자신의 생각으로 코딩을 해보고 문제 기능적인 문제 해결이 되는지 확인이 되고 나면 코드의 문맥 흐름과 구조에 대한 손을 보게 된다. 즉 글쓰기에서 자신의 생각을 일단 편안하게 작성하면서 문맥의 흐름을 맞추고 이런 저런 내용의 보완을 하여 자신이 쓴 글이 하고자하는 이야기의 당위성을 만들어가는 과정을 거치는 것이다. 보통 이런 과정을 글쓰기에서 탈고의 과정이라고 부른다.

 코드 또한 마찬가지다. 내가 작성하여 배포에 적용되는 코드는 제품에 적용되는 코드이다. 제품과 시제품은 다르다. 시제품은 본 기능이 제대로 작동하는지 기능적인 관점에만 치중하게 되어있다. 하지만 제품은 고객에게 인계되는 미려함이 담겨져있다. 

 코드가 하는 일은 고객의 문제를 해결 해 주는 것이 1차적인 목적이다. 하지만 1차적인 목적을 하고나면 소프트웨어라는 특성이 가지는 다음의 특성을 만나게 된다. 변경이 발생하게 된다는 것이다. 고객에게 필요한 목적달성을 하고 나면 다시금 고객에게 필요한 목적 달성의 변경으로 코드의 변경을 유발되게 된다. 코드의 변경이 유발될 때 우리는 만나지 못한 2차적인 고객의 요구에 부합하지 못한 것을 발견하곤 하는데 그 고객은 바로 우리들 자신이라는 것이다.

 그 코드가 당시의 환경에는 알맞았고 그 구조가 적당했기 때문에 합리적이다. 이런 이야기를 하는 것이다. 아니라. 그 코드가 만약 탈고의 과정을 거친 코드라면 그 당시의 역사적 사유에 대해서 받아들일 수 있을 것이다. 하지만 탈고의 과정을 거치지 않은 익명게시판에 아무렇게나 싸지르는 키보드 워리워와 같은 덧글과 같다면 그것은 비지니스의 가치와 엔지니어링 가치의 트레이드 오프에 대해서 이야기할 대상 자체가 되지 못 한다는 것이다.

 내가 생각하는 클린코드라는 것은 그런 것이다. 구조적으로 확장성이 대단히 고려가 되었고 SOLID 원칙을 치쳤으며 패턴적용이 미려하고 이런 거시적인 이야기가 아니다. 서로 다른 실력을 가지고 있는 개발자가 당시의 수준으로 자신이 풀이한 문제해결의 코드가 1차원 적인 고객만을 생각한 것인지 2차 고객인 자신을 생각하여 탈고를 거친 것인가? 에 따라서 클린코드로 가기 위한 여정을 거쳤느냐 아니냐는 것이다. 즉 클린코드로 가기 위한 과정은 트레이드 오프의 대상이 아니라는 것이다. 클린코드로 가기 위한 행위나 생각은 필수라는 것이 내 생각이다.

 많은 초급개발자들이 제품코드에 코딩을 하는 모습을 자주 볼 수 있다. 그리고 문제 해결이 되면 아무런 생각이 없이 그 제품에 커밋을 하고 이슈관리에 이슈를 클로즈하는 모습을 볼 수 있다. 하지만 노련한 개발자일 수록 문제 발생이 일어난 부분을 덜어내서 문제 해결의 목적에 맞는 코드를 만들고 그 코드를 다시 제품코드에 적용하기 위한 노력을 한다. 이 과정에서 TDD방식이 수행될 수도 있을 것이다. 이 과정이 클린코드를 만드는 과정인 것이다. 그 여정을 시작했다면 조금 미흡할 수도 있고 매우 훌륭할 수도 있는 코드가 제품에 적용되어 제품코드 다운 일을 하게 될 것이다. 하지만 이런 과정이 없는 코드는 제품에 답기 위한 코드로 볼 수 없다는 것이 나의 개인적인 생각이다.

 즉 클린코드를 만들기 위한 노력은 비지니스 대응을 위한 트레이드 오프의 대상이 아닌 것이다. 그냥 몸에 베인 것이고 누구나 그렇게 하는 것이다.

 저 글의 내용을 따라 링크된 글을 보면 그 글에서도 당시의 기술적용에 타협을 하는 내용이 나온다. 최신기술을 쓰고 더 합리적인 기술과 구조를 만드들고 하는 것들만이 클린코드를 위한 과정으로 본다면 트레이드 오프 대상이 될 수 있다. 하지만 작은 범위로 들어가서 개발자 개개인이 작성하는 코드 한줄 한줄은 그냥 나와야되는 코드는 아니라고 생각한다. 클린코드의 과정은 개발행위의 가장 기저에서 수행되어야되는 루틴이다.