gocore: 서비스 셋이 함께 쓰는 Go 공용 라이브러리
Node로 만든 코인충 서버를 Go로 다시 쓰면서 Go 서비스가 셋이 되었습니다. 같은 뼈대를 세 번 만들지 않으려고, 다시 쓰기 전에 공용 라이브러리를 먼저 뽑았습니다.
2026-10-25 작성
- Go
- PostgreSQL
- Redis
- Prometheus
01무슨 문제였나
서비스마다 설정, 로깅, 캐시, 락, 모니터링, 데이터베이스 연결을 따로 만들면 같은 일을 세 번 하게 됩니다. 서비스가 둘일 때는 견딜 만하지만 셋이 되면 어느 한쪽의 고침이 다른 쪽에 닿지 않습니다. Node에서 Go로 옮기면 서버 메모리도 크게 줄어드니 옮길 이유는 분명했습니다. 그래서 다시 쓰기 전에 공통 뼈대부터 뽑았습니다. 이름은 여기얼마 서버의 core 디렉터리를 이어받았다는 뜻입니다.
02어떻게 만들었나
무엇을 넣을지는 세 가지 기준으로 정합니다. 도메인과 무관할 것, 이미 두 서비스 이상이 쓰고 있을 것, 전역 상태 없이 주입해 쓸 것. "나중에 쓸 것 같다"는 이유로는 넣지 않습니다.
공통으로 둔 것은 웹 요청 처리, 에러 응답 형식, 캐시와 락, 백그라운드 작업, 푸시 알림, 로그와 지표입니다. 세 서비스가 같은 형식의 에러와 같은 이름의 지표를 내므로 모니터링 대시보드도 하나로 충분합니다. 같은 일을 하는 구현이 여럿인 곳은 같은 시험을 모두 통과해야 합니다.
03운영과 숫자
지금은 패키지 27개를 세 서비스가 함께 씁니다. 코드는 비공개 저장소에 있고, 경계를 지키는 일은 사람의 기억 대신 자동 검사가 맡습니다. 공통 부분을 한곳에서 고치면 세 서비스가 같은 주에 함께 좋아집니다. 한 서비스에서 겪은 문제를 한 번 고치면 나머지에도 같은 해결이 닿고, 새 서비스를 만들 때도 뼈대를 처음부터 짜지 않아도 됩니다.
04배운 점
처음에는 부품을 따로 떼어 관리했다가 하나로 합쳤습니다. 모두 직접 운영하는 서비스라 나눠 두는 비용이 이득보다 컸기 때문입니다. 한계도 압니다. 쓰는 곳이 전부 내 서비스일 때만 통하는 방식이라, 외부 사용자가 생기면 다시 설계해야 합니다.
이렇게 만들고 운영하는 방식 그대로, 고객님의 서비스를 만들어 넘겨드립니다.
1~2개월 동안 실제로 운영되는 서비스를 함께 만들고, 그 뒤에는 AI로 직접 고치고 키울 수 있게 넘겨드립니다.