Disqus for rellat

릴랏 멘토링 가이드 8


이 글은 이기준 이기환이 진행하는 릴랏 멘토링 프로그램의 가이드 문서 제 8편이에요. 이 멘토링 프로그램이 뭔지 궁금하신 분은 릴랏 블로그를 방문해서 정주행 해보세요. 릴랏이란 오픈소스를 이용하고 학습 과정을 공개해서 프로그래밍을 공부하자는 캠페인이에요.

이원재님의 실천 내용

이원재님이 지난 한 달 동안 공부한 것을 간추려서 정리해 볼게요. 공부한 내용은 아래 링크에 전부 기록되어 있어요.




    1. 테트리스 싱글(1인용) 게임 오픈소스를 분석했다.
    2. 테트리스를 4인용 게임으로 개조했다.
    3. 테트리스 4인용 게임 클라이언트에 서버를 붙였다.
    4. 테트리스 서버를 리팩토링했다.
    1. 비주얼드 싱글 게임 오픈소스를 분석했다.
    2. 비주얼드 서버를 만들어 보았다.
    3. 비주얼드에 게임용 그래픽 프레임워크를 도입해 보았다.
      1. JS 2D 게임 프레임워크를 표로 정리해서 비교했다.
    1. 블랙잭 싱글 게임 오픈소스를 분석했다.
    1. 이기준 이기환이 만든 릴랏 IDE 소스를 분석했다.

2017년 7월 이원재님의 일정

2017년 8월 이원재님의 일정

우리는 이원재님이 정직한 일정을 운영하도록 하고 있어요. 과거 일정은 실제로 한 일을 기록하는 역할을 하도록 실제 한 일을 기준으로 조정해요. 그리고 미래 일정도 과거에 했던 일을 근거로 해서 실현 가능성이 높게 수시로 조정해요. 캘린더에서 흐리게 처리된 과거 일정은 전부 실제로 한 일을 사실대로 기록한 것이에요. 이것을 보면 이원재님의 생산성이 향상되어 가고 있다는 것을 알 수 있어요.


프로그래머의 성장 단계

아래는 프로그래머의 성장 단계를 설명한 것이에요. 평가 기준은 제가 자체적으로 만들었어요. 그러나 평가 방법을 객관적으로 공개했기 때문에 누구에게나 공정하게 적용할 수 있어요.

  1. 코딩 문법은 안다: 코더, Coder
    1. 남이 만들어 놓은 예제를 조립해서 돌아 가는 프로그램을 만든다.  
      1. 예제 코드, 레거시 코드를 "복사해서 붙여넣기"하는 수준이다.
      2. 그런 다음 문법 깔맞춤을 지켜서 에러가 안 나게 한다.
      3. 학원을 다녀서 직업 과정을 수료하면 이 단계에 이르게 된다.
    2. 혹은 자기 스스로 코딩 문법을 사용해서 간단한 프로그램을 만든다.
      1. 사람들은 흔히 복붙 안 하고 자기가 타자로 치면 구현이라고 말하지만 그것은 사실 구현이 아니다. 예제를 복사해서 붙여넣기 하지 않는 대신 남의 코드를 눈으로 보고 참고를 해서 자기 손으로 타자를 친 수준이다.
        1. Ctlr-c - Ctlr-v 복붙은 아닌데 눈으로 보고 손타자로 복사해서 붙여넣기 했다는 말이다.
        2. 그래서 그런 것은 구현이라고 하지 말고 재현이라고 해야 된다.
    3. 계속 발생하는 각종 에러는 덕테이프로 땜빵을 하듯이 예외 처리를 해서 패치한다.
      1. 각종 땜빵질을 익혀서 노하우가 생기면 코더 경력자가 된다.
      2. 이것만 해도 회사에서 어느 정도 인정받고 먹고는 산다.
      3. 그러나 치킨집 트리는 피할 수 없다.
  2. 개발 철학을 배우고 그것을 코드에 적용해서 실천한다: 개발자, Developer
    1. 업계에서는 코더와 개발자를 혼용해서 부른다. 코더나 개발자나 다 개발자라고 불러 준다.
      1. 이것은 마치 건설업계에서 일용직 노동자도 "기사"라고 불러주는 호칭 관행과 비슷한 것이다.
        1. 사실은 일당 5만원 받는 잡부인데도 이기사, 김기사, 박기사 이런 식으로 불러 줌
      2. 그러나 기술직으로 인정받는 기사는 엄연히 단순 노동만 제공하는 잡부와는 다르다.
        1. 그러므로 업계에서 부르는 호칭 관행이 있다는 것과 별도로 실제 개념이 다르다는 것을 이해하자. 싸울 필요는 없다.
    2. 개발자는 개발 철학을 응용해서 프로그램의 구조를 변경할 능력이 있다.
      1. 그렇게 해서 에러를 줄인다.
      2. 정보처리 효율을 높인다.
      3. 유저, 고객, 개발하는 사람들에게 편리함을 준다.
    3. 개발자는 "프로그램의 목적을 달성하는 더 나은 정보처리 방법"을 만들어 낸다.
      1. 이것이 닥치면 닥치는 대로 땜빵을 해서 문제를 해결하는 코더와의 차이점이다.  
    4. 이것을 하려고 개발자는 개발 철학을 공부하고 실천한다.
      1. 추상화
      2. 객체화
      3. 함수화
      4. 모듈화
      5. 이벤트화
      6. 실시간 반응형
      7. 비동기형
      8. 기타 새로운 개념과 철학이 만들어지고 실험되고 있다.
        1. 그런 과정을 거쳐서 새로운 기술과 언어가 시장에 등장한다.
  3. 자기가 상상한 것을 프로그램으로 만들어 낸다: 창조자, Creator
    1. 이 사람은 전지전능하다. 자기가 상상한 것을 프로그램으로 만들어 낸다. 그래서 고수라고 불린다.
    2. 남이 만들어 놓은 코드가 있으면 참고해서 조립하고 참고할 코드가 없으면 자기 스스로 만들어 낸다.
      1. 만들면서 헛된 자존심과 고집을 부리지 않는다.
      2. 이 사람에게는 상상한 것을 프로그램으로 만들어 내는 것이 중요하다. 즉, 자기가 만들려고 하는 프로그램의 정보처리 과정을 만들어 내는 것이 중요하다.
    3. 상대적으로 삽질을 적게 하면서 결과물을 만들어 낸다.
      1. 이 과정에서 프로그래밍 개발 철학을 사용해서 효율을 높인다.
    4. 이전에는 없던 새로운 프로그램, 획기적인 프로그램을 만들어 낸다.
    5. 그렇게 해서 사용하는 사람들에게 편리함을 준다.  

모든 프로그래머는 이 단계를 거쳐요. 저와 이기환님도 예외는 아니죠. 우리도 다 이 단계를 거쳤어요. 우리는 프로그래밍을 한 지 3년쯤 되고 나서부터 창조자 단계에 들어섰고 이 단계에서 레벨을 계속 상승시키는 중이에요. 우리는 또한 코더이면서 개발자에요. 왜 우리가 창조자라고 주장할 수 있을까요? 우리는 우리가 만들고 싶은 프로그램을 상상한 대로 그대로 만들 능력이 있기 때문이죠. 그걸로 증명하는 거에요. 우리는 이전에 없었던 프로그램을 만들어 냈죠. 이전에 없었던 기능, 이전에 없었던 기술을 만들어 냈어요. 그래서 창조자에요.

누구나 올바른 방법으로 꾸준히 하면 몇 년 뒤에는 창조자 단계에 들어갈 수 있어요. 이 기준으로 평가했을 때 이원재님은 딱 한 달 만에 코더에서 개발자로 급하게 실력을 향상시키고 있는 중이에요. 이원재님이 제대로 깨우치기 전에는 코더라고 부르기도 어려웠어요. 이원재님이 릴랏 멘토링을 제대로 시작한 2017년 7월 전까지는 다른 사람이 만든 예제를 복사해서 붙여넣고 조립을 해서 에러 안 나게 만들어 내는 것도 제대로 하지 못했다는 말이죠. 그런데 지금은 어떤가요? 프로그램을 여러 개 만들어 보고 그 안에서 다시 리팩토링을 거듭하면서 프로그램의 구조를 개념과 철학을 사용해서 바꾸어 나가고 있어요. 그게 개발자의 단계에요. 그런 차이가 있어요.

다시 코더 이야기로 돌아가 볼게요. 코더 단계에서도 수준별로 레벨이 달라요. 그래서 코더 단계에서도 상, 중, 하로 급이 나뉘어요. 이 차이는 주로 소스 이어 붙이기 능력과 에러 핸들링 능력이에요. 얼마나 빨리 소스 조립을 하느냐, 얼마나 빨리 에러를 고치고 디버그를 하느냐로 판단할 수 있어요.

상상을 해보아요. 코더가 참고할 예제 소스를 분석하고 그것을 가지고 와서 덕테이프로 이어 붙이듯이 얼기설기 엮어서 짜맞추었어요. 실제 코더의 업무는 코딩 언어를 사용해서 문법 깔맞춤을 해주는 것이에요. 문법 깔맞춤이 덕테이프 역할을 하는 거죠.

부서진 자동차는 물론 아폴로11호 우주선까지 고치는 덕테이프의 위력

이제 얼기설기 엮은 코드를 실행시켜 보았어요. 그랬더니 제대로 돌아가는 부분도 있지만 문제가 생겨서 에러가 나는 부분도 있었어요. 이제 그 부분은 패치로 물이 새는 곳을 막듯이 처리해요. 주로 에러를 예외 처리해서 디버그해요.

물이 실시간으로 새고 있는 구멍도 즉시 막아 드립니다!
광고를 보고 나면 쓸 일이 없는데도 괜히 사고 싶어진다는 그것.. 뭔가를 고치고 싶어하는 남자들의 로망!

이제 개발자 단계에 대해서 이야기 해보아요. 개발자는 문법 깔맞춤 정도에 그치지 않고 구조를 자신이 원하는 방향으로 만들어요. 각종 개발 철학을 적용해서 프로그램의 구조를 만들어 내요. 그렇게 해서 이전보다 에러가 구조적으로 덜 나게 만들고, 구조적으로 속도가 더 빨라지게 만들면 개발자의 업무가 성공한 거에요.

이번엔 창조자의 단계를 보아요. 창조자는 상상한 것, 기획한 것을 실제 프로그램으로 만드는 능력으로 평가해요. "이런 프로그램을 만들고 싶다."는 생각을 하고 그 프로그램이 이 세상에 아직 없을 때 그것을 창조해서 만들어 내는 거에요.

