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

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) 글로 남기기

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