[WIL] 외부 개발자의 참여로 개선을 이루는 오픈소스 사례 - 팝빌

금주에 있었던 재미있던 경험을 블로그에 남겨봅니다.

 

회사에서는 링크허브(LinkHub)라는 비즈니스 파트너를 통해 문자 메시지 발송 서비스를 이용하고 있었다.

Spring Boot 기반의 Kotlin JVM으로 개발을 하고 있었다. 그래서 링크허브에서 Java 언어를 위해 제공하는 SDK를 더 쉽게 연동할 수 있게 제공하는 Spring Boot SDK를 사용하고 있었다.

// build.gradle.kts
dependencies {
  // ..
  implementation("kr.co.linkhub:popbill-spring-boot-starter:1.4.0")
}

 

위와 같이 의존성을 추가하면 스프링 부트 스타터가 자동 설정을 통해 com.popbill.api.MessageService 인터페이스를 DI가 가능합니다.

오픈소스

위의 MessageService 링크를 보면 알 수 있듯이 팝빌의 SDK는 GitHub에 소스 코드를 확인할 수 있습니다.
즉, 일종의 오픈소스인 셈입니다.

 

여러 언어를 지원하고 있어서 여러 리포지토지가 있다. Spring Boot 기반의 연동을 한다면 아래 두 리포지토리가 관심의 대상이다.

• popbill.sdk.java - https://github.com/linkhub-sdk/popbill.sdk.java
• popbill.springboot - https://github.com/linkhub-sdk/popbill.springboot

12-Factor 앱과 오픈소스

2012년 Heroku에서 일하던 개발자들은 클라우드 시대에 적합한 애플리케이션 개발과 배포 방법에 맞는 12가지 원칙(Twelve Factor)을 정리하여 공개하였습니다.

https://12factor.net/

The Twelve-Factor App

 

이 원칙에는 오픈 소스라고 명시적으로 나와있지는 않습니다.

하지만 3번째 원칙인 설정(Config)에서 설정이 제대로 되었는지 확인하는 가장 간단한 방법을 코드 기반을 언제라도 오픈 소스로 만들 수 있는지로 확인할 수 있다고 언급을 하고 있습니다.

A litmus test for whether an app has all config correctly factored out of the code is whether the codebase could be made open source at any moment, without compromising any credentials.

 

아마도 링크 허브는 자사의 SDK 소스 베이스를 private repository가 아닌 public repository로 오픈 소스화를 하여 운영을 하고 있었습니다.

라이브러리 버전 업데이트 이후 문자 발송이 안되는 이슈

스프링 부트 버전을 3.3.4에서 3.3.5로 업데이트하면서 다른 의존하고 있는 라이브러리들도 버전 확인을 했습니다.

팝빌 SDK 최초 연동한 2022년 8월에는 본문의 의존성 예시와 같이 1.4.0 버전을 사용하고 있었습니다.

현재 2024년 11월 기준 1.14.5가 최신 버전이었습니다.

 

마이너 버전이 10이란 값이 증가한 만큼 버전 업데이트를 하는 것이 SDK가 의존하고 있는 다른 서드파티 라이브러리 취약점 해결에도 도움이 되겠다고 판단하여 같이 업데이트를 하기로 했습니다.

 

한가지 마음에 걸렸던 점은 2024년 4월경 spring boot SDK 버전을 1.14.1에서 1.14.3으로 올리고 문자 메시지 전송이 안되었던 이슈 때문이었습니다.

당시 팝빌 기술지원팀에 연락을 해서 SDK 올리고 나서 이상이 있다는 제보를 했었지만 해결이 되지 않았습니다.

당시 프로젝트를 진행하는 상황이라 같이 원인을 파악하면 좋았지만 시간 여유가 있지 않았습니다.

 

다행히 이번에는 프로젝트를 진행하지 않아서 DevOps 중 운영(Operations)에 신경을 쓸 수 있는 시점이라 오픈 소스의 장점을 살려 문제가 되는 부분을 파악해서 제공을 하면 서로 Win-win 할 수 있는 기회가 될 것이라 생각하였습니다.

전략: D&C

문제를 찾기 위한 여러 가지 방법이 있었겠지만 컴퓨터 공학에 자주 나오는 분할정복(Divide and Conquer) 전략을 택하였습니다.