이제 각 단계별로 실력을 평가하는 방법을 정리해 보아요.

  1. 코더
    1. 상급
      1. 작은 단위 프로그램 기준으로 48시간 이내에 소스 연결 작업과 디버깅이 끝난다.
    2. 중급
      1. 1주일 이내에 끝난다.
    3. 하급
      1. 1달 이상 걸린다.
  2. 개발자
    1. 상급
      1. 작은 단위 프로그램 기준 1주일 이내에 개발 철학을 반영한 구조 변경과 디버깅이 끝난다.
    2. 중급
      1. 1달 이내에 끝난다.
    3. 하급
      1. 3달 이상 걸린다.
  3. 창조자
    1. 상급
      1. 작은 단위 프로그램 기준으로 MVP, 시제품이 1달 이내에 나온다.
    2. 중급
      1. 3달 이내에 나온다.
    3. 하급
      1. 6개월 이상 걸린다.

이 평가 기준을 가지고 이원재님을 평가해 보아요. 이원재님은 2017년 7월 둘째 주부터 "코더 중급" 수준으로 일하고 있어요. 그리고 개발자 단계 테크 트리를 열고 "개발자 하급" 수준의 일을 하고 있어요. 이기환님은 어떤가요? 이기환님은 "코더 상급", "개발자 상급", "창조자 상급" 역할을 하고 있어요. 이것은 이기환님이 개발하고 업로드하는 소스를 보면 알 수 있어요.

이원재님 현재 실력 (2017년 8월 17일 기준)
  1. 코더 중급
    1. 작은 게임 오픈소스 분석하고 조립해서 작동하게 하는 일을 1주일 이내에 한다.
  2. 개발자 하급
    1. 리팩토링을 하면서 소스의 구조를 개선하는 일을 경험하고 있다.
    2. 이 부분은 이제 막 시작했다.

이원재님과 비교하는 이기환님의 실력
  1. 코더 상급
    1. 작은 게임 오픈소스를 분석하고 조립하는 일을 평균 48시간 내에 한다.
  2. 개발자 상급
    1. 리팩토링과 구조 변경도 평균 1주일 내에 한다.
  3. 창조자 상급
    1. 이전에 없었던 새로운 프로그램의 시제품을 1달 내에 만들어 낸다.

이기환님이 대단한가요? 그렇지 않아요. 이기환님보다 더 잘하는 사람이 있을 수도 있어요. 이 기준은 상대적인 거에요. 누구나 훈련을 해서 향상시킬 수 있어요. 그리고 이 상중하 기준은 업무 처리 속도를 기준으로 나눈 것이에요. 빠른 것이 절대적으로 좋은 것은 아니에요.

예를 들어 느릿느릿 대기만성형으로 프로그래머 생활을 할 수 있어요. 코딩 업무 처리 속도가 느리지만 개발자 역할을 깨우칠 수 있고 창조자 역할도 깨우칠 수 있어요. 코더 하급이면서 개발자도 하급, 창조자도 하급이 되는 것이죠. 이러면 느리지만 할 것은 다 해요. 빠른 산출물을 원하는 회사 생활에서 성공하기는 어렵지만 자아 실현의 입장에서 개인 프로젝트로 자기가 원하는 프로그램을 만들어 보고 성취감을 느낄 수 있어요. 천천히 오랫동안 준비해서 다 만들어 놓고 스타트업을 시작하면 되요. 상대적으로 속도가 빠른 것이 좋기는 하지만 속도가 느리다고 해서 못하는 것은 아니에요.

가장 안타까운 경우는 시간을 많이 들여서 공부했는데 계속 코더 하급에만 머무는 것이에요. 개발 철학을 이해하고 응용하지 못하고 창조자가 되어서 창의적인 프로그램을 만들어 보지 못하는 경우죠. 이러면 회사에서 직장 생활을 해도 힘들어요. 그런데 이런 경우가 사람들 사이에 상당히 많아요.

그래서 이번 글에서는 어떻게 하면 삽질을 적게 하는 사고방식을 개발할 수 있는지, 어떻게 하면 코더에서 개발자로, 개발자에서 창조자로 테크 트리를 열고 거듭날 수 있는지 강의해 보아요.


더 나은 정보처리 방법이란 무엇일까?

코더에서 벗어나서 개발자와 창조자 단계를 열어 나가려면 "더 나은 정보처리 방법"에 대해서 생각하는 습관이 필요해요. 생각하는 습관은 사고방식이라고 해요.

  1. 코더에서 개발자로, 창조자로 자신을 업그레이드 하려면 "더 나은 정보처리 방법"에 대해서 생각하는 사고방식이 필요하다.
  2. "더 나은 정보처리 방법"이란 비교를 하고 실험을 해서 알아내야 한다.
    1. 정보처리 속도가 더 빨라지게 한다.
    2. 더 많은 양의 정보를 처리할 수 있게 한다.
    3. 유저에게 편리함을 주는 정보처리를 한다.

자, 그러면 이 사고방식을 배우려면 어떻게 해야 할까요?


상대적으로 비교를 하는 사고방식

더 나은 정보처리 방법을 알아내려면 상대적으로 비교를 하는 사고방식을 훈련해야 해요. 그 예시를 이원재님의 글에서 살펴 보아요.

과제 일지_이원재 2017년 7월 9일
오늘은 자바스크립트로 객체지향의 구현쪽을 공부 해 보았다.

생성자의 생성 및 new 부분이 원래 알고 있던 것과 조금 달랐다. 자바나 c++은 어떤 클래스 내에 메소드와 프로퍼티들이 묶여있는 느낌이라면 자바스크립트는 메소드가 어떤 한 객체에 묶여있지 않고 여기저기서 객체에 따라 다른 동작을 할수 있어 더 자유로운 언어라는 생각이 들었다. 하지만 자칫 잘못 사용하면 코드가 아주 꼬이기 쉬울 것 같다. 그리고 이러한 방식이 어떤 상황에서 필요할 것인지가 아직 느낌이 오지 않는다.

prototype이라는 개념을 새로 배웠는데, 용도가 약속되어있는 특수한 프로퍼티로, prototype에 저장된 속성들은 생성자를 통해 객체가 만들어 질 때 그 객체에 연결된다. 또한 prototype chain이라는 개념이 있는데, 만약 자식 객체에서 어떤 프로퍼티에 접근할 경우, 먼저 자식 객체에 그 프로퍼티가 있는지 확인 후 프로토타입 객체에 있는지 확인하고 없다면 프로토타입에 있는지 확인 후 없다면 그 프로토타입이 가지고 있는 객체로 찾아 들어가서 그 객체의 프로토 타입에 프로퍼티가 있는지를 확인하는 방식으로, 체인처럼 연결 되어 있어 prototype chain이라는 명칭이 붙었다.

또한 표준 내장 객체에 대한 내용이 신기했다. 맨 처음 말한 메소드 관련 내용과 관련하여, 기본적으로 내장되어있는 객체에 내가 원하는 함수를 작성하여 추가한 후 이를 사용이 가능하다. 자바나 c++에서는 생각조차 못했었던 내용이며 자바스크립트가 자유분방한 언어라는 특징을 보여주는 한 부분이다.

이로써 자바스크립트 관련 강의를 한번 완주 하였다. 분명 완벽히 이해 했다고는 볼 수 없지만, 모든걸 이해하려고 하기보다는 대략적인 큰 그림을 잡고 실제로 개발 해 나가면서 디테일을 잡아가는 것이 중요하다고 생각해서 강의 진도를 빨리 진행 하였다. 이제 다시 테트리스 코드를 분석 해 보고 전체적인 설계를 다시 진행 해야 겠다.

오 공부를 다시하고 테트리스 코드를 살펴보니 뭔가 더 이해가되고 눈에 들어온다.



이것을 보면 무엇을 알 수 있나요? 이원재님은 JS(자바스크립트)를 배울 때 주입식으로 외우려고 하지 않았어요. 이원재님은 자기가 이전에 배워서 알고 있던 것과 새로 배운 JS 문법을 비교해서 무엇이 비슷하고 무엇이 다른지 생각하는 과정을 가져 보았어요. 이것이 상대적으로 비교를 하는 사고방식이에요. 이 사고방식을 매일 매순간 실천해야 해요.

저는 릴랏 멘토링을 진행하면서 공부를 하는 사람들이 자기가 배운 내용을 그냥 복사해서 붙여넣기 방식으로 일지에 적는 것을 많이 보았어요. 그런데 그러면 내용을 주입식으로 맹목적으로 외우는 공부가 되기 때문에 응용하는 것이 어려워요. 뭐가 비슷하고 뭐가 다른지 알지 못하면 응용하기 어려워요. 그래서 항상 상대적으로 비교하고 실험하는 습관을 들여야 해요.


이기환님이 그래픽 카드를 사러 전자상가에 갔다

이 이야기는 제가 이원재님을 가르치려고 꺼낸 일화에요.

  1. 이기환님이 그래픽 카드를 사러 전자상가에 갔다.
  2. 집에서 가방과 돈, 핸드폰 등을 챙겼다.
  3. 집을 나섰다.
  4. 대중교통을 탔다.
  5. 전자상가에 도착해서 내렸다.
  6. 아니 이럴수가, 전자상가에 방문하기로 했던 가게가 문을 열지 않았다.
    1. Or, 가게에 재고가 떨어져서 물건을 살 수 없었다.
  7. 이기환님은 뒤늦게 다른 가게에서 물건을 사려고 했지만 다른 가게에서는 이기환님이 알아 본 가격에서 2~3만원 웃돈을 붙여서 불렀다.
  8. 그래서 이기환님은 그냥 집에 돌아왔다.

이기환님은 이 경험을 관찰해서 이런 정보처리 과정을 만들어 냈어요.

  1. 이기환님이 그래픽 카드를 사러 전자상가에 갔다.
    1. 먼저 방문하기로 한 가게에 전화를 해서 영업 시간을 물어 보고 사려고 하는 물건의 재고가 있는지 확인한다.
    2. 한 곳에만 물어 보지 않고 다른 가게에도 문의를 해서 3곳의 정보를 알아 놓는다.

이기환님은 이렇게 자신의 경험을 관찰해서 교훈을 만들어 냈어요. 이게 "더 나은 정보처리 방법”을 만들어 낸 사례에요. 왜 이게 더 나은 정보처리 방법인가요? 그 이유는 이 정보처리 방법을 이용하면 위에 나오는 "6번, 아니 이럴 수가" 상황을 예방할 수 있기 때문이에요. 이기환님은 더 나아가서 이 교훈을 그래픽 카드 구매 뿐만 아니라 세상을 살아가는데 전반적으로 두루두루 사용할 수 있다는 것을 깨달았어요.

  1. 이기환님이 00을 하려고 했다.
    1. 이기환님은 00을 하려고 집을 나간다던지 급하게 뭘 하려고 하지 않는다.
    2. 이기환님은 먼저 00에 관련된 기관(회사, 관공서, 기타)에 연락을 해서 업무 시간을 물어 보고 해야 하는 00에 대해서 물어 본다.
    3. 한 곳에만 물어 보지 않고 비슷한 정보를 제공하는 곳에도 문의를 해서 3곳의 정보를 받아서 비교한다.

자, 이기환님은 그래픽 카드 구매를 하다가 얻은 교훈에서 그래픽 카드라는 단어를 비우고 수학에서 함수처럼 거기에 다른 단어가 들어올 수 있게 만들었어요. 지금 제가 설명하는 이 일화가 추상화와 객체화 개념을 설명해요. 이제 진도를 좀 더 나가 보아요.


