원사이트

🚀 공식 문서를 읽어야 하는 이유?

1. 라이브러리, 프레임워크에 있어서 강의 내지는 책은 현실의 속도를 반영하는 데 여러 제약이 있다.

2. 블로그에 누군가가 정리한 글은, 내가 작성하는 글도 마찬가지지만, 부정확한 정보를 제공할 가능성이 높다.

🚀 공식 문서의 어떤 부분을 읽어야 할까?

1. 기본적으로 Overview 혹은 Get Started 파트를 통해 해당 서비스를 관통하는 철학을 파악해야 한다.

2. 그 핵심 철학을 기준으로 API Reference를 말 그대로 톺아봐야 한다.

🚀 공식 문서를 어떻게 읽으면 좋을까?

1. 본인이 영잘알(=영어 마스터라는 뜻)이다?, 그냥 읽으시면 되겠다.

2. 영잘알이 아니면 GPT를 옆에 켜놓고, 번역 돌리면서 읽으시면 되겠다.

3. 공식 문서에 예제 코드가 있다면 코드를 먼저 확인하고, 없다면 GPT에게 공식 문서의 설명 부분을 전달하여 설명이 녹아든 예제 코드를 만들어달라고 부탁한다.

4. 이해에 있어서는 귀납적 접근 방식(= 구체적 사례를 통해 보편적 명제를 이해하는 방식)이 압도적으로 유리하다.(반박시 님 말이 다 맞음)

🚀 API Reference 선별 기준?

1. 서비스에서 제공하는 API가 대략 20-30개 정도이고, 사람들이 많이 사용하고 있다면 효율 따지지 말고 그냥 다 읽자.

2. AWS처럼 API가 너무 방대하다면, 다른 사람들의 코드를 통해 메인이 되는 API를 우선적으로 읽고 나머지는 기술 부채로 남겨두자.

🚀 다른 리소스와의 균형

1. 강의, 책, 블로그 글 역시 훌륭한 학습 리소스다.

2. GPT 역시 효율을 위해 자주 사용하는 것이 좋다.

3. 다만, 공식 문서가 First Source of Truth라는 사실을 늘 견지해야 한다.

🚀 결론

1. 현업에 가서 API 명세서를 이해하지 못해서 뻔뻔하게 사수에게 핑프짓을 할 호방함이 없다면, 징징대지 말고 공식 문서를 열심히 읽자.

2. 어차피 대부분의 일은 문서로 진행된다. 문서를 읽는 능력이 코딩 능력만큼이나 중요하다. 아니? 사실 코딩 능력이라는 게 공식 문서 읽기 능력과 같은 말일지도 모르겠다.

🚀 회고

소설가가 본인의 글을 작성하는 시간보다 타인의 글을 읽는 시간을 훨씬 많이 확보하는 것처럼, 개발자는 코드를 작성하는 시간보다 공식 문서를 읽는 시간을 압도적으로 많이 확보해야 한다. 방대한 양의 문서를 읽으면서 그저 의미 있는 것과 의미 없는 것, 가치 있는 것과 가치 없는 것을 끈기 있게 구분해야 할 뿐이다.

그런데, 의미와 가치는 내가 직접 판단해야 하는 것이지, 게으르게 남들의 기준으로만 판단하면, 누구나 작성할 수 있는 코드만 작성하는 코딩 앵무새가 될 수밖에 없다. 자기 생각이 없는 사람이 남들이 할 수 있는 말만 장황하게 풀어내는 것과 같은 이치다. 생각만 해도 짜증난다.

안다는 말을 함부로 하지 말고 똥인지 된장인지 찍어 먹어보는 습관을 길러보자. 생각보다 아는 게 없음을 알 수 있고, 결국 이게 메타인지 아닐까.