기록하는삶

[논문 리뷰] Qwen3-ASR

mingchin — Wed, 11 Mar 2026 22:30:08 +0900

1. 한 줄 핵심 요약

52개 언어를 지원하며 단일 아키텍처로 스트리밍과 오프라인 추론을 모두 완벽하게 소화하는 고효율 오픈소스 음성 인식(STT) 및 강제 정렬(Forced Alignment) 모델. STT는 1.7B와 0.6B 모델, Forced aligner는 0.6B 모델 공개.

2. 연구 배경 및 문제 정의

상용 API와의 성능 격차: 기존 오픈소스 ASR(자동 음성 인식) 모델들은 강력한 상용 서비스(API)에 비해 다국어 처리나 복잡한 환경(노이즈, 노래 등)에서의 인식률이 부족
스트리밍/오프라인 아키텍처의 파편화: 실시간(Streaming) 서비스와 대용량 오프라인 처리를 위해 보통 구조가 다른 별개의 모델을 운용해야 하는 번거로움이 존재 << 매우 공감하는 부분
타임스탬프 추출의 한계: 정밀한 텍스트-음성 동기화에 필수적인 '강제 정렬(Forced Alignment)' 모델 중, 다국어를 빠르고 정확하게 지원하는 통합 솔루션이 부재

3. Contributions

SOTA급 다국어 모델 공개: 52개 언어와 방언을 지원하며 Whisper large-v3를 능가하는 1.7B 모델과, 효율성에 극대화된 0.6B 모델을 Apache 2.0 라이선스로 오픈소스화.
스트리밍/오프라인 통합: 동적 윈도우 크기를 조절하는 메커니즘을 통해 하나의 모델로 짧은 실시간 청크부터 최대 20분에 달하는 긴 오디오까지 유연하게 처리.
NAR 기반 강제 정렬 모델 제안: 기존의 Auto-regressive 방식이 아닌 Non-Autoregressive(NAR) 방식으로 빠르고 정확하게 단어/문장 단위 타임스탬프를 예측하는 Qwen3-ForcedAligner-0.6B 최초 공개 → forced aligner 쪽은 대충 봤는데, 기존의 Montreal Forced Aligner를 사용해 pseudo-labeling하고, 몇 가지 학습 기법을 적용해 정확도를 끌어 올렸다고 한다. 사실 근데 이건 별 기대 안되고.. 커뮤니티 반응도 좀 봤었는데 그냥 그렇다는 글을 몇 개 봤었다. 하지만 그 필요성과 잘 연구 안해주는 분야인데 공개하준 것에 감사하다.

4. 방법론 / 아키텍처

AuT (Audio Transformer) 인코더 (~300M): 128차원의 Fbank(Mel-spectrogram 기반) 특징을 입력받아 8배 다운샘플링하여 12.5Hz 주기로 표현 공간을 압축한다. 핵심은 동적 윈도우(1~8초)가 적용된 FlashAttention으로, 이를 통해 컨텍스트 길이에 구애받지 않고 유연하게 작동한다. → ASR로 사전 학습된 인코더를 가져온다. 무려 40million.. / next kaldi인 K2 쪽에서도 관련 기법을 보았었다. 실시간 모델을 따로 두지 않고 통합하는 시도가 맞는 방향이다.
Qwen3-Omni 기반 백본: Qwen3-Omni 사전 학습 모델을 기반으로 하여 풍부한 언어 이해 능력을 ASR 태스크에 그대로 이식했다. 이미지, 오디오, 텍스트 input을 받을 수 있는 멀티모달 기반으로 3 trillion 토큰을 사전학습을 한 뒤, ASR에 맞게 finetuning 되었다고 한다.
ASR supervised finetuning: (Omni 기반이다보니) Instruction-following)을 억제하는 스타일 전이(Style Transfer) 학습, 묵음에 강인하도록 별도 학습

묵음 별도 학습은 정말 필요하다.

Reinforcement Learning: GSPO(Group Sequence Policy Optimization)를 적용했다고 하는데, 이는 따로 읽어봐야 할 것 같다. 쨌든 강화학습을 통해 잡음에 대한 강인성, 방언 등 어려운 발음에 대한 인식률을 끌어올렸다고 한다.

5. 실험 설계 및 결과

평가 지표: 내부 및 다수의 오픈 벤치마크 데이터셋 사용, TTFT(Time-to-First-Token), Throughput(처리량), Alignment Shift(정렬 오차).
실험 결과:
- 1.7B 모델: 오픈소스 최고 수준의 정확도(SOTA) 달성 및 주요 상용 API와 대등한 성능 → 한국어 체감 성능 매우 훌륭
- 0.6B 모델 (효율성): 평균 TTFT 92ms 달성. 동시 요청(Concurrency) 128 기준, 1초의 연산 시간으로 2,000초 분량의 음성을 전사하는 놀라운 처리량을 입증
- 강제 정렬 모델: 기존 강제 정렬 모델들 대비 타임스탬프 오차율(Shift)을 67~77% 감소

미쳐버린 수치다

6. 후기

whisper야 안녕: 실시간과 배치를 모두 고려한 모델을 만들었다는 점, LLM 백본을 사용해 문맥에 강점이 있는 것, 동시처리면에서 압도적인 성능을 보이고, vllm으로 추론이 가능하다는 점, large-v3가 뭔가 맛이 가고.. finetuning 시에 오히려 성능이 떨어지고 할루시네이션이 심해진다는 점(나만의 경험이 아니라 다수의 의견임을 최근에 확인했다) 등을 고려할 때, whisper의 시대가 가버린 것 같다. 실제 보유한 벤치마크 성능도, 체감 성능도 whisper보다 좋았다.
직접 finetuning도 해보고 추론해본 결과, 할루시네이션에 특별히 강점이 있는지는 잘 모르겠다. whisper 대비 나은 것은 맞지만, 잡음이나 babble 등에 약한 것은 어쩔 수가 없다.
공개된 것처럼 vllm 기반 추론 + 동시처리 성능은 압도적이다. 다만 내가 구현할 때 기준으로 실시간 알고리즘은 공개했다고는 하지만 그냥 앞에서부터 누적하면서 반복 추론하는 불쉿코드가 공개된 상태였기 때문에, 직접 실시간에 가까운 windowing 추론을 구현해야했다. RTF도 정말 말도 안되는 수준이라, 웬만한 배치 추론은 벌써? 하는 시점에 결과가 나와있다.
TTFT 직접 측정해봐도 120ms 수준이었다. (1.7B 모델) 부하를 걸면 점진적으로 증가하긴 하지만, 매우 안정적인 편이다. 특정 지점까지는 거의 변화가 없었다.
cross-lingual / code switching도 꽤 잘 되는 편이다. finetuning 하면 이 부분이 희석될 수 있다고 생각하는데, 어떻게 해야 성능을 유지 또는 보완할 수 있을지 고민이 필요하다.
스케일링이나 학습 기법의 규모가 너무 압도적이라.. 사실 뭐 우리나라가 따라갈 재간이 있나 싶다. 사용된 데이터의 양도 그렇고, 멀티모달리티 기반 백본 학습 후 finetuning, 거기에 강화학습까지.. 한국어 전용으로 학습한다고 해도, 여기에 finetuning 하는게 훨씬 나아보인다. 공개된 학습 데이터들의 전사 규칙이 일관되지 못한 것이 문제가 되는데, 적당히 큰 LLM에 프롬프트 잘 만들어서 ITN 시키면 어느 정도 학습에 용이한 형태의 데이터를 만들 수 있었다.
매우 최근에 공개된 프레임워크로, 최신 아키텍쳐를 지원하는 것도 강점이다.
TO DO
- forced aligner 관련해 추가로 살펴보기
- 강화학습 관련 논문 보기 - 데이터 스케일링의 다음 단계로 RL은 이제 그냥 필수로 붙는 것 같다. 좀 더 많이 알아야 함.

[회고] 2년차를 마무리하며 - 모델러, 그리고 개발자로서의 성장

mingchin — Sun, 9 Feb 2025 21:42:23 +0900

0. 들어가며

24년은 1년을 꽉 채워 회사를 다닌 첫 해였다. 내 밑으로도 사람이 들어오고, 위로도 한 명이 나가며 자연스럽게 역할이 커진 한 해였다. 대외적으로는 Whisper를 필두로 시장이 혼란하고 어려웠고, 그래서인지 나름 경쟁력이 있던 모델의 성능이 이슈가 되기도 했다. 사내에서 근본적으로 해결해야 하는 문제를 많이 발견하여 불만이 가득한 한 해를 보냈다고 생각했었는데, 돌아보니 늘 문제제기를 하는 데에 그치지 않고 무언가 변화와 해결을 시도했던 덕에, 꽤나 많은 것들이 달라지기 시작했다는 것이 보여 뿌듯하기도 한 1년이었다.

1. 올해의 keywords

올해의 키워드 3개를 꼽아보자면,

"모델러와 개발자로서의 성장, 선한 영향력, 지속 가능성의 향상"

이라 말하고 싶다.

1-1) 모델러 & 개발자로서의 성장

작년에는 주로 데이터를 수집/정제하여 신규로 모델을 학습하는 일에 치중하고, 개발은 이미 만들어진 무언가에 손을 보태는 정도였다면 올해는 이미 성능이 어느정도 확보된 모델을 고도화하며 보다 심도 있는 문제정의와 해결을 도모하고, 그것을 위해 필요한 개발을 주도하는 과정에서 개발 실력 자체도 많이 성장했다. 단순히 기능하는 개발이 아닌 유지보수성, 확장성, 편의성 등을 고려하는 일종의 시큐어 코딩을 하기 시작했다는 점에서 나에게 칭찬을 해주고 싶다.

퇴사자가 생기며 16kHz 한국어 모델 학습을 맡게 되었고, 이미 어느정도 성능이 확보된 상황이었으나 아래의 문제가 있었다.

데이터를 추가로 append 하는 것 외에 학습 목표가 설정되지 않음
일부 음절은 아예 추론이 불가능
음절 인식률은 높으나, 단어 인식률이 상대적으로 떨어짐
학습이 매우 불안정하여 epoch별 모델의 성능 편차가 크게 나타남, 특정 epoch에서는 비정상적으로 성능이 낮음

이미 영어 모델 학습 과정을 모니터링하고 분석하면서 위의 문제들에 대한 해결 방안을 어느 정도 준비해 둔 덕에, 수월하게 목표를 설정하고 성능을 향상시킬 수 있었다. 학습 목표를 인식률 향상 뿐 아니라 베이스 도메인 확장에 두고, 품질이 낮은 데이터를 걸러내는 기법을 적용해 학습 안정성 또한 확보하고자 했다. 또한 토크나이저를 개편하여 일부 꼭 필요하나 누락됐던 음절들을 포함시키고, 띄어쓰기를 기존과 다른 방식으로 접근해 단어 인식률 향상폭을 키울 수 있었다. 각 epoch별 인식 경향에 대한 분석과 평가 셋별 다르게 나타나는 양상들을 꼼꼼히 분석한 덕에 sudo labeling으로 오염된 학습 데이터를 찾아내고, 현 모델 구조의 약점을 보완할 augmentation 기법 개발의 필요성을 발견할 수 있었다. 스케줄러 변경을 통해 학습 관리를 보다 용이하게 하고, 기존 파라미터들 중 활용할 수 있는 것들을 조정해 보다 robust한 모델을 학습하는 데 성공했다.

