SK AI Networks 부트캠프 2주차 회고

2주차가 끝났다. 이번 주는 화요일부터 금요일까지 4일 동안 수업이 진행됐고, 겉으로 보면 지난주에 이어 Python을 더 배우는 시간이었다. 그런데 이번 주를 지나고 나서 남은 감각은 단순히 “문법을 더 익혔다”보다는, 이미 사용해 오던 언어를 더 낮은 단계에서 다시 구조적으로 보기 시작했다는 쪽에 가깝다.

기본 문법을 다시 훑는 것만으로는 크게 새로울 게 없었다. 대신 이번 주에는 MRO, inheritance, ABC, collections.abc, attribute lookup, namespace, import system, context manager, exception handling, generator, closure, descriptor, metaclass 같은 주제들을 공식 문서와 여러 레퍼런스를 같이 보면서 더 확장적으로 따라갔다. 같은 범위를 공부하더라도 어디까지 낮은 단계에서 이해해 볼지에 따라 완전히 다른 공부가 된다는 걸 다시 느낀 주였다.

특히 이번 주에 좋았던 점 중 하나는, 수업 범위를 벗어나서 다른 걸 많이 했다는 의미보다는 오히려 해당 범위들 내부에서 내가 공부를 더 확장적으로 이어갈 수 있었다는 점이다. Python을 이미 사용해 왔기 때문에 문법을 다시 외우는 방향보다는, 지금 배우는 범위 안에서 “왜 이렇게 동작하는가”, “이 동작은 어떤 객체 모델 위에서 성립하는가”를 계속 확인하는 방식으로 공부를 가져갈 수 있었다.

이번 주에는 dunder method를 단순히 문법적인 장치로 보는 게 아니라, 어떤 behavior를 어떤 protocol로 제공할 것인가라는 관점으로 다시 보게 됐다. collections.abc를 따라가다 보니 iterable/iterator만 따로 떼서 보는 게 아니라 container, hashable, sized 같은 분류까지 같이 보게 됐고, 결국 Python에서는 특정 타입을 엄격하게 선언하는 것보다 어떤 동작을 제공하느냐가 더 중요하다는 점을 다시 확인하게 됐다. 이 부분은 내가 이번 주에 봤던 ABC와 duck typing 관련된 내용들과도 자연스럽게 이어졌다.

또 기존에도 “Python을 안다”는 말이 표면적인 사용법을 안다는 뜻만은 아니라는 건 알고 있었지만, 이번 주에는 공식 문서를 더 자주 참조하면서 그 차이를 훨씬 더 구체적으로 바라볼 수 있게 됐다. 리스트, 딕셔너리, 함수, 클래스 같은 익숙한 도구들도 결국 object model, special method lookup, attribute lookup, namespace, import system, descriptor, metaclass 같은 맥락 안에서 다시 읽을 수 있다는 점이 분명해졌고, 그래서 앞으로도 사용법 자체보다 동작 원리 쪽에 시선을 유지하는 게 맞겠다는 생각이 더 강해졌다.

Keep

이번 주에 가장 만족스러웠던 건 학습 리듬이 어느 정도 안정적으로 이어졌다는 점이다. 정해진 시간 안에 수업을 듣고, 수업이 끝난 뒤에도 내가 이해를 더 넓히고 싶은 부분을 따로 찾아보는 흐름이 자연스럽게 유지됐다. 단순히 진도를 따라가는 것보다, 그날 나온 키워드를 레퍼런스로 다시 확인하면서 공부를 이어가는 방식이 지금의 나한테는 잘 맞는 편이다.

또 하나 유지하고 싶은 건 레퍼런스 중심의 학습 방식이다. 공식 문서, 강의, 발표 자료, 잘 정리된 코드 예제들을 먼저 모아두고, 그 안에서 내가 이해되지 않는 지점을 중심으로 다시 따라가는 방식은 확실히 도움이 된다. 무조건 정리부터 하는 것보다, 먼저 여러 자료를 충분히 보고 내가 정확히 무엇을 모르는지 파악한 뒤 들어가는 편이 훨씬 밀도가 높았다.

이번 주에 특히 좋았던 건 범위를 무작정 넓히는 방식이 아니라, 같은 범위 안에서도 더 낮은 단계의 설명과 구현 관점을 계속 찾아보는 흐름이 만들어졌다는 점이다. 이 방식은 당장 속도는 느릴 수 있어도, 나중에 상위 개념을 볼 때 훨씬 단단한 이해로 이어질 가능성이 크다고 느꼈다.

