program punch!

https://product.kyobobook.co.kr/detail/S000001766367

책 목차:

1장 객체, 설계 : https://inhyeok-blog.tistory.com/32
2장 객체지향 프로그래밍 : https://inhyeok-blog.tistory.com/33
3장 역할, 책임, 협력 : https://inhyeok-blog.tistory.com/34
4장 설계 품질과 트레이드오프 : https://inhyeok-blog.tistory.com/36
5장 책임 할당하기 : https://inhyeok-blog.tistory.com/37
6장 메시지와 인터페이스 :
7장 객체 분해 :
8장 의존성 관리하기 :
9장 유연한 설계 :
10장 상속과 코드 재사용 :
11장 합성과 유연한 설계 :
12장 다형성 :
13장 서브클래싱과 서브타이핑 :
14장 일관성 있는 협력 :
15장 디자인 패턴과 프레임워크 :

소프트웨어 설계와 소프트웨어 유지보수 분야에 있어서 이론을 잘 아는 것이 얼마나 효과적일까? 사실 이론보다는 실무가 훨신 앞서있다. 추상적이고 복잡한 이론을 모두 알고 소프트웨어 설계와 소프트웨어 유지보수를 실행한다는 것은 비효율적이다. 이 책은 패러다임을 설명하기 위해 추상적인 개념이나 이론을 앞세우지 않을 것이다. 가능하다면, 코드로 설명할 것이다. 그것이 실무를 이용해서 공부하는 가장 좋은 방법이다.

1. 티켓 판매 애플리케이션 구현하기

 티켓 판매 애플리케이션은 영화관에서 손님에게 티켓을 판매하는 내용을 구현하는 프로그램이다. 이를 예제 삼아서 이후의 이야기가 전개된다.

2. 무엇이 문제인가

 로버트 마틴에 의하면, 소프트웨어 모듈이 가져야 하는 세가지 기능은 아래와 같다.

1. 제대로 실행되어야 한다.
2. 변경이 용이해야 한다.
3. 이해하기 쉬워야 한다.

이제 이 3가지 원칙에 따라서 예제 코드가 어떤 문제를 가졌는지 확인해 보자.

예상을 빗나가는 코드

 로버트 마틴의 3번째 소프트웨어 모듈의 기능인 '이해하기 쉬워야 한다'는
   1. 위에서 아래로 의도를 파악하면서 읽는 것
   2. 주어진 조건(Param)과 달성 해야할 목적(return)을 보고 코드를 예상 할 수 있는 것  
   3. 코드를 읽을 때 다음줄을 예상 할 수 있는 것
을 달성 해야 할 것으로 보인다. 이 관점에서 기존의 예제 코드를 확인해 보자.

 최초의 코드는 모든 객체가 자율성을 가지지 못했다. 소극장이라는 제3자가 손님의 가방을 뒤져서 돈을 가져간다. 우리의 의식대로 흘라가지 않는 것이다. 예컨데, 우리가 상상하는 현실에서는 관람객이 직접 자신의 가방에서 초대장을 꺼내 판매원에게 건내야 하는 것이다.

 또한 이 코드를 이해하기 위해서는 프로그램의 세부적인 객체들을 아주 많이 알아야 한다. 우리는 프로그램의 모든 내용을 알고 있는 상태로 코드를 읽지 않는다. 최소한의 정보만 가지고(또는 이름만 가지고) 코드의 역할을 예상하면서 코드를 읽어야 한다. 이런 상황에서 다양한 객체에 접근해서 목적을 달성하는 일은 코드를 읽어가는 사람들에게 큰 부담을 준다.

변경에 취약한 코드

 사용자가 가방 없이 삼성페이를 사용한다고 가정하자. 우린 얼마나 많은 코드를 변경해야 하는가? 그리고 얼마나 다양한 곳에서 코드를 변경해야 하는가?

 우리가 코드를 변경하면서 가장 많이 어려움을 겪는 것은 사이드 이펙트를 예상해서 미리 해결해야 하는 것이다. 사이드 이팩트가 발생하는 이유는 우리가 수정하려는 객체나 메소드가 너무 다양한 곳에서 사용되어서 그런 것 인데, 이러한 문제를 미리 예방하고 또 해결하는 것이 의존성을 줄이는 것이다. 
 하지만 변경이 두렵다고 의존성을 무한정 줄일 수 도 없는 노릇이다. 객체지향이란 객체간의 메시징을 통해서 상호작용하는 것을 의미하기 때문이다.

3. 설계 개선하기

 앞서 언급한 2가지 문제점을 설계를 개선해서 해결해보자. 예상을 빗나가는 코드를 예상할 수 있도록 만들고, 변경에 취약한 코드를 변경에 용이한 코드로 만드는 것이다.

자율성을 높이자

 이 챕터에서는 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 캡슐화를 진행한다. 또한 캡슐화를 통해서 인터페이스와 구현을 분리하고, 이를 통해서 결합도가 낮아지고 변경에 유연하도록 해준다.