절차 지향과 객체 지향

프로그램 한 개에는 여러 가지 방식의 정보처리 과정이 들어가요. 절차 로직도 좀 들어가고 객체 로직도 좀 들어가고 그래요. 그래서 상대적으로 더 객체를 많이 사용해서 객체 지향으로 정보처리 과정을 만들었느냐, 상대적으로 절차 지향으로 만들었느냐 그런 비교를 해야 해요.


그러면 왜 객체를 사용하는가?

프로그래밍을 할 때 객체를 사용하는 이유는 다음 번에 다른 상황에서 사용할 수 있는 "열린 정보구조체"를 만들어 내려고 그런 거에요. 위에 이기환님이 경험에서 교훈을 끌어 내고 교훈을 다른 일에도 응용할 수 있게 개조한 것을 생각해 보세요. 프로그래밍에서 객체는 그런 역할을 해요.

왜 그렇게 해야 할까요? 그 이유는 그렇게 해서 분업과 자동화를 하려고 하기 때문이에요. 더 쉽게 말해서 삽질을 덜 하는, 더 나은 정보처리를 하려고 하기 때문이에요.

왜 절차 지향 정보처리는 삽질이 유발될까요? 아담 스미스의 "국부론"이라는 책을 보면 이런 일화가 나와요. 못(핀)을 만드는 공장의 이야기에요. 공장에서 못을 한 개 만드는데 공정이 이러했어요.

  1. 철사를 잡아 편다.
  2. 철사를 못 길이에 맞게 자른다.
  3. 잘라낸 철사의 한 쪽 끝을 뾰족하게 갈아 낸다.
  4. 쇠조각을 망치로 쳐서 못 대가리에 해당하는 부분을 만든다.
  5. 못 대가리를 못 몸통에 땜질로 붙인다.
  6. 만들어낸 못을 한 곳에 모은다.
  7. 못을 100개씩 종이에 싸서 박스에 담는다.
  8. 박스를 포장한다.
  9. 도매상으로 출고한다.

이 전 과정을 한 사람이 할 경우 한 시간에 한 개, 하루에 최대 20개 정도 생산할 수 있었어요. 그런데 이 과정을 각 과정 별로 분리해서 여러 사람들에게 분업해서 맡겼더니 하루에 못을 수천 개에서 수만 개 생산할 수 있었다고 해요. 이것이 분업의 특징이에요. 우리는 이것을 사람이 하는 일이 아니라 컴퓨터 프로그램이 하는 정보처리 과정이라고 생각해 보아요.

프로그램이 내부에 한 방향 시퀀스로 이루어진 로직을 가지고 있었어요. 한 번 그 로직이 실행되고 나면 시퀀스가 끝나거나 일단락 되기 전까지는 다른 일을 할 수 없었어요. 컴퓨터의 CPU, 메모리, 네트워크 등 자원이 시퀀스 로직에 물려 있었기 때문이에요.

그래서 그 프로그램을 객체화 개념으로 다시 설계했어요. 그래서 정보처리 과정의 각 부분을 객체로 분리해서 각 객체에서 분업을 해서 정보처리가 일어날 때마다 필요한 만큼 컴퓨터의 자원을 사용하게 했어요. 그랬더니 더 많은 양의 정보처리를 할 수 있었어요.

자, 제가 이 이야기에서 설명하려고 하는 것은 추상화 객체화를 하는 이유가 이렇게 분업화 자동화를 해서 더 나은 정보처리를 하려고 하기 때문이라는 것이에요. 이것을 실현하느냐 마느냐는 실전에서 얼마나 개념을 잘 살려서 프로그래밍을 하느냐에 달려 있어요.


고추참치 한 번 먹으려고 원양 어선을 타고 태평양에 가야 한다면?

이번에는 다른 예를 들어 보아요. 제가 고추참치를 먹고 싶어요.

  1. 가까운 수퍼나 마트를 들러서 고추참치를 사먹는다.
  2. 참치 먹기가 그리 쉽나? 원양 어선을 타고 태평양으로 나간다.

냉장고를 열어 봐라~♬ 고추참치 꺼내 먹어라~♬

이 얘기 들으니까 황당하고 웃기죠? 그런데 이게 초창기 컴퓨터 프로그래밍에서는 실제로 있었던 일이에요. 초창기 컴퓨터 프로그램은 각 프로그램이 전부 하드웨어 제어 부분, 즉 요즘에는 OS에서 관리해 주는 부분을 개별적으로 가지고 있었어요. 그래서 프로그램 한 개를 실행 시키려고 하면 최종 목적에 해당하는 고추참치 부분을 로딩하기 전에 한참 동안 "원양 어선을 타고 태평양에 가는 부분"을 로딩해야만 했어요.

나는 고추참치를 먹으려고 했을 뿐인데 어쩌다 여기까지 왔지?

그래서 프로그래머들이 불편하고 짜증이 나서 공통이 되는 하드웨어 제어 부분을 별도 프로그램으로 떼어서 만들었어요. 그것이 운영체제, OS, 유닉스의 시작이었어요. 자, 여기에도 분업화 개념이 사용되었어요.

"00수산"을 만들어서 거기서 고추참치를 공급받으면 어떨까?

이렇게 분업화 개념은 컴퓨터 프로그램이 운영체제 OS와 응용 프로그램 Application(App)으로 분리가 된 이유이기도 해요.


그래서 핵심 개념은 분업과 자동화다

추상화와 객체화를 비롯해서 앞으로 님들이 배울 모든 개발 철학들은 분업과 자동화를 하려고 사용하는 도구에요. 분업과 자동화를 하는 이유는 최종적으로 "더 나은 정보처리 과정"을 만들어 내려고 하는 것이에요.

이제 반대로 생각해 보아요. 아무리 최신 개발 철학이라고 하더라도 그것을 적용했더니 분업화 자동화를 하지 못하고 "더 나은 정보처리 과정"을 만들지 못했다면 그것을 사용할 필요가 없어요.

실제 프로그래밍을 하다 보면 그런 경우가 생겨요. 개발 철학은 좋은데 컴퓨터의 성능이 뒷받침 되지 않아서 그만큼의 효과가 안 나온다던지, 개발 철학은 좋은데 그것을 해당 프로그래밍 언어에서 사용을 하려면 코딩 문법이 까다로워서 작업 시간이 너무 많이 걸린다던지 하는 문제가 생길 수 있어요. 그래서 비교를 해서 "내 입장에서 가장 나은 것"을 선택하는 사고방식이 필요해요. 비교를 하고, 실험을 하고, 정량 관찰을 해야 해요. 퍼포먼스 측정을 하고 필드 테스트를 하는 습관을 들여야 해요.


사람과 대화를 해도 계속 절차 경험만을 우기면 대화를 하기 어렵다

"아, 내가 옛날에 말이야. 이런 경험이 있었는데.."하면서 모든 일을 자기 경험을 반복하면서 처리하려고 하는 사람이 있어요. 경험하고 그것을 기억만 해요. 경험을 관찰해서 추상화를 하고 더 나은 정보처리 방법을 만들어 내려고 하지 않아요. 그러면 꼰데가 되요.

나이가 들었기 때문에 꼰데가 되는 것이 아니에요. 젊은 꼰데도 많아요. 군대에서 삽질한 이야기, 군대에서 축구한 이야기, 과거에 자기가 고생했다는 얘기만 반복하는 사람을 생각해 보세요. 그런 것은 그냥 고생하면서 뺑이쳤다는 경험을 얘기하는 것일 뿐, 다른 일에 응용할 수 있는 교훈이 없어요. 그게 문제에요. 경험에서 앞으로 인생에 도움이 되는 교훈을 추상화 해내지 못하면 의미가 없어요. 그래서 꼰데가 되는 거에요. 경험이 나쁜 것은 아니에요. 교훈, 응용, 융통성이 없다는게 문제에요.

꼰데는 자꾸 자기 경험을 가지고 밀어 붙여요. 직장 생활에서 만나는 꼰데를 생각해 보아요. 이 경우에도 꼰데는 경험에서 배우는 것이 없어요. 그냥 경험 자체에 의미를 부여하려고 해요. 경험에서 배운 것을 바탕으로 변화한 현실에 대해서 어떻게 대응할지 생각을 안 해요. 그게 문제에요. 경험이 문제가 아니에요. 경험을 하고 그 경험을 관찰해서 추상화 과정을 거쳐서 의미 있는 교훈, 앞으로 응용할 수 있는 정보처리 방법을 만들어 내면 경험이 의미가 있어요.  

이제 프로그래밍으로 예를 들어 보아요. 지금 님이 스마트폰 앱을 만들려고 하고 있어요. 그런데 님 앞에 앉아 있던 꼰데가 이렇게 말한다고 생각해 보아요. "와, 내가 일하던 때에는 말이야. 화면 한 번 띄우려고 해도 C를 사용해서 어쩌고 저쩌고.. 요즘 사람들은 다들 프로그래밍을 쉽게 배우는 것 같아. 쉽게 배우니까 고생해서 배우는 프로그래밍의 소중함을 잘 모르는 것 같아."

아니, 이게 무슨 고추참치 먹으려면 원양 어선 타야 한다는 이야기인가요? 고추참치의 참 맛을 알려면 원양 어선을 타 봐야 한다는 그런 얘기인가요? 프로그래밍 언어의 역사를 보아요.

맹목적으로 공부하지 말고 어떤 철학을 바탕으로 해서 이 언어들이 만들어졌는지 생각해 보자

경험을 관찰하고 추상해서 교훈을 만들어 내는 것을 통찰이라고 해요. 우리는 이런 역사의 흐름을 살펴 보면서 "내 입장에서 내가 하는 일에 도움이 되는 기술"을 계속 배워야 해요. 개발 철학을 응용해서 내가 만들고 싶은 프로그램에서 더 나은 정보처리를 할 수 있도록 해야 해요.

사람들이 저에게 무슨 프로그래밍 언어를 배우면 장래에 제일 유망하겠느냐고 물어보는 경우가 많이 있어요. 그런데 그 질문을 하는 사람의 사고방식은 꼰데가 되는 급행열차에요. 제가 위에 말한 것처럼 여러 가지 언어를 배우고 그것들을 비교해서 내가 지금 개발하려고 하는 프로그램에 상대적으로 가장 적합한 것을 고르는 사고방식을 훈련해야 해요. 그게 아니라 괜찮아 보이는 언어를 한 개 택해서 그것만 열심히 하려고 하면 비교하고 더 나은 정보처리 방법을 만들어 내는 사고방식을 훈련하지 못해요.

  1. 여러 개의 언어를 연습해 보고 비교하고 실험하는 습관을 들여야 한다.
    1. 그래야 "더 나은 정보처리 방법"을 만들어 내는 사고방식을 훈련할 수 있다.
  2. 반대로 유망할 것 같은 언어나 기술을 택해서 그것만 공부하려고 하면 위의 비교하고 더 나은 방법을 만들어 내는 사고방식을 훈련하기 어렵다.
    1. 그래서 경험에 의존하는 꼰데가 될 확률이 커진다.

