ebson

어디를 고칠지 정하기까지처음부터 이 버그를 노리고 들어간 것은 아니었습니다. ShardingSphere는 JDBC 드라이버와 데이터베이스 프록시를 함께 제공하는 큰 프로젝트입니다. 프록시 모드는 여러 언어의 클라이언트가 실제 데이터베이스인 것처럼 접속하도록 각 데이터베이스의 와이어 프로토콜을 직접 구현합니다. 그중 PostgreSQL 방언 쪽 코드를 읽다 보니, 확장 쿼리(extended query)에서 바인드되는 파라미터를 해석하는 디코더가 눈에 들어왔습니다. PostgreSQL의 확장 프로토콜에서는 클라이언트가 Bind 메시지로 파라미터 값을 넘길 때, 각 값을 텍스트 포맷 또는 바이너리 포맷으로 보냅니다. 배열 타입이라면 텍스트 포맷의 경우 {1,2,3}이나 {a,b,c} 같은 중괄호 리터럴로 전달..

작은 수정 하나를 고르기까지오픈소스에 기여해 보고 싶다는 생각은 오래전부터 있었지만, 막상 apache/shardingsphere 같은 큰 저장소 앞에 서면 어디서부터 손을 대야 할지 막막했습니다. 그래서 처음에는 거창한 기능을 떠올리기보다, 이미 잘 돌아가는 코드 안에서 조건 하나가 어긋난 자리를 찾아보기로 했습니다. 저장소의 모든 모듈을 한 줄씩 훑어본 것은 아닙니다. 제가 실무에서 Oracle을 다뤄 본 경험이 있어서, 데이터베이스 방언(dialect)을 처리하는 database/connector/dialect 쪽부터 눈에 익은 코드를 따라 읽어 내려갔습니다. 그러다 OracleMetaDataLoader에서 데이터베이스 버전을 확인하는 두 메서드에 시선이 멈췄습니다. Oracle은 버전에 따라 ID..

작은 로그 한 줄에서 시작한 기여오픈소스에 처음 기여할 때 가장 어려운 부분은 코드를 고치는 일이 아니라, 고칠 만한 지점을 찾는 일이라고 생각합니다. 저장소를 읽다 보면 로그 문구 하나, 조건 하나가 미묘하게 어긋난 자리를 마주치게 됩니다. 이번에 Apache ShardingSphere에 올려 머지된 제 변경도 그런 자리에서 시작했습니다. agent/core 모듈의 바이트코드 계측 어드바이저가 오류를 기록할 때, 정작 어느 클래스에서 문제가 났는지를 로그에 잘못 남기고 있던 부분을 고친 작업입니다. PR은 아래 링크에서 확인할 수 있습니다. https://github.com/apache/shardingsphere/pull/39077ShardingSphere의 Agent는 애플리케이션 코드를 직접 수정하..

통과하는 테스트가 늘 안심할 만한 것은 아닙니다오픈소스 기여를 하려고 마음먹고 저장소를 열면, 대개는 "고칠 만한 버그"를 찾으려고 합니다. 저도 처음에는 그랬습니다. 그런데 Jenkins처럼 오래 굴러온 프로젝트에서 눈에 띄는 동작 버그를 찾기란 쉽지 않았습니다. 이미 많은 사람이 오래 들여다본 코드이기 때문입니다. 방향을 조금 틀어 본 곳이 test 모듈이었습니다. Jenkins 저장소의 test 모듈에는 src/main이 없습니다. 오직 JenkinsRule 기반의 기능 테스트만 들어 있는 모듈입니다. 그래서 이 모듈에서 찾을 수 있는 결함은 "실행하면 실패하는 코드"가 아니라 다른 종류입니다. 테스트가 통과하지만, 그 통과가 실제로는 아무것도 보장하지 않는 경우입니다. 이런 결함은 CI에서 절대로..

