저랑 오픈소스 같이 공부하실분~
사내에서 성능 병목을 겪거나, 라이브러리의 버전 관리를 하다 보면 자연스럽게 오픈소스의 코어 로직을 탐색하게 된다.
불과 몇 달 전까지만 해도 오픈소스 코드를 읽는 것 자체가 벅찼지만, AI의 발전 덕분에 (물론 내 실력이 향상된 것도 있지만) 자체가 달라졌고, 지금은 훨씬 쉽게 탐구할 수 있게 되었다.
예전에는 내가 필요한 부분만 빠르게 훑고 넘어가는 일이 많았지만, 최근엔 코어 기능을 응용하거나 프로젝트에 직접 접목해야 하는 일이 잦아지면서 더 깊이 있는 이해와 분석이 필요해졌다.
아마 이 글을 읽는 많은 분들이 단순한 관심을 넘어서, 실질적인 오픈소스 기여를 목표로 하고 있으리라 생각한다. 그래서 이 글은 단순한 맞춤법 수정이나 사소한 버그 픽스가 아닌, 내가 어떤 방식으로 AI를 활용해 오픈소스의 핵심 로직을 탐구하고, 구조적 이해를 바탕으로 한 의미 있는 기여를 위한 접근 방법에 초점을 맞추어 정리해보려 한다.
AI를 활용한 오픈소스 탐구
“AI를 활용해 오픈소스를 공부한다” 고 하면 막연하게 느껴질 수 있다.
실제로 오픈소스 코드베이스는 방대한 경우가 많아, 모든 내용을 AI에게 학습시키는 건 아직 불가능하다. (가벼운 용량의 라이브러리면 가능할 것 같지만..)
그래서 나는 아래와 같은 계획을 세우고, 그에 맞춰 AI를 효율적으로 활용해왔다.(요즘 claude 4.0 모델을 사용하고있다.)
1. 관심 있는 라이브러리를 포크한다.
2. 핵심 로직 한 부분을 선정하고, 관련 로직들을 탐색하며 구조를 파악한다.
3. 명확한 구조를 보여주는 로직을 중심으로 AI에게 학습시킨다.
4. AI와의 대화를 통해 메인테이너의 설계 의도와 방향성을 추정한다.
5. 이해되지 않는 부분은 질문 리스트로 정리한다.
6. 각 질문에 대해 가설을 세우고, AI에게 흐름 설명을 요청하며 검증한다.
7. 이해한 내용이 타당하다면, 실제 개선 PR을 위한 브랜치를 만들어 기여를 시도한다.이렇게 보면 이해가 되지 않는 부분이 많을 것 같아 가장 최근에 공부하고 기여해본 TanStack Route 라우팅 탐색 최적화 (PR #4513) 을 가지고 이야기해보겠다.
관심 있는 라이브러리 선택해보자.
가장 먼저 관심 가지고 깊게 분석해볼 라이브러리를 선택하는 것이 첫 번째다. 나는 다음의 기준을 우선순위로 두었다.
- 회사에서 실제로 사용 중인 라이브러리
- 사내에서 사용하는 버전과 공식 최신 버전 간의 간극이 큰 라이브러리
- 유사 기능을 가진 다른 라이브러리들과의 구조 비교가 가능한 라이브러리
나는 최근 회사에서 react-router를 사용하고 있었는데, 앞으로 tanstack-router로 교체해보는 것이 더 나은 선택일 수 있을지 고민하게 되었다.
계기는 우연히 본 Reddit 게시글이었다. (물론 새로운 라이브러리가 나올때마다 쉽게 바꾸고 대응할 수 없겠지만, 관심은 가져야한다고 생각한다.)
- React Router v7이 Remix의 구조적 영향을 크게 받았으며, 점점 Remix 중심의 방향으로 진화하고 있다는 내용.
- React Router v7과 TanStack Router의 차이점이 무엇인가요?
이 내용이 궁금해져 react-router의 버전 히스토리를 살펴보았고, 그 대안으로 떠오른 tanstack-router가 눈에 들어왔다. 보다 명확한 비교와 판단을 위해 tanstack/router 레포지토리를 포크하고 본격적인 분석을 시작했다.
TanStack 라이브러리 성장 속도가 엄청 빠르다.
처음 tanstack/query 만 서버상태관리를 위해 사용했다.
그러다 정신차리고 보니, router, store, db, form 등 라이브러리들을 쏟아내고있다.
모든 라이브러리를 알지 못해도 현재 사용하고있는 아래 라이브러리의 코어 로직은 탐구해봐야겠다고 생각했다.
- react-router
- 클라이언트 상태관리 라이브러리(zustand, jotai, recoil)
- react-hook-form
핵심 로직 한 부분을 선정하고, 공부해보자.
처음부터 코어 로직들을 다 살펴보겠다는 목표를 가지고 탐구를 시작했다.
하지만 코어 로직이 상당히 비대하고, 깊은 이해도를 가지기에는 많은 시간이 소비가 되어 원래의 목표를 달성하기 전에 절망에 빠져버렸다. 그래서 내가 중점으로 살펴볼 핵심 로직을 정하고 그 로직을 중심으로 연결된 로직들을 살펴보는 방식을 취했다.
내가 tanstack-router를 살펴보려 했을 때 가장 먼저 궁금했던 것은 성능 병목과 구조적 효율성이었다. 특히 다음 세 가지가 주요 관찰 포인트였다.
- TanStack Router는 성능 측면에서 얼마나 최적화되어 있을까?
- 기존 react-router와 비교했을 때, 제공하는 메서드나 API의 호환성이 충분할까?
- 실무에서 마이그레이션을 진행한다면 비용이 얼마나 들까?
이 중 가장 먼저 확인해야 할 것은 라우팅 트리 매칭 방식이었고, 이에 관련된 matchRoutesInternal을 집중적으로 탐색하게 되었다.
학습한 로직을 중심으로 AI에게 학습시킨다.
코드를 분석하다 보니 matchRoutesInternal 함수가 라우트 트리를 전부 순회하며 매칭하는 구조로 작성되어 있다는 점이 눈에 띄었다.
메인 로직과 연관된 함수들을 보았다. getMatchedRoutes 함수를 통해 경로 매칭하고 내부에 파라미터 파싱 및 검증, 검색 파라미터 검증 로직들이 서로 연관되어있다.
이 방식은 트리 깊이가 깊거나, 라우트 수가 많아질수록 성능 병목이 발생할 수 있는 구조라고 생각해보았다. 그래서 학습한 로직과 matchRoutesInternal 함수와 연관된 로직들을 AI 에게 학습시켜보았다.
메인테이너의 설계 의도와 방향성 파악하기
기존 로직을 AI와 함께 분석하며, 왜 현재 구조가 이런 방식으로 설계되었는지, 이 구조가 어떤 문제를 풀기 위해 존재하는지 메인테이너의 입장에서 고민해보았다.
단순히 “어떤 부분이 효율적이고, 어떤 부분이 비효율적이다”라고 판단하는 것이 아니라, 이 방식이 왜 선택되었고, 어떤 조건에서 성능 문제가 생기는지를 파악하는 것이 중요했다.
Claude 4.0 모델 을 아래처럼 활용해보았다.
이해되지 않는 부분은 질문 리스트로 정리해보기
분석 도중 다음과 같은 의문이 생겼다.
- “왜 전체 트리를 매번 순회하는가?”
- “자식 노드를 가지는 경우에도 모든 경로를 전수조사해야 하는 구조인가?”
- “이 방식은 현재 구조에서 최적의 선택일까, 아니면 단순한 구현상의 디폴트인가?”
이러한 질문 리스트를 바탕으로, 더 효율적인 구조로 대체할 수 있을지 가설을 세우며 AI 를 활용해 더 깊이있게 matchRoutesInternal 을 탐구해보았다.
가설 검증해보기
이후 나는 다음과 같은 가설을 세웠다.
매번 트리를 순회하지 않고, Trie 기반의 정적 라우트 매칭 구조로 바꾼다면 성능을 개선할 수 있지 않을까?
이 아이디어를 바탕으로 RouteTrie 구조를 새로 작성하고, 기존의 matchRoutesInternal 로직을 대체해 성능을 개선하는 방안을 구현했다.
또한 자체적으로 테스트 파일을 구성해 가설을 검증했고, 아래 개선사항을 확인했다. (내가 작성했던 테스트는 PR 올리는 과정에 삭제했는데, 메인테이너가 추가 테스트 파일을 작성해 PR 에 추가해줬다.)
- A → B → A와 같이 이전 페이지로 빠르게 돌아오는 경우, A 페이지 데이터가 캐시에 유지
- 동시 네비게이션 시 사용자가 링크를 빠르게 여러 번 클릭할 때 발생할 수 있는 데이터 손실을 방지
- 페이지 데이터를 새로 고치는 도중 다른 페이지로 이동했다가 돌아올 때 캐시된 데이터가 유지
검증이 옳다면 실제 개선 PR을 위한 브랜치를 만들어보자.
검증 결과 성능 병목이 실제로 존재했고, 내가 제안한 구조가 이를 개선할 수 있다는 확신이 들었다. 이에 개선된 로직을 기반으로 PR을 올렸고, 메인테이너가 이를 받아들여 최종적으로 공식 반영되었다.
마무리하며
이 글에서는 어떤 코드를 어떻게 수정했는지를 설명하려는 것이 아니다. 더 중요한 것은, 이런 흐름으로 오픈소스를 탐구하고 이해하는 방식이 나한테 많은 도움이 되었다는 것을 알려주고 싶었다.
처음에는 단순한 의문에서 출발했지만, 핵심 로직을 직접 탐색하고, AI를 활용해 설계를 파악하며, 작은 가설을 세워 검증하고, 실제 기여까지 연결해보는 일련의 과정을 거치면서 단순한 학습 이상의 깊이 있는 이해와 개발자로서의 성장을 경험할 수 있었다.
이런 방식으로 지난 2개월 동안 여러 오픈소스 라이브러리들을 분석하고, 그 중 일부는 실제로 개선하며 기여의 보람도 느낄 수 있었다.
그리고 요즘 제일 많이 탐구하고 있는 toss 의 오픈소스들
오픈소스를 분석해보는 것은 엄청 어렵고, 거창한게 아니다.
내가 사용하는 도구가 왜 이렇게 만들어졌는지에 대한 ‘왜’에서 출발해, 작은 질문과 개선 의지를 가지고 접근해본다면 누구나 만들고 기여해볼 수 있다고 생각한다.
이 글을 작성한 이유는 혼자 공부하다 보니 너무 어렵고, 이게 적합한 개선인지 이 부분에 대해 다른 사람들은 어떻게 생각하는지 궁금해졌기 때문이다.
누군가와 함께 특정 라이브러리의 구조를 뜯어보고, 토론하고, 분석하며 함께 기여하는 과정을 만들 수 있다면 얼마나 좋을까?
그래서 아래에 해당하면 연락한번 주셔도 좋겠습니다! 같이 공부하고 분석해보면 좋을것같다. 링크드인, jihoon7705@gmail.com 또는 댓글로 연락 주셔도 좋습니다!
- 오픈소스에 관심 있지만 어디서 시작할지 막막한 분
- 프론트엔드 직무에 밀접한 코어 라이브러리에 흥미 있는 분
- 구조와 설계에 대한 분석을 좋아하는 분
- AI를 활용한 오픈소스 학습법에 관심 있는 분