diff --git a/The_Missing_README/Chapter02.md b/The_Missing_README/Chapter02.md
new file mode 100644
index 0000000..7c5cc32
--- /dev/null
+++ b/The_Missing_README/Chapter02.md
@@ -0,0 +1,171 @@
+## 2장 역량을 높이는 의식적 노력
+
+> 경쟁력을 갖춘 개발자가 되기 위해 스스로 해야 할 일
+
+마틴 브로드웰의 `학습을 위한 가르침`이라는 책에서 나오는 능숙함을 4 단계로 나눠 정의한다.
+
+- 무의식적 능력부족(unconscious incompetence)
+  - 업무를 올바르게 수행할 역량도 안 되고 자신의 부족함을 인지하지도 못하는 상태를 말한다.
+- 의식적 능력부족(conscious incompetence)
+  - 업무를 제대로 수행하지는 못하지만 자신의 부족함은 인지하는 상태를 뜻한다.
+- 의식적 능숙(conscious competence)
+  - 노력을 통해 해당 업무를 수행할 역량이 갖춰진 상태를 의미한다.
+- 무의식적 능숙(unconscious competence)
+  - 해당 업무를 수월하게 수행할 수 있는 역량이 갖춰진 상태를 의미한다.
+
+모든 엔지니어는 의식적이든 무의식적이든 능력부족 단계에서 시작한다. **모든 엔지니어링 기술을 알고 있더라도 해당 회사, 팀의 절차와 규칙은 반드시 익혀야 한다.**
+
+목표는 빠르게 의식적 능숙 상태에 들어가는 것이다.
+
+### 실전에 앞서 익혀야 할 자기주도 학습 방안
+
+배움은 능숙한 엔지니어에 이르고 향후 몇 년간 제대로 성장하는 데 도움이 되는 방법이다. 소프트웨어 엔지니어링 분야는 끊임없이 발전한다. 따라서 노련한 사람이든 초짜이든 배움을 지속하지 않으면 도태된다.
+
+#### 본격적인 학습을 위한 몸풀기
+
+입사 후 몇 달간은 일단 상황이 어떻게 돌아가는지 파악하는 데 집중하자. 그러면 설계 회의나 온콜 교대 업무, 운영 이슈, 코드 리뷰 등에 참여하는 데 도움이 된다.
+
+#### 직접 부딪혀보며 배우자
+
+가장 좋은 학습방법으로 직접 실습하며 학습하는 것이다. 팀에 합류한 신입이라면 적절한 난이도의 미션을 팀장이 부여해줄 것이기 때문에 너무 겁먹지 않는 것이 좋다. 실수는 피할 수 없다.
+
+#### 코드 동작을 이해하기 위해 다양한 실험을 해보자
+
+여러 가지 시도를 해보며 코드가 어떻게 동작하는지 알아두자. (기록)
+
+디버거를 통한 생명주기를 파악하거나 프로그램 로직등을 학습한다.
+
+#### 문서 읽는 습관은 몸에 배야 한다
+
+매주 일정 시간을 할애해 자료를 읽는 습관을 들이자.
+
+*여기서 가장 중요한 점은 매주 일정한 시간이라는 점이다. 가장 안좋은 형태는 불태우는 과정이고 그 과정에서 금방 질리기 마련이다.*
+
+> 코드는 결코 거짓을 전하지 않는다. 하지만 주석은 간혹 거짓을 말할 때가 있다.
+
+할일은 티켓이나 이슈로 관리한다. 서로 무슨일을 하는지 알 수 있도록, 무슨 일을 해야하는지 공유가 되는 것이 가장 먼저이다.
+
+#### 발표 영상을 찾아서 보자
+
+사내 발표나 기술에 대한 외부 발표 영상을 보고 이를 공유하자. (정리를 통해 개념을 학습)
+
+#### 때로는 밋업과 컨퍼런스도 참여하자
+
+컨퍼런스와 밋업에 참석하는 것은 네트워크를 구축하고 새로운 아이디어를 접할 수 있는 좋은 방법이다.
+
+### 시니어 엔지니어의 업무를 체험하고 협업하자
+
+- 체험하기(shadowing)
+  - 다른 사람이 업무를 수행하는 동안 그림자처럼 따라 다니는 것을 말한다.
+  - 따라다니며 배우고 이후에는 바꿔보는 것도 좋은 방법이다.
+- 짝 프로그래밍(pair programming)
+  - 두 명의 엔지니어가 하나의 컴퓨터에서 작업하는 방식이다.
+  - 코드의 품질을 높이기 좋은 방법으로 권한다면 무조건 해보는 게 좋다.
+
+#### 개인 프로젝트 활동에서 배움을 얻을 수 있다
+
+사이드 프로젝트는 새로운 기술과 아이디어를 접할 수 있는 방법이다. 다만 항시 '본업'에 충실해야 한다.
+
+오픈소스 프로젝트에 참여하는 것도 한 방법이다.
+
+가장 중요한 것은 배워야 하는 소재라는 근거로 프로젝트를 선택해서는 안 된다. 해결하고 싶은 문제를 찾아내고, 자신이 배우고 싶은 도구를 이용해 그 문제를 풀어야 한다. 목표가 있어야 더 오래 몰두하고 더 많이 배울 수 있는 본질적인 동기가 스스로에게 부여된다.
+
+대체로 회사에는 업무 외 활동에 대한 규정이 정해져 있으므로 자신이 속한 회사의 정책을 확인하는 것이 좋다.
+
+### 제대로 질문하자
+
+모든 엔지니어는 질문을 해야 한다. 질문은 배움에 있어 매우 중요한 비중을 차지한다. 신입 엔지니어는 팀 동료에게 폐가 될까 싶어 모둔 것을 혼자 알아내려고 한다. (매우 비효율적)
+
+#### 스스로 문제를 해결해보자
+
+먼저 스스로 답을 찾아보자. 설령 동료가 답을 알더라도 그에 앞서 스스로 노력해봐야 한다. 그 과정에서 매우 많이 배우게 되고, 직접 찾아본 내용을 토대로 도움을 청할 수 있다.
+
+무작정 인터넷을 뒤지는 방법은 옳지않고, 정보는 문서와 코드에 다 존재한다.
+
+#### 제한 시간을 정하자
+
+문제를 해결하기 위한 시간을 정해두자, 스스로 시도해보기 전에 제한 시간을 정해두면 학습 효과도 높아질 뿐 아니라 부적합한 결론이 도출되는 상황을 미연에 방지할 수 있다.
+
+*앞서 말한 하루에 몰아서하는 좋지 못한 상황에 대한 방어법이다.*
+
+#### 자신이 시도한 방법을 공유하자
+
+질문을 할 때는 자신이 이미 파악한 내용을 설명해야 한다. 기록해둔 내용을 그대로 전달하라는 의미가 아니다. 시도한 방법을 간결하게 요약하자.
+
+```
+앨리스 님께,
+testkey가 왜 testKVStore에 저장되는지 혹시 아시나요?
+그것 때문에 피드가 굉장히 느려지고 있거든요.
+
+고맙습니다.
+
+ooo드림
+```
+
+```
+앨리스 님께,
+저는 지금 testKeyValues가 (DistKV 레포에) TestKVStore에 저장되는 문제를 해결 중이에요. 숀이 앨리스 님께 물어보라고 하더라구요. 이와 관련하여 도움을 받고 싶습니다.
+
+테스트를 실행하면 두 번까지는 성공적으로 넘어가는데 세 번째 테스트에서 매번 실패합니다. 랜덤하게 실패하는 것 같습니다. 그 테스트를 따로 실행해봤는데도 여전히 실패하고 있는걸 보면 다른 테스트에 영향을 받는 것은 아닌 것 같습니다. 테스트 루프안에서 실행해도 원인을 찾지 못하고, 소스코드를 읽어도 명학환 원인을 찾을 수 없었습니다. 일종의 경합 상태 같은데 어떻게 생각하시나요?
+
+프로덕션 환경에선 큰 영향이 없을거라고 하니 급한 문제는 아니지만, 테스트 실패시마다 빌드가 20~30분씩 느려져서 꼭 해결하고 싶습니다. 혹시 몰라 테스트 환경과 로그를 같이 첨부합니다.
+
+감사합니다.
+
+ooo드림
+```
+
+두 메일은 명확한 차이가 있다. 처음 관계는 불만이 있어보이지만 명확한 컨텍스트와 문제를 설명하기에 상세 내용을 파악하는 것에서 시간을 허비하지 않는다.
+
+#### 동료를 방해하지 말자
+
+모든 동료는 각자가 해야할 일이 명확하게 존재한다. 그래서 집중이 필요하다. 설령 쉬운 문제일지라도, 그에게 해결책이 있다고 해도 다른 이를 쉽게 방해해서는 안된다.
+
+*이에 대한 순간은 개개인마다 다를 수 있지만, 어느정도 눈치로 파악이 가능하다. 헤드폰을 쓰거나 자신만의 공간에 가는 등*
+
+#### 비동기식 멀티태스킹 의사소통을 시도하자
+
+멀티태스킹, 비동기는 컴퓨터의 영역뿐만 아니라 사람 간의 의사소통에도 적용할 수 있다.
+
+질문은 여러 사람이 각자의 상황에 따라 응답할 수 있는 곳에 올리자. 모든 사람이 볼 수 있는 곳에 올려두면 문제가 해결됐다는 점도 모두가 알 수 있게 된다.
+
+#### 동기식 요청은 한 번에 보내자
+
+간단한 질문은 이메일이로 해결 가능하지만, 복잡한 논의는 적합하지 않다. 직접 만나 대화하면 '많은 내용'을 빠르게 전달할 수 있지만 다소 비용이 든다.
+
+### 성장의 장애물을 극복하자
+
+스스로 학습하는 방법을 아는 것만으로는 충분하지 않다. 반드시 성장에 방해되는 요소는 제거해야 하고 가장 보편적인 장애물은 가면 증후군과 더닝 크루거 효과이다.
+
+#### 가면 증후군
+
+대부분의 신입은 의식적 능력부족 상태에서 시작한다. 배울 것도 많고 자신을 제외한 모든 사람이 자신보다 훨씬 앞서가는 느낌을 받는다. 어쩌면 어울리지 않는 자리에 있는 것 같다거나 단지 운이 좋아 이 직업을 갖게 된 듯해서 온갖 걱정에 휩싸이기도 한다. 그러다 보면 간혹 스스로에게 너무 업격해지기도 한다.
+
+이런 현상을 바로 가면 증후군이라고 하며 자신을 의심하며 스스로에 대한 불신이 강해지는 경향이 있다. 사실 누구나에게 있는 보편적인 현상이라는 점을 기억해야 한다.
+
+가면 증후군은 점점 더 강화되는 경향이 있으며 모든 오류는 자신의 능력 부족에 대한 증명으로 여기는 반면, 모든 성공은 남을 '기만'하는 증거로 바라본다.
+
+이 상황에선 적절한 자기인식(메타인지)가 중요하다. 운이 좋은 것이 아닌 자신이 증명한 성과로 봐야하며 지속적인 기록을 통해 자신을 바라봐야 한다.
+
+피드백을 받는 것도 도움이 된다.
+
+*임포스터 증후군이라는 비슷한 증후군도 있다.*
+
+#### 더닝 크루거 효과
+
+더닝 크루거 효과는 가면 중후군과 반대되는 현상으로, 스스로 과대평가하는 인지적 편견을 갖는 것이다. 무의식적 능력부족 상태의 엔지니어는 자신이 뭘하는지 뭘 모르는지 모른다.
+
+그래서 자신의 역량을 제대로 평가하지 못한다. 자신감이 넘친 나머지, 자신이 속한 회사의 기술 스택을 비난하고 코드 품질에 불만을 가지며 설계를 무시한다. 이러 부류는 늘 자신의 생각이 옳다고 확신하며 기본적으로 피드백을 거부한다.
+
+이도 마찬가지로 메타인지의 영역으로 해결이 가능하고 타인의 의견을 통해 되돌아볼 수 있다.
+
+### 개발자 필수 체크리스트
+
+|이것만은 지키자|이것만은 피하자|
+|---|---|
+|코드를 이용해 자주 실험하자|이무 생각 없이 코드만 찍어내서는 안 된다|
+|설계 문서와 다른 사람이 만든 코드를 읽자|위험과 실패를 두려워하지 말자|
+|밋업, 커뮤니티, 관심 그룹, 멘토링등 프로그램에 참여하자|너무 잦은 컨퍼런스는 금물이다|
+|논문과 블로그를 읽자|질문하기를 두려워하지 말자|
+|멀티캐스트/비동기식으로 소통하자| |
+|인터뷰나 면접, 긴급대응 교대 업무를 따라 다녀보자| |