오픈소스 기여, 딸깍으로 해도 되나요?

AI 시대에 오픈소스 기여를 한다는 것

들어가며

안녕하세요, 오픈소스를 좋아하는 개발자 이승재입니다. 제가 쓴 코드와 만든 작업물이 누군가에게 영향을 준다는 게 좋고, 사실 그 재미 때문에 개발을 한다고 해도 과장이 아닌데요.

오늘은 그 재미를 처음 알게 된 이야기와 최근 받은 피드백, 그리고 그 피드백이 남긴 생각을 써보려 합니다.

오픈소스를 사랑하는 이유

첫 오픈소스 기여는 exercism이었습니다. 개발 공부를 처음 시작할 때 보고 배운 사이트라 언젠가 받은 만큼 돌려주고 싶었고, 2024년 11월 Java 트랙의 Parallel Letter Frequency 문제에 풀이 접근법을 정리한 PR #2863을 올렸습니다. 미숙한 영어에 처음 보는 기여 규칙까지, 여러 차례 피드백을 받고 나서야 병합되었습니다.

그 뒤 사이트에 들어가 보니 작성한 코드와 설명이 그대로 올라가 있었고, 컨트리뷰터 자리에는 제 이름이 박혀 있었습니다. 학생이던 당시엔 그 모습이 너무 기쁘고 벅차서 한동안 몇 번이고 다시 들어가 봤던 기억이 납니다.

이 경험을 살려 동아리 구름톤 유니브의 세종대×건국대 연합 테크톡에서 오픈소스 읽기 능력 기르기라는 주제로 발표하기도 했고, exercism의 기억이 여전히 남아 지금도 오픈소스에 기여하고 있습니다.

LLM 기여는 의미가 있는가?

오픈소스에 더 자주 기여하고 싶어서 한때는 사용하는 라이브러리와 프레임워크마다 에이전트와 스킬을 두고, 주기적으로 검사해 결함을 찾으면 PR을 올렸었습니다. 그 덕분에 실제로 많은 기여를 할 수 있었는데, 전자정부 표준프레임워크에서만 22건이 병합되었고, Spring Data JPA와 jjwt, LangChain4j에도 PR을 올렸습니다. 그런데 PR이 쌓일수록 어느 순간부터 왠지 모르게 찝찝했습니다.

그러던 중 Spring Boot에 낸 PR #51468에서 이런 피드백을 받았습니다.

Did you use AI to produce the description? Regardless, it's unnecessarily verbose for a one-line change to main code and includes lots of details that are already available elsewhere.wilkinsona · Spring Boot 메인테이너

PR 설명을 AI로 썼는지 묻고는, 어느 쪽이든 코드 한 줄짜리 변경치고 쓸데없이 길고 다른 곳에 이미 있는 내용까지 담았다는 지적이었습니다.

I use an LLM to look for bugs in projects I use, then check the bug is real and run the tests myself. … I still think it is good for open source, but I would like to know if you agree. Are LLM pull requests more tiring than helpful now? Or is it still worth it if it brings in more contributors?masiljangajji · 저

저는 평소 쓰는 프로젝트에서 LLM으로 버그를 찾아 고친다고 답하면서, 이런 기여가 오픈소스를 더 좋게 만든다고 기대한다고 덧붙였습니다. 그리고 LLM으로 만든 PR이 실질적으로 도움이 되는지, 기여 문턱이 낮아지면서 컨트리뷰터가 늘어난 지금을 메인테이너로서 어떻게 보는지 물었습니다.

답은 이랬습니다.

As we have limited resources, we much prefer dealing with bugs that are causing real-world problems. The value of fixing these is much higher than fixing something that may technically be a bug but isn't have a negative impact on anyone.wilkinsona · Spring Boot 메인테이너

자원이 한정되어 있으니 현실에서 문제를 일으키는 버그를 훨씬 선호하고, 기술적으로는 버그일지 몰라도 아무에게도 피해를 주지 않는 것을 고치는 일은 크게 의미가 없다는 겁니다.

LLM 자체를 탓하지는 않았고, 현실의 문제를 고쳤다면 무엇을 썼든 환영이며 잘 다듬기만 하면 LLM이 관여했는지 알 수도 없다고 했습니다. 다만 중요한 건 컨트리뷰터 수가 아니라 기여의 질이라며 이렇게 덧붙였습니다.

The best way to contribute to an open source project is to use it in your day-to-day work in real-world situations. You can then propose bug fixes and enhancements that make your day-to-day work easier, benefiting both you and the rest of the community.wilkinsona · Spring Boot 메인테이너

가장 좋은 기여 방법은 그 프로젝트를 실제 업무에서 매일 쓰는 것이고, 그러다 내 일을 편하게 해줄 수정과 개선을 제안하면 모두에게 이득이라는 이야기였습니다.

저 역시 LLM으로 문제를 찾고 코드를 개선하는 게 잘못이라고 생각하지 않습니다. LLM이 찾아 준 버그라도 그걸 판단하고 해결책을 도입하는 데에는 여전히 엔지니어링 디시전이 필요하니까요. 그래도 개운하지 않은 마음은 사라지지 않았습니다.

이력서를 위한 오픈소스

이 피드백을 받고 나서 곰곰이 생각했습니다. 코드를 개선하고 오픈소스를 파악하는 건 지금도 재밌고, PR이 병합되면 기쁘기도 합니다. 그런데 왜 이렇게 찝찝하고 답답했을까요?

고민 끝에 내린 결론은, 이력서를 채우기 위한 기여를 하고 있었다는 겁니다. 직접 맞닥뜨린 문제를 해결하는 게 아니라 이름을 올리고 싶어서 일부러 결함을 찾아 고치고 있었으니까요. 언제부턴가 오픈소스 기여를 해야만 하는 일처럼 느끼고 있었던 것 같습니다.

기여할 오픈소스도 Java·Spring 생태계 안에서만 골랐습니다. 애초에 Java·Spring 개발자라 이쪽 생태계가 훨씬 익숙하고 많이 써 본 것도 맞지만, 이력서에 임팩트가 있다는 점을 고려하지 않았다고는 못 하겠습니다.

결국 찝찝했던 건 LLM 때문이 아니라 목적 때문이었습니다. 어디에 기여하는지보다 왜 기여하는지가 훨씬 중요하다고 느꼈고, 진짜 문제를 해결하겠다고 생각했습니다.

나를 위한 오픈소스

실제로 겪은 문제를 고친 PR 두 개를 소개합니다. 첫 번째는 sqlglot입니다. 업무에서 Athena 기반 text-to-SQL 기능을 만들며 LLM이 생성한 쿼리를 실행 전에 sqlglot으로 검증하고 있었는데, Athena에서는 잘 도는 LIKE 'QA3\_%' ESCAPE '\' 같은 쿼리가 TokenError로 거부되었습니다. 확인해 보니 Athena dialect은 Hive와 Trino 규칙을 합쳐 토큰화한 뒤 어느 엔진으로 보낼지 정하는데, Hive에서는 \가 이스케이프 문자라 '\'가 닫히지 않은 문자열이 되어 Trino로 넘어가기도 전에 실패하고 있었습니다. 합친 규칙으로 토큰화에 실패하면 엔진별 규칙으로 다시 시도하도록 고친 PR #8629를 올렸고 당일 병합되었습니다.

두 번째는 Strands Agents SDK입니다. Bedrock에서 Claude로 LLM 서비스를 운영하다 에러 로그에서 ValidationException을 발견했는데, 모델이 stopReason은 tool_use로 주면서 정작 툴 호출 정보는 비워 보낸 경우였습니다. SDK는 tool_use를 보고 툴을 실행해 결과를 돌려주려 했지만, 실행할 툴이 없어 결과 대신 빈 user 메시지를 붙였고 다음 요청에서 에러가 났습니다. 툴 호출 정보가 없으면 턴을 끝내도록 고친 PR #5145를 올렸고 아직 리뷰를 기다리고 있습니다.

두 PR은 Java·Spring 생태계를 벗어난 첫 Python 기반 오픈소스 기여였습니다. LLM을 쓰는 방식은 이전과 같았지만, 직접 겪은 문제를 해결한다고 생각하니 찝찝함이 한결 줄어들었습니다.

의미 없는 기여는 없다

저는 어떤 형태의 기여든 의미가 있다고 봅니다. 의도가 어떻든, LLM을 썼든 결국 코드는 개선되니까요. 앞서 말했듯 문제를 찾는 건 '딸깍'으로 가능해도, 기존 코드와의 호환성을 지키며 메인테이너를 설득해 리뷰를 통과하는 일은 여전히 엔지니어의 몫이고요. 다만 메인테이너의 말처럼 실제로 쓰다가 만난 문제를 고칠 때 그 가치가 훨씬 크고, 의미도 더 와닿는 것 같습니다.

요즘은 오픈소스 기여 외에도 이력서에는 전혀 도움이 안 되는 것들을 만들고 있습니다. 대표적으로 바탕화면에서 함께 움직이는 치이카와 펫이 있는데요, 왕짱졸귀탱구리로 너무나 귀엽고 만드는 게 정말 재밌습니다.

'딸깍'의 시대가 오면서 많은 개발자분들이 커리어를 고민하고 있습니다. 개발하는 방식이 급격하게 바뀌는 만큼 방향을 잡기 힘들어하거나 흥미를 잃기도 하고, 시장은 차갑다 못해 얼어붙어 어떻게든 이력서 한 줄 쓰는 게 간절한 시기입니다. 저도 다르지 않아서, 처음 배울 때보다 재미가 덜한 건 사실입니다. 그럼에도 쓸모없는 것들을 개발해 보면 좋겠습니다. 다들 너무 여유 없이 각박하게 살아가는 것 같거든요. 왕짱귀여운 치이카와를 만들며 한숨 돌려 보는 건 어떨까요? AI 개척 시대의 모든 개발자분들을 응원합니다.

읽어주셔서 감사합니다.