AWS 에는 특징 저장소([[[SW Environment](https://janghoo.notion.site/Environment-d73d08b95a824b3f957eb0134f8ced1f) MLOps](https://janghoo.notion.site/MLOps-1be9e881d5444f268fde8c1ea7e00f59) Feature Store](https://janghoo.notion.site/Feature-Store-15843dbb6be94c1d9cfffe6427cc64a6))서비스가 존재한다. 물론 EC2와 EFS, EBS, S3 등을 이용하여 직접 개발자의 입맛에 맞게 구현할 수도 있다. 이것은 어떤 추상화 수준을 선택할지의 문제이다. 완제품을 떼다가 판매할지, 직접 만들어 판매할지의 문제이다(from1).

대부분의 스타트업을 비롯해 수많은 회사들은 데이터 기반의 의사결정을 했을 때 어떤 효용이 있는지도 확신하지 못한다. 이를 판단하는 일을 feasibility 를 측정해보는 일이라고 한다(from2). 그런데 feasibility 도 검증되지 않는 상태에서 왜 이들을 가져다쓰지는 않고 직접 다 만들어내려고 하는가? 솔직히 멋지고 복잡한 시스템 다이어그램을 그려보고 싶은 것은 아닌지, 커리어에 쓸 스토리를 만들고 있는 것은 아닌지 잘 생각해 보자.

이런 것을 ‘멋있다’ 라고 생각하는 것은 아닐지 (source: Uber Michelangelo).

Feasibility 를 가늠할 필요가 있는 회사에서 ‘시스템을 밑바닥부터 직접 다 만들어야 함’ 혹은, ‘완성품을 사용하는 것은 무조건 비싸고 부실함’ 을 주장하는 것은 순전히 자신의 커리어만 생각한 이기적인 의사결정이다(from3,5). MLOps 의 메인 목표는 이미 존재하는 솔루션들로 비즈니스 이익을 극대화할 수 있도록 돕는 것이다. 클라우드가 덜 제공하는 기능을 다시 만들거나 잘 연결하는 일이 메인이 아니다(참고1).

source: UC Berkeley Full Stack Deep Learning Course, Lecture 8, Data Management

KEEP IT SIMPLE

디자인 씽킹(from4)에서 정의된 문제(DEFINE)는 비즈니스의 이익 극대화이다. 아이디어(IDEATE)는 MLOps 인 상황이다. 그럼 당연히 아이디어가 문제의 핵심을 관통할 수 있는지 프로토타이핑(PROTOTYPE)을 먼저 해야 한다. 프로토타이핑의 핵심은 최소주의이다.

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.

1. responsible ai principle 01. heuristic benchmark : 휴리스틱 벤치마크를 넘어 모델의 성능 향상을 모델의 비즈니스 효용가치로 변환해야 한다. … 연매출 환산시 실제로 얼마의 가치가 있는 것인지를 계산해 보아야 한다. 이를 모델 효용 가치 지표라고 한다. → sup 로 붙이기. 이걸 해야 한다.

from : 과거의 어떤 생각이 이 생각을 만들었는가?

1. ‣
2. ‣
3. ‣
4. deer.b2.2.1.4.1.1. title: 디자인씽킹(design thinking), 특히 정의(define)단계에는 문제를 정의하는 일과 목표를 수립하는 일 모두가 포함되어 있어 문제를 정의하는 일을 간과하기 쉽다.
5. 2_1_3_2_4.1. title: 창업팀이 최고의 시너지를 내기 위해서는 서로의 창업 동기와 비전에 대해서 솔직해져야 한다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?

1. ‣