코딩적 주관과, 클린 코드라는 이상

사실 클린 코드라는 개념, 목적 자체는 개발자라면 누구나 추구하는 것이다.

그러나 이런 목적에 대해서 그 방법론을 소개하는 경우, 사실 객관적인 증거를 들기보다는

그냥 추상적인 개념을 새로 가져와서 드는 경우가 있다. 그리고 사실 좀 더 사람들이

관심가질만한 소재일 수록 살살 글에 녹이면 사람들이 찰떡같이 믿게 되기도 한다.

 

나는 예전에 유행하던 클린코드 책에서 indent를 가급적 하지 말라는 말을 보고 그냥 그 책을 덮어버렸다.

그 부분에서 뒤에도 볼 것도 없이 헛소리라고 생각했기 때문이다. 오랜 기간 코드를 유지 보수해본 경험상 내 노하우는 그와 정반대의 노선에 있었다. 언어학적으로도 옛날 노엄 촘스키의 주장과도 같은 얘기에 불과했다. 머릿속에 언어학에 대한 선천적 언어장치가 있어서 인터프리트해준다는 인식을 기반한 것이다. 그러나 AI의 발전으로 눈앞에 증명된 양상은 그냥 무수한 반복 학습이 언어의 형성과 구성을 도와주며 그동안 심리학, 교육학 이론 등에서 제기된 모방이론 등이 더 인간의 언어적 구성을 설명하는데에 합당하다는 것을 멀리 갈 것도 없이 그 자체로 증명해준다. 그렇기에 10:1에서 10이 동일한 코드를 읽는 시간이라는 것은 그냥 언어학적으로 말이 안 되는 소리인 것이다. 설령 둔재라 해도 10이 동일한 코드를 읽는 시간이었다면, 그 다음은 9, 그다음은 8, 그리고 7, 그리고 6.. 이런식으로 점점 짧아지고 그렇기에 오히려 동일한 코드를 무수히  많이 보면 볼 수록 인간의 인지능력은 빠르게 확장되어 더 빠르게 처리하고 더 빠르게 오류를 잡아낼 수 있다. 그 내용은 마치 이해와 암기를 따로 인식하여 약팔이 하는 사람들과 같은 맥락을 같이 한다. 실상은 정반대이다. 이해를 극단적으로 잘 하면 암기도 잘하게 되고 암기를 극단적으로 무수히 하면 이해도 당연히 높아진다. 동일한 구조를 무수히 많이 본다면, 재구조화, 개선은 언어학적, 교육학적, 심리학적 3관점에서 볼 때 이론적으로 훨씬 빨라진다.

 

그리고 헛소리일 것이라는 이러한 생각은 다음의 영상들과 내용들 때문에 더 굳어져왔고 그냥 TDD와 다름없는 약팔이, 그냥 일시적인 유행 정도로만 생각하고 덮어버렸다.

https://www.youtube.com/watch?v=HoP8qWpucWA 

 

https://www.skullkim-dev.com/2023/02/21/is-clean-code-answer/

클린 코드가 정답인가? - skullkim | skull | iskull | yunki kim | 김윤기

​

https://overreacted.io/ko/goodbye-clean-code/

잘가, 클린 코드

 

 

그런데 얼마전 면접에서 관련 내용을 물어보는 팀이 있었다. 심지어 그 팀은 전설적인 개발자들이 모인 팀이라고

내가 생각하던 분들이었다. 실제로도 우리나라에서 보기 드문 순수 인디정신의 개발자들이고 전설을 새로 써내려가고 있는 그룹이었다. 그렇기 때문에 속마음은, '아니, 이렇게 전설적인 분들이 아직도 이미 철 지난 클린코드 유행을 믿으세요?' 내지는 혹은 '나를 거르려고 함정을 까시는 건가?' 하는 마음이 들었다. For문을 나누어 놓은 부분에 대한 것이었는데, 나는 그냥 내가 설계한 코드이기에 이래서 이렇게 설계하였다라고 하였고, 그 부분에 대해서 태클이 들어왔다. 그래서 나는 관련 설명을 생성에서 다 적어놓은 것을 보여주었다. 하지만 별로 수긍하는 것 같아 보이지는 않았다. 나름대로 다른 입장에 대하여 경청을 하는 모습을 보여준다고 생각을 했는데, 전혀 다르게 생각하시는 것이 느껴졌다.

 