빌더 내 저품질 데이터 탐색이나 평균 모델 생성 등의 기능을 개발한 것 외에도 이미 타인에 의해 만들어진 프로젝트를 뜯어 고치는 과정에서 정말 많은 스트레스와 함께.. 개발 능력을 성장시킬 수 있었다. 산소는 부족할 때나 숨이 막히는 기분을 알게 되듯, 작년 VAD 개발 시 훌륭하게 구조화 및 모듈화된 프로젝트를 커스텀할 때는 몰랐던 문제들을 마주하며 다시금 개발 단계에서 중요한 것들에 대해 돌아보게 되었다. Typehint나 docstring, dataclass 기반의 config 관리, typer 기반의 action 관리, docker를 통한 dependency 관리, 프로젝트 구조화, 기능별 함수 및 객체 분리의, logging과 예외처리 등의 중요성과 필요성, 그리고 무분별하게 복사되어 여기저기 중복돼 존재하는 코드들이 어떻게 나에게 고통을 선사할 수 있는지 등등.. 담담하게 나열만 했지만 정말 뼈저리고 아프게.. 중요한 것들을 체감하고 덕분에 지금까지 가졌던 좋지 않은 습관들로부터 멀어질 힘을 얻었다. 당장 기능하게 만드는 것보다 선행되어야 하는 것들이 저렇게나 많으며, 결국 "빠른" 개발이 아니라 "좋은" 개발을 추구할 때 지수적인 효율 상승까지 따라온다는 것을 잊지 않아야겠다. 그렇게 경험치와 분노를 쌓은 나는 음성인식 학습기도 싹 갈아엎어 재구조화하고, 엉멍으로 개발된 코드들을 다 뜯어고치는 작업을 한 달만에 해치우며 MLOps 관련 개발을 진행할 준비를 마쳤다. 작년에는 엄두도 안났던 것이 이제는 나에게 당연한 것이 되었다.

1-2) 선한 영향력

현재 파트장을 포함해 총 5명이 하나의 파트로 기능하고 있으나, 사실 4명의 파트원들은 거의 개인 프로젝트를 진행하는 것처럼 일이 분배되어 있다. 각자 무엇을 하는지 일, 주 단위로 공유하고 서로 인사이트를 주고 받기도 하고, 때로 손이 필요하면 서로 돕기도 하지만 대부분은 개인의 역량에 따라 프로젝트의 진행 속도나 완성도, 성패가 크게 좌지우지 되고 만다. 이는 규모가 크지 않은 기업에서 어느정도 필연적인 부분이지만.. 나아지는 방향으로의 변화의 바람이 나에게는 필요했다.

가령 git 기반 협업 및 코드 공유의 경우 작년에 도입하여 이제는 자연스러워지긴 했지만, 여전히 PR에 대한 리뷰나 이슈 등록 및 해결, github action 등을 활용한 CI/CD로의 확장 등에 대해서는 진전이 더뎠다. 모든 것이 자율에 맡겨지면 결국 "하는 사람만 하는" 것이 되어버리고, 좋은 문화가 자리잡기는 어렵겠다는 생각이 들었다. 그래서 간단한 작업부터 참여가 적은 파트원에게 직접 PR을 올리고 리뷰 요청을 하거나, 리뷰에 참여하여 그것이 피드백되는 과정에서 어떤 잠재적 위험이 예방될 수 있는지를 경험할 수 있도록 했다. 가장 최근에 내가 올렸던 대규모 업데이트 사항에 대한 PR에서 해당 팀원은 자발적으로 테스트에 참여해주면서 몇 가지 버그 제보와 개선사항에 대해 코멘트를 주었고, 덕분에 빠르게 반영하여 보다 나은 업데이트를 완성할 수 있었다. 구구절절 이론적 설득보다도 결국 본인이 기여하고 있다는 것과 그 기여의 효용을 직접 체감했을 때 가장 빠르게 설득이 가능하다고 믿는다.
또한 프로젝트 진행 시 꼭 필요하지만 거의 생략되던 중요한 문서화 과정들을 팀 내 문화로 자리잡게 하기 위해 노력중이다. 너무 많은 문서는 개발의 방해 요소가 되기도 하지만, 그렇다고 아무 문서도 필요 없다는 것을 뜻하지는 않는다. 최소한의 기확안과 요구사항 정의, 기능 정의, 테스트가 제대로 이루어지고 그것이 문서로 남을 때 프로젝트가 안정적으로 진행될 수 있고, 진행된 프로젝트에 대한 복기나 피드백 역시 가능하다고 생각한다. 우리는 그 어떠한 문서도 관리자로부터 요구받지 않아, 거의 사실상 자율에 맡겨진다. 실무자 입장에서 수고를 덜 수 있다고 생각할 수 있지만, 사실 굉장히 자주 방향을 잃거나, 무언가 빠뜨리거나, 애초부터 잘못된 기획이나 설계임을 뒤늦게 깨닫거나, 문제가 발생했을 때 복기나 피드백을 요청하고 싶어도 본인 머릿 속 외에는 아무런 정보가 없으니 구두로만 소통해야 하는 등.. 훨씬 더 많은 수고가 따라오는 것이 대부분이다.
한 개의 프로젝트에 집중할 수 있을 때는 나도 체감하지 못하던 문제들을 점점 업무가 많아지며 더 크게 느끼게 되었고, 우리 업무환경에 맞게 크게 3개 depth의 문서를 기반으로 프로젝트 진행 및 파트장과의 소통을 시도했다. 사실 이 시도는 아직까지 반쪽짜리 성공에 가깝다. 아직까지 문서 기반으로 소통하는 것의 중요성과 필요성이 채 다 어필이 되지 않은 느낌이 강하고, 팀 내에서도 다른 파트원들의 따라오려는 시도가 있었지만, 거의 나 혼자 진행하고 있다시피 한 부분이다. 그 이유는 열심히 작성해두어도 관리자 그 누구도 이에 기반에 성과를 확인해주거나 진행 상황을 이해해주지 않기 때문이 가장 크다. 그래도 해당 논의가 반복해서 이루어진 덕에, 진행 과정에서 문제가 발생했을 때 "요구사항 정의가 제대로 이루어졌다면", "우리가 좀 더 상세하게 정의된 기능 개발 목표에 기반해 소통할 수 있다면" 과 같이 그 필요성과 효용성에 대해 더 건설적인 논의가 이루어지고 있으며, 이번에 진행되는 새 프로젝트에 한해서라도 해당 부분을 제대로 시도해보자는 요청이 받아들여질 수 있었다.

외에는 github action에 기반해 배포 자동화 등의 가능성을 제시하고, versioning과 모델 배포 파이프라인의 효율화의 필요성을 설득하여 이 부분에 대한 개발이 진행 중이거나 예정되어 있다. 나 혼자 하는 것이 아닌 좋은 사레나 상황을 만들어 타 팀원들이 함께할 수 있도록 영향력을 끼치는 것에서 보람을 느낀다.

1-3) 지속 가능성의 향상

2와 연결되는 이야기인데, 아직 열정이 넘치는 햇병아리로서 지속 가능성을 위한 고민을 시작했다는 점에서 만족스럽다. 여전히 성장에 목마르고, 개발이 재미있는 것은 동일하나 작년에 비해 좀 더 평균적으로 좋은 퍼포먼스를 낼 수 있도록 나를 관리하려고 노력했다. 작년에는 성과를 내야 한다는 압박과 함께, 즐거우면 끝도 없이 몰입하는 특성에 브레이크를 걸지 않아 시도때도 없이 집에 와서도 들여다보고, 휴일에도 계속 업무를 하는 일이 잦았다. 그것이 좋은 결과로 이어지는 경우도 많았지만, 때로는 지치고 스트레스가 쌓여 오히려 업무 시간에 집중력이 떨어지거나 실수가 늘어나기도 했다. 집에 와서나 휴일에 업무를 하는 것을 최대한 지양하고, 규칙적인 수면과 업무 시간을 유지하기 위해 노력했고, 그 덕에 회사에 있는 시간 동안의 평균적인 업무 효율이 좋아졌다는 느낌을 받는다. (이는 작년 말 회고에서 내가 이루고 싶었던 바와 부합하기도 한다.)
워낙 좋아하는 것과 그렇지 않은 것에 대한 온도 차가 커서, 문서화 하는 것에 대한 거부감이 컸었는데, 동시에 진행되는 업무가 많아지며 그 필요성을 더 체감하게 되었고, 결국 장기적으로 더 좋은 개발을 하기 위해서는 귀찮더라도 문서를 남기는 것이 꼭 필요하다는 생각 하에 더 많은 시간을 투자하기 시작했다. 막상 그렇게 해보니 문서를 작성하는 시간동안 개발의 방향이나 아이디어에 대해 꼼꼼하게 정리하게 되어 하고자 하는 것에 대한 이해가 더 깊어졌다. 또 작성된 문서에 기반해 개발 중간 단계에서도 계획대로 잘 가고 있는지 추가/수정해야 할 사항은 없는지 점검하는 것이 실수를 줄이는 데에 크게 도움이 되었다. 이는 개발 일정에 대한 대략적인 책정이나 조율에도 도움이 되어, 전보다 더 내가 특정 업무를 얼마의 시간동안 할 수 있는지에 대해 세분화하여 그려볼 수 있게 되었다.

또한 전에는 나의 업무가 아니더라도 파트 내에 벌어지는 모든 일들에 대해 관심가지며, 문제가 발생하지 않도록 하는 데에 많은 노력을 기울였다. 타 파트원이 진행하는 학습을 계속 모니터링 한다든가, 보고 자료에 기반해 조언을 한다든가. 의도 자체는 좋으나 타 팀원의 성장할 수 있는 기회를 제한하는 느낌도 있고, 나의 한정적인 에너지가 분산되어 같은 일도 더 힘들게 진행하게 되는 부작용이 있었다. 좀 더 나의 업무와 파트 내 중요한 일들에 집중하려고 노력하면서, 보다 긴 호흡에서 지속 가능한 형태로 나의 업무 습관과 환경을 만들어나가고 있다고 생각한다.

2. 3년차의 나에게 필요한 것

2-1) 더 작은 단위의 개발 진행 및 PR 요청하기