그냥 꼰데를 넘어서 "흉악한 꼰데"가 있어요.
"요즘에 프로그래밍 언어가 쉬워져서 개나 소나(?) 프로그래밍 한다고 덤비는 바람에 전체적으로 개발자 질이 떨어지고 대우도 안 좋아지고 그래서 기분이 좋지 않다."
이런 흉악한 사람을 만나면 멀리하도록 해요. 이런 사고방식을 가진 사람은 일하는데 도움도 하나 안되고 주변에 해만 끼쳐요.


추상화와 객체화

그러면 이제 추상화와 객체화를 어떻게 하는지 좀 더 이야기를 해볼게요. 위에서 제가 뭐라고 했었죠? 추상화와 객체화를 하는 이유가 분업과 자동화를 하려고 하기 때문이에요. 먼저 이걸 이해하는 것이 중요해요.

이제 그러면 추상화와 객체화를 어떻게 해야 할까요? 이기환님이 그래픽 카드 사러 간 이야기에서 이미 중요한 내용을 다 이야기 했지만 이번에는 새로운 예를 들어서 설명해 보아요.

몇 년 전에 징병되어서 군생활을 하던 사람이 저에게 상담을 요청한 적이 있어요. 그 사람은 행정 업무를 주로 했었는데  자꾸 업무 중에 상관에게 야단을 맞는다면서 어떻게 하면 군대 업무를 잘할 수 있는지 물어 보았어요.

제가 이야기를 들어 보니 이 사람의 문제는 이러했어요.
  1. 자신이 맡은 보직이 정해져 있다고 착각을 했다.
  2. 자신에게 할당된 업무 유형이 정해져 있다고 착각을 했다.
  3. 업무가 두 개 이상 자신에게 주어지면 무엇을 먼저 하고 무엇을 나중에 할지 본인이 판단을 하지 못했다.
    1. 본인이 판단이 안되면 즉시 관리자 역할을 하는 선임이나 장교에게 물어 보고 확인을 받으면 되는데 그러지 않았다.
    2. 이 사람은 이런 상황이 되면 위에 2번, 자신에게 할당된 업무 유형이 정해져 있다는 착각을 떠올리고 자기가 하고 싶은 순서대로 일을 했다.
  4. 그러다 보니 업무 진행 상황을 보고하지 못하고, 일을 제 시간에 종료하지 못했다.
  5. 심지어 자의 반, 타의 반으로 업무 진행 사실을 누락하기도 했다.
  6. 그러다가 걸리면 문책을 받았다.
  7. 그러면 그 사람은 억울하다고 생각했다. 군생활이 비정상적으로 빡세고 힘들다고 생각했다.

그래서 제가 그 사람에게 준 조언은 이러했어요.
  1. 님이 맡은 보직 유형은 이제부터 한 가지 뿐이라고 생각해라.
    1. 그것은 선임과 상사가 해달라는 것을 하는 것이다.
    2. 그외에 님이 맡은 다른 고유한 업무 유형이 있다는 생각을 버려라. 그것이 님 군생활을 가장 힘들게 하는 착각이다.
  2. 선임과 상사가 가혹행위와 범죄행위를 하지 않는 이상 그외에는 그냥 전부 최선을 다해서 시키는 대로 해라.
    1. 가혹행위
      1. 성추행
      2. 똥군기
      3. 왕따(기수열외 같은)
      4. 그외 각종 갑질과 괴롭힘
    2. 범죄행위
      1. 군대 내부 비리에 가담하라고 한다던지
      2. 다른 사람을 괴롭히는데 가담하라고 한다던지
      3. 금품이나 향응을 요구한다던지
    3. 가혹행위와 범죄행위는 답이 없으니 헌병대에 신고하고 맞서 싸워라.
      1. 물론 지금 상황은 그런 상황이 아님
  3. 이제부터 실전에 들어가 보자. 앞으로는 일 처리 방식을 시퀀스(절차) 방식이 아니라 이벤트 방식으로 바꾸어야 한다.
    1. 모든 일은 일을 진행하는 순서가 있다. 군대에서는 대부분 일을 진행하는 절차를 미리 만들어 놓고 그걸 가르쳐 준다.
    2. 그런데 두 가지 이상의 일이 들어오면 시퀀스도 두 개 이상이 되어서 일이 꼬이기 시작한다.
    3. 그래서 시퀀스를 적절하게 섞어야 하는데 이 섞는 기준을 이렇게 잡아라.
      1. 시퀀스(절차) 중에 몇 시까지 보고가 우선적으로 들어가야 하는 절차가 있는가?
        1. 그러면 그 절차 단계까지를 우선 순위로 잡아서 먼저 한다.
      2. 절차 중에 요청을 보내 놓고 응답을 받을 때까지 시간이 걸리는 절차가 있는가?
        1. 이 절차 사이에 다른 업무의 절차를 끼워 넣어서 동시 작업 진행이 가능하게 한다.
    4. 이것이 바로 이벤트 방식이다. 일의 절차를 잘게 잘라서 각 절차 조각을 이벤트로 간주하고 일을 진행하는 것이다.   
      1. 중요한 이벤트와 덜 중요한 이벤트
      2. 정해진 시점까지 칼같은 보고를 해주어야 하는 이벤트와 안 해도 되는 널널한 이벤트
      3. 응답이 올 때까지 기다려야 하는 이벤트와 바로 이어서 할 수 있는 이벤트
  4. 자, 이제부터 더 중요한 것을 설명한다. 이벤트 방식 일처리는 반드시 스케줄러를 갖추어야 한다. 이게 실전에서는 수시로 업무 진행 상황을 보고하고 피드백을 받아서 순서를 변경해주는 작업이다.
    1. "상관님, A 업무는 총 1, 2, 3, 4 ,5 단계에서 3단계까지 한 상황이고 B 업무는 총 5단계 중 2단계를 하고 있습니다. 현재 B 업무를 00시까지 완료해서 현황 보고해야 하기 때문에 B 업무에 우선순위를 두고 먼저 하고 있습니다. "
      1. 이런 식의 스케줄 보고를 하루에 정기적으로 몇 번 해주어야 한다.
      2. 그리고 선임이나 상사가 물어보면 실시간으로 대답해 주어야 한다.
        1. 실시간으로 대답을 해주려면 내 쪽에서 미리 일정 구조를 정리해 놓아야 한다.
        2. 물어 보니까 그때부터 막 찾아 보려고 하면 안된다.
    2. 스케줄링을 할 때 뭐를 먼저해야 할지 모르겠으면 솔직하게 얘기를 하고 물어 보면 잘 가르쳐 준다.
    3. 이렇게 과정을 공개하면서 일을 진행하면 일이 잘못되어서 문책을 당할 확률이 줄어든다.
    4. 업무를 시키는 사람 입장에서 신뢰가 생긴다.
      1. 상사에게 신뢰받으면 간섭도 줄어들도 자율 재량 권한도 생긴다.
      2. 긍정적인 순환이 생긴다.

제가 말한 이 교훈은 군대 뿐만 아니라 회사 생활을 할 때도 응용할 수 있어요. 군대라는 말을 비우고 회사라는 말을 넣기만 해도 말이 되요. 이렇게 경험에서 절차, 시퀀스를 관찰해서 거기서 반복되는 패턴을 찾아 내야 해요. 이것이 추상화 작업이에요. 그 패턴을 별도의 박스, 별도의 블럭, 별도의 덩어리로 분리해 내면 그게 객체에요.

그러려면 일에서 결과정보에 해당하는 것을 해제해 보면 되요. 언어 문장에서 결과정보는 명사에요. 참고로 저는 이렇게 객체를 부르는 말로 정보구조체라는 말을 만들었어요. 정보를 처리하는 구조체라는 뜻이에요. 박스, 블럭, 덩어리 등의 단어보다 좀 더 학문적으로 설명하려고 만들었어요.


객체? 모듈? 엔진? 프레임워크? 라이브러리? API? 덩어리? 블럭?

"객체는 뭐고 모듈은 뭔지 헷갈려요." 하는 경우가 있어요. 이런 이름은 뭐라고 불러도 상관 없어요. 전부 정보를 처리하려고 만든 구조체에요. 추상화와 객체화 개념을 이해하는 것이 중요해요. 분업화와 자동화의 개념을 이해하는 것이 중요해요. 여기서 개념과 철학은 같은 뜻이에요. 추상화 철학이라고 해도 되고 추상화 개념이라고 해도 뜻이 같아요.

새끈한 새로운 개념이 나왔다고 해요. 그런데 현실에서 분업화와 자동화에 도움이 안되면 사용 안 해도 되요. 실제로 이벤트화 모듈화 개념은 1970년대부터 나왔어요. 그런데 그때는 컴퓨터의 성능이 골골거리는 바람에 그 개념으로 이득을 얻을 수가 없었어요. 마른 수건 쥐어 짜듯이 메모리 한 줌, CPU 클럭 한 줌 쥐어짜는 상황에서 컴퓨터 자원을 펑펑 써야 하는 이벤트화 모듈화는 이상만 좋고 사람들이 기피하는 개념이었어요.

그런데 컴퓨터 하드웨어 성능이 발달하면서 상황이 바뀌었어요. 요즘에 점차 인기를 얻고 있는 Node.js를 보아요. 이 Node.js가 바로 이벤트화 개념이 많이 적용된 기술이에요. Node.js에서는 시퀀스를 잘게 잘라서 이벤트 알갱이로 만든 다음 그것들의 순서를 우선 이벤트 순위별로 자유롭게 처리할 수 있어요. 물론 이렇게 하려면 코딩을 할 때 그게 가능하도록 정보처리 과정을 객체화 모듈화 이벤트화 해주어야 해요.


참고가 되라고 제가 그림을 그려 보았어요. 위에 기존 프로그램들은 프로그램의 정보처리 과정에 해당하는 절차 로직의 길이가 상대적으로 긴 편이었어요. 그래서 한 개의 절차 로직이 CPU 쓰레드에 들어가면 그게 끝날 때까지는 다른 시퀀스가 못 들어오는 병목 현상이 생겼어요. 그래서 이 문제를 해결하려고 병렬 처리 개념을 고안해 냈어요. 정보처리를 하는 파이프라인 역할을 하는 쓰레드 유닛을 늘린 것이죠. 그래서 병목 현상을 일부 줄이기는 했는데 여전히 한 시퀀스가 처리되고 있을 때 그게 끝날 때까지는 다른 시퀀스가 뒤에서 기다려야 한다는 점에서는 같았어요.

그런데 제가 위에 군대 이야기에서 설명한 것처럼 정보처리 과정 중에는 전체 시퀀스 중에 일부 단계가 중요하고 다른 단계가 덜 중요한 경우가 많이 있었어요. 1, 2, 3, 4, 5단계 중에 2단계까지는 빨리 피드백 해주어야 되고 나머지는 널널한 경우가 있고 평소에는 모든 단계가 널널하다가 무슨 이벤트가 발생하면 갑자기 민감한 피드백이 필요한 상황이 된다던지 하는 일이 일어났어요.  

