💎 들어가며
Let's make a library 시리즈
Let's make a library 시리즈에서는 일전에 Ros Bridge 프로토콜 분석을 바탕으로 개발한 RosBridge 라이브러리의 과정을 일지를 적어보고자 합니다.
이 시리즈에서는 아래 내용에 대해 적어볼까 합니다. (지속적으로 추가될 수 있음)
- 라이브러리 개발여정
- OSSRH로 Maven에 라이브러리 배포하는법
포스팅 내용
이번 포스팅에서는 아래 내용에 대해 기술합니다.
- 라이브러리란 무엇인지
- 라이브러리
배포하면서 알게된 것들 - 라이브러리를 만들게 된
계기, 앞으로의목표 - 개발하면서 얻은
인사이트, 앞으로의숙제
1. 라이브러리
1.1 라이브러리의 정의
개발에 앞서 선행되야 될 내용으로 라이브러리란 무엇인가? 에 대해 찾아보았습니다.
라이브러리란?
라이브러리란 특정한 코드(함수 혹은 클래스)를 포함하고 있는 컴파일된 파일이다.소프트웨어 개발 시 공통으로 사용할 수 있는 특정한 기능들을 모듈화한 것으로, 완전한 프로그램이 아닌, 특정한 부분 기능만을 수행하도록 제작된 프로그램이다.
이렇게 자주 쓰이는 함수들을 라이브러리에 모아 프로젝트 시작 시 코드에 해당 라이브러리 파일만 include 시켜주면 그 안에 있는 함수를 쉽게 사용할 수 있다.
💡모듈 : 특정 기능별로 나누어지는 프로그램 덩어리
내가 라이브러리를?
예전에 이런 생각을 한적이 있습니다.
라이브러리를 개발한 사람들은 어떻게 뭘 하다가(어떤 계기로) 라이브러리를 만들게 된걸까?
특히나 라이브러리는 일정 수준의 공통으로 사용할 수 있는 Util 파일을 넘어섰기 때문입니다.
아직까지도 잘 알지는 못하지만, 특정 프로토콜로 통신할 수 있도록 개발하는 것을 주제로 삼는 것이 적당하지 않을까 싶습니다.
1.2 라이브러리 개발 목표
🫥 왜 나는 라이브러리를 만들었을까?
소프트웨어 개발에서 가장 중요한 것이
계기(왜 시작하게 됐느냐),동기(나를 움직이는 힘),목표(내가 도달해야할 목표)이라고 생각합니다.
ROS라는게 아직까지는 워낙에 희소한 기술(로봇 개발에 한정)이다 보니 레퍼런스나 라이브러리가 많이 없습니다.
어렵게 찾아낸 라이브러리가 사용하고자 하는 기능이 없어 or 맘에 안드는 부분들 때문에 만들어서 사용하자는 결론에 도달한 것이 라이브러리 개발의 시작이었습니다.
처음에는 기존에 서칭한 라이브러리들을 레퍼런스로 기능을 구현하였지만 기존 라이브러리들은 오래된 레퍼런스라 로직 구현 원리 파악에 집중했고, 나만의 프로젝트를 구성할 라이브러리, 프레임워크 등을 찾아보게 되었습니다.
🤦♀️ 라이브러리 배포는 꼭 필요해?
기껏 만들어놓고 jar 파일로 압축해서 쓴다고? 패키지 관리자(POM)에서 손쉽게 쓸 순 없을까?
❤️ Vert.x 와의 만남
WebSocket자체가비동기기반인데동기적으로 구현하는 것이 올바른가? 에 대한 물음을 시작으로 자연스레비동기 프레임워크에 관심을 갖게 되었습니다.
친하게 지내던 서버 개발자랑 얘기하면서 Vert.x 프레임워크의 존재를 알게 되었습니다. Vert.x는 node.js를 본따 만든 프레임워크로 Future, Promise 등의 유사한 기능이 있습니다.
Vert.x를 보면서 저는 이런 생각을 했습니다. "아, 내가 찾던거다!!!"
그 때부터 새로운 기능 개척, 러닝 커브 등으로 인해 개발 난이도는 급 상승했지만 하루의 모든 순간이 라이브러리 개발에 집중되어 있고 제가 살아있음을 실감하게 된 경험이었습니다. 사실 Vert.x의 원리파악을 제대로 할 시간도 없었기 때문에 허술한 부분이 많습니다. 다시 차근차근 공부해가면서 Vert.x도 포스팅하고 라이브러리도 업데이트할 계획입니다.
🫡 앞으로의 목표
앞으로 저의 목표는 <많은 사람들이 사용하는 저의 라이브러리를 개발하는 것>입니다.
하나의 라이브러리를 개발을 하면서 많은 인사이트를 얻게 되었는데, 그 인사이트를 바탕으로 견고한 라이브러리를 개발하고 싶습니다.
많은 경험을 쌓아가면서 더많은 인사이트를 얻을 수 있으면 좋겠습니다.
1.3 라이브러리 배포
라이브러리의 방향성
모든 라이브러리의 최종 목표는 많은 사람들이 이용하는 것인데요.
그 시작은 우선, 라이브러리가 많은 사람들이 볼 수 있도록 저장소에 등록(배포)되는 것입니다. 저는 ✨OSSRH 서비스를 통해 저의 라이브러리를 Maven Central Repository (중앙 저장소)에 등록했습니다.
Maven Central Repository, Sonatype Nexus, OSSRH
Maven Central Repository(중앙 저장소)란 오픈 소스 라이브러리, 메이븐 플러그인, 메이븐 아키타입을 관리하는 저장소입니다.
라이브러리 배포를 찾아보면서 GitHub에 배포된 소스를 Maven 중앙저장소에 무료로 등록할 수 있는 방법을 알게 되었습니다.
바로 OSSRH라는 것인데요! OSSRH(Open Source SW Repository Hosting)은 Sonatype 이라는 회사가 지원하는 오픈 소스를 무료로 호스팅할 수 있도록 도와주는 서비스입니다.
Nexus는 Sonatype에서 개발한 저장소 관리자로, 가장 중요하고 많이 사용하는 기능은 아티팩트를 등록하고 관리하는 것입니다.
라이브러리를 배포해보고 Nexus를 알게된 후, 신나서 다른 개발자들과 얘기하면서 알게 된 점이 일부는 이미 Nexus를 알고 있었습니다. 사내에 구축된 Nexus를 사용한다네요.
물론 라이브러리를 직접 개발해 본 경험은 아니지만, 신기하면서도 신났던게 부끄러웠습니다. 그래도 저도 "사내에서 Nexus를 구축해서 사용한다"는 정보를 알게되었습니다. 역시 개발자는 소통하면서 사는게 중요한 거 같아요.
2. 인사이트(Insight)
라이브러리를 개발하면서 여러가지 인사이트를 얻을 수 있었습니다. 그 인사이트들을 공유해보자 합니다.
What is Insight?
통찰(洞察, Insight)은 특정 맥락 내에서 특정 원인과 효과를 이해하는 것을 말한다. 통찰이란 용어는 몇몇 관련 의미가 있다.
- 약간의 정보: 사물의 내적 본성을 이해하거나 직관적으로 바라보는 것의 행동이나 결과(그리스어로 누스(nous 혹은 noesis)라고 함)
- 예민한 관찰과 추론(deduction), 안목(discernment), 인지(perception)의 힘, 지성(intellection)이나 누스(noesis)라고 함
- 모델, 맥락, 시나리오에서 관계와 행동의 동일시에 기반한 원인과 결과를 이해하는 것
참조: 통찰 - 위키백과
아래 적은 내용들은 제가 얻은 인사이트일 뿐 완전히 적용되지는 않았습니다. (다짐이랄까?)
앞으로 아래 내용들을 차차 적용하면서 라이브러리를 발전시켜 나갈 것입니다.
2.1 라이브러리 개발은 하나의 여정
하나의 여정
라이브러리 개발이란 내가 머리속으로 그린 메커니즘들을 코드로 실현해 나가는 과정이라고 생각합니다.
초기에는 미흡하나 점진적 업그레이드 만이 과정을 완성시킬 수 있습니다. 그 과정이 미흡했더라도, 그 자체로도 굉장히 유의미한 시간이었습니다.
사실 초창기 모델은 타 라이브러리를 벤치마킹하는 데에서 시작했습니다. 하지만 점차 기능들이 추가되고, 뼈대(프레임워크)를 바꾸게 되면서 전혀 다른 형태의 프로그램으로 완성되면서 나만의 라이브러리를 완성시키게 되었습니다.
시작과 끝
프로그램 개발에 있어 가장 중요한 것은 일단 시작하는 것이고, 멈추지 않는 것입니다.
프로그램에 있어 멈춤은 있어도 완성이란 순간은 없는 것이라고 생각합니다. 많은 라이브러리들이 역사 속으로 사라지는 데에도 업데이트하는 것을 멈췄기 때문이죠.
2.2 테스트 코드를 작성하자
일전에는 많은 라이브러리의 테스트 코드를 보면, 아래와 같은 생각이 들었습니다.
테스트 코드 상태
"왜 혼자 정보를 만들고, 정보를 뿌리는 것인가?" ≒ "혼자 북치고 장구친다."
하지만, 라이브러리 개발을 하면서 왜 테스트 코드가 이렇게 쓰여져 있는지 깨닫게 되었습니다. 아래와 같은 목적을 위해 테스트 코드를 작성하는 것이 아닐까..
- 테스트로서의 가치: 단위 테스트를 위해 테스트 코드 작성
- 사용자에게 정보 제공: 라이브러리를 사용하는 사용자들에게 라이브러리 사용법을 제공
다른 개발자 친구에게 말해줬더니 이런 말을 들었습니다.
"그러면 테스트 코드에 Server 따로, Client 따로 만들면 되지!"
이게 가장 좋은 방법이나 라이브러리를 위해 테스트 프로그램을 추가로 개발하는 건 좀 헤비하달까..?
결론: 여유 있을 때 하자!
정말 여유가 된다면, 라이브러리에 대한
Documentation도 만들고, 테스트 클라이언트도 만들어보면 좋을 거 같네요.
2.3 버전 관리를 하자
우당탕탕 라이브러리
저는 사실상 혼자 or 둘이서 개발하는 경우가 많아 브랜치 전략(ex. Git Flow)을 사용해본 적이 없어서 아직 버전 관리를 제대로 해본 적이 없습니다.
하지만 라이브러리를 개발하면서 가장 많이 느낀 것은
- 단위 테스트는 필수
- 버그는 숨쉬듯 나타난다.
- 꼭 배포한 뒤에 적용 과정에서 버그가 나타난다.
이미 배포를 해버렸으니 버그를 수정한 뒤에 또 다시 배포하려고 하면, 버전을 올려야 되서 버전이 엉망진창이 되버리는 것이 문제입니다.
Maven에 배포했기 때문에 Maven Repository 공식 홈페이지 에서 아래와 같이 내가 만든 라이브러리 정보를 볼 수 있는데, 정말 우당탕탕 라이브러리가 아닐까 싶어 솔직히 조금 부끄러운 마음도 있어요...
그래도 이게 난데 어쩌겠어요?ㅎㅎ🤣 똑같은 실수를 반복하지 않는게 중요하지 않을까요ㅎㅎ
OSSRH 특급 정보!
OSSRH로 라이브러리를 배포하면 이전 버전을 지울수 없습니다! 꼭 주의하세요! 이거 서칭하다가 3일은 꼬박 날렸습니다.
여담) 사내 Nexus를 사용하시는 분들은 그냥 폴더를 지우면 된다네요...😭
Git Flow
엉망진창이 된 버전을 보면서 버전 관리와 브랜치 전략의 필요성을 절실히 느끼게 되었습니다.
브랜치 전략으로는 GitFlow를 언급하지 않을 수 없는데요. 아래는 흔히 사용하는 Git Flow의 사진입니다.
혼자서 개발하더라도 Git Flow에서 정말 사용할 부분만 뽑아도 라이브러리를 개발할 때는 적어도 develop, hotfix, release, master 정도의 브랜치는 있어야되지 않을까요?
2.4 CI/CD를 적용하자
버전 관리와 브랜치 전략과 CI/CD는 빼놓을 수 없는 관계라고 생각합니다.
특정 브랜치 전략으로 CI/CD 자동화를 걸어놓으면 비로소 최종 결과물이 완성되는 것이지요.
CI/CD에 대해 간략하게 설명하자면 아래와 같습니다. (일전에 Portfolio 시리즈 에서 기술한 내용을 인용하였습니다.)
CI/CD
CI/CD는Continuous integration & Continuous deployment의 줄임말로서, 지속적인 통합과 배포를 의미하는데, 쉽게 말해 소프트웨어 코드를 병합하여 배포파일을 만들고 서버에 이를 배포하는 과정들을 자동화하는 것을 의미합니다.소스를 DVCS(Git) 서버에 올리기만 하면 순차 처리자(자동화 도구)가 이 과정들을 알아서 처리하는 것이지요.
GitHub Actions
GitHub에서는 GitHub Actions라는 도구로 CI/CD를 지원합니다.
자동화 도구를 사용하지 않고 생으로 배포하다보니 한번은 데스크톱을 바꾸게 되었더니 기존 환경세팅이 전부 날아가서 한동안 라이브러리 배포를 못해 애먹은 적이 있습니다.
이러한 일을 미연에 방지하기 위해 앞으로 개발한 라이브러리 배포전에 CI/CD를 구축해보려고 합니다.
💎 Reference
💎 마치며
글을 마치며, 개발여정이라고는 했지만 거의 일기장 수준으로 재밌게 작성했네요😊 역시 회고록 쓰는게 제일 재밌는거 같아요. 많은 분들에게 도움이 되셨으면 좋겠습니다.❤️
사실 마치는 글을 항상 쓰면서 누군가 내글을 읽기는 할까? 라는 생각을 했었는데 포스팅을 보고서 메일주신 분, 댓글 달아주신 분들 덕분에 보람참을 느꼈어요! 너무 감사해요.😊😊
소통하며 지내요 우리🙌
잘 봤습니다. 좋은 글 감사합니다.