[회고] 1년차를 마무리하며

00. 회고에 앞서

2023년 2월 1일에 입사하여 곧 1년차를 마무리하는 시점에 회고를 위해 방치하던 블로그를 열었다. 출퇴근 길, 하루를 마무리하며 잠들기 전, 종종 맞이하는 여유로운 주말 등등의 시간에 자연스럽게 나의 일과 일상을 돌아보긴 하지만, 그래도 굳이 글로 정리해보려는 이유는 아래와 같다.

• 나는 기억력이 좋지 않다. 흐릿한 기억이 사라지기 전에 기록을 남기고 싶다.
• 목적을 가진 글을 잘 쓰는 연습을 하고 싶다.
• 주기적으로 쌓인 경험을 잘 엮어 정리하고 싶다. 내가 이렇게 성장해왔구나, 미래에 생각할 수 있었으면 좋겠다.

반복하면 나아질 것을 기대하며, 생각나는 키워드를 중심으로 적어보려한다.
 

01. 올해의 Keywords

01-1) 당장 해결하지 못해도, 외면하지 말자

누구나 그렇겠지만, 내가 입사하기 이전에 존재했던 것들과 익숙해지고 친해질 시간이 필요했다. 함께 일하는 사람들이나 사내 문화와 같은 것부터 협업 및 형상관리, 현재 배포된 모델과 연구 개발 단계의 모델링 과정, 현재가 있게한 히스토리와 앞으로의 방향성과 같이 나의 업무와 직접적으로 연결된 디테일한 부분들까지. 모든 것이 배우고 익혀야 할 내용들이었다. 
 
우리 회사는 부서별 상시 채용을 하기에 회사 차원의 신입 교육이라든가 온보딩 프로세스는 존재하지 않았고, 나는 2022년 말부터 충원된 3명 중 막내로 내 사수격 사람들과 3-4개월의 텀을 두고 입사하게 되었다. 음성인식 모델링 경험이 있긴 했지만 실무에서 필요한 지식은 부족한 상황이었고, 음성인식과 관련된 기초적인 교육을 받은 뒤 배포되어 서비스되고 있는 모델의 모델링 과정을 익히고 개선하는 것이 나의 업무의 시작이었다. 신입 사원의 교육을 담당하는 부서나 인원이 따로 있지 않아 본인들의 업무는 업무대로 수행하며 인수인계 및 교육이 이루어졌기 때문에, 그 과정이 체계적이라 느껴지지는 않았다. 그래도 그 속도가 꽤 빨랐을 뿐 질적으로 부족하다는 생각이 들지 않아 다행이었다.
 
이후 기존 배포 모델의 모델링 및 서비스 과정을 인수인계 받으며 아래의 문제를 파악하게 되었다.

• G2P(Grapheme to Phoneme) 모델이 변환 가능한 완성형 2350자가 표현하지 못하는 표준어가 많다. 또한 모델의 output이 잘못된 경우가 다수 발견되었다.
• lexicon 내에 불필요한 word가 많았다. 이는 기반이 되는 corpus가 제대로 정제되어있지 않음을 의미했다.
• Noisy한 환경에는 robust 했으나, noise에 대한 insertion이 과도하게 발생하는 경우가 발견되었다.

문제의 원인을 파악하고, 해당 문제를 개선하고, 이를 검증해 반영하는 과정은 당시에 내가 생각했던 것보다 훨씬 많은 시간과 에너지를 필요로 했다. 때때로 내가 생각하는 것보다 중요한 agenda로 다루어지지 못했고, 내가 원하는 것보다 더 적은 일정을 할애해야 했기에 안그래도 바쁜 와중에 긁어 부스럼인가 싶기도 했다. '엔지니어라면 발견한 문제를 발견한 이상 해결해야 한다'는 단순한 신념 아래 가능한 범위 안에서 개선을 시도했으나, 때때로 기대했던 것보다 실질적인 모델 성능 향상으로 이어지지 않아 실망하기도 했다.
 