여기서 나는 일종의 충격을 받았는데, 같은 게임 개발자여도 클린 코드라는 것을 추구하기도 하는구나 하는 것이었다. 그래서 나는 클린코드 관련한 내용들을 쭉 읽어보면서 혹시 내가 우물안의 개구리였던 것은 아닌가 하고 생각하였다. 그러나 읽으면서도 한참동안은 대체 왜 이 클린코드를 내게 물어본 것인지 다소 의문이긴 했는데 처음에는 정말 당시 혼란스러운 와중에 적은 메일이 좀 '재수없게 이력서 메일을 약간 잘난 척 하듯이 보낸' 것처럼 보이긴 하다는 점이었고 그래서 애초에 뽑을 마음이 없었다는 것이 좀 유력한 가능성이 있어보였다. 하지만 그럼에도 불구하고 의문이 좀 해소되지 않았기에, 생각을 다시 정리해보았는데 어쩌면 클린코드 자체를 정말 신뢰하는 것일지도 모른다는 생각이 들었고 그렇다면 전설적인 분들이 옹호하는 클린코드라면 실무에서 유용성이 확실히 있긴 있다는 것인가? 하는 생각이 들었다. 하지만 아무리 보아도 마감 기한이나 데드라인을 앞둔 게임개발자가 그렇게 시간을 굳이 내어 for문 나눠놓은 것까지 일일히 다 변수를 선언하며 뜯어고친다면, 시간 효율성이 너무 떨어질 것이 분명했다. 그래서 내린 나름의 결론은, 작품이 성공한 분들의 입장과 그 전의 개발자의 입장, 그리고 팀 개발과 1인 개발은 입장자체가 다를 수도 있겠다는 것이다. 즉 이미 성공 궤도에 올라 유지 보수에만 집중하고자 하는 운영진이라면 사실 시간은 어느 정도 여유가 있으니, 모든 변수 하나하나를 알아보기 쉽게 코드를 다 뜯어고치는 것이 더 매력적으로 느껴질 것이다. 하지만 성공이 보장되어 있지 않고 온갖 에러가 나는 와중에 불량률 0%을 준수하여 제품을 최종 완성하는 데 매달려야 하는 개발자라면, 그런데 시간을 쓰기보다는 '가독성을 높이는' 정도에 더 포커싱을 두어 시간이 지나도 알아볼 수 있는 '깔끔한' 기준에 부합하는 코드를 작성하고 바로 수행해야할 다음 작업으로 넘어갈 것이다. 여기서 입장이 갈리지 않나 하고 생각한다. 팀 기준 개발과 1인 개발의 차이이라면 생각해보면 더 선명하다. 그들은 거의 공동 대표에 가깝고 나는 그냥 실패한 개발자이다. 성공한 사업장의 대표라면, 사실 팀원을 구한다고 해도 클린코드라는 기준이든 어떤 기준이든 선명한 기준을 그대로 따르는 개발자들이 좋을 것이다. 들어와서 가르칠 수도 있겠지만 그보다는 미리 알고 있는 사람이 좋을 것이다. 그래서 나는 1인 개발자를 추구하는 사람들이 아니라 나중에라도 혹은 지금 당장 취업을 목적하여 프로그래밍을 하고 있는 사람들이라면 나처럼 살지 말고 차라리 클린코드라는 책을 읽어보기라도 하고 싫으면 덮고 이렇게 사는 것을 권한다. 나는 내 분풀이나 내 기분 때문에 사실이 아닌 것을 사실이라 하지 못하는 성격이고, 괜한 오해나 폐를 끼치는 것을 다소 싫어한다. 그래서 나는 그분들을 위하서라도 클린코드 자체를 믿지 말라 이런 말을 함부로 하지는 못하겠다. 실제로 나에게는 게임개발을 하면서 여유있게 내 게임도 만들고 전문직 공부도 같이 할 수 있는 하나의 가능성을 소멸시킨 셈이 되었으니까.  어떻게든 버틸 수는 있겠지만 다시 초조한 상황이 되었다.

 

결국 내가 내린 결론은 다음과 같다. 클린코드라는 것은 부정하는 것도 긍정하는 것도 쉽지 않다.

사실 누구나 추구하는 것인 동시에 다만 누군가의 말이 절대적으로 옳다는 것은 쉽게 실현되기 어렵다.

그것은 결국 각자의 코딩적 주관이기 때문이다. 

*프로그래밍적 주관이라고 안 쓰는 까닭은 코딩은 주관이 있지만 프로그래밍은 주관이 없다고 생각하기 때문이다.

깔끔한 코드라는 의견의 대립은 있을 수 있어도 자료구조와 알고리즘에 대해 의미와 무의미를 따질 수는 없다.

 

이른바 마법사에게는 마법적 주관이 있는 것과 같이, 프로그래머에게는 각자의 코딩적 주관이 있다.

그리고 이 코딩적 주관은 각자의 입장에 따라서 답이 다를 수밖에 없다.

분명 무엇이 더 좋은 코드인지에 대한 정의를 물어도 사람들의 의견이 다른 것은