좁은 화면에서 브레드크럼이 비어 있었습니다Jenkins 화면 위쪽에는 지금 보고 있는 위치를 알려 주는 브레드크럼 바가 있습니다. 폴더 안에 폴더가 있고 그 안에 잡이 있고 다시 빌드 번호가 붙는 구조라, 경로가 조금만 깊어져도 브레드크럼은 화면 폭을 쉽게 넘깁니다. Jenkins는 이럴 때 앞쪽 항목들을 숨기고 점 세 개짜리 오버플로 버튼을 만들어, 숨긴 항목들을 드롭다운으로 보여 줍니다. 제 화면에서는 그 드롭다운이 비어 있었습니다. 버튼은 정상적으로 나타나고 클릭하면 팝업 상자도 뜨는데, 그 안에 아무 항목도 없었습니다. 숨겨진 브레드크럼으로 돌아갈 방법이 화면 안에 남아 있지 않다는 뜻이었습니다. 브라우저 콘솔을 열어 두고 버튼을 다시 눌러 보니 TypeError: Cannot read prope..

들어가며오픈소스에 기여한다는 말은 오랫동안 저에게 한 단계 멀리 있는 일이었습니다. 큰 프로젝트의 코드는 제가 끼어들 틈이 없을 만큼 잘 정돈되어 있을 것 같았고, 설령 고칠 곳을 찾더라도 메인테이너를 설득할 만한 변경을 만들 자신이 없었습니다. 그런 막연한 거리감을 줄여 보려고 평소에 쓰던 도구의 저장소부터 천천히 들여다보기 시작했습니다. 그 도구 중 하나가 Jenkins였습니다. 이 글은 Jenkins 코어에 올린 작은 변경 한 건(#26954)이 머지되기까지의 기록입니다. 바뀐 코드는 배열에 항목 두 개를 더하고 그 위 Javadoc 한 줄을 맞춘 것이 전부입니다. 그런데 그 두 줄에 닿기까지, 그리고 그 두 줄을 머지시키기까지 배운 것이 적지 않았습니다. 변경의 크기와 배움의 크기가 비례하지 않는..

GCS 파일 상태가 0과 null을 돌려주고 있었습니다Apache Paimon은 여러 클라우드 스토리지를 Hadoop 호환 파일시스템으로 감싸 다룹니다. 각 스토리지 구현은 파일 상태를 Paimon의 FileStatus 형태로 감싸 내보내는데, 구글 클라우드 스토리지용인 paimon-gs-impl에서 이 감싸는 과정에 빈틈이 있었습니다. 이번 글에서는 그것을 메운 apache/paimon#8559를 이야기하려 합니다. 문제는 HadoopCompliantFileIO 안의 HadoopFileStatus에 있었습니다. 이 클래스는 Hadoop의 FileStatus를 감싸, 경로·크기·디렉터리 여부·수정 시각 같은 값을 감싼 대상에 위임해 돌려줍니다. 그런데 접근 시각과 소유자를 돌려주는 메서드는 오버라이드하지..

Serializable인데 serialVersionUID가 없었습니다Apache Paimon은 여러 클라우드 스토리지를 파일시스템 플러그인으로 붙입니다. 각 스토리지에는 플러그인을 로드하는 FileIOLoader 구현이 하나씩 있고, 텐센트 클라우드 COS용은 COSNLoader입니다. 이 클래스에 직렬화 식별자가 빠져 있어, 이번 글에서는 그것을 채운 apache/paimon#8555를 이야기하려 합니다. 시작은 인터페이스를 확인하는 데서였습니다. FileIOLoader는 Serializable을 상속합니다.public interface FileIOLoader extends Serializable { 즉 이 인터페이스를 구현하는 모든 로더는 직렬화 대상입니다. Paimon에서 파일시스템 로더가 직렬화되..

정상 동작이 경고로 찍히고 있었습니다Apache Paimon은 여러 클라우드 스토리지를 파일시스템 플러그인으로 지원합니다. 그중 텐센트 클라우드의 COS를 다루는 paimon-cosn-impl 모듈에서, 설정을 읽어 들이는 자리의 로그 레벨이 상황과 어긋나 있었습니다. 이번 글에서는 그것을 제자리로 돌린 apache/paimon#8554를 이야기하려 합니다. COSNFileIO는 초기화 시점에 configure에서 사용자가 준 설정 가운데 COSN 접두사를 가진 항목을 골라 Hadoop 설정으로 옮깁니다. 그 옮기는 항목마다 로그를 한 줄씩 남기고 있었는데, 그 레벨이 warn이었습니다.// AS-IShadoopOptions.set(key, value);LOG.warn( "Adding con..

오픈소스에 기여를 이어 가면서 저는 "같은 일을 하는 두 갈래 중 한쪽만 고쳐진 자리"를 자주 봅니다. 이미 누군가 문제를 인지하고 한 곳을 손봤는데, 똑같은 문제를 안고 있는 형제 코드가 그대로 남아 있는 경우입니다. 이런 자리는 대개 리뷰 부담이 작습니다. 고칠 방향을 새로 정할 필요 없이, 이미 머지된 형제의 방식을 그대로 따라가면 되기 때문입니다. 이번에 다룰 기여(#8494)도 그렇게 찾은 것입니다. OpenTelemetry Java의 OTLP exporter 테스트에서, gRPC 쪽은 이미 완화된 단언이 HTTP 쪽에는 그대로 남아 환경에 따라 깨질 수 있던 문제였습니다. 먼저 PR 링크를 남겨 둡니다. 실제 변경과 리뷰 과정은 https://github.com/open-telemetry/op..

오픈소스 기여를 이어 가면서 저는 "이미 잘 도는 코드 안에서 한쪽만 다르게 동작하는 자리"를 찾는 방식을 자주 씁니다. 새 기능을 크게 얹는 대신, 같은 일을 하는 두 갈래가 서로 어긋난 지점을 찾으면 그게 대개 버그입니다. 이번에 다룰 기여(#8493)도 그렇게 찾은 것입니다. OpenTelemetry Java의 OTLP exporter에서, 로그 레코드의 플래그 필드 하나를 두 직렬화 경로가 서로 다른 바이트로 내보내던 문제였습니다. 먼저 PR 링크를 남겨 둡니다. 실제 변경과 리뷰 과정은 https://github.com/open-telemetry/opentelemetry-java/pull/8493 에서 볼 수 있습니다. 로그 레코드에는 두 벌의 마샬러가 있습니다OpenTelemetry는 수집한 ..

오픈소스에 처음 기여를 시작할 때 가장 막막했던 건 "무엇을 고쳐야 하는가"였습니다. 큰 기능을 새로 만들 자신은 없었고, 그렇다고 오타 하나만 고치기에는 뭔가 아쉬웠습니다. 그래서 택한 방법은 이미 잘 돌아가는 코드 안에서 "한쪽만 다르게 동작하는 부분"을 찾는 것이었습니다. 이번에 다룰 기여(#8497)도 그렇게 찾은 것입니다. OpenTelemetry Java의 Prometheus exporter에서, 같은 메서드가 속성의 위치에 따라 배열 값을 서로 다른 형식으로 내보내던 문제였습니다.PR 링크를 먼저 남겨 둡니다. https://github.com/open-telemetry/opentelemetry-java/pull/8497 에서 실제 변경과 리뷰 과정을 볼 수 있습니다.Prometheus ex..

같은 모듈 안에서 비슷한 일을 하는 클래스가 여럿일 때, 어느 하나에만 개선이 들어가고 나머지는 그대로 남는 일이 있습니다. 기능이 없는 것도 아니고 버그가 눈에 띄는 것도 아니라 한동안 지나가기 쉽습니다. 이번에 LangChain4j에 올려 머지된 변경이 그런 자리였습니다. Jlama 모듈에서 모델 다운로드가 실패할 때, 채팅 모델은 인증 오류인지 모델을 못 찾은 것인지 알려 주는데 나머지 네 개는 뭉뚱그린 예외만 던지고 있었습니다.예외 타입이 뭉개지던 경로Jlama는 자바에서 모델을 로컬로 내려받아 돌리는 라이브러리이고, LangChain4j의 langchain4j-jlama 모듈이 이를 감싸 줍니다. 모델 객체를 만들 때 필요한 모델 파일을 먼저 내려받는데, 이 다운로드가 실패하면 그 실패를 어떤 ..

주소 끝의 슬래시 하나는 평소에 신경 쓸 일이 없습니다. 그런데 라이브러리가 그 주소를 다른 라이브러리에 넘겨주는 자리에서는 그 한 글자가 예외로 이어지기도 합니다. 이번에 LangChain4j에 올려 머지된 변경이 그런 경우였습니다. HuggingFace 모듈에 직접 엔드포인트 주소를 지정하면, 그 주소가 슬래시로 끝나지 않았다는 이유만으로 모델 객체를 만드는 순간 예외가 났습니다. 커스텀 주소를 넣으면 만들어지지도 않던 클라이언트당시 DefaultHuggingFaceClient는 Retrofit으로 HTTP 호출을 처리하고 있었습니다. Retrofit은 기준 주소를 받을 때 반드시 /로 끝나야 한다는 규칙을 두고, 그렇지 않으면 baseUrl must end in /라는 메시지와 함께 IllegalA..

임베딩 스토어를 쓰다 보면 메타데이터로 결과를 좁히는 일이 자주 있습니다. 문서에 붙여 둔 키-값 중에서 특정 값을 가진 것만 골라내는 흔한 작업입니다. LangChain4j는 이런 조건을 Filter라는 공통 타입으로 표현해 두고, 각 스토어 모듈이 그것을 자기 데이터베이스가 알아듣는 질의로 번역합니다. 사용하는 쪽에서는 어떤 스토어를 쓰든 같은 코드를 쓰면 되니 편한 구조입니다. 그런데 이 "번역"이라는 말 안에는 조용한 위험이 하나 들어 있습니다. 번역이 조금이라도 어긋나면, 같은 필터를 걸었는데 스토어마다 다른 결과가 나옵니다. 그것도 예외가 터지는 게 아니라 그냥 결과가 조금 달라지는 방식으로요. 이번에 LangChain4j에 올려 머지된 변경은 정확히 그 종류의 어긋남을 다룬 것이었습니다. l..

설정 문서 생성기가 &를 그냥 흘려보내고 있었습니다Apache Paimon은 설정 옵션 문서를 손으로 쓰지 않고 코드에서 생성합니다. paimon-docs 모듈의 Utils.escapeCharacters가 옵션 설명 문자열을 HTML에 안전하게 넣을 수 있도록 특수 문자를 이스케이프하는 역할을 합니다. 이 메서드가 앰퍼샌드(&)를 처리하지 않고 있어, 이번 글에서는 그것을 채운 apache/paimon#8552를 이야기하려 합니다. 기존 구현은 꺾쇠괄호만 이스케이프하고 있었습니다.// AS-ISpublic static String escapeCharacters(String value) { return value.replaceAll("", TEMPORARY_PLACEHOLDER) ..

byte[] 키를 자바 Map으로 찾으면 어긋납니다Apache Paimon의 paimon-common 모듈에는 내부 데이터 구조를 비교하고 해시하는 InternalRowUtils가 있습니다. 이 유틸리티가 MAP 타입을 비교하는 방식에 어긋난 부분이 있어, 이번 글에서는 그것을 고친 apache/paimon#8536을 이야기하려 합니다.문제는 맵의 키를 찾는 방식이었습니다. 기존 equals는 한쪽 맵의 키를 꺼내 다른 쪽 맵에서 contains와 get으로 찾았습니다. // AS-ISObject key = get(keyArray1, i, mapType.getKeyType());if (!map2.contains(key) || !equals(map1.get(key), map2.get(key),..

생성된 비교기가 부동소수점을 == 로 비교하고 있었습니다Apache Paimon은 레코드를 비교하는 코드를 실행 시점에 생성합니다. paimon-codegen 모듈의 EqualiserCodeGenerator가 필드 타입에 맞춰 RecordEqualiser의 equals 본문을 Scala 템플릿으로 찍어 내는 구조입니다. 이 생성된 비교기가 부동소수점 필드를 다루는 방식에 어긋난 부분이 있어, 이번 글에서는 그것을 맞춘 apache/paimon#8534를 이야기하려 합니다. 문제의 출발점은 원시 타입 필드를 비교하던 자리였습니다. 생성기는 정수나 부동소수점 같은 내부 원시 타입을 만나면 자바 == 연산으로 비교하는 코드를 찍어 냈습니다.// AS-IS — 내부 원시 타입은 모두 == 로 비교if (isIn..

하나만 빠진 오버라이드Apache Paimon의 타입 시스템에서 중첩 타입들은 서로 닮은 메서드 묶음을 함께 오버라이드합니다. ArrayType, MapType, VectorType, RowType은 모두 equalsIgnoreFieldId와 isPrunedFrom을 각자 구현하고 있었는데, 같은 계열인 MultisetType만 이 둘을 오버라이드하지 않고 있었습니다. 이번 글에서 이야기할 기여는 그 빠진 자리를 채운 apache/paimon#8519입니다. 이 두 메서드는 스키마를 비교할 때 쓰입니다. equalsIgnoreFieldId는 두 타입이 필드 id만 다를 뿐 구조는 같은지 판정하고, isPrunedFrom은 한 타입이 다른 타입에서 일부 필드를 덜어 낸(프루닝된) 형태인지 판정합니다. 스키..

같은 인자를 두 번 넣은 해시Apache Paimon의 paimon-api 모듈을 살펴보다가, equals와 hashCode가 서로 다른 필드를 바라보고 있는 자리를 발견했습니다. FunctionChange의 중첩 타입인 UpdateDefinition에서 hashCode()가 이렇게 되어 있었습니다.@Overridepublic int hashCode() { return Objects.hash(definition, definition);}definition을 두 번 넣고, name은 빠져 있었습니다. 이번 글에서 이야기할 기여는 이 한 줄을 바로잡은 apache/paimon#8518입니다.FunctionChange는 함수 정의의 변경을 표현하는 타입으로, 정의를 추가하는 AddDefinition, 갱..

형제 타입은 이미 고쳐져 있었습니다Apache Paimon의 타입 시스템 코드를 읽다가, 서로 닮은 형제 클래스들 사이에서 한 곳만 다르게 처리된 부분을 발견했습니다. paimon-api 모듈의 VectorType.defaultSize()는 자식 크기를 곱할 때 오버플로를 막는 헬퍼를 쓰고 있었는데, 같은 계열의 RowType·MapType·MultisetType은 그냥 정수 덧셈으로 자식 크기를 합치고 있었습니다. 이 작은 비대칭이 이번 글에서 이야기할 기여의 출발점입니다. 실제로 올려 머지된 변경은 apache/paimon#8517입니다. defaultSize()는 각 데이터 타입이 메모리에서 차지하는 기본 바이트 크기를 어림하는 메서드입니다. 예를 들어 INT는 4, BIGINT는 8을 돌려주고, ..

PR #8492에서 제가 바꾼 것은 문자열 리터럴 한 글자입니다. s 하나를 지웠습니다. 이렇게 적어놓고 보면 굳이 글로 남길 일인가 싶지만, 이 한 글자를 확인하는 과정에서 저는 "테스트가 있다"와 "테스트가 검증한다"가 같은 말이 아니라는 것을 꽤 구체적으로 마주하게 됐습니다. 그 부분이 남아서 정리해둡니다. 클래스 이름과 다른 이름을 출력하던 메서드:exporters:otlp:profiles는 profiles 시그널을 OTLP gRPC로 내보내는 모듈입니다. profiles는 트레이스·메트릭·로그에 이어 OpenTelemetry에 들어온 비교적 새로운 시그널이고, 이 모듈은 alpha 산출물입니다. 이 모듈을 읽다가 OtlpGrpcProfileExporter의 toString()에서 멈췄습니다.@O..

OpenTelemetry Java 저장소에 몇 건의 변경을 올리면서, 저는 큰 기능을 만드는 것보다 이미 있는 코드가 스스로 약속한 것을 지키고 있는지 확인하는 쪽이 초보 기여자에게 더 맞는 일이라는 생각을 하게 됐습니다. 이번 글에서 다룰 PR #8489는 그런 종류의 변경입니다. 프로덕션 코드 네 줄과 테스트 파일 하나가 전부지만, 그 네 줄에 도달하기까지 확인해야 했던 것들이 저에게는 더 남았습니다. 엔드포인트를 검증한다는 말의 의미OpenTelemetry Java에서 exporter는 수집한 텔레메트리를 OTLP 같은 프로토콜로 백엔드에 보내는 역할을 합니다. 이때 어디로 보낼지를 지정하는 값이 엔드포인트고, 보통 http://localhost:4318 같은 문자열로 들어옵니다. exporters..

코드를 읽을 때 저는 대체로 메서드 하나를 붙잡고 그 안에서 값이 어떻게 흐르는지를 봅니다. 그 방식으로 찾을 수 있는 결함이 있고, 그 방식으로는 절대 안 걸리는 결함이 있습니다. 이 글에서 다룰 #17066은 후자였습니다. 관련된 메서드 두 개는 각각 놓고 보면 어디에도 이상이 없습니다. 문제는 둘을 순서대로 불렀을 때 생겼습니다. 어떻게 그 순서를 의심하게 됐는지, 그리고 한 줄을 고치기까지 무엇을 확인했는지를 정리해 보려고 합니다.셰딩된 객체가 필드를 기억하는 방식무대는 iceberg-core의 ShreddedObject(core/src/main/java/org/apache/iceberg/variants/ShreddedObject.java)입니다. Iceberg의 Variant는 스키마가 미리 정..

Apache Iceberg에 기여하면서 자주 쓰는 방법 중 하나는 같은 일을 하는 코드를 나란히 놓고 보는 것입니다. 다만 이 방법에는 함정이 있습니다. 구현이 서로 다르다는 사실만으로는 어느 쪽이 틀렸는지 알 수 없기 때문입니다. 이 글에서 다룰 #17055는 그 판단을 어디까지 밀어붙여야 했는지, 그리고 리뷰에서 받은 질문 하나가 제 근거를 어떻게 다시 확인하게 만들었는지에 관한 기록입니다. 저는 Iceberg의 벡터화 읽기 전반을 아는 사람이 아니라 이 한 경로를 코드로 따라가 본 사람의 시점에서 씁니다.딕셔너리 인코딩 값을 Arrow 벡터에 옮기는 자리문제가 있던 곳은 iceberg-arrow 모듈의 VectorizedDictionaryEncodedParquetValuesReader(arrow/s..

Apache Iceberg에 몇 건 기여하다 보니, 제가 코드에서 눈을 두는 자리가 조금씩 옮겨 갔습니다. 처음에는 값이 잘못 계산되는 곳을 찾았는데, 어느 순간부터는 "이 코드가 실패할 때 사용자에게 무엇이 보이는가"도 함께 보게 됐습니다. 이 글에서 다루는 #17098은 그렇게 찾은 건입니다. 고쳐도 정상적인 읽기·쓰기 동작은 단 하나도 바뀌지 않고, 오직 예외가 던져질 때의 메시지만 달라지는 수정입니다. 그런 변경을 왜 PR로 올릴 만하다고 판단했는지, 그리고 그 판단을 위해 무엇을 확인해야 했는지를 정리해 보려고 합니다. 저는 Iceberg 전반을 아는 사람이 아니라 이 한 경로를 코드로 확인해 본 사람의 시점에서 씁니다. 포맷 문자열이 포맷되지 않는 자리문제가 있던 곳은 ORC 스키마를 Iceb..

OpenTelemetry Java(open-telemetry/opentelemetry-java)에 기여를 이어 가면서, 같은 모듈 안에서 비슷한 역할을 하는 클래스들을 나란히 놓고 비교하는 습관이 생겼습니다. 이번 기여(#8490)도 그렇게 시작했습니다. 세 형제 exporter를 차례로 열어 보다가, 그중 하나만 클래스 설명이 통째로 비어 있는 것을 발견했습니다.같은 모듈, 같은 역할, 다른 문서문제의 자리는 :exporters:logging 모듈이었습니다. 이 모듈은 텔레메트리를 로그나 표준 출력으로 찍어 주는 exporter를 모아 둡니다. 수집기로 보내기 전에 콘솔이나 로그에서 무엇이 나가는지 확인하는, 거친 디버깅용 도구입니다. 여기에는 신호별로 세 exporter가 한 벌로 들어 있습니다. L..

OpenTelemetry Java(open-telemetry/opentelemetry-java)에 기여를 이어 가면서, 이번에는 평소 잘 들여다보지 않던 자리를 열어 보게 됐습니다. 바로 package-info.java입니다. 클래스도 메서드도 아닌, 패키지 전체를 한 문장으로 소개하는 문서 전용 파일입니다. 이번 기여(#8487)는 그 한 문장이 패키지가 실제로 담고 있는 것과 어긋나 있던 문제를 고친 기록입니다.패키지 소개가 두 가지만 말하고 있었다문제의 자리는 :exporters:logging-otlp 모듈의 패키지 설명이었습니다. 이 모듈은 텔레메트리를 OTLP JSON 형식으로 로거에 찍어 주는 exporter를 모아 둡니다. 그 패키지의 package-info.java는 이렇게 적혀 있었습니다..

오픈소스 저장소를 읽다 보면, 코드 자체보다 코드를 설명하는 문장이 먼저 눈에 걸릴 때가 있습니다. 이번에 OpenTelemetry Java(open-telemetry/opentelemetry-java)에 올린 두 번째 기여(#8484)가 그랬습니다. 선언형 설정(declarative config) API를 들여다보다가, 한 메서드의 Javadoc이 스스로와 어긋나 있는 것을 발견했습니다. 바뀐 코드는 문장 두 개뿐이지만, 왜 그런 어긋남이 생겼는지 따라가 보는 과정이 제게는 공부가 됐습니다.첫 문장과 @return이 다른 말을 하고 있었다문제의 자리는 :api:incubator 모듈의 DeclarativeConfigProperties 인터페이스였습니다. 이 인터페이스는 YAML로 작성한 설정을 프로그램..

오픈소스에 기여해 보고 싶다는 생각은 오래 했지만, 막상 시작은 늘 미뤘습니다. 큰 저장소를 열면 어디부터 봐야 할지 막막했고, 내가 고칠 만한 자리가 있을까 싶었습니다. 그러다 OpenTelemetry Java(open-telemetry/opentelemetry-java)를 골라 한 모듈씩 천천히 들여다보기로 했습니다. 모든 코드를 다 읽겠다는 욕심은 처음부터 버렸습니다. 대신 테스트 코드부터 읽었습니다. 테스트는 그 모듈이 무엇을 보장하려 하는지 가장 솔직하게 보여 주는 자리라고 생각했기 때문입니다. 이 글은 그렇게 찾은 작은 기여 한 건(#8483)을 정리한 기록입니다. 바뀐 코드는 단 한 줄이지만, 그 한 줄을 올리기까지 저장소의 구조와 규칙을 익히며 배운 것이 적지 않았습니다.형제 테스트가 서로..