본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다
패스트캠퍼스 환급챌린지란?
(~6/20) 50일의 기적 AI 환급반💫 | 패스트캠퍼스
초간단 미션! 하루 20분 공부하고 수강료 전액 환급에 AI 스킬 장착까지!
fastcampus.co.kr
https://fastcampus.info/4n8ztzq
주말에도 재미있게 강의를 들을 수 있게 해주는 환급챌린지 최공!
34일차 공부 시작!
오늘의 강의 주제는 '차트 라이브러리 만들어보기-라이브러리 설계 원칙'이다.
(오늘도 마찬가지로 모자이크 처리..)
오늘의 학습 내용
- 라이브러리를 설계할 때 반드시 고려해야 할 원칙들 -
* 코드 인터페이스의 일관성
가장 먼저 강조된 것은 인터페이스의 일관성이다. 라이브러리를 만든다는 것은 궁극적으로 사용자에게 여러 기능을 제공하는 접점(interface)을 설계한다는 것과 같다. 여기서 말하는 인터페이스는 단순히 UI를 의미하는 것이 아니라 함수와 클래스의 이름, 동작 방식, 파라미터 구조 등 사용자가 사용하는 모든 코드 구성 요소를 뜻한다.
예를 들어, 어떤 곳에서는 get과 set으로 구성된 메서드를 제공하면서, 다른 곳에서는 느닷없이 update라는 이름을 사용하는 식이라면, 사용자는 매번 매뉴얼을 뒤적여야 한다. 이런 불일치는 학습 비용을 높이고, 라이브러리를 사용하는 입장에서 큰 피로를 유발한다. 따라서 함수 이름이나 사용 방식에서 예측 가능한 일관성을 유지하는 것이 매우 중요하다.
* 오류 처리 방식의 통일성
그다음으로 중요한 원칙은 에러 처리의 일관성이다. 때에 따라 null을 반환하기도 하고, 또 어떤 메서드는 예외를 던지는 식으로 제각각이라면 사용자는 그에 맞춰 코드 구조를 다르게 잡아야 한다. 일관되지 않은 예외 처리 방식은 유지보수성과 신뢰성을 모두 떨어뜨린다. 때문에 라이브러리 설계 초기에 애러 처리 방식을 통일하고 모든 컴포넌트가 그 원칙을 따르도록 설계해야 한다.
* 버전 관리의 원칙: 시맨틱 버저닝
더 좁은 범위이지만 실무에서 중요하게 작용하는 원칙으로는 버전 관리를 들 수 있다. 규모가 작을 때는 잘 느껴지지 않지만, 하나의 프로젝트가 시간이 지나 점점 커지고 나면 각 변경 사항을 관리하기가 어려워진다. 이때 필요한 것이 바로 시맨틱 버저닝(Semantic Versioning)이다.
시맨틱 버저닝은 주로 1.0.0 형태로 구성되며, 각각 메이저 버전, 마이너 버전, 패치 버전을 의미한다. 패치 버전은 단순한 버그 수정이며, 기존 사용자는 아무런 수정 없이 그대로 사용할 수 있다. 마이너 버전은 기능이 추가되긴 했지만 기존 코드는 여전히 작동하게 설계된다. 반면, 메이저 버전은 구조 자체가 변경될 수 있어 기존 코드가 호환되지 않을 수 있다. 따라서 어떤 수준의 변경인지, 사용자가 업데이트해도 되는지는 이 버전만 봐도 어느 정도 예측할 수 있다.
npm 등에 라이브러리를 올리지 않더라도, 시맨틱 버저닝의 원칙을 따르면 소프트웨어의 신뢰도를 높이는 데 큰 도움이 된다.
* 문서화의 중요성과 자동화
마지막으로, 문서화의 필요성을 짚고 넘어갈 필요가 있다. 라이브러리의 코드를 직접 읽고 이해할 수 있는 사람은 극히 일부이며, 대부분의 사용자는 문서를 통해 기능을 이해하고 사용하게 된다. 문제가 되는 점은, 코드가 언제든 바뀔 수 있는데 문서는 항상 늦게 혹은 누락되기 쉽다는 것이다.
이를 보완하기 위해 코드 기반 자동 문서화를 활용하면 좋다. 대표적인 도구로는 JSdoc이 있다. /** ... */ 형태의 특수한 주석을 붙이면, JSdoc이 이를 읽어 HTML 형태의 문서로 생성해 준다. 이렇게 자동 생성되는 문서는 코드 변경 시 함께 갱신할 수 있어서 문서와 구현 간의 괴리를 줄일 수 있다. 협업 시에도 큰 도움이 되며, 논의의 기준점으로 활용할 수 있다.
(36강인데 35강으로 밀려썼습니다. 챕터 title 확인)
마치며
오늘도 환급 챌린지 36강 공부 완료!!
이번 강의를 통해 단순한 기술 구현을 넘어서 하나의 라이브러리를 소프트웨어로서 제대로 구성하고 운영하기 위한 원칙들을 배울 수 있었다. 이름 짓기, 오류 처리, 버전 관리, 문서화와 같은 영역들은 사소해 보이지만 장기적으로 개발자의 신뢰도와 생산성을 결정짓는 매우 중요한 요소들이기 때문에 앞으로도 한 번 더 생각하고 하도록 해야겠다.