Skip to content

Latest

천천히 올바르게. AI Researcher & DevOps Engineer Youngju's tech blog. GPU/CUDA, LLM, MLOps, Kubernetes AI workloads, distributed training, and data engineering.

어학학습48편 표시 중
일반NEW

고객의 도메인을 모델로 — 유비쿼터스 언어에서 온톨로지까지

고객사의 도메인 지식은 대개 문서가 아니라 사람 머릿속에 암묵지로 있습니다. Forward Deployed Engineer의 핵심 작업 하나는 이 흩어진 암묵지를 팀이 공유하는 명시적 모델로 바꾸는 것입니다. 이 글은 가장 싸고 값진 첫걸음인 DDD의 유비쿼터스 언어에서 출발해, 바운디드 컨텍스트로 같은 단어의 충돌을 다루고, 엔티티·값 객체·애그리게이트로 명사를 모델링합니다. 그다음 사람들이 자주 뒤섞는 세 단어 — 택소노미, 온톨로지, 지식 그래프 — 를 구분하고, 형식 스택(RDF/RDFS/OWL과 schema.org)과 운영 스택(프로퍼티 그래프와 Palantir Foundry의 객체·링크·액션)을 나란히 놓습니다. 마지막으로 정직하게 말합니다. 온톨로지는 과설계되기 가장 쉬운 산출물이고, 가장 흔한 실패는 아름답지만 아무도 안 쓰는 온톨로지라는 것. 그래서 개념이 아니라 비즈니스가 실제로 던지는 질문에서 시작해야 한다는 것.

일반NEW

Forward Deployed Engineer의 크래프트 — 요구사항 발굴, 도메인 모델링, 그리고 채택을 향한 최적화

앞선 글은 FDE에게 필요한 지식 지도 — 리눅스·네트워크·쿠버네티스·DB·보안 — 를 정리했습니다. 그 지도는 문을 열어 줄 뿐, 고객사 건물 안에 들어간 뒤 실제로 무엇을 하는지는 말해 주지 않습니다. 이 글은 그 "동사"에 관한 것입니다. Palantir이 직접 쓴 Delta·Deployment Strategist 역할 문서, The Pragmatic Engineer의 취재, 그리고 현재 열려 있는 Anthropic·OpenAI FDE 공고를 근거로, 이 일의 대부분을 이루는 여섯 가지 움직임을 다룹니다 — 요구사항 발굴(요청한 것 vs 진짜 필요한 것), 고객의 도메인을 양쪽이 함께 가리킬 수 있는 공유 모델로 만들기, 지저분하고 에어갭이며 레거시인 환경에 통합하기, 피드백 도구로서의 데모, 언제 아니오라고 말하고 과잉 설계를 피할지, 그리고 유일하게 중요한 점수 — 짠 코드의 양이 아니라 채택. 마지막으로 가장 어려운 부분을 정직하게 적었습니다 — 남의 건물에서, 남의 일정에 맞춰, 다리(bridge)로 서 있는 일.