히카맹 선생님의 코드스피츠 강의를 들으며 자바스크립트에 대한 이해를 높이기 위해 스터디를 하게 되었다. 이 포스팅은 그에 대한 정리글이다.

프로그래밍에 대한 철학적 접근

코드스피츠 ES6+ 기초편의 1화를 들으며 가장 와닿았던 부분은 자바스크립트에 대한 내용이 아닌 철학적인 접근이었다. 프로그래밍 언어가 앞으로 어떤 방향성으로 발전할 지는 모르겠으나 현재까지는 단순히 컴퓨터만 읽는 게 아닌 프로그래머들 사이의 의사소통 수단으로서도 사용되는 만큼 이 프로그래밍에 대한 철학적 접근이 굉장히 중요해보였다.

코드스피츠의 히카맹 선생님은 켄트백의 책에서 내용들을 발췌해 알려주었다

가치, 원칙, 패턴

<프로그래머인 내가 코드를 짤 때 어떤 가치를 가지고 코드를 짤 것이냐 - 가치 ->

• 의사소통 : 다른 팀원들이 코드를 봤을 때 "모두가 이해할 수 있는 코드를 짜는 것"에 집중

  읽기 좋은 코드는 결국 그 프로젝트가 얼마나 원활하게 진행되냐를 가늠 짓는 것 같다. 프로그래밍은 혼자 모든 것을 만드는 경우도 있겠지만 최소한 회사에 소속된 프로그래머인 이상 혼자만들 게 되는 경우는 없을테니까, 모두가 원활하게 읽을 수 있는 코드(이른 바 클린코드)는 팀원 간 소통을 위해서 거의 필수적인 가치가 아닐까 싶다.

  개인적인 최근의 경험으로는 진행중인 사이드 프로젝트에서 맡은 페이지를 작업하며 서비스 전체에 공통적으로 자주 쓰일 것 같은 컴포넌트를 분리하는 작업을 진행했었는데, 이 때 가장 중요하게 생각했던 것이 이 분리된 작은 단위의 요소들의 이름과 최대한 재사용 가능한 작은 단위로 분리하는 것이었다. 이 때 의사소통의 가치는 요소들의 이름에 집중했다는 것 아닐까 싶은데, 역시나 이름이 직관적인 만큼 다른 개발자가 사용하는 데 불편함이 없었다. 이런 이름에 대한 고민 덕분인 지 같이 작업하던 개발자분에게서 최고의 찬사를 들었다. "너무 직관적이고 사용하기 편한데요?"
  

• 단순함 : 구조적 관점에서 복잡성을 제거하고 이를 기반으로 "유지보수가 용이하도록 짜는 것"에 집중

  복잡한 코드는 의사소통에 지대한 영향을 끼친다. 물론 안좋은 쪽으로.
  또한 필요하지 않은 코드들이 같이 존재하고 있는 순간 가독성이 떨어짐은 물론 오독할 수 있는 경우도 늘어나 유지보수적 측면에서 효율적이지 못하다. 그러므로 복잡성을 최대한 제거하고 유지 보수가 용이하도록 해야하는 것.
  나는 알고 있다... 작성하다보면 더러워지는 내 코드.. 하지만 결국 이는 리팩토링으로 해결가능하니까 리팩토링의 중요성이기도...?

• 유연함 : 사용성 측면에서 특정 기능만을 사용가능한 함수보다는 "다양한 역할을 수행할 수 있도록 짜는 것"에 집중

  매사 특정 상황에만 사용해야하는 딱딱한 코드 보다는 다양한 환경에서 사용될 수 있는 코드가 더 높은 재사용성을 보여준다. 코드를 유지보수하기 좋게 만드는 것은 결국 높은 재사용성을 가진 코드들이 얼마나 읽기 쉽고 단순하게 만들어졌느냐가 아닐까 싶다.

<원칙을 세우고 프로그래밍해야한다. 그래야 원칙에 벗어났을 때 바로 캐치할 수 있다 - 원칙 ->

