4개월 차 신입 AI Engineer가 스타트업에서 배운 것들
최규민
2026년 3월 2일2 분 소요
AI 엔지니어로 일 한지도 이제 4개월이 지나 5개월 차에 접어들었고,
가장 많은 성장을 이뤘다 생각했던 2025년 상반기에 견줄 만큼 많은 성장을 이뤄낸 지난 4개월이었다.
AI 프로덕트 개발이 점점 많아지는 시점에서 합류하게 되어 내가 할 수 있는 일이 많았고,
결국 붐이 온 AX(AI Transformation) 관련 업무도 많이 맡을 수 있어 너무 행복한 시기를 보내고 있다!
지난 글에서 겨냥한 바와 같이 모델러 보단 소프트웨어 엔지니어에 가까운 개발자로 일하고 있는데,
- 우리 회사에는 온프렘 GPU 서버가 없고
- 생성형 AI 서비스가 많지 않았으며
- AI 엔지니어 팀은 나 혼자고
- 내 엄밀한 기능조직으로서의 소속은 백엔드 개발팀이다.
전임자의 퇴사와 내 입사 까지 AI 엔지니어의 공백이 한 달 가량 되는 상태였고,
따라서 AI Software Engineer로서의 역량은 물론 백엔드 엔지니어로서의 역량과 1인 팀에서 일하는 방법에 대해서도 많은 배움이 있었다.
수습 3개월이 지나고도 1개월이 더 지난 지금 시점에서, 지금까지 AI 소프트웨어 개발 초기 단계의 스타트업에서 내가 배운 것들을 정리해본다.
문서화를 철저히
'프로젝트를 진행하는 팀원 중 몇명이 제대로 된 인수인계 등의 절차 없이 갑작스럽게 빠지게 되었을 때 프로젝트가 중단 내지는 그에 준하는 심각한 상황에 놓이는지'를 나타내는 지수로, 평상시 팀원간의 정보 공유 정도나 업무 대체 가능 여부 등을 종합적으로 반영하는 지표이다.
버스 팩터란 명칭은 저렇게 팀원이 갑자기 빠지게 되는 경우의 예시로 버스에 치여서 죽는 경우를 들었기에 붙은 것이다.
출처 - 나무위키(https://namu.wiki/w/버스 팩터)
우리 팀(AI 엔지니어)은 나 혼자다!
이 말은 즉 내가 만드는 제품이 어떤 원리와 어떤 환경으로 작동하는지 문서화를 하지 않으면 프로덕트의 개발이 블랙박스에 빠질 확률이 매우 높다는 뜻이다(물론 요즘이야 코딩 에이전트가 다 해주겠지만).
출근하다 버스에 치이면 “이제 AI 개발 누가 해주냐”인 상황!
전임자님 또한 이를 우려하셨는지 매우 상세한 인수인계서를 작성해 주셨고, 실제로 버그를 잡거나 워크플로우를 파악하는 데에 많은 도움을 받았지만, 누락된 부분이나 모호한 부분들이 많아서 처음에는 적응에 난황을 겪기도 했다. “이게 뭐 하는 데에 쓰는 거지?”의 연속이라고 해야하나.
이런 나를 구해준 것은 deepwiki-open 이라는 오픈소스였는데, 이전부터 잘 사용하고 있던 deepwiki의 오픈소스 버전이다.
ollama 및 커스텀 임베딩 적용 가능 등의 plug-and-play가 가능한 점이 좋았는데, 메인테이너가 밝힌 바로는 시작부터 gemini-cli로 작성된 오픈소스여서 무수한 버그들이 있었다.
이를 개선하고 팀(이라고 해봐야 나 혼자지만)이 운영 중인 코드베이스를 상세히 문서화 하고자, wiki-as-readme 라는 오픈소스를 만들어 직접 사용하고 있다.
wiki-as-readme를 통해 인수인계서엔 나와있지 않은 상세한 워크플로우 등등을 알 수 있게 되었고, 개발 중인 프로덕트를 빠르게 이해할 수 있었다.
덕분에 우리 회사가 앞두고 있던 큰 규모의 국가과제의 서류 작업에도 도움을 드릴 수 있었고, 다행히 무사히 2차 년도 선발에 통과하여 개발 중이다.
처음에는 나만 쓰는 툴이었지만 iOS 개발자님도 기여해주시며 팀이 함께 쓰는 툴로 거듭나는 중!
단순한 레거시에 머무르지 말자
당연히 모든 팀에는 레거시가 있기 마련이지만, 단순한 레거시는 빠르게 타파할 수 있다고 생각한다.
그리고 단기적으로나 장기적으로나 개발 편의성을 위해서라도 꾸준한 리팩토링은 필요하다.
내가 팀에 합류한 시점에서 AI 프로덕트는
- Git 등을 통한 형상 관리가 안 되어 있고(모든 함수가 Cloud Run이나 Lambda, SageMaker에만 있음)
- 파이썬 백엔드의 경우 타입체킹 등등이 갖춰지지 않은 상태였고
- CICD가 없었다.
wiki-as-readme를 통해 구조를 파악한 뒤 가장 먼저 착수한 일은 이런 사항들을 바로 잡는 일이었다.
우선 프로덕트가 사용 중인 모든 서버 코드베이스를 Git에 올리고, 팀이 사용하는 Jenkins를 통한 CICD 파이프라인을 구축했다(실제로 AWS ECR을 정리하던 도중 이미지 하나가 삭제되어 서비스 장애가 발생한 이슈가 있었고, 다행히 SageMaker에서 코드를 발견해서 복구하기도 했다…).
파이썬 백엔드는 Pydantic, orjson 등을 사용하여 보다 백엔드에 가까운 코드로 리팩토링 하였고,
개발 편의성을 위해 모던 파이썬 생태계에서 떠오르는 astral의 삼신기, uv, ty, ruff를 사용하여 클린 코드를 지향하였다.
리팩토링 과정에서 torchserve 서버에서 심각한 메모리 누수가 있음(요청을 13번 보내면 서버가 죽어버린다!)을 발견하고, 적절한 추상화와 싱글톤 처리, GC 등을 통해 해당 서버의 비용을 25퍼센트 수준으로 줄여버린 일도 있었다.
물론 이 모든 것은 내가 담당하는 프로덕트의 개발 일정이 느슨한 덕도 있었지만,
실제로 바로 패치하지 않으면 심각한 상황이 벌어질 수 있는 지점들이 많았고, 새로운 기능을 심는 것보다 레거시를 청산하며 전면적인 리팩토링을 거친 것이 적절한 선택이었다고 생각한다.
“로컬에서 빌드 해봤나요?”
사실 이건 좀 부끄러운 건데… 나는 로컬에서 빌드+테스트하고 Push하는 습관이 없었다!
그럴 만한 사유라고 한다면 내 거의 모든 사이드 프로젝트가 홈서버에서 운영 중이라는 점이다.
당연히 개발망/운영망을 나눠 놓긴 했지만, 일단 무지성으로 develop에 push 하고 직접 QA 해보는 식의 워크플로우가 익숙해져 있었고,
팀이 사용하는 Spring Boot에 대한 이해도 부족도 원인이라면 원인이었다(Gradle 설치법을 몰랐다거나…).
지금은 당연히 로컬에서 빌드 테스트를 먼저 하고(그 전에 린터 포맷터 체크도 하고) 개발망에 올리고 있다.
네이밍 룰의 중요성 - Prefix를 활용하자
우리 팀의 서비스는 MSA로… 무수히 많은 레포와 서비스가 있는데, 처음에는 어떤 기능을 수정할 때 어디를 고쳐야 하는지 감도 잡히지 않았다.
이는 사내 개발팀 네이밍 룰을 파악한 뒤에는 해결됐는데, 서비스 타입과 이름 등을 kebab case 등으로 적절히 조합하는 방식-즉 서비스 명 앞에 prefix를 적절히 붙이는 방식-으로 운영되고 있었다.
홈서버를 운영하며, 운영 중인 서비스나 인스턴스 이름이 시간이 조금만 지나도 헷갈리는 일을 꽤 겪었는데, 이를 보고 내 개인 개발환경에도 바로 적용했다.
가령, 나는 GPU가 달린 WSL 데스크탑과 CPU만 있는 미니PC 두 대의 서버를 운영 중인데, 각각의 SSH 검증 키 이름을
server-ssh-cpu-machine
server-ssh-gpu-machine등으로 설정하는 것이다.
마무리 하며…
입사 후 4개월 간 정말 많은 일을 겪었고, 많은 성장을 이뤄냈다.
상술한 개발 관련된 것들 외에도 얻은 점이 있다면…
사실 인턴십 당시에도 이렇다 할 협업을 진행해보지 않았음에도
“나 정도면 소프트 스킬 나쁘지 않지”
라고 근거 없는 자신감이 있었는데, 실제로 PO/디자이너/프론트/백엔드 개발자 분들과 협업을 진행하니 아 정말 나쁘지만 않은 수준이구나…!를 깨닫기도 했다. 중간 보고의 중요성이라든지…
몇 년 전까지만 해도 내가 개발자를 할 줄은 몰랐는데, 1년 만에 갑자기 정규직이 돼서 워커홀릭처럼 일하고 있다.
그리고 팀이 점차 AX에 접어들며, AI 엔지니어로서 내가 할 수 있는 일들도 점차 많아지고 있다.
앞으로도 꾸준히 성장하며 팀의 성장에 기여할 수 있는 AI 엔지니어가 될 수 있도록, Bus Factor가 1이지만 다른 회사 AI 엔지니어 팀 부럽지 않은 팀이 될 수 있도록 노력해야겠다.