멘토님과 개인 면담을 했다. 삼성전자, 네이버 자소서, 노션 포트폴리오를 사전에 제출했다. 대체적으로 2가지의 큰 주제로 진행했다. 포트폴리오는 읽는 사람인 면접관 혹은 채용자를 위한 글이라는 점, 내가 생각하는 강점인 소프트 스킬을 드러내는 방법이었다. 피드백을 받을 때마다 느낀 점이지만, 사람마다 너무 다양한 케이스가 있어 자신의 배경을 전제로 피드백을 받아들이면, 온전히 흡수하지 못하는 것 같다. 이것이 자소서/포트폴리오 첨삭의 맹점이라고 생각이 든다. 그럼에도 피드백에서 공통 분모는 존재하기 마련인데, 대체적으로 다음과 같았다.
프로젝트의 흐름이 드러나야 한다. 인사 담당자가 글만으로도 프로젝트 전개 과정을 알 수 있어야 한다.
개발 직군의 자소서/포트폴리오에는 객관적인 결과가 드러나야 한다. 그것이 가장 효율적인 소통 방식이기 때문이다.
과제를 하며 의존성 문제가 심했다. 특히 코랩 위에서 동작을 가정으로 출제된 문제였기 때문에 더욱 심하게 느꼈다. 문제의 라이브러리는 torchtext. torchtext는 24년 4월 이후로 공식 지원이 멈춘 상태이기 때문에 앞으로도 사용하지 말아야겠다. 앞으로 프로젝트 혹은 현업 업무에서도 의존성 체크는 수시로 이루어져야겠다는 생각을 다시 했다. (처음은 졸업과제를 진행하면서 생각했다.)
13:00 ~ 16:00
torchtext가 상당히 골때렸다. 해당 과제에서는 build_vocab_from_iterator라는 함수를 사용했는데, 빌더 패턴을 사용하는 코드여서 torchtext 파일을 이래저래 뒤졌다. build_vocab_from_iterator는 vocab 함수를 호출하고, vocab 함수는 Vocab 클래스 객체와 VocabPy... 뭐 이런 클래스 객체를 통해 Vocab 객체를 만드는데, 결론적으로 build_vocab_from_iterator는 Vocab 객체를 반환하면 되는 것이었다. 내가 직접 뜯어본 바로는 Vocab 객체는 defaultdict과 같이 소프트 해싱을 사용하여 없는 키에 접근해도 -1 등의 default index를 반환하고, corpus에서 토큰 배열과 토큰→id 딕셔너리를 저장하는 역할을 했다.
datasets.dataset_dict.DatasetDict 객체도 살짝 살펴봤다. 우선 datasets는 huggingface에서 제공하는 라이브러리로 공개 데이터셋을 손쉽게 불러올 수 있었다. 과제에서는 영어-독어 번역 데이터셋을 사용했다. pandas.DataFrame과는 살짝 다르게, 각 칼럼 별로 딕셔너리가 저장돼 있었다. DataFrame은 칼럼을 선택하면 pandas.Series 데이터셋으로 변하는 반면, 좀 더 형식에서 자유로운 것 같다. 어쨌든 낯선 자료 구조를 사용하니 디버깅에 시간이 많이 걸렸다.
처음에 과제를 진행하면서 행렬 차원 맞추기 게임을 싫어했었다. 어짜피 pre-trained 모델을 파인 튜닝할 것이라고 생각했기 때문이다. 하지만 프로그래밍 개념 학습 과정에서 구현보다 확실한 방법은 없는 것 같다. 특히 에러가 수 없이 많이 일어난다면 적극적인 학습 활동이 이루어지는 것 같다. 이제까지 맞춘 문제에 현혹되는 삶을 살았던 것 같다. 내가 틀렸음을 발견했을 때 더 큰 기쁨을 느낄 수 있었으면 좋겠다. 공부도 삶도.
16:00 ~ 19:00
행렬 맞추기 게임 1단계가 끝났다. 어텐션 구현 문제였는데, 인코더/디코더/Dot-Product-Attention 연산을 구현하는 문제였다. 중간에 모두 클래스 정의 부분이었기 때문에 테스트 코드를 추가했다. 나름 TDD를 한 것 같다. 물론 지피티가 테스트 코드를 작성했긴 하지만.
어제와 마찬가지로 오늘도 성과가 없었다. 문득 앞으로 이런 날이 비일비재할 것 같다는 생각이 들었다. 하지만 괜찮다. 과제는 지침 상 토론으로 해결하면 안 되지만(물론 이것도 충분히 무시할 수 있다.), 앞으로 프로젝트를 하며 발생한 문제는 토론 혹은 브레인 스토밍으로 해결할 수 있기 때문이다.