면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.
새로운 기술 스택을 배울 때 저는 공식 문서부터 보는 것을 원칙으로 합니다. 블로그나 강의보다 공식 문서가 가장 정확하고 최신 상태라는 것을 여러 번 확인하였습니다. 읽으면서 막히는 부분은 직접 코드를 실행하면서 확인합니다. 최근에 익힌 것은 FastAPI입니다. 기존에 Flask를 사용해왔는데, 비동기 처리와 타입 힌트 기반 API 설계 방식이 달라서 처음에는 낯설었습니다.
소규모 개인 프로젝트를 하나 만들면서 익히는 방식을 택했는데, 실제로 만들어보니 이해가 훨씬 빨라졌습니다. 배운 것을 쓰면서 익히는 방식이 저에게 가장 잘 맞습니다. 만들어보지 않으면 이해했다고 착각하기 쉽더라고요.
기술 스택을 배울 때는 전체 구조를 먼저 파악하고, 세부 기능을 채워가는 방식을 씁니다. 처음부터 모든 걸 알려고 하면 막혀서 포기하게 되더라고요. 먼저 '이 기술이 무엇을 해결하려는 것인가'를 이해하면, 세부 기능이 어디에 위치하는지 보입니다. 최근에는 `Docker`와 컨테이너 개념을 공부했어요. 개발 환경을 통일하는 문제로 팀 프로젝트에서 어려움이 있었는데, Docker Compose로 해결하면서 개념이 자리를 잡았습니다.
이론보다 문제를 해결하면서 배우는 경험이 가장 빠르게 체화되는 것 같아요. 그 방식을 계속 유지하겠습니다. 문제가 있으면 거기서 배우고, 배우면 다음에 더 잘 풀 수 있어요.
기술을 배울 때 저는 '왜 이렇게 설계됐을까'를 계속 물으면서 공부합니다. 기능만 외우면 다른 상황에서 응용이 안 되더라고요. 설계 이유를 이해하면 비슷한 상황에서 스스로 판단할 수 있어요. 최근에는 Redis를 익혔습니다. 캐싱 레이어가 왜 필요한지, 어떤 데이터가 캐싱에 적합한지를 이해하면서 공부했어요.
공부한 내용을 팀원에게 간단하게 설명해보는 습관을 가졌는데, 설명하다 보면 내가 모르는 부분이 명확하게 드러나서 더 효과적이에요. 가르치면서 배우는 방식이 저한테 잘 맞습니다. 설명할 수 없으면 아직 모르는 것이라고 생각해요. 그래서 배울 때 항상 설명 가능한 수준까지 파고드는 것을 목표로 합니다.
같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.
진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.