jimin-fundamental

첫 오픈소스 컨트리뷰션 도전: 이슈 선정부터 PR 승인까지

쟈민 — Sun, 8 Mar 2026 22:55:55 +0900

회사에 다니니까 개인 개발할 시간이 부족해지는데

공부는 더 하고 싶다고 생각이 들던 찰나

오픈소스 컨트리뷰션을 해보면 어떨까 생각이 들었다

- 새로운 라이브러리 탐색하고 익히면서 나중에 내 프로젝트나 사내 프로젝트할 때에도 좋은 라이브러리 도입할 수 있게 됨

- 다른 팀의 코드베이스 탐색하고 파악하는 경험 쌓기

- 좋은 경력

이와 같은 이유로 다짐했다!

Contribute할 프로젝트 및 이슈 고르기

Contribute을 하는 방법은 마음에 드는 프로젝트를 찾고, 그 프로젝트 내의 issue 중 내가 해결할 수 있을만 한 걸 찾아서

해결 후 커밋해서 PR을 날리는 게 일반적이다.

근데 어떤 프로젝트를 할지가 제일 고민이 됐다......!

처음에는 spring boot나 java 라이브러리 같은 유명한 프로젝트를 해보려고 했는데

issue들을 보니까 'teams-only'(개인 기여자가 아니라 스프링부트를 만든 팀이 해결해야하는 이슈)가 대부분이어서

처음 contribute하는 내가 기여할 수 있는 프로젝트를 찾아 나섰다.

이때 참고한 게 이 블로그(https://dev-hiro.tistory.com/23)의 팁이었는데, 깃허브의 고급검색을 활용하면 된다는 것!

깃허브에서 spring을 검색한 후 왼쪽 nav바 하단에 Advanced search를 누른 다음

language: 선택한 언어로 개발
팔로워의 수나 스타 수: ex) > 5000
라벨: ex) "good first issue"

과 같이 고급 검색을 이용하면 기여할만 한 프로젝트 및 이슈를 찾기가 매우 쉬워진다!

이슈와 프로젝트 분석하기

