개나소나 오픈소스 원리를 이해할 수 있는 Code Wiki

미국 시각으로 올 11월 13일 Code Wiki를 출시했다.

간단히 말하면, AI를 통해 오픈소스 프로젝트의 전체적인 구조를 AI가 파악해서 하나의 "지식 베이스"를 구축한 다음, 이를 기반으로 Gemini 와 대화해 가면서 원리를 이해하고, 이를 기반으로 NotebookLM이 제공하는 팟캐스트 및 영상 생성 등 다양한 컨텐츠를 손쉽게 통합하여 오픈소스를 더 쉽게 기여할 수 있는 구글의 "착한"(?) 프로젝트이다.

뭐? Don't be evil 이 이젠 옛말이라고? 어 인정.

아무튼, 개발자에게 이 좋은 프로젝트를 통해 더 손쉽게 개발자 인터뷰를 대비할 수 있을 것이고, 그리고 Gemini CLI 를 통해 현재는 오픈소스 프로젝트 위주로 지원하는 범위를 사설 프로젝트에서도 사용 가능하도록 해준다니 내부 프로젝트 문서화에도 도움이 될 것으로 기대한다.

자, 그럼 이게 왜 너희들에게 좋은지, 내가 여태 소스 쳐봐가면서 개고생했는데 그럴 필요 없는지 설명 들어간다 아가리 벌려라.

첫 인상

한국에서 자바 스프링이 백엔드의 업계 표준이듯, 대한민국에서 프론트엔드 업계 표준(물론 외국도 업계 표준이나 다름없긴 하지만)인 react 프로젝트를 통해 첫인상부터 살펴보도록 하겠다.

그렇다. react 공식 문서와 사뭇 다르고, 그리고 챕터도 뭔가 낯설 것이다.
이녀석은 프로젝트의 특징을 Gemini 가 분석해서 내준 결과라고 보면 되는 것이다.

이렇게 다이어그램으로 구조 분석도 해 줘서 예를 들어 리액트가 테스트를 진행할 때 어떤 방식으로 개발되었는지도 분석해준다.

채팅

하지만 너희들은 이걸 원하겠지.

세줄요약.

나한테 시키지 말고 AI한테 시켜라.

됐냐? 아무튼, 이렇게 너가 react 프로젝트에서 알고 싶었던 것들, 대체 이게 어떻게 돌아가는지 등등, 궁금한 사항들을 채팅을 통해 답변을 얻을 수 있다. Gemini 는 출처에 집중하여 답변에 특화되어 있다 보니, NotebookLM 처럼 출처에 집중한 답변을 해서 어찌보면 집중력이 뛰어나고, 어찌보면 다른 지식과 결합을 거부해서 답답하게 느낄 수 있을 것이다.

그럼 AI한테 원리를 물어보도록 하자.

use 함수는 공식 문서에서 Hook 이 아닌 API에 속해 있다.

useState 처럼 훅 함수일 줄 알았건만, 심지어 같은 일회성 훅인 useId 조차 훅 함수인데 얜 왜 API로 분류했느냐?

원리를 분석하여 잼민이(Gemini)에게 물어보도록 하자.

이렇게 Code wiki의 채팅은 출처에 집중하여 답변을 처리해 준다.
Dispatcher 라는 생소한 객체가 나오고, 전문 용어가 막 튀어나오는 모습이 우리가 알던 AI 답변과는 사뭇 다르다.
그렇다면 다른 AI는 어떨까?

ChatGPT

Grok

Claude

아오 시발 그놈의 "좋은 질문이에요"...

Code Wiki 와 일반 LLM 차이점

자, 여기서 ChatGPT, Grok, Claude 등의 범용 LLM에서 답변이 스타일만 다를 뿐, 맥락은 비슷하다는 것을 눈치챘는가?
대충 정리하면

• use 는 useState 처럼 use 훅 조건에 부합하지 않는다.
• 조건에 부합하지 않는 대신 더 강력하고 저수준의 작동이 가능해졌다.
• 그리고 "이렇게 구분을 명확히 해 개발자들의 혼동을 줄였다" 라는 확신에 찬 멘트까지.

이에 반해 Code Wiki 는 코드 중심으로, 코드 설계에 입각하여 설명해 줬다는 차이점을 알 수 있다.
이렇게 하면, react 에서 훅이 어떻게 돌아가는지, 그리고 react 개발자들이 가장 혼란스러워하는 "hook은 작동 방식이 비동기지만 왜 비동기로 제공하지 않는가" 문제를 다른 방식으로 접근할 수 있을 것이다.

결론

어? 벌써 끝이야? ㅇㅇ 끝이야. 왜냐면 현재 제공하는 Code Wiki는 이게 다거든.

1. 오픈소스 프로젝트를 지정하면, 지정한 오픈소스의 전체적인 구조와 코드를 파악하고,
2. 파악한 자원들을 지식 베이스화하여 이를 통해 선택적으로 프리젠테이션 및 팟캐스트, 다이어그램 등을 생성
3. 그리고 이 지식 베이스를 기반으로 채팅할 수 있는 환경 조성

사실 NotebookLM 써본 사람이라면 새삼스러울 것 없는 기능이겠지만, 처음 접근한 사람들은 이 별거 아닌것 처럼 보이는게 장난 아닌 파급력이 일어날 것이라는 걸 내가 이미 설명했을 것이다.

그리고 Gemini CLI 통해 사내 프로젝트도 개념원리 문서화가 가능해지니, 인수인계 문서는 AI 선에서 컷트할 가능성이 높아진 셈이다. 아직 제공은 안 하지만...

하지만 역으로 말하면, 기존 개발자들은 더 쉽게 개념 원리를 이해하여 더 빡센 인터뷰가 여러분을 기다릴 것이며, 구직 중인 개발자들은 이를 대응하기 위해 이렇게 AI를 활용하여 많은 준비를 거듭해야 할 날이 올 지도 모른다.

뭐? 앞으로 영원히 개발자 필요없어진다고? 연초부터 개발자 필요없다고 천명한 MS, 구글, 아마존... 그래서 효과 봤대?
봤냐고? 있으면 근거 자료 가져와 봐. 한국은 준비할 수도 없는데 AI 에 돈쳐바르는 미국이라고 성공한 사례? 없어.

난 반박 자료 준비했는데, 내가 준비한 반박 자료는 이렇다. AI에 돈 존나게 쳐붓고 있지만 거시적인 성과는 없다는 점을.

• AI가 일자리 대체하는게 아니라 비용을 소비할 뿐
• AI 초안 프로젝트 95%가 실패하는 이유와 이를 피하는 법
• 2025년 IT업계의 대량 해고는 AI 때문이 아니다! (어느 지인분이 공유해주신 좋은 반박자료 감사합니다.)

MIT, 맥킨지 등의 신뢰 가능한 기관 및 언론에서도 묻지마 AI 투자와 고용 감소를 우려하고 있는데 뭐?

자, 아무튼, 내가 너희들에게 이렇게 희망고문(?)이라도 시켜줬는데 개발자 할 거야 말 거야?
난 강요 안한다. 선택에 달렸다. 대신, 너희들에게 과제가 주어졌다.
AI를 통해 경력있는 신입이 될 것이냐, 아니면 그만 둘 것이냐.

경력있는 신입은 이제 더 이상 어색한 표현이 아닌 시대라는 점만 알아두거라.

끗.