그래서 Node.js에서는 매우 작은 정보처리 과정까지도 알갱이 처럼 분할해서 이벤트형으로 만들 수 있게 해주었어요. 그랬더니 쓰레드가 한 개 뿐인데도 우선적으로 처리해야 하는 이벤트들을 처리해서 병목 현상을 줄였어요. 쓰레드가 한 개 뿐이지만 처리할 수 있는 이벤트는 기존 프로그램보다 더 많아졌어요. 게다가 Node.js는 서버 유닛 자체를 증설하는 방식으로 트래픽 분산을 할 수 있어요.

그래서 이런 혁신이 일어났어요. 해마다 미국에서는 블랙 프라이데이가 되면 유명 쇼핑몰 웹사이트에 트래픽이 몰려서 서버가 다운되는 일이 자주 일어났어요. 그래서 아마존, 월마트, 베스트바이 같은 업체들은 트래픽이 급증하는 시기를 대비해서 호스팅 업체에서 서버를 대량으로 임대했어요. 그러나 그렇게 해도 다운이 되는 일이 종종 있었어요. 그런데 Node.js 서버를 도입했더니 서버를 대량으로 임대하지 않고 트래픽 급증 사태를 해결할 수 있었어요. 현재 Node.js는 넷플릭스, 이베이, 페이팔, 링크드인, 그루폰 등 실리콘 벨리 대기업에서 사용하고 있어요. 엔터프라이즈급 성능을 인정받은 거죠.

아래는 이원재님이 Node.js 서버를 공부하면서 쓴 내용이에요.

과제 일지2_이원재 2017년 8월 6일 일요일
저번에 그렸던 순서도 대로 게임을 진행하려고 로직을 작성하였다.
맨 처음엔 while문에 여러 함수를 나열해 가며 진행하는 방식으로 작성 하려고 했었다.

그러나 나중에 서버쪽을 생각 해 보면, node.js는 싱글 스레드, 이벤트 기반이다.  여러가지 이벤트가 들어오면 그 이벤트들이 병행 처리가 된다. 이러한 처리에 따라, 한 이벤트가 처리되는 시간이 매우 길어버리면 퍼포먼스가 떨어진다. 따라서 개발자는 이벤트를 잘게 쪼갤수록 더 좋은 성능 향상을 얻을 수 있다.

따라서 어떤 함수에 while문을 넣고, 거기서 돌리는 방식이 아닌, 버튼에 이벤트가 발생 했을 경우 처리해주는 함수들을 만들어 준 다음 그 함수들로 인해 게임이 진행되는 방식으로 개발 하였다.

생활 일기_이원재 2017년 8월 10일 목요일
개발 하다가 순간 든 생각이 있다.

eventEmitter를 적용하면서 ‘아니 그냥 클래스로 만들어서 그 메소드를 호출하고 인자값으로 데이터를 보내주는 것과 뭐가 다를까?’ 라는 의문이 들었었다. 생각해 보니 이 방법은 어떤 로직의 흐름 안에 갇혀서 그 메소드가 불려야 인자값을 전달할 수 있다.

그러다 Emitter 방식으로 이벤트가 발생하고, 해당 데이터를 전달하는 방식은 로직에 갇혀있지 않고 어디선가 이벤트가 발생하면 바로 인식하고 동작한다. 그래서 좀 더 자유롭고 유연한 프로그램이 된다.

이기준: 그러네요? 그러면 좀 더 이벤트 지향적인 정보처리를 하게 되겠네요. 이원재님이 자기 스스로 질문을 해서 그렇게 문법 뒤에 있는 의미를 생각하게 되어서 기쁘네요.

앞으로 남은 중요한 부분은 뭐냐면 이제 그 정보처리 과정을 제대로 구현했을 때 이득이 있느냐 하는 것을 실험과 시뮬레이션을 해서 알아 내는 거에요.

이득이라는 것은 이런 것이에요.
  1. 성능 이득
  2. 편리함 이득
  3. 그렇게 해서 유저(고객)를 만족시켜 주는지 아닌지

언어 문법, 논리로는 거창하고 대단하고 좋은데 실전에 들어갔더니 성능이 너무 구리다던지, 쉽게 예를 들어서 서버를 돌렸는데 동접 몇 만 명을 버티지 못하고 깨져 버린다던지 아니면 개념은 거창했는데 실 사용을 하니까 전혀 편리하지가 않다던지 그런 부분을 종합해서 유저에게 만족을 못 주고 불편함을 준다던지 이러면 개념이 좋더라도 사용하지 않아야 하는 거죠. 그런 비교가 필요해요.

그래서 미니 테스트를 자주 해보세요. 이제 앞으로는 미니 테스트를 하고 미니 시뮬레이션을 자주 하면서 비교한 것을 증명하는 습관을 길러 나갈거에요.

"실험을 했는데 그 결과가 제가 코딩을 잘하고 못해서 영향을 끼쳤는지, 그 언어의 구조적인 문제인지 어떻게 판단해야 할까요?"같은 질문도 할 수 있는데요. 이 부분은 동일 조건으로 여러 가지 변형을 주어서 실험을 계속 해보면 차이를 알아낼 수 있어요. 그래서 실험하는 사고방식과 습관이 몸에 베어야 되요.

이원재: 한 언어의 정보처리 과정이 최고다 이런 개념을 가진 정보처리과정만 사용하면 될꺼다 가 아니고 항상 검증과 비교를 통해야 하는군요. 그것을 통해 최적의 방법을 찾아야 하구요! 그리고 일방향으로 배우면 외우고 습득하더라도 머리로 받아드린 것이라서? 얼마 안가서 또 까먹고 그랬었는데 이렇게 느낌으로 탁 깨우쳐서 배우고 기록해 두니까 제것이 되었다는 느낌이에요. 신기한게 EventEmitter에 대해 피드백을 받았을 때는 전체적으로 어떻게 구현 할 지 몰랐는데 소스 분석을 좀 여러번 하고 예시를 보고 구현을 해보니까 신기하게 감이 왔어요. 그런데 헙 제가 딱 질문하려던 것을 답해주셨네요 ㅋㅋ


리팩토링 습관

리팩토링을 하면서 개발 철학을 적용하면 자연스럽게 코더에서 개발자로 테크 트리를 열고 능력을 개발하게 되요.

이기준: 이원재님은 튜토리얼 분석을 이제 다 끝냈어요?

이원재: 넵 이제 거의 끝나가지고 한번 제 코드로 짜보고 리팩토링 해보려구요! 이런 효과 주는? 프레임워크를 처음 써봐가지고 많이 헤맨거같아요. ㅋㅋ 이 로직도 board 채우고 match check하고 또 채우고 match check하고 이런게 물려 있어서 한번 떼어봐야겠어요.

이기준: 그래요. 이원재님 입장에서 편한 것을 선택하구요. 또 저에게 배운 개발 철학, 객체화 모듈화 이벤트화 입장에서 더 나은 방식으로 개조를 해보세요. 그게 잘하는 거에요. 대부분의 사람들은 그 작업을 안 하고 그냥 코드가 동작하면 그걸로 만족하려고 하거든요. "어떻게 하면 더 나은 정보처리를 할 수 있을까?"하는 생각을 안 하는 거죠. 그런 점에서 이원재님은 참 잘하는거에요. 제가 가르친 보람이 있어요.

이원재: 감사합니다 🙂 얼른 몸에 익도록 열심히 하겠습니다

이기준: 이렇게 개념을 배우고 그것을 실전에서 바로 실천한다는 것이 중요한데 이원재님은 그걸 잘하고 있어요. 처음에 테트리스 분석하고 구현할 때는 남의 것을 많이 참고한다는 느낌을 받았지만 두 번, 세 번 업그레이드하고 리팩토링 하면서는 더 이상 그런게 아닌 거죠.

이원재: 네 완전 다른 소스가 되었죠ㅎㅎ 모듈화 해보니까 더 깔끔해지고  코드가 역할에 맞게 분리되는거같아서 좋았어요



그렇죠. 이렇게 하면 잘되요.


"입천재"는 안 믿어요

저는 썰만 푸는 입천재를 믿지 않아요. 온 동네방네 넘쳐 나는 "엄마 친구 아들"을 믿지 않아요. 업계의 누구, 전설의 레전드 그런거 전부 다 안 믿어요. 저는 제가 매일 실천하는 것만 중요하게 생각해요.

저는 다른 사람이 무슨 말을 하면 그 말을 실천하는지 안 하는지를 봐요. 말을 하면 말은 믿지 않아요. "아, 저 사람이 그런 말을 했구나." 여기서 끝이에요. 말은 그냥 말이라는 것을 받아들이고 이제 그 말을 어떻게 이해하고 어디까지 실천하는지를 봐야 하는 거에요.

이 글을 읽는 님들도 님들이 하루하루 그날 실천할 수 있는 것에 집중하세요. 사고방식의 차이를 이해하고 더 나은 사고방식을 실천하세요.


시간 관리와 집중

배지원님이 저에게 하루에 얼마나 시간을 서서 코딩하고 개발하냐고 물어 보았어요. 제가 "한 10시간 정도 되지 않을까요?"라고 했어요. 중간에 틈틈이 아기 돌보기도 하고, 집안일도 하고 하면서요.

그런데 절대적인 시간을 많이 투입한다고 해서 결과물이 잘 나오거나 실력이 향상되는 것은 아니에요. 제가 이번 글에서 이야기한 사고방식들은 코딩을 할 때만 사용하는 것이 아니에요. 그냥 일상 생활을 하면서도 사용할 수 있는 사고방식이에요. 사고방식 훈련에는 정해진 시간 같은게 없는 거죠. 하루 종일 할 수 있거든요.

이기준: 진짜 좋아하면 따로 시간 관리를 할 필요가 없어요. 이원재님 같은 경우에는 프로그래밍 하다가 잘 안 풀리면 산책 나갔다 오는데 산책하면서 문뜩 좋은 생각이 나서 갔다 오면 문제가 잘 풀리고 그런다고 하더라구요. 그러면 이원재님은 산책을 하러 갔기 때문에 휴식을 한 것인가요, 아니면 일을 잘하는데 도움이 되는 일과 관련된 활동을 한 것일까요? 여기서 깨달음을 얻어 보세요.



