.jpg?table=block&id=348ddf18-253e-8066-bb9f-cdfbf6704798&cache=v2&width=1200)
보안이 중요한 온프레미스 환경에서도 최신 AI 기술을 안정적으로 운영할 수 있어야 한다는 요구가 늘고 있습니다. 엑셈 LLM플랫폼팀은 폐쇄망 환경에서도 동작하는 온프레미스 LLMOps · Agentic AI Builder 플랫폼 'eXemble'을 만들며, 고객의 문제를 기술로 풀어가고 있습니다.
Computer Vision 도메인을 거쳐 LLM 플랫폼으로 커리어를 확장해 온 권효은 님과, Java 백엔드 개발자에서 Product Owner로 영역을 확장해 온 허세진 님을 만나 서로 다른 배경의 두 AI 엔지니어가 하나의 제품을 함께 만들어가는 이야기를 들어보았습니다.
1. 모델 개발과 제품 기획, LLM플랫폼팀의 두 역할
Q. 안녕하세요, 두 분 간단히 자기소개 부탁드립니다.
권효은: 안녕하세요, LLM플랫폼팀에서 eXemble의 AI 성능 개선과 기능 개발을 담당하고 있는 권효은이라고 합니다. Computer Vision으로 커리어를 시작해 OCR, 이미지 생성, 3D Reconstruction, 추천 시스템, VLM 등 다양한 도메인의 AI 개발을 경험해왔습니다. 이후 LLM 기반 서비스와 플랫폼을 더 깊이 있게 다뤄보고 싶어 엑셈에 합류하게 되었습니다.
여러 도메인을 거치면서 자연스럽게 개별 모델 성능 개선을 넘어, 서비스 전체 관점에서 AI 문제를 해결하는 방향으로 시야가 확장되었고, 지금은 특정 기술 자체보다는 ‘어떤 문제를 풀 것인가’에 더 집중하는 방식으로 일하고 있습니다.
허세진: 안녕하세요, LLM플랫폼팀 허세진입니다. 저는 엑셈에 백엔드 개발자로 입사해 XAIOps 모니터링 솔루션 개발로 커리어를 시작했고, 기능 구현을 넘어 제품 전반을 고민하는 역할로 자연스럽게 확장되면서 현재는 eXemble의 Product Owner를 맡고 있습니다. 개발자의 관점에서 벗어나 고객의 실제 문제를 해결하는 방향으로 넓어진 시야를 기반으로, 지금은 AI 기술을 단순 구현이 아닌 고객 가치로 연결하는 데 집중하고 있습니다.
Q. 두 분 모두 다양한 AI·개발 도메인을 경험해오셨는데요, 기존 경험이 지금의 LLM·AI 시스템 개발로 어떻게 확장되고 이어졌는지 궁금합니다.
권효은: 이전 직장에서 VLM 기반의 OCR의 여러 Downstream Task를 개발하면서 한 가지 한계를 자주 느꼈습니다. 인식 성능은 분명히 좋아졌지만, 결과를 일관되게 통제하거나 서비스 수준으로 안정화하는 일은 단일 모델만으로 해결하기 어렵다는 점이었습니다. 결국 문제는 ‘모델 성능’이 아니라 ‘서비스에서 일관되게 활용할 수 있는 구조’에 있었던 거죠.
한 프로젝트에서는 문서 이해 성능은 충분했는데도, 정작 이걸 활용하는 LLM 응답 품질이 뒷받침되지 않아 전체 서비스 가치가 저하되는 경험을 했었는데요. 이때 처음으로 ‘모델 하나가 아니라 시스템 전체를 봐야 한다’는 문제의식을 갖게 되었고, 자연스럽게 개별 Task를 넘어서 End-to-End 관점에서 문제를 바라보게 되었습니다. 때마침 학계에서도 문서를 ‘인식하고 변환하는 것’에서 ‘이해하고 활용하는 것’으로 패러다임이 이동하는 흐름이 뚜렷했습니다. 그런 변화 속에서 엑셈과 좋은 기회로 연결돼, 현재는 eXemble 개발에 참여하고 있습니다.
허세진: 저는 Java 백엔드 개발자로 시작해 현재는 LLM 플랫폼 개발까지 이어오고 있는데요. 표면적으로는 연산 환경이 CPU에서 GPU로, 메모리 구조도 시스템 메모리에서 HBM (High Bandwidth Memory) 중심으로 크게 변화한 듯 보이지만, 결국 데이터를 효율적으로 처리하고 비기능적 요구사항을 설계하는 작업의 본질은 기존 백엔드와 크게 다르지 않았습니다. 그래서 기존 경험이 아키텍처 설계에 직접적인 도움이 됐어요.
오히려 가장 큰 변화는 기술 스택 전환이었습니다. Java/Spring MVC라는 동기 환경에서 Python/FastAPI 기반의 비동기 환경으로 넘어오면서 런타임 에러 대응과 안정성 확보가 핵심 과제가 되었고, 팀원들과 함께 시행착오를 거치며 AI 도메인까지 빠르게 익혀갈 수 있었습니다.
2. 제한된 환경에서 완성된 LLM 플랫폼 설계 방식
Q. eXemble과 같은 LLMOps 플랫폼이 어떤 문제의식이나 필요에서 출발하게 되었나요?
권효은: 저는 이전까지 SI 형태의 프로젝트를 많이 해왔는데요, 하다 보니 유사한 요구사항임에도 프로젝트가 계속 파편화되고 재사용성이나 확장성이 어렵다는 한계를 자주 느꼈습니다. 고객사마다 커스터마이징이 반복되면서 코드 관리나 유지보수 복잡도가 빠르게 올라가는 게 특히 힘들었던 것 같아요.
하지만 LLM이 등장하면서, 모델 자체보다는 데이터 구성이나 워크플로우, 운영방식에서 서비스 차별화가 만들어질 수 있겠다는 생각이 들었습니다. 자연스럽게 “이걸 프로젝트 단위가 아니라 플랫폼으로 풀 수 없을까?”라는 고민으로 이어졌고, 그게 eXemble과 같은 LLMOps 플랫폼으로 확장하게 된 계기가 되었습니다.
허세진: LLM이 등장한 이후, 활용 여부에 따라 업무 생산성의 차이가 크게 벌어진다고 느꼈습니다. 다만 중요한 것은 단순히 사용하는 것이 아니라, 이를 안정적으로 운영하고 반복 가능하게 만드는 구조라고 생각합니다.
특히 금융·제조처럼 보안 요구사항이 높은 환경에서는 SaaS형 LLM을 활용하기 어렵고, 온프레미스 환경에서 직접 구축·운영하는 것도 쉽지 않은 한계가 있습니다. 기존 솔루션 역시 Agent나 LLMOps 기능이 분리되어 있거나 권한 제어가 부족한 경우가 많았고, 이러한 문제를 하나의 플랫폼에서 통합적으로 해결해보고자 한 것이 eXemble을 개발하게 된 계기가 되었습니다.
Q. 엑셈의 핵심 환경은 온프레미스인데요. 외부 클라우드 없이 폐쇄망에서 LLM을 운영하면서 가장 까다로운 점은 무엇이었나요?
권효은: 온프레미스 환경의 가장 큰 장점은 데이터가 외부로 나가지 않는 보안성과 안정성이라고 생각합니다. 다만 그만큼 최신 모델이나 기능을 빠르게 도입하기 어렵고, 인프라 리소스가 제한적이라는 한계도 분명히 존재합니다. 특히 API 기반 상용 모델과 비교했을 때 성능 부담이 있는 상황에서, GPU 자원까지 제한되다 보니 모델 선택과 아키텍처 설계 단계부터 현실적인 제약을 많이 고려해야 했습니다.
그래서 저희는 단순히 더 좋은 모델을 쓰기보다는, 주어진 환경 안에서 성능을 최대한 끌어올리는 방향에 집중하고 있습니다. RAG기반 최적화로 모델 성능을 보완하고, vLLM 서빙과 비동기 파이프라인 설계를 통해 처리 효율을 개선하고 있습니다. 이 외에도 리소스 효율화를 위해 양자화나 NPU 같은 다양한 하드웨어 옵션들도 검토하고 있으며, 여러 과정들을 거치면서 시스템 전체 관점에서의 최적화가 중요하다는 걸 많이 배우고 있습니다.
허세진: 온프레미스 환경에서 가장 큰 어려움은 리소스 제약, 특히 GPU에 대한 접근성이라고 생각합니다. 초기에는 LLM 기반으로 기능을 구현했지만, 실제 고객사 입장에서는 이를 운영할 만큼의 인프라를 갖추기 어려운 경우가 많았습니다.
그래서 GPU 의존도를 낮추고, sLM(Small Language Model)만으로도 충분한 결과를 낼 수 있는 구조를 만드는 데 집중하고 있습니다. 단순히 모델 성능을 높이기보다는, 고객 환경에서 안정적으로 동작하고 반복 가능한 결과를 만드는 것이 더 중요하다고 보기 때문인데요. 앞으로도 이러한 방향에서 경량화와 효율성 중심의 개선을 이어갈 생각입니다.
Q. eXemble처럼 비개발자도 쓸 수 있는 노코드 에이전트 빌더를 설계할 때 가장 많이 고민한 지점이 어디였나요?
권효은: eXemble을 설계하면서 가장 고민했던 부분은 사용성과 기술적 유연성을 어떻게 함께 가져갈 것인가였습니다. 현업 사용자를 고려해 학습 없이도 사용할 수 있는 직관적인 구조를 만드는 데 집중했고, Tool Calling이나 Sub-Agent 같은 개념도 사용자 관점에서 이해하기 쉽게 재구성했습니다.
동시에 B2B 환경 특성상 확장성과 유연성도 중요했기 때문에, 워크플로우를 DAG 기반으로 구성하고 메타데이터와 YAML 기반으로 관리해 설정 변경과 기능 확장이 가능하도록 설계했습니다. 개발 과정에서는 구조적 완성도와 속도 사이에서 트레이드오프가 자주 발생했는데요. 상황에 따라 유연하게 조정하며 균형을 맞추고 있습니다.
허세진: 온프레미스 솔루션 특성상 사용성이 뒤로 밀리기 쉬운 점을 가장 경계했습니다. 기능이 동작하는 것에 집중하다 보면 사용성은 이후에 개선되는 경우가 많은데, 이렇게 되면 구조가 복잡해진 뒤에야 문제를 인지하게 되는 한계가 있다고 생각했습니다.
그래서 이를 방지하기 위해 실제 고객 배포 이전에 사내에 eXemble을 먼저 공개해 피드백 루프를 구축했습니다. 그 과정에서 100건 이상의 피드백을 수집했고, 사용자 관점의 불편을 빠르게 확인해 구조적인 개선으로 이어갈 수 있었습니다. 또한 내부 PoC를 통해 팀원들이 직접 워크플로우를 만들어보고, 사용성 관련 피드백을 즉시 반영하는 과정을 반복하고 있습니다.
Q. RAG나 에이전트 시스템을 구축하면서 기존 방식으로는 해결되지 않았던 문제를 마주한 경험이 있으실까요? eXemble에서는 이를 어떻게 구현하고 있는지도 궁금해요.
권효은: 이 부분은 지금도 계속 고민하고 있는 영역인데요. RAG 시스템은 고객사 데이터 구조와 특성이 달라 단일한 방식으로는 안정적인 성능을 확보하기 어려웠습니다. 초기에는 Chunking, Embedding, Retrieval 같은 기본 전략을 적용했지만, 데이터에 따라 성능 편차가 크게 발생했고, 결국 ‘하나의 정답 전략은 없다’는 걸 체감했습니다.
그래서 현재는 RAG 파이프라인을 모듈화해 각 단계를 설정 기반으로 제어할 수 있도록 구현하고 있고, 특정 방식에 고정하기보다는 상황에 맞게 전략을 선택할 수 있는 구조로 개선해 나가고 있습니다. 결국 다양한 환경에서도 일관된 품질을 내는 게 중요하고, 실제로는 모델보다 데이터를 어떻게 전처리하고 구조화하느냐에 따라 결과가 더 크게 달라진다고 느끼고 있어요.
허세진: eXemble은 Agentic AI Builder 플랫폼인데, 초기에 가장 큰 문제는 워크플로우 품질을 정량적으로 평가할 기준이 없다는 점이었습니다. PoC 과정에서 할루시네이션이 발생할 때마다 프롬프트를 수정하고 테스트를 반복했지만, "이전보다 나아졌는지"를 객관적으로 판단하기가 어려웠습니다.
그래서 내부 백오피스에서 질문-답변 데이터셋을 구축하고, 워크플로우 변경 전후의 답변 품질을 비교할 수 있는 평가 체계를 만들었습니다. 이후 이 구조를 eXemble 기능으로 제품화해, 사용자도 플랫폼 내에서 결과를 직접 테스트하고 검증할 수 있도록 적용하고 있습니다. 이 과정에서 기존 워크플로우 엔진의 한계도 드러나 현재는 엔진 구조도 재설계하고 있습니다.
3. PoC와 문서로 쌓아가는 팀의 기술 선택과 개발 문화
Q. 주로 활용하시는 기술 스택이나 툴이 궁금해요. 보통 어떤 기준으로 선택하시나요?
권효은: 주로 Python 기반으로 개발하고 있고, 백엔드는 FastAPI, LLM 서빙은 vLLM을 중심으로 구성합니다. GPU 환경의 추론 최적화와 데이터 파이프라인까지 포함해 전체 시스템을 설계하고 있어요.
기술을 선택할 때는 성능, 확장성, 운영 안정성을 가장 중요하게 보고 있는데요. FastAPI는 Python 기반 AI 생태계와의 호환성과 비동기 처리 측면에서, vLLM은 KV cache와 batching 기반의 메모리 효율과 처리 성능 측면에서 장점이 있어 활용하고 있습니다.
데이터는 PostgreSQL과 Milvus를 역할별로 나눠서, 메타데이터와 트랜잭션은 PostgreSQL로, 임베딩 기반 검색은 Milvus로 처리하고 있습니다. 최근에는 양자화, 경량화 모델, NPU 등 다양한 최적화 방식과 함께 RAG Retrieval 전략과 워크플로우 개선도 지속적으로 진행하고 있습니다.
허세진: 저도 FastAPI와 vLLM을 중심으로 시스템을 구성하고 있고, exemONE을 활용해 애플리케이션, 호스트, 데이터베이스를 통합 모니터링하고 있습니다.
기술을 선택할 때는 “Keep It Simple”이라는 원칙을 가장 중요하게 보고 있는데요, 새로운 기술을 도입하기 전에 현재 구조 안에서 해결할 수 있는지를 먼저 검토하고, 불필요한 복잡도를 줄이는 데 집중하고 있습니다. 특히 온프레미스 환경에서는 아키텍처가 복잡해질수록 장애 대응 비용이 크게 증가하기 때문에, 기존 데이터베이스나 캐시로 해결 가능한지도 우선적으로 판단하고 있습니다. 또한 외부 기술 의존성은 언제든 변경될 수 있다는 전제 하에, 코드 레벨에서 레이어를 분리해 유연하게 대응할 수 있는 구조를 유지하고 있습니다.
Q. 팀 내에서 새로운 기술을 도입하거나 실험할 때 어떤 방식으로 진행되나요? 빠르게 변하는 AI 기술을 팔로업하는 나름의 방법이 있다면 함께 소개해주세요.
권효은: 제가 팀원분들께 자주 드리는 말은 “일단 문서로 정리해서 공유해 주세요”입니다. 새로운 기술이 필요하면 리서치부터 설계 방향, 도입 계획까지 문서로 정리하고, 이를 기반으로 비동기 피드백과 PoC 검증을 병행합니다. 이렇게 하면 적용 가능성을 빠르게 판단할 수 있고, 그 과정에서 나온 판단 기준이나 인사이트도 자연스럽게 공유됩니다.
의사결정도 문서 중심으로 진행해 불필요한 회의를 줄이고, 필요한 논의만 짧게 가져가는 방식을 선호합니다. 이런 방식으로 빠르게 실험하고 적용하면서도 팀의 방향성을 유지하고 있습니다.
개인적으로 기술을 팔로업할 때는 일상적으로 정보를 흡수할 수 있는 환경을 만들어두는 편인데요. SNS 알고리즘에 AI 관련 연구나 블로그 글이 뜨도록 설정해두고, 흥미로운 논문이 나오면 빠르게 읽어보며 프로덕트에 적용할 부분이 있는지 고민해보기도 합니다.
허세진: 저는 완벽한 설계보다 점진적인 개선을 통한 도입을 더 중요하게 보고 있습니다. 기존보다 나아질 수 있는 부분이 있다면 빠르게 적용하고, 운영하면서 고도화해 나가는 방식입니다. 예를 들어 eXemble 워크플로우 평가 기능도 처음부터 복잡한 구조를 도입하기보다는, BERTScore 기반의 자동 평가를 MVP로 먼저 적용한 뒤 점진적으로 확장해 왔습니다. 다만 핵심 인프라 변경은 ROI를 기준으로 신중하게 판단하고 있습니다.
기술 팔로업은 vLLM, LangChain 등의 릴리즈 노트를 중심으로 영향도를 검토하고 있고, 최근에는 vLLM 오픈소스 Meetup에 참석해 최신 동향을 파악하며 다른 엔지니어들과 운영 경험을 공유하기도 했습니다.
Q. AI 모델을 실서비스로 운영하며, 성능과 사용자 경험의 간극을 줄이기 위해 가장 중요하게 보시는 부분은 무엇인가요?
권효은: AI 엔지니어로서 모델 성능도 중요하지만, 결국 더 중요한 건 사용자가 체감하는 가치라고 생각합니다. LLM은 정량 지표가 개선돼도 체감이 달라지지 않는 경우가 많아, 데이터를 직접 보면서 간극의 원인을 파악하는 과정이 중요한데요.
정확도나 비용은 튜닝이나 경량화로 개선이 가능하지만, 답변 품질은 유저와 데이터에 따라 기준이 달라 일관되게 맞추기 어렵습니다. RLHF 같은 방법을 적용하더라도, 결국 데이터를 기반으로 문제를 정의하는 과정이 필요하다고 생각합니다.
또 정확도와 응답 속도는 트레이드오프 관계라, TTFT(Time To First Token)를 포함한 사용자 경험을 고려해 균형을 맞추고 있습니다. 실제로도 일부 성능을 감수하더라도 End-to-End 응답 속도를 우선한 구조를 선택한 경험도 있는데요, 결국 사용자가 실제로 어떻게 느끼는지까지 포함해서 설계하는 게 AI 서비스 운영에서 가장 중요한 부분이라고 생각합니다.
허세진: 현재 eXemble은 제품 초기 단계인 만큼 LLM 아웃풋의 정확성을 가장 우선으로 보고 있습니다. 다만 프롬프트 구성이나 RAG 파이프라인을 강화할수록 품질은 올라가지만 TTFT가 증가하는 트레이드오프가 있기 때문에, 고객사 유스케이스에 맞게 균형을 조정하는 것이 중요하다고 생각합니다.
이를 위해 프롬프트 구조화나 의도 분류 노드를 활용해 LLM 파이프라인을 최적화하고 있습니다. 앞으로는 TTFT, 동시 사용자 수 같은 인프라 지표와 함께, 응답 재생성 비율이나 답변 채택률 같은 사용자 행동 지표도 수집해 모델 성능과 UX 간의 간극을 데이터로 확인할 계획입니다.
Q. 각자 다른 배경을 가진 팀원들과 협업하시면서 기술적 의견이 충돌했을 때, 팀에서는 어떤 방식으로 의사결정을 하시나요?
권효은: 기본적으로는 해당 태스크를 가장 잘 이해하고 있는 담당자의 의견을 존중합니다. 다만 의견이 차이가 있는 경우에는 PoC나 간단한 테스트로 빠르게 검증하고, 데이터를 기준으로 방향을 정리하는 방식을 선호하고 있습니다.
팀원들이 진행 상황을 투명하게 공유하는 문화가 잘 형성되어 있어 큰 충돌은 많지 않고, 오히려 피드백을 빠르게 주고받으며 완성도를 높이고 있습니다. SSE 기반 채팅 기능 개발 당시에도 인터페이스를 함께 정리하며 방향을 맞춰갔고, 최근에 임베딩 성능 이슈 역시 실험 결과를 공유하면서 원인을 좁혀가고 있습니다.
허세진: 저희 팀은 몰입 시간을 존중하는 비동기 커뮤니케이션과 문서 기반 협업을 중심으로, 시도 과정과 의사결정 맥락을 기록으로 남기는 문화를 지향하고 있습니다. 실제로 의사결정은 문서로 공유하고 검토를 거친 뒤, 최종적으로 모두가 확인할 수 있도록 기록으로 정리해두는 방식으로 운영하고 있어요.
이런 협업 방식 덕분에 대부분의 이슈는 문서와 논의를 통해 자연스럽게 정리되는 편입니다. 다만 구조적인 판단이 필요한 설계 단계에서는 의견이 나뉘는 경우도 있는데요. 예를 들어 권한 체계를 설계할 때 저는 ‘팀’ 단위 그룹이 필요하다고 봤고, 디자인팀은 기존 조직 구조로 충분하다는 입장이었습니다. 이후 논의 끝에 고객 피드백을 기반으로 확장 여부를 판단하기로 하고, 우선은 조직 단위로 구현하는 방향으로 정리한 적이 있습니다.
이 과정에서도 서로의 의견을 충분히 공유하고 정리할 수 있었던 건, 각자의 관점을 편하게 드러낼 수 있는 심리적 안전감이 있는 환경이기 때문이라고 생각합니다.
4. eXemble의 다음 단계를 함께 만들어갈 AI Engineer에게
Q. 엑셈에서 '여기 오길 잘했다' 싶었던 순간과, 앞으로 넓혀 보고 싶은 기술·커리어 방향이 있을까요?
권효은: 입사 전에는 eXemble에 대해 깊이 알지 못한 상태라 걱정이 있었는데요, 막상 합류해 보니 서비스를 처음부터 함께 만들어가는 과정 자체가 빠르게 성장할 수 있는 좋은 기회라고 느껴졌습니다.
물론 초반에는 서비스에 대한 이해도가 충분하지 않은 상태에서 설계부터 개발까지 전반을 맡으면서 부담도 있었지만, 그 과정에서 시스템을 전체적으로 바라보는 시각을 키울 수 있었고 협업 방식이나 Git 기반 개발 문화도 팀의 도움을 받아 빠르게 적응할 수 있었습니다. 이후 모노레포 운영이나 LLM 서비스 구조 설계와 같은 밀도 있는 경험들을 통해 실무 역량까지 빠르게 채워갈 수 있었어요. 이런 경험들이 누적되면서 지금의 환경이 제 성장 방향과 잘 맞는다는 확신도 더 분명해졌습니다. 앞으로는 리서치 영역까지 확장해서 모델과 시스템을 함께 이해하고 설계할 수 있는 역량도 키워보고 싶습니다.
허세진: 저는 새로운 문제를 해결하는 과정 자체에 흥미가 있는 사람이라고 생각합니다. 엑셈에서는 계속해서 새로운 도전 과제를 마주하면서 그 해답을 찾아갈 수 있었고, 그 과정이 저에게는 꽤 큰 동기부여가 되었습니다.
AIOps 백엔드 개발자로 시작해 ML/DL과 모니터링 도메인을 익혔고, 이후 솔루션 엔지니어와 기획 경험을 거치면서 고객 문제를 기술로 해결하는 과정에 더 큰 관심을 가지게 되었습니다. 이 과정들을 돌아보니 저는 단순히 개발을 하는 것보다, 실제로 가치가 만들어지는 과정을 설계하고 완성해가는 일에 더 흥미가 있었던 것 같습니다.
앞으로도 PO로서 제품을 0에서 1로, 1에서 100으로 성장시키는 역할로 커리어를 지속적으로 확장해 나가고 싶습니다.
Q. 마지막으로, 지원을 고민하고 계신 분들께 한 말씀 부탁드립니다.
권효은: 불확실성 때문에 망설이고 있다면 한 번쯤 도전해보시길 권해드리고 싶어요. 저 역시 쉽지 않은 순간들이 많았지만, 결과적으로 도전해서 후회한 적은 거의 없었거든요.
엑셈에서 일하면서 느낀 건 단순히 주어진 업무를 수행하는 데서 끝나는 게 아니라, 문제를 정의하고 해결하는 전 과정을 직접 경험할 수 있다는 점이었어요. B2B 솔루션 특성상 상황이 빠르게 바뀌고 여러 팀과 협업할 일도 많은데, 이런 환경을 성장의 기회로 받아들일 수 있는 분이라면 더 잘 맞으실 거라 생각합니다.
무엇보다 서로에게 자극이 되는 환경 속에서 빠르게 성장하고 싶으신 분들이라면 주저하지 말고 도전해보시면 좋겠습니다.
허세진: 저희는 Claude, ChatGPT 같은 SaaS형 AI를 사용할 수 없는 내부망 환경에서 AX를 지원하는 솔루션을 만들고 있습니다. 그래서 고객사마다 인프라와 적용 도메인이 다르고, 요구사항도 다양하게 들어오는 편입니다.
저 역시 백엔드 개발자로 입사해서 LLM 서빙부터 RAG 파이프라인, 워크플로우 엔진 설계까지 빠르게 영역을 확장해야 했고, 잘 몰랐던 분야를 하나씩 익혀가며 실제 제품으로 만들어가는 과정 속에서 제품과 함께 성장하고 있다는 걸 많이 느꼈습니다.
그래서 처음 접하는 도메인이더라도 빠르게 학습하고, 실제 고객 문제를 해결해보는 과정을 즐기시는 분이라면 저희 팀에서 충분히 재미있게 일하실 수 있을 거라고 생각합니다.
📢 엑셈 LLM플랫폼팀에서 함께 성장할 AI Engineer를 찾습니다
동료가 된다면 이런 경험을 함께 할 수 있어요
- 온프레미스 환경에서 LLMOps · Agentic AI Builder 플랫폼을 0에서 1로 만들어갑니다.
- RAG · 에이전트 워크플로우 · sLM 경량화 등 폐쇄망 특화 AI 최적화를 직접 설계하고 운영합니다.
- vLLM · FastAPI 기반 AI 백엔드를 설계하고, 제한된 GPU 리소스 안에서 서빙 성능을 최적화합니다.
- 문서로 소통하고 데이터로 판단하는 비동기 엔지니어링 문화 속에서 함께 성장합니다.
함께 보면 좋은 아티클