최근 한 구글 시니어 개발자의 영상을 인상 깊게 봤다. "업무를 얼마나 작은 단위로 잘게 쪼갤 수 있느냐"가 중요한 능력 중에 하나라는.. 올해 짧은 기간에 많은 개발을 진행해야 한다는 압박과 욕심 때문에, 대규모 업데이트를 너무 짧은 시간에 하나의 PR에서 다루면서 크고 작은 실수가 많이 발생하고, 아쉬움이 컸다. 이는 나 개인의 잘못보다도 올바른 과정에 대한 호소가 가 닿지 않는 사내 문화와 "새로운 프로덕트"만을 원하는 관리자 등 여러 환경적 요인에 기인하는 것이긴 하지만, 그러니 더더욱 나 자신이 좋은 개발자로 성장하는 데 있어 좋지 못한 습관이 몸에 자리잡지 않도록 노력하고 싶다.

2-2) 새로운 기술 스택의 장착

모델 배포 자동화나 엔진 개발 등 마침 올해 좋은 기회들이 있다. 사내에서 새 도전이 꺼려지는 이유 중에 하나는 과정으로의 실패나 좌절에 대한 여유가 주어지지 않는다는 점이다. 모델 배포 자동화의 경우에도 정말 중요한 아젠다임에도 고작 3주의 시간이 주어졌고.. 화자 분리 엔진 개발의 경우에도 새로운 언어에 적응하고 해보지 않은 엔진에 대한 도전임에도 정말 짧은 시간이 주어졌다. 기간 내에 그럴듯한 결과물을 내기 위해서는 하드코딩 위주의 수준 낮은 개발이 이루어지기 마련인데, 이번에는 VAD 개발 때의 실수를 반복하고 싶지 않다. (빌더를 "동작만 할 수 있게" 남겨둔 덕에 하자가 많다.) "해봤다"가 아닌 나의 새로운 기술 스택이 될 수 있도록, 올바른 과정으로 소화하고 경험하여 내 것으로 만들 수 있도록 노력하고 싶다.

2-3) 글로 남기기

항상 완성도가 떨어진다고 느껴 글쓰기가 꺼려지는데, 보다 많은 글을 남겨야 한다. 결국 텍스트화 하는 과정에서 한 번더 머릿속에서 정리되기도 하고, 나중에 다시 쉽게 떠올릴 수 있는 기반이 된다. 포트폴리오를 업데이트 하는 것을 포함해, 보다 많은 것들을 글로 남겨 내 자산으로 만드는 한해가 되기를!

[Rust] usize, 익명 함수 클로저와 기본 메서드

mingchin — Tue, 3 Dec 2024 23:43:04 +0900

지난 글에서 구현했던 함수를 뜯어보자.

usize

Rust는 함수의 output type을 꼭 지정해주어야 한다. "unsigned size"의 준말로, 시스템 포인터 크기와 동일한 크기를 가지는 unsigned integer다. 요즘엔 거의 다 64bit 시스템을 사용하니 8바이트라 보면 되겠다.

hyp.chars().filter(|c| !c.is_whitespace()).collect();

굉장히 파이써닉한.. 표현이 놀랍다. 하나씩 뜯어보면 아래와 같다.

hyp.chars():
- hyp 문자열을 문자(char) 단위로 분리하여 이터레이터를 생성합니다.
- 예: "hello world" -> ['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd']
.filter(|c| !c.is_whitespace()):
- 이터레이터에서 각 문자를 검사하여 공백 문자가 아닌 문자만 남깁니다.
- |c|는 클로저(익명 함수)로, 각 문자 c를 받아서 !c.is_whitespace() 조건을 검사합니다.
- is_whitespace()는 문자가 공백인지 확인하는 메서드입니다.
- 예: ['h', 'e', 'l', 'l', 'o', ' ', 'w', 'o', 'r', 'l', 'd'] -> ['h', 'e', 'l', 'l', 'o', 'w', 'o', 'r', 'l', 'd']
.collect():
- 필터링된 문자들을 모아서 새로운 컬렉션(예: 문자열)으로 만듭니다.
- 기본적으로 collect()는 이터레이터의 요소들을 모아 벡터(Vec)로 반환하지만, 타입 힌트를 주면 문자열로도 변환할 수 있습니다.

let hyp = "hello world";
let result: String = hyp.chars().filter(|c| !c.is_whitespace()).collect();
println!("{}", result); // 출력: "helloworld"

예시 코드상에서, result 라는 변수에도 형을 지정하고 값을 할당하는 표현이 있다.

익명 함수, 클로저

파이썬의 lambda와 유사한 역할을 하는 것으로 보인다. " |c| = lambda c:" 와 동일한 표현이며, 변수는 아래 3가지 방법으로 할당(캡처)할 수 있다.

참조로 캡처: &T - 클로저가 변수를 읽기 전용으로 캡처합니다.
가변 참조로 캡처: &mut T - 클로저가 변수를 수정할 수 있도록 캡처합니다.
값으로 캡처: T - 클로저가 변수를 소유하도록 캡처합니다.

기본적으로는 1의 참조로 캡처를 시도하며, 값으로 캡처를 하고 싶은 경우에는 "move"라는 별도 메서드를 사용해야 한다.

let haystack = vec![1, 2, 3];
let contains = move |needle| haystack.contains(needle);

println!("{}", contains(&1)); // true
println!("{}", contains(&4)); // false

// haystack을 다시 사용하려고 하면 컴파일 오류가 발생합니다.
// println!("There are {} elements in vec", haystack.len()); // 오류 발생

클로저가 변수의 소유권을 가져간다는 사실이 흥미롭다. 아마 사용과 동시에 변수를 해제하는? 느낌인 것 같다.

타입 캐스팅 as

"cer = (substitution_count + insertion_count + deletion_count) as f64" 와 같이 integer의 합산으로 계산한 결과를 f64 형으로 변환한다.

문자열의 할당 String::new()

빈 문자열을 할당하는 방법은 여러 가지가 있다.

# 1
let s = String::from("");

# 2
let s = "".to_string();

# 3
let s = String::with_capacity(0);

String::new()는 초기 버퍼를 할당하지 않는 mutable 객체로, 할당 시 메모리 비용이 저렴하다. 3의 방법과 동일하며, 0 대신 일정 바이트를 할당하는 경우 처음부터 그만큼의 메모리를 사용하게 되는데, 이는 추후 문자열을 추가할 때 재할당을 하지 않는 다는 점에서 차이가 있다.

io::stdout().flush().unwrap()

flush()는 버퍼에 쌓인 데이터를 즉시 출력하거나 전송한다고 한다.

use std::io::{self, Write};

fn main() {
    print!("Enter your name: ");
    // io::stdout().flush().unwrap(); // 이 줄을 주석 처리하면 메시지가 즉시 출력되지 않을 수 있습니다.
    let mut name = String::new();
    io::stdin().read_line(&mut name).unwrap();
    println!("Hello, {}!", name.trim());
}

실제 이렇게 실행해보니, 사용자 입력을 기다리는 동안 "Enter your name: "의 메시지가 출력되지 않는다.

unwrap()의 경우 해당 앞의 메서드가 정상적으로 실행되었는지 체크하는 예외처리로, 에러가 발생할 경우 프로그램을 패닉 상태로 만든다. (sys.exit()과 유사한 것 같다.)

io::stdout().flush().expect("Failed to flush stdout");

unwrap()이 아니라 expect()로 실행할 경우, 예외 발생에 대한 로깅을 할 수 있다.

[Rust] CER과 WER 계산하기

mingchin — Fri, 22 Nov 2024 23:48:15 +0900

세부 목표 설정

Rust 언어를 보다 재밌고 효율적으로 공부하기 위해 아래의 기능을 가진 안드로이드 앱을 만들어 볼 예정이다.

두 개의 빈 텍스트를 입력할 수 있는 공간을 가짐
셋 중 하나의 eval metric을 설정 가능(CER / WER / ALL)
두 개의 문장을 입력 후, "calculate"을 누르면 두 문장의 metric을 연산 후 TMSID를 포함해 출력

간단한 기능이지만 난 안드로이드의 a도 모르기 때문에.. 험난한 여정이 될 것이다.

CER / WER 연산하기

Copilot에게 CER에 대해서 설명하고, 띄어쓰기의 경우 음절에서 배제해야 한다는 사실을 말해주었더니 그럭저럭 기능하는 코드를 주었다.

use std::io::{self, Write};

struct CerResult {
    total: usize,
    match_count: usize,
    substitution_count: usize,
    insertion_count: usize,
    deletion_count: usize,
    cer: f64,
}

fn calculate_errors(hyp: &str, ref_: &str) -> (usize, usize, usize, usize) {
    let hyp_chars: Vec<char> = hyp.chars().filter(|c| !c.is_whitespace()).collect();
    let ref_chars: Vec<char> = ref_.chars().filter(|c| !c.is_whitespace()).collect();
    let mut match_count = 0;
    let mut substitution_count = 0;
    let mut insertion_count = 0;
    let mut deletion_count = 0;
    
    let mut i = 0;
    let mut j = 0;
    
    while i < hyp_chars.len() && j < ref_chars.len() {
        if hyp_chars[i] == ref_chars[j] {
            match_count += 1;
            i += 1;
            j += 1;
        } else {
            substitution_count += 1;
            i += 1;
            j += 1;
        }
    }
    
    if i < hyp_chars.len() {
        insertion_count = hyp_chars.len() - i;
    }
    
    if j < ref_chars.len() {
        deletion_count = ref_chars.len() - j;
    }
    
    (match_count, substitution_count, insertion_count, deletion_count)
}

fn calculate_cer(hyp: &str, ref_: &str) -> CerResult {
    let (match_count, substitution_count, insertion_count, deletion_count) = calculate_errors(hyp, ref_);
    let total_chars = ref_.chars().filter(|c| !c.is_whitespace()).count();
    let cer = (substitution_count + insertion_count + deletion_count) as f64 / total_chars as f64;
    
    CerResult {
        total: total_chars,
        match_count,
        substitution_count,
        insertion_count,
        deletion_count,
        cer,
    }
}

fn main() {
    let mut ref_input = String::new();
    let mut hyp_input = String::new();
    
    print!("Enter the reference sentence: ");
    io::stdout().flush().unwrap();
    io::stdin().read_line(&mut ref_input).unwrap();
    let ref_input = ref_input.trim();
    
    print!("Enter the hypothesis sentence: ");
    io::stdout().flush().unwrap();
    io::stdin().read_line(&mut hyp_input).unwrap();
    let hyp_input = hyp_input.trim();
    
    let result = calculate_cer(hyp_input, ref_input);
    
    println!("Total: {}", result.total);
    println!("Match: {}", result.match_count);
    println!("Substitution: {}", result.substitution_count);
    println!("Insertion: {}", result.insertion_count);
    println!("Deletion: {}", result.deletion_count);
    println!("CER: {:.4}", result.cer);
}