이게 제가 대답으로 해준 이야기에요. 쉽게 말하면 자기가 좋아해서 하는 일은 하루 종일 할 수 있다는 말이에요. 심지어 다른 일을 하고 있어도 내가 하고자 하는 그 일에 도움이 되는 효과가 있어요. 그러면 하루 24시간 그 일을 하는 효과가 생겨요. 잠자는 시간까지도 내가 하고 싶어하는 그 일에 도움이 되는 거에요.

  1. 당구 배운지 일주일째 되는 당구에 흠뻑 빠진 청년은 밤에 누워서 천장을 보면 쓰리쿠션 길이 보인다고 한다.
  2. 바둑 배운지 몇 달째 되는 바둑에 흠뻑 빠진 아이는 밤에 누워서 천장을 보면 포석과 사활이 그려진다고 한다.
  3. 축구를 좋아하는 사람은 밤에 누워서 천장을 보면서 334, 442 포메이션을 만들어서 볼을 드리블 하고, 패스하고, 슛하는 모습을 상상한다.
  4. 스타크래프트 좋아하는 학생은 밤에 누워서 천장을 보면 투 배럭 마린메딕, 럴커와 저글링 러시, 드라군과 리버 드롭이 펼쳐진다.

그래서 제가 릴랏 멘토링 가이드 5에서 진짜 자기가 좋아하는 것이 무엇인지 생각해 보고 거기에 집중하도록 해야 한다고 한 거에요. 또한 릴랏 멘토링 가이드 6에서 말한 것처럼 일의 결과에 연연하지 않고 자기 스스로 즐거운 마음을 만들어 내는 훈련을 해야 한다고 했어요.

이원재: 일을 하다가 산책을 하면서 무의식적으로 자기가 하던 일을 계속 생각하게 되고 그 과정에서 사고 과정이 환기가 되어서 해결책이 생각 나는 것 같아요. 대신 산책을 할 때 편한 마음이어야지 "아, 고쳐야지 고쳐야지."하는 마음이면 산책하는 효과가 없다고 생각해요.

이기준: 맞아요. 집착하는 마음은 비우고 그냥 순수하게 즐거움 마음만 가지고 휴식을 하면서 상상을 하고 있으면 내가 가진 뇌의 다른 부분들이 도와 주는 거죠. 그러면서 상상을 비교하고 그러면 더 잘되구요.


간절한 마음을 가지면 이루어진다던데 왜 안되지?

그 이유는 그 간절한 마음이 잘못된 방식으로 이루어져 있을 수 있기 때문이에요. 내 마음 속에서 무슨 정보처리가 일어나고 있을까요? 인간의 마음 속을 컴퓨터 프로그램처럼 정보처리 모델로 형상화 해보아요.


우리 마음 속에 이런 모듈이 세 개 있다고 상상해 보아요. 그런데 욕구 모듈이 상위에서 하위에 있는 감정과 이성에게 이런 저런 명령을 내리고 제어를 했어요. 그러면 어떻게 될까요?

그러면 그 욕구를 달성하려고 꾀를 부리고 머리를 쓰는 상황이 일어나요. 욕구는 바로 본능적인 욕구에요.
  1. 식욕
  2. 성욕
  3. 수면욕
  4. 배설욕
  5. 놀고 싶은 욕구
  6. 쉬고 싶은 욕구

감정은 무엇일까요?
  1. 희노애락의 감정
  2. 물질적인 소유욕
  3. 사회적으로 주변 사람에게 인정받고 싶은 욕구
    1. ㅅㅌㅊ, ㅎㅌㅊ 구분
    2. 금수저 흙수저 구분

이번 글에서 제가 강의한 사고방식은 전부 이성에 해당해요. "더 나은 정보처리 방법을 만들고 싶은 욕구"는 이성적인 욕구인 거죠.


낮은 차원의 본능적인 욕구가 나를 컨트롤 하는 상황

위의 그림처럼 욕구 모듈이 상위에서 다른 모듈을 컨트롤 하면 새로운 사고방식을 배우고 실천하는게 어려워요. 각종 충동에 시달리기 때문이에요. 그래서 이런 문제를 겪게 되요.

  1. 사기를 치고 속임수를 써서라도 성공하고 싶은 충동
  2. 부정행위, 치팅을 해서라도 결과를 충족하고 싶은 충동
  3. 그냥 과정은 다 무시하고 결과만 충족하고 싶은 충동
  4. 다 때려 치우고 일탈을 하고 싶은 충동

"아, 젠장, 이런 귀찮은 과정 따윈 다 무시하고 그냥 돈 많이 벌고 싶다고!"

간절한 마음을 잘못 이해하고 낮은 차원의 욕구로 간절한 마음을 가지면 잘 안되요. 폐인되요. 욕구와 감정으로 간절하게 원하는 마음을 가지고 했는데 능력을 개발하기 보다는 충동에 시달리게 되요. 제가 과정과 방법에 대한 칭찬 글에 관련된 내용을 써놓았어요.


높은 차원의 욕구: 이성

이성적인 욕구는 이런 것이에요.
  1. 자아 존중
  2. 자아 실현
  3. 이타심
  4. 이 세상을 더 좋은 곳으로 만들고 싶다는 생각

거창하게 3번, 4번까지 생각할 필요 없고 일단 1번 2번에 집중해 보아요. 제가 릴랏 멘토링 가이드 6에 아무 이유 없이 긍정적인 마음을 자기 스스로 만들어 내면 자아 존중을 하는 것이라고 했어요. 그걸 그림으로 표현하면 이래요.


자, 살펴 보아요. 내가 욕구의 충동 없이, 욕구와 감정의 자동반응 없이 즐거운 마음을 만들어 내서 느끼면 내 이성이 욕구와 감정 위에서 컨트롤 하는 모양이 되요. 그렇게 자아 존중을 실현하는 것이에요.

이제 그 다음에는 뭘 해야 할까요? 즐거운 마음을 스스로 만들어 내고 나면 그 다음에는 이번 글에서 설명한 것 같은 "더 나은 정보처리를 하는 방법"을 생각하고 비교하고 실험하는 사고방식을 만들고 실천해야 해요. 그러면 실력이 발전해요.

여기서 더 나아가서 3번 4번에 해당하는 이타심과 이상을 실천하면 더 좋겠죠. 저는 제 나름대로 실천하고 있어요. 릴랏 멘토링 활동을 그래서 하는 거에요.


내면의 충돌과 조화

이원재님은 프로그램을 자기 스스로 만들게 되면서 즐거움을 느낀다고 했어요. 이것은 수준이 높은 순수한 즐거움이에요. 왜냐하면 식욕 성욕같은 본능이나 ㅅㅌㅊ, ㅎㅌㅊ 같은 사회적 욕구가 아니기 때문이죠. 이것은 자아 존중에 해당하는 즐거움이에요. 이원재님은 프로그래밍 실력을 개발하면서 자아 실현을 하는 즐거움을 느껴요. 내가 지금 하는 생각이 어떤 상황에 해당하는지 알아내는 쉬운 방법이 있어요. 이 질문을 해보세요.

  1. 나는 결과에 기대심을 가지는가, 과정을 실천하는데 즐거움을 느끼는가?
    1. 결과에 대한 기대심을 가지면 욕구나 감정이 상위에서 나머지를 컨트롤 하고 있는 모양이다.
    2. 과정을 실천하는데 즐거움을 느끼고 결과에 대한 기대심을 버릴 수 있다면 이성이 상위에서 나머지를 컨트롤 하고 있는 모양이다.
  2. 나는 아무 이유 없이 즐거운 감정을 만들어 내서 느낄 수 있는가, 아니면 외부 상황이나 현실에서 감정을 반응해서 느끼는가?
    1. 아무 이유 없이 즐거운 감정을 만들어 내서 느낄 수 있다면 이성이 상위에서 나머지를 컨트롤 하고 있는 모양이다.
    2. 외부 상황이나 현실에서 감정을 반응해서 느끼면 욕구나 감정 모듈이 상위에서 나머지를 컨트롤 하고 있는 모양이다.

이렇게 자신의 생각을 관찰해 보고 내가 어떤 상황에 있는지를 유추할 수 있어요.


자기 관찰이 필요하다

자기 관찰을 해서 내가 하는 생각을 살펴 보고 내 생각이 어떤 과정으로 이루어져 있는지 파악을 해야 해요. 이렇게 자기 생각을 관찰하는 습관은 나중에 "더 나은 정보처리를 하는 방법"을 생각할 때에도 도움이 되요.


생각의 개미지옥: 헛된 자존심이 만든 함정

좋은 자존심이란 자아 존중이에요. 아무 이유 없이 긍정적인 감정을 자기 스스로 만들어 내서 느끼는 것이에요. 그러나 많은 사람들이 자존심이라고 생각하는 것은 헛된 자존심이에요. "내가 이정도 실력은 있는 사람이다." 같은 사회적 욕구에 자동반응해서 느끼는 거죠. 헛된 자존심이 무엇인지 알아 보아요.  

생활 일기_이원재 2017년 8월 11일 금요일
오늘은 비주얼드 소스를 조금 수정하고 서버쪽 개발을 들어가려고 했다.

원래의 비주얼드 소스 자체가 보석이 바뀌고, 폭발하는 효과를 주려고 함수끼리 이리저리 얽혀있었다. 그래서 보여주는 부분과 로직 부분을 떼어내기 위한 작업을 하려고 보니 도저히 떼어낼 수가 없었다.

다음에는 뷰 부분과 로직 부분이 얽혀있는 소스는 가져오지 않겠다는 생각을 하고 다른 소스를 찾아 보았다. 다른 소스는 뷰와 로직 부분이 잘 떼어져 있었고 어떤 이벤트가 발생하면 로직이 뷰 부분에 요청한다. 뷰 부분에서는 jquery를 이용하여 효과 부분을 처리하고 있었다.

나는 이 소스가 내가 생각하던 소스와 맞다고 생각하고 분석을 한 후에 포팅을 하려고 했다. 여태까지 게임 작업은 p5.js를 통해서 하고 있어서 당연히 p5.js로 바꾸려고 했었다. 그런데 p5.js 에서는 효과를 주는 기능들이 부족했고 그래서 이리저리 바꿔 보고 내가 직접 만들어 보려고 낑낑댔다.

그러면서 머리 속이 복잡해졌다. 사실 지금까지 개발하면서 뷰 쪽을 다른 라이브러리고 구현을 해야하나 생각을 하면서도 그냥 p5.js로 구현 했었고, 빠르게 구현해낼 수 있었으니까 이걸로 하려고 했는데 잘 안돼니 답답했다. 계속 붙잡고 늘어졌다. 여태 p5.js로 잘 구현이 되었으니까 이걸로 당연히 구현이 될꺼라고 생각하고 만들어 갔다. 그런데 잘 안되었다 -> 이런 생각의 순환이 계속되어 그 속에 갇혀버리니 답이 없었다.

그래서 결국 이기준님 이기환님께 제가 지금 삼천포로 빠지고 있는 것 같다고 하며 현재 상황에 대해 여쭈어 보았다. 그랬더니 다른 라이브러리를 쓸 때가 왔다고 말씀해 주셨다. 지금이 좋은 타이밍이라고 말씀 해 주셨다. 그 순간 뭔가 머리를 때리는 생각이 들었다. 나는 하던 일이 안되고 있었을 때 다른 라이브러리를 찾아서 비교해 보고 적용해 보는 생각을 하지 못하고 계속 갇혀 있었다.