하지만 돌아보면 문제의 원인을 찾고 해결 방법을 탐구하는 것은 모델링 과정을 이해하는 데에 큰 도움이 된 것은 물론이요, 이후 다른 상황에서 유사한 잠재적 위험을 감지할 수 있는 힌트가 되었다(이런 데이터가 들어가면 이런 문제가 생길텐데?). 뿐만 아니라 시기가 다를 뿐 해당 문제점은 실제 서비스 상에서의 개선 요청 등으로 잊을만하면 눈 앞에 다시 나타나, 효용이 없을 것 같던 개선된 모델도 빛을 발하는 순간이 찾아오곤 했다. 
 
작년의 나에게 귀띔할 수 있다면, 아래와 같이 말해주고 싶다.
 

문제가 발견된다면 원인을 반드시 파악하고 기록할 것. 당장 해결할 수 없다면, 정기적으로 누적된 문제의 우선 순위를 정리하고 해결할 것. 서비스를 위한 모델링은 정량적 수치가 전부가 아님을 기억할 것.

01-2) VAD - 모델링 A to Z

기존 VAD가 잡음에 대한 FA이 빈번한 문제를 개선하고, 보다 가볍고 성능이 좋은 E2E 기반의 VAD 모델 학습이 가능할지 여부를 검토하기 위한 프로젝트를 담당해 시작했다. 시작할 당시에는 VAD의 개념조차 처음 접했고, 기존 모델 학습을 위한 빌더 내에서 잡음 mixing, 데이터 라벨링 등의 부분에서 문제와 한계가 발견되는 상황이었다. 처음에는 내가 개발한 것도 아니고, 유지보수가 이루어진지도 한참 지난 낡은 코드를 분석하고 수정보완하며 업데이트 하는 과정이 피곤하게 느껴지기도 했지만, 돌아보니 아래의 수확이 있었다.

• VAD의 동작 원리와 한계에 대한 이해
• VAD를 위한 데이터 수집 및 라벨링 과정에 대한 경험
• (서비스 측면에서의) 모델 유지보수의 중요성 - 결국 쓰일까? 싶었던 업데이트된 모델이 필요한 순간이 찾아왔다
• 소스코드 형상관리의 중요성
• 올바른 테스트 셋 생성 및 선정의 필요성

