25분 동안 일에 집중하고 5분 휴식합니다. 이것을 한 포모도로라고 합니다. 완전히 몰입하고 휴식을 통해 환기시킬 수 있는 효율적인 시간 관리 기법입니다.

집중하고 몰입하는 게 중요다고 하지만 시야가 좁아진다는 단점도 있습니다. 어떤 풀리지 않는 문제 때문에 골머리를 앓다가, 갑자기 허무하게 해결해 본 경험이 다들 있으실 겁니다. 그래서 무조건 몰입만 하는 것은 안 좋을 수 있는데, 포모도로는 5분이라는 강제적인 휴식 때문에 주변을 환기하는 데 도움이 됩니다.   

그래서 위의 과정을 엄격하게 지켜서 시간 관리를 하면 포모도로는 나만의 단위가 생깁니다. 예를 들어서 한 번의 포모도로에 20페이지의 책을 읽었다면, 네 번의 포모도로면 80페이지를 읽을 수 있고 이렇게 계산하면 내가 이 책을 읽는 데 얼마나 걸릴지 예측할 수 있게 됩니다.  

이러한 장점 때문에 업무 시간, 개인적인 시간에 포모도로를 하는 것을 굉장히 선호하는데, 그 과정에서 어려움도 많았습니다. 오늘은 그 여정기를 공유하고자 합니다.

## 전용 앱 사용하기