왜 갇혀 있었을까? 생각을 해보면 원래부터 써왔던 것인데 내가 구현을 못 하는 것이라고 생각했다. 어떤 라이브러리가 어떤 기능을 지원을 안 한다면 처음 해야 하는 일은 대안을 찾아보는 것이다. 처음 써보는 것이라도 또 분석하면 되지 않는가? 그리고 찾다 찾다 도저히 없다, 다른 사람이 만든 오픈소스도 없고 다른 라이브러리도 없다, 그런데 나는 이 기능이 꼭! 필요하다 하는 경우에는 내가 구현하는 것이다 라고 생각을 해야겠다. 대안을 찾아서 비교 분석 해보고 지금 내가 하려고 하는 정보처리 과정과 가장 알맞는 것을 찾아내는 것 그게 지금의 내가 해야할 일이다.

내일은 game 프레임워크 순위 이 링크를 보고 어떤 프레임워크를 쓰는 것이 좋은지 비교 분석해 봐야 겠다.



헛된 자존심은 자기가 실력이 있다, 내가 이정도는 한다 이런 식으로 착각을 하는 거에요. 아까 위에 군대 이야기에서 "내 보직이 원래 이런 건데 너무 많은 다른 업무를 시킨다."이런 착각하고 같은 거죠. 자기 이미지에 대한 착각이 있어요. 그런 착각을 하면 어떻게 될까요? 고추참치 한 번 먹으려고 원양 어선을 타고 태평양까지 가게 되요. 삽질을 하게 되는 거죠. 오성민님이 과제 일지에 이런 내용을 적었어요.

과제 일지_오성민 2017년 8월 11일 목요일
이틀동안 어제 검색으로 찾은 가속도관련 소스들을 스크래치에 적용하려하였다. 수직점프와 좌우 이동시 가속도가 느껴지게 해냈지만, 좌우이동에 있어서, 버튼을 떼었을 때 동작이 바로 멈추지 못 하고 의도한 움직임보다 더 미끄러지는 증상이 있었다. 수학적인 공식을 제어문으로 나타내는데 부족함이 있는지 좀처럼 해결하지 못했다. 시간을 오래 소모할수록 아이디어 보다는 생각없이 숫자만 조금씩 바꿔가는 요행을 바라는 내 모습을 볼 수 있었다.

시간을 더 쓰지 않기로 결심하고 ‘github supermario jump acceleration’라고 노골적인 구글링을 해보니 Github에서 슈퍼마리오 1차 스테이지를 재구현한 파이썬소스를 찾을 수 있었다. 이미 원하는 목표가 뚜렷했었는데 왜 진작에 이렇게 검색하지 않았지? 내 스스로 확률을 과소평가하고 에둘러 검색하는 경향도 있다는 것도 알았다. 여하튼 마침 슈퍼마리오를 일차적으로 구현하려 했었는데 난 운이 좋았다. 소스분석을 바로 시작해야지. https://github.com/justinmeister/Mario-Level-1

이기준: 잘했네요. 많은 사람들이 이상한 생각, 자기 스스로 태클거는 생각 하느라고 간단한 검색을 잘 안 해요. 그렇게 자기 스스로 일을 힘들게 만들죠. 그 사고방식의 함정에서 빠져 나오는게 중요해요.

오성민: 감사합니다. '정신수양'이라고 말하면 다분히 도교적인 느낌을 받았었는데요. 더 이상 거창한 단어가 아니라, 이번에 제가 느끼기에, 과거의 함정에서 벗어나는 측면에서, 프로그래밍 작업 도중에도 '정신수양'을 하는 것 같습니다.



오성민님의 경우를 보세요. 마리오 한 번 만들어 보려고 가속도 기능까지 처음부터 개발해야 하는 상황이 온 거에요. 개인의 자유 입장에서 보면 뭐를 선택하던지 자유에요. 그러나 가슴에 손을 얹고 생각을 해보세요. 마리오 한 번 만들어 보려고 가속도 기능을 처음부터 다시 개발하는게 그게 진짜 효율있고 똑똑한 정보처리 방식인가요? 상대적으로 더 나은 정보처리 방법인가요?

두 개의 관점이 있어요. 이 두 개의 관점으로 평가를 해보면 되요.

  1. 마리오를 만드는 것이 중요하다.
    1. 여러 소스를 비교하고 리팩토링을 거듭하면서 개발 철학을 익히는 것이 중요하다.
  2. 내가 혼자 다 만드는 것이 중요하다.

많은 사람들이 간단한 구글 검색도 안 해보고 그냥 막 맨땅에 박치기 식으로 도전한 다음 열등감을 느끼면서 자책해요. 내가 ㅅㅌㅊ인줄 알았는데 ㅎㅌㅊ였네 이런 식으로요. 그게 헛된 자존심의 함정이에요. 거기에 한 번 빠지면 몇 달 동안 헤어나지 못하는 사람도 있어요. 개미가 개미지옥 함정에서 쉽게 빠져 나오지 못하는 것처럼 버둥거릴수록 계속 아래로 떨어져요.

  1. 왜 난 이것도 못하지?
  2. 왜 잘 안되지?
  3. 내가 못나서 그런가?
  4. 아, 미치겠네?
  5. 이 프로젝트를 괜히 했나?
  6. 아, 재미없다. 다른거 하고 싶다.

자, 이 생각의 개미지옥은 누가 만든 것인가요? 바로 그 사람 본인이 스스로 만든 거에요. 자기가 만든 함정에 자기가 발목 잡혀서 빠진 거에요.

내가 스스로 만든 생각의 개미지옥

"친구야, 거긴 아니야. 빨리 나와!"

아래는 이원재님과 이 주제에 관해서 대화를 나눈 내용이에요.

이원재: 진짜 찾아보거나 물어보면 되는데 괜히 태클거는 생각을 가지고 낑낑거리면 시간만 가고 문제 해결은 안되는 것 같아요. 지금 하는 방법이 안되면 빨리 분석해보고 다른 방법으로 가보면 되는데 말이에요.

이기준: 그래요. 이걸 이원재님도 겪고 다른 사람들도 겪어요. 이원재님은 상대적으로 빨리 빠져 나오는 편이구요. 앞으로는 가능하면 함정에 안 빠지도록 하고, 빠지더라고 알아차리고 재빨리 벗어나는 습관을 길러야 해요. 그렇게 해서 장기적으로는 예방을 하면 좋겠죠? 이런 이유 때문에 자기 관찰을 하는 것이 중요하다고 얘기한 거에요.


이미 발명된 것들을 다시 처음부터 재발명하려고 하지 말자

“이미 만들어 놓은 발명품인 바퀴를 네가 처음부터 재발명하지 마라.”라는 말이 있어요. 줄여서 "바퀴를 재발명하지 마라."라고 해요.


왜 재발명하지 말라고 할까요? 그 이유는 재발명을 하는 동안 시간과 노력을 낭비하기 때문이에요. 솔직히 말해서 재발명해도 되요. 그건 개인의 자유잖아요. 그런데 님들이 계획을 가지고 무슨 프로젝트를 하고 있다고 가정해 보아요. 이미 만들어서 오픈소스로 공개된 "바퀴"들을 참고하지 않고 님들이 그걸 처음부터 재발명한다면 프로젝트의 계획을 달성할 수 있을까요? 마감 시한을 지킬 수 있을까요? 프로젝트를 완료할 수나 있을까요?

이미 발명된 바퀴의 기술을 공개해서 누구나 참고하고 개선할 수 있게 하자는 것이 오픈소스의 개념이에요. 님들이 오픈소스 문화에 참여하고 싶다면 이미 발명된 것들을 재발명하지 말고 참고해서 개선하세요.

비교를 해보아요.
  1. 이미 발명된 것들을 혼자서 처음부터 다시 만든다.
    1. 이러면 개인 입장에서는 공부가 되기는 되는데 프로젝트 입장에서는 삽질이다. 시간이 낭비된다.
  2. 이미 발명된 오픈소스를 적극적으로 찾아 내서 분석하고 개선한다.
    1. 이러면 개인 입장에서 공부가 되고 동시에 프로젝트 입장에서도 시간을 단축시켜서 이득이다.
    2. 일석이조다. 그래서 이게 더 낫다.
  3. 재발명 삽질을 줄이는 것이 바로 오픈소스 문화가 만들어진 목적이다.  

오픈소스가 무엇인가요? 오픈소스는 프로그래머들이 자기가 발명한 코드를 다른 사람들에게 자유롭게 읽어 보고 고쳐서 개선할 수 있게 해준 것이에요. 그래서 어떤 효과가 생겼나요? 더 이상 프로그래머들이 이미 누가 발명해 놓은 코드를 처음부터 재발명 하느라고 시간을 낭비하지 않아도 되요. 그래서 2000년대 이후, 인터넷이 발달하면서 오픈소스를 통해서 수많은 소프트웨어들이 쏟아지게 된 것이죠.

오픈소스 문화를 갈라파고스 신드롬과 비교해 보세요. 갈라파고스 신드롬이란 오픈소스와는 반대로 기술을 걸어 잠그고 경쟁자들끼리 각자 비슷한 것을 재발명하는 상황을 말해요. 이미 누가 발명해 놓았지만 특허로 잠겨 있고 기업 비밀로 숨겨져 있기 때문에 경쟁 회사 입장에서는 다시 처음부터 개발해야 하는 것이죠. 그래서 어떻게 되었나요? 갈라파고스화 된 회사들은 오픈소스를 활용하는 회사들에게 밀려서 역사 속으로 사라졌어요.


갈라파고스 전략을 선택한 회사들이 도토리 키재기 식으로 더딘 경쟁을 하는 동안 오픈소스를 활용한 회사들은 기술과 성능을 훨씬 빨리 개선했기 때문이에요. 그렇게 된 이유는 간단해요. 오픈소스를 기반으로 한 회사들은 바퀴를 처음부터 재발명하는 삽질을 하지 않았고 그래서 상대적으로 시간과 자원을 낭비하지 않았기 때문이에요. 오픈소스 회사들은 그 시간에 중요한 기술적 개선과 사용자의 편의 향상에 집중할 수 있었어요.


무엇을 하더라도 그냥 막 하지 말고 비교해서 상대적으로 내 입장에서 더 나은 것을 선택하는 과정을 가져라

이원재님이 비주얼드를 p5.js로 만들어 보려다가 잘 안되는 부분이 있어서 게임 프레임워크를 도입해 보기로 했어요. 그래서 이원재님은 정보를 수집해서 표를 만들었어요. 왜 만들었을까요? 비교를 해서 우리 입장에서 상대적으로 더 나은 것을 선택하려고 그런 거에요. JS 2D 게임 프레임워크 비교표

이기준: 이기환님이 시트에 코멘트를 달아 주었네요. 제가 읽어보니 페이저로 하고 싶어요. 페이저 하다가 페이저 보다 더 좋은 것을 발견하면 또 비교해 보고 갈아타도록 해요.

이원재: 네 저도 읽고 있었어요 조사한 것 중에 phazer가 가장 좋은 것 같아요. 더 조사해야 하나 고민중이었는데 그럼 페이저로 진행해 보겠습니다. 이기준님 이기환님 피드백 감사합니다! ㅎㅎ