특히나 담당자가 퇴사하면서 구전동화처럼 전해지는 히스토리에 의존한 소스코드 개발 및 모델링이 아주 어려웠는데, 그 경험을 직접 한 덕분에 E2E로 넘어오면서 보다 구조화된 프레임워크를 찾고, git 기반 형상관리의 필요성을 더욱 강하게 어필할 수 있었다. 또한 학습 데이터 및 평가 데이터도 워낙 부족하고 기존에 존재하던 것들도 엉망인 상황이었는데, 덕분에 구체적으로 그 문제들을 하나하나 발견하고 해결해 나가는 과정에서 음성 데이터 자체를 더 들여다 볼 기회가 자연스레 많았고, 필요한 데이터가 있다면 수집하는 데 있어서도 그 속도가 붙었다.
테스트 셋 생성 과정에서는 직면한 문제에 따라 일일히 음원을 들으며 내가 레이블링 하기도 하고, 그것이 불가능한 상황에서는 접근성 면에서 용이한 오픈 모델들을 기반으로 앙상블을 통해 정답지를 생성하기도 했다. 결국 정확도와 작업공수 사이의 trade-off는 존재하기 마련인데, 상황에 따라 유연하게 대처하는 경험을 했다는 점에서 만족스럽다.
이후 신규 프레임워크 탐색, 데이터 수집 및 라벨링, 빌더 리팩토링, 모델링의 과정을 거쳐 E2E 기반 VAD 개발을 진행했다. 논문을 직접 구현할 정도의 시간은 주어지지 않아 이미 개발된 코드를 사용한 점은 아쉽지만, 나의 상황에 맞게 적용하는 과정에서 자연스레 dataclass 기반의 객체 관리의 유용성을 알게된 점, 기존 형태로 학습을 진행했을 때 속도 면에서 병목이 발생하는 지점을 분석하고 이를 해결한 점, 그리고 현재의 음성인식 모델과 같은 input feature를 활용하기 위해 frontend를 변경하는 과정에서 음성 특징 추출 과정을 보다 심도 있게 들여다 본 것이 좋았다.
아쉬운 점이 있다면, amplitude 기반으로 라벨링을 진행하고, 이에 적합한 데이터 셋을 활용하여 그리고 잡음을 적절하게 활용하여 어느 정도의 성능을 낸 것은 사실이지만, 그 과정이 보다 논리적인 과정으로 진행됐다면 어떨까 하는 부분이다. 실제 음원 예시와 어느 정도의 통계적 수치에 기반에 판단을 하긴 했지만, 논리적 비약이 발생했던 것은 부정할 수 없다. 결과가 좋지 않았다면,, 그 논리적 결함을 보완해 나가는 것이 꽤 어렵지 않았을까..
가장 후회되는 것은 바로 히스토리 기록.. 내가 가장 고통 받았던 부분임에도 매주 보고자료를 만드는 것으로 어느정도 추적할 수 있다는 핑계로 제대로 남기지 못했다. 물론 이건 우리 회사의 구조적 문제이기도 한데, 꽤나 퀄리티가 높은 수준의 보고 자료를 매주 만들어내야 하는 부담이 실제로 존재하기 때문에, 유의미하게 히스토리를 남기는 과정도 그게 관리되는 과정도 생략되기 쉽다. 하지만 결국 늘 문제가 발생하거나, 어떤 이유로 추가 작업이 발생하게 되면 기록에 의존하게 되므로,, 그리고 나는 기록에 매우 취약하므로,, 나를 위해서라도 보다 신경써야 하는 부분이다.

01-3) 영어모델학습 - 결국 답은 데이터에 있다

지금도 진행형인 영어 ASR 모델 개발. 사실 이미 한국어 쪽에서 검증된 빌더를 가지고 영어 모델을 학습하는 것이라 인계 당시에는 부담이 적은 일일 것이라 생각했으나, 모든 일이 그렇듯 생각지 못한 문제들을 만나고 해결하는 과정을 겪었다. 기억나는 몇 가지는 아래와 같다.

• Sentencepice Tokenizer 적용 → 토큰이 뭔가 이상한데..?
• 준비된 학습 데이터 → 데이터가 뭔가 이상한데..?

난 이미 Tokenizer 및 학습 데이터에 대한 준비와 실험이 어느정도 진행되고 있었던 시점에 인계를 받았다. 당시 내재된 문제를 밝혀내는 데에도 꽤 오랜 시간이 걸렸는데, 지금 돌아보면 아주 기본적인 것들에 대한 크로스체크가 당연히 필요하다는 사실을 너무나도 간과했던 것 같다. 예를 들면 토크나이저의 토큰 구성은 어떤지, 데이터는 어떤 종류가 얼마나 있고, 각각의 DB는 분류별로 어떤 음원들인지 직접 들어보고 텍스트를 까본다거나.. 당시 매주 서버를 쉬지 않게 돌리고 그 결과 수치를 확인하는 작업에 매몰되어 정작 중요한 작업들에 대해서는 모델링 결과가 이상하다는 사실을 보고 나서야 시간을 투자하는 아주 큰 오류를 범했다. (덕분에 시간도 꽤 날렸다고 생각한다.)
특히 데이터에는 아주 많은 문제가 있었는데 녹음 자체가 잘못되어 있거나, 샘플링 변환 과정에서의 오류, 전사 오류, 데이터의 불균형한 augment 등 다양한 문제를 안고 있었다. 기존의 데이터를 최대한 활용하면서 문제를 수정하는 방향의 해결 방안을 우선적으로 기획하였으나, 데이터의 절대 양도 부족한 상황이었고 애초의 수정의 작업 공수가 제로 베이스에서 시작하는 것보다도 클 것으로 예상되었기 때문에 데이터 수집부터 다시 수행하는 태초마을로의 귀환을 선택했다. 
결과적으로 아주 잘한 일이 되었는데, 아래의 이유 때문이다.

