[일일리포트] Day 19 (ProjectLifeCycle)

해당 일일리포트에서는 네이버 커넥트에서 진행하는 '부스트캠프 AI Tech 3기'에서 배운 내용을 다루고 있습니다. 저작권 이슈 때문에 관련 자료를 올릴 수는 없기에 핵심 이론과 코드를 요약해서 올리고 있기에 내용이 부족할 수 있습니다.

▶ Today I Learned (핵심 요약 정리)

AI Service Basic

이번 주는 AI서비스에 관해서 필요한 기초적인 부분들에 대해 다루게 되는 것 같다. 머신러닝 프로젝트 라이프 사이클이나, 리눅스와 쉘 커맨드, 가상화 기술인 도커, 머신러닝 실험 및 배포 도구인 MLflow의 기본적인 개념에 대한 강의가 준비되어 있었다.

따라서 이번 주는 해당 강의 등을 정리할 예정인데, 각 강의의 분량이 많은 관계로 2일 간 나눠서 정리를 할 계획이다. 우선 오늘은 ML Life Cycle과 리눅스 Shell Command에 대해 정리해 볼 계획이다. 언제나처럼 배보다 배꼽이 더 커지지 않게 복습하면서, 중요한 개념들 위주로 정리해야겠다.

Machine Learning Project Life Cycle

문제 정의

앞으로 겪게 될 일은 대부분 문제(Problem)로 정의할 수 있다. 문제를 잘 풀기 위해선 문제 정의가 매우 중요하다. 풀고자 하는 문제가 명확하지 않으면 그 이후 무엇을 해야할 지 결정하기 어려워진다. 예를들어 '저는 AI를 통해 사람들을 행복하게 만들고 싶어요'라고 할 때 다양한 질문이 나올 수 있다. '어떤 사람들? 행복의 정의는? 돈? 복지? 장애 격차 해소?'

따라서 문제를 충분히 정의하고 고민하는 습관을 만드는 것이 중요하다. How보다 Why에 집중을 해야 한다.

본질을 파악하는 과정이다. 해결해야 하는 문제는 무엇이고, 어떻게 해결할 것인지를 생각

문제 해결을 위한 Flow

• 현상파악
• 목적, 문제 정의
• 프로젝트 설계
• Action
• 추가 원인 분석

1.현상파악

어떤 현상이 발생되었다면, 어떤 일에서 발생한 것인지? 해당 일에서 어려움은 무엇인가? 해결하면 좋은 게 무엇인지? 추가적으로 해볼 수 있는 것은 무엇일지? 어떤 가설을 만들 수 있을지를 생각한다. 

2.구체적인 문제 정의

앞선 현상을 더 구체적으로 명확한 용어로 정리해본다.

• 무엇을 해결하고 싶고, 또 무엇을 알고 싶은지를 정의 (문제 상황, 원인)
• 어떻게 문제를 해결할 수 있을지를 생각해보기 (해결방안). 문제 상황을 "한 단어로 정리해봐도 좋다", 문제를 일으키는 원인과 해결방안을 고민하기
• 문제의 해결 방식은 다양하기 때문에 데이터로 해결할 수 있는 방법을 고민해보기. 문제를 쪼개서 파악해보고, 점진적으로 실행하기

이때, 무조건 AI가 옳다가 아니라, 기존 문제를 분석하고 해결책을 생각하면서 AI가 사용될 수 있는 방안을 고려

3.프로젝트 설계

프로젝트 과정(현실)

1. 문제정의
2. 최적화할 Metric선택
3. 데이터 수집, 레이블 확인
4. 모델 개발
5. 모델 예측 결과를 토대로 Error Analysis. 잘못된 라벨이 왜 생기는 지를 확인
6. 다시 모델학습, 더 데이터 수집, 다시 또 모델 학습 ... 그러다 갑자기 성능이 안 좋아지면 다시 학습
7. 최적화할 Metric이 실제로 잘 동작하지 않아 Metric수정 시 다시 시작 ...

문제 정의 후, 프로젝트 설계를 자세히 하는 것이 중요하다. 보통은 다음과 같은 프로세스로 진행하면 좋다고 한다..

• 해결하려고 하는 문제 구체화
• 머신러닝 문제 타당성 확인
• 목표 설정, 지표 결정
• 제약조건
• 베이스 라인, 프로토타입 개발
• 평가(Evalutation) 방법 설계

머신러닝 문제를 고려할 때는 제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려해야 함

