라이브러리를 읽는 법: Problem → Solution → Trade-off

iOS 라이브러리 스터디를 시작하게 된 이유

우연히 디프만 동아리에서 iOS 라이브러리 스터디에 참여하게 되었다.
동아리 내에는 현업자분들도 계시고, 실무 관점에서 피드백을 받을 기회가 흔치 않다 보니 참여를 결심했다.

총 6명이서 진행하는데, 나를 제외하면 모두 현업을 하고 계신 분들이었다.
연차도 1~4년차까지 다양해서, 같은 코드를 보더라도 각자 다른 포인트에 관점을 두고 해석하는 과정을 통해

“왜 이렇게 설계했는지”를 더 입체적으로 고민해보고 배우고 싶었다.

---

내가 하고 싶은 학습 방식: 사용자 관점이 아니라 설계자 관점

이번 스터디에서 내가 가져가고 싶은 학습 방식은 단순하다.

• Problem → Solution → Trade-off
• 사용자 관점 X → 설계자 관점 O

라이브러리를 공부할 때 흔히 “이 메서드는 뭘 한다 / 이 클래스는 뭘 담당한다” 같은 기능 설명으로 끝나기 쉽다.

 

하지만 실제로 실력이 쌓이는 지점은 그 다음이라고 생각한다.
즉, 코드가 하는 일이 아니라 코드가 태어난 이유를 묻는 것이다.

• 이 코드는 어떤 문제 때문에 생겼는가? (Problem)
• 그 문제를 어떤 방식으로 해결했는가? (Solution)
• 그리고 그 선택은 무엇을 얻고, 무엇을 포기했는가? (Trade-off)

이 관점이 잡히면, 특정 라이브러리 하나를 넘어서서
다른 라이브러리/우리 코드에서도 같은 질문을 던질 수 있게 된다.

---

스터디 진행 방식

스터디의 방향은 딱히 강하게 정해진 건 없고, 각자 학습한 내용을 공유하는 흐름이다.

그래서 나는 매주 “내가 이해한 것”을 단순 요약하기보다,

내가 학습하면서 실제로 궁금했던 지점과 그 지점이 드러내는 설계 판단의 근거/트레이드오프를 중심으로 정리해 공유해보려고 한다.

---

첫 번째 라이브러리: 이미지 캐싱 Kingfisher

첫 번째로 선정한 라이브러리는 이미지 캐싱에 많이 사용되는 Kingfisher였다.
요즘 컴퓨터 구조를 학습하면서 CPU의 “캐시”라는 키워드를 계속 접하다 보니, 이미지 캐싱도 더 친근하게 다가왔다.

 

사실 나는 Kingfisher를 단순히 “이미지 캐시를 해주는 래퍼 라이브러리” 정도로만 사용해왔다.
하지만 이번에는 “그냥 쓰는 것”을 넘어, 왜 이런 구조를 선택했는지를 코드로 확인해보고 싶었다.

---

마무리

물론 하나의 라이브러리를 온전히 “씹어 먹는 것”은 쉽지 않다.
그래도 이 시간을 소중히 여겨서, 사람들이 많이 사용하는 기술에는 어떤 문제들이 있었고,

그 문제를 해결하기 위해 어떤 트레이드오프를 감수했는지를 제대로 배우고 싶다.

결국 목표는 하나다.

라이브러리를 읽는 경험이, 내 엔지니어링 사고(문제 정의 → 설계 선택 → 트레이드오프 판단)를 더 단단하게 만드는 것.