Problem

이번 주에 가장 크게 느낀 문제는 역시 정리의 오버헤드였다. 지난주부터 노션 자료를 Obsidian으로 마이그레이션하고, 파일 구조와 링크를 다시 잡고, 개념들을 연결하는 작업을 진행해 왔는데, 이 과정 자체는 분명 의미가 있었다. 다만 자료가 많아질수록 “이해를 깊게 하는 일”보다 “정리를 보기 좋게 만드는 일”에 시간이 더 많이 들어가기 시작한다는 점이 생각보다 크게 느껴졌다.

레퍼런스를 많이 보는 건 좋은데, 그걸 전부 다 자세한 노트나 기술 블로그 형태로 남기려 하면 결국 기록 자체가 목적이 되기 쉽다. 나는 결과적으로 기록을 많이 남기는 것보다, 실제로 이해하고 설명할 수 있게 되는 쪽에 더 무게를 두고 싶다. 그래서 이번 주에는 “정리를 잘하는 것”과 “이해를 잘하는 것”을 분리해서 봐야겠다는 생각이 더 분명해졌다.

또 하나는 범위가 넓어질수록 오히려 스코핑이 더 중요해진다는 점이다. 나한테 중요한 건 범위를 일부러 좁히는 게 아니라, 어떤 단위로 개념을 끊어서 보고, 그 단위를 어떻게 상위 개념과 연결할 것인지를 명확하게 잡는 것이다. 예를 들어 generator를 보면 곧바로 coroutine과 concurrency로 이어지고, import system을 보면 namespace package와 packaging으로 이어지고, attribute lookup을 보다 보면 descriptor와 metaclass까지 자연스럽게 연결된다. 이런 확장은 오히려 내가 원하는 방향에 가깝다. 다만 그럴수록 “이번 주에는 무엇을 어떤 단위로 이해했는가”를 구조화하는 감각이 더 중요하다는 걸 느꼈다.

기술 블로그에 대한 생각도 비슷하다. 내가 공부한 걸 글로 남기는 건 여전히 좋다고 생각한다. 다만 모든 내용을 완성도 높은 기술 블로그로 만들려는 태도는 지금의 나한테는 오히려 비효율적이다. 정말 세밀한 디테일이 필요하면 결국 공식 문서를 보는 게 맞고, 내가 남겨야 하는 건 공식 문서를 대체하는 글이 아니라 내가 무엇을 이해했고, 무엇을 더 확인해야 하는지를 남기는 기록에 더 가깝다고 느꼈다.

Try

다음 주에는 기록보다 이해를 더 우선하는 방향으로 학습 방식을 조금 더 분명하게 가져갈 생각이다. Obsidian은 계속 쓰겠지만, 모든 내용을 세세하게 정리하는 용도보다는 필요한 레퍼런스를 남기고 핵심 키워드만 구조화하는 용도로 더 가볍게 사용할 예정이다. 리니어처럼 “이번 주에 어떤 토픽을 봤는지”를 트래킹하는 용도는 유지하되, 지나치게 정리 자체에 많은 시간을 쓰는 방식은 줄이려고 한다.

학습 주제 쪽에서는 다음 주부터 concurrency를 조금 더 집중해서 볼 생각이다. 기본적인 사용 방법 수준의 설명은 이미 알고 있지만, 실제로 Python 내부에서 어떤 제약과 구현 위에서 돌아가는지, 그리고 그것이 운영체제/스레딩 관점과 어떻게 이어지는지는 더 공부하고 더 생각해 봐야 할 부분이 많다. 특히 generator, yield, coroutine, threading, GIL, free-threaded Python 같은 주제는 서로 따로 떨어져 있는 게 아니라 실행 모델이라는 하나의 축으로 연결해서 봐야 한다고 느꼈다.

이 과정에서는 Python 공식 문서를 더 적극적으로 따라가 볼 생각이다. 다만 공식 문서는 어느 정도 기본 지식을 이미 알고 있다는 전제 위에서 서술되는 경우가 많기 때문에, 공식 문서를 읽기 위해 필요한 배경지식 자체도 여러 강의와 레퍼런스를 통해 계속 보강해야 한다. 그래서 다음 주에는 공식 문서를 기준점으로 삼되, 필요한 경우 운영체제 강의나 추가 레퍼런스를 계속 붙여가면서 이해를 쌓는 방식으로 진행할 예정이다.