내가 기여하고자 하는 프로젝트는 'Dependency-Check'(https://github.com/dependency-check/DependencyCheck/issues/8356)이다.

무려 7.5k의 repo이다!

이 프로젝트는 소프트웨어 구성 분석(SCA, Software Composition Analysis) 도구로, 프로젝트에서 사용하는 외부 라이브러리(의존성) 내에 공개된 보안 취약점(CVE)이 포함되어 있는지 탐지하는 역할을 한다. Java, .NET, Ruby, Node.js 등 다양한 기술 스택을 지원하며, 각 라이브러리의 메타데이터를 수집하여 미국 국가 취약점 데이터베이스(NVD)와 대조함으로써 개발자가 사전에 보안 위험을 인지하고 조치할 수 있도록 돕는 오픈소스 보안 엔진이다.

그중에서 해결하고자 하는 이슈는 'Narrow down VersionFilterAnalyzer scope (#8356)'이다.

(https://github.com/dependency-check/DependencyCheck/issues/8356)

이 이슈는 VersionFilterAnalyzer 클래스가 설계된 의도와 다르게 너무 넓은 책임을 가지고 있는 문제를 말하는 이슈이다.

현재 VersionFilterAnalyzer의 JavaDoc에는 이 클래스가 JAR 형식에만 분석을 수행해야 한다고 하지만, 실제 구현상으로는 모든 타입의 의존성 파일을 대상으로 분석 로직을 실행하고 있다.

이는 불필요한 연산 자원을 낭비할 뿐만 아니라, 특정 파일 타입(JAR)을 위해 설계된 로직이 다른 타입의 파일에 적용되어 예기치 않은 부작용을 낳을 수 있다.

이 문제점을 해결하기 위해서는 다음과 같은 변경사항이 필요하다.

상속 구조의 변경: 현재 AbstractAnalyzer를 따르고 있는 VersionFilterAnalyzer가 AbstractFileTypeAnalyzer를 상속받도록 수정해야 한다.
분석 대상 제한: 상속받은 AbstractFileTypeAnalyzer의 기능을 활용하여, 분석 프로세스 진입 전 대상 파일이 JAR 확장자인지 확인하는 필터링 로직을 적용한다.

AbstractAnalyzer 과 AbstractFileTypeAnalyzer 의 차이는 다음과 같다.

- AbstractAnalyzer: 가장 기본적인 추상 클래스로, 파일의 타입이나 확장자에 상관없이 모든 리소스에 대해 분석 로직을 실행할 수 있는 범용적인 구조다. 현재 상태는 VersionFilterAnalyzer가 이 클래스를 상속받고 있어, 파이썬이나 자바스크립트 파일까지 불필요하게 분석 프로세스에 포함되고 있다.

- AbstractFileTypeAnalyzer: AbstractAnalyzer를 한 번 더 확장한 클래스로, 파일 확장자 기반의 자동 필터링 기능이 내장되어 있다. 이 클래스를 상속받으면 getSupportedExtensions()라는 메서드를 오버라이드해야 한다. 여기에 "jar"라고 명시해두면, 엔진이 파일을 스캔할 때 확장자가 일치하지 않는 파일은 아예 이 분석기를 거치지 않기 때문에 프로세스가 정확해진다.

Assign 받기

이슈 해결 전 assign 요청을 하는 모습

오픈소스 생태계에서는 작업 중복 방지 등을 이유로 이슈 해결 전 assign을 받는 문화가 있다.

따라서 나도 이렇게 assign을 요청했다.

assign을 요청한 후 issue 발행인의 댓글과 함께 assign을 받으면 작업을 시작하면 된다.

작업하기

오픈소스 기여는 일반적인 사내 협업과는 조금 다른 절차가 있으니 실수를 줄이기 위해 단계를 나눠 정리해봤다.

1. Fork & Clone: 내 IDE로 가져오기

오픈소스 원본 저장소(Upstream)에는 내 마음대로 커밋을 올릴 권한이 없다. 그래서 먼저 내 계정으로 통째로 복사해오는 과정이 필요하다.

GitHub 페이지 우측 상단의 [Fork] 버튼을 눌러 내 계정으로 가져온다.

그다음, 내 컴퓨터로 소스코드를 내려받는다. (Clone)

git clone https://github.com/내-계정-ID/DependencyCheck.git
cd DependencyCheck

2. Upstream 설정: 원본과 동기화하기

내가 작업하는 동안에도 원본 프로젝트에는 새로운 코드들이 계속 올라온다. 내 코드가 옛날 버전이 되지 않도록 원본 저장소를 연결해둔다.

git remote add upstream https://github.com/dependency-check/DependencyCheck.git
git fetch upstream
# 항상 최신 상태의 main에서 작업을 시작하는 게 국룰!

3. 이슈 전용 branch 생성

main 브랜치에서 바로 수정하는 건 위험하다. 이슈 번호나 작업 내용을 담은 새 브랜치를 만들어서 깔끔하게 관리하자.

어떤 브랜치 이름으로 만들지는 해당 프로젝트에 기존 브랜치 이름들을 참고하면 된다.

git checkout -b fix/8356-narrow-version-filter-scope

4. 코드 수정하기

드디어 인텔리제이를 켜고 코드를 수정할 시간! 내가 분석한 대로 extends를 변경하고 로직을 다듬는다.

- 구조 변경: 명세에 맞는 상속 구조 선택

기존 VersionFilterAnalyzer는 모든 파일을 대상으로 분석을 시도하는 AbstractAnalyzer를 상속받고 있었다. 이를 특정 확장자만 선별적으로 처리할 수 있는 AbstractFileTypeAnalyzer로 변경했다.

// 부모 클래스를 변경하여 파일 타입 기반 분석기로 정의
public class VersionFilterAnalyzer extends AbstractFileTypeAnalyzer {

 	// JAR 필터
    private static final FileFilter FILTER = FileFilterBuilder.newInstance().addExtensions("jar").build();

    // JAR 파일만 허용하는 필터 적용
    @Override
    protected FileFilter getFileFilter() {
        return FILTER;
    }

    // 구조 변경에 따른 초기화 메서드 구현
    @Override
    public void prepareFileTypeAnalyzer(Engine engine) throws InitializationException {
        // 별도 초기화 로직 없음
    }
}

실제 주석은 영어로 코드 베이스에 맞게 작성해야 한다!

- 검증: 테스트 코드로 로직 증명

수정한 로직이 의도대로 동작하는지 확인하기 위해 테스트 케이스를 추가했다. .jar 파일은 정상적으로 수용하고, 그 외의 확장자(.war, .exe, pom.xml 등)는 제외하는지 검증했다.

@Test
void testAcceptOnlyJarFiles() {
    VersionFilterAnalyzer instance = new VersionFilterAnalyzer();
    instance.initialize(getSettings());
    
    // JAR 파일은 통과
    assertTrue(instance.accept(new File("example-1.2.3.jar")));
    
    // 그 외 확장자는 차단 (설계 의도 확인)
    assertFalse(instance.accept(new File("example-1.2.3.war")));
    assertFalse(instance.accept(new File("example-1.2.3.exe")));
    assertFalse(instance.accept(new File("pom.xml")));
}

테스트까지 완료했으면 그 다음 step으로 넘어간다.

작업이 완료되었으면?

1. Commit & Push: 명확한 메시지 남기기

커밋 메시지는 해당 프로젝트의 다른 커밋들을 보고 이와 형식을 맞춰서 작성한다.

내 프로젝트는 contribution 가이드라인이 있어서 그걸 따라서 작성했다.

커밋 관련 규칙은 다음과 같았다. - https://www.conventionalcommits.org/en/v1.0.0/

여기서 말하는 feat과 fix의 차이점은

feat: 새로운 기능을 codebase에 추가하는 것
fix: codebase의 버그(의도와 다르게 동작하는 것)을 수정하는 것

git add .
git commit -m "fix: narrow down VersionFilterAnalyzer scope to JAR files"
git push origin fix/8356-narrow-version-filter-scope

2. Pull Request (PR) 날리기

내 GitHub 저장소로 가보면 상단에 [Compare & pull request] 버튼이 떠 있을 것이다.

보통 PR 메세지는 아래의 내용을 포함하는데, 이것 또한 해당 프로젝트의 컨벤션을 확인하고 같은 형식으로 진행하면 된다.

What: 무엇을 고쳤는지 (상속 구조 변경 등)
Why: 왜 고쳤는지 (JavaDoc과 실제 코드의 불일치 해결 등)
How: 어떻게 테스트했는지 이 내용들을 정성스럽게 적어서 PR을 날리면 끝!

나의 프로젝트의 PR 형식은 정해져있었는데 이는 다음과 같았다.

## Description of Change

<!--
Please add a description of the proposed change
-->

## Related issues

<!--
e.g 
- fixes #xxxx
- relates to #xxxx
-->

## Have test cases been added to cover the new functionality?

*yes/no*

이제 다른 분들의 리뷰를 기다리기만 하면 된다!!

뿌듯하다ㅎㅎ

TIL: 무한 피어리뷰의 늪에서 깨달은 “이해하기 쉬운 커밋”의 조건

쟈민 — Sat, 6 Dec 2025 18:41:33 +0900

처음으로 회사에서 제대로 된 프로젝트를 Git에 올리기 시작하면서, 나는 말 그대로 무한 피어리뷰의 늪에 빠졌다.

혼자 개발하거나 해커톤에서 빠르게 구현할 때는 서로의 커밋을 꼼꼼히 보거나 코드리뷰를 하는 경우가 거의 없다 보니, 나의 커밋 단위는 늘 크게 유지됐다.
기능 A를 어느 정도 완성하면, 다음 기능 B로 넘어가기 전에 일종의 백업용으로 커밋을 했기 때문이다.
즉, 나의 커밋은 협업을 위한 것이 아니라, 그저 나 자신을 위한 기록이었다.

협업 속 Git은 철저히 “남을 위한 도구”

하지만 회사에서의 커밋은 완전히 다르다.
커밋은 단순 백업을 넘어서 협업의 기반이자, 다른 개발자가 내 코드를 이해하도록 돕는 중요한 소통 수단이 된다.

동료들은 내 코드를 처음 본다.
심지어 프로젝트 전체를 clone하고 분석한 뒤 커밋을 읽는 것도 아니다.

그들은 커밋 메시지 제목 → 본문 → 코드 변경 순으로 읽으며 단서를 찾아간다.
즉, 커밋은 그들에게 있어 내 코드를 이해하기 위한 유일한 가이드라인이다.

그래서 나는 피어리뷰 늪에 빠지면서 깨달았다.

‘아… 지금까지의 내 커밋 방식은 협업에서 완전히 탈락이다.’

그렇다면 “이해하기 쉬운 커밋”은 무엇일까?

그걸 정의하려면 오히려 반대로 생각하면 쉽다.
상대가 절대 이해할 수 없는 커밋을 떠올려보면 된다.

이해하기 어려운 커밋의 3가지 특징

한 커밋에 너무 많은 것이 들어 있다
- 서로 다른 기능, 서로 다른 목적의 수정이 한데 섞여 있다.
- 읽는 사람은 이 커밋이 “무엇을 위한 것인지” 알기 어렵다.
커밋 간 순서가 뒤죽박죽이다
- A 작업 중간에 갑자기 생각난 B를 넣고, 그 뒤에 C가 끼어들고…
- 흐름이 없으니 읽는 사람은 작성자의 사고 과정을 추적하기 어렵다.
커밋 메시지가 나만 알아보게 쓰여 있다
- “fix bug”, “temp”, “작업함”, “update”…
- 메시지가 ‘왜 이런 커밋이 필요한지’ 설명하지 않는다.

돌아보면, 솔직히 말해 과거의 내 커밋은 이 모든 항목을 완벽히 충족하고 있었다…

이해하기 쉬운 커밋을 만드는 방법

그렇다면 하나씩 고치면 된다.

1. 커밋의 단위는 ‘작업의 의미’로 나눈다

A라는 기능을 구현하기 위해
a → b → c 순서의 작업이 필요하다고 해보자.

개발자인 나는 A라는 목적과 세부 단계들을 모두 알고 있지만,
이 커밋을 처음 보는 사람은 A가 무엇인지조차 모른다.

그래서 각 커밋에는 단 하나의 작업(a)만 들어가야 한다.

“공통 Repository 인터페이스 추가”
“MongoDB Repository가 인터페이스 구현하도록 수정”
“DynamoDB 전용 Repository 추가”

이렇게 나누면 커밋 하나를 봐도 “이 커밋은 ○○를 위한 것”이라는 의미 전달이 명확해진다.

반면 a+b+c를 한 커밋에 넣으면
이유도 흐름도 목적도 전부 섞여버린다.

2. 커밋 순서 = 내가 실제로 코드를 작성한 순서

리뷰어는 커밋을 시간 순서대로 읽는다.
그 흐름은 곧 내 사고 과정의 흐름이 된다.

그런데 작업 중간에 갑자기 “아 맞다 이것도 고쳐야지” 하며
d 같은 다른 작업을 끼워 넣으면?

리뷰어는 자연스럽게 이 커밋이 왜 여기서 튀어나오는지 헷갈리게 된다.

따라서

생각난 수정이라도 작업을 끼워넣지 않고 별도 커밋으로 분리하는 것
(필요하다면 “chore: 누락된 validation 추가”처럼 명확하게)

이게 리뷰 난이도를 크게 낮춰준다.

3. 커밋 메시지는 “why / what / how” 구조로 쓴다

커밋 메세지는 내 커밋을 요약하는 부분이자, 상대가 코드를 읽기 전 읽게되는 부분이다.

따라서 아래와 같은 정보를 넣어주면 이해하기 쉽다.

why – 왜 이 커밋이 필요한가?

어떤 문제를 해결하는가
어떤 목적을 달성하는가
이 commit의 Goal이 무엇인가.

what – 목적을 위해 무엇을 했는가?

어떤 변화를 만들었는지
어떤 파일, 어떤 로직이 수정 혹은 추가되었는지

how – 기술적으로 어떻게 구현했는가?

어떤 방식, 어떤 패턴, 어떤 라이브러리를 사용했는지
특별한 이유가 있는 설계 선택이라면 반드시 여기에 포함

how는 상황에 따라 생략해도 된다.
단, 리뷰어가 “왜 이런 구현을 했지?” 하고 궁금할 만한 부분이 있다면 적어주는 것이 좋다.

실제 예시로 보는 좋은 커밋의 구조

상황:
기존 프로젝트는 MongoDB만 사용하도록 구조가 고정돼 있었고,
DB 전환이 어려운 문제가 있었다.
이를 해결하기 위해 브릿지 패턴을 도입해 구조를 유연하게 만들기로 했다.

그렇다면 커밋의 “why”는 다음과 같다.

특정 DB에 대한 종속성을 제거하고 쉽게 전환 가능한 구조를 만들기 위해

그리고 작업은 다음과 같이 나뉜다.

공통 Repository 인터페이스 정의
기존 MongoDB Repository가 인터페이스를 구현하도록 변경
DynamoDB Repository 추가 후 공통 인터페이스 구현

이 각각이 하나의 커밋이 된다. 이 커밋들의 why는 모두 동일하겠다.

그리고 “how”에는

브릿지 패턴을 어떻게 적용했는지
어떤 인터페이스가 어떤 메서드를 갖는지
기존 구조와 어떻게 연결되는지

등의 내용을 적어준다.

정리하자면 핵심은 다음과 같다.

리뷰어가 커밋 메시지만 읽어도 “아 이런 코드가 나오겠구나” 하고 자연스럽게 예측 및 이해되도록 하는 것.

이렇게 커밋을 작성하면 다음과 같은 효과가 있다.

피어리뷰 시간이 줄어든다
동료들의 내가 작성한 코드에 대한 이해도가 올라간다
나 자신도 개발 단계·흐름을 더 명확하게 정리하면서 코드를 짤 수 있다
나중에 과거 코드를 다시 볼 때도 훨씬 빠르게 복기할 수 있다

커밋은 단순히 코드를 저장하는 도구가 아니다.
나의 사고 과정과 의도를 녹여, 미래의 나와 동료에게 ‘이해’를 전달하는 도구이다.

4개월차 신입 개발자 회고

쟈민 — Mon, 10 Nov 2025 15:33:28 +0900

타임라인

2025.06.30 인턴 백엔드 개발자로 IT 스타트업 회사에 입사
2025.09.30 정규직으로 전환
이후 실제로 실무를 한지 한달이 조금 넘었다.

첫 회사이자, 첫 실무를 하면서 배운 것들이 많아 이를 기록해보려고 한다.

회사 후기

굉장히 자유로운 분위기의 전형적인 IT 스타트업인 거 같다.
이 회사가 첫 회사라 다른 회사와의 비교가 불가능하지만, 아래와 같은 장점들이 있었다.

1. 복지가 정말 좋다.
회사의 여러 복지 중에서 내가 가장 좋아하는 것은 '유연근무제'이다.
8~12시 사이에 내가 원하는 때에 회사에 가서 8시간 ~ 9시간을 채우고 퇴근하면 되는데,
아침이나 저녁 일정을 자유롭게 조절할 수 있는 점이 정말 좋다.
최근에는 9시에 가서 저녁을 먹고 7시까지 일한 후 헬스를 가는 루틴으로 살고 있다.

2. 배울 수 있는 분위기이다.
실무를 할 때, 단순히 일이 주어지고 혼자서 해내야하는 분위기가 아니라, 관련 개념에 대해서 먼저 발표를 직접 하거나 다른 사람들의 발표를 듣고, 이를 바탕으로 실무를 한다.
예를 들어, k8s로 환경 구축을 해야하는 미션을 받았다고 해보자. 그러면 'k8s로 환경 변경해!'가 아니라,
k8s에 대해 공부하고 이에 대해 발표해라 -> 발표를 팀장님이 들으시고, ~ 부분에 대해서 이해를 못한 거 같다. 더 보완해서 다시 발표해라 -> 이제 우리 서버를 다 k8s로 돌려라.
이런 식으로 진행이 된다.

처음에는 실무에 바로 투입되고 싶은 마음이 컸기 때문에 이러한 특징이 마냥 달갑지는 않았는데,

원래의 나의 잘못된 습관이었던 '완벽히 이해하지 않고 바로 구현하기'를 고치는 데 많은 도움이 되고 있다.

공식 문서를 뜯어보고, 완전히 이해하기 위해 노력하면서 내가 성장하는 게 느껴진다.

3. 다양한 분야를 접할 수 있다.

이 부분은 장점이자 단점일 수 있는데, 단순 서버 개발자에 한정되지 않고 다양한 업무를 도전해볼 수 있다.

서버 개발뿐 아니라, 인프라 엔지니어의 역할은 물론, 최근에는 html 개발까지 하고 있다. 또한, 다음 주에는 VC의 역할로 부산 지스타로 출장을 나간다.

누군가에게는 단점일 수 있지만, 나의 경우에는 프론트엔드에도 관심이 있었고, 실무에서 다양한 업무를 직접 해보면서 나에게 뭐가 맞는지 찾고 싶은 마음이 컸었다.

따라서, 일반 백엔드 개발자라면 할 수 없는 것들(출장, html 개발 등)을 하면서 내 식견을 넓힐 수 있는 거 같아 좋다.

지금까지 한 것

지금까지 배운 것 중에 기록하고 싶은 소재는 다음과 같다.

OOP와 SOLID
발표할 때(커뮤니케이션 할 때) 지켜야 하는 것들
Docker
K8S
MongoDB
PostgreSQL
DeepLink(Applink, Universal Link, Custom URL scheme)
nvidia orin driver 연결 방법
(곧 있을 출장 후기)

앞으로 최대한 꾸준히 배운 것들을 정리하면서 성장하는 모습을 기록하고, 또 성장하고 싶다.