[고찰] 프로그래밍 통찰력 (Programming Insight)

인터넷 하다가 마주한 짤

 

  요즈음 개발에대한 수요가 급증하고, 프론트 백 할것없이 기술 수준이 나날히 높아지고, 채용시장에서 요구하는 기술스펙이 다양해지고 있다.

 취업을 대비하여 거의 모든 부트캠프들이 리엑트나 스프링을 가르치고, 이 기술이 아닌 기술을 공부하는것은 취업에 도움도 안되는것에 시간을 쏟는 멍청이. 블라인드 같은데서는 쿠버니타스정도는 백엔드의 기본 소양이고, MSA 가 아닌 아키텍쳐는 구 시대의 다루기도 힘든 레거시 코드취급에 서비스회사가 아닌 SI 업계는 배울것 하나없는 개발자의 무덤

 솔직히 말해서 나는 요즘에 저런 기술 중심의 메타나, 서비스 기업에서 사용하는 기술만이 온 세상의 중심인거처럼 생각하는것이 마음에 들지 않는다. 왜냐하면 기술은 결국 취사 선택의 문제 이기 떄문이다.

그래서 그게 뭐가 그리 잘났는데?

사실 블라인드 라는 커뮤니티의 유저 풀 때문에 유난히 그런것도 있다

 나는 프로그래밍을 공부한다는것은 기술을 배우는게 아니라고 생각한다.

우리가 프로그래밍을 공부하는 이유는 프로그래밍에 대한 통찰력 얻기 위해서이다.

우리가 왜 OOP 디자인 패턴을 배우는가? 상황에 맞는 패턴을 가져와서 쏙쏙 쓰기위해서?

 아니다 애초에 디자인 패턴이 나오고 개발이 나온것이 아니기 때문에 디자인패턴은 룰이 될수없다. 우리가 디자인 패턴을 배우는이유는 펙토리패턴이 뭔지, 왜 이름이 프록시인지, 팩토리 메서드와 추상팩토리의 차이점이 뭔지를 배우는게 아니라 문제상황을 지혜롭게 해결하는 방법을 선조로부터 배우는것이다. 이것이 프로그래밍에 대한 통찰이다.

우리가 왜 OOP 솔리드를 배우는가? 공변성이라는 단어를 알기 위해서? Object-Oriented Programming 의 절대적인 룰이기때문에?

 아니다 솔리드는 외우는것이 아니다. 솔리드원칙 으로 부터 어떻게 프로그래밍해야하는지 통찰을 얻는것이다. OOP 의 원칙들을 공부하다보면 결국에 다형성을 이용한 확장성이고 디커플링이다. 프로그래밍을 하면서 자연스럽게 좋은 코드를 작성할수있고, 좋은코드로 리펙토링 할수있는 통찰력을 길러야 하는것이다.

 그렇기 떄문에 필자는 FP 찬양론자임에도 불구하고 FP 개발자들이 OOP 를 마치 시대에 뒤떨어진 저급 패러다임으로 인식하는것이 불편하다. 왜냐하면 패러다임이라는것은 결국에 "제약" 과 "툴" 이기때문이다. 본질적으로 좋은 소프트웨어 설계를 위한 요소는 FP 나 OOP 나 동일하다 [The principles of software design still apply, regardless of your programming style. by Robert C. Martin (Uncle Bob)]

 왜 클린코드와 클린소프트웨어 같은 엉클밥의 서적이 소프트웨어 서적계의 명저인가? 왜냐하면 해당 서적이 프로그래밍에 대한 통찰력을 기르게 해주기 떄문이다.

 왜 우리는 (나 는) 왜 클린코드에서 하라는 내용을 지킬수록 프로그램이 거지같아 지는가? 이는 프로그래밍에 대한 통찰력이 부족하기 때문이다. 클린코드, 클린 소프트웨어는 TODO 리스트마냥 체크리스트가 아니다. 지켰으면 OK 하고 지워지는 항목이 아니다. 왜 지키라고 하는가? 에 대한 내용이다.

"파라미터 개수를 최소화 하세요" -> "아 이 함수 파라미터가 10개네 파라미터 1개로 넘기는게 젤 좋다 그랬으니까 10개를 클래스 하나로 묶어서 ParameterGroup 라는 객체 하나만 넘기면 되는구나"  이게 아니라