• 데이터 수집 & 모델 학습의 롤과, 데이터 정제의 롤을 구분해 협업을 진행
  • 매주 정기 회의를 하며 태스크를 나누어 수행하는 사내 협업 경험은 소통의 효율성을 고민해볼 수 있었다는 점에서 의미 있었고, 결과적으로 모델링에 더욱 집중할 수 있게 되어 보다 다양한 학습 기법을 고민하고 실험할 수 있는 발판이 되었다.
• 코드 리뷰와 페어 프로그래밍 등의 경험
  • "더 나은 방향성의 소스 코드를 함께" 개발한다는 것은 생각보다 어려운 일이다. 시간을 들여 리뷰를 남기고, 개선을 요청하고, 그것이 잘 이루어졌는지 검토하고, 때로는 함께 개발을 진행하기도 하는 과정을 회사에서 해본 것은 처음이었는데 내가 상대방을 대하는 태도에서 잘하는 것과 어려워하는 것을 알 수 있어 좋았다. 하나씩만 기록해보자면, 나의 의견을 피력하는 데 있어 그것을 상대방이 알아듣기 쉽게 설명하는 데에는 능한 면이 있었지만 실제 상대방의 몫으로 필요한 부분을 요구하고 관철하여 결과로 완성되기까지의 과정을 (필요한 상황에서) 밀어 붙이는 것이 부담으로 느껴지는 점은 약점이라 생각된다. 나는 아직까지 "나쁜 사람"이 될까 두려워하는 것 같은데, 일을 정확하게 요구하는 것은 결코 나쁜 일이 아니라는 점을 타인 뿐만 아니라 나에게도 적용해야 한다.
• 학습 파이프라인의 구축
  • 이제는 직접 업무에 관여하지 않는 다른 파트원들도 "내가 신규 데이터를 수집하면, J가 정제를 진행하고 내가 그것을 학습에 반영한다"는 사실을 인지하고 있다. 어떤 일이 돌아가는 프로세스가 정립되고, 이를 담당자 외에도 팀이 인식하여 그 예상 범위 안에 들어오게 하는 것 역시 체계의 한 부분이라 생각한다. 안정된 체계가 만들어졌을 때 조직이 개인의 역량에 의지하는 정도가 줄어들 수 있으며, 그게 곧 어느정도는 일이 잘 돌아가는 것을 의미한다고 생각한다.

결국 태초마을로 돌아가 더 많은 데이터를 수집하고, 이를 입맛에 맞게 정제하고, 그걸 활용해 모델 학습을 한 결과 유의미한 성과를 낼 수 있었다. 또한 VAD 개발 때의 경험을 바탕으로 히스토리를 남기는 일에도 좀 더 신경쓰고 있고, 다른 팀원들이 활용할 수 있는 형태로의 소스 코드 개발도 수행하면서 팀에 기여할 수 있는 좋은 기회였다.

01-4)  GIT, 논문스터디 - 내 주변의 문화 바꾸기

누군가 어떤 동료로 기억되고 싶냐고 묻는다면, "그 주변을 긍정적인 방향으로 이끄는 힘이 있는 사람"이 되고 싶다 답한다. 다소 추상적일 수 있지만, 실제로 늘 그렇게 노력하기 때문에 돌아보면 실질적인 변화를 만들기 위해 노력했고 가시적인 변화도 있었다.

• SVN to Git