"ref"의 경우 예약어로 사용할 수 없어 ref_로 대체를 요청했다.

대충 살펴보니.. 앞 음절부터 순차적으로 탐색하기 때문에, 정확한 편집거리를 계산해 줄 수 없는 상태였다.

당연히 위와 같은 오류를 범하게 된다. 그래서 Levenshtein edit distance의 개념을 사용해 음절을 연산해달라고 요청했다. 이를 위해서는 외부 패키지인 edit_distance하고, 그래서 이를 Catgo.toml 내 dependency에 아래와 같이 추가해준다.

[dependencies]
edit-distance = "2.0"

????

이 문제는 chars() 메서드가 UTF-8 문자로 문자열을 처리하기 때문에 발생할 수 있습니다. chars() 메서드는 각 문자를 UTF-8 코드 포인트로 처리하므로, 한글 문자 하나가 여러 개의 코드 포인트로 인식될 수 있습니다. 이를 해결하기 위해
graphemes 메서드를 사용하여 유니코드 그래프 클러스터를 처리할 수 있습니다.

오.. UTF8에서 한글이 3음절로 다루어지기 때문에 Total이 3배가 돼서 나온 것 같다. 그래서 이를 해결한 최종 코드는

use std::io::{self, Write};
use edit_distance::edit_distance;
use unicode_segmentation::UnicodeSegmentation;

struct CerResult {
    total: usize,
    match_count: usize,
    substitution_count: usize,
    insertion_count: usize,
    deletion_count: usize,
    cer: f64,
}

fn calculate_cer(hyp: &str, ref_: &str) -> CerResult {
    let hyp_chars: Vec<&str> = hyp.graphemes(true).filter(|c| !c.chars().all(char::is_whitespace)).collect();
    let ref_chars: Vec<&str> = ref_.graphemes(true).filter(|c| !c.chars().all(char::is_whitespace)).collect();
    
    let hyp_str: String = hyp_chars.concat();
    let ref_str: String = ref_chars.concat();
    
    let distance = edit_distance(&hyp_str, &ref_str);
    let total_chars = ref_chars.len();
    let cer = distance as f64 / total_chars as f64;
    
    let mut match_count = 0;
    let mut substitution_count = 0;
    let mut insertion_count = 0;
    let mut deletion_count = 0;
    
    let mut i = 0;
    let mut j = 0;
    
    while i < hyp_chars.len() && j < ref_chars.len() {
        if hyp_chars[i] == ref_chars[j] {
            match_count += 1;
            i += 1;
            j += 1;
        } else {
            substitution_count += 1;
            i += 1;
            j += 1;
        }
    }
    
    if i < hyp_chars.len() {
        insertion_count = hyp_chars.len() - i;
    }
    
    if j < ref_chars.len() {
        deletion_count = ref_chars.len() - j;
    }
    
    CerResult {
        total: total_chars,
        match_count,
        substitution_count,
        insertion_count,
        deletion_count,
        cer,
    }
}

fn main() {
    let mut ref_input = String::new();
    let mut hyp_input = String::new();
    
    print!("Enter the reference sentence: ");
    io::stdout().flush().unwrap();
    io::stdin().read_line(&mut ref_input).unwrap();
    let ref_input = ref_input.trim();
    
    print!("Enter the hypothesis sentence: ");
    io::stdout().flush().unwrap();
    io::stdin().read_line(&mut hyp_input).unwrap();
    let hyp_input = hyp_input.trim();
    
    let result = calculate_cer(hyp_input, ref_input);
    
    println!("Total: {}", result.total);
    println!("Match: {}", result.match_count);
    println!("Substitution: {}", result.substitution_count);
    println!("Insertion: {}", result.insertion_count);
    println!("Deletion: {}", result.deletion_count);
    println!("Total Errors: {}", result.substitution_count + result.insertion_count + result.deletion_count);
    println!("CER: {:.4}", result.cer);
}

하지만 자세히 보니.. 다시 앞에서부터 순차 계산을 하는 코드를 뱉어내며 레퍼런스를 던져주고 뭔 짓을 해봐도 같은 코드를 뱉어내기 시작했다. 그래서 클로드를 써보기로..

일단 첫 구현체부터 훨씬 나은 모습을 보여줬다. 직접 Levenshtein edit distance 계산을 구현하고, 그 결과를 출력하고자 했다. 하지만 유사하게 encoding 관련 오차가 있었고, 이를 지적해도 제대로 해결되지 않았다. 그레서 아래의 파이썬 레퍼런스를 던져주고, 이걸 참고해서 수정해보라고 했다.

def word_error_rate_detail(
    hypotheses: List[str], references: List[str], use_cer=False
) -> Tuple[float, int, float, float, float]:
    """
    Computes Average Word Error Rate with details (insertion rate, deletion rate, substitution rate)
    between two texts represented as corresponding lists of string.

    Hypotheses and references must have same length.

    Args:
        hypotheses (list): list of hypotheses
        references(list) : list of references
        use_cer (bool): set True to enable cer

    Returns:
        wer (float): average word error rate
        words (int):  Total number of words/charactors of given reference texts
        ins_rate (float): average insertion error rate
        del_rate (float): average deletion error rate
        sub_rate (float): average substitution error rate
    """
    scores = 0
    words = 0
    ops_count = {'substitutions': 0, 'insertions': 0, 'deletions': 0}

    if len(hypotheses) != len(references):
        raise ValueError(
            "In word error rate calculation, hypotheses and reference"
            " lists must have the same number of elements. But I got:"
            "{0} and {1} correspondingly".format(len(hypotheses), len(references))
        )

    for h, r in zip(hypotheses, references):
        if use_cer:
            h_list = list(h)
            r_list = list(r)
        else:
            h_list = h.split()
            r_list = r.split()

        # To get rid of the issue that jiwer does not allow empty string
        if len(r_list) == 0:
            if len(h_list) != 0:
                errors = len(h_list)
                ops_count['insertions'] += errors
            else:
                errors = 0
        else:
            if use_cer:
                measures = jiwer.cer(r, h, return_dict=True)
            else:
                measures = jiwer.compute_measures(r, h)

            errors = measures['insertions'] + measures['deletions'] + measures['substitutions']
            ops_count['insertions'] += measures['insertions']
            ops_count['deletions'] += measures['deletions']
            ops_count['substitutions'] += measures['substitutions']

        scores += errors
        words += len(r_list)

    if words != 0:
        wer = 1.0 * scores / words
        ins_rate = 1.0 * ops_count['insertions'] / words
        del_rate = 1.0 * ops_count['deletions'] / words
        sub_rate = 1.0 * ops_count['substitutions'] / words
    else:
        wer, ins_rate, del_rate, sub_rate = float('inf'), float('inf'), float('inf'), float('inf')

    return wer, words, ins_rate, del_rate, sub_rate

그랬더니, 마지막 출력부 정도만 원하는 대로 조금 손보면 되는 코드를 잘 던져주었다.

use std::io;
use unicode_segmentation::UnicodeSegmentation;

fn compute_error_rate(hyp: &str, ref_str: &str, use_cer: bool) -> (usize, usize, usize, usize) {
    let (hyp_list, ref_list) = if use_cer {
        (
            hyp.graphemes(true).collect::<Vec<&str>>(),
            ref_str.graphemes(true).collect::<Vec<&str>>()
        )
    } else {
        (
            hyp.split_whitespace().collect::<Vec<&str>>(),
            ref_str.split_whitespace().collect::<Vec<&str>>()
        )
    };

    if ref_list.is_empty() {
        return if hyp_list.is_empty() {
            (0, 0, 0, 0)  // No errors
        } else {
            (hyp_list.len(), hyp_list.len(), 0, 0)  // All insertions
        };
    }

    let m = hyp_list.len();
    let n = ref_list.len();
    
    // 레벤슈타인 거리 행렬
    let mut dp = vec![vec![0; n + 1]; m + 1];
    for i in 0..=m { dp[i][0] = i; }
    for j in 0..=n { dp[0][j] = j; }

    // 작업 추적 행렬
    let mut ops = vec![vec![0; n + 1]; m + 1];

    for i in 1..=m {
        for j in 1..=n {
            if hyp_list[i-1] == ref_list[j-1] {
                dp[i][j] = dp[i-1][j-1];
                ops[i][j] = 0;  // 매치
            } else {
                let sub = dp[i-1][j-1] + 1;
                let del = dp[i-1][j] + 1;
                let ins = dp[i][j-1] + 1;

                dp[i][j] = sub.min(del).min(ins);
                ops[i][j] = if dp[i][j] == sub { 1 }  // 대체
                else if dp[i][j] == del { 2 }  // 삭제
                else { 3 };  // 삽입
            }
        }
    }

    // 오류 계산
    let mut substitutions = 0;
    let mut deletions = 0;
    let mut insertions = 0;
    let errors = dp[m][n];

    // 역추적으로 오류 타입 분류
    let mut i = m;
    let mut j = n;
    while i > 0 && j > 0 {
        match ops[i][j] {
            1 => { substitutions += 1; i -= 1; j -= 1; }
            2 => { deletions += 1; i -= 1; }
            3 => { insertions += 1; j -= 1; }
            _ => { i -= 1; j -= 1; }
        }
    }

    // 남은 삽입/삭제 처리
    insertions += j;
    deletions += i;

    (errors, insertions, deletions, substitutions)
}

fn calculate_error_rate(hypotheses: &[String], references: &[String], use_cer: bool) -> (f64, usize, usize, usize, usize) {
    let mut total_errors = 0;
    let mut total_words = 0;
    let mut total_insertions = 0;
    let mut total_deletions = 0;
    let mut total_substitutions = 0;

    for (h, r) in hypotheses.iter().zip(references.iter()) {
        let (errors, insertions, deletions, substitutions) = compute_error_rate(h, r, use_cer);
        
        total_errors += errors;
        total_words += if use_cer { 
            r.graphemes(true).count() 
        } else { 
            r.split_whitespace().count() 
        };
        total_insertions += insertions;
        total_deletions += deletions;
        total_substitutions += substitutions;
    }

    let error_rate = if total_words > 0 {
        total_errors as f64 / total_words as f64
    } else {
        f64::INFINITY
    };

    (error_rate, total_words, total_insertions, total_deletions, total_substitutions)
}

fn main() {
    println!("Enter the hypothesis sentence:");
    let mut hyp = String::new();
    io::stdin().read_line(&mut hyp).expect("Failed to read line");
    let hyp = hyp.trim().to_string();
    
    println!("Enter the reference sentence:");
    let mut ref_str = String::new();
    io::stdin().read_line(&mut ref_str).expect("Failed to read line");
    let ref_str = ref_str.trim().to_string();
    
    let (error_rate, total_words, total_insertions, total_deletions, total_substitutions) = 
        calculate_error_rate(&[hyp], &[ref_str], true);
    
    println!("\nCER Calculation Results:");
    println!("CER: {:.2}%", error_rate * 100.0);
    println!("Total Chars: {}", total_words);
    println!("Total Ins: {}", total_insertions);
    println!("Total Del: {}", total_deletions);
    println!("Total Sub: {}", total_substitutions);
}