![포모도로 앱](https://a.storyblok.com/f/92702/1068x827/e7e92115ff/.png)

일단 포모도로를 하려고 하면 타이머를 찾게 됩니다. 전용 포모도로 앱이 시중에 많이 나와있습니다. 자동 시작이나 자동 휴식 시간으로 전환되고 알람도 되고 좋은 점이 많습니다. 특히 가장 좋은 점은 히스토리 관리가 됩니다. 더불어 통계 기능까지 있어서 내가 하루에 얼마나 시간을 사용했는지 한눈에 알 수 있다는 장점이 있습니다.  

하지만 포모도로의 최대 단점은 휴식 시간을 온전히 지키지 못한다는 것입니다. 혼자 하다 보면 더 쉬고 싶죠. 그러다 보니 집중시간 1시간에 휴식시간이 2시간이 돼버립니다.

## 같이 하기

![쿡쿠와 스프레드 시트](https://a.storyblok.com/f/92702/1158x500/26400a4fbb/cuckoo.png)

같이하면 좀 더 낫습니다. 오프라인으로 같이 모여서 한다든지, 아니면 온라인상에서 공용 타이머를 두고 할 수 있습니다. 이 타이머는 공용이기 때문에 시간을 어기기가 쉽지 않습니다. 그리고 스프레드시트를 사용해서 하는 일을 적고 스케줄도 같이 맞춰서 하면 혼자서 시간을 지키지 않는다든지 하는 위험이 줄어듭니다. 하지만 마음 맞는 사람을 같이 찾아야하는 어려움이 있습니다.

## 타이머

![타임타이머](https://a.storyblok.com/f/92702/3024x3024/eaf4d43aba/.jpg)
컴퓨터를 사용하게 되면 딴짓을 하게 될 가능성이 높습니다. 우리를 유혹하는 너무 많은 것들이 있기 때문이죠. 유튜브 넷플릭스 등등 포모도로를 키려고 하다가 유혹에 넘어가버릴 수 있습니다. 이럴 때는 타이머를 사용할 수 있습니다. 아주 빠르게 타이머를 시작할 수 있다는 장점이 있지만 자동으로 휴식 전환이라든지 기록해 주는 기능은 없습니다.

## 스마트 전구

![스마트 전구](https://a.storyblok.com/f/92702/980x500/c16b988ef3/smartbulb.jpg)

알람을 무시한다든지, 아예 타이머를 키지 않는다든지 하는 경우에는 속수무책입니다.
코드숨 사무실에서는 스마트 조명을 사용해서 쉬는 시간에는 파란색, 집중 시간에는 일반 조명을 틀어놔서 포모도로 시간을 인지할 수밖에 없는 환경을 만들었습니다. 맨 처음에는 아예 꺼버리려고 했는데, 밤에 무서울 것 같아서 쉬는 시간에는 파란색 조명으로 바뀌도록 했습니다. 

## 모래시계

![모래시꼐](https://a.storyblok.com/f/92702/3024x4032/388362acfa/hourglass.jpg)

최근에 시도해 본 건데, 모래시계는 굉장한 장점이 있습니다. 바로 중지와 되돌리기 기능이 없습니다. 만약 내가 중간에 집중이 깨져서 다시 시작하고 싶다고 해도 모래를 쏟아붓고 다시 할 수 없습니다. 그래서 계속해서 하게 만드는 장점이 있습니다. 단점은 소리라든지, 시간을 알아챌 수 없다는 단점이 있습니다. 그리고 25분 타이머는 국내에는 파는 곳이 별로 없어서 알리에서 직구를 해야 합니다.

## 불렛저널

![불렛저널](https://a.storyblok.com/f/92702/3024x4032/d098ecf2b3/.jpg)

내 목표가 항상 눈에 보이는 게 좋아서 공책에 불렛저널로 할 일을 관리합니다. 오늘 할 일을 적을 때 몇 포모도로 걸리 것 같은지도 적고, 예상과 빗나갔을 때는 빨간색 펜으로 표시를 합니다. 아이패드에 기록하는 것은 충전도 너무 귀찮고 켜야지만 보인다는 굉장한 단점이 있고요. 컴퓨터에 기록하는 것은 마찬가지로 해당 앱을 켜야 보인다는 게 굉장한 단점입니다. 반면에 다이어리는 항상 켜져 있고 떨어트려도 깨지지 않습니다. 그래서 오프라인 다이어리를 좀 더 선호합니다.

## 앞으로

앞으로도 계속해서 더 효율적인 시간 관리를 위해서 노력할 것입니다. 지금도 굉장히 많은 시도를 하고 좋은 점은 배웠지만 반드시 더 나은 방법이 존재할 것입니다. 여러분들도 여러 시도를 통해서 자신만의 방법을 찾으셨으면 좋겠습니다.


더 효율적인 시간 관리를 위해 포모도로를 리팩터링한 경험을 공유합니다

더 나은 포모도로를 위한 여정기

저는 요즘 닌텐도 스위치 스포츠에 푹 빠져 있습니다. 특히 배구에 빠져 있습니다. 다른 게임들과 다르게 팀워크가 중요하고, 특히 서브를 위한 빌드 업을 해서 공격하는 것이 맘에 들었습니다.

공을 토스하면서 "자 간다!"라고 외칩니다. 이 말을 들은 우리 팀은 무슨 뜻인지 정확하게 이해하고 타이밍에 맞게 서브를 날립니다. 제가 "자 지금부터 내가 너에게 공을 토스해 줄 거야. 네가 편하게 칠 수 있도록 공을 올려줄게. 너는 타이밍을 맞춰서 점프를 한 다음, 상대방의 블락을 피해서 스파이크를 날려!"라고 하지 않아도 됩니다. 짧은 한마디로 제 모든 의도를 전달할 수 있습니다.

이런 일이 가능한 이유는 팀원들간에 공통 기반 지식이 있기 때문입니다. 척하면 척 알아듣는거죠. 이러한 공통 기반은 우리가 커뮤니케이션을 효율적으로 할 수 있는데 아주 큰 도움이 됩니다.

이러한 공유된 믿음은 다른 사람들에 대해서 정확한 가정을 할 수 있게 해주며, 무엇을 할 것인지 정확하게 예측할 수 있게 해줍니다. 서로에 대해 예측 가능성이 높을수록 팀의 성과도 높다는 연구결과가 있습니다. 이걸 다른 말로 하면 투명성이라고도 부릅니다. 서로 알고 있는 지식이 상식처럼 여겨진다면, 투명성이 높다고 볼 수 있습니다.

하지만 이러한 공통 기반은 우리가 생각하는 것만큼 잘 동작하지는 않습니다. 공통 기반은 서서히 손상되고, 오해를 불러일으킵니다. 상황도 바뀌고 목표도 바뀌면 공통 기반을 유지하기 힘들어집니다. 특히 복잡하고 변화하는 상황에서는 더더욱 그렇습니다. 심지어 소프트웨어 개발팀은 공통 기반을 가지고 있는 사람이 바뀌기도 합니다.

다음은 제가 실제로 코드 리뷰를 남긴 사례입니다.

> 1. 바람직한 컴포넌트의 작명 기준
>
> ClickMe 컴포넌트와 Button 컴포넌트명을 지을 때 고민이 되었던 사항이 있습니다.  
> 저는 핵심적인 정체성이 잘 드러나면 될 것 같아서 ClickMe는 굳이 Button이라고 명시하지 않았습니다.  
> 둘 다 버튼을 누르면 조작되고 보여지는 컴포넌트라는 특성이 있지만,  
> 다른 역할을 할 때 컴포넌트 이름을 어떻게 지으면 좀 더 직관적이게 될지 고민입니다.

위 질문에 대하여 다음과 같이 답변을 남겼습니다. 

![](https://a.storyblok.com/f/92702/1144x523/b4a1774e42/2023-08-21-11-29-48.png)

1. 이러한 일이 발생하는 이유는 다른 사람들도 내가 이해하는 대로 이해할 거라고 생각하기 때문입니다. 내가 지금 기억하고 있는 것을 미래의 그때에도 기억할 거라고 생각하기 때문입니다.
2. 단어라는 것은 다르게 해석될 수 있습니다. 단순한 단어보다는 예를 들어서 설명하는 것이 훨씬 정확하게 전달할 수 있는 방법입니다. 이러한 예시를 우리는 테스트 코드로 작성할 수 있습니다.
3. 사람마다 가지고 있는 지식은 다를 수 있습니다. 각자 가지고 있는 지식이 다르기 때문에, 그 사람도 알고 있을 거라고 착각할 수 있습니다.

우리는 공통 기반을 지속적으로 감독하고 수정해야 합니다. 팀원들이 바뀌어도 영향이 없도록 공통 지식 언어를 만들고, 팀의 컨벤션 문서를 만들고 다듬어야 합니다. 또한 코드 리뷰를 통해서 이러한 지식들이 잘 만들어지고 있는지 감독하고 수정해야 합니다. 그리고 코드에 나만 아는 맥락으로 이해할 수 있는 코드를 만들어서는 안됩니다. 그러려면 명확하게 이해될 수 있는 이름, 이를 뒷받침하는 테스트 코드들이 있어야 합니다.

## 참고

- [](https://github.com/CodeSoom/react-week2-assignment-1/pull/185) 
- [프레임 \| 최인철 저자(글) \| 21세기북스](https://product.kyobobook.co.kr/detail/S000000711324)
- [이기는 결정의 제1원칙 \| 게리 클라인 저자(글) · 강홍구 번역 \| 21세기북스](https://product.kyobobook.co.kr/detail/S000000708253)


코드에 나만 아는 지식이 있으면 위험한 이유에 대해서 알아봅니다.

코딩할 때 남들도 다 알거라는 착각이 위험한 이유

"피드백 없이는 배울 수 없다."라는 말처럼 학습에 있어서 피드백이 굉장히 중요하다고 알려져 있습니다. 하지만 피드백이 있다고 해서 학습에 무조건 도움이 되지는 않습니다.  

우리가 양궁을 하고 있다고 가정해 봅시다. 화살을 쐈는데 내가 몇 점에 맞았는지 모른다면 실력이 늘 수 있을까요? 몇 점을 맞았는지 알아야 잘했는지 못했는지 알 수 있죠. 하지만 단순히 내 화살이 어디에 꽂히는지를 보는 것만으로는 무엇을 제대로 하고 있고, 무엇을 잘못하고 있는지를 알 수가 없습니다. 숨은 어떻게 고르는지, 활의 정렬은 어떻게 해야 하는지 피드백을 받아야 알 수 있습니다.  

여기서 점수는 결과에 대한 피드백입니다. 결과에 대한 피드백은 우리가 어떻게 하면 더 잘할 수 있는지를 파악 하는데 도움이 되지 않습니다. 실력을 향상시키기 위해서는 우리의 행동방식에 대한 과정 피드백이 필요합니다.  

피드백에도 한계는 존재합니다. 
1. 피드백을 준다고 해서 무조건 되는 것도 아니다. 받아들일 준비가 되어야 한다.
2. 피드백을 왜곡하면 피드백을 이해하는 일조차 안된다.
3. 피드백을 받고 주의를 기울여야 하는데 그렇지 못하면 아무 쓸모가 없다.
4. 피드백 제공하는 것 자체가 굉장히 어렵다. 특히 암묵적 지식에 대한 것을 제공하는 건 더 어렵다.
5. 행동 결과에 대한 피드백을 줘서 먹히는 상황은 단순한 경우만 그렇다. 복잡한 상황에서는 학습자들이 피드백을 해석해야만 한다.

피드백에 대한 모범 사례를 하나 소개해 드리겠습니다.  

> 항공모함에는 착함신호사관이 있어서 전투기의 착륙을 유도합니다. 전투기의 방향과 각도가 좋지 않을 경우 되돌려 보냅니다. 
> 
> 해링턴은 전투기 비행 조종사였는데, F-4에서 A-6 탑승 기종을 변경을 위해 새로운 조종법을 배웠다. 그리고 착함하는 능력을 평가하는 날이 되었다.
>
> 해링턴은 완벽한 각도와 방향으로 진입하고 있다고 생각했지만 계속해서 착함신호사관으로부터 계속 "오른쪽으로, 오른쪽으로"라는 말을 들었다. 해링턴은 자신이 틀리지 않았다고 생각하여 계속해서 시도했지만 계속해서 거절당했고 시험에 떨어질 위기에 빠졌다.
>
> 그날 밤 착함신호사관은 해링턴에게 가서 이렇게 물었다. "자네가 전투기의 방향과 각도를 맞추는 방법을 설명해 주겠나?" 해링턴은 항상 하던 방식대로 했다고 설명했다. 전투기의 기수를 중심선에 맞추고 착함을 위해 진입하는 방법이었다. 그 착함신호사관은 해링턴이 말한 것을 보고 평소에 조종했던 전투기와 차이를 생각해 보라고 말했다.
>
> 두 기종 사이에는 차이점이 하나 있었다. F-4는 전투기는 조종사가 정중앙에 앉고 A-6는 조종사가 양옆으로 앉는다 그래서 조종사가 전투기에 정중앙에 앉지 않는다. 해링턴도 그 사실을 알았지만 어떤 차이가 발생하는지는 몰랐다
>
> 착함신호사관은 해링턴에게 히치하이크를 하는 것처럼 엄지를 세운 채로 팔을 펴고, 출입문 등의 수직선에 엄지를 정렬해 보라고 했다. 그다음 그의 머리를 왼쪽으로부터 45센티미터 정도 이동시킨 다음 다시 문의 수직선에 정렬시켜보라고 했다. 그 즉시 해링턴은 자신이 전투기의 기수를 왼쪽으로 벗어나게 한다는 것을 깨달았다.

위 사례에서 착함신호사관은 상대방에 입장에서 생각했으며, 있는 사실을 그대로 전달하는 것이 아니라, 해링턴이 자신의 잘못을 쉽게 경험해 볼 수 있는 방법을 찾았습니다.

단지 피드백을 제공하는 것만으로는 충분하지 않습니다. 우리는 피드백을 이해할 수 있게 만드는 방법을 찾아야 합니다.  

왜 나는 보이는데 그 사람에게는 보이지 않는지를 파악하고, 그 사람이 볼 수 있는 환경을 만들어 주어야 합니다. 만약 곧바로 결과에 대한 피드백을 준다면 그 사람은 학습의 기회를 잃어버리고 이건 오히려 학습에 방해가 될 수 있습니다.

## 참고

- [이기는 결정의 제1원칙 \| 게리 클라인 저자(글) · 강홍구 번역 \| 21세기북스](https://product.kyobobook.co.kr/detail/S000000708253)


피드백의 한계를 알아보고 효과적으로 피드백하는 방법을 알아봅니다.

피드백만으로는 충분하지 않은 이유

팀에 잘하는 사람이 있으면 정말 든든합니다. 어떤 문제든 해결해 주고 모르는 것이 없습니다. 도메인 지식도 풍부하고 레거시 히스토리도 다 알고 있습니다. 정말 이 사람이 없었으면 어떻게 했나 싶습니다. 천만다행입니다. 하지만 이런 사람이 오히려 팀에 위기를 가져올 수 있다는 사실을 아시나요?  

소프트웨어 개발 팀은 개인보다 더 오래 살아남습니다. 언젠가 이 핵심 인력은 팀에서 나가게 됩니다. 다른 인원으로 보충해도 그 지식은 보충되지 않습니다.  

만약에 이 핵심 인력이 팀을 나가버린다면 무슨 일이 벌어질까요? 상상도 하기 싫습니다. 재앙입니다. 팀원들은 절망에 빠져 전의를 상실할 것입니다. 

팀에 핵심 인력이 있으면 안 됩니다. 모든 사람이 핵심 인력이 되어야 합니다. 그러려면 팀은 소프트웨어 장인 정신을 추구하고 후계자를 키우려고 노력해야 합니다.

소프트웨어 장인은 우수한 기술을 습득하고 공유하는 것을 가장 중요한 일로 여깁니다. 그냥 전문가와는 다르게, 장인 정신은 후계자를 키웁니다. 지금 자신이 핵심 인력이라면 다른 팀원들도 핵심 인력이 되도록 힘써야 합니다. 팀원이라면 핵심 인력의 지식을 모두에게 분배되도록 해야 합니다. 그랬다면 모든 사람들이 핵심 인력이 되었을 것이고, 누군가가 팀에서 나간다고 하더라도 팀은 유지할 수 있을 것입니다.  

버스 팩터(Bus factor)라는 말이 있습니다. 팀원이 버스에 몇 명이나 치여야 프로젝트가 망하는지를 나타내는 숫자입니다. 버스 팩터가 1이라는 말은 핵심 인력이 어느 날 갑자기 버스에 치인다면 팀은 프로젝트를 성공적으로 완료할 수 없다는 의미입니다. 가장 이상적인 숫자는 팀원의 숫자와 같습니다. 우리는 버스 팩터가 팀원의 숫자와 같아지도록 노력해야 합니다.

## 참고
- [프로그래밍 심리학 \| 제랄드 M. 와인버그 저자(글) · 조상민 번역 \| 인사이트 ](https://product.kyobobook.co.kr/detail/S000001032983)
- [프로그래머의 길 멘토에게 묻다 \| 데이브 후버 , 애디웨일 오시나이 저자(글) · 강중빈 번역 \| 인사이트](https://product.kyobobook.co.kr/detail/S000001469857)
- [Bus factor](https://en.wikipedia.org/wiki/Bus_factor)

소프트웨어 장인 정신이 개인뿐만 아니라 개발팀에도 중요한 이유를 알아봅니다

개발팀에 소프트웨어 장인 정신이 필요한 이유

백지 공부법은 공부한 것을 백지 위에서 모두 쏟아내면서 공부하는 공부법입니다. 그러면서 모르는 것을 발견하게 됩니다. 배운 것을 인출하면서 자연스럽게 암기도 됩니다. 심지어 장기 기억에도 더 오래갑니다. 하지만 손글씨가 느려서 시간이 너무 오래 걸린다는 단점이 있습니다.  

그러면 손으로 쓰는 게 오래 걸리니까 키보드로 입력하면 어떨까요? 이것이 바로 타이핑 공부법입니다. 손으로 쓰는 것보다 빠르기 때문에 시간이 많이 걸리지도 않으면서, 인출을 통한 아주 효율적인 공부를 할 수 있습니다. 덤으로 내가 공부한 것도 자료로 정리가 되니 언제든 다시 찾아볼 수 있습니다.

## 타이핑 공부법

구체적인 방법은 다음과 같습니다. 

1. 일정 시간 동안 책을 읽습니다. 너무 많이 읽으면 앞 내용을 다 기억하기 힘들고, 너무 적게 읽으면 학습 효과가 떨어집니다. 적당히 15분 정도가 좋습니다.
2. 책을 덮고, 배운 것을 쏟아냅니다. 기억나지 않는 부분도 있지만 괜찮습니다. 어차피 또다시 채울 것입니다.
3. 부족한 부분을 다시 읽고 위의 과정을 되풀이합니다. 이때 새로 채우는 부분은 빨간색이나 다른 색으로 씁니다.
4. 위 과정을 반복합니다.

사람들은 책을 보면서 따라치면서 정리를 합니다. 책을 보고 그대로 따라치는 것은 별로 도움이 되지 않습니다. 왜냐하면 첫째, 보고 따라치는 것은 인출이 아닙니다. 둘째, 이럴 거면 어차피 책에 있는 것을 그대로 보면 되는데 낭비 같은 생각이 듭니다. 셋째,  장기 기억에 남지 않습니다. 열심히 정리까지 해서 시간을 많이 투자했는데, 막상 기억에 남는 게 없으면 참 슬픕니다.  

결국 공부는 암기입니다. 이해가 되어야 암기가 되는 것이 아니라 암기가 되어야 이해가 됩니다. 책이 뒤로 갈수록 어려워지는 이유는 앞의 부분을 외우고 이해한 것을 가정하고 책을 전개하기 때문입니다.  

내 지식은 설명할 수 있는 지식과 설명할 수 없는 지식으로 나눌 수 있습니다. 설명할 수 없는 지식은 내 지식이 아닙니다. 알고 있다는 착각입니다. 타이핑 공부법으로 내가 배운 지식을 글로 작성하면 설명할 수 있는 지식이 됩니다. 설명할 수 있을 때 까지 공부하는 것입니다.

![타이핑 공부법 예제](https://a.storyblok.com/f/92702/1080x978/0dd0d694bf/typing-example.png)

코드숨에서 같이 읽기와 타이핑 공부법을 같이 적용해 봤습니다. 처음에는 기억도 잘 기억나지도 않고 어려움에 호소했지만, 타이핑할 것을 생각하고 책을 읽으니 집중해서 읽을 수 있었고 기억에도 오래 남을 수 있었습니다.

## 참고
- [공부 속도가 느리면 무조건 보세요. '이기는 공부법' (+ 연세대 과수석 성적 공개, feat. 타이핑 공부법)](https://www.youtube.com/watch?v=GYdJaxdS1qs)
- ["쓸데없는 메모 3위 '많이 쓴 메모' 2위 '보고 쓴 메모' 1위는..." 25년 기록학 전문가가 말하는 메모 '제대로' 하는 법 \| 김익한 교수 \| 빅퀘스천 30회](https://www.youtube.com/watch?v=L7zWucx7TR8)

타이핑 공부법을 통한 인출 위주의 학습법을 소개합니다.

개발자 책 읽는 법 - 타이핑 공부법

많은 개발자들이 오늘 배운 것을 기록하기 위해서 TIL을 작성하고 있습니다.  
"배운 것"이라고 하다 보니 대부분의 사람들이 오늘 공부하는 것을 적습니다.  
TIL은 공부한 것을 적으면 안 됩니다.  
일이 생겨서 공부를 하지 못한 날은 적을 게 없다고 생각하기 때문입니다.  

적을 게 없다면 우리는 왜 적을 게 없었을까?를 생각해 보아야 합니다.  
TIL을 효과적으로 적고 싶다면 깨달은 것을 적어야 합니다.  
깨달은 것은 통찰이라고도 부르는데, 내가 보지 못하던 것을 보는 것을 말합니다.  
혹은 같은 것을 보고도 다르게 보는 것을 말합니다.  

아마 이런 경험은 다들 있을 것입니다. 

> "아 이렇게 대답할걸! 왜 그땐 생각 못 했지?"

면접을 보고 나오는 길에 아쉬웠던 순간들이 떠오릅니다.  
이런 순간이 통찰을 얻는 순간입니다.

이러한 통찰을 얻으려면 오늘 있었던 일을 하나씩 되감기를 하듯 생생하게 그려봐야 합니다.  
지금에서야 다르게 보이는 것들을 떠올려봐야 합니다.

> "그러고 보니, 다시 생각해 보니"

TIL을 작성하면서 위와 같은 말이 많이 나올수록 성공적인 TIL입니다.

그러면 어떻게 생생하게 그려볼 수 있을까요?  
이런 그림을 그리는 데 도움을 주는 활동을 하나 소개합니다.

## 표현적 글쓰기

머릿속에서 떠나가지 않는 생각이나 고민 때문에 일상생활이 힘들 수 있습니다.  
우리는 어떤 방법이든 그 생각들을 뱉어내야 합니다.  
표현적 글쓰기는 자신의 고민들을 뱉어내는 글쓰기로 마음을 치유하는 글쓰기입니다.

### 마음 살피기 시

표현적 글쓰기의 종류 중에 시적 글쓰기가 있습니다.  
비유적인 언어와 이야기 구조를 사용하여 내 마음을 표현하는 것입니다.  
제인 케넌이 쓴 "그렇지 않을 수도"라는 시를 한 번 읽어봅시다.

> 나는 침대에서 나왔다  
> 시트는 부드럽고, 흰 고양이는 가르랑거리고  
> 그렇지 않을 수도 있었는데.  
> 나는 뜨거운 차 한 잔에  
> 너무나 즐거웠다  
> 그렇지 않을 수도 있었는데.  
> 
> 나는 침대 위에서 내 아이들과 놀았다.  
> 웃음, 간지럼, 기쁨.  
> 아침 내내 책을 읽고 글을 쓰고 달리기를 했다  
> 이 모두가 내가 좋아하는 일들.  
> 점심에 나는 뜨거운 샤워를 즐기고,  
> 그 후 친구의 집에 갔다  
> 그렇지 않을 수도 있었는데.  
> 
> 우리는 저녁을 먹었다, 맛있는 모로코 음식이었다  
> 와인을 마시고 이야기를 나누고 웃으며 또 먹고, 또 마시고.  
> 우정. 그렇지 않을 수도 있었는데.  
>
> 나는 침대에서 잤다  
> 창밖에 수국  
> 벽에는 우리 아이들의 그림, 그리고 또 오늘과 같은  
> 또 다른 하루의 계획을 세웠다.  
> 하지만 나는 안다. 어느 날, 그렇지 않을 수도 있다는 것을.  
>   
> \- 제인 캐넌  

일단 아침에 어떻게 일어났는지를 그리면 그 다음 행동이 그려집니다.  
그렇게 해서 잠들 때까지 하나씩 그려봅니다.  
그리고 마지막에 "그렇지 않을 수도 있었는데"를 붙여봅니다.  
그러면 좋았던 것은 그렇지 않을 수도 있었는데 좋았던 거고 앞으로도 계속하려고 합니다.  
아쉬웠던 점은 그렇지 않을 수도 있었는데 다음에 다르게 해볼 것을 생각해 봅니다.  

여기서 중요한 것은 머릿속에 그려보면서 관찰하는 것을 글로 설명하는 것입니다.  
자연스럽게 떠오르는 것을 적어보고, 내 속의 있는 비평가를 차단해야 합니다.

TIL을 쓰는 것보다 이렇게 마음 살피기 시를 써봅시다.  
하루에 있었던 일을 생생하게 그립시다.  
그리고 다르게 했을 수도 있겠다 생각해 봅시다.  
그리고 내일의 또 다른 나를 그려봅시다.

## 참고
- [표현적 글쓰기 서평](https://hannut91.github.io/blogs/books/expressive-writing)
- [표현적 글쓰기 \| 제임스 W. 페니베이커 , 존 F. 에반스 저자(글) · 이봉희 번역 \| 엑스북스](https://product.kyobobook.co.kr/detail/S000001893269)
- [통찰, 평범에서 비범으로 \| 게리 클라인 저자(글) · 김창준 번역](https://product.kyobobook.co.kr/detail/S000000733618)
- [오늘 나는 무엇을 배웠나? - 달랩](https://dal-lab.com/2019/09/18/today-i-learned/)
- [Three Fs](https://web.archive.org/web/20050502233833/http://no-smok.net/nsmk/ThreeFs)


"마음 살피기 시"를 쓰면서 하루를 되돌아 보는 방법에 대해서 알아봅니다.

TIL대신에 마음살피기

우리는 일을 할 때 다음과 같은 경우에 동기가 올라갑니다.

- Skill variety: 한 가지 일을 할 때 다양한 스킬을 써야 / 계발해야 할 수록 동기가 올라감
- Task Identity: 자신이 한 일과 그것의 최종적 결과물이 직접적 연관성이 있다고 느껴질수록(프로세스의 일부에만 관여하거나, 프러덕트의 일부에만 관여하지 않고 더 전반적으로) 동기가 올라감
- Task Significance: 자신이 하는 일이 다른 사람들의 삶에 영향을 많이 준다고 느낄수록 동기가 올라감
- Autonomy: 자신이 하는 일에서 자율적인 부분이 클수록 동기가 올라감
- Feedback: 자기 일의 결과에 대해 더 많이 알수록 동기가 올라감

지금 하고 있는 일이 재미가 없다면, 일의 정의를 다시 해야 합니다. 내가 하고 싶고 재미있는 일로 만들어야 합니다. 면담 사례를 통해서 어떻게 일의 정의를 다르게 할 수 있는지 살펴보겠습니다.

## 면담 사례

철수: 지금 하고 있는 일이 너무 재미가 없어요. 일하기가 너무 싫어요.

**윤석: 지금 어떤 일을 하고 계시나요?**

철수: API를 자동으로 테스트할 수 있는 통합 테스트를 작성하고 있어요.

**윤석: 왜 재미가 없다고 느껴지세요?**

철수: 제가 하고 싶었던 건 CI/CD를 도입하고 싶었습니다. 파이프라인을 구축하고 나서 파이프라인에 자동화된 테스트와 통합 테스트를 추가하고 싶었는데, 팀장님이 원하는 것은 아니었습니다. 팀장님은 통합 테스트를 일단 추가하는 것만 원하시고 계세요.

**윤석: 철수님이 하고 싶었던 것과 차이가 좀 있네요. 통합 테스트는 어떤 테스트인가요?**

철수: QA 하시는 분들이 API가 올바르게 동작하는지 수동으로 하고 있는데, 스크립트로 작성해서 자동으로 실행할 수도 있는 테스트에요"

**윤석: 그러면 QA 하는 분들은 유용하게 사용할 것 같은데, 그래도 별로 재미가 없으신가요?**

철수: 네. QA 하시던 분은 좋아하시긴 하는데, 원래 하고 싶었던 것과 전혀 달라서 별로 하고 싶지도 않고 재미도 없어요.

**윤석: 이게 개발이 되면 자동으로 테스트를 실행할 수 있어서 좋을 것 같네요. 테스트 하나를 작성하면 QA분들이 수동으로 하는 것을 대신해서 얼마나 시간을 아끼는 건가요?**

철수: 음... 그건 잘 모르겠어요. 기존에 수동으로 테스트 하는 데 얼마나 걸리는지

**윤석: 수동으로 하는 시간을 알고있고, 자동으로 테스트를 실행했을 때 걸리는 시간을 알면, 테스트 하나를 작성할 때마다 QA분의 시간을 얼마나 아낄 수 있는지 계산할 수 있겠네요?**

철수: 음.. 네 그렇죠

**윤석: QA 분의 월급... 을 모르겠지만? 월급을 대충 어느 정도 받는다고 가정해서 시급으로 계산하면, 한 통합 테스트를 만들 때마다 회사에 돈을 얼마를 아끼는지 계산할 수 있겠네요**

철수: 그렇겠네요

**윤석: 아마도 테스트는 반복적으로 실행할 테니, 아까 계산한 금액에 반복되는 수만큼 계산하면, 철수님이 통합 테스트를 작성할 때마다 한달에 아끼는 돈을 계산할 수 있겠네요.**

철수: 와 맞아요

**윤석: 그래서 통합 테스트를 작성하기 전후 를 비교해서 어떤 성과를 만들어냈는지 숫자로 표현도 가능하겠네요. 이렇게 하는 건 어떠세요?**

철수: 그러면 제가 하는 일이 돈과 관련되어 있고 결과를 바로 볼 수 있어서 좋겠네요. 재밌을 것 같아요. 한 번 그렇게 해볼게요!

내가 하는 일이 어떤 영향을 미치는지 알지 못하면 일이 재미없습니다. 왜 해야 하는지도 납득이 되지 않습니다. 우리가 한 일과 그것의 최종적 결과물이 연관성이 높다고 느껴질수록 동기가 올라갑니다. 사례에서는 철수가 통합 테스트를 작성하면 회사에 바로 이익이 되고 숫자로 눈으로 확인할 수 있게 됐습니다.

그리고 우리가 하는 일이 다른 사람들의 삶에 영향을 많이 준다고 느낄수록, 자신이 하는 일에서 자율적인 부분이 많을수록, 자기 일의 결과에 대해 더 많이 알수록, 한 가지 일을 할 때 다양한 스킬을 쓸수록 동기가 올라갑니다. 사례에서는 QA 엔지니어에게 좋은 영향을 미칠 수 있으니 동기 수준이 올라갑니다.

철수의 일을 다시 정의했습니다. 통합 테스트를 작성하는 일에서 QA 비용 줄이기로. 그냥 시켜서 하는 일에서 내가 하고 싶은 일로.


우리는 스스로 일의 정의를 선택할 수 있으며, 그 선택에 따라 결과가 달라집니다. 만약 일이 재미없고 퇴사하고 싶을 때 일의 정의를 다시 생각해 보면서 일의 재미를 만들어보는 것은 어떨까요? 일이 재밌어질 뿐만 아니라 더 멋진 커리어와 경험을 만들어볼 수 있습니다.

## 참고

- [AC2 의사결정과 동기부여 워크샵](https://www.ac2.kr/)


하기 싫은 일에 새로운 의미를 부여하여 하고 싶은 일로 만드는 방법을 사례로 알아봅니다.

재밌게 일하는 방법

일 재밌게 만드는 법

사놓고 펴보지도 못한 책이 산더미처럼 쌓여있으신 분들 많으실 겁니다 저 또한 그렇습니다. 우선순위에 밀린 책들, 좋다고는 하는데 너무 두꺼운 책들, 너무 어려워서 엄두도 안 나는 책들이 계속 쌓여만 갑니다.

의지를 불태워보려고 하지만 개인의 의지로는 쉽지 않습니다. 그렇다면 동료들과 같이 읽는 것은 어떨까요? 같이 읽으면 동기 부여도 되고, 서로 의지할 수 있어 힘도 나고, 책 내용에 대해 토론도 할 수  있어서 배울 것도 더 많아집니다.

## 같이 읽기

같이 읽기란 동료들과 같이 정해진 시간 동안 책을 읽는 것을 말합니다. 구체적인 방법으로는 다음과 같습니다.

1. 한 세션 동안 얼마나 읽을지 정합니다. 챕터로 나눌 수 있고, 적당히 최대 30분이 넘지 않는 범위에서 정합니다.
2. 읽는 데 얼마나 걸릴지 같이 추정합니다. 너무 정확하게 할 필요는 없습니다. 각자 읽는 시간도 조금씩 다를 수 있습니다. 그래도 어느 정도 걸릴 것 같은지 시간을 정합니다.
3. 정한 시간 동안 책을 읽습니다.  같이 공유할 수 있는 타이머가 있으면 좋습니다.
4. 만약 시간이 부족하다면, 시간을 추가합니다. 시간이 얼마나 더 필요할 것 같은지 이야기를 나누어서 시간을 추가하고 나머지를 읽습니다.
5. 다 읽었으면 읽은 부분에서 중요한 부분, 인상적이었던 부분, 좀 모호해서 궁금한 부분을 같이 이야기를 나눕니다. 이때도 시간이 너무 길어지지 않도록 시간을 제한하는 것이 좋습니다.
6. 이제 다시 처음으로 돌아가서 다음은 어디까지 읽을지 정하고 얼마나 걸릴지 추정합니다. 이전 세션에서 얻은 경험이 있기 때문에 이번에는 좀 더 정확하게 추정할 수 있을 것입니다. 

이렇게 같이 읽고, 시간을 정해두고 읽으면 짧은 시간 내에 엄청 집중해서 읽을 수 있습니다. 너무 어려워서, 혹은 너무 두꺼워서 미뤄뒀던 책도 함께 읽으면 할 수 있습니다.

계속 시간을 추정하면서 읽으면 얼마나 읽을 수 있는지 가늠할 수 있게 되고, 이게 점점 정확해지면 내가 얼마 만에 책을 다 읽을 수 있는지를 알게 됩니다. 즉 내가 앞으로 성장하기 위해서 어느 정도의 속도로 성장할 수 있을지 가늠해 볼 수 있습니다. 그리고 얼마나 성장할지 결정할 수도 있게 됩니다.

실제로 이것을 해보면 짧은 시간에 너무나 많이 읽을 수 있다는 것을 알게 됩니다. 너무 효율적이라서 이제 혼자서 책읽기가 불가능해질 수 있습니다.

![같이 읽기 디스코드](https://a.storyblok.com/f/92702/461x349/ad2837bcfb/.png)

코드숨에서 관심 있는 책에 대해서 같이 읽는 스터디도 진행 중이고, 오프라인에서 같이 읽는 스터디도 진행하고 있습니다.

여러분들도 동료들과 한 번 해보세요. 만약 이런 훌륭한 동료가 없다면 코드숨 커뮤니티에 오세요. 좋은 동료들이 기다리고 있습니다.

![같이 읽기 오프라인](https://a.storyblok.com/f/92702/3024x4032/61a34bf6a2/img_9042.jpg)

책을 더 많이, 더 잘 읽는 법: 같이 읽기를 이용한 개발자의 학습 전략

개발자 책 읽는 법 - 같이 읽기

read-together

![](https://a.storyblok.com/f/92702/1280x1050/dc763e1252/asch_experiment.png)

1951년 미국 스와츠모어 칼리지 캠피스에서 심리학자 솔로몬 애쉬가 한 실험을 진행했습니다. 실험에 참가한 8명 중 7명은 실험을 위해서 투입된 사람이었고 나머지 한 명은 이 사실을 모르고 있었습니다.

실험은 왼쪽 카드에 그려진 선분의 길이와 같은 선분을 오른쪽 카드에서 고르는 일이었습니다. 한 눈에 봐도 오른쪽 카드의 2번 째 선분과 같다는 것을 알 수 있었습니다. 그런데 7명의 동조자들이 일부러 오답을 선택하면 참가자들의 대부분이 오답을 따랐습니다. 다수의 의견에 동조하지 않고 자신의 판단을 고수한 참가자는 25%에 불과했습니다.

하지만 실험을 변형하여 동조자 중 한 명이 정답을 선택하도록 하였을 때 참가자의 정답 선택률은 100%로 증가했습니다. 이는 다수의 의견과 다르더라도 '자기편'이 있다는 것이 소신을 지킬 수 있는 힘을 준다는 것을 보여줍니다. 이는 우리가 소신을 지키지 못하는 이유가 주변에 '한 사람'의 지지가 없기 때문일 수 있음을 보여줍니다.

심지어 한 사람이 정답을 선택하지 않고 오답을 선택하더라도 결과가 동일하게 나왔습니다. 다수와도 의견이 다르다는 의미에서 보자면 같은 편인 새로운 의미의 동지를 만들어준 것이죠.

우리는 아군이 필요합니다. 나의 의견을 들어주고 같이 동조해 주는 아군이 단 한 명만 있더라도 우리는 행동할 수 있게 됩니다. 이 작은 행동으로 자신과 조직을 바꿀 수 있는 첫걸음을 만들 수 있습니다.

만약 팀에 코드 리뷰하는 문화를 도입하고 싶다면 먼저 코드 리뷰를 해보세요. 부정적인 반응을 하는 사람도 있고 긍정적으로 반응하는 사람이 있습니다. 부정적인 반응을 하는 사람은 필요 없습니다. 나에게 긍정적인 반응을 하는 사람에게 다가가 코드 리뷰를 하는 문화를 도입해 보자고 제안하고 같이 만들어 보세요.

만약 팀 내에서 스터디를 같이 하고 싶다면 스터디를 해보자고 제안해 보세요. 마찬가지로 그런 걸 왜 하냐는 반응과 해보면 좋을 것 같다는 반응하는 사람이 있습니다. 긍정적인 반응을 하는 사람과 스터디를 만들어 보세요. 그리고 이게 잘되면 또 다른 사람들을 꼬셔서 좋은 문화를 전파해 보세요.

꼭 모든 사람을 설득할 필요는 없습니다. 우리에게는 단 한 사람의 아군만 있으면 됩니다. 또한, 우리 각자도 다른 사람의 '아군'이 될 수 있다는 점을 기억해야 합니다. 이런 방식으로 우리는 서로를 지원하며, 더 큰 변화를 이끌어낼 수 있습니다.

## 출처

- [프레임 \| 최인철 저자(글) \| 21세기북스](https://product.kyobobook.co.kr/detail/S000000711324)
- [Asch conformity experiments](https://en.wikipedia.org/wiki/Asch_conformity_experiments)


팀 내에 좋은 개발 문화를 만들기 위해서 사용할 수 있는 아군 만들기 패턴에 대해 알아봅니다

코드 리뷰 문화를 만드는 방법 - 아군 만들기

팀 내에 코드 리뷰를 도입하는 방법 - 아군 만들기

코드숨에서 고통 주도 개발이라는 말을 사용했습니다. 이 말의 진짜 의미는 인출을 시도했을 때 내가 모른다는 사실에 직면하게 되면서 고통을 받게 되고, 이 고통을 이겨내야 성장이 있다는 의미였습니다.

그런데 이 고통이라는 말이 많은 오해를 일으킵니다. 마치 공부하는 내용이 어려워서 겪는 고통을 의미한다든지, 공부는 원래 힘든 거야 같은 오해를 만듭니다.

무조건 고통스러워야 성장이 일어나는 것은 아닙니다. 오히려 방해가 될 수 있습니다. 예를 들어서 우리가 어떤 알고리즘을 구현할 수 없다거나, 주어진 요구사항을 구현할 수 없다는 사실에 직면했을 때 우리는 이 사실을 해석하는 과정을 거치게 됩니다. 이 사실을 해석하면서 평가와 비난의 소리를 퍼붓게 됩니다.

> "이런 단순한 기능도 구현하지 못하다니, 나는 역시 한심해"

이러한 부정적인 평가는 우리를 좌절하게 만듭니다. 사람은 부정적인 것에 더 집중하게 되어 있습니다. 이러한 인식은 성장보다는 오히려 자기 방해를 만들어내게 됩니다.

따라서 변화를 위해서는 현상 그대로 비평가적으로 인지해야 합니다. 비평가적으로 인지한다는 것은 일어난 사실에 대해서 판단하지 않는 것입니다. 잘한다, 못한다, 싫다, 좋다 등 판단하는 것을 멈추고 객관적인 사실만 기술하는 것입니다.

> "이런 기능은 내가 구현을 못하는구나"

이렇게 있는 그대로 사실만을 바라보면 그다음은 알아서 따라오게 돼있습니다. 역설적이지만 자신과 자신의 행동을 있는 그대로 느끼고 받아들이려는 노력이 변화의 시작이며 변화를 촉진하는 가장 효과적인 방법입니다.

자신에 대한 평가는 이제 멈추고, 있는 그대로 자신을 받아들여야 합니다.

## 참고

- [테니스 이너 게임 \| 티머시 갤웨이 저자(글) · 김기범 번역 \| 소우주](https://product.kyobobook.co.kr/detail/S000061898264)
- [이너 게임 \| 티머시 갤웨이 저자(글) · 최명돈 번역 \| 가을여행](https://product.kyobobook.co.kr/detail/S000001975255)



학습에서의 고통을 넘어: 비평가적 자기 인식으로 성장하기

고통 주도 개발에서 비평가적 인지로

책을 읽다가도 길을 잃을 때가 있습니다. 길을 잃으면 글자를 눈으로 보는 상태가 됩니다. 내용이 머릿속에 들어오지 않습니다.

집중력을 잃어서 그렇습니다. 집중력이 흐트러지면 주의가 산만해지고 딴짓을 하게 됩니다.

3색 볼펜 읽기법으로 밑줄을 그으면서 읽으면 끝까지 길을 잃지 않고 집중할 수 있습니다. 그리고 여러 가지 관점으로 보려고 노력하기 때문에 생각하면서 읽게 되고 책의 흐름도 파악하면서 읽을 수 있습니다.

## 3색 볼펜법

![삼색 볼펜법 예제 사진](https://a.storyblok.com/f/92702/3024x4032/3e4c300659/img_6703.jpg)

3색 볼펜 읽기 법은 3가지 색으로 밑줄을 그으면서 책을 읽는 방법입니다. 아주 중요해서 다른 사람도 이 내용만큼은 놓치면 안 되는 곳에는 빨간 줄을 긋습니다. 그 다음으로 중요하다고 생각하는 곳은 파란 줄을 긋습니다. 개인적으로 마음에 든다거나 중요하다고 생각하는 부분은 초록 줄을 긋습니다.

간단하게 보일 수 있지만, 실제로 해보면 엄청난 차이가 발생하게 됩니다. 볼펜을 딸깍 바꿀 때마다 머릿속에 있는 관점 스위치가 바뀌면서 객관적인 관점과 주관적인 관점을 바꿔가면서 책을 읽게 됩니다. 다른 사람들이 봐도 중요한지 객관적으로 판단하면서 읽게 되므로, 내용을 평가하면서 읽게 됩니다. 나중에 다시 책을 보더라도 중요한 부분만 볼 수 있으니 시간을 절약할 수 있습니다.

3색볼펜 읽기공부법에서 소개된 것은 아니지만, 개인적으로는 빨간색 파란색 줄이 그어진 문장만 읽더라도 내용이 자연스럽게 이어지는지 생각하면서 줄을 그어가며 책을 읽습니다. 수강생들에게 설명해 줘야 할 일이 많다 보니 그러는 건데요. 책을 읽으면서도 전체적인 흐름을 계속해서 파악하면서 읽게 되고 기억에도 잘 남는 것 같습니다.

다음은 제가 3색 볼펜 읽기 법으로 줄을 그으면서 읽어본 글입니다. 글 출처에 남겨 놓았으니, 나라면 어떻게 줄을 그으면서 읽을 건지 한 번 시도해 보시고 비교해 보시기를 바랍니다.

![3색 볼펜 읽기법 예제](https://a.storyblok.com/f/92702/712x1084/89faf0b003/example.png)

## 참고

 - [3색볼펜 읽기공부법 \| 사이토 다카시 저자(글) · 류두진 번역 \| 중앙북스 ](https://product.kyobobook.co.kr/detail/S000000526689)
 - [바쁜 직장인을 위한 스터디 비결](http://egloos.zum.com/agile/v/3684946)
 - [매일 한 시간씩 논문 쓰기](https://ppss.kr/archives/94681)
 

집중력을 잃지 않고 효과적으로 책을 읽는 3색 볼펜 읽기 법에 대해 알아봅니다.

개발자 책 읽는 법 - 3색 볼펜 읽기 법

책을 읽었지만 남는 게 없다고 느끼시는 분들을 위해 저만의 책 읽기 방법을 공유합니다.

책을 읽을 때는 능동적으로, 인출을 하면서 책을 읽어야 합니다. 그래야 기억에 오래 남습니다.

질문 만들기는 핵심 내용을 파악하고 내가 제대로 이해했는지 확인하면서 읽을 수 있도록 도와주고 목표를 잃지 않도록 도움을 줍니다. 

## 질문 만들기

![질문 만들기 예제](https://a.storyblok.com/f/92702/3024x2506/0098a34ddb/.jpg)

질문 만들기는 핵심 내용을 질문으로 바꿔보는 것입니다.

예를 들어서 아래와 같은 문장이 있다고 가정해 보겠습니다.

> 문제 발생 사실을 전달해야 하는 방향은 함수 호출의 역방향이다. 문제에 따라서는 더 큰 맥락을 알아야 문제를 해결하거나 대안을 제시할 수 있는데, 호출 사슬의 아래쪽보다 위쪽에 있는 함수들이 더 큰 맥락을 알고 있기 때문이다. - 핵심 코틀린 프로그래밍 - 5장 예외

위의 문장을 질문으로 바꿔보면 `왜 문제 사실을 전달해야 하는 방향은 함수 호출의 역방향인가?`라고 할 수 있습니다. 이 문장을 페이지 위에 적어놓고 머릿속으로 스스로 답변을 해보면, 내가 이 내용을 이해했는지 피드백을 받을 수 있습니다. 책을 읽는 동시에 인출을 시도하는 것입니다.

또 다른 예제를 한 번 살펴보겠습니다.

> 데이터가 커지면 그 속도 차에 기인하는 문제가 복잡해지기 쉽다. 강의 6에서는 먼저 이런 사항들이 시스템 전체의 확장성 전략에 어떤 영향을 줄지에 대해 살펴보도록 하자 - 대규모 서비스를 지탱하는 기술 - 강의 6 규모 조정의 요소

저자가 노골적으로 앞으로 어떤 이야기를 할지 의도를 드러내고 있습니다. 이런 경우는 쉽습니다. 알아보자고 한 내용을 그대로 질문으로 적으면 됩니다. 위의 문장을 질문으로 바꿔보면 `데이터가 커질 때 시스템 전체의 확장성 전략에 어떤 영향을 주는가?`라고 할 수 있습니다.

질문을 만들었으니 이 질문에 대한 대답을 할 수 있도록 찾으면서 책을 읽으면 됩니다.

큰 챕터를 하나 읽었다면 다음으로 해야 할 것은 `한 챕터를 관통하는 질문 하나`를 만드는 것입니다. 단 하나의 질문을 만들려고 생각해 보면 한 챕터를 모두 아우르는 질문을 만들어야 하고 이는 챕터에 대해서 완벽하게 이해하지 않는 한 만들기가 어렵습니다. 핵심 주제에 대해서 생각해 볼 수 있고 그 질문에 답해보면서 내가 제대로 이해했는지 확인할 수 있습니다.

예를 들어서 메모리와 디스크의 핵심 챕터를 읽은 후 `컴퓨터는 어떻게 정보를 기억하는가?`와 같은 질문을 만들어볼 수 있겠습니다.

이렇게 질문으로 만들고, 이 질문에 답하면서 책을 읽으면 책을 능동적으로 읽을 수 있고, 목표를 확실히 하고 책을 읽어나갈 수 있습니다. 그리고 내가 제대로 이해했는지 돌아볼 수도 있고, 읽은 내용을 인출하면서 책을 읽어서 훨씬 더 오래 장기기억으로 남길 수 있습니다.

## 참고

- [어떻게 공부할 것인가 \| 헨리 뢰디거, 마크 맥대니얼, 피터 브라운 저자(글) · 김아영 번역 \| 와이즈베리](https://product.kyobobook.co.kr/detail/S000000625448)


기억에 오래 남도록 효과적이고 능동적으로 책 읽는 방법에 대해 알아봅니다.

개발자 책 읽는 법 - 질문 만들기

개발자 책 읽는법

코드숨 리액트 8기 수강생 이재윤님이 과제를 진행하는데 어려움을 겪어 디스코드
DM으로 질문을 했습니다. 단순히 해답을 전달하면 그 과정을 학습할 수 없으므로
해법을 알려드리기 위해서 질문을 하고 답변 했던 내용입니다.  

위 내용을 다시 돌아보면서 어떻게 문제를 효과적으로 해결할 수 있는지를 살펴봅니다.

## 문제 상황

레스토랑 상세 페이지에 `<Link />`를 통해서는 접근이 가능하지만, 새로고침을
하거나 URL을 직접 입력하여 페이지에 접근할 때는 페이지에 아무것도 뜨지 않고 있습니다.

![](https://user-images.githubusercontent.com/14071105/174757836-fa4ef01f-e154-420c-bd3b-7c2bd9fba9c9.png)

## 접근

에러 상황만 봐서는 문제를 확인할 수 없어 실제로 실행해 보아야 했습니다.
실행해보니 다음과 같이 `404 Not found`가 응답하는 것을 확인할 수 있었습니다.

![](https://user-images.githubusercontent.com/14071105/174758073-c6a78b5b-a9bc-4e73-844c-107db875d7c5.png)

### 일어난 현상 자체를 바라보기

![](https://user-images.githubusercontent.com/14071105/174758592-ecbf6147-900e-431c-9e2b-b9f80c9f6976.png)

이 때 이재윤님은 자신이 작성했던 코드에 문제가 있어서 안되는 것이라고 추측하고
있습니다. 그러다보니 이전에 했던 일을 돌아보며 문제의 원인을 찾고 있습니다.  

우리가 어떤 에러나 문제를 만났을 때, 내가 무엇을 잘못했길래 안되는거야?라고
생각할 수 있는데요. 그러다보면 발생한 문제보다는 자신의 한 일에 대해서 더 집중하게
됩니다. 그래서 문제의 근본적인 원인보다는 지금까지 했던 행위들을 돌아보면서
문제의 원인을 찾게됩니다.

우리는 문제에 더 집중해야 합니다. 현재 발생한 문제를 직시하고 일어난 현상
자체에서 분석하여 문제를 해결해야 합니다. 그래서 일단 일어난 현상 자체를
분석해야 한다고 말씀드렸습닌다.

### 아는 것과 모르는 것을 구분하기 (자료수집)

![](https://user-images.githubusercontent.com/14071105/174775724-27a7aac5-fb65-4dff-9c26-b0f9253ec83f.png)

그래서 일단 저 요청에 대해서 재윤님이 알고있는지 것이 무엇인지 찾아보았습니다.
지금 하고 있는 요청이 무엇인지, URL의 앞 부분과 뒷 부분으로 나누어 봤고, 진짜로
의미하는 바가 무엇인지 찾아보려고 했습니다.

![](https://user-images.githubusercontent.com/14071105/174775920-f3ab4d89-de7c-4c2b-99ae-81358372fe6c.png)

`/restaurants`가 현재 우리가 있는 위치라는 사실과 webpack으로 빌드했을 때
`main.js`가 나온다는 사실을 찾아냈고, 다시 `main.js`를 가지고 자료를 찾아보았습니다.

![](https://user-images.githubusercontent.com/14071105/174777964-b6c9a7c3-b4a9-4057-9ad5-14eca7825f58.png)

실제로 우리 코드에 있는 `main.js`를 찾았고 여기서는 `main.js`를 상대
경로로 불러오고 있어서 아까 수집했던 `/restaurants`가 현재 위치를 나타낸다는 사실과 `main.js`를 
상대 경로로 불러오고 있다는 사실을 조합하여 문제의 원인을 찾았습니다.

## 해결

![](https://user-images.githubusercontent.com/14071105/174778106-bb7cdabf-7c00-4cdc-8062-4ec4ae670246.png)

위의 문제 해결 과정에서 근본적인 원인을 정의 했고 해결할 수 있는 여러가지 방법을 제시했습니다.

## 결론

문제 상황을 만나면 일단 아는 것과 모르는 것으로 구분해 내야 합니다. 그 다음 아는
것만으로 문제를 해결할 수 있는지 계획을 세워야 합니다. 만약 아는 것만으로 해결할
수 없다면 자료 조사를 통해서 문제를 해결하는데 필요한 자료들을 수집해야 합니다.
수집한 자료들로 다시 계획을 세워보고, 안되면 다시 자료조사를 하고 실행해야
합니다. 만약 실행이 잘 되지 않는다면 계획, 그리고 자료조사를 반복해서 실행해야
합니다.

## 참고

* [이재윤님의 회고](https://jaeyooniverse.tistory.com/92)


문제에 해결할 때 아는 것과 모르는 것을 구분하여 효과적으로 해결하는 방법을 공유합니다

사례로 알아보는 문제를 효과적으로 해결하는 방법

코드숨에서 모던 자바스크립트 튜토리얼 읽기, 자바스크립트 코딩의 기술 책 읽기, 리액트 문서 읽기 스터디를 진행했습니다. 코드숨 교육에서도 적용 중인 아웃풋 중심의 학습법을 스터디에도 적용하기 위해서 했던 시도들을 공유합니다.

## 문제집 만들기패턴을 적용하다

### 문제집 만들기 패턴이란?

문제집 만들기 패턴이란 기록할 내용을 문제로 바꿔서 적고 나중에 답하는 학습 패턴을 말합니다. 예를 들어서 자바스크립트에서 `var`는 `lexical scope`를 따르는 반면 `let`은 `block scope`를 따른다는 문장을 봤을 때 이 문장을 질문으로 만들면 `var`와 `let`은 각각 어떤 scope를 따르는가?로 바꿀 수 있습니다.

### 문제집 만들기 패턴의 장점

* 피드백을 얻을 수 있습니다.
  내가 만든 질문에 답해보면서 내가 정말로 다 이해했는지, 아니면 아직 부족한 것이 있는지 피드백을 얻을 수 있습니다. 공부를 어디까지 해야 되나?라는 고민이 있는데 이 질문에 답할 수 있을 때 까지로 정할 수 있습니다.
* 저자의 의도를 파악하는 데 도움이 됩니다.
  질문으로 만드는 과정 자체가 저자의 의도를 파악하는 과정이기 때문에 핵심 개념에 대해 더 집중할 수 있습니다.
* 더 깊이 있는 사고를 하게 해줍니다.
  학습내용의 가장 중요한 개념들을 질문 형태로 만들어보면 단순히 내용을 요약해서 질문으로 바꾸는 것이 아니라 함축적인 작업이기 때문에 더 깊이 있는 사고를 하게 해줍니다.

### 질문을 만들어오고 서로 답변하기

문제집 패턴을 스터디에 적용해서, 각자 읽으면서 질문을 만들어 구글 폼에 기록하게 했습니다. 그리고 그 문제들로 스터디 시간에 다른 사람들에게 질문을 하고 그 답변에 대해 얘기하는 식으로 스터디를 진행했습니다.

![image](https://user-images.githubusercontent.com/14071105/99968401-6ece4900-2ddc-11eb-87cd-573688ae1747.png)

단순히 자신이 읽은 부분을 다른 사람에게 들려주는 스터디 방식은 그저 인풋 중심의 학습법이라서 집중하기도 어렵고 특히 온라인 스터디라서 더 집중력이 필요한 데 한계가 있습니다. 질문에 대한 답을 하다 보면 자연스럽게 배웠던 것을 회상하게 되고 다른 사람의 답변에 대해 생각해보면서 스터디에 더 능동적으로 참여할 수 있게 됩니다. 그래서 시간이 굉장히 빠르게 간 느낌이 들었고 온라인 스터디였지만 전혀 지루하지 않았습니다.

### 만족도와 성취도는 다르다

스터디 회고 때 얘기를 해본 결과 대다수가 그냥 리뷰를 하는 스터디가 더 좋다고 답변했습니다. 질문에 대해서 사람들이 답변을 아주 잘해서 학습의 성취도가 아주 좋다고 생각했습니다. 그래서 만족도도 높을 것이라고 생각했지만 학습의 만족도는 전혀 달랐습니다. 학습의 만족도와 학습의 성취도는 반드시 비례하는 것이 아닐 수 있다는 것을 배웠습니다. 그래서 결국 자바스크립트 코딩의 기술 스터디는 단순 리뷰로 스터디 방식을 다시 바꾸었습니다.  
문제집을 만들면서 읽는 것이 학습에 어떻게 도움이 되는지, 어떻게 질문을 만드는 게 좋은지에 대해 충분히 설명하지 않았습니다. 그래서 질문을 만들어오는 게 어렵다고 느낀 사람도 있었습니다. 그래서 다음에는 충분히 설명을 하고 진행하기로 했습니다.

## 정교화패턴을 적용하다

정교화는 생소한 내용을 자신만의 언어로 표현하여 기존의 지식과 연결하는 과정입니다. 단순히 정리를 하는 것이 아닌 우리가 배워야 할 것들의 핵심 질문을 던지고 토론을 하면서 스터디를 진행해보았습니다.

* 무엇인가?
* 왜 사용하는가?
* 어떻게 사용하는가?

이 세 가지 질문에 답할 수 있다면 어떤 개념에 대해서 우리가 잘 알고 있다고 판단할 수 있습니다. 이러한 질문들을 사람들에게 던지고 답변을 받고 그 답변에 대해서 다시 얘기하고, 답변들을 모아 정리를 하며 스터디를 진행했습니다. 예를 들어서 리액트의 `useState`를 배웠다면 다음과 같은 질문에 답할 수 있어야 합니다.

* `useState`란 무엇인가?
* `useState`를 왜 사용하는가?
* `useState`는 어떻게 사용하는가?

### 자연스럽게 토론이 진행된다

질문에 대한 답을 하면서 답변에 대해서 다시 다른 사람들에게 물어봅니다. 더 부족한 것은 없는지, 덧붙이고 싶은 건 없는지, 틀렸다면 왜 틀린 지 맞았다면 왜 맞는지에 대해서 질문을 던집니다. 계속해서 우리가 정말 정확하게 그 개념을 알게 될 때까지 반복합니다. 그러면 자연스럽게 토론이 진행됩니다.  
우리가 무언가에 대해서 정확히 말하는 것도 중요하지만, 특정한 설명이 정말로 맞는지, 틀린지 구별할 수 있어야 합니다. 그래서 계속해서 질문과 답변을 하며 토론을 하여 중요한 개념들을 정리하며 계속적으로 인출을 하여 학습하게 됩니다.

## 앞으로 다양한 아웃풋 중심의 학습 패턴을 적용해봐야겠다.

개념들을 정리를 해서 좋은데 그래서 이걸 어디에 써먹지? 같은 고민들에 빠집니다. 그래서 아주 간단한 예제라도 예제를 만들어봐야 합니다. 예를 들어서 쿠버네티스 오토 스케일링에 배웠다면 실제로 오토 스케일링을 할 수 있어야 합니다.  
스터디에서 정리한 것을 예제로 만들어오는 숙제를 만들거나 라이브 코딩을 하여 시도를 해야겠습니다.

## See also

* 윤석님의 리액트 스터디 회고 - [https://hannut91.github.io/retrospective/react-study](https://hannut91.github.io/retrospective/react-study)
* 윤석님의 모던 자바스크립트 스터디 회고 - [https://hannut91.github.io/blogs/modern-javascript](https://hannut91.github.io/blogs/modern-javascript)
* 김난님의 회고 - [https://github.com/naraekn/TIL/blob/master/20.10/201021.md](https://github.com/naraekn/TIL/blob/master/20.10/201021.md)
* 울트라 러닝 - [http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9791162541289](http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9791162541289)
* 어떻게 공부할 것인가 - 교보문고 - [http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9788937834868](http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9788937834868)

코드숨 교육에서도 적용 중인 아웃풋 중심의 학습법을 스터디에도 적용하기 위해서 했던 시도들을 공유합니다.

스터디에 아웃풋 중심의 학습법을 적용하기

코드 리뷰란 다른 사람이 작성한 코드를 보고, 코드를 개선하기 위해 서로 논의하는 것을 말합니다. 간단한 오타수정부터 기능, 올바른 이름짓기, 디자인 등등 코드를 개선하기 위한 많은 일들을 할 수 있습니다. 그래서 많은 개발 조직에서 코드의 품질을 유지하기 위해 코드 리뷰를 적극 활용하고 있습니다. 하지만 코드 리뷰는 단순히 코드를 개선하는 일 뿐만 아니라 개발자들이 많은 지식들을 배울 수 있는 좋은 기회입니다. 코드 리뷰를 이용해서 무엇을 더 배울 수 있을까요?

## 더 좋은 코드를 만들 수 있을까?

다른 사람의 코드를 읽으면서 코드의 의도를 파악하고 더 개선할 수 있는 부분은 없는지 찾습니다. 만약 내가 모르는 것을 발견했다면 문서나 책을 통해서 찾아봅니다. 새롭게 공부하며 지식을 습득하게 되고 그 지식에 대한 아주 휼륭한 예제코드도 같이 알게됩니다. 이해하는게 어렵다면 작성자에게 질문할 수 있으니 아주 휼륭한 선생님도 같이 얻게 된 셈입니다.
나라면 이 문제를 어떻게 해결할까? 더 좋은 방법으로 해결할 수 있을까? 혹은 더 효율적으로 이 문제를 해결할 수 있을까? 고민합니다. 만약 개선할 부분을 찾았다면 작성자에게 제안을 해야 합니다. 근데 제안을 할 때 이유도 같이 첨부해야겠죠?

![](https://user-images.githubusercontent.com/14071105/95009702-117d0d80-065f-11eb-9ad3-4dc493f8dbf6.png)

작성자는 처음 알게되는 개념일 수 있기 때문에 아주 자세하게 설명해야 합니다. 하지만 내가 다른 사람에게 설명할 수 있을정도로 알고 있지 않다면 설명하기가 어렵습니다. 그래서 문서나 책을 통해 자세히 공부한 다음에 정리를 해서 설명해야 합니다. 이 과정에서 공부를 할 수 밖에 없게됩니다.

## 먼저 코드 리뷰 하기

이런! 제가 생각했던게 틀렸습니다.

![](https://user-images.githubusercontent.com/14071105/95010312-2491dc80-0663-11eb-9400-c31eb9f04219.png)

코드 리뷰의 가장 좋은 점중 하나는 먼저 코드 리뷰를 하면 나도 코드 리뷰를 받을 수 있다는 사실입니다. 더 좋은 방법이라고 생각했지만, 작성자가 코드를 작성하여 코드에 대해서는 더 많이 알고 있기 때문에 더 좋은 방법이 있을 수 있습니다. 코드 리뷰를 보고 정말 좋은 제안이라고 받아들인다면 내가 잘 작성했다는 것을 확인할 수 있습니다. 만약 작성자가 생각했을 때 코드 리뷰가 별로라고 생각한다면 왜 별로라고 생각하는지 답변이 올 것입니다. 그러면 내가 제안한 코드 리뷰에 대해서 다시 코드 리뷰를 받을 수 있게됩니다!

## 셀프 코드 리뷰

내가 작성한 코드를 다른 사람이 보기 전에 나 스스로 코드 리뷰를 하게 되면 또 새로운 사실들을 많이 발견할 수 있습니다. 다른 사람이 코드를 볼 때 관점으로 바라보는 연습을 하면 나는 당연하게 이해될거라고 생각했던 것들을 다른 사람들이 봤을 때는 이해하기 어려운 코드들을 발견할 수 있습니다. 그러면 더 의도를 드러내도록 수정할 수 있고 혹은 더 생각이 나지 않는다면 다른 사람들에게 “더 좋은 방법이 있을까요?“라고 조언을 구할수도 있습니다. 만약 코드로 설명할 수 없는 부분은 코멘트로 부가설명을 더할 수 있습니다.

## 같이 성장하기

코드숨에서는 코드 리뷰를 통해 수강생들의 학습을 도와드리기도 하지만 사실은 가장 많이 배우는 사람들은 리뷰어입니다. 더 많이 알려드리기 위해 더 많이 공부하고 있고, 리뷰를 하면서 같이 성장하고 있습니다.

## 참고

* Code Review Developer Guide - https://google.github.io/eng-practices/review/
* 피드포워드 - 교보문고 - http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9791187856795
* 피드포워드 서평 - 윤석 블로그 - https://hannut91.github.io/blogs/books/feed-forward

코드리뷰로 코드를 개선하고 학습하는 방법에 대하여 연구해봤습니다.

코드 리뷰로 학습하기

애자일하게 일해야 하는 게 옳다는 것은 이미 널리 퍼진 사실 같습니다. 기존의 폭포식으로 일하는 방식을 보면 굉장히 잘못됐다고 말합니다. 그런데 학습에 대해서는 사람들은 여전히 폭포식이 더 익숙한 것 같습니다. 학습도 애자일하게 학습을 할 수 있다면 어떨까요? 빠르게 피드백을 얻어 학습의 방향을 재설정하는 거죠. 회고라는 도구를 사용하면 아주 쉽게 적용할 수 있습니다.

## 회고

회고란 지나온 것을 돌아보며 좋았던 점은 어떻게 유지할지, 아쉬웠던 점은 어떻게 개선할지 고민하는 활동을 말합니다. 예를 들면 면접이 끝난 후 내가 어떻게 대답했는지를 다시 회상해보는 겁니다. 그러면 당시에는 생각나지 않았던 내용들도 생각이 날 수도 있고, 내가 조금 안 좋은 말투로 답변을 했을 수도 있고 또는 좀 더 잘 말할 수 있었는데 그러지 못한 것에 대한 아쉬움이 생각날 수 있습니다. 그러면 다음 면접에서는 내가 답변 못했던 지식들을 더 공부해서 갈 수 있고, 말투나 태도에 대해서 어떻게 교정해야 할지 결정할 수 있습니다.
회고는 단순히 지나온 것들 돌아보고 후회하는 일이 아닙니다. 그래서 나는 어떤 행동을 취할 것인가를 결정하는 행위입니다. 예를 들면 하루종 일 업무 전화 때문에 일에 집중을 못했다는 사실을 알게 됐습니다. 업무 전화 때문에 일에 집중할 수 없어!라고 불평을 하는 것이 아니라 일에 집중하려면 어떻게 해야 할까?라고 고민해야 합니다. 그래서 업무 전화를 올 때마다 처리하는 것이 아닌 업무 전화들을 모아놨다가 한 번에 처리하고 그 나머지 시간은 일에 집중하기로 합니다. 이렇게 해보니 업무처리가 좋아졌다면 앞으로도 이런 방법을 유지할 것입니다. 만약 이렇게 행동했는데 해결되지 않았다면 다시 다른 행동을 취할지 고민하고 결정해야 합니다.

## 회고 시작하기

회고 프레임워크를 사용하면 누구나 쉽고 빠르게 회고를 시작할 수 있습니다.

1. Facts (사실, 객관)
   실제로 내가 했던 일이나 겪었던 일의 사실을 적습니다.
2. Feelings (느낌, 주관)
   내가 했던 일을 하면서 느꼈던 감정이나 느낌을 적습니다.
3. Findings (배운 점)
   내가 했던 일을 통해서 새롭게 배운 점이나 알게 된 점을 적습니다.
4. Affirmation (자기 선언)
   내가 했던 일을 통해 배운 점과 아쉬운 점을 어떻게 유지하고 개선할 것인지 적습니다.

예를 들면 다음과 같이 할 수 있습니다.

1. Facts: 처음으로 스터디라는 것을 진행했다. 모던 자바스크립트 튜토리얼 정주행 스터디를 모집하고 진행했다. 진행 방식은 챕터마다 각자 질문을 준비해오고 랜덤으로 질문하고 답변하면서 토론을 진행했다. 내가 발견했던 버그에 대한 내용이 있어서 공유했다.
2. Feelings: 처음 스터디를 진행해봐서 그런지 긴장을 많이 했다. 지루하지 않고 재밌었다.
3. Findings: 사람들이 실무에서 작성한 코드들에 대해서 더 관심이 많은 걸 알게 됐다. 기술들이 실제로 쓰임새가 어디인지 궁금한 사람들이 많다는 것을 알게 됐다.
4. Affirmation: 앞으로 실무에서 만나는 다양한 예제들을 기록해놓고 공유해야겠다.

## No 회고 No 머지

코드숨 교육에서는 한 주의 과제가 끝난 후 반드시 회고를 작성해야 합니다. 그렇지 않으면 작성한 코드는 머지되지 않고 그러면 수료할 수 없습니다. 수강생들은 교육과 코드리뷰를 통해서 배우지만 회고를 통해서 한 번 더 배우고 다음 과제에서는 내가 어떻게 행동할지를 결정할 수 있습니다.

![image](https://user-images.githubusercontent.com/14071105/93716940-7f303080-fbad-11ea-9712-c1ca9fc501f6.png)

위의 회고는 6주차 용민님이 과제를 완료한 후 작성한 회고입니다. 나중에 안 사실이지만 회고를 잘 작성한 사람일수록 과제와 개인 프로젝트를 성공적으로 완성시킨 비율이 월등히 높았습니다.

## 참고

* 탤런드 코드 - 교보문고 - http://www.kyobobook.co.kr/product/detailViewKor.laf?barcode=9788901096414
* 오늘 나는 무엇을 배웠나? - 달랩 - https://dal-lab.com/2019/09/18/today-i-learned/

코드숨 교육 과정에서 회고를 통한 학습에 대해 정리해봤습니다.

회고를 교육과정에 포함시키다

## 예제 주도 학습법

학습을 하면서 항상 하는 고민 세 가지가 있습니다.

### 1. 내가 당장 뭘 공부해야 하지? 😅

불안한 마음에 무언가를 공부하려고 하지만 무엇을 할지 모르겠고 결정하기도 어렵습니다. 점점 책들은 쌓여가고 불안한 마음만 커져갑니다.

### 2. 내가 잘하고 있는 게 맞나? 🤔

공부를 시작했습니다. 근데 내가 지금 잘 공부하고 있는 건지 확신이 들지 않습니다. 다른 사람들은 어떻게 공부하고 있는지 궁금해지고, 잘하고 있는지 걱정이 되어 집중하지 못하고 꾸준히 공부가 안됩니다.

### 3. 아니 그래서 이걸 어디다 써먹지? 😇

공부를 하긴 하는데 어디에 써먹을지 모르니 머리에 잘 들어오지도 않고, 어려운 주제를 만나면 나는 아직 쓸 일이 없을 거야 하며 넘겨서 제대로 학습이 안됩니다.

## 피드백

세 가지 고민 모두 공부를 하면서 `피드백`을 얻을 수 없어서 생기는 문제입니다.
내가 필요한 지식은 무언가의 피드백을 통해서 어떤 지식이 필요하기 때문에 공부를 해야 합니다.
예를 들어 내가 만들고 싶은 프로그램을 만드는데 필요한 지식을 공부할 수 있습니다.

배운 지식을 직접 사용하지 않으면 나에게 어떤 변화가 일어났는지 피드백을 얻을 수 없습니다.
예를 들어 배운 지식을 가지고 사이드 프로젝트를 진행하면서 해당 지식을 사용할 수 있는 사람이 될 수 있습니다.

배운 것을 직접 적용해보며 내가 모르고 있는 것과 아는 것이 무엇인지 피드백을 얻어야 합니다.
예를 들어 사이드 프로젝트를 만들면서 막히는 부분을 발견하고 문서를 찾아보고 책도 보면서 학습을 합니다.

## 예제를 만들자 😎

사이드 프로젝트를 하는 일은 쉬운 일이 아니기 때문에 제가 제안하는 것은 `예제`를 만드는 것입니다. 배운 지식에 대해서 누군가가 쉽게 이해할 수 있게 예제를 만들어 보는 겁니다. 예를 들면 관계형 데이터 베이스를 공부하고 있다고 생각해 봅시다. 이 관계형 데이터 베이스를 배운다면 저는 관계형 모델로 문제를 설계할 수 있어야 합니다.
지금 책을 읽고 있으니 책 정보를 보관하는 저장하는 애플리케이션을 관계형 모델로 설계를 해봅니다.

![image1](https://user-images.githubusercontent.com/14071105/92922561-032d3e80-f471-11ea-821d-1e5ce9a2ee8c.png)

간단하게 책의 제목과 저자, 회사의 이름을 기록했습니다. 이런! 그런데 책을 기록하다 보니 저자가 여러 명인 책을 발견했습니다! 어떻게 해야 하지? 고민이 됩니다. writer 칼럼에 문자열 `,`로 구분할까? 하지만 이는 좋은 방법이 아닌 것 같습니다. 검색이 굉장히 어려워지기 때문이죠. 지금 문제는 북마크라는 테이블이 두개의 술어논리를 만족하고 있기 때문입니다.

* A 책은 B에 의해 쓰였다.
* A 책은 C에 의해 발행되었다.

정규화를 실시해봅니다.

![image2](https://user-images.githubusercontent.com/14071105/92922577-07f1f280-f471-11ea-89ef-8ab683226986.png)

정규화했습니다. 이제 여러 명의 저자도 쉽게 등록할 수 있습니다! 이렇게 간단한 예제를 만들면서 학습을 한다면 보다 빠르게 내가 잘 이해 안 된 것을 발견할 수 있습니다.

혹은 예제를 훌륭하게 만들어 냈다면 나는 올바르게 학습했다는 것을 확신할 수 있습니다. 그러면 학습에 대한 고민을 아주 많이 줄일 수 있다고 생각합니다. 아주 간단한 예제라도 상관없으니 예제를 만들면서 학습해보시길 바랍니다.

예제를 직접 만들어 학습하는 방법을 고민하고 실천에 옮긴 과정을 소개합니다.

CodeSoom Tech Blog