회사에 와서 정말 놀랐던 점 중 하나인데, 형상관리가 제대로 이루어지지 않는 문제가 있었다. 기존 파트 내 개발자 수가 적었고, 그래서 사용되던 svn마저 제대로 기능하지 않고 있었던,, 입사 당시부터 바꾸고 싶었고, 모두가 그렇게 잘 알지는 못하는 상황에서 누군가는 시간을 투자해야 했던 상황이었기 때문에 기초 지식을 공부하고, 기본적인 규율을 정리해서 공유하는 시간을 정기적으로 가지려 노력했다. 한 가지 느낀 것이 있다면, 어떤 문화를 새로 정착시키고자 할 때는 전달되는 정보의 양과 질도 중요하지만 그것이 듣는 이들에게 '잘' 수용되는가, 그리고 문화로 자리잡을 수 있도록 반복적으로 제시될 상황을 만들 수 있는가가 중요했다. 마치 아이들을 가르치는 것과 같다는 느낌이 들었다. 시간이 필요하고, 한 걸음씩 차차 약속이 이행되는지를 잘 점검해야 했다. (현재 진행형..)

• (논문) 스터디

필요하다고 생각했었지만, 내가 제안한 것은 아니었다. 이 측면에 있어서는 누군가 먼저 앞장서 주었을 때, 그것을 적극적으로 잘 수용하고 그 문화가 잘 유지될 수 있도록 힘쓰는 역할을 하고 있다. 워낙 일이 바빠서,, 아무래도 주기도 자꾸 길어지고 스킵하는 경우들이 생기고 있는데 그 필요성을 상기하고, 내가 나서서 한 번이라도 더 하고, 또는 진행 방법을 조금 바꾸어 그 준비 부담을 줄이는 등의 방향으로 만들어진 문화를 기능하도록 심폐 소생하려 노력 중이다. 실제로 연구자와 개발자 그 어딘가 사이에 위치하는 우리 직무의 특성상, 논문을 통해 꾸준히 새로운 아이디어를 접하는 일은 당연히 중요하다. 뿐만 아니라 특정 내용에 대해 스스로 자료를 정리하고, 누군가에게 설명할 기회는 사실 굉장히 소중한 기회이고 그 주제나 완성도에 관계 없이 누구나에게 성장의 발판이 될 수 있다고 믿는다. 최근에는 각자 진행하는 업무의 디테일한 과정이나 시행착오, 실험 설계와 그와 관련된 세부 자료 등을 공유하기 위한 시간으로도 활용하고 있는데, 각 개인의 의사결정 과정을 보다 자세히 엿볼 수 있는 기회여서 좋다.

02. 잘한 것과 아쉬운 것

👍) 목표의 설정과 달성

처음 VAD 관련 개발 목표와 세부 계획을 세울 떄, 그리고 영어 모델 학습 목표 인식률을 설정할 때 아무래도 경험이 많지 않은 것이 어려움을 주었다. 어떤 시행착오를 만날지, 내가 하고자 하는 일에 얼마만큼의 시간이 실제로 소요될 지 가늠하기 어려웠다. 특히나 입사 이전 프로젝트에는 대부분 일정의 데드라인이 우선적으로 정해져 있는 경우가 대부분이었기 때문에,  목표에 알맞는 일정 산정부터 시작하는 것이 쉽지 않았다. 

예상 밖의 상황을 만나고 계획이 수정 보완되는 것이 불가피한 일이라고 한다면, 큰 틀에서의 계획이 틀어지지 않는 선에서 성공적으로 설정했던 목표를 달성했거나 달성하고 있어 만족스럽다. 일정보다 일찍 일이 마무리되는 것은 문제가 되지 않지만, 일정이 밀리는 것은 큰 문제가 될 수 있는 만큼 모든 세부 태스크에 여유 일정을 확보하는 것이 좋고, 일정 내 불가능한 목표라면 때로는 과감하게 포기하거나 대안을 찾는 것도 중요하다는 것을 배웠다.

