들어가며 ACOR v1.2.0을 릴리즈했다. 이번 버전은 프로젝트 구조를 Go 표준으로 정리하고 몇 가지 버그를 수정하는 데 집중했다. 표준 프로젝트 구조로 변경 v1.2.0에서는 Go 커뮤니티의 표준 프로젝트 레이아웃을 따르도록 구조를 변경했다 (#2). Go 프로젝트가 성장하면서 파일 구조를 체계적으로 관리할 필요가 있었다. Standard Go Project Layout 가이드라인을 참고하여: pkg/: 외부에서 import 가능한 패키지 코드 internal/: 내부 전용 코드 cmd/: 메인 애플리케이션 이런 구조를 적용함으로써 프로젝트의 의도를 더 명확히 전달할 수 있게 되었다. 지원 Go 버전 변경 Go 버전 지원 정책을 업데이트했다 (#5). ...
들어가며 ACOR v1.1.0을 릴리즈했다. 이번 버전은 새로운 기능 추가보다는 프로젝트의 기반을 현대화하는 데 집중했다. Go 생태계의 변화에 맞춰 의존성 관리와 CI/CD 시스템을 최신 표준으로 전환했다. 왜 Go modules로 전환했는가 ACOR은 처음 Glide를 사용해 의존성을 관리했다. Glide는 Go에 공식 의존성 관리 도구가 없던 시절, 커뮤니티에서 널리 사용되던 도구였다. 하지만 Go 1.11부터 Go modules가 공식으로 도입되면서 상황이 바뀌었다. Glide의 한계는 명확했다: 유지보수 중단: Glide는 더 이상 활발히 개발되지 않는다 버전 관리: 정확한 버전 고정과 의존성 트리 관리가 번거롭다 재현성: 다른 환경에서 동일한 빌드를 보장하기 어렵다 Go modules는 이 문제들을 해결한다. go.mod 파일 하나로 의존성을 관리하고, Semantic Versioning을 기반으로 버전을 제어한다. 무엇보다 Go 도구 체인에 내장되어 있어 별도 설치가 필요 없다. ...