놀라운 것은 " jiwer 라이브러리의 기능을 직접 구현해야 할 것 같네요. " 라고 말한 뒤 세부 error 계산을 위한 로직을 알아서 구현했다는 점.. 하지만 그럼에도 정확한 구현은 아니었다.

결국 세부 연산까지 포함한 레퍼런스까지 던져준 후에야 정확한 코드를 받을 수 있었다.

use std::collections::HashMap;
use unicode_segmentation::UnicodeSegmentation;
use std::io::{self};

#[derive(Debug)]
struct EditResult {
    distance: Vec<Vec<usize>>,
    steps: Vec<char>,
}

fn edit_distance(reference: &[&str], hypothesis: &[&str]) -> EditResult {
    let m = reference.len();
    let n = hypothesis.len();
    let mut d = vec![vec![0; n + 1]; m + 1];

    // Initialize first row and column
    for i in 0..=m {
        d[i][0] = i;
    }
    for j in 0..=n {
        d[0][j] = j;
    }

    // Compute edit distance matrix
    for i in 1..=m {
        for j in 1..=n {
            if reference[i - 1] == hypothesis[j - 1] {
                d[i][j] = d[i - 1][j - 1];
            } else {
                let substitute = d[i - 1][j - 1] + 1;
                let insert = d[i][j - 1] + 1;
                let delete = d[i - 1][j] + 1;
                d[i][j] = substitute.min(insert).min(delete);
            }
        }
    }

    // Backtrack to get steps
    let mut steps = Vec::new();
    let mut x = m;
    let mut y = n;
    while x > 0 || y > 0 {
        if x > 0 && y > 0 && reference[x - 1] == hypothesis[y - 1] {
            steps.push('e');
            x -= 1;
            y -= 1;
        } else if y > 0 && d[x][y] == d[x][y - 1] + 1 {
            steps.push('i');
            y -= 1;
        } else if x > 0 && y > 0 && d[x][y] == d[x - 1][y - 1] + 1 {
            steps.push('s');
            x -= 1;
            y -= 1;
        } else if x > 0 {
            steps.push('d');
            x -= 1;
        }
    }
    steps.reverse();

    EditResult {
        distance: d,
        steps,
    }
}

fn calculate_cer(reference: &str, hypothesis: &str) -> HashMap<String, f64> {
    let ref_chars: Vec<&str> = reference.graphemes(true).collect();
    let hyp_chars: Vec<&str> = hypothesis.graphemes(true).collect();

    let result = edit_distance(&ref_chars, &hyp_chars);
    let steps = result.steps;
    let distance = result.distance[ref_chars.len()][hyp_chars.len()];

    let total = ref_chars.len();
    let counter: HashMap<char, usize> = steps.iter()
        .fold(HashMap::new(), |mut acc, &step| {
            *acc.entry(step).or_insert(0) += 1;
            acc
        });

    let error_rate = if total > 0 {
        (distance as f64 / total as f64) * 100.0
    } else {
        0.0
    };

    HashMap::from([
        ("cer".to_string(), error_rate),
        ("tot".to_string(), total as f64),
        ("mat".to_string(), *counter.get(&'e').unwrap_or(&0) as f64),
        ("sub".to_string(), *counter.get(&'s').unwrap_or(&0) as f64),
        ("del".to_string(), *counter.get(&'d').unwrap_or(&0) as f64),
        ("ins".to_string(), *counter.get(&'i').unwrap_or(&0) as f64),
    ])
}

fn calculate_wer(reference: &str, hypothesis: &str) -> HashMap<String, f64> {
    let ref_words: Vec<&str> = reference.split_whitespace().collect();
    let hyp_words: Vec<&str> = hypothesis.split_whitespace().collect();

    let result = edit_distance(&ref_words, &hyp_words);
    let steps = result.steps;
    let distance = result.distance[ref_words.len()][hyp_words.len()];

    let total = ref_words.len();
    let counter: HashMap<char, usize> = steps.iter()
        .fold(HashMap::new(), |mut acc, &step| {
            *acc.entry(step).or_insert(0) += 1;
            acc
        });

    let error_rate = if total > 0 {
        (distance as f64 / total as f64) * 100.0
    } else {
        0.0
    };

    HashMap::from([
        ("wer".to_string(), error_rate),
        ("tot".to_string(), total as f64),
        ("mat".to_string(), *counter.get(&'e').unwrap_or(&0) as f64),
        ("sub".to_string(), *counter.get(&'s').unwrap_or(&0) as f64),
        ("del".to_string(), *counter.get(&'d').unwrap_or(&0) as f64),
        ("ins".to_string(), *counter.get(&'i').unwrap_or(&0) as f64),
    ])
}

fn main() {
    println!("Enter the hypothesis sentence:");
    let mut hyp = String::new();
    io::stdin().read_line(&mut hyp).expect("Failed to read line");
    let hyp = hyp.trim();
    
    println!("Enter the reference sentence:");
    let mut ref_str = String::new();
    io::stdin().read_line(&mut ref_str).expect("Failed to read line");
    let ref_str = ref_str.trim();

    let cer_result = calculate_cer(ref_str, hyp);
    let wer_result = calculate_wer(ref_str, hyp);

    println!("CER Results: {:?}", cer_result);
    println!("WER Results: {:?}", wer_result);
}

드디어 정확한 결과가 나왔다ㅠㅠ

일단 오늘 해보면서 느낀점은

Copilot 보단 클로드가 코딩을 훨씬 잘한다. 그래도 결국 자꾸 틀린 부분을 찾아내고, 보완해주어야 하는 점을 구체적으로 지적하고 레퍼런스를 제공해야만 원하는 지점에 도달할 수 있다.
생각했던 것보다 Rust 구현체가 간결하고 직관적인게 python과 겹쳐보이는 구석이 있다.

오늘은 생각보다 너무 길어져서.. 다음에는 이 완성된 코드를 뜯어보며 변수의 형 정의나 특정 메서드들에 대해 공부해봐야겠다.

[Rust] 조건문과 반복문 - let if, loop, match

mingchin — Tue, 19 Nov 2024 21:45:06 +0900

Rust의 기본적인 조건문과 반복문은 C 계열 언어와 거의 동일하다. 일부 C와 python이 조합된 것 같은.. Rust 만의 특성을 가지는 몇 가지를 살펴본다.

let if

변수를 지정하는 let과 조건 분기를 조합해서 아래와 같이 사용할 수 있다.

use std::io;

fn main() {
    println!("Please enter the temperature:");

    let mut input = String::new();
    io::stdin().read_line(&mut input)
        .expect("Failed to read line");

    let temperature: i32 = input.trim().parse()
        .expect("Please type a number!");

    let weather = if temperature > 25 {
        "hot"
    } else if temperature > 15 {
        "warm"
    } else {
        "cold"
    };

    println!("The weather is: {}", weather);
}

위와 같이 작성하고 실행해보면, 동적으로 입력된 stdin에 따라 "weather" 변수가 셋 중 하나로 할당된다.

loop

Rust는 while문이 존재함에도, 무한 루프를 정의하기 위한 "loop"가 따로 있다.

fn main() {
    let mut count = 0;

    let result = loop {
        count += 1;

        if count == 10 {
            break count * 2; // 루프를 종료하면서 값을 반환합니다.
        }
    };

    println!("The result is: {}", result);
}

특이한 점은 while/loop문 역시 동적 변수 할당이 가능하다는 점이다. loop를 돌다가 break하는 시점에 "result" 변수를 할당해 줄 수 있다. 리턴하고 싶은 값은 break 바로 뒤어 적어주면 된다.

match

C의 switch/case와 유사한 문법이 Rust에도 있다.

use std::io;

fn main() {
    loop {
        println!("Guess my favorite natural number:");
        let mut input = String::new();
        io::stdin().read_line(&mut input)
            .expect("Failed to read line");
        let number: i32 = match input.trim().parse() {
            // 예외 처리부
            Ok(num) => num,
            Err(_) => {
                println!("Please type a valid number!");
                continue;
            }
        };

        match number {
            1 => println!("It's my second favorite!"),
            2 | 3 | 5 | 7 | 11 => println!("This is a prime number, I love prime numbers"),
            13 => {
                println!("This is my favorite number!");
                break;
            },
            _ => println!("This is just a number."),
        }
    }
}

위와 같이 작성하면, 13을 맞힐 때까지 반복해서 숫자를 입력해야하는 무한 루프를 실행할 수 있다.

use std::io;

fn main() {
    println!("How old are you?:");
        let mut input = String::new();
        io::stdin().read_line(&mut input)
            .expect("Failed to read line");
        let age: i32 = match input.trim().parse() {
            // 예외 처리부
            Ok(num) => num,
            Err(_) => {
                println!("Please type a valid age!");
                return;
            }
        };

    let group = match age {
        0..=10 => "child",
        11..=20 => "teenager",
        21..=64 => "adult",
        _ => "senior",
    };

    println!("You are in the {} group.", group);
}

위와 같이 구성하면, "age"가 어떤 구간에 속하냐에 따라 조건 분기가 가능하다.

처음이라 좀 난해한 구석이 있지만.. 적응하고 나면 정말 가독성이 좋은 언어일 것 같다.

[Git/Gitea] Gitea Actions를 활용한 테스트 코드 실행 자동화 (2)

mingchin — Tue, 19 Nov 2024 17:19:32 +0900

지난 글에 이어서.. 시행착오를 정리한다.

Docker Compose를 기반 act_runner 활성화

지난 글에서는 act_runner binary를 다운 받고, 이를 직접 실행해 daemon을 활성화 하는 방식으로 Gitea와 연결해 테스트 코드를 실행했다. 하지만 이렇게 하면 매우 기본적인 실행들 외에는 많은 제약이 발생하고, 커스터마이징 하기가 쉽지 않다. (하나만 띄울 수 있고, 직접 daemon을 매번 재실행해야 하며, 관련 로그도 보기 어렵다 등등) 따라서 Docker compose를 활용해 act_runner를 컨테이너로 실행하는 것이 좋다.

Act_runner 설정 config.yaml 준비

act_runner generate-config > config.yaml

을 실행하여, confing.yaml을 생성하면 정말 많은 옵션들을 볼 수 있다.

대부분은 수정하지 않고 그냥 사용해도 무방하지만, 몇 가지 살펴볼 것들이 있다.

runner - labels

runner:
  labels: "label_name"