👎) 기록과 히스토리는 중요하다

때로 실무를 바쁘게 처리하다보면, 진행한 업무에 대해 정리하고 기록하는 것이 후순위로 밀리기도 한다. 매주 보고 자료를 만들고 주간 진행 업무에 대해 정리해두긴 하지만 종종 각 프로젝트 별 세부 히스토리가 필요하기 마련이다. 소스코드에 대한 형상관리는 git에게 맡기면서 그 부담이 줄었지만, 그 외 데이터 수집이나 모델링, 실험 설계와 그 결과의 경우 기억에 의존하거나 서버 내 로그 등에 맡기기에는 무리가 있다.

지난해 퇴사자가 인수인계를 진행할 때, 혹은 내가 진행했던 부분에 대해 한참이 지나 다른 팀원에게 그 내용의 일부를 전달해야 하는 일이 생길 때, 혹은 실 서비스 상의 어떤 이슈로 인해 그 문제 상황에 대한 원인 등을 추적해야할 때 등등 기록이 필요한 순간은 생각보다 자주 생긴다. 돌아보면 나는 히스토리를 남기는 일에 있어 꾸준하지 못한 모습을 보이기도 했는데, 이는 내가 그 중요성을 제대로 인지하지 못하여 그것이 중요한 "업무"라고 생각하지 않았기 때문인 것 같다. 마치 히스토리를 정리하는 일은 "쉬고 있는" 듯한 느낌을 받았고, 그래서 빠르게 끝내고 실무를 처리해야 한다는 생각을 하기도 했다. 실제로 나의 인식보다 훨씬 중요한 일이므로,, 더 효율적이면서도 잘 기록을 남길 수 있는 연습이 필요하다.

03. 2년차를 바라보며

• 2년차에 이루고 싶은 것

아무래도 이 일을 시작할 때는 직무에 대한 흥미, 그리고 현실적인 필요성과 조건에 초점을 맞추어 직업을 선택했기 때문에 중요한 문제들에 대해 나만의 답을 가지지 못한 채 일을 시작했다. 1년 간은 새로운 상황에 적응하고, 주어진 업무를 처리하기에 바빴다면, 2-3년차에는 더 많은 경험을 바탕으로 아래의 질문들에 보다 정리된 나만의 답을 만들어나가고 싶다.
 
일을 하며 보람과 가치를 느끼는 순간은 언제인지, 내가 잘할 수 있는 것과 그렇지 못한 것은 무엇인지, 이 일을 함으로써 어떤 가치를 창출하고 싶은지, 시장에서 더 인정받는 개발자/엔지니어가 되기 위해 갖추어야 하는 능력은 무엇일지, 음성인식 외에 내가 관심있는 분야가 있다면 어떤 분야일지, 지금 내가 일하는 곳의 장단점이 무엇이며 나는 어떤 환경에서 일하고 싶은지 등등.
 
그리고 일과 업무의 균형을 잘 만들어나가고 싶다. 언제고 필요하면 초과 근무를 할 수 있고, 쉴 때도 내가 원하면 일을 할 수 있다. 다만 의욕이 앞서 무리를 하고 나면, 부작용도 찾아오기 마련이다. 근육이 휴식을 통해 성장하고 때로 무리하면 부상으로 인해 오히려 성장할 기회를 놓치는 것처럼, 일에 있어 성장도 꾸준함이 가장 큰 무기가 될 수 있다고 생각하는데 돌아보면 올해 몇몇 순간들에 지쳐있어 꾸준함을 가지지 못했던 것 같아 아쉽다. 나의 상태를 잘 살펴서 더 달려나갈 수 있을 때는 그렇게 하고, 휴식이 필요할 땐 휴식을 줄 수 있는 유연함을 갖추고 싶다.

 

그리고 내년에도 회고를 남기는 것을 잊지 않아야지.