Why?
requests 를 분석하게 된 계기는 아래와 같다.
- 파이썬을 더 깊게 알고 싶었다. 기존에도 코딩 테스트를 볼 수 있을 정도로는 다룰 수 있었으나 이것만으로는 조금 더 심화된 문법(class, iterator, generator)이나 연관 모듈(packaging, test, pip)을 배울 수는 없었다. 오픈소스 코드를 분석하며 파이썬으로 OOP 를 어떻게 하는지, 패키징은 어떻게 되는지, 테스트 코드는 어떻게 짜여 있는지를 알고 싶었다.
- HTTP 라이브러리가 어떻게 구성되어있는지를 읽으며 HTTP 프로토콜의 작동 방식을 탐구하고 싶었다.
- 작은 단위가 아닌 어느정도 규모가 있는 코드를 읽고 싶었다. 어플리케이션 코드를 보면 좋겠지만 이런건 회사에 들어가거나, 내가 직접 프로젝트를 진행하지 않는한 여러 파일로 구성된 코드를 볼 기회는 흔치 않다.
How?
필자는 어떻게 requests 를 분석했을까?
- 우선 requests 가 지원하는 기능을 알기 위해 공식 문서에 기능 파트(Quickstart, Advanced Usage)를 정독했다. 만약 모르는 HTTP 관련 개념이 있다면 인터넷에서 찾아보고 정리했다.
- 소스코드를 다운받아 기능이 어떻게 구현되는지 분석했다. 예를 들어, 주로 사용하는 HTTP GET 요청인
requests.get(…)호출이 어떻게 이뤄지는지를 코드를 따라 이동하며 분석했다. - 파이썬 또는 OOP 개념이 어떻게 적용되었는지를 살펴봤다. 예를 들어, ‘패키징 방식이 어떻게 구성되었을까?’, ‘어떤 디자인 패턴이 쓰였을까?’ 질문하며 소스코드를 살폈다.
아래는 공식 문서를 보면서 궁금했던 점을 찾고 정리한 문서 일부다.
Retrospect
이 과정에서 꽤나 많은 시간(1주일 정도)을 투자했다. 이 과정 속에서 무엇을 느꼈을까?
‘야크 털 깎기’ 를 주의하자.
야크 털 깎기란, ‘원래 목적을 달성하기 위한 하위 문제들이 꼬리를 물어 원래 목적과 전혀 상관 없는 일을 하는 것’을 말한다. 목적을 달성하기 위한 하위 문제들을 풀다보니 어느새 엉뚱한 야크 털을 깎고 있는 것이다. 야크 털 깎기의 문제는 원래 목적을 잃어버리고 엉뚱한 일을 하면서 엄청난 시간을 까먹을 수 있다는 점이다. 저자 또한 이런 일이 많았는데, 예를 들어 ‘requests.py 의 패키징 방식’을 탐구해보자는 것이 ‘python 패키징 방식의 종류’ → ‘setup.py, setup.cfg, pyproject.toml 의 정의’ → ‘toml 의 정의’ → ‘XML, YAML, toml 과 같은 메타데이터 포멧의 특징’ → … 등 어느새 야크 털을 깎고 있었다. 궁금한게 많아 파고들어가는건 좋지만 이렇게 야크 털을 깎다간 본래의 목적을 달성할 수 없다. 따라서 앞으로는 달성하고자 하는 목표에 due date을 정하고 지금 내가 하는 일이 목표와 얼마나 연관되어 있는지 depth 를 따져 야크 털 깎기를 방지해야겠다.
'기술적' 완벽 보다는 '기능적' 완벽으로
저자가 requests.py 레포지토리에 올린 Issue 에 답변을 달아준 ian stapletoncordas 의 에세이 No Should be Your Default 에서는 "기본적으로 '아니오'가 기본이어야 한다”고 말한다. 새로운 기능 추가를 받아들이는 것보다는 “아니요, 추가하지 않겠습니다.” 방식으로 접근해야 프로젝트 고유의 목적을 유지하면서 버그를 줄일 수 있다고 한다. requests.py 는 아주 오래되고, 아주 많은 곳에서 사용되고 있는 라이브러리이다. 그만큼 핵심적인 기능은 이미 모두 구현되어 있다. 우리 개발자들은 기술적인 완성도(언어, 소프트웨어공학, 아키텍처 등에서)를 추구하기 때문에 분명 requests.py 에 개선할 점이 보일 수 있으나, 이는 기술적인 관점일 뿐 이것을 사용하는 사용자들에게는 오히려 버그를 만들고 일관성을 깨트릴 확률이 크다! 따라서 우리는 ‘기술적’인 완벽을 추구하기보다, ‘기능적’인 완벽을 추구하는게 더 바람직하다.
완벽한 글도 없다.
비슷한 맥락으로 완벽한 글도 없다. 이 세상에 독자가 필요로 하는 모든 정보를 담고있고, 모든 사람을 이해시킬 수 있고, 하나도 틀린 글자가 없는 글은 없다. 그런 논문도 존재할 수 없다. 무작정 글의 무결성을 추구하기보다는 '내가 전달하는 바가 무엇인지'를 바탕으로 글을 쓰자. 틀려도 된다. 글이 추구하고자 한 목적을 달성하는게 훨씬 중요하다.
말할 때 처럼 글을 쓴다.
글에 어느 정도까지의 내용을 담을지, 어느 정도의 깊이를 담을지, 어떤 건 넣고 어떤건 뺄지 고민을 하다보니 금방 쓸 수 있는 글을 2~3일씩 걸려 작성했다. 그 과정에서 몇가지 노하우가 생겨서 다음엔 더 빨리 좋은 글을 써낼 수 있다.
대화를 통해 정보를 전달할 때는 ‘제한된 시간 내에’, ‘말하고자 하는 핵심을 단백하게’ 얘기하는게 좋다. 그게 만약 학술적/기술적인 대화라면 더욱 그렇다. 나는 특히 ‘말하고자 하는 핵심을 단백하게’ 적는게 어렵다. 말할 때는 분명 핵심을 잘 이야기하는 것 같은데, 글을 쓰다보면 중간 중간 떠오르는 생각에 매몰되어 핵심을 적는데 집중하지 못하는 것 같다. 그래서 앞으로는 글을 쓸 때 1. 큰 틀을 먼저 잡고 2. 핵심이 되는 문장만을 적어놓은 다음 3. 상대방이 글을 이해하기 위해 필요한 최소한의 지식만을 추가로 담아 글을 쓸 예정이다.