Python 외의 주제에서는 데이터베이스도 다시 보고 싶은 영역이다. 단순히 클라이언트를 붙여서 사용하는 수준이 아니라, 내부 구조와 query optimization, execution plan, storage layer 관점에서 다시 보고 싶다는 생각이 계속 들고 있다. 다만 다음 주의 1순위는 우선 concurrency 쪽에 두고, 데이터베이스는 수업 진도와 함께 필요한 만큼 연결해서 가져갈 것 같다.

이번 주에 같이 체크한 외부 흐름 / 추가 레퍼런스

이번 주에는 Python 자체를 공부하는 것과 별개로, 최근 에이전트 툴링과 RAG 흐름도 같이 계속 체크했다. OpenAI 쪽에서는 GPT-5.4와 함께 tool search, built-in computer use, larger tool ecosystems 관련 발표와 문서를 확인했고, 이 부분은 내가 지금 사용 중인 브라우저 자동화/DevTools 기반 워크플로우와도 자연스럽게 연결됐다. 지금까지의 computer-use 계열 접근이 주로 screenshot 기반 루프와 마우스/키보드 액션 반복에 많이 의존했다면, 앞으로는 이 부분이 더 네이티브하게 정리될 가능성이 있겠다는 생각을 다시 하게 됐다.

또 Google Workspace CLI도 따로 체크했다. 예전에 Workspace/SMTP/자동화 관련 작업을 직접 다뤘던 경험이 있다 보니, 이번에 본 gws 저장소가 이후 워크플로우에 어떻게 연결될 수 있을지 한 번 더 확인해 보고 싶어졌다. 특히 이 도구가 Rust 기반 CLI라는 점, 그리고 agent skill까지 같이 엮고 있다는 점은 나중에 다시 볼 가치가 있다고 느꼈다.

RAG 쪽에서는 vector-only retrieval의 한계, reranker의 역할, k값 선택 문제, GraphRAG/HybridRAG 같은 접근, 그리고 retrieval 결과를 언제 어떤 방식으로 모델에 주입할 것인가에 대한 발표들을 계속 찾아봤다. 아직 여기서 어떤 결론을 내린 건 아니지만, 적어도 “retrieval을 잘한다”는 말이 단순히 벡터 검색 하나로 끝나는 문제가 아니라는 점은 더 분명하게 보이기 시작했다.

이번 주 기준으로 아직 더 확인하고 싶은 항목들도 분명하다. 다음 주 이후에 다시 보고 싶은 건 크게 다음과 같다.

Python의 concurrency 관련 실행 모델: threading, GIL, free-threaded build, generator/coroutine 사이의 연결
generator의 send(), throw(), close()까지 포함한 실행 흐름
computer use / tool search / MCP 계열 워크플로우가 실제 에이전트 정확도와 토큰 사용량에 어떤 차이를 만드는지
Google Workspace CLI(gws)가 기존 자동화 워크플로우와 어떻게 연결될 수 있는지
GraphRAG, HybridRAG, parametric retrieval 같은 흐름이 실제 retrieval 품질에 어떤 차이를 만드는지
데이터베이스 내부 구조와 query optimization을 운영체제/시스템 관점과 함께 다시 보는 흐름

마무리

이번 주를 한 문장으로 정리하면, Python을 “익숙한 언어”로 다루는 데서 멈추지 않고, 더 낮은 단계에서 다시 읽기 시작한 한 주였다.

이번 주에 공부한 내용들을 전부 다 정리해서 완결된 형태로 남기지는 못했다. 하지만 오히려 그래서 더 분명해진 것도 있다. 지금 나한테 중요한 건 모든 내용을 완벽한 노트나 블로그 글로 남기는 게 아니라, 내가 어떤 개념을 어떤 단위로 이해하고 있고, 무엇을 다음 주제로 연결해 나가고 싶은지를 계속 확인하는 일이다.

다음 주에는 기록의 오버헤드는 조금 줄이고, 이해의 밀도는 조금 더 높이는 방향으로 가보려고 한다.

writat

Search This Blog