"이해 할 수 있는코드 (Understandable), 읽을수 있는 코드 (Readable) 한 코드를 짜기위해" -> 파라미터가 많으면 이해하기 어려워지므로 "파라미터 개수를 최소화 하는것" 이 중요하다.

 

 프로그래밍 언어로 봤을때, 개인적으로는 어노테이션, 어트리뷰트와 같은 메타 데이터에 의존하는 프로그래밍은 언어적 한계라고 생각한다.

 1. 해당 기능의 공식적인 지원 (자바 롬복 보다 씨샵의 프로퍼티나 코틀린의 데이터가 좋다.)

 2. 언어내에서 (메타 데이터가 아닌) 기능확장 (매크로, 넓게 보자면 모나드문법)

하는것이 보다 좋은 방향이라고 생각한다.

취업을위해서 언어를 공부한다면 자바/자스 말고 다른걸 하는것은 멍청해 보일수있는데 그럼에도 불구하고, 내가 Clojure 같은 Lisp 계열이나 FP 의 모나드같은걸을 좋아하는 이유도 비슷하다.

 이러한 언어는 언어의 확장이 가능하기 때문이다. Clojure(정확히는 Lisp) 은 Programmable Programming Language 라는 별명을 가지고 있고,  Monad를  Programmable Semicolon 라고 부른다.

내가 이런 '의견'을, '언어에 대한 철학'을, '기능의 확장에 대한 욕심'을 가지고 있는 이유는, Clojure나, Monad 같은 개념을 접했기 때문이다. 만약 내가 이러한 개념을 전혀 알아보지 않았다면, 아마 1. 해당 기능의 공식적인 지원 까지밖에 생각할수없을것이다.

 내가 Clojure를 잘하고, Monad를 완벽하게 이해하고있는것은 결코 아니지만 (못한다, 먼저 알고있다 수준), 이러한 개념을 접하고, 저변을 넓히고, 해상도를 넓히는것이 통찰력에 더 도움이 된다고 생각한다.

 자바를 버리세요! 나, 기술 공부할시간에 따른것을 하세요! 나 회사들은 지금의 채용시스템바꿔라 같은 소리가아니다. 애초에 내 스펙이, 이런 말을 할만한 수준이 되는것도 아니다. 본인 자체가 뛰어난 스킬을 가진 분야가 없다보니, 자기 기술에 정통한 뛰어난 개발자를 분야 상관없이 몹시 존경한다.

 나는 회사에서 기술 경력자를 뽑는것, 해당 기술 스택에 대한 지식을 검증하기 위한 면접, 알고리즘, 코딩테스트, 과제등 비난하지 않는다. 회사는 비용을 최소화 하면서도, 검증된 기술자를 데려와야 하기 때문에, 그리고 완벽한 평가방법이란 사실 없기때문에, 약간의 오류는 있을수있어도 무난한게 채용을 진행하는게 이해가 안되는게 아니다. (약간의 오류를 예로 들면, 알고리즘은 설계를 반영하지 못하지만 평등하다, 과제는 그 사람의 프로그래밍적인 소양을 보기 쉽지만, 누구나 똑같은 시간을 투자할수있는것이 아니다. Github 포트폴리오등은 관리안하는 사람에게 불리하다.) 그리고 이러한 채용 시장에 고용되기 위해서 지능적으로 플레이하는것또한 비난하지 않는다. Spring 을 하는 회사에 가고싶으면 Spring 을 공부하는게 ASP 를 공부하는것 보다는 유리하고, 지원자입장에서도 요구하는 기술스택을 알고가는것이 예의라고 생각한다.

 내가 하고 싶은 말은 채용시장이 그렇기 때문에, 현재 유행하는 기술이기때문에, 취업시장에 유리하기때문에, 그것만이 프로그래밍의 중심인양 생각되는게 싫은것이다.

 언어를 싫어할수는 있어도 수준 낮은 언어는 없고, 사장되는 기술은 있어도 가치없는 기술은 없다. 우리는 왜 프로그래밍을 하는가? 이러니 저러니해도 좋아서 하는 개발자 아닌가? 우리는 고통받기위해서 공부하는게 아니다. 하고싶은걸 하자. 넓게 하자. 이건 멍청한게 아니라 멋있는것이고, 어떤것을 하든 통찰력과 시야를 길러줄것이다.

 

 

ps. 내글을 내가 읽어도 무슨 내용인지 이해하기 힘드네;; 이래서 공돌이들한테도 문과적 소양이 필요한가보다.