이 부분이 많이 헷갈렸는데, 그냥 내가 띄우고자 하는 act_runner의 별명을 지어준다고 생각하면 된다. 레이블을 활용해 특정 동작을 선택적으로 연결하고 실행할 수 있다. 여기 지정하는 값은, 실제 workflow 관련 yml 파일이나 이어 작성할 docker-compose.yml 내에도 연결하기 위해 동일하게 세팅해줘야 하는 값이므로 기억해두자.

1. Runner 분류: 여러 Runner를 운영할 때, 특정 Runner에만 워크플로를 실행시키고 싶을 때 사용합니다. 예를 들어, 테스트 환경용 Runner와 프로덕션 환경용 Runner를 분리하여 사용할 수 있습니다.
2. 작업 필터링: label은 runs-on 필드와 매칭되어 특정 Runner에서만 작업이 실행되도록 합니다.

runner - envs - DOCKER_REGISTRY_AUTH

runner:
  DOCKER_REGISTRY_AUTH: "~/.docker/config.json"

온프로미스 레지스트리 내 이미지를 활용해 Gitea Actions를 수행하고 싶은 경우 셋팅해줘야 한다. 이미 구축한 온프로미스 레지스트리에 로그인을 수행하게 되면 해당 경로에 자동으로 파일이 생성되며, 그 안에는 아래와 같은 형식의 텍스트가 저장돼 있다.

{
        "auths": {
                "my_ip:my_port": {
                        "auth": "MyAuThCodE="
                }
        }

Action을 수행하는 순간 도커 이미지를 pull하고 환경을 구축하도록 할 예정이기 때문에 필요한 부분!

container- valid_volumes

container:
  # If you want to allow any volume, please use the following configuration:
  valid_volumes:
    - '**'
  # valid_volumes: []

Actions를 수행할 컨테이너가 특정 경로를 볼륨으로 잡고 싶은 경우 설정한다. 주석에서 알 수 있듯 어떤 볼륨이든 따로 인자를 주어 잡을 수 있게 하려면 위의 옵션을, 그렇지 않으면 리스트에 직접 볼륨 잡을 목록들을 넣으면 된다.

container- valid_volumes

container:
  # If it's empty, /workspace will be used.
  workdir_parent:

Actions를 수행할 컨테이너의 진입 working directory를 지정할 수 있다. 어차피 특정 레포지토리를 clone해서 사용할 것이라 나의 경우는 사용할 필요가 없었다.

docker-compose.yml 준비

version: '3'

services:
  act_runner:
    image: gitea/act_runner:latest
    container_name: gitea_act_runner
    privileged: true
    environment:
      CONFIG_FILE: /config.yaml
      GITEA_INSTANCE_URL: my_url # Gitea 서버 URL로 수정
      GITEA_RUNNER_REGISTRATION_TOKEN: MY_TOKEN_HASH # Gitea에서 생성된 액트 러너 토큰으로 수정
      GITEA_RUNNER_LABELS: label_name # 러너에 적용할 레이블 설정
      GITEA_RUNNER_NAME: runner_name # 러너 이름 설정
      GITEA_RUNNER_CAPACITY: 1 # 동시에 처리할 작업 수 (1은 기본값)
    restart: always
    volumes:
      # .runner file을 직접 보고 싶은 경우에만 활성화
      # - ./act_runner/data:/data
      - ./config.yaml:/config.yaml
      # 컨테이너 내에서 로컬 docker.sock을 사용하고 싶은 경우
      - /var/run/docker.sock:/var/run/docker.sock

기본 셋팅은 위와 같다. GITEA_RUNNER_REGISTRATION_TOKEN의 경우 지난 글과 동일한 방식으로 받아 오면 되고, GITEA_RUNNER_LABELS는 위의 runners - label 에서 지정한 "레이블 명"과 동일한 값을 사용해야 연결된다. volumes에 위에서 작성한 config.yaml을 act_runner 컨테이너가 바라볼 수 있도록 해준다. (아래와 같이 같은 depth에 존재할 때 기준이며, 다른 위치라면 경로에 맞게 수정)

# act_runner 실행
docker compose up -d

# 컨테이너 로그 확인
docker logs -f gitea_act_runner

# act_runner 내리기
docker compose down

관련해 문제가 발생하면 logs를 통해 확인할 수 있다. Gitea GUI의 Settings - Actions - Runners 에서 "idle"로 활성화 된 runner가 있어야 한다.

Workflow 실행을 위한 준비

Gitea는 기본적으로 ubuntu:latest 이미지를 활용해 테스트를 수행하지만, 나는 온프로미스에 따로 구축해둔 "my_image"를 활용해 테스트를 수행해야 하는 상황이었다.

name: Test Workflow

on:
  push:
    branches:
      - feat/gitea-actions

jobs:
  test:
    runs-on: label_name
    container:
      image: my_image:latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v2  # 레포지토리의 변경 사항을 가져옴
        token: ${{ secrets.PAT }}
      - name: AdaptModel
        run: python builder.py

위의 샘플 코드를 실행하기 위해 필요한 단계는 아래와 같다.

1) 테스트 용 이미지 내 필수 패키지 설치(Node.js, git)

이미지를 구성하다보면 layer를 최소화 하다보니 일반적으로 있을만한 패키지들이 자주 누락된다. 위의 steps 중 "Checkout code"에 해당하는 부분은, git으로 Gitea 레포지토리에 접근하여 현 브랜치(feat/gitea-actions)의 변경 사항을 clone 해오는 역할을 한다. 이는 Github Actions의 호환 런타임인데, Node.js를 필요로 한다. 따라서 두 패키지를 이미지 내에서 활용 가능하도록 설치해주어야 한다.

# Install Node.js & git (minimal stage)
RUN curl -fsSL https://rpm.nodesource.com/setup_16.x | bash - && \
    dnf install -y nodejs git  && \
    dnf clean all

2) git clone을 위한 토큰 설정

위 clone 과정을 위해, Gitea에 로그인하는 과정이 필요할 수 있다. ID/Passwd로 레포지토리에 대한 접근을 허용하는 경우, Settings - Actions - Secrets에 이를 사전 지정하여 코드에 ID/Passwd를 노출하지 않고 안전하게 접근할 수 있다.

"username:password" 형식으로 입력해두고, token: ${{ secrets.PAT }} 를 추가하면 된다.

3) 실행 코드 넣기

여기까지 진행하면, 작업 브랜치(feat/gitea-actions)에 push를 하는 순간 "my_image:latest"를 이용해 컨테이너를 띄우고, gitea 레포지토리에 사전 정의된 ID/Passwd로 로그인 후 clone을 수행해 작업 브랜치와 동일한 소스코드를 가진다. 따라서 해당 소스코드에 대해 테스트 하고 싶은 내용들을 순차적으로 "name/run"의 쌍으로 넣어주면 된다.

이때 컨테이너 내에서 컨테이너를 띄우는 것이 물리적으로 가능은 하지만.. 기본적으로 각 "name/run" 쌍의 프로세스가 정상 종료되었는지 여부로 Actions 탭에서 성공 실패를 띄워주기 때문에, 이 부분을 유의해서 각 단계를 설정해야한다.

몇 번의 시행착오 끝에..! 이제 정말 유효한 테스트 코드들을 구성하고, 작업마다 정상 동작하는지 여부를 체크하도록 하는 일만 남았다.

[Rust] 소유권과 라이프타임을 통한 메모리 관리

mingchin — Sun, 17 Nov 2024 17:18:16 +0900

Rust가 가지는 특별한 개념인 소유권에 대해 Copilot에게 물었을 때 아래의 답을 얻을 수 있었다.

소유권

Rust의 소유권 시스템은 메모리 안전성을 보장하기 위해 설계되었습니다. 주요 개념은 다음과 같습니다:

소유권(Ownership): 각 값은 특정 변수에 소유권이 있습니다. 한 번에 하나의 변수만 값을 소유할 수 있습니다.
이동(Move): 소유권이 다른 변수로 이동할 수 있습니다. 이동 후 원래 변수는 더 이상 값을 사용할 수 없습니다.
빌림(Borrowing): 소유권을 이동하지 않고 값을 참조할 수 있습니다. 빌림에는 불변 참조와 가변 참조가 있습니다.
- 불변 참조(&): 값을 읽기만 할 수 있습니다.
- 가변 참조(&mut): 값을 변경할 수 있습니다.
라이프타임(Lifetime): 참조가 유효한 범위를 나타냅니다. Rust는 라이프타임을 추적하여 유효하지 않은 참조를 방지합니다.

그러면 이러한 소유권은, C 계열 언어의 어떤 문제를 극복하고자 설계된 개념일까?

1. 메모리 누수

C와 C++에서는 프로그래머가 직접 메모리를 할당하고 해제해야 합니다. 이 과정에서 메모리를 제대로 해제하지 않으면 메모리 누수가 발생할 수 있습니다. Rust는 소유권 시스템을 통해 메모리를 자동으로 관리하여 이러한 문제를 방지합니다.

2. 잘못된 메모리 접근

C 계열 언어에서는 포인터를 통해 메모리 주소를 직접 조작할 수 있습니다. 이로 인해 잘못된 메모리 접근(예: 해제된 메모리 접근, 경계 밖 메모리 접근 등)이 발생할 수 있습니다. Rust는 소유권과 빌림 규칙을 통해 이러한 잘못된 접근을 컴파일 타임에 방지합니다.

3. 데이터 경합

멀티스레드 환경에서 여러 스레드가 동시에 동일한 메모리에 접근할 때 데이터 경합이 발생할 수 있습니다. C와 C++에서는 이러한 문제를 해결하기 위해 복잡한 동기화 메커니즘을 사용해야 합니다. Rust는 소유권과 빌림을 통해 데이터 경합을 방지하고, 안전한 동시성을 보장합니다.

4. 안전하지 않은 코드

C와 C++에서는 메모리 안전성을 보장하지 않는 코드가 쉽게 작성될 수 있습니다. Rust는 소유권 시스템을 통해 메모리 안전성을 보장하며, 안전하지 않은 코드를 작성할 때는 명시적으로 unsafe 블록을 사용하도록 요구합니다. 이를 통해 안전하지 않은 코드의 사용을 최소화하고, 코드의 안전성을 높입니다.

요약하자면, 직접 메모리를 할당하고 해제하거나 메모리 주소를 조작하는 등 개발자에게 많은 권한이 주어지기 때문에 반대로 개발자의 실수나 부주의로 인한 문제가 발생할 위험이 커진다. 따라서 Rust는 소유권 등의 개념에 기반하여 이를 원천적으로 제한하여 위험을 감소시키고자 한다. 생성형 AI 기반의 코드 작성이 피할 수 없는 흐름인 시대가 오는 만큼 더더욱 이런 언어 차원에서의 안정성 확보가 좋은 안전장치가 되어줄 것이라고 생각하고, 그래서 Rust가 매력적이다.

// C 코드에서 발생할 수 있는 문제 - 해제된 메모리에 대한 접근
#include <stdio.h>
#include <stdlib.h>

