AI 직무 구분과 R&R - 실무 관점에서 본 역할 정의
AI Engineer, 정말 다 같은 엔지니어일까?
“AI Engineer로 지원했는데 실제로는 데이터 정제만 하고 있어요.”
“AI Research Engineer와 AI Engineer의 차이가 뭔가요?”
“End-to-End AI Engineer라는 직함을 처음 봤는데, 정확히 뭘 하는 건가요?”
AI 업계에 종사하면서 자주 받는 질문들입니다. 실제로 AI 관련 직무는 회사마다, 팀마다 다르게 정의되어 있어서 지원자도, 채용하는 쪽도, 심지어 같은 팀 내에서도 혼란스러워하는 경우가 많습니다.
저도 처음 AI 커리어를 시작할 때 이런 혼란을 겪었고, 지금까지 다양한 포지션을 거치면서 각 직무의 실제 모습을 경험했습니다. 이 글에서는 제가 직접 겪은 AI 직무들의 실제 역할과 책임, 그리고 개인적인 커리어 변화 과정을 공유해보려고 합니다.
1. AI Researcher
AI Researcher는 새로운 알고리즘이나 모델 구조를 제안하고, 기존 기술의 한계를 극복하기 위한 연구를 수행하는 역할입니다. 산출물은 주로 논문이며, CVPR, NeurIPS, ICML, ICCV 등 국제 학회에 제출해 기술력을 증명합니다. 제품을 만드는 목적보다는, 이론적 기여나 SOTA 갱신, 모델의 성능 향상에 초점을 둡니다. 대부분 대학이나 대기업 산하 연구소에 소속되어 있으며, 현실의 데이터보다 논문용 정제 데이터셋과 벤치마크를 많이 다룹니다. 구현보다는 아이디어 중심의 작업을 많이 하며, 코드는 실험을 위한 도구일 뿐 핵심은 기획과 설계에 있습니다.
2. AI Research Engineer
AI Research Engineer는 AI Researcher가 제안한 논문 기반 기술을 실제로 구현하고, 실험을 통해 성능을 재현하거나 개선하는 역할입니다. 논문을 코드로 옮기고 실험 파이프라인을 구성하며, 벤치마크 데이터셋을 기반으로 다양한 실험을 반복합니다. 연구의 논리적 타당성과 구현상의 현실성 사이의 다리를 놓는 엔지니어로, 코딩 스킬과 수학적 이해력을 모두 요구받습니다.
3. AI Engineer
AI Engineer는 실제 제품이나 서비스에 적용할 AI 모델을 학습하고, 데이터셋을 구성하거나 모델의 성능을 개선하는 역할을 합니다. 주어진 목적에 맞는 모델을 선정하고, 필요한 경우 커스터마이징하거나 파인튜닝합니다. 학습된 모델을 기반으로 추론 결과를 만들어내고, 그 결과를 평가하여 다음 학습에 반영하기도 합니다. 비즈니스 요구사항과 기술 사이에서 균형을 맞추는 실무형 엔지니어입니다.
4. Applied AI Engineer
Applied AI Engineer는 고객이나 사용자의 니즈에 맞춰 AI 기술을 실질적인 문제 해결에 적용하는 엔지니어입니다. 자체적으로 Task를 정의하거나, 주어진 과제를 해결하기 위해 적절한 데이터셋을 구성하고, 모델을 실용적인 형태로 만들고 설명하는 데 집중합니다. “이건 가능한가요?”라는 질문에 기술적으로나 현실적으로 “가능합니다” 혹은 “불가능합니다”를 판단하고 설계합니다. 실제 서비스와 맞닿은 AI 개발자의 입장에 가장 가까우며, 설계적 사고와 유연한 문제해결력이 중요한 포지션입니다.
5. AI Backend Engineer
AI Backend Engineer는 학습된 AI 모델을 실제 서비스에 연동하기 위한 시스템을 구성하고, 모델의 추론 결과를 API나 소켓을 통해 전달하는 역할을 합니다. Docker 환경 구성, Python-C++ 바인딩, Redis 및 캐시 브로커 구성 등을 통해 분석엔진과 실서비스 간의 연결을 책임집니다. 모델 학습에는 직접 관여하지 않으며, 학습된 모델을 “서빙 가능한 형태”로 가공하고 실행 환경을 안정화하는 데 초점을 둡니다. 서비스 운영 단계에서 가장 가까운 위치에 있는 AI 시스템 엔지니어입니다.
6. End-to-End AI Engineer
일반적으로 End-to-End AI Engineer는 데이터 수집부터 모델 학습, 분석엔진 구현, API 연동, 결과 시각화, 운영 배포까지 전 단계를 책임집니다. 다양한 직무 간 경계를 넘나들며 기술적 소통을 주도하고, 시스템 전체의 흐름을 이해하며 실무를 진행합니다. 종종 PM 없는 PO, AI 기술 총괄 역할을 수행하게 되며, 기술 인바운드 대응이나 고객 피드백 수용까지 맡는 경우도 많습니다. 과업의 깊이보다는 넓이와 연결성을 중시하며, 혼자서 프로토타입을 구성하거나 제품화까지 이끄는 유연성이 필요한 포지션입니다.
7. Full Stack AI Engineer
Full Stack AI Engineer는 AI 모델 개발뿐 아니라 프론트엔드와 백엔드까지 아우르며, 실제 사용자에게 도달하는 시스템 전체를 구축할 수 있는 엔지니어입니다. React, FastAPI, AWS 등 다양한 기술 스택을 조합해 웹 인터페이스와 모델을 통합 구현합니다. POC, 데모, 전시용 AI 시스템을 짧은 시간 내에 만드는 데 강점을 가지며, 디자인 감각이나 사용성 고려도 병행하는 경우가 많습니다. AI와 Web 사이의 단절 없이 하나의 서비스로 완성해내는 융합형 개발자입니다.
8. 그 외 실무형 역할들 (직무로 인정받지 않지만 중요함)
| 역할 | 설명 |
|---|---|
| 데이터 수집 | 영상/이미지/센서 데이터를 직접 모으는 과정 |
| 데이터 정제 | 누락 제거, 잘못된 포맷 보정, 샘플 선정 |
| 데이터 라벨링 | 수작업 혹은 오토라벨링 툴을 통한 정답 구축 |
| QA/검수 | 라벨 정확성 검토, 클래스 분류 체계 정비 |
| 보조 명칭 | Data Manager, Annotation QA, Data Ops 등 |
실무에서 가장 시간이 오래 걸리지만, 공식 직무로 분류되지 않거나
외주/비정규직/도급 형태로 분리되는 경우가 많습니다.
AI 개발 프로세스 단계별 직무 기여도
| 단계 | AI Researcher | AI Research Engineer | AI Engineer | Applied AI Engineer | AI Backend Engineer | End-to-End AI Engineer | Full Stack AI Engineer |
|---|---|---|---|---|---|---|---|
| 기획 | ✕ | ✕ | △ | △ | △ | ○ | ○ |
| Task 정의 | ✕ | △ | △ | ○ | △ | ○ | △ |
| 데이터 수집 | ✕ | △ | ○ | △ | △ | ○ | △ |
| 데이터 정제 | ✕ | △ | ○ | △ | △ | ○ | △ |
| 데이터 가공 | △ | ○ | ○ | △ | △ | ○ | △ |
| 학습 데이터셋 구축 | △ | ○ | ○ | △ | ✕ | ○ | △ |
| 모델 학습 | ○ | ○ | ○ | △ | ✕ | ○ | △ |
| 모델 검증 | ○ | ○ | ○ | ○ | ✕ | ○ | △ |
| 모델 최적화/경량화 | △ | ○ | ○ | ○ | △ | ○ | △ |
| 분석엔진 개발 | ✕ | △ | ○ | ○ | ○ | ○ | △ |
| 시스템 배포/운영 | ✕ | ✕ | △ | △ | ○ | ○ | ○ |
| 웹(프론트/UI) | ✕ | ✕ | ✕ | △ | △ | △ | ○ |
기호 설명:
- ○ = 주도
- △ = 일부/협업
- ✕ = 관여하지 않음
이 표는 각 직무가 관여하는 AI 개발 단계만을 나타냅니다. 투입 시간, 책임 강도, 병행 과업 수는 포함되지 않습니다.
현 조직의 AI 직무 구성
| 역할 | 간단 설명 |
|---|---|
| Team Leader | 팀 총괄 및 일정, 외부 협의 전반을 담당 |
| (Almost) Full Stack AI Engineer | 모델 및 시스템 전반 구현, 웹 기반 데모 제작 및 검색엔진 연동 등 |
| 다양한 컴포넌트 개발 | |
| End-to-End AI Engineer | 모델부터 시스템까지 전방위 대응 |
| AI Backend Engineer | 분석엔진을 실서비스에 연동, 시스템 인터페이스 담당 |
| AI Research Engineer | 모델 학습, 알고리즘 연구, 성능 개선, 대회/논문/기술검증 등 수행 |
Team Leader
팀 전체 일정과 외부 대응을 총괄합니다. 고객사, 영업, 대표단과의 기술 협의에 참여하며, 내부 리소스 배분과 역할 조율을 주도합니다. 직접적인 모델 학습이나 분석엔진 개발에는 참여하지 않지만, 전반적인 방향성과 일정을 리드합니다.
(Almost) Full Stack AI Engineer
모델 결과를 기반으로 한 웹 기반 데모 제작, 검색엔진 연동, UI/UX 구성 등 시스템 전반을 폭넓게 다룹니다. Flask 기반 웹서버 구성, ChromaDB, Elasticsearch 연동 등 프론트·백엔드 경계를 넘나드는 구현이 가능하며, 분석엔진이 아닌 데모 중심의 시스템을 주로 설계하고, 필요 시 모델 파인튜닝도 수행합니다. 제품화에 가까운 프로토타입을 구성하지만, 실제 제품화 시에는 프론트엔드·백엔드 개발자가 별도로 투입됩니다. 조직 내에서는 비주력 제품을 중심으로 활동하며, 보조 기술 지원 역할도 함께 수행합니다.
End-to-End AI Engineer
AI 모델 개발부터 시스템 연동, 실서비스 대응까지 전체 흐름을 책임지며, 특히 외부 대응, 출장, 사업관리 협업이 모두 집중되는 핵심 포지션입니다. 모델을 학습하는 것뿐 아니라, 분석엔진에 탑재하고 실시간 환경에서 안정적으로 동작하도록 설계·조율합니다. 배포 이후 발생하는 이슈에 직접 대응하며, 추론 파이프라인, 테스트 구성, config 조정 등 운영 관점까지 폭넓게 다룹니다. 외부 회의 참석, 실증 환경 데이터 수집, 성능 검증, 제품화 대응까지 포함되어 있어, 실질적으로 AI 기반 시스템 전체를 관리합니다.
AI Backend Engineer
분석엔진의 추론 결과를 실서비스와 연결하는 인터페이스 개발을 핵심으로 담당합니다. Python 기반 분석엔진과 외부 시스템 사이의 REST API, WebSocket, Python-C++ 바인딩 모듈을 구현하며, Docker 환경 구성, 디코더/인코더 설정, 메모리 관리, 속도 튜닝 등도 병행합니다. 모델 학습에는 관여하지 않으며, “분석 결과가 실시간으로 서비스에 전달되도록 가공하는 역할”에 집중합니다. 또한, 시스템 내에서 예외 처리, 중단/재시작 로직, timeout 설정 등 운영 안정성을 확보하는 역할도 수행합니다.
AI Research Engineer
모델 학습을 중심으로 한 연구 개발을 전담합니다. 딥러닝 기반 구조 설계, 실험 설계, 성능 튜닝 등 학습 관련 주요 업무를 수행하며, 외부 경진대회 참가, 기술 검증, 논문 작성 등 학술적 성과에도 적극적으로 참여합니다. 모델의 구조적 완성도와 성능 향상이 주요 과업이며, 분석엔진 연동이나 실서비스 적용에는 직접 관여하지 않습니다. 기술의 원천성과 확장 가능성을 높이는 데 집중하며, 연구소 내 가장 학문 중심적인 포지션입니다.
Career Path
1. Data Analyst
저는 전형적인 CS 출신 개발자가 아닌, 상경계열 출신의 Data Analyst로서 AI 커리어를 시작했습니다. 사업관리팀 소속이었지만, 당시에는 개발자가 전혀 없는 조직에서 Python 기반 자동화 도구를 혼자 개발하며 실무를 주도했습니다. 엑셀보다는 Pandas, CLI보다는 Jupyter에 익숙했고, Slack 알림 봇, 리사이징/이름변경/비식별화 도구, 시각화 스크립트 등 다양한 툴을 만들어 데이터 흐름을 자동화했습니다.
수집부터 정제, 가공, 라벨링, 학습 테스트, 검수에 이르기까지 모든 단계를 하나의 FTP 서버 안에서 처리하도록 구성한 초기형 데이터 파이프라인을 직접 설계하고 운영했습니다.
또한, 데이터 상태를 기반으로 공정별 잔여 물량을 분석하고, 일일 리포트를 자동 생성하며, KPI 달성을 위한 추가 수집/보완 계획을 수립하는 등 정량적 관리와 품질 통제까지 총괄했습니다.
모델 학습 자체는 공식 R&R이 아니었지만, 가공단의 책임을 입증하고 “라벨링 문제로 성능이 안 나온다”는 학습단의 주장을 선제적으로 차단하기 위해 직접 라벨링한 데이터를 학습해보는 방식으로 사내 품질 검증 체계까지 구축했습니다.
정식 직무명은 Data Analyst였지만, 실제 역할은 거의 Entry-level AI Engineer에 가까웠습니다. 다만 당시에는 모델 개발보다 “데이터 상태를 분석하고 일정과 품질을 맞추는 것”이 핵심 목적이었기 때문에 경력증명서 상에는 Analyst로 기재되었으며, 이 경험은 훗날 AI Engineer로 전향하는 데 강력한 기반이 되었습니다.
2. AI Engineer
Data Analyst 시절 경험을 기반으로, 본격적으로 AI 모델 학습 중심의 업무에 전념하기 시작했습니다. 특수대학원에서 AI 전공을 병행하며, 실무와 학문을 함께 다져나간 시기이기도 했습니다. 조직 내에서는 연구소 소속으로, 주로 Vision AI 기반 Detection, Segmentation, Tracking 모델을 직접 학습하며 다양한 실험을 반복했습니다.
가장 큰 특징은 단일 모델 구조만을 고집하지 않고, 다양한 아키텍처를 바꿔가며 학습 실험을 주도했다는 점입니다. 오픈소스 기반 모델뿐 아니라, 프로젝트 목적에 맞춰 구조를 튜닝하거나 config를 조정하며 다량의 학습을 수행하는 것이 핵심 역할이었습니다.
실험 목적에 따라 필요한 경우에는 직접 데이터 수집, 정제, 라벨링까지 선행적으로 수행하기도 했습니다. Data Analyst 시절부터 데이터 흐름 전반을 이해하고 체화해온 덕분에, 학습을 위한 데이터 확보와 준비 과정도 능동적으로 처리할 수 있었습니다.
당시에는 최적화, 경량화, 서빙과 같은 후처리 단계에는 직접 관여하지 않았으며, 학습이 끝난 후 성능 지표를 기록하고, 필요시 시각화 기반 정성적 검토를 통해 모델을 개선하는 데 집중했습니다.
정식 직무는 AI Engineer였으며, 핵심 업무는 다양한 모델을 “직접 학습해보는 것” 자체에 있었습니다. 후속 배포보다는 실험적 모델링과 학습 반복 중심의 역할이었고, 학습 중심의 수행 경험이 Applied AI Engineer로 이어지는 기반이 되었습니다.
3. Applied AI Engineer
AI Engineer 시절에는 학습 자체에 집중했다면, Applied AI Engineer로 넘어오면서부터는 학습 결과를 실환경에 적용 가능하게 만드는 일에 무게가 실리기 시작했습니다.
실제 업무는 학습부터 검증, 최적화, 분석엔진 탑재 전까지의 전 과정을 직접 수행하거나 조율했습니다. 당시 제품화 중심의 조직에서, 팀의 필요와 방향성에 따라 Applied AI Engineer라는 직함이 새롭게 도입되었고 그 첫 역할로 합류하게 되었습니다.
연구소가 만든 모델을 검증하고 문제를 파악해 수정하거나, 요청한 모델이 일정 등의 사유로 전달되지 않을 경우 직접 학습부터 경량화까지 전 과정을 대신 수행하기도 했습니다.
정식 모델 개발이 아닌 PoC, 기능 시연용, 전시용 영상 제작 등을 위해 수집부터 정제, 가공, 학습, 검증, 분석엔진 적용 전 시각화까지의 전체 흐름을 혼자서 처리한 경험도 많습니다.
다양한 프로젝트에서 검증 대상이 된 모델들의 정량·정성 평가, 실제 시스템 탑재 전 리소스 체크(fps, 메모리, 실행시간 등), 성능을 보완하기 위한 추가 실험 및 보조 학습, 그리고 테스트셋 구성과 결과 분석까지 포함된 역할이었습니다.
당시에는 모델 개발과 검증의 R&R이 불명확했기 때문에, 연구소와 제품화 팀 사이의 공백을 메우는 실무 조율자 역할도 수행했습니다.
Applied AI Engineer는 말 그대로, 현실적인 제약을 반영하여 모델을 실사용 가능한 형태로 “적용”시키는 역할이었습니다. 실험보다 현장 적용, 구조보다 리소스 조건, 알고리즘보다 ROI(Return on Investment)가 중요한 상황에서 가능 여부를 판단하고, 안 되는 것을 되게 만드는 것이 Applied의 핵심이었습니다. 극단적으로는 “돼요? 안돼요?”가 실질적인 산출물이 되는 경우도 많았습니다.
4. End-to-End AI Engineer
조직 개편과 AI Backend Engineer의 퇴사로 인해, Applied AI Engineer에서 분석엔진과 시스템 연동까지 책임지는 포지션으로 확장되었습니다. 그 결과, 현재는 모델 개발뿐 아니라 모델이 탑재된 AI 시스템 전체를 책임지는 End-to-End AI Engineer 역할을 수행하고 있습니다.
기획 의도 파악, 사전 검증, 모델 설계 및 학습, 분석엔진 최적화, 시스템 반영, 성능 대응, 운영 안정화까지 AI 모델이 현장에서 쓰일 수 있도록 하기 위한 전 과정을 조율하고 실행합니다.
예를 들어, 아래와 같은 역할을 실제로 수행하고 있습니다.
- 고객 요구 사항 기반 Task 정의 및 PoC용 데이터 수집
- 라벨링 가이드 작성 및 라벨 검수/피드백
- 모델 설계 및 반복 학습
- 시각화 기반 정성 평가
- 모델 최적화 및 경량화
- 분석엔진 성능 저하 이슈 대응 (실시간성, 리소스 등)
- 외부 회의 참석 및 실서비스 이슈 실시간 해결
- 실제 웹 인터페이스에서 결과 확인 및 파라미터 조정
- 분석엔진 추론 로그 기반 이상 탐지 및 개선점 도출
기술 스택 면에서는 Python 기반 모델 프레임워크와 함께 GPU 점유율, 추론 속도, 시스템 동작 상태를 체크하며 전체 AI 파이프라인을 다룹니다. Streamlit 기반 간단한 데모도 직접 구성하지만, 복잡한 API 연동이나 시스템 설계는 AI Backend Engineer 또는 Full Stack Engineer와 협업합니다.
모델을 넘어서 시스템 전체를 보는 것이 End-to-End의 핵심입니다. 다만, 시스템 아키텍처 자체를 처음부터 설계하거나 구조적으로 리팩터링하는 CS 중심의 역량은 포함되지 않습니다. 대신 현장에서 바로 돌아가는 실체를 다룬다는 점에서, 실용적 End-to-End에 가깝다고 할 수 있습니다.
정리
| 항목 | AI Engineer | Applied AI Engineer | End-to-End AI Engineer |
|---|---|---|---|
| 목표 | 모델을 잘 만든다 | 기술로 문제를 푼다 | 제품을 완성시킨다 |
| 중점 | 모델 구현·학습·서빙 | 문제 정의 + 도메인 적용 | 전체 AI 파이프라인 구성 |
| 책임 범위 | 모델 단위 (학습~서빙) | 비즈니스 문제에 맞는 솔루션 제공 | 데이터 → 모델 → 추론 → 시스템 연동 전 과정 |
| 시스템 기여도 | 분석엔진 일부 또는 모델 컴포넌트 | 분석엔진 사용·조정 중심 | 분석엔진 + 추론 파이프라인 + API 구조까지 설계 |
| 고객/도메인 이해 | 낮음 | 매우 높음 | 중간~높음 |
| 산출물 | 모델, 서빙 코드, 실험 리포트 | PoC 데모, 기능 검증 시각화 영상, 커스터마이징 모델 | AI 시스템 전체 또는 제품 초기버전 |
| 협업 대상 | 백엔드, MLOps | 백엔드, PM, 고객사, 도메인 전문가 | 백엔드, 프론트, 인프라, PM, 고객 등 전방위 |
Applied vs E2E, 2개월차 회고
1. End-to-End, 진짜 좋을까?
최근 신입 AI Backend Engineer가 합류했지만, 저는 여전히 E2E 역할에서 벗어나지 못하고 있습니다. 외부 회의와 출장 일정이 잦아지면서, 인수인계도 충분히 하지 못한 채 하루하루를 넘기고 있습니다. 일주일에 개발을 이틀도 못 할 정도로 일정이 쏠려 있고, 본래 집중해야 할 개발 업무는 점점 밀려만 갑니다.
전임자가 퇴사한 뒤 AI Backend 역할까지 자연스레 떠맡게 되면서 체력적, 정신적으로도 부담이 큽니다. 막상 일을 나누려 해도 애매한 부분이 많고, 실력 있는 분이긴 하지만 시스템 구조 전체를 파악하기엔 아직 시간이 더 필요합니다. 결국 모델 서치 같은 업무까지도 백엔드에게 부탁하게 되는 현실이 가끔은 미안하게 느껴지기도 합니다. 애초에 그쪽 업무는 그분의 역할이 아닌데 말이죠.
Applied에선 경험으로 커버할 수 있었던 일도 많았지만, E2E는 그렇지 않습니다. CS 기반이 부족한 저에겐 네트워크나 시스템 구조, 인터페이스 설계가 버겁게 다가오고, 이해하지 못한 채 넘기지 않으려다 보니 오히려 더 많은 리소스를 쓰게 됩니다.
2. Applied의 명료한 구조가 그리운 이유
그래서인지 Applied AI Engineer 시절이 자주 떠오릅니다. 요청 기반 업무라 실적을 수치로 드러내긴 어렵지만, 책임 범위와 산출물이 명확했고, 제 성향과도 잘 맞았습니다. 지금처럼 흐릿한 책임선 사이에서 모델, 시스템, 회의, 고객 대응까지 모두 챙겨야 하는 구조보다는, 그 시절엔 단 하나의 질문만 있으면 됐습니다.
“돼요?” / “안 돼요?”
그 한마디로 갈리는 명료한 구조가 저에겐 큰 안정감을 줬습니다. 기술이 기준을 만족하느냐 마느냐, 그 단순한 결론이 오히려 제게는 더 잘 맞았던 것 같습니다. 무엇보다 처음엔 “안 돼요”였던 걸 “되게” 만들어가는 과정이 참 매력적이었습니다. 조금씩 성능을 끌어올려 결국 OK를 받아내던 그 순간의 성취감은 지금도 생생히 기억납니다.
가끔은 퇴사한 전임자가 돌아오고, 제가 다시 Applied로 복귀할 수 있다면 좋겠다는 생각도 듭니다. 하지만 이제는 연차도 쌓였고, 더 많은 책임을 받아들여야 할 시기라는 것도 알고 있습니다.
3. 무게는 늘었지만 권한은 줄었다
사실 저에게 인수인계를 하고 나간 사람이 벌써 네 명입니다. 그 중에는 리더급 1명도 포함되어 있었고, 그 자리를 명확히 메우기도 전에 자연스레 제게로 업무가 몰려들었습니다. 공식적인 리더는 아니지만, 실질적인 리더 역할까지 떠맡게 된 셈입니다.
리더가 아니면 권한은 없고, 책임만 생깁니다. 회의와 구조 파악, 고객 대응까지도 제 몫이 되었고, 정작 본업인 개발은 손에 꼽을 만큼밖에 못 하고 있습니다. VSCode도, Cursor도 켜는 날보다 닫는 날이 많아졌습니다. 이제는 “내가 왜?”, “왜 나만?” 같은 생각조차 줄어들었습니다. 에너지를 아끼기 위해 그런 물음에 더는 힘을 쓰지 않기로 했습니다.
4. 실력은 남는다, 결국은
그래도 한 가지는 분명합니다. 실력은 늡니다. Data Analyst 시절에도 처음엔 구조도 모른 채 일을 떠맡았지만, 버티고 부딪히며 익힌 것들이 결국 지금의 밑바탕이 되었습니다. 그때처럼 지금도 매일 조금씩 영역이 확장되고 있다는 걸 체감합니다.
이직한 지 얼마 안 된 경우에는 인수인계 문서보다 먼저 조직의 구조와 사람들을 살펴봐야 합니다. 어디가 비어 있는지, 그 빈틈이 무너지면 어떤 연쇄 반응이 나에게까지 번질지 생각해야 합니다. 지금의 저는 그 연쇄 반응의 끝에 서 있는 사람입니다.
다음에 이직을 하게 된다면, E2E보다는 Applied AI Engineer 포지션에 더 집중해보고 싶습니다. 현 회사도 제안을 받아 입사했듯이, 언젠가 Applied로 다시 함께하자는 제안이 오길 조용히 기다리고 있습니다. 그 때는 서로의 기대가 일치하는 자리에서, 더 단단하게 함께 일해보고 싶습니다.
그 전까지는 지금의 자리에서 제 역할에 최선을 다할 생각입니다.
그래도 야근은 하지 않습니다. 무슨 일이 있어도 칼퇴근합니다.
최소한의 리소스는 남겨둬야 다음 날도 일할 수 있기 때문입니다.
출장은 여전히 가기 싫지만요.