원칙의 필요는 딱딱한 규칙이 아니다. 원칙을 지켜야만 원칙에서 벗어나 버그를 일으키는 것들, 혹은 더 참신한 아이디어들이 쉽게 눈에 들어오기 때문이다. 대표적인 원칙 3가지 예시를 켄트백은 제시했다.

• 지역화 : 전역변수로 사용가능하더라도 "무조건 지역화 시켜 사용해한다"라는 원칙
• 중복제거 : 중복된 코드를 제거해나간다는 원칙(중복은 허용되지 않는다는 원칙)
• 대칭성 : get이 있다면 set이 있는 것과 같이 사용인이 해당 코드를 사용할 때 대칭적인 코드도 만들어두어 활용도를 높인다는 원칙

<원칙을 실체화시키고 실무와의 간극을 메워주는 서포터 - 패턴 ->

켄트백이 말하는 패턴은 총 3가지, 개발론, 설계론, 각종 적용 패턴이다. 무언가를 만들어나가는 방법론적인 얘기로 이해가되는데, 스스로 패턴에 대한 이해도가 떨어져 이부분은 앞으로 계속 공부를 이어나가고, 또 켄트 벡의 구현 패턴과 같은 서적들을 읽어나가야 어느정도 이해가 되지 않을까?
그렇기에 이 부분에 대해서는 이 포스팅에 대해서는 정리하지 않는 것으로 하겠다. 이해 없는 블로깅만큼이나 의미없는 것은 없으니까.

느낀 점

어쩌면 당연하다고 생각했던 그 가치들이 굉장히 중요한 철학을 내포하고 있었다는 생각이 들었다. 하지만 그 당연함은 상당히 익숙해지기 어려워 꾸준히 사고하고 학습하며 적용해야한다. 어쩌면 이 강의에서 말한 부분들은 잊고 있던 가장 중요한 사고를 일깨워줬는 지도 모르겠다.

그리고 익숙한 개념이었던 가치와 원칙과는 달리, 단 한번도 적용해본 적이 없던 패턴에 관한 부분은 스스로 이해가 잘 되지 않아 생각을 정리할 수가 없었다. 꾸준히 많은 문제들에 부딪혀 나가면서 학습해나가다 보면 패턴에 대해서도 이해와 공감이 있지 않을까?

켄트 벡의 저서를 먼저 읽어볼 필요가 있을 것 같다. 읽게 된다면 이 부분에 대해서는 조금 더 자세하게 포스팅할 예정.

프로그래밍이란?

그렇다면 프로그래밍이란 무엇인가?
내가 아는 프로그래밍은 '프로그램을 만드는 것'이라는 단순한 정의에 그쳤었다. 하지만 프로그래밍은 생각보다 더 디테일한 단어였고, 이는 꼭 숙지하고 있을 필요가 있었다.