그것은 개개인의 경험과 놓여진 상황에 따라서 각자가 지닌 코딩적 주관이 다르기 때문이다.

 

클린코드 책을 다시 읽어보면서, 클린 코드라는 목적 자체가 틀린 것은 확실히 아니고, 나처럼 아예 처음부터 불신하고 책을 덮어두고 관련 개념을 배워두지 않는 것도 뭐 꼭 좋은 것은 아니라고 생각이 든다. 왜냐면 경험적으로 이런 케이스도 있기 때문이다. 다만 나는 보다 1인 개발자, 그것도 아직 성공을 하지 못하였지만 앞으로 완성을 하고자 하는 많은 초보 개발자들을 위하여, 그들이 확실한 '클린한 코드'에 달성하는 단 한 가지의 방법을 알고 있다. 이것은 수십 수백 수천 페이지의 책을 읽을 필요도 없고 이론도 필요 없다. 원래 진리란 간결하고 단순하며 5살 짜리 아이도 공감할 수 있는 성질의 것이다. 나는 이렇게 생각한다. 그렇기에 나는 클린코드의 저자인 로버트 마틴이 추구하는 목적에는 십분 공감하지만 사실 방법론을 주장하면서 구체적인 증명과 검증의 과정 없이 ~~하면 ~~~더 좋을 것이다. ~~~하면 ~~~더 깔끔할 것이다. ~~~하면 나중에 봐도 좋을 것이다.~~ 개념만 던지고 보는 식이어서 결국 엉뚱한, 모순되는 방법을 제시했다고 나는 생각한다.  바로 인덴트를 최대한 적게하는 것이 좋을 것이다라는 추상적 사고의 편견이 이 모든 쓸데없는 방법들을 살에 살을 붙여 늘리게 된 주 원인이라고 생각한다. 해서 내가 제시하는 방법은 이것이다. 사실 인덴트는 매우 당장은 귀찮은 짓이고 이것 때문에 로버트 마틴은 그렇게 생각해볼 생각을 한 것 같다. 허나 그것에 대한 실제적 검증을 10년간 해보지 않은 것이 그의 패착이 되었고 그가 제시하는 후속하는 좋은, 논리적으로 타당한 개념들과 이에 대응하는 방법론들의 현실적 괴리가 발생하지 않았나 한다. 내가 공감하는 보이 스카우트 원칙과 그의 방법론들은 전혀 손 발이 맞아떨어지지 않는다고 생각한다. 하지만 나는 아직까지 실패한 게임개발자에 불과하고 메시지보다 메신저를 선택한다면 내가 아닌 상대방을 택하길 바란다. 사실 나중에 성공하고 기재할까 했지만 그런 날이 올까 싶어서 일단 글을 적어보고 마는 것이다. 나란 놈도 참 유약하지 않나 싶다.

 

 

 

1단은 전제 2가지는 이것이다.

'귀찮아도 Indent'해라.

'지금 Indent해두면 나중에 무조건 편해진다.'

 

그리고 절대 명제가 있다.

1. if, else, for, switch, 등에 '{'나 '}'를 쓸 때는, 블럭 안의 내용을 모두 100자 내외의 한 줄로 작성할 수 있지 않다면,

   내용이 단 한 자라도 들어있는 이상  꼭 그 가로 위치를 일치시킨다. 

2. '{'와 '}'가 여러번 중첩되는 경우 동일한 위계의 문장들은 Indent 정도를 반드시 일치시켜라.

3. 하위 위계의 문장들은 상위 위계의 문장들보다 반드시 Indent 되어야 한다. 

 

* 이를 잘 살펴보면, if a {}는 해당사항이 없다.

* 또한 if (a==1) exit; 도 해당사항이 없다.

 

예를 들어, 다음과 같이 작성하는 것이다.

using System;
using System.Collections.Generic;
using System.Text;
namespace CSharp
{
    //observer Pattern
    class InputManager
    {
       public delegate void OnInputKey();
       public event OnInputKey InputKey;
       
       public void Update()
       {
           if (Console.KeyAvailable == false)
               return;
           ConsoleKeyInfo info = Console.ReadKey();
           if (info.key == ConsoleKey A)
           {
               //모두한테 알려준다!
               InputKey();
           }
       }
    }
}

 

 

이 작업을 해두면 실제로 3년이 지나도 5년이 지나도 7년이 지나도 9년이 지나도 10년이 지나도 

프로그래밍적 인사이트만 있다면 충분히 코드를 바로 바로 해석해서 작업을 해나갈 수 있다.

못 믿겠으면 하지 말아도 좋다. 객관적으로, 나는 실패한 개발자니까.

하지만 확실히 하다보면 다른 것을 느끼게 될 것이다.

 

