개인 개발자와 프로페셔널 개발자의 차이
나는 이천 여 사용자를 대상으로 하는 받아쓰기(speech-to-text) 도구를 여러 라이브러리를 조합해 혼자서 만들었고 사내에 서비스 했었으며, 이 경력을 토대로 채용 면접관들의 많은 의심을 뚫고 수천만 명을 서비스 대상으로 하는 국내 굴지의 IT 서비스 회사의 머신러닝 엔지니어로 취직했었다. 여기서 나는 두 개 부서, 총 3개 팀을 거치면서 여러가지 기술과 업무방식을 배울 수 있었다. 최근에는 핀테크 회사에 데이터 사이언티스트로 이직했으나 여기서는 업무 범위에 제한이 더 적어, 나의 경험과 흥미에 따라 머신러닝 엔지니어로서의 역할을 많이 하게 될 것 같다. 약 1년 반이 조금 넘는 시간 동안의 내 경험을 회고해 보면서 내가 개인 개발자로서 일할 때와 달리 대규모 서비스를 하게 되는 조직에서 엔지니어로 일할 때의 차이점을 정리해 보고 싶다. 이 글이 혹시나 그러한 변곡점을 겪고자 하는 분들께 도움이 되기를 희망해본다.
1. 트래픽을 다루기 위한 노력
트래픽은 내 서비스가 얼마나 많은 사용량을 가지고 있는지를 나타낸다. 구체적으로는 얼마나 빈번하게 대량의 데이터 전송과 연산이 요구되는지를 의미한다. 예를 들어, 수천 명이 주 평균 1회 사용하는 서비스는 하루 평균 약 280회의 트래픽을 발생시키지만, 동일한 서비스가 수천만 명의 사용자를 대상으로 할 경우, 트래픽을 안정적으로 처리할 수 있는지를 신중하게 고려해야 한다.
서비스를 사용자에게 제공하는 것을 '서빙'이라고 하며, 특히 B2C 회사의 경우 실시간 트래픽을 다양한 서비스에 대해 처리해야 하므로 트래픽을 분산시켜야 한다. 청약과 같은 대규모 서비스에 접속자가 몰려 장시간 대기하거나, 특정 서비스가 과부하로 인해 웹사이트가 다운되는 경우를 뉴스에서 볼 수 있다. 이를 '서버가 터진다'고 표현하며, 이러한 상황을 방지하기 위해 컨테이너 이미지를 클러스터에 배포하여 운영한다. 로드밸런서는 말 그대로 실행 이미지가 복제된 여러 서버간의 처리 '부하'를 균일하게 배분하는 역할을 하여 대량의 트래픽을 감당한다.
클러스터를 구성하는 데에는 클라우드 엔지니어의 도움을 받아 하드웨어 및 네트워크 설정을 완료한 후, 소프트웨어 엔지니어는 컨테이너 이미지를 생성하고 쿠버네티스(Kubernetes, K8s) 명령어를 사용해 이를 클러스터에 배포한다. 일반적으로 CI/CD 파이프라인(Jenkins, GitHub Actions 등)을 통해 소스 코드가 변경되면 자동으로 새로운 도커 이미지를 생성하고, 이를 쿠버네티스 클러스터에 배포한다. 외부 사용자는 해당 클러스터의 IP 또는 도메인을 통해 서비스에 접근하게 된다.
2. 핵심 기술
개발자는 언어에 크게 좌우되지 않는 경향을 보인다. 왜냐면 언어의 기본 문법은 크게 다르지 않기 때문이다. 그러나 각 언어의 구성 철학에 따라 해당 언어를 효율적으로 쓰기 위한 코드를 짜는 것, 유지보수하기 좋은 코드를 작성하는 것, 그리고 각 언어에서 사용 가능한 여러 도구를 배워 사용하는 것의 과제가 남아있으며 이는 개발자라면 계속 관심을 기울일 수 밖에 없는 측면이라 생각된다. 모델링에서 Python이 활용되는 것처럼, C++의 대안으로 등장하고 있는 Rust, 현재 많이 활용되는 Golang 등은 속도가 중요한 서빙에서 활용된다.
데이터를 위해서는, 데이터의 처리를 위한 빅데이터 솔루션을 활용하는 것은 또 하나의 언어를 배우는 것과 다름이 없다고 생각된다. SQL, Spark 을 자유롭게 사용하려면 어느정도의 학습이 필요하다. 또한 시스템 구성 측면에서 데이터를 어떻게 저장하고 관리할지에 대해서는 수많은 종류의 데이터베이스에 어떤 종류의 데이터를 어떻게 저장하는 것이 최적인지에 대한 고민과 경험에 따른 업데이트, 그리고 많은 데이터 테이블을 효과적으로 관리하기 위한 구체적인 정책과 전략이 필요하다.
대표적인 데이터베이스로는 MySQL, PostgreSQL, MongoDB, Redis 등이 있으며, 각각 장단점이 다르다. MySQL은 안정성과 빠른 읽기 성능이 장점이지만, 고급 기능과 확장성에서 제한이 있다. PostgreSQL은 고급 기능과 데이터 무결성을 제공하며 확장성이 뛰어나지만, 성능과 복잡성 면에서 trade-off가 한다. MongoDB는 유연한 스키마와 수평적 확장성이 장점이나, ACID 트랜잭션 지원이 제한적이며 데이터 일관성 문제가 있을 수 있다. Redis는 매우 빠른 인메모리 데이터 저장 성능과 다양한 데이터 구조 지원이 특징이지만, 메모리 제한과 고급 쿼리 기능의 부족이 단점이다. 각 데이터베이스는 특정한 사용 사례와 요구 사항에 따라 선택하는 것이 중요하다.
3. 협업
나는 프로 개발자가 되기 전에는 Github은 코드를 백업해 두는 정도로 사용했다. 그러다 들어간 K사에서는 내 브랜치에 커밋하는 브랜치를 포함해 메인 브랜치에 머지해야 하는 상황이 닥쳤다. 얼마 지나지 않아 내가 커밋을 머지하려는데 이미 다른 코드의 머지가 있어서 컨플릭트가 나서, 리베이스냐 머지냐를 놓고 고민하게 되었다. git은 생각보다 익히기 복잡하다. 하지만 한 번 익힌 git/github은 나로 하여금 어떤 유명 저자의 책에 등장한 코드의 오류를 잡아 거기에 PR을 올리고 approve를 받을 수 있게 했다. 협업의 링구아 프랑카라 할 수 있는 git이다. 그리고, 두 번 째 부서에서 지라 등의 컨플루언스 도구를 처음 쓰게 되었을 때 매우 성가셨지만, 티켓 빼는 재미를 쏠쏠하게 느끼게 되었다.
만일 프로 개발자가 되기를 원한다면, git을 쓰는 버릇을 들이면서, 많은 케이스를 겪어보기를 권한다. 나도 학습 속도가 빠른 편이지만, git에서 만나는 여러 케이스들에 전반적으로 익숙해 지기 전까지, 초반의 git pro 책 숙독 이후에도 한 1년 정도 걸린 것 같다.