컴퓨터 언어는 크게 두가지의 항목으로 나뉘게 된다. 첫째로는 보편적으로 사람들이 프로그래밍이라고 얘기하는 컴파일 언어(C, JAVA, C++, C# 등)에서의 프로그래밍, 그리고 두번째로는 JavaScript와 같은 스크립트 언어(인터프리터 언어)에서의 프로그래밍이 있다.

컴파일 언어의 프로그래밍 과정

위 이미지 파일은 컴파일 언어가 프로그래밍 되는 과정 순서이다. 그리고 아래는 그 과정에서 어떤 일이 일어나는 지에 대한 간략한 요약이다.

• Language code (Lint time) : 컴파일러가 검사하지 않고 Lint 가 돌면서 코드를 검사하는 단계
  • 사람이 읽을 수 있는 언어를 텍스트로 작성하는 단계 (Language code => Machine language 로 넘어가는 단계를 컴파일링이라고 함)
• Machine language (Compile time) : 컴파일러가 검사하는 단계
  • 0과 1로 이루어진 컴퓨터가 읽을 수 있는 언어로 바꿔주는 단계 혹은 그 언어
• File
  • Machine language 로 변환이 된 이후 Load 될 수 있는 상태, 즉 파일이 된다
• Load
  • File 을 클릭하면 Load 된다. 이 과정은 컴퓨터의 주메모리로 올라가는 과정이다. 코드는 이과정에 이르러서야 프로그램으로 명명된다.
• Run : 실행시점 // 만약 Run time 에도 에러가 걸리지 않았으나 실행된 프로그램에서 논리적 오류가 발생한 경우를 라고 말한다.
  • 주메모리에 올라간 이후, 즉 Load된 이후 실행을 하게 되면 비로서 프로그램이 실행된다.
• Terminate
  • 종결

스크립트 언어의 프로그래밍 과정

위 이미지 파일은 스크립트(인터프리터) 언어가 프로그래밍 되는 과정 순서이다. 인터프리터 언어는 컴파일러 언어와 달리 Language code 단계 이후 컴파일이 되지 않고 File이 브라우저에 적재(Load - 메모리 내부에 적재)된 후에 컴파일이 진행된다. 메모리 내부에서 Machine language로 변환된다.

• Language code
  • 코드가 작성되고 컴파일 과정 없이 바로 File로 변환됨
• File
• Load
  • File은 브라우저로 바로 적재됨
• Machine language
  • 파일이 적재된 이후에야 Machine language로 컴파일됨 (메모리 내부에서 Machine language로 변환되는 것이 스크립트 언어의 특징)
• Run
• Terminate

컴파일 언어와 스크립트 언어의 "Run time"

먼저 느낀 점부터...

런타임이라고 하면 실행단계 정도로 이해하고 있었으나, 사실은 더 굉장히 중요하고 복잡한 내용이었음을 알게되었다. 프로그램이 실행된 후 메모리 상에 적재된 명령들이 어떻게 수행되는 지 그리고 이런 런타임이 일어난 후 대체 왜 문으로 이루어진 것들은 실행이 종료가 되었는 지 알 수 있었다.

Compile Language에서의 Run time

위 그림은 Compile 언어에서 이루어지는 런타임을 그림으로 그린 것이다.
그리고 위 그림의 기재된 순번은 아래에 자세하게 정리됐다.

1. 메모리에 저장된 명령을 외부버스를 통해 Fetch(CPU가 알아들을 수 있는 명령어(instruction)로 변환하는 과정)되어 디코더로 들어가 디코딩됨.
2. Instruction 을 기반으로 해 명령을 연산함
3. 명령에서 필요하다고 한 값을 메모리에서 데이터유닛으로 불러옴
4. 연산유닛으로 전달한 후 연산작업을 거침
5. 실행된 값을 데이터 유닛으로 옮김
6. 그 값을 다시 메모리로 옮겨 저장함

Script Language에서의 Run time

스크립트 언어에서 런타임은 다소 특이한 면이 있다.
컴파일 언어와는 달리 상대적 관점에서 static/run 의 분기가 나뉘는데, 이미 실행이 된 것들은 현 시점에서 static이 되고 실행이 되는 중인 현재가 곧 run time이 된다. 개념 자체가 특이하고 굉장히 상대적인 개념이라 현시점이 run time인 것이 가장 중요한 지점이라고 할 수 있다.

느낀 점

앞서 말했듯 굉장히 평면적으로 알고 있던 프로그래밍에 대한 정의를 알게 됐다. 그리고 내가 주로 다루는 JavaScript와 같은 인터프리터 언어와 C, JAVA, C++ 등과 같은 컴파일러 언어가 이렇게도 다르다니 싶었다.

CS에 대한 지식이 그렇게까지 충분하지 않았던 터라 이런 기초적인 부분에 대해서 학습하는 것도 굉장히 힘에 부치는 듯 하였으나 기본적인 작동 원리는 알고 프로그래밍에 대해 언급하는 게 옳다는 걸 이번에 좀 더 깨우친 것 같다. 런타임이 무엇인지에 대해서도 평면적으로 알았고, 컴파일 타임이니 린트 타임이니 아는 척하기 급급했던 단어들에 대해서도 조금 더 자연스럽게 설명할 수 있게 된 것 같아 설레이기도 한다. 1화 중 일부를 정리했을 뿐인데도 다시 한 번 복습하고 이해하며 넘어가느라 중간에 끊었다. 이건 추가로 이어서 포스팅 할 수 있도록 하겠다.