- LegiNote 프로젝트 개발 이야기1 - 아이디어
- StatPan이 국회 법률안 및 회의록에 대한 접근성을 높이고 AI를 활용한 입법 효율 향상을 목표로 LegiNote 프로젝트를 시작했습니다.
AI가 번역한 다른 언어 보기
durumis AI가 요약한 글
- LegiNote 프로젝트는 웹 서비스 개발을 위해 Svelte, Rust, Go, Python 등을 활용하며, 특히 Go로 개발된 워커는 OpenAPI 데이터 수집 및 업데이트 역할을 수행합니다.
- 워커는 데이터 수집 로직 설정, 실행, DB 적재 등의 기능을 수행하며, 다양한 API 데이터에 대한 확장성을 목표로 합니다.
- 프로젝트는 디펜던시 최소화를 위해 기능별 폴더 분리를 통해 구성되며, PostgreSQL, pq, sqlx 등을 활용하여 데이터베이스 연동 및 쿼리 처리를 수행합니다.
안녕하세요 StatPan 입니다.
LegiNote 사이드 프로젝트의 개발기를 쓰고 있습니다.
이전편은 다음의 링크를 참고해주세요.
기본 아키텍쳐
태양토끼님 협찬 Leginote 설계
Leginote는 우선 웹 서비스로 개발이 될 것을 염두해두고 다음과 같은 기술 스택을 사용할 예정입니다.
프론트엔드: Svelte
백엔드: Rust (rupring을 매우 염두하고 있는데, 변할 수 있습니다)
워커: Go (필수 디펜던시를 제외한 극한의 std 사용을 추구)
데이터 분석: 파이썬(전처리부터, 추후 인공지능까지 접목)
위 스택에서, 제가 중점으로 기여하는 영역인 워커, 데이터 분석 부분을 중점으로 개발기를 연재 예정입니다.
우선 워커 이야기를 해봅시다.
워커
언어의 선택
golang logo
저는 파이썬으로 프로그래밍을 시작했고, 현재 주 업무가 데이터 사이언스 분야인 만큼 파이썬 언어가 가장 익숙합니다. 그러나 스크립트 언어만 알고 있던 저는 든든한 컴파일 언어에 대한 욕심을 가지게 되면서 Go와 Rust 언어에 관심을 가지게 되었습니다.
특히 요 근래 가장 관심을 가지고 지켜보던 언어가 Rust 였는데, Rust가 대표적으로 함께 언급될 때 C++과 Golang이 함께 있었죠. (물론 C++도 우수한 언어이지만 이러한 네트워크 관련 서비스 개발에서는 제외 했습니다. 앞으로도 딥러닝 프레임워크 내부를 다루는게 아닌 한 직접적으로 다룰지 잘모르겠네요)
이렇게 Rust와 Golang을 학습하고 간단한 네트워크 요청에 사용해보면서 Rust의 장단점과 Golang의 장단점을 간단하게 파악했습니다. 이 글에서 둘의 장단점을 따지기에는 글이 길어지니, 다른 편에서 별도로 정리하는 것이 좋을 것 같아서 간단하게만 언급하자면
네트워크 분야에서 추가 디펜던시 없이 구성 가능하고, 매출이 일어날지 알 수 없는 미지의 프로젝트를 진행하기에 Golang을 사용하기로 결정하였습니다.
워커 역할
OpenAPI 화면
워커는 역할은 매주기마다 OpenAPI 사이트를 통해서 데이터를 수집 및 업데이트 하는 것으로, 다음의 3가지로 나눠볼 수 있습니다.
1. 특정 정보에 대해 수집 로직 설정
2. 수집 로직을 실행하는 러너 설정
3. 수집데이터 DB 적재
위 3가지의 동일한 절차를 다양한 API 데이터에 대해 동일하게 적용하며 확장해 나가는 것이 목표 입니다.
프로젝트 구성 방안
프로젝트의 구성에 대해서 다양한 아키텍쳐가 존재하며 특히 프레임워크를 사용하면 프로젝트 시작부터 구조를 갖춘 상태로 시작을 할 수 있습니다. 단, 위 언급한대로 이번 프로젝트에서는 디펜던시를 최소화하며 개발 하는 것을 목표로 두었기에 위 정의한 로직의 구현과 가깝게, 각 기능별로 폴더를 분리하고자 했습니다.
프로젝트는 아래와 같이 구성됩니다.
leginote-worker-bill/
├── main.go
├── api/
│ └── client.go
├── db/
│ ├── connection.go
│ └── repository.go
├── util/
│ ├── error.go
│ └── runner.go
│ └── config.go
├── worker/
│ └── worker.go
├── go.mod
└── go.sum
api - 데이터 수집은 공공데이터 OpenAPI를 통해서 수집을 합니다. 따라서 OpenAPI와 통신하는 기본적인 코드는 api 폴더 아래로 들어가게 됩니다. 현재는 1개의 API만 메인으로 사용하기 때문에 1개의 클라이언트 파일로만 구성되어 있습니다.
db - DB와 통신하는 로직이 정의되어 있습니다. connection 내부 코드는 connection만 담당하며, repository에는 다양한 upsert SQL을 담아 실행하는 로직이 있습니다. SQL 자체가 코드에 있는 것은 역시 너무 복잡해서 SQL은 추후 별도의 파일로 만들려고 합니다.
util - 작업을 하면서 기능을 보조하는 다양한 로직을 정의해둔 곳입니다. error는 go에서 나오는 error result를 편리하게 처리하기위해 임시로 만들어둔 스크립트 입니다. 이후 뒤 개발 이야기의 내용에서 나오겠지만 이게 엄청난 나비효과의 원인이 됩니다(?)
config 파일은 .env 파일을 읽을 때, 별도의 패키지를 쓰기 않기 위해서 .env 파일을 읽는 함수를 직접 정의한 파일입니다.
worker - api 및 db 로직을 적절히 사용해서 원하는 동작을 만들어내는 주요 로직이 담긴 곳입니다. 나중에 워커 종류가 늘어나면 마찬가지로 늘어나야 할 상황인 것 같은데, 우선 1개의 메인 워커 동작만 담겨있습니다.
추후, 계속해서 레이어드 아키텍쳐의 원칙이 지켜진 상태에서 코드를 발전시켜볼 계획입니다.
프로젝트 디펜던시
postgres 사용을 위한 pq
쿼리 사용을 위한 sqlx
워커 마무리
코드없이 이론만 나열하는게 왠지 재미 없을 것도 같고, 저도 조금 늘어지는 것 같아 조금은 빠르게 마무리하는 것 같네요
벌써 2편은 끝입니다. 3편 부터는 코드 한줄이라도 더 들고와서 이야기를 나누면 좋겠다는 바램이 있네요
레지노트 개발간에, 필요하다고 생각하시는 기능이 있거나, 또는 개발에 관해서 궁금하신 점 언제든지 댓글 해주세요!