void use_after_free() {
    int *ptr = (int *)malloc(sizeof(int));
    *ptr = 42;
    free(ptr);
    printf("%d\n", *ptr); // 해제된 메모리에 접근 -> 정의되지 않은 동작이며 Rust에서는 이와 같은 접근이 불가
}

int main() {
    use_after_free();
    return 0;
}

// Rust에서의 안정성
fn use_after_free() {
    let ptr = Box::new(42); // Box는 힙에 메모리를 할당하고 소유권을 가집니다.
    // 메모리는 ptr이 범위를 벗어날 때 자동으로 해제됩니다.
    println!("{}", *ptr); // 안전하게 접근
}

fn main() {
    use_after_free();
}

예시 코드로 소유권 이해하기

새롭게 "onwership"이라는 프로젝트를 생성하고, main.rs에 아래와 같이 작성해 실행해보았다.

cargo new onwership

fn main() {
    let s1 = String::from("Hello"); // s1이 문자열 "Hello"의 소유자입니다.
    let s2 = s1; // 소유권이 s1에서 s2로 이동합니다. 이제 s1은 더 이상 사용할 수 없습니다.

    // println!("{}", s1); // 이 줄은 컴파일되지 않습니다. s1은 더 이상 유효하지 않습니다.
    println!("{}", s2); // s2는 "Hello"를 출력합니다.

    let s3 = String::from("World");
    let s4 = &s3; // s3의 불변 참조를 s4에 빌려줍니다.
    println!("{}", s3); // s3는 여전히 유효합니다.
    println!("{}", s4); // s4는 "World"를 출력합니다.

    let mut s5 = String::from("Rust");
    let s6 = &mut s5; // s5의 가변 참조를 s6에 빌려줍니다.
    s6.push_str(" Programming"); // s6를 통해 s5를 변경할 수 있습니다.
    println!("{}", s5); // s5는 "Rust Programming"을 출력합니다.
}

s1을 정의하는 순간 생긴 소유권이, s2를 정의하는 순간 s1으로부터 s2로 옮겨갔다(소유권 이동). 따라서 println!("{}", s1); 과 같은 코드는 동작할 수 없다. 실제 해당 주석을 해제하고 컴파일을 시도해보면,

이렇게 친절하게 에러를 뱉어준다. (물론 이미 extension이 설치된 VSCode가 알려준다.)

소유권을 이전 받지 않고 값을 참조하는 방법에는 불변 참조(&)와 가변 참조(&mut)가 있으며 가변 참조로 받아왔을 때만 s6처럼 본인이 소유권을 가지지 않았음에도 s5를 변경할 수 있다. (여전히 소유권 자체는 s5에 있음)

아래의 예시로는 라이프타임의 개념을 이해할 수 있다.

fn main() {
    let string1 = String::from("Hello, world!");
    let result;
    {
        let string2 = String::from("Rust");
        result = longest(&string1, &string2);
        // string2는 이 블록을 벗어나면 소멸됩니다.
        println!("A: The longest string is {}", result); // 이 줄은 컴파일되지 않습니다.
    }
    // println!("B: The longest string is {}", result); // 이 줄은 컴파일되지 않습니다.
}

// 두 문자열 참조를 받아서 더 긴 문자열 참조를 반환하는 함수
fn longest<'a>(x: &'a str, y: &'a str) -> &'a str {
    if x.len() > y.len() {
        x
    } else {
        y
    }
}

해당 코드를 실행하면 아래와 같이 출력된다.

그러나 A: 로 시작하는 출력문 주석하고 B: 로 시작하는 출력문을 주석 해제하여 컴파일을 시도하면,

이렇게 에러를 만날 수 있다. 불변 참조(&)로 빌려온 값의 라이프타임이 해당 참조가 이루어진 블록 밖에서는 소멸되어, 출력할 수 없는 것이다. 하나의 함수 내에서도 블록 단위로 수명을 제한할 수 있다는 것이 놀랍다.

Rust 컴파일러는 라이프타임을 프로그래머가 명시적으로 지정할 수 있으며, longest 함수 내 'a 관련 표현이 "lifetime specifier"에 해당한다. a일 필요는 없으며, 원하는 이름을 자유롭게 쓸 수 있다고 한다. ('abc 와 같이 사용 가능)

또한 라이프타임 명시는 아래의 경우에는 생략될 수 있다고 하는데, "규칙에 맞게 작성하면 생략할 수 있다" 정도만 기억하고 보다 상세한 이해는 차차 해나가도록 하자.

입력 참조가 하나인 경우: 입력 참조의 라이프타임이 반환 참조의 라이프타임과 동일합니다.
여러 입력 참조가 있는 경우: 반환 참조의 라이프타임은 첫 번째 입력 참조의 라이프타임과 동일합니다.
메서드의 경우: self의 라이프타임이 반환 참조의 라이프타임과 동일합니다.

아래 코드는 1에 해당하는 입력 참조와 반환 참조의 라이프타임이 동일하다는 것을 컴파일러가 추론할 수 있는 예시이다.

fn first_word(s: &str) -> &str {
    let bytes = s.as_bytes();
    for (i, &item) in bytes.iter().enumerate() {
        if item == b' ' {
            return &s[0..i];
        }
    }
    &s[..]
}

[Rust] cargo 프로젝트 내 Cargo.toml과 Cargo.lock 그리고 incremental compilation

mingchin — Thu, 14 Nov 2024 23:21:05 +0900

오늘은 첫 글에서 hello Rust 프로젝트를 생성하고, 이를 컴파일 및 실행하면서 자동으로 생긴 리소스들 중 관심이 가는 것들을 살펴본다.

Cargo.toml

Copilot에게 Cargo.toml에 대해 물으니 아래와 같은 답변을 받을 수 있었다.

Cargo.toml 파일은 Rust 프로젝트의 설정 파일로, 프로젝트의 메타데이터와 의존성을 관리하는 중요한 역할을 합니다. 이 파일은 TOML (Tom’s Obvious, Minimal Language) 형식으로 작성되며, 다음과 같은 주요 섹션으로 구성됩니다

[package]
name = "my_project"
version = "0.1.0"
authors = ["Your Name <your.email@example.com>"]
edition = "2021"

[dependencies]
my_other_project = "0.2.0"
serde = "1.0"

[dev-dependencies]
anyhow = "1.0"  # 에러 핸들링을 위한 라이브러리
serde_json = "1.0"  # JSON 파싱을 위한 라이브러리

그러니까.. Rust는 cargo라는 패키지 매니저이자 빌드 시스템을 활용해 "cargo build", "cargo publish" 등 빌드와 배포를 진행할 수 있다. 이때 Cargo.toml 파일은 해당 프로젝트의 버전, 타 프로젝트와의 의존성, 개발 중에만 필요한 라이브러리의 의존성을 명시할 수 있다. [dev-dependencies] 섹션에 명시된 라이브러리들은, 개발 중에만 사용되고 배포 빌드에는 포함되지 않는다고 한다. 또한 명시된 프로젝트 버전 정보가 빌드된 파일의 메타데이터에 포함돼, 디버깅이나 배포에 편리하다. 버전 및 의존성 관리를 강제하는..

Cargo.lock

Cargo.lock 파일은 프로젝트의 의존성 트리를 고정(freeze)하는 역할을 한다. Cargo.toml 파일에 명시된 의존성뿐만 아니라, 그 의존성들이 의존하는 모든 하위 의존성들의 정확한 버전을 기록하여, 동일한 빌드가 재현 가능하도록 한다.
아니 근데 Cargo.toml에서 이미 고정했는데...? 라고 생각했으나.. 두 파일의 역할은 조금 다르고, 상호 보완적이다.

Cargo.toml의 역할

의존성 선언: 프로젝트에서 필요한 라이브러리와 그 버전 범위를 선언합니다.
사양: 어떤 라이브러리가 필요한지, 그리고 그 라이브러리의 최소 버전 요구 사항을 명시합니다.

Cargo.lock의 역할

의존성 고정: 실제로 사용된 라이브러리의 정확한 버전을 기록합니다.
재현 가능성: 동일한 프로젝트를 다른 환경에서 빌드할 때, 동일한 의존성 버전을 사용하도록 보장합니다.

즉, Cargo.toml에는 필수 및 최소 의존성을 표기한다면, Cargo.lock은 언제든 특정 빌드를 재현할 수 있는 안전장치다. 실제 여러 명의 개발자가 협업하는 상황에서는 환경이 꼬이는 일이 허다하기 때문에..
예를 들어 위 Cargo.toml 파일 예시의 serde = "1.0"를 보면, 개발자는 1.0.x 버전 중 어떤 것이든 사용할 수 있다. 다만 특정 시점에 빌드를 하고 배포할 때 1.0.130 버전이 사용됐다면, 이는 Cargo.lock에 기록하여 오류 및 버그 가능성을 줄인다.

cargo update

위 명령어를 통해, Cargo.toml 파일에 기록된 의존성의 범위 내에서 가능한 최신 버전으로 Cargo.lock을 업데이트 할 수 있다.

증분 컴파일(Incremental Compilation)

프로젝트 내 target/debug/incremental 디렉토리를 보면, 소스코드 변경 후 빌드를 반복할 때마다 무언가 파일이 쌓인다.

그 안에는 다시 .lock 파일과 bin 파일들이 생성된 것을 확인할 수 있었다.

해당 디렉토리는 증분 컴파일(incremental compilation)과 관련된 데이터를 저장하는 곳이다.

증분 컴파일은 Rust 컴파일러가 이전 빌드의 결과를 재사용하여 컴파일 시간을 단축시키는 기능입니다.
이 디렉토리에는 컴파일러가 중간 결과를 캐시하여, 코드의 일부만 변경되었을 때 전체를 다시 컴파일하지 않고 변경된 부분만 다시 컴파일할 수 있도록 합니다

docker가 이미지를 layer로 관리하며 빌드 과정을 캐싱하고 불필요한 메모리 사용과 빌드 과정을 줄이는 것과 유사한 개념인 것 같다. 의존성 그래프를 활용해 변경되지 않은 부분은 재사용하고, 변경된 부분만 다시 컴파일한다.

내부적으로 알아서 증분 컴파일 캐시를 제거하여 너무 커지지 않도록 관리하며, 소스 코드가 크게 변경되거나 프로젝트 설정이 변경되면, 컴파일러는 캐시를 무효화하고 필요한 부분을 다시 컴파일하여 오래된 데이터가 남아 있지 않도록 한다.

cargo clean

또한 위 명령어로 아티팩트와 증분 컴파일 캐시를 모두 삭제할 수 있다.

다음 글에는 기본 문법과 Rust 만의 특별한 문법이 있다면 공부해보자.

[Git/Gitea] Gitea Actions를 활용한 테스트 코드 실행 자동화 (1)