우리가 이렇게 조사를 하고 검토를 하고 선택을 하는데 걸린 시간이 총 6시간 정도 되었어요. 이렇게 자연스럽게 비교하고 테스트하고 선택하는 일을 해야 해요. 이게 능력이에요.


모든 것을 처음부터 다 이해하려고 하지 말고 지금 내가 하려는 일에 필요한 것만 이해하고 사용하자

생활 일기_ 이원재 2017년 8월 16일 수요일
며칠동안 bejeweled 게임에 game framework를 붙인다고 오랜기간 씨름했다. 내가 접근한 방법들을 비교해보면서 진행 했고, 지금의 나에게 가장 잘 맞는 방식을 찾았다.

첫 번째로 game Framework로 구현된 비주얼드 게임을 분석 하였다. 그 게임의 정보 처리 과정을 파악하랴 내 정보처리 과정의 방식으로 생각하랴 frame work 사용 방법 분석하랴 아주 골치가 아팠고 잘 되지도 않았다. 내가 생각한 정보 처리 과정이 아니다보니 끼워맞추기식 밖에 안되었던 것 같다.

두 번째로 그래도 여러번 봤으니까 어느정도 분석이 되서 좀 분리해 보려고 했다. 하지만 앞에서 머리가 복잡해서 일이 진행이 안되었고 프레임워크 사용한걸 보기만 했지 내가 단위 테스트를 해보고 내 정보처리 방식에 맞게 적용한 것이 아니라서 제대로 사용할 수도 없었고, 분리도 안되었다.

세 번째로 다시 초심으로 돌아가서 내가 테트리스 했던 방식을 생각해 보았다. 테트리스는 일단 원래 있던 코드를 똑같이 만들어 보고 그 정보처리 방식을 머리와 손으로 익힌 후, 라이브러리를 배워서 내가 필요한 부분에만 적용 시켜가며 만들어 갔었다. 내가 필요한 부분을 테스트해보며 써보는 방식을 내가 이번에는 안했던 것 같아서 진짜 처음부터 다시 생각하고 분석해서 내가 필요한 부분을 정리하고, 그 정리한 부분에 맞는 프레임워크 기능을 끌어서 미니 테스트를 많이 돌려보고 그 결과들을 붙여서 1인용 오프라인 게임을 만들어 내었다.

오늘에서야 느낀점은 내가 분석하고 머릿속으로 알고있는 코드라도 지금의 나는 일단 손으로 쳐보고 이해해야 한다. 그리고 내가 필요한 부분을 정리하여 작은 테스트를 여러 번 하여 사용법을 익히고 작동 여부를 검증해야 한다. 아직까지는 이렇게 해야 흐름이 보이고 사용법이 익혀진다. 그리고 테스트하는 과정에서 작은 부분도 간과해서는 안된다 오늘도 id 프로퍼티때문에 몇시간을 날렸다. ㅠㅠ 이건 아니겠지 라고 생각하지 말고 일단 다 테스트 해보긴 해야된다고 생각하고 들어가야겠다.

프레임워크를 사용하는데 가장 빠른 방법은 내가 필요한 부분을 프레임워크 방식으로 변형시켜서 적용하는 것이다. 그리고 내가 필요한 부분에 적용하는 횟수가 점차 증가할수록 프레임워크의 숙련도가 올라갈 것이다. 처음부터 다 이해하고 할순없다. 작게작게 쌓아가자.

이기준: 잘 관찰했네요. 이원재님이 지난달에 테트리스를 처음 시작할 때 빠르게 성공할 수 있었던 데에는 이유가 있었죠. 그 사고방식을 계속 되새기면서 이어나가야 되요.

이원재: 네 계속 까먹지 않도록 이어나가야겠어요ㅎㅎ 오늘은 서버작업을 들어가보려고합니다


그러려면 내가 지금 무엇을 하려고 하는지, 내 입장에서 무엇이 필요한지 알아야 한다

그래서 자기 관찰이 필요한 거에요. 위에서 본 것처럼 이원재님은 7월달에 성공한 사고방식을 8월달에는 놓치고 실수하기도 했어요. 그러나 이원재님은 실수에서 벗어나는 것이 빠른 편이에요. 제가 가르쳐 주면 바로 알아 듣고 빠져 나와요. 이게 안되는 사람은 실수가 한 달 내내 가고, 몇 달 가고, 몇 년까지 가기도 해요.

이 차이는 어디서 올까요? 바로 자기 관찰이에요. 내가 무엇을 하려고 하는지, 내 입장에서 무엇이 필요한지 생각하는 습관이 필요해요. 그리고 내가 평소에 무슨 생각을 하면서 사는지, 이 생각은 어떤 구조로 되어 있는지, 어떤 과정으로 이루어져 있는지 관찰해야 해요.


인간을 움직이는 것은 사고방식이다

저는 흑인이 인종적으로 못나서 문제를 겪는다고 생각하지 않아요.
인종 때문이라고 그렇게 생각하는게 인종 차별이죠?

그러면 무엇이 문제의 원인일까요? 사람들은 환경 탓을 해요. 가정 환경, 사회적인 환경 때문이라고 하죠.
그러나 저는 환경이 불우한 것이 영향을 끼치기는 하지만 그게 전부라고 생각하지 않아요. 영향을 주더라도 20%가 되지 않는다고 생각해요. 예를 들어서 제가 불행한 사고를 당해서 가난해 지더라도 저는 그것을 극복해 나올 거에요. 저 같은 사람은 환경에 얽매이지 않는다는 거죠.

그렇다면 무엇이 사람의 인생에 가장 큰 영향을 끼칠까요? 저는 그것이 사고방식이라고 얘기해요.
아래 동영상에 나오는 사람은 잘못된 사고방식을 가진 가족과 친구들 사이에서 자랐어요. 그래서 자기도 모르게 그 사고방식을 배우게 되었죠.

그러다가 이 사람은 감옥에 가서 깨우쳤어요. "이 사고방식은 더 이상 안돼."하구요.
그런 다음 읽고 쓰기를 배우고, 금융 사고방식을 배워서 다른 사람들을 가르쳐 주고 있다고 하네요.
저는 문제를 해결하고 더 나아지는 저만의 사고방식을 만들었어요. 저는 나중에 이 사고방식을 많은 사람들에게 전파할 거에요. 이미 릴랏 활동으로 그렇게 하고 있고 성과가 나고 있죠?

저는 나중에 저소득 국가, 우리가 못사는 나라라고 하는 곳에 가서 아이들에게 이원재님이 배운 것과 똑같은 릴랏 방식으로 컴퓨터 프로그래밍과 과학 기술을 가르칠 거에요. 그렇게 해서 문제의 원인이 인종도 아니고, 환경도 아니고, 자원의 부족함도 아니라는 것을 증명할 거에요.



인간의 사고방식이 곧 객체화된 정보구조체에요. 사람의 마음 속에는 수십 개, 수백 개의 사고방식이 있어요. 사고방식은 다른 말로 생각 습관이에요. 둘 다 같은 뜻이에요. 더 나은 사고방식을 깨우치고 실천하는 것이 중요해요. 사물을 관찰하고, 나 자신의 생각과 행동을 관찰해서 과거의 사고방식을 포착하고 나아가서 새로운 사고방식을 만들 수 있어요.

제가 코더 상급, 개발자 상급, 창조자 상급이라고 소개한 이기환님은 검정고시 고졸 출신이에요. 거기다 이과도 문과도 아닌 예체능이었어요. 그런 이기환님이 실력을 쌓는데 걸린 기간이 3년 정도 밖에 되지 않았어요. 저는 이기환님이 18살때 고등학교를 중퇴시키고 가르쳤어요. 그래서 저는 학력 불문, 나이 불문 누구나 다 가르칠 수 있다고 생각해요.


과제 일지, 생활 일기가 50페이지를 넘어가면 새 문서를 만들어 주세요

이렇게 하는 이유는 평균적으로 구글 문서가 50페이지가 넘어가면 로딩할 때 버벅거리기 때문이에요. 폴더에서 "이기준 과제 일지 2", "이기준 생활 일기 2" 이런 식으로 새 문서를 만들어 주세요.

Facebook Comments

Disqus Comments

About Author

안녕하세요. 제 이름은 이기준이에요.  저는 Deduction Theory, LLC라는 소프트웨어 회사에서 CEO로 일하고 있어요.
저는 최근 오픈소스 공개 스터디 릴랏 프로젝트의 내용을 번역해 주실 자원봉사자를 모집하고 있어요. 제 생각에는 이 프로젝트가 전세계에 사는 어린이, 학생, 어른에게 도움이 될 거에요. 특히 저소득층에게요. 이 프로젝트는 무료에요. 사람들에게 도움을 주려고 기획했어요. 저는 나중에 저소득 국가에 학교와 고아원을 짓고 사람들에게 이 프로젝트 방식으로 컴퓨터 프로그래밍을 가르쳐 주고 싶어요. 그렇게 해서 나중에 그 사람들이 더 나은 직업을 가질 수 있게 돕고 싶어요.
아래에 링크한 릴랏 소개 페이지를 읽어 본 다음 이것이 도울 만한 가치가 있다고 생각되시면 저에게 말해주세요.
오픈소스 공개 스터디 프로젝트 Rellat을 소개합니다
원문 컨텐츠는 한글로 전부 제가 쓴 것이에요. 우리는 세계 모든 언어로 번역할 계획을 가지고 있어요. 감사합니다.
안녕하세요. 이기준님과 함께 Rellat 프로젝트를 진행하고 있는 이기환입니다.
제가 프로그래밍을 처음 시작한 것은 어린 시절 어도비 플래시 프로그램에서 애니메이션을 만들다가 게임을 만들고 싶어서 액션스크립트를 사용한 것입니다.
연역론의 방법론은 제가 평소에 일을 하는 방법과 같습니다.
저는 사실 500줄 이상 넘어가는 코드를 보면 정신이 없고 잘 기억도 안됩니다. 지금도 간단한 코드 문법이 기억이 안나서 구글을 뒤지는 경우가 허다합니다.
대신 저는 이 코드가 어떤 사고방식을 사용해서 만들어졌는지, 어떤 관계정보를 사용했는지를 추적합니다. 이것이 연역론의 코딩 방법론, 코딩 스타일, 컴퓨팅 세계관입니다.
이 사고방식을 갖추면 더 나은 정보처리 방식이 무엇인지 비교할 수가 있습니다. 이것이 프로그래밍의 본질이고, 가장 중요한 것입니다.
나머지 프로그램의 빈공간은 구글과 스택오버플로우의 힘을 빌려서 채워넣습니다.
저는 여러분도 그렇게 하면 끊임없이 만들어지는 새로운 기술, 수만 줄의 코드 속에서 허우적거리지 않으면서 대규모의 질 높은 정보처리를 더 효과적으로 할 수 있다고 생각합니다. 

Popular Posts

Visitor Map

Flag Counter