왜냐하면 이건 실증적으로 내가 직접 전혀 다른 전공분야만 수업들으며 외대앞- 강남역의 거리를 오가면서도

어플도 만들고 출시하고 프레임워크도 만들고 개발할 수 있는 원동력 중 하나로, 한참 시간이 지난 코드를

다시 봐도 한 눈에 알아볼 수 있게 된 원동력이기 때문이다. 사실 이건 내 비법 중의 하나로 여겨 감춰오던 

것이기도 하나, 클린코드라는 키워드가 계속 내 마음속에 자리를 잡아 생각을 거듭하던 끝에 적게 된 것이다.

어쩌면 독자들을 위해서는 좋은 결과일지도 모르겠다. 

 

이런 걸 알면 손코딩도 훨씬 수월해진다. 기준점이 잡히기 때문이다.

손코딩은 그리고 A4용지 묶음으로, 묶어주는 집게 등을 사놓고 하는 걸 권장한다.

노트는 칸 수 등의 제약되는 한계점이 많기 때문이다. 

프로그래밍적 지식이 많고 경험이 쌓일 수록 손코딩이 익숙하면 좋은 점이 많다.

코드 줄 수를 줄인답시고 같은 코드를 줄이고 줄이고 줄이거나 한 줄에 밀어넣고 보는 것은 중요치 않고

전체 구조를 보고 축약해서 적을 수 있는 것이더 중요함을 점차 깨닫게 될 것이다.

즉 '전체 구조를 축약하여 볼 수 있는' 눈이 성장하게 되고 그래서 300줄 1000줄 10000줄이 넘는 코드라도,

매우 빠르게 해독하고 이해하고 작성하며 로직에러를 캐치할 수 있게 된다.

서브 노트북이 필요없이 구조를 옮길 수 있다는 것도 강점이다.

단 깜지, 반성문 식으로 모든 걸 적는 것은 제대로된 손코딩이 아니다. 축약하고 압축하고 정리할 수 있을 수록

지식과 눈이 높아졌다는 의미이다. 만약 손코딩 과제를 냈다면 그냥 키워드만 적고 인덴트만 바로 해도

맞게 해줘야한다.

 

나는 이것이 결코 다른 코드들보다 좋은 코드라고 주장하지 않는다. 

그래서 이런 코드 스타일을 믿고 다른 사람들이 짜놓은 코드들을 헤집어 놓는 것도 옳다고 생각하지 않는다.

하지만 그들이 추구하는 '클린' 내지는 'Lean'한 코드에는 도달할 수 있게 만들어 줄 것임을 나는 안다.

이런 방식이야말로 그들이 말하는 것처럼 '애자일'하며 시간 소모가 '최소'에 가깝고, 나중에 봐도 한눈에 알아본다.

결국 그 모든 이들은 먼 방황가 길고 긴 강을 건너 다시 이 길로 돌아오게 될 것이다.

 

나는 존 돌턴과 같은 운명을 지닌 이 같다.

내가 무슨 말을 할 때 다들 내 말을 부정하고 소리를 질러대지만

시간이 지나면 결국 "그래. 그러고보니 자네 말이 맞았군."하게 된다.

그런데 나는 그것이 결코 승리라고 생각되지 않는다.

 

왜냐면 죽어서 인정받으면 뭐하고 돌 던짐을 받고 창으로 배를 뚫리며 배척받았다가 신앙처럼 추앙받으면 뭐하는 가.

내가 추구하는 것은 솔몬처럼 지나친 관심과 지나친 돈과 지나친 애정 지나친 명예 없이도

자기가 하고 싶은 것을 하며 자유로우면서도

제 때 제 때 필요한 빵과 애정과 사랑이 있는 행복한 삶이다.

그런데 그게 참 어려운 것 같다.

 

통찰력은 없는 이에게는 불행을 가져주고

있는 이에게도 고통을 가져다 주는 지도 모르겠다.

 

 

// 절대 명제 개정사항 2023/06/05 : 편의를 위해서 다음과 같이 개정합니다.

절대 명제대로 하는 게 해독은 쉬운데 저 부분까지 하는 것이 

아주 사소한 부분까지 세로로 너무 길어지는 경향이 있는 부분이 있는 것 같아서 이렇게 합니다.

 

1. if, else, for, switch, 등에 '{'나 '}'를 쓸 때는, 내용이 단 한 자라도 들어있는 이상

    꼭 그 가로 위치를 일치시킨다. 

를

1. if, else, for, switch, 등에 '{'나 '}'를 쓸 때는, 블럭 안의 내용을 모두 100자 내외의 한 줄로 작성할 수 있지 않다면,

   내용이 단 한 자라도 들어있는 이상  꼭 그 가로 위치를 일치시킨다.