• 머신러닝 문제는 결국 데이터로부터 어떤 함수를 학습하는 것이기 때문에, 머신러닝 문제 타당성을 평가해보고 필요한 데이터의 종류와 기존 모델이 있는지 등을 살펴 복잡도를 평가해봐야 한다. 

머신러닝은 모든 문제를 해결할 수 있는 마법의 도구가 아니라는 생각을 가지고 유연한 사고를 가져야 한다.

머신러닝이 사용되면 좋은 경우

• 패턴: 학습할 수 있는 패턴이 있는지를 확인한다. 생성되는 방식에 패턴이 없다면 학습할 수가 없다. 
• 목적 함수: 학습을 위한 목적 함수를 만들 수 있어야 한다.
• 복잡성: 패턴이 복잡해야 한다. 예를 들어 집 가격을 예측할 경우 복잡한 패턴이 필요할 수가 있다.
• 데이터 존재 여부: 데이터가 존재하거나 수집할 수 있어야 한다. 데이터가 없다면 데이터 수집 계획부터 수립
• 반복 발생: 사람이 반복적으로 작업을 실행하는 경우. 작업이 반복된다는 의미는 패턴이 있다는 것이기 때문에 사람의 노동력을 줄일 수 있는 관점에서 머신러닝을 사용할 수 있다.

머신러닝이 사용되면 좋지 않은 경우

• 비윤리적인 문제 (별도의 조건이 필요)
• 간단히 해결할 수 있는 문제
• 좋은 데이터를 얻기 어려운 경우
• 한 번의 예측 오류가 치명적인 결과를 발생할 경우
• 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
• 비용이 효율적이지 않은 경우 (시간, 인력, 머신)

목표설정, 지표 결정

• 프로젝트의 목표: GOAL(큰 목적), Objective(목적을 달성하기 위한 세부 단계 목표)
• 지표결정: 데이터의 Label은 지표와 연결되는 내용이기 때문에 중요하다.
• 최적화하고 싶은 목적 함수가 여러가지 있는 경우, 서로 충돌할 수 있다.
  • Objective가 여러 개인 경우 분리하는 것이 중요하다. 모델을 계속 재학습하지 않도록 모델을 분리해야 한다.

제약조건(Constraint & Risk)

• 일정: 프로젝트에 사용할 수 있는 시간
• 예산: 사용할 수 있는 최대 예산
• 사람: 이 프로젝트로 인해 영향을 받는 사람
• Privacy: Strage, 외부 솔루션, Cloud 서비스 등에 대한 개인정보 보호
• 기술적 제약
• 윤리적 이슈
• 성능: Baseline, Threshold, Performance Trade-off, 해석 가능 여부, Confidence Measurement
  • Baseline: 모델이 더 좋아졌다고 판단할 수 있는 Baseline이 필요하다. 자신이 모델이라 생각하고 어떻게 분류할지 Rule Base규칙을 설계한다.
  • 간단한 모델부터 시작하는 이유는 모델의 위험을 낮추는 것이 목표가 되어야 한다.
  • 유사한 문제를 해결하고 있는 SOTA 논문을 파악해보기

베이스라인, 프로토 타입

• 베이스라인 이후에 간단한 모델을 만들면 피드백을 들어보면 좋다.
• 프로토 타입을 만드는 프레임워크로는 Voila, Streamlit, gradio 등이 있다.

Metric Evaluation

 앞선 문제를 해결할 경우 어떤 지표가 좋아질까를 고민해야 한다. 모델의 성능지표(RMSE)일 수도 있고, 비즈니스의 지표(매출)가 될 수도 있다. 지표를 잘 정의해야 우리가 수행한 Action이 기존보다 더 성과를 냈는지 아닌지를 파악할 수 있다(이를 위해 AB Test를 진행하기도 한다). 결국 만든 모델이 비즈니스에 어떤 임팩트를 미쳤을지에 대해 생각해봐야 한다. 머신러닝 프로젝트는 궁극적으로 수익을 높이는 것이 목표가 되어야 하기 때문이다. 

• 전환율 증대(매출 증대), 반복업무 자동화(내부 직원 리소스 효율로 인한 비용 절감), 고객 만족도 창출, 사이트 체류 시간 증가 등

4.Action

모델 개발 후 배포 & 모니터링을 통해 앞서 정의한 지표가 어떻게 변하는지 파악해야 한다. '현재 모델이 어떤 결과를 내는지?', '잘못 예측하고 있다면 왜 그런지? 어떤 기준으로 예측하고 있는지?' 와 같은 에러를 분석해봐야 한다.