mingchin — Thu, 14 Nov 2024 10:36:41 +0900

배경

온프로미스 구축이 용이하다는 점 때문에, Gitea를 도커 컨테이너로 띄워놓고 운영 중이다. Github actions과 유사한 기능을 Gitea에서도 사용할 수 있는데, 환경 구축과 테스트 코드 실행 과정을 정리한다.

환경 구축

1) Gitea Actions 활성화

Gitea 서버가 떠있는 공간에서 설정을 바꿔준다. 기본적으로는 actions 탭이 활성화 돼있지 않다.

# custom/conf or config 디렉토리 내 app.ini 에 추가
[actions]
ENABLED = true
DEFAULT_ACTIONS_URL = https://gitea.com/gitea/act_runner

# 설정 추가 후
systemctl restart gitea

# 혹은
docker restart {gitea_container]

이제 Gitea GUI 환경에서 각 repo 마다 settings Actions 탭을 활성화 할 수 있다. (이 부분 역시 모든 레포에 대해 기본적으로 Actions 탭을 활성화 하도록 환경 셋팅을 바꿀 수 있다고 한다.)

2) 워크플로 파일 작성

자동으로 실행하고 싶은 작업을 생성한다. 레포지토리 루트에 ".gitea/workflow" 디렉토리를 생성 후, ".yml" 확장자로 아래와 같이 추가하면 된다.

mkdir -p .gitea/workflows

# .gitea/workflows/test.yml 생성
name: Test Workflow

on:
  push:
    branches:
      - main
    paths:
      - 'builder/**'

jobs:
  test:
    runs-on: self-hosted
    steps:
      - name: Run tests
        run: echo HI

"on"은 트리거를 의미한다. 위 예시는 main branch에 push하는 순간 자동으로 해당 workflow가 실행되도록 설정한 것이며, 외에도 pull_request, schedule(정기 실행), workflow_dispatch(수동 실행), release 등의 옵션이 있다. 또한 paths를 지정한 경우에는, 해당 부분에 변경 사항이 있을 때만 실행되도록 설정한다.

"jobs"는 실제 실행한 동작과 관계된다. "runs-on"의 경우, 해당 동작을 실행할 컨테이너를 띄울 이미지를 설정할 수 있다. 기본값으로는 ubuntu:latest 이미지가 활용되는 것으로 보이며, 커스터마이징도 가능하다. "self-hosted"는 별도 컨테이너를 띄우지 않고 push 등 동작이 발생한 로컬 환경에서 action을 수행하도록 한다. "steps" 하위에 여러 개의 "name"과 "run"을 순차적으로 동작하도록 배치가 가능하다.

3) act_runner 설치 및 설정

Gtiea는 "act_runner"를 통해 사전 정의된 action을 실행하고, 그 결과를 Gitea 서버에 전달해 출력한다. 이 부분은 별도 설치 및 셋팅이 필요하다. 링크에서 OS에 맞는 버전을 선택해 다운로드 받으면 된다.

# 리눅스
wget https://dl.gitea.com/act_runner/0.2.11/act_runner-0.2.11-linux-amd64

# 실행 권한
chmod +x act_runner-0.2.11-linux-amd64

# bin 폴더로 이동
mv act_runner-0.2.11-linux-amd64 /usr/local/bin/act_runner

이렇게 bin 디렉토리로 옮겨 놓으면 편하게 사용이 가능하다. 이제 이 act_runner를 통해 daemon을 직접 실행하거나, 혹은 config를 별도로 작성 후 docker-compose를 통해 act_runner를 실행할 수 있는데, 일단 테스트를 위해 전자로 진행했다.

act_runner register

를 실행하면, interactive하게 기본 설정들을 할 수 있다. (분명 --instance 등의 인자를 줄 수 있게 돼있는데, 줘도 안먹고 다시 입력해야 한다.) gitea 서버 주소, token, tag_name 등을 순차적으로 입력하면 된다. token의 경우 연결하고자 하는 레포지토리의 settings - Actions - runners 탭에서 아래와 같이 찾을 수 있다.

이렇게 하면 등록 절차를 마칠 수 있고, 이제 이 act_runner가 동작할 수 있도록 daemon을 띄워준다.

nohup act_runner daemon &

길뚫을 위해 이렇게 수행하긴 했으나.. 매번 daemon 띄우는 것도 일이고, 이렇게 하면 하나의 서버에서 한 개의 레포지토리에만 act_runner를 연결할 수 있으니, 결국 config 만들고 docker-compose를 실행하는 쪽으로 진행해야 할 것 같다.

act_runner generate-config > config.yaml

이렇게 하면 기본 구조를 갖춘 config.yaml이 생성되고, 여기에 방금 interactive하게 수행한 기본 값들에 대한 셋팅, 그리고 그 외에도 추가적인 기능들과 관련된 셋팅을 수행할 수 있다. 그리고 이 config를 활용해 docker-compose를 수행할 yaml은 아래의 구조로 생성하면 된다.

version: "3"

services:
  act_runner:
    image: gitea/act_runner:0.2.10
    container_name: act_runner
    privileged: true
    environment:
      CONFIG_FILE: /config.yaml
      GITEA_INSTANCE_URL: "https://192.168.56.173:3300" 
      GITEA_RUNNER_REGISTRATION_TOKEN: {token}
      GITEA_RUNNER_NAME: "act_runner"
      GITEA_RUNNER_LABELS: ubuntu-latest:docker
    volumes:
      - ~/act-runner/data:/data
      - ~/act-runner/cache:/root/.cache    
      - ./config.yaml:/config.yaml
      - /var/run/docker.sock:/var/run/docker.sock

이 부분 셋팅하고 실제 실행은 다음 번에 해본다.

아마 이 구조로 셋팅하고 "docker-compose up -d" 를 실행하면 직접 register하고 daemon을 실행한 것과 동일한 결과를 보여줘야 한다.

아무튼 이렇게 직접 daemon을 잘 실행했다면, main branch에 변경 사항을 push 했을 때 아래와 같이 Actions 탭에서의 수행을 볼 수 있다.

길뚫 성공..!

[Rust] 공부를 시작하며

mingchin — Tue, 12 Nov 2024 22:25:34 +0900

목표 설정

블로그에 글을 쓰며 공부한 게 언제인지.. 짬을 내서 퇴근 후에 도커와 쿠버네티스 강의를 들으면서도, 사실 짬을 내 정리하는 게 여간 어려운 일이 아니었다. 뒤쳐지지 않기 위해, 그리고 배우는 재미를 잊지 않기 위해 다시 한 번 시작해야 할 때다. 아래의 목표를 가지고 공부를 해보려 한다.

생성형 AI 활용법 익히기

코드도, 글도, 브레인스토밍도 이제는 생성형 AI 없이 진행하는 것이 바보다 싶을 정도로 훌륭한 초안 짜기 도구가 되었다고 생각한다. 실제 업무에서도 객체 구조를 잡거나 코드 초안의 작성, 규칙이 있는 변경사항에 대한 일괄 적용 등에 자주 활용하고 있다. 글을 쓰는 데에 Copilot을 사용해보며 chatGPT와의 차이도 느껴보고, 그 한계도 더 많이 체험해보고 싶다. 살재로 글의 뼈대나 초안을 Copilot으로 작성해보거나, 공부해야 하는 키워드를 검색해 보는데도 사용할 예정이다.

저수준 언어와 친해지기

나의 주 언어는 Python이다. 주로 모델링을 담당하다 보니 업무는 파이썬과 쉘스크립트만 알아도 충분하지만 C++ 기반인 엔진에 대한 보다 깊은 이해를 필요로 하는 순간이나, 저수준 언어에 대한 기반 지식이 아쉽게 느껴질 때가 있다. C 계열 언어의 한계성을 극복하고자 만들어진 Rust를 공부하면, 나에게 더 효용이 높은 시간이 될 것 같다.

안드로이드 개발을 향해

온디바이스 STT에 대한 수요도 있고.. AI 모델링을 하더라도 서비스를 위해 필요한 백/프론트의 구성이나 흐름을 이해하는 것이 도움이 되듯이, 저수준 언어로 구현될 수밖에 없는 안드로이드 개발 과정을 대략적으로라도 이해해볼 수 있다면 좋겠다.

왜 Rust인가?

모질라 재단에서 2010년 공개한 언어인 Rust는, C/C++와 동등한 수준의 속도를 유지하면서 안전성과 동시성을 향상시키는 것을 목표로 설계되었다고 한다. C/C++은 메모리 등 하드웨어를 자유자재로 제어할 수 있다는 장점이 있지만, 그만큼 해당 제어를 잘못 했을 때의 위험성 또한 높다. (Segmentation fault나 메모리 누수는 내가 C 개발자가 아닌데도 맨날 듣는 재앙의 소리다.) 더 엄격한 문법과 규칙에 기반해, 이러한 잠재적 위험을 사전에 제거한다고 한다. 아마도 이를 가능하게 하는 아래의 키워드들을 차차 앞으로 공부해야 할 것이다.

Keywords: 소유권, 빌림(Borrowing), 수명(Lifetimes), 트레이트, 제네릭(Generics), 에러 처리(Error Handling)

Hello Rust

언어 공부의 국룰은 인사하기. 아래의 과정으로 설치하면 된다. (Window11 환경, VSCode는 별도 설치)

1) Rust 설치

링크에서 rustup-init.exe 파일을 다운로드 할 수 있다.

1번 옵션으로 설치했다.

설치하는 데 시간이 걸리니 요 친구를 VSCode에 설치해두자.

친절도 해라.. 1번으로 설치. cmd에서 아래 명령어를 실행해 버전을 확인 할 수 있으면 된다.

rustc --version

2) Rust 프로젝트 생성 및 실행

설치한 "cargo"가 자동으로 프로젝트를 구성해주는데, 프로젝트 이름은 digit으로 시작할 수 없다고 한다. (~~벌써 빡세다.. 숫자는 외않되?~~)

cargo new hello_rust

만들어진 디렉토리 내부를 확인해보면, 기본 구조가 잡혀있다.

main.rs 파일을 열어보면, Hellow, World 출력을 위한 코드가 기본적으로 잡혀있다.

이를 아래와 같이 수정해보니,

자동으로 Cargo.lock 파일이 생성되었다. 이게 어떤 역할을 하는지는 차차 알게 되겠지..

프로젝트 내에서

cargo run

을 실행하면,

컴파일 후 결과를 보여준다.

그리고 프로젝트 내의 변화를 보면,

"target'이란 이름의 부산물이 생겼다. 자동으로 "debug" 내에는

.exe 실행 파일을 포함해 이런 것들이 생겼다.

반복해서 실행해보니, runtime이 0초인 것으로 보아 재컴파일이 필요 없도록 캐싱을 하나보다.

Window 환경에서의 개발과 구조화된 프로젝트에 익숙해질 기회가 생긴 것 같다.