동작이 되는 부분과 안되는 부분을 점차적으로 좁혀서 안되는 특정 시점에서의 소스 코드의 변화를 파악하면 될 것이기 때문입니다.

popbill.springboot 버전	popbill-sdk 버전(Java)	동작
1.14.0	1.64.0	발송 OK
1.14.1	1.65.1 ~ 1.65.2	발송 NG
1.14.2	1.65.3	발송 NG
1.14.4	1.65.4	발송 NG
1.14.5	1.65.5	발송 NG

 

표로 정리하면 1.14.1 버전부터 문자 발송 이슈가 있는 것을 알 수 있었습니다.
이제 의존하고 있는 SDK인 1.65.1에서 어떠한 변화가 있는지 확인을 하면 원인을 찾을 수 있을 것 같았습니다.

원인은 case 스타일의 변경

2024년 3월 22일 함수 파라미터가 camelCase에서 PascalCase로 변경되었습니다.

• 커밋 해시: 2ab443346ef51b55ec5cc1c244677a73ff0336c6

변경하면서 문자 메시지 발송의 JSON 모델인 SendRequest 클래스의 프로퍼티도 PascalCase 형식으로 바뀌었습니다.

 

따라서 서버의 스펙이 같이 변경되지 않았다면 content, subject, adsYN 프로퍼티는 제대로 읽지 못할 가능성이 있습니다.

관련 이슈 등록: https://github.com/linkhub-sdk/popbill.springboot/issues/2

 

버그 제보와 커뮤니케이션

11월 20일 (수) 링크허브 기술 센터에 전화 연락을 하고 문제가 되는 부분에 대하여 파일 이름과 코드 라인 수준으로 제보를 했습니다.
이제 금방 이슈가 SendRequest의 PascalCase로 변경된 프로퍼티가 camelCase로 바뀌면서 금방 해결되겠지 생각을 했지만 문제에 대해 공감을 시키는 것은 어려웠습니다.

그것도 그럴만 한 것이 사내에서 1.14.1 이상의 버전에서 문자 메시지를 잘하고 있는 팀도 있었기 때문입니다.

 

나중에 알게 되었지만 전체 기능에 문제가 있지 않고 동보전송이라는 한 번에 여러 명에게 동일한 문자 메시지를 발송하는 부분만 문제였기 때문입니다.

Message 배열에는 별도의 content, subject 등이 있어서 개별로 다른 내용의 메세지를 보낼 수 있는데 이 방식을 사용하면 메시지 전송에 문제가 없기 때문입니다.

 

또한 담당자는 당시 메시지 전달에 대한 테스트를 모두 통과했다면서 버그에 대한 납득을 시키는 것도 개선하는 과정에 어려운 점이었습니다.

다행히도 Message 내부의 모델은 case style이 동일한 것을 통해 SendRequest의 프로퍼티 변경이 이슈가 될 것이라고 설득을 해서 좀 더 내부 검토를 하겠다는 대답을 받을 수 있었습니다.

다음 날

11월 21일 (목) 기술 센터에서 연락을 받았고 해당 이슈가 동보전송에 문제가 있음을 알려주었습니다.

그래서 수정한 버전을 고쳐서 배포했다고 연락을 받았습니다.

• 변경 commit: 13a0627

다시 camelCase로 변경

배운 점

회사 생활을 하면서 다른 비즈니스 파트너와 협업을 하면서 여러 연동을 해본 경험이 있습니다.

하지만 다른 회사에서 작성한 소스 코드를 보면서 같이 버그를 파악하고 해결한 경험은 이번이 처음입니다.

왜냐하면 보통 회사의 코드는 자산으로 여겨서 외부에 공개하는 경유가 드물기 때문입니다.

 

하지만 링크허브의 경우 연동하는 부분의 소스코드를 오픈소스화하면서 제 3의 외부 개발자가 구체적인 문제의 원인을 파악하는 기회를 제공하였습니다. 이로 인해 연동받는 관점에서는 문제 해결을 빠르게 할 수 있었고 제공하는 입장에서는 사용하는 다른 서드파티 업체에도 개선의 경험을 같이 누릴 수 있는 좋은 기회였다고 생각합니다.