무엇이 개선됐는가

 수정을 통해 각 객체의 자율성을 가지고 행동하므로서 예상할 수 있는 코드가 되었고, 인터페이스와 구현을 분리하므로서 변경에 용이한 코드가 되었다.

어떻게 한 것인가

 객체의 자율성을 높히는 방향으로 설계했더니(캡슐화를 잘 했더니) 이해하기 쉽고 유연한 설계를 얻을 수 있었다!

캡슐화와 응집도

 자율성을 높히는 키포인트는 바로 객체간에 오직 메시지를 통해서만 상호작용 하도록 한 것이다.(Tell, don't ask) 이는 세부 기능과 상태를 캡슐화 하므로서 할 수 있었고, 이는 높은 응집도의 객체를 만들 수 있었다.

절차지향과 객체지향

• 절차지향 프로그래밍
  프로세스와 데이터를 별도의 모듈에 위치시키는 방식
• 객체지향 프로그래밍
  프로세스와 데이터가 동일한 모듈 내부에 위치시키는 방식

우리가 최초로 작성한 예제 코드는 절차지향 프로그래밍의 예시이고, 변경된 예제 코드는 객체지향 프로그래밍의 예시이다. 다시말해서 앞서 문제를 식별하고 해결한 과정은 절차지향 프로그래밍에서 객체지향으로 패러다임이 변하는 모습을 보여준 것이며, 이에 따라 얻게 된 장점을 나열 한 것이다.
 절차지향은 정의 때문에 필연적으로 이해하기 어렵고, 변경에 유연하지 못하다. 하지만 객체지향은 캡슐화를 이용해 의존성을 적절히 관리함으로서 객체사이의 결합도를 낮춘다. 이를 통해 이해할 수 있으며, 변경에 유연한 코드가 되는 것이다.

더 개선할 수 있다

사실 앞선 예제 코드의 개선활동에서 완전히 자율적인 객체들 만으로 구성된 코드를 만들지는 않았다. 이러한 부분을 해결한다면 추가적인 의존성이 생기기 때문이다.

 앞서 언급했듯, 결합도를 높히는 것은 변경에 유연하지 못한 코드를 만들게 된다. 이번 코드 변경은 자율성을 높히고 캡슐화를 더 강하게 만들어서 정보은닉과 객체 상태를 변경하는 지점이 적어지는 것을 목적으로 했으나, 추가적으로 결합도가 높아지는 문제를 수반하게 되었다. 
 결국 완벽한 설계라는 것은 없는 것이다. 설계는 트레이드오프의 결과물이며, 설계는 균형의 예술인 것이다.

그래, 거짓말이다!

 앞서서 Theater과 Bag, TicketOffice가 자율성을 가져야 한다는 것은 자연스러운가? 이상하다. 앞서서 우린 예상할 수 있는 코드를 작성해야 한다고 이야기하면서 의식대로 흘러가는 코드가 필요하다고 말했다. 그럼 객체지향이란 의식에 따라서 흘러갈 수 없으며, 예상할 수 있는 코드를 만들어야 한다는 사실은 순전히 거짓말인 것인가?
 그래 거짓말이다! 객체지향의 세계는 현실과 똑같지 않아서 언제나 의식에 부합하는 코드만을 만들 수 없다. 객체지향의 세계에서는 모든 객체가 능동적이고 자율적인 존재가 된다. 이를 의인화원칙이라고 부른다.

4. 객체지향 설계

설계가 왜 필요한가

 설계란 코드를 배치하는 것이다

설계는 변화를 수용할 수 있는 형태로 코드를 배치하는 것이 중요하다. 변경을 수용할 수 있는 설계가 중요한 이유는 코드를 변경할 때 버그가 추가될 가능성이 높기 때문이다. 우리는 필연적으로 코드를 수정하게되고, 이때 발생하는 버그는 우리에게 두려움을 불러 일으켜서 코드 수정을 회피하게 한다.(이에대한 좋은 해결방안인 TDD가 있다.)

객체지향 설계

 앞서 언급한 이유로 변경에 유연하게 대응할 수 있는 코드가 좋은 설계이다. 객체지향 프로그래밍은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수원하게 대응할 수 있는 가능성을 높여준다. 

http://www.yes24.com/product/goods/106729751

책 목차:

01_데이터 파이프라인 소개: https://inhyeok-blog.tistory.com/m/28

02_최신 데이터 인프라: https://inhyeok-blog.tistory.com/29

03_일반적인 데이터 파이프라인 패턴: https://inhyeok-blog.tistory.com/30

04_데이터 수집: 데이터 추출:

05_데이터 수집: 데이터 로드:

06_데이터 변환하기:

07_파이프라인 오케스트레이션:

08_파이프라인의 데이터 검증:

09_파이프라인 유지 모범 사례:

10_파이프라인 성능 측정 및 모니터링:

데이터 파이프라인 설계는 다양한 제약사항(준 실시간성, 최종 설과가 ML모델 or 대시보드 등)이 존재한다. 따라서 숙련된 엔지니어도 데이터 파이프라인 설계는 어려운 일이다. 하지만 이를 해결하기 위한 몇가지의 패턴을 통해서 도움을 받을 수 있다. 

1. ETL과 ELT

ETL과 더 현대적인 ELT, 두 패턴 모두 데이터 웨어하우스에 데이터를 공급하고 분석가나 보고 도구가 이를 유용하게 쓸수 있게 하는 데이터 처리에 대한 접근 방식이다.

Extract(추출): 로드 및 변환을 준비하기 위해 다양한 소스에서 데이터를 수집하는 단계

Load(로드): 원본 데이터(ETL의 경우) 또는 변환된 데이터(ELT의 경우)를 최종 대상(데이터 웨어하우스, 데이터 레이크 등)으로 가져오는 단계

Transform(변환): 분석가, 시각화 도구 등에 유용하게 쓸 수 있도록 소스 시스템의 원본 데이터를 결합하고 형식을 지정하는 단계

2. ETL을 넘어선 ELT의 등장

ETL은 수십년동안 데이터 파이프라인의 표준이었다. 이 표준은 여전히 사용되고 있지만(심지어 어떤 상황에서는 ELT보다 유리하다[https://dining-developer.tistory.com/50]) 최근에는 ELT라는 추가 선택지가 등장했다. 이는 대용량 스토리지와 높은 컴퓨팅 파워를 가진 클라우드 서비스의 등장고, 열-기반 DBW(SnowFlake/RedShift/Bigquery)의 등장이 배경이 된다.
 예전에는 방대한 양의 원보데이터를 로드하고 이를 사용 가능한 데이터로 변환하는 데 필요한 스토리지나 컴퓨팅 자원이 모두 모여있는 데이터 웨어하우스에 액세스할 수 없었다. 하지만 클라우드 컴퓨팅을 통해 확장에 용이한 환경을 구성할 수 있게 된 것이다.
 또한 열-기반 DBW는 OLAP(온라인 분석 처리)를 더 효과적으로 처리할 수 있도록 했다. DB의 I/O효율성, 데이터 압축, 데이터 처리를 위한 여러 병렬 노드에 데이터 및 쿼리를 분산하는 기능을 통해 데이터 변환(Transform)은 열-기반 DBW에서 담당하고, 파이프라인은 데이터 로드(Load)에 집중할 수 있게 된 것이다.

 column store database의 신흥 강자 ClickHouse도 시간나면 살펴보자

3. EtLT 하위패턴

ELT가 지배적인 패턴이 되었지만, 그럼에도 로드하기 전에 약간의 변환은 필요하다. 이때의 변환은 비즈니스 논리 또는 데이터 모델링을 위한 변환이 아니라 민감한 데이터를 마스킹 하는 것과 같이 법적 또는 보안상의 이유로 파이프라인 초기에 필요한 것이다. 

- 테이블에서 레코드 중복 제거

- URL 파라미터를 개별 구성요소로 구문 분석

- 민감함 데이터 마스킹 또는 난독화

4. 데이터 분석을 위한 ELT

데이터 엔지니어는 데이터 파이프라인 전체를 구성하는 일을 하고, 데이터 분석가는 수집된 데이터를 기반으로 유의미한 정보를 얻어내는 일을 한다. 이때, 유의미한 정보를 얻어내는 일은 데이터 파이프라인에서 변환(Transform)에 해당하는 일인데, 기존의 ETL에서는 데이터 분석가가 데이터 파이프라인 전반에 걸쳐서 작업을 수행해야했다. 하지만 ELT의 경우에는 추출(Extract)와 로드(Load)를 데이터엔지니어가 담당하고, 데이터 분석가서 변환(Transform)을 담당하므로서, 팀 구성원들이 더 낮은 상호 의존성을 휙득하여 ELT 자체의 강점에 집중할 수 있다. 또한 ELT패턴은 데이터 엔지니어가 분석가가 데이터로 수행할 작업을 정확히 예측해야 하는 필요성을 줄여준다. ELT의 경우 변환 단계를 나중으로 넘김으로써 분석가에게 더 많은 옵션과 유연성을 제공할 수 있는 것이다.

5. 데이터 제품 및 머신러닝을 위한 ELT

데이터는 분석, 보고 및 예측 모델 이상의 용도로 사용된다. 데이터 제품을 강력하게 만드는 데도 사용되는데, 데이터 제품의 몇 가지 일반적인 예는 다음과 같다.

 비디오 스트리밍 홈 화면을 구동하는 콘텐츠 추천 엔진

 전자상거래 웹사이트의 개인화된 검색 엔진

 사용자가 생성한 레스토랑 리뷰에 대한 감성분석을 수행하는 애플리케이션

이런한 각 데이터 제품은 ML모델에 의해 구동될 가능성이 높다. 이러한 데이터는 다양한 소스 시스템에서 가져올 수 있으며 모델에서 사용할 수 있도록 일정 수준의 변환을 거칠 수 있다.

- 머신러닝 파이프라인의 단계

 데이터 수집 - 데이터 전처리 - 모델 학습 - 모델 배포

- 파이프라인에 피드백 통합

좋은 ML파이프라인은 모델 개선을 위한 피드백 수집도 포함된다. (최근에는 A/B테스팅도 중요하다.) 이를 위해서 사용자들의 행위를 수집해서 데이터 웨어하우스로 다시 수집하고, 학습 데이터 또는 미래 모델이나 실험에 쓰기 위해 모델의 향후 버전에 통합 할 수 있다. 

http://www.yes24.com/product/goods/106729751

책 목차:

01_데이터 파이프라인 소개: https://inhyeok-blog.tistory.com/m/28

02_최신 데이터 인프라: https://inhyeok-blog.tistory.com/29

03_일반적인 데이터 파이프라인 패턴: https://inhyeok-blog.tistory.com/30

04_데이터 수집: 데이터 추출:

05_데이터 수집: 데이터 로드:

06_데이터 변환하기:

07_파이프라인 오케스트레이션:

08_파이프라인의 데이터 검증:

09_파이프라인 유지 모범 사례:

10_파이프라인 성능 측정 및 모니터링:

이 책에서는 일괄 처리/스트리밍 데이터 수집, 직접 구축하는 것/제품을 구매하는 것 과 같이 데이터 파이프라인을 구축할 때 일반적인 의사결정사항에 대한 내용을 다룬다.

1. 데이터 파이프라인이란?

 데이터 파이프라인은 다양한 소스에서 새로운 가치를 얻을 수 있는 대상으로 데이터를 옮기고 변환하는 일련의 과정이다. 일반적으로는 데이터 추출, 데이터 가공, 데이터 유효성 검사를 포함한 여러 단계로 구성되며, 때때로 머신러닝 모델이 포함되기도 한다. 이러한 과정은 데이터 크기, 상태, 구조 등의 환경에 따라서 달라진다.

2. 누가 파이프라인을 구축할까?

 데이터 엔지니어이다. 데이터 엔지니어는 요구사항을 파악하고 확장 가능한 프로덕션 상태로 전환하는데 도움을 준다. 또한 데이터 유효성과 적시성을 보장하는 것을 중시한다. 이러한 역할을 수행하기 위해서 데이터 엔지니어들은 아래와같은 공통적인 기술을 가지고 있다.

 - SQL과 데이터 웨어하우징 기초

 - 파이썬 그리고/또는 자바

 - 분산 컴퓨팅

 - 기본 시스템 관리(Cloud, Linux, Loging 등)

 - 목표 지향적 사고방식

3. 왜 데이터 파이프라인을 구축할까?

 경영진은 깨끗한 차트와 대시보드를, 마케팅은 소셜 미디어에서 깔끔하게 포장된 통찰력을, 고객 지원부서는 예측 수요 모델의 산출물을 기반으로 콜 센터 직원을 최적화 하기도 한다. 이런 결과물들은 데이터 파이프라인을 거쳐서 보여지는 것이며, 이를 위해서 데이터 파이프라인에서는 원본데이터 정리/정형화/정규화/결합/집계/마스킹/정제 등의 작업이 일어난다. 

4. 어떻게 데이터 파이프라인을 구축할까?

 일반적으로 Python/Java(요즘은 Go가 치고올라오고있다) Sql이 사용된다.

Chapter 1 자라기

당신은 몇 년 차?

소프트웨어 시장에는 경력(연차)가 높은 사람이 고급 인력이라는 인식이 있습니다. 하지만 저자는 이를 부정하며, 오히려 연차를 기준으로 임금을 결정하는 방식이 관료주의적이며, 결과적으로 조직에 손해를 끼치는 방향이라는 점을 주장하려고 합니다.
존 헌터(John Hunter)는 채용시 고려하는 각 항목들과 실제 직무 수행간에 성과의 상관성을 측정하는 연구를 수행했습니다. 그 결과는

항목	상관성
경력	0.18
학력	0.10
필체	0.02
나이	-0.01
관심사	0.10
작업 샘플 테스트	0.54
아이큐	0.51
구조화된 인터뷰	0.51
성실성(성격테스트 기반)	0.41
꼼꼼함(성격테스트 기반)	0.31

으로 사실상 경력은 직무 수행능력과 연관성이 낮다는 결과가 나왔습니다. 물론 1~2년차의 경우에는 경력이 크리티컬한 상관성을 보여줬지만, 이는 단편적인 예시일 뿐입니다.
존 헌터의 연구는 소프트웨어 개발자를 대상으로 한 연구가 아닙니다. 하지만 톰 드마르코(Tom DeMarco), 티모시 리스터(Timothy Lister)의 연구 등에서 소프트웨어 개발의 경우에도 경력과 생산성은 아예 무관하다는 사실을 밝혔습니다. 반면 유의미한 상관성을 보인 항목이 있었는데, 이는 바로 개발자의 경험이 얼마나 폭넓고 다양했는지에 대한 것입니다. 이로서 경력의 양적인 면보다 질적인 면이 중요하다는 사실을 알게됩니다.
앞서 언급한 연구들은 '잘 뽑는법'에 관한 연구라면, '잘 키우는법'에 관한 연구에서는 업무 능력 향상에 투자한 시간 이 직무 성과와 유의미한 상관성을 보입니다. 이러한 꾸준한 공부는 IT분야와 같이 지식이 계속 업데이트 되는 경우라면 더더욱 큰 전문성의 성장을 이끌어냅니다. 회사 입장에서는 이러한 성장을 위한 시스템을 잘 구축하는 것이 회사와 개발자 모두에게 윈윈하는 방식입니다.
개발자가 성장(경력이 아닌 실력)을 위해서 할 일은 의도적인 수련 입니다. 하지만 업무를 하는동안에 의도적인 수련은 쉽지 않습니다. 이를 도와줄 수 있는 방법이 바로 피드백을 짧은 주기로, 교정할 기회가 있게 얻는 것 입니다. 이를 위해서 각 판단과 상황을 관찰한 결과를 기록해두고 후에 피드백하더라도, 판단의 이유를 명백하게 기억할 수 있도록 하는 것이 중요합니다.

여기서 하고싶은 말은 연차만으로 좋은 개발자가 될 수 없다! 좋은 개발자가 되기 위해서는 의도적인 수련을 꾸준히, 열심히 해라! 였습니다. 의도적인 수련을 위한 팁으로 꼼꼼한 기록을 통한 피드백과 교정을 언급했습니다. 이러한 방식으로 절차적 지식을 축적하고, 수정 할 수 있도록 하는 것입니다.

자기계발은 복리로 돌아온다

잡코리아의 설문에 따르면 하루의 1~2시간 이상을 자기계발에 투자하는 직장인이 3/2이상입니다. 이정도는 기본이라는 것이지요. 게다가 지식이나 능력은 복리로 이자가 붙기 때문에 더욱 노력해야합니다. 따라서 더 빨리 자라고 싶다면 이율을 높히는 법, 지속적으로 현명한 투자를 하는법 을 고민해야 합니다.
저자는 더글라스 앵겔바트(Douglas Engelbart)의 작업 구분방식을 인용합니다.

A : 제작, 개발, 생산, 판매 등과 같이 표면적이고 직접적인 성과를 내는 작업

B : A를 가능케 하는 시스템/프로세스를 설계하는것(A를 개선하는 것)

C : 사고방식과 상호 작용 방식을 개선하는 것(B를 개선하는 것)

이러한 구분 방식 중에서 B와 C 작업에 투자하는 비율을 늘리는 것을 복리로 성장하는 방식이라고 합니다. 즉, 어떻게 하면 더하기가 아닌 곱하기를 할 수 있을지, 어떻게 하면 곱하기의 비율을 높일 수 있을지를 고민하는 것입니다.

저자의 복리성장을 위한 방식은 치열한 성장을 위한 전략입니다. 저의 학창시절 공부법과 시간관리에 대해서 열심히 찾아봤던 기억이 떠오르네요. 그러한 노력덕분에 투자한 시간 대비 좋은 성적이 나왔던 것 같습니다. 하지만 절대적인 시간의 차이는 극복하지 못했지만요. 최근 인간공학(인지공학)이라는 과목을 공부하면서 이와 관련된 내용을 배웠습니다. 그런 지식들을 잘 활용해서 정리하고 활용해 나가는 것이 저의 성장에 큰 영향을 미치겠지요. 이에 대해서는 다른 포스팅에 꾸준하게 정리해나가겠습니다.

학습 프레임과 실행 프레임

저자는 실행프레임(주어진 과업을 이루어야할 성과로 여기는 생각)과 학습프레임(주어진 과업을 배울 경험으로 여기는 생각)에 관한 이야기를 합니다. 당연히 학습프레임이 실행프레임보다 큰 성장을 이루어 냅니다. 하지만 현실은 녹록치 않을 수 있습니다. 업무하면서 학습이 중요하다는 생각을 가지는 것은 어렵습니다. 이에대해 저자는 1년차 개발자 2명을 비교함으로서 답변합니다. 1년밖에 되지 않아서 책만보고 선임들에게 도움을 요청하지 않는 주니어가 있는가 하면, 1년밖에 되지 않아서 선임들에게 도움을 요청하고, 때로는 도움을 주는 주니어가 있었습니다. 결국 시각차이입니다.

저는 어릴적 자기개발서를 읽는 것을 좋아했습니다. 하지만 나이가 들어가면서 자기개발서가 뻔해지고, 지루해졌죠. 이제는 뻔한 문제를 새롭게 접근하는 자기개발서를 더 선호합니다. 이번 챕터는 오만한 제 생각을 부숴주는 글이었습니다. '매사에 배우는 자세로 임해라'와 같은 뻔한 말들은 이미 졸업한지 오래라고 생각했습니다. 하지만 머리로만 알고있는 이런 지식을 저는 전혀 실천하지 않고 있었습니다. 당연히 배워야겠죠. 당연히 성장해합니다. 뻔한말로 잘난척할 생각은 그만 버리고 몸으로 움직여야할 때 입니다.

가장 학습하기 힘든 직업이 살아남는다

인공지능의 등장은 우리의 방향을 고민하게 합니다. 언젠가 대체될 지도 모르는 능력을 키우는 것은 의미 없는 행위가 될 수도 있으니까요. 저자는 인공지능 시스템에 비해 인간이 유리한 영역을 '암묵지', '직관'이 작동하는 회색 영역이라고 언급합니다.
저자는 컴퓨터로 대체되기 힘든 변수 중에 5가지의 카테고리를 추립니다.

• 독창성 : 주어진 주제나 상황에 대해 특이하거나 독창적인 생각을 해내기, 혹은 문제를 해결하는 창의적인 방법들을 만들어내기
• 사회적 민감성 : 타인의 반응을 알아차리고 그 사람들이 왜 그렇게 반응하는지 이해하기
• 협상 : 사람들을 화해시키고 서로 간의 차이를 조정하려고 노력하기
• 설득 : 다른 사람들이 마음이나 행동을 바꾸게 설득하기
• 타인을 돕고 돌보기: 개인적인 도움, 치료, 감정적 지지, 혹은 동료, 고객, 환자 같은 타인들에 대한 기타의 개인적 도움을 제공하는 것

이러한 기준에서 우리는 컴퓨터로 대체되기 힘든 변수에 해당하는 능력을 키워야 합니다. 이런 업무를 수행하는 개발자를 프로그래머 가 아니라 소프트웨어 개발자 라고 이야기합니다. 소프트웨어 개발자는 소프트웨어를 뭘 만들지를 고민하고 설계하는 부분이 포함되며, 그 과정에서 타인과 상호작용하는 업무가 많습니다. 앞서 이야기한 독창성, 협상, 설득 등에서 차이가 나는 것입니다.

개발공부를 하면서 자주 듣던 이야기가 코드몽키가 되어서는 안된다 는 것이었습니다. 또한 김범준의장님(배달의 민족)은 개발자란 비지니스 벨류를 만들어 내는 사람이다 라고 말했습니다. 앞서 언급한 내용들과 일맥상통하는 이야기입니다. 이 책이 쓰여진 시점에는 없었지만, 지금은 자동으로 프로그래밍을 해주는 서비스까지 나왔습니다. 아직까지는 여러 이슈가 남아있지만 이러한 서비스들이 상용화 되는 것도 조만간일 것입니다. 제가 어떤 방향으로 나아가야할지는 명확합니다. 대체불가능한 개발자가 되자!

달인이 되는 비결

달인이 되는 비결은 꾸준히 반복하되, 실력을 개선하려는 동기 가 있어야하고 구체적인 피드백을 적절한 시기 에 받아야 합니다.

수십 년 동안 전문가가 안 되는 비결

논문<Conditions for intuitive expertise>에 의하면 전문가의 믿을 수 있는 직관이 형성되려면 타당성 과 피드백 이 필요합니다. 즉, 예측할 수 있는 일정한 규칙(타당성)과 즉각적이고 명확한 결과(피드백)이 필요하다는 것입니다. 하지만 소프트웨어 개발의 경우는 타당성도 낮고 피드백도 낮은 편입니다. 따라서 타당성을 높이기 위해 변수를 제한하고 실험을 하면서 규칙성과 인과관계를 찾으려고 노력해야하며, 주변사람들에게 피드백을 적극적으로 구해야합니다.

당신이 제자리걸음인 이유

실력을 높히기 위해서는 의도적 수련이 필요하고, 특히 의도적 수련을 질적으로 발전시키 위해서 동기와 피드백이 필요하다고 언급했습니다. 저자는 이에 추가적으로 적절한 난이도가 필요하다고 말합니다. 이는 미하이 칙센트미하이의 몰입이론과 일치하는 부분입니다. 미하이는 작업 난이도와 실력이 비슷한 부분에서 몰입을 경험하고, 최고 수준의 집중력을 보이며, 학습능력과 퍼포먼스가 최대치가 된다고 이야기합니다. 만약 작업 난이도보다 실력이 뛰어나면 지루함을 느낄 것이고, 작업 난이도보다 실력이 저조하면 불안감을 느낄 것입니다. 둘다 바람직한 상태는 아닙니다. 따라서 우리는 지루하거나 불안한 상황일 때 몰입하는 상황으로 우리의 상태를 이동시킬 필요가 있습니다. 지루할 때는 작업 난이도를 높히거나(추가적인 작업 수행하기/요구 수준 높히기, ex 자동화 테스트 만들기/요청을 100개 처리하는 환경 구축 -> 1000개 처리하는 환경 구축) 실력을 낮추는 방법(제약조건 달기, ex 디버거 안쓰기)으로 몰입 상태로 이동하고, 불안할 때는 작업 난이도를 낮추거나(작업 분할하기, ex 테트리스 만들기 -> 화면 가운데 사각형 그리기) 실력을 높혀서(전문가의 도움/도구 활용/비슷한 경험 복기, ex 페어프로그래밍/괜찮은 디버거 사용) 몰입 상태로 이동합니다. 이렇듯 몰입상태를 유지하는 것은 성장과 생산성 향상에 매우 중요한 요소인데 이를 잘 수행하기 위해서는 본인이 어떤 상태인지 아는 메타인지 가 중요합니다. 이를 위해서 계속해서 본인의 상태를 체크하는 활동이 필요합니다.
적절한 난이도 설정은 개인의 성장에도 중요한 요소이지만, 팀장으로서 팀원들에게 적절한 난이도를 설정해 주는 것도 중요합니다.

의도적 수련의 일상적 에시

프로그래밍 언어 배우기의 달인

전문성에 따라서 업무의 성과는 극명하게 나뉩니다. 미군에서 개발한 지뢰탐지기는 탐지율이 일반군인 10%, 전문가 90%로 80%나 차이가 나기도 했죠. 이러한 전문가의 방법을 배우려면 작업분석 이라는 기법을 활용해서 기술을 뽑아내기도 합니다. 그 방법은 전문가에게 구체적인 사건에 대해 말하도록 유도하는 것 입니다. 예컨데 유명한 개발자에게 언어를 습득하는 방법을 뽑아내기 위해 최근 언어 학습 경험을 물어보는 것이죠. 아래에서는 저자가 개발자에게 전문성을 뽑아낸 과정을 서술합니다.
첫째로, 이 전문가는 해당언어(Go)의 튜토리얼을 읽으면서 어떤 것을 만들고싶은지(단어 갯수 세기 프로그램) 고려하면서 튜토리얼을 읽는다고 합니다. 그리고 만들고 싶은 프로그램을 만들 수준이 되면 튜토리얼을 멈추고 해당 프로그램을 구현하고 다시 튜토리얼을 읽습니다.
둘째로, 이 전문가는 표준 라이브러리 소스코드를 읽습니다. 언어를 배운다는 것은 문법과 키워드를 익히는 것이 아니라 코드 스타일을 익히는 것이라고 생각하기 때문이죠. 이러한 관점에서 언어를 배우기위해 가장 효과적인 교보재는 해당 언어의 표준 라이브러리가 작성된 방식입니다. 즉 전문가는 튜토리얼을 공부하는 것 만으로는 그 언어의 숙어와 패턴, 스타일을 배우기 불충분하다는 것을 알고 있는 것이죠.
셋째로, 다른 사람의 코드에 내가 필요한 기능을 추가합니다. 실제로 해당언어로 구현된 오픈소스를 다운받아서 새 기능을 추가했습니다. 이때 전문가는 아주 작은 기능 하나를 추가합니다. 이러한 방식으로 실제 코드의 감(읽고 쓰기)를 익히는 것입니다. 게다가 피드백은 덤이죠.

첫번째 방법은 적극적 읽기로, 무언가를 읽을 때 구체적인 질문이나 목적을 가지고 있는 방법을 말합니다. 죽은 공부를 하지말고 적극적으로 질문을 던지고 목적을 가지고 공부하라는 것이죠.

실수는 예방하는 것이 아니라 관리하는 것이다

실수를 대하는 문화는 크게 두가지가 있습니다. '실수 예방', '실수 관리'. 실수 예방은 실수를 저지르지 말라고 요구합니다. 따라서 실수한사람을 비난하고, 처벌하고, 당사자는 실수를 감추게 됩니다. 하지만 실수 관리는 실수가 더 나쁜 결과를 내기전에 빨리 회복하도록 돕고, 실수를 공개하고, 실수를 통해 배우는 분위기입니다. 비용측면에서도 실수관리 문화가 수익성이 높습니다. 그 이유는 실수를 통해 학습해야만 실수를 줄일 수 있기 때문입니다. 개인의 실수를 비난하고 예방하기만 한다면 결국 실수한 경험이 공유되지 못하고, 더욱이 이를통해 무엇인가를 배울 수도 없습니다.

나의 실수를 대처하는 방식은 극명하게 실수예방 이었습니다. 실수가 발생하더라도 수습하기 바쁘고, 없었던 일처럼 지나가게 하기위해서 노력헀죠. 우리학교 교수님께서 디자인띵킹에 대해서 강의하실때도 유의미한 실패를 반복하라고 이야기 하곤 하셨습니다. 이런 이야기들이 같은 맥락에서 있는 것 같Chapter 1 자라기습니다. 실패,실수를 적극적으로 활용하고 관리하도록 합시다. 저자의 홈페이지에 있는 실수노트를 작성하는 것도 좋은 방법같습니다.

실수 노트 양식은 다음을 참고로 합니다.
제목 : 이 실수에 기억하기 좋은 이름을 붙입니다.
관련인 : 해당 실수에 관련있는(결과에 영향을 주거나 받거나) 사람들을 적습니다
타임라인 : 가로로 수평선을 그리고 어느 시점에 실수가 발생했고, 언제 최초 감지 되었고, 언제 최초 회복 작업을 시작했는지 표시합니다. 그 외에 중요 한 사건들이 있으면 역시 표시합니다.
실수 시점 분석: 실수 시점에 대한 자세한 설명입니다. 구체적으로 실수가 무엇이었는지. 원래는 뭘 했어야, 혹은 안했어야 했는지를 적고, 왜 그런 실수가 일어났는지 적습니다.
감지(detect) : 무엇을 보거나 듣고 처음 실수를 감지했는지. 그리고 당시에 어떤 (부정적) 미래가 펼쳐지리라 추측했는지.
회복(recover) : 회복을 위해 무엇을 했는지. 당시 다른 옵션은 무엇이 있었는지. 왜 그 옵션을 선택했는지.
결과 : 그 후에 결과적으로 어떻게 되었나.
교훈 : 다음번에 비슷한 실수를 어떻게 더 빨리 감지할 수 있을지, 어떻게 더 빨리 회복할 수 있을지, 혹은 실수 발생 전 시점의 행동 자체를 어떻게 교정하면 좋을지.

작가 홈페이지

뛰어난 선생에 대한 미신

이제껏 학습의 중요성과 조건 등을 살펴봤습니다. 이 글과 다음 글에는 배워도 별로 효과를 보지 못하는 경우를 알아봅니다.
뛰어난 선생은 많이 알고있는 사람이 아닙니다. 본인의 지식이 익숙해지면서 암묵화 되는 경우가 있기 때문이죠. 실례로 의사가 간단한 수술법을 가르칠 때도 성공적으로 수술을 진행하기 위한 지식의 30%만 가르치고 있다는 연구가 존재합니다. 이러한 현상을 극복하기 위한 방법은 학생과 선생이 인지적 작업 분석 같은 방법을 사용해 보는 것입니다. 학생의 경우 자신과 학생에 대한 분석을 잘하는 선생을 고르는 것이 유리한 전략일 것입니다.

나홀로 전문가에 대한 미신

어떤 기술적 실천 법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요 합니다. 예컨데 상사가 내가 하는 일을 보고 반대하면 그를 설득해야 하며, 하다가 모르는 것이 생기면 주변에 물어봐야 하니까요. 세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없습니다.
존 가트맨은 자신의 책 신뢰의 과학에서 신뢰가 깨어져 있는 상태에서는 어떤 행동을 해도 악의적으로 보인다는 연구를 언급합니다. 직장에서도 비슷합니다. 팀장이 선의로 책을 선물해도 팀원들은 '나 보고 이런 거 모르니 공부하라는 얘기야? 지는 뭘한다고..'와 같이 생각할 수 있는 것이죠. 이러한 신뢰를 사회적 자본이라고 합니다. 사회적 자본이 좋은사람은 사회적 기술이 일반적으로 뛰어납니다.
전문가는 도메인지식 뿐만이 아니라 사회적 자본과 기술도 뛰어납니다. 벨 연구소는 뛰어난 연구자의 결정적인 특징은 사회적 자본, 특히 소셜 네트워크의 차이였습니다. 뛰어난 연구자는 같은 부탁을 해도 훨씬 더 짧은 시간에 타인의 도움을 얻었습니다. 개발자의 경우도 다르지 않습니다. 시니어 개발자에게 초보개발자에게 해줄 조언을 적어보라 했을 때, 뛰어난 개발자들의 70%는 동료와의 협력을 언급하는 반면 실력이 그저그런 개발자들은 20%만 동료와의 협력을 언급했습니다.
그럼 사회적 기술을 키우기 위해선 어떤 방법이 있을까요? 기본적으로 일상에서 하는 인사, 대화, 질문 등에 신경쓰면서 이를 기록하고, 복기하고, 다른 인터랙션을 가정해 보는 것 만으로도 도움이 될 수 있습니다.

취직이 다가올 수록 사회적 기술을 등한시 하게 되는 것 같습니다. 지금 급한건 코딩테스트, 개발능력이라고 느껴지기 때문이겠죠. 하지만 저자는 제게 그렇지 않다고 이야기하고 있습니다. '세상의 어떤 일도 골방에서 혼자 이루어 낼 수 없다고'.