5.추가 원인 분석

새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할지 모색해야 한다. 그 과정에서 앞서 진행한 과정들을 반복하게 된다.

비즈니스 모델

회사에서 중요한 것은 비즈니스이기 때문에, 비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 가능성이 존재한다. 비즈니스를 이해하려면 제일 처음 '우리가 뭐로 돈을 버는지?'에 대해 생각해봐야 한다. 

 

1) 회사의 비즈니스 파악하기: 회사가 어떤 서비스, 가치를 제공하고 있는가?
2) 데이터를 활용할수 있는 부분은 어디인가?

• 데이터가 존재한다면 어떤 데이터?
• 데이터로 무엇을 할 수 있을까?
• 데이터는 신뢰할만한가? 데이터 정합성은 맞는가? 레이블이 잘 되어 있는가?
• 다양한 팀 분들과 직접 인터뷰하는 것도 좋은 방법
• 무엇을 해볼 수 있고, 왜 해야 하는가?

3) 모델을 활용한다고 하면 예측의 결과가 어떻게 활용될 수 있는가?

• 더 좋은 가치를 제공하고 매출을 증대할 수 있는가
• 내부 인원이 수동으로 진행해야 하는 업무를 자동화할 수 있는가 등

Linux & Shell Command

 개발자들은 파이썬, 자바, C등 어떤 언어를 사용하든 Linux를 마주치게 될 수밖에 없고 그만큼 많이 사용하게 된다고 한다. 왜냐하면 오픈소스이며, 서버에서 자주 사용하는 OS이기도 하고, 안전성과 신뢰성을 갖추고 있기 때문이다. 

• 터미널/콘솔: 쉘을 실행하기 위해 문자 입력을 받아 컴퓨터에 전달하고 프로그램의 출력을 화면에 작성한다.
• Shell: 사용자가 문자를 입력해 컴퓨터에 명령할 수 있도록 하는 프로그램이다. 다음은 Shell을 사용하는 경우이다.
  
  • 서버에서 접속해서 사용하는 경우
  • crontab 등 Linux의 내장 기능을 활용
  • 데이터 전처리를 위해
  • Docker를 사용하는 경우 (Docker의 OS는 Linux)
  • 수백대의 서버를 관리할 경우
  • Jupyter notebook의 Cell 앞에 !를 붙이면 쉘 커멘드가 사용됨
  • 배포 파이프라인 실행할 때

해당 강의 내용 중 Shell 명령어와 Vi 명령어에 관한 부분은 다른 포스팅(Linux Shell & Vi Editor Command)에서 별도로 정리했습니다.

▶ Review (생각)

 이번 주 강의의 경우 엔지니어로서 어떤 마음가짐을 가져야하는지에 대한 생각을 많이하게 해주는 것 같다. 강의의 구성도 그렇고, 제일 첫 강의에서부터 마음가짐이나 생각과 관련한 사항들에 대해서 말씀을 해주셨다. 'AI 엔지니어가 되기 위해서는 큰 그림을 인지하고, 능동적인 자세와 지속적으로 개선하려는 의지를 가져야 한다', '프로토타이핑부터 모델 배포, 모니터링 과정을 이해하는 사람이 될 수 있게 기술을 이해해야 한다', 'AI엔지니어의 기본 소양은 문제 정의에 대한 고민을 하는 사람이기 때문에 Why를 습관적으로 물어보며 답을 하나씩 찾아가야한다'와 같은 부스트캠프에서 공부를 하면서 어떠한 마음가짐으로 공부를 해야할 지에 대해서 생각해볼 수 있는 기회가 된 것 같다.

 오늘로 해서 이번 주 특강을 제외한 강의는 다 들었지만, 양이 꽤나 방대해서 오늘은 ML Project Life Cycle과 Linux에 대해서만 정리했다. 이번 주 강의들은 늘 배워두면 좋겠는데 라는 생각은 있었지만, 시도해보지 못했거나 간략하게 알고 있던 부분들이 많아 흥미롭게 들을 수 있었다. 남은 특강들의 주제도 AI엔지니어로서 현업에서 어떤 일을 겪게 되고, 어떤 마음가짐을 가지고 어떻게 준비해야 하는지에 대한 내용을 담고 있어서 또 기대가 된다.

 내일은 블로그 정리를 하면서 앞서 배운 강의들을 다시 한 번 정리하고, 특강들을 들어봐야겠다. 

Generalist, Specialist의 구분보다는 꾸준함이 더 중요하다