[Quarkusio/Quarkus] 첫 오픈소스 기여

Quarkus란?

Quarkus는 Java 기반 클라우드 네이티브 애플리케이션을 빠르고 가볍게 만들기 위한 프레임워크입니다.

 

• 마이크로서비스
• 컨테이너/Kubernetes 환경
• 서버리스(Lambda 등)
• 빠른 스타트업과 리소스 효율이 중요한 서비스

위와 같은 서비스에서 주로 사용합니다.

 

저는 이 프레임워크를 사용해보진 않았지만, JVM 언어가 주력이기 때문에 첫 기여 리포지포리로 선정해보았습니다!!

제가 오픈소스 기여 리포지토리/이슈를 선정했을 때 기준을 공유하자면,

 

1. 주로 사용하는 언어로 고르려고 했습니다. AI가 코드를 작성해주더라도, 본인이 이해할 수 있어야 메인테이너분께 해를 안 끼칩니다!!

2. 메인테이너가 (이슈, PR이) 활발한 리포지토리를 선택하려 했습니다. 체계가 있으면 배울 점이 많을 것 같았습니다.

3. 도전하기 쉬운 issue를 고르려고 했습니다. 너무 어렵거나 큰 기능은 오래 걸리고 신경써야할 부분이 많습니다. 저는 그래서 데이터베이스 이름이 길어졌을 때 단축하는 정도의 쉬운 이슈를 선택했습니다!

 

이슈 분석

DB2는 데이터베이스 이름을 8자로 제한합니다. Quarkus Dev Services는 datasource 이름을 그대로 DB 이름으로 사용하는데, "additional" 같은 8자 초과 이름을 쓰면 컨테이너 기동이 실패하는 문제였습니다.

 

해결 과정

8자를 초과하는 이름을 단순히 잘라내면 서로 다른 datasource 이름이 같은 DB 이름으로 충돌할 수 있습니다. 그래서 prefix(4자) + SHA-224 해시(4자) 방식을 선택했습니다. 원래 이름의 앞 4글자로 가독성을 유지하면서, 해시 4자로 unique를 보장하는 구조입니다.

사용자가 db-name을 직접 설정한 경우에는 truncation 없이 그대로 사용하도록 했고, 자동 truncation이 발생하면 경고 로그를 남겨 사용자가 인지할 수 있게 했습니다.

 

PR 리뷰 과정

메인테이너(yrodiere)가 3차례 리뷰를 진행했습니다.

첫 번째 리뷰에서 해시 알고리즘과 로그 메시지, 테스트 방식에 대한 피드백을 받았습니다. 두 번째 리뷰에서는 테스트를 별도 파일에서 기존 integration-tests로 옮기는 제안을 받아 반영했습니다.

가장 까다로웠던 부분은 테스트였습니다. 처음에는 경고 로그를 검증하려 했으나, CI가 실패했습니다. 원인을 추적해보니 StartupLogCompressor가 Dev Services 기동 성공 시 로그를 의도적으로 숨기고 있었습니다. 이 내부 동작을 파악한 뒤, 로그 검증 대신 REST 엔드포인트 호출로 테스트 방식을 변경하여 CI를 통과했습니다.

 

첫 기여인데, 어떠셨나요?

우선 제가 염려한 바와 달리 메인테이너 분께서 친절하게 알려주시고 확인도 빨리 해주시는 편이였습니다.

좋은 제안도 해주셔서 배울 점이 있었습니다.

내 코드가 너무 불만족스러우면 어떡하지 하는 걱정도 있었는데 꽤 많은 부분이 그대로 반영되었습니다. 😉

 

처음 CI가 한 번 실패했는데, 빌드가 성공하면 로그를 숨기는 코드가 있어서 실패했었습니다.ㅎㅎ

메인테이너께서 REST 테스트로 변경을 제안해주셔서, 수정하고 CI 성공했습니다.

CI 성공 알림을 확인하고 PR에 들어가봤는데

Merged, thank you!

이렇게 쿨하게 남겨주시고 머지해주셨습니다. 😁

 

머지까지의 과정이 복잡할 것이라 걱정했는데, 메인테이너가 활발하게 활동하는 리포지토리임에도 불구하고

엄청 복잡한 과정없이 순조롭게 끝났습니다.

이번 일을 계기로 오픈소스 기여에 장벽이 허물어진 것 같습니다.

다음에는 꼭 제가 사용하는 라이브러리나 프레임워크의 오픈소스 기여도 도전해보고 싶네요!

 

참고: https://github.com/quarkusio/quarkus/pull/51913(Merge된 PR)

 

배운 점

1. 작은 이슈였지만, 얻을 게 많았습니다.
- "8글자 제한 처리" 단순해 보였는데
- 해시 알고리즘 선택, 테스트 방법, 로그 메시지 문구까지 신경 쓸 게 많았습니다.

- 특히 로직은 괜찮았는데, 테스트가 처음 기여해보니 생소하더라고요!

2. 리뷰어 피드백을 정확히 이해하고 커밋하면 좋습니다
- 이해가 안 갈 땐, 추측하지 말고 질문하는 편이 좋습니다.

3. 프레임워크 내부 이해가 중요합니다.
- StartupLogCompressor가 로그 숨기는 거 몰랐으면 계속 헤맸을 것입니다.
- 테스트 실패 원인 찾으려면 내부 동작 파악이 필요합니다.

- Claude Code같은 AI 툴을 잘 활용하면 좋아요!