Grace's Tech Blog

[MLOps] 1. Motivation for MLOps

HJChung — Tue, 9 Apr 2024 18:16:19 +0900

link: https://ml-ops.org/content/motivation

Why you Might Want to use Machine Learning. 왜 ML을 적용하고 싶은가?

Statista Digital Economy Compass 2019,에 따르면 최근 트렌드는

Data driven 세상. 엄청난 기하급수적으로 증가하는 데이터가 모이는 세상인 것과
이렇게 모여진 데이터에서 insight를 찾아내는 rtificial Intelligence / Machine Learning / Data Science 가 증가한다는 것.

모든 ML pipeline은 model을 만드는데 필요한 모든 연산들의 set이다.

요약: 그래서 대체 MLOps가 뭔데? MLOps, as a DevOps extension, establishes effective practices and processes around designing, building, and deploying ML models into production.

어디에 필요한가?

ML model 학습 측면

ML개발의 어려운 점을 알고, 이를 해결해주는것이 MLOps의 엔지니어링이다.

→ 그럼 ML개발의 어려운 점이 뭔지를 알아야 한다.

ML model 성능 측정측면

ML model을 input data가 주어졌을 때 어떤 output(이 output에는 classification, sentiment, recommendation, or clusters 이런 것들이 있고, 실제로 우리 회사에서도 classification, sentiment, recommendation, or clusters (중에 어떤 모델이 있는지 한 번 더 확인하기) 모델이 있고, 나는 이 모델을 서빙해 본 경험이 있다.) 을 내는 거라고 생각하면, 각 모델의 성능은 1) 정확도precision 2) recall 3) accuracy 로 평가할 수 있다.

—> 1. 우리 연구팀에서는 성능 평가를 어떻게 하는지 여쭤보기.

—> 2. 이걸로 모델 성능 측정을 자동화 할 수 있을까? 그러기 위해서는 1) 지금 우리 회사에서는 모델 성능 측정을 어떻게 하고 있으며 2) 만약 메뉴얼 하게 하고 있다면, 자동화 할 수 있는 부분이 있고, 이걸 내가 할 수 있는가? 를 확인해야함.

ML model 서빙 측면

학습된 모델을 제품화 한다는 것은 모델을 software system에서 사용 가능하도록 엔지니어링 한다는 것이다. 즉, ML model의 배포라고 할 수 있다. 이 단계를 보면,

어떤 모델 종류가 있고, 그 모델들이 어떻게 제품과 될 수 있는지를 보면,

Recommendation, which identifies the relevant product in a large collection based on the product description or user’s previous interactions.
Top-K Items Selection, which organizes a set of items in a particular order that is suitable for user (e.g. search result).
Classification, which assigns the input examples to one of the previously defined classes (e.g “spam”/”not spam”).
Prediction, which assigns some most probable value to an entity of interest, such as stock value.
Content Generation, to produce new content by learning from existing examples, such as finishing a Bach chorale cantata by learning from his former compositions.
Question Answering, which answers an explicit question for example: “Does this text describe this image?”
Automation, which can be a set of user steps performed automatically, such as stock trading
Fraud and Anomaly Detection, to identify an action or transaction being a fraud or suspicious
Information Extraction and Annotation, to identify important information in a text, such as people’s names, job descriptions, companies, and locations.

이런 것들이 있다.

하지만 ML model의 배포를 하고 나서의 어려움은,, 대표적으로

‘ 모델을 학습해서 생성할 때와 배포 한 후의 성능 차이가 있고, 이를 매우는 것이 어렵기 때문이다. (Because bridging the gap between ML model building and practical deployments is still a challenging task.) '.

그래서

위에서 1) ML model 학습, 2) ML model 성능 측정, 3) ML model 배포와 그 후 에서의 burden 에 대해서 알아보았다.

그럼 이 각각의 측면에서 어떻게 해결해 줄 수 있는 방법이 있을까 생각해보기 전에 ML Based Application(AI 기능이 탑재된 서비스)의 개발은 어떤 것들고 구성되어 있는지를 보고, 그 중 구멍을 매꾸는 방법이 있을까로 치환, 문제와 연관해서 생각해보면 어떤가?

The complete development pipeline includes three levels of change: Data, ML Model, and Code.

After deploying the ML model into a software system, we might recognize that as time goes by, the model starts to decay and to behave abnormally, so we would need new data to re-train our ML model.
After examining the available data, we might recognize that it’s difficult to get the data needed to solve the problem we previously defined, so we would need to re-formulate the problem.
In the ML project at some stages, we might go back in the process and either collect more data, or collect different data and re-label training data. This should trigger the re-training of the ML Model.
After serving the model to the end-users, we might recognize that the assumptions we made for training the model are wrong, so we have to change our model.
Sometimes the business objective might change while project development and we decide to change the machine learning algorithm to train the model.

https://libertegrace.tistory.com/entry/Lecture-머신러닝-엔지니어-실무-ML-Pipeline-이해 여기에 나온 어려움들이 고대로 있다.

지금까지

현재 왜 ML이 중요해지고 있는지 를 매우 간략하게 알아보았고,
근데 ML model을 학습(개발) 하고 제품화 하는데 어려움은 뭔지 를 알아보았다.

이제 MLOps가 뭔지 정의를 내려보자.

The term MLOps is defined as “the extension of the DevOps methodology to include Machine Learning and Data Science assets as first-class citizens within the DevOps ecology” Source: MLOps SIG.

MLOps라는 용어는 "머신 러닝 및 데이터 과학 자산을 DevOps 생태계의 일급 시민으로 포함하기 위한 DevOps 방법론의 확장"으로 정의됩니다. 출처: MLOps SIG.

MLOps, like DevOps, emerges from the understanding that separating the ML model development from the process that delivers it — ML operations — lowers quality, transparency, and agility of the whole intelligent software.

[Agile] Scrum vs Kanban. 우리 팀에 더 적합한 방식은?

HJChung — Thu, 4 Apr 2024 09:38:47 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

Scrum

Scrum이란?

Iteraton기반의 Project 관리 Framework

Scrum의 가치

courage: cross team이 되어 그 팀 안에서 어떤 것을 완수하는 것을 지향하기 때문에 assign된 채로가 아니라 open에서 자율적으로 자신을 assign 해서 진행하는 것을 지향함. 이렇게 하는 용기. 등.. 많은 용기가 필요함 방식임.
focus: sprint 기간에 어떤 것에 집중함으로서 생산성 향상에 직결되고
commitment: 팀이 ‘이것 만큼은 완수하겠다’ 라는 약속
respect: 과정과 결과에 대해서 회고하고 이를 통해서 앞으로 우리가 나아가야할 방향을 조정하는 것을 추구함
openness: 우리가 하고 있는 모든 일들에 대해서 현재 지금 어떤 상태인지, 어떤 risk를 가지고 있는지를 투명하게 오픈하는 것.

Scrum 적용시 고려사항

Doing scrum 시 고려해야 할 것은

scrum 환경을 만드는데 적절한가. 적절하지 않으면 도입해도 괜찮은 시점인가? 그 시점이라면 환경 구축에 힘 쏟기!
Definition of Done 정의하기
sprint 주기 찾기
적정한 story point 찾기
velocity(이번 sprint에 완료된 업무의 총합) 을 추적하고 측정하는 것

Being scrum 시에 고려해야 할 것은

팀을 보호한다는 것의 의미, 어떻게 고객과 팀과 stackholder들과 원만한 관계를 유지하면서 우리 팀을 보호할 것인가? (우리 팀에서는 CAO님이 많이 걱정하고 신경써주시고 있는 이 부분.)
고객과의 협력이 의미하는게 뭔지 생각해보기
1. 누가 고객인가?
2. 의료 B2B인 우리 회사, 우린 고객을 만나기가 어려운데?
주변과의 신뢰를 어떻게 만들 것인가
우리의 우선순위는 존중받고 있는가
팀멤버의 피로도 관리

Scrum의 전체적인 프로세스

sprint(단거리 질주)를 도입해서 sprint로 iteration을 돌리는데
- sprint는 30일 이내
- sprint 기간에 어떤 것에 집중함으로서 생산성 향상에 직결되고
- sprint 보호도 중요하지만 긴급한 대응을 외면하지는 않음

Scrum시 필요한 역할

Product Owner: 팀이 만들어내야 하는 Product의 요구사항을 관리하는 사람
1. Product Vision제시
2. Product Backlogs 들 중에서 우선순위 설정
3. 릴리즈 일자 결정
4. 팀이 가치있는 일을 할 수 있도록 함
Scrum Master
1. 팀을 위해 일하는 Servant 리더
2. ‘이건 이렇게 하는게 좋겠다. 저건 저렇게 하는게 좋겠다’ 식의 가이드를 줘서 팀의 방해 요소를 팀원들이 해결할 수 있도록 도움을 주는 사람
Scrum Team
1. self organizing
2. cross functional

Scrum Event

(단거리 질주 시작 전) Sprint Planning meeting
1. Product Owner가 최신의 우선순위가 반영된 product backlog들을 scrum team에게 이해시키고, 전달한다.
2. Product backlog들은 소비자의 언어로 명시되어있는데, 이걸 구현의 언어로 전환한다.
  1. 그래서 scrum team을 이루는 cross functional 멤버(기획자, 개발자, 디자이너.. 등)은 모여서 아 백로그를 처리하려면 이런 작업이 필요하겠네, 저런 작업이 필요하겠네.. 등을 정리하고, task로 바꾸고, 일정 예측하는 시간.
→ 이 1, 2 과정을 통해 이번 sprint기간 동안 할 일인 task들을 확정을 하고, 팅이 확정한 task 목록의 업무는 반드시 완료하겠다는 commitment(다짐)을 한다. → 이걸로 ready to run & tension up!!!
(단거리 질주 중간 중간 매일) Daily scrum meeting
1. Quick Review
  1. 이전 Daily scrum meeting 이후로 진행된 일
  2. 이후 Daily scrum meeting 이후로 진행 할 일
  3. 내가 이 일들을 진행하는데 발생한 혹은 예상 가능한 blocker 공유
2. 팀의 업무 진행 현황을 매일 sync-up
Sprint review meeting
1. 내가 요구한 요구 사항이 잘 구현이 되었는지를 확인하는 과정임. 이게 ‘너 개발 잘했네 못했네’ 등의 개인의 능력치를 공개적으로 평가하는 자리가 아니라. PO가 요구한 요구사항과 실제 구현된 것이 일치하는지 그런 것들을 확인하고, 유연하고 빠른 요구사항 반영을 위한 장치이다.
2. 요구사항을 더 정확하고 세밀하게 만드는 장치
3. 중요한 것에 더 집중하게 만들 수도 있다.
sprint retrospective meeting
1. sprint과정 평가 및 개선점 도출
2. 지속적인 발전과 개선을 촉진할 수 있는 장치
3. sprint 기간 종료와 tension release

Kanban

Kanban이란?

Kan(visiual) Ban (card or board).

(이전 글에서 계속 Scrum에서 해야 할 것으로 Sprint 를 말했던 것처럼 Kanban에서도 Doing kanban을 위해 해야할게 있다면)

Kanban의 가치

Just in Time (JIT): 요구사항을 바로바로 반영하고, 그때마다 우선순위도 바로바로 바뀌고..Visualize what you do today.
Limit the work in process (WIP): 컨테이너 벨트를 생각해보면 어느 흐름에서 병목이 생기면 다른 일들은 다 막혀있을 수 밖에 없기 때문에 ‘할 수 있는 만큼만 가져가’야 한다는 것.
Manage flow: 계속 workflow는 모니터링해서 LEAD time을 줄이기 위해 개선하고, 튜닝해야 한다.

Kanban의 프로세스

그리고 이 때 task는 push방식이 아니라 pull 방식이다.

여기서 Scrum과 Kanban의 차이!

Scrum에서는 Product Backlog에서 팀이 이번 sprint에 할 수 있는 만큼 할당해서 진행하는데
Kanban은 항상 최신 우선순위에 따라서 중요한 것을 Selected column에 넣고 진행함. 그래서 바뀌는 우선순위에 just in time으로 대응할 수 있게 함.

Kanban의 장점

더 짧은 주기로 feature을 더 빠르게 제공할 수 있음. ↔ Scrum은 sprint기간에 의해서 WIP limit이 통제가 되는데, Kanban은 그냥 들어오는 순서대로 우선순위 높은것순서대로 계속 달리는 말 같기 때문.
우선순위가 아주 자주 바뀐다면, Kanban이 이상적.
WIP limit과 workflow 의 LEAD time에 대한 데이터가 쌓이면 어느정도 팀의 처리 속도를 예측 할 수 있음 (내가 이런 일을 줬더니 LEAD TIme이 이정도 걸리는 구나. 그럼 다음에도 이정도 규모의 일은 이정도 걸리겠구나)

Kanban 적용시 고려사항

팀의 workflow를 정의해야한다. (우리는 어떤 workflow로 일을 처리해야 효율적일지.. 등)
WIP limit의 초기값을 어떻게 정할 것인지. (initial n-1,2 items per person…)
item 간에 유사한 크기로 분할해야하는데, 이 크기를 어떻게 잡을 것일지
회고 를 통해 Manage flow

Being Kanban에 대해 고려사항

생산라인인가 개발팀인가 라는 불만
Scrum 처럼 Role이 분명하지 않은데 ‘누군가가’ Lead Time, WIP 모니터링, .. 등을 일을 해 줘야함.

Scrum vs Kanban. 우리 팀에 더 적합한 방식은?

[MSA, Monorepo] 사내 모노레포 도입기에 대해서 글을 썼다.

HJChung — Fri, 8 Mar 2024 02:44:21 +0900

회사에서 모노레포를 도입한 과정에 대해서 사내 블로그에 글을 썼다.

여기 그 링크를 첨부한다.

#9. 저는 모노레포구요. 개발 효율이 추구미에요.

안녕하세요 DeepBio에서 Backend 개발을 담당하고 있는 정현정입니다.

medium.com

[Agile] 업무 가시화 방법

HJChung — Mon, 12 Feb 2024 15:12:00 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

업무 가시화가 필요한 이유

일을 하다보면 이런 질문을 진짜 많이 하고, 받게 된다.

나 역시 그렇다.

업무 진행 상황이 어떤가요?
로드맵은 어떻게 되나요?
여러 요구사항 중 가장 급한 것은 무엇인가요?
해당 기능은 언제 릴리즈 된다구요?

이런 질문에 대한 답, 정보들을

1) 시각화 해서 필요한 사람들이 이 자료를 활용할 수 있게 하는 것

2) 그래서 모두가 Same page에 있게되어, 누가 이걸 하고 있는지, 내가 이걸 하는데 누구에게 도움을 요청하면 되는지 알 수 있다. (협업 효율화)

3) 현재 어떤 문제가 있는지를 가시화해서 현재 상태에 대한 빠른 파악 그리고 해결 방법, 해결 후 예측

이 가능하기 위해서 업무 가시화가 필요하다.

가시화가 되어야 하는 요소

우선순위 설정

요즘 내가 가장 많이 Top manager분들께 드리고 있는 질문이며,
그 분들께서 답을 주기까지 기다리지 않고, 내가 먼저 제시하려면 어떻게 해야하는지가 궁금했다.
이렇게 내려온 우선순위가 팀 단위로 cascading 되었을 때, 나는 이걸 어떻게 정리 할 수 있을지 고민이 많다.
이번 세션을 통해 내 고민에 대한 도움을 받고자 했고, 도움이 된 것 같다.

팀원들이 이런 불만, 질문을 한다면?

업무가 많은데 우선순위를 모르겠어요
많은 일이 동시에 진행되어 정신이 없어요
Daily standup meeting을 하고 있는데, 팀원들이 팀 업무에 대한 이해도가 떨어져요

해결책

팀과 팀원들의 업무를 드러내고,
Scrum/Kanban board를 이용하여 업무 리스트, 우선순위, 상태 가시화
이를 통해 어느 팀원이 여러 일이 하고 있다는 것이 가시화되고 해결해야한다는 것을 챙길 수 있다.
그리고 말로만 하는 것보다 이 칸반을 보면서 Daily standup meeting을 진행하면 이해도가 훨씬 높아질 수 있다.

Issue/Risk 관리

팀원들이 이런 불만, 질문을 한다면?

Issue 혹은 Risk를 놓치고 진행해서 일정 지연이 일어나는데, 잘 관리할 수 있을까요?

해결책

Issue와 Risk를 중요도와 함께 시스템(task management tool같은거)에 등록을 한다.
Issue는, issue의 정의와 이 issue가 close되는 조건을 명확하게 적고,
risk의 정의와 risk의 level, detail, 대응 방안 등을 명확하게 적는다.

R&R(Role & Responsibility)

이건 <[Agile] 하나의 팀을 만드는 방법> 에서 살펴본 RACI로 시각화를 할 수 있다.

RACI(R: Responsible, A: Accountable, C: Consulted, I: Informed) table을 구성하고,

table의 각 작업의 R&R(Role & Responsibility)를 명확히 해보는 것.

<RACI(R: Responsible, A: Accountable, C: Consulted, I: Informed) table>

이란, 업무에 대하여 관련자들이 담당하는 역할과 책임을 매트릭스 형태로 기술한 것이다.

Responseible(담당): 업무를 진행하는 실무 담당자
Accountable(책임): 결과물에 대해 책임을 지는 최종 결정권자
Consulted(조언): 업무가 결정되거나 수행되기 전 조언을 주는 자
Informed(통지): 업무와 진행 상황/수행 결과의 통보를 해주는 자

팀 상태

팀원들이 이런 불만, 질문을 한다면?

팀원들이 전반적으로 지쳐 있어요 --> 팀원 상태 문제
외부팀과 협업 시 힘들어요. 프로세스가 문제인 것 같아요. --> 팀 성숙도 문제

해결책

팀원 상태 시각화가 필요 <Agile Team Health Check>
팀 성숙도 시각화가 필요
회고

팀 업무 시간

팀원들이 이런 불만, 질문을 한다면?

코딩 외 다른 일에 시간을 많이 써서 생산성이 떨어지는 것 같아요. --> 업무 시간 문제

해결책

가장 노력이 많이 들어가고, 민감한 부분이기 도 해서, 어떤 걸 측정할지, 왜 측정하는지 팀원들과 합의 과정이 꼭 필요하고
이 측정 후에 결과를 바탕으로 팀원간의 이해, 회고 등이 있어야 한다.

[Agile] 지속성장을 위한 애자일 팀의 건강진단

HJChung — Mon, 12 Feb 2024 00:15:08 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

애자일 팀 건강진단(Agile Team Health Check) 이란?

함께 일하는 방식을 개선하고자 하는 애자일 팀을 위한 자체 평가 도구
팀의 온도를 측정하고 지속적인 개선을 시작할 수 있는 좋은 방법
일반적인 건강검진처럼 지속적으로 측정하여 팀의 성장을 추적할 수 있다.

왜 필요한가?

는 이게 뭔지에 대한 설명에 잘 나와있다.

애자일 팀 건강진단(Agile Team Health Check)의 진단 요소 측정 결과가 지속적으로 함께 일하는(== 즉, Team work) 방식을 개선하고 --> 이게 잘 개선되었는지 (==함께 일하는 팀의 성장) 으로 이어졌는지를 평가할 수 있는 지표이기 때문이다.
이 지표를 측정해야만 관리하고 개선될 수 있다.

진단 요소

애자일 팀 건강진단(Agile Team Health Check)의 진단 요소에는 뭐가 있을까?

<The propsed model of Big Five in teamwork by Salas> 에 따르면

함께 일하는(== 즉, Team work) 데에 필수적인 환경 요소는

팀 멘탈 모델의 공유 (Share Mental Models)
닫힌 순환 커뮤니케이션 (Closed-loop Communication)
상호 신뢰 (Mutual Trust)

핵심 요소는

림 리더십 (Team Leadership)
팀 지향 (Team Orientation)
상호 업무 모니터링 (Mutual Performance Monitoring): 구성원들이 어떤 일을 하고 있는지 아는 것
상호 지원 (Back-up Behavior)
적용성 (Adaptability)

---> 그래서 애자일 팀 건강진단(Agile Team Health Check)는 이러한 환경 요소와 핵심 요소를 측정하는 것이다.

측정 방법

'환경 요소'와 '핵심 요소'라는 보이지 않는 걸 어떻게 측정할 것인가?

팀의 가치나 원칙과 같은 키워드나 문장, 질문을 통해 구성원들이 느끼는 바를 측정하거나 질문에 대한 답을 통해 측정한다.

이를 1) 설문을 통해 측정하거나 2) 워크샵을 통해 측정하는 방식이 있다.

1) 설문을 통해 측정하는 방식은 시간이 적게 소요되나 설문에 대한 이해나 관심이 달라서 결과에 대한 신뢰성이 떨어질 수 있다.

2) 워크샵의 경우 시간과 노력을 들여야 하나 설문이나 질문에 대한 이해나 관섬을 논의할 수 있어서 결과에 대한 신뢰성을 높일 수 잇다.

그래서 가능하다면 워크샵을 통해 함께 논의하고 측정하는 것이 추천된다.

측정 도구

1. Atlassian Team PlayBook - Team Health Monitor

진단 요소라고 판단한 8가지 속성을 기반으로 워크샵 형태로 진행하여 팀의 상태를 평가하는 방법을 제공함.

2. Spotify Squad Health Check

Tribe 또는 Squad 의 모임인 Cross-team 형태에서 Team health Check 데이터를 수집하는데 이상적으로 적합하여 대형 프로젝트를 진행하는 팀에서 사용하는 도구

3. 그 외에도 직접 만들어서 사용하기

팀 가치나 원칙 혹은 규칙등을 선정하여 직접 도구를 만들어서 사용하기도 한다.

라인싸몰의 Agile Team Health Check Case study

라인싸몰 Case Study는
1. [Agile] 애자일 팀의 시작. 라인싸몰 Case Study
2. [Agile] 하나의 팀을 만드는 방법
의 글을 통해 계속 이어지는 것으로, 위 2 링크가 선행되어야 라인싸몰 Case Study에 대한 이해가 쉽다.

1) 라인싸몰 Home 팀 Agile Team Health Check background

- 새로운 PO의 합류

- 새로운 PO와 기존 구성원과 가치에 대한 의견 충돌

- 새로운 PO는 베트남 오픈에 대한 일정 압박이 있음.

- 팀은 일은 많고 일에 대한 동기가 많이 떨어진 상태임.

2) 진단 요소

팀 가치나 원칙 혹은 규칙등을 선정하여 검진 요소 만듬.

3) 측정 방법

도출된 진단 요소로 설문을 진행.

4) 측정된 것으로 진단 결과 도출

설문 결과를 바탕으로 팀이 모여서 취약점을 확인하고 개선 사항을 도출함.

5) 개선을 위한 Action Item

설문 결과를 바탕으로 회고와 같은 활동을 통해 Action Item을 도출하고 개선하려고 노력함.

[Agile] 하나의 팀을 만드는 방법

HJChung — Sat, 10 Feb 2024 23:14:50 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

Agile Inception

하나의 팀. 모두가 한 버스에 같이 타기.

프로젝트가 실패하는 이유

팀의 목표에 대해서 sync를 못하고 일을 하는 것.

사람들이 프로젝트 성공의 의미를 다 다르게 해석 & 생각하고 있어서
SW를 Release할 때서야 서로의 생각이 달랐다는 것을 깨닫는 경우도 있음.
처음부터 모두 같은 생각을 가지지 않았다는 것이 문제라는게 아니라, 모두의 의견이 일치되지 않은 상태에서 프로젝트가 시작된 것이 문제.
이루어진 적이 없는 합의가 이루어졌다고 믿는 성급한 가정이 실패의 이유이다.

프로젝트 성공을 위해 필요한 것

결국, 너무 당연한 말이지만 팀의 목표에 대해서 sync를 맞추는 것.

여러 방식과 시도의 커뮤니케이션을 통해서

어? 너는 House를 이렇게 생각하고 있었구나. 나는 이렇게 생각하고 있었어. --> 맞춰나가기

즉, 아래의 과정이 필요하다.

현명한 선택을 하기 위해 목표, 비전, 프로젝트 현재 상태에 대해 팀원과 소통
이해관계자가 적절한 결정을 내릴 수 있도록 프로젝트에 관해 알아야 할 정보 제공 --> 도경님한테 리포트 프로젝트 과외해 달라고 해야겠다.

결국 이 과정들을 거쳐서 팀의 목표에 대한 sync를 맞춰서 각 개인마다 하나의 목표를 알고, 서로가 그 목표를 위해 어떤 일을 하는지를 아는 '하나의 팀' 을 만들자라는 것이고, 이 하나의 팀이 우리의 프로젝트를 성공으로 이꿀어준다는 것이다.

최고의 팀은 '하나의' 팀이다.

<철학> 하나의 팀

하나의 팀을 위해서는 아래의 질문에 답할 수 있어야 하며,

이후 나올 Inception workshop의 결과로 각 팀원들이 이 질문에 답할 수 있다면, 성공적인 workshop이었다고 할 수 있을 것 같다.

우리 팀은 왜 존재하는가? 팀으로 만든 분명한 목적. 존재의 목적
우리는 무엇을 하는가?
우리는 어떻게 행동해야 하는가? 이는 팀의 가치에 연관된다. 업무를 하면서 팀의 가치가 충돌될 때 어떻게 행동할 것인가? 이는 팀의 정체성, 행동 양식으로 나타난다.
우리는 어떻게 목표를 이룰 것인가? 핵심 전략을 찾고, 이 전략을 이루기 위한 구체적인 업무
누가 무엇을 해야 하는가?

<방법론> Inception workshop

팀의 목표에 대한 sync를 맞춰서 각 개인마다 하나의 목표를 알고, 서로가 그 목표를 위해 어떤 일을 하는지를 아는 방법

프로젝트 시작의 시점에 모든 이해관계자, 실무자 들이 sync를 맞추기 위한 좋은 방법에는 Agile Inception Deck practice가 있다.

10 questions of Inception Deck (프로젝트를 시작하기 전에 반드시 물어야 할 10개의 까다로운 질문)

우리가 여기 왜 모였는지 물어봐라
엘리베이터 피치를 만들어라 (30초간 2문장으로 프로젝트를 설명)
제품의 광고를 디자인 하라 (당신이 고객이면 사겠는가?)
NOT 리스트를 작성하라.
프로젝트에 관계된 다양한 사람들과 알고 지내자
해결책을 보여줘라 (기술적인 아키텍쳐를 보며 모두 같은 생각을 하고 있는지)
미리 야근 거리가 될 만한 것을 찾아보자
규모를 정하라 (3, 6, 9 개월?)
우선순위를 파악하라 (Scope, Budget, Time, Quality)
비용과 결과물이 무엇인지 보여줘라

--> 근데 이 리스트만 봐서는 '어쩌라고', 그리고 답변을 받았다고 해도 '그래서 이 답변이 성공적인 프로젝트로 가는데 도움이 어떻게 되는데?' 라는 생각이 든다.

그래서 앞서서 정리한 내용에서 우리가 Agile Case Study를 하기 위해 만든 <라인싸몰> 서비스에서 '라인싸몰 Home팀 의 Inception Deck'은 어떻게 하는지 그 팀의 Workshop을 한 번 보면서 이번에는 Inception Deck의 case study를 해보고자 한다.

1) 라인싸몰 Home 팀 Inception workshop background

- 최근에 Home 팀에 경력직 PO 1명, 개발자 1명이 합류

- 멤버들간의 생각이 통일 되지 않은 컨센서스 이슈들이 나오는게 감지됨

2) 라인싸몰 Home 팀 Goal of Our Inception Workshop

- 팀원들간의 컨센서스 만들기 & 목표 얼라인하기

- 팀이 담당하는 Scope를 명확히해서 그 부분에 집중할 수 있게 하기

- 팀원의 각 역할을 명확히 해서 구멍하는 역할없이 업무가 잘 돌아가도록 하기

3) Inception 10 Questions들의 목표.

즉, '그래서 이 답변이 성공적인 프로젝트로 가는데 도움이 어떻게 되는데?' 에 대한 답이 이 link이 된다.

- 컨센서스 만들기와 목표에 얼라인 하기는 Elevator Pitch와 OKR를 성공적으로 도출해내는데 도움이 될 것이다.

- 역할 R&R 명확히 하기는 Cross Functional Team내에서의 R&R을 명확히하는데 도움이 될 것이다.

- 위험요소 사전 식별은 프로젝트가 시작되는 시점에 끝나는 시점의 일을 미리 예측을 해봄으로써 대응 할 수 있다.

Inception Workshop Day 1.

Day 1의 목표는 프로젝트 참여 멤버들의 하나의 Goal에 얼라인 하게 하는 것.

1. 체크인: 이후의 워크샵의 분위기를 부들부들하게 만들어 진행을 원할하게 하기 위한 ice breaking.

2. Elevator Pitch: '우리 서비스의 고객은 누구인지 / 우리가 고객에게 무엇을 제공하는지 / 우리의 가장 큰 경쟁상대는 누구인지 / 그 경쟁상대와 우리는 어떤 큰 차별점이 있는지' 를 두 문장을 30초 이내로 말할 수 있도록 하는 format. 을 팀원들과 나눈다. 이 것들을 모아서 voting하고, 최종 elevator pitch를 만들 수 도 있다.

➡️ 우리 회사의 워크샵 경험으로 치자면 <북극성 지표 만들기> 였다고 생각한다.

➡️ 이를 좀 더 깊이있게

우리 팀은 왜 존재하는가? 팀으로 만든 분명한 목적. 존재의 목적
우리는 무엇을 하는가?
우리는 어떻게 행동해야 하는가? 이는 팀의 가치에 연관된다. 업무를 하면서 팀의 가치가 충돌될 때 어떻게 행동할 것인가? 이는 팀의 정체성, 행동 양식으로 나타난다.

에 대한 답으로 도출해내고 싶을 때 사용할 수 있는 개념(활동)은 <Team Value Proposition>이다.

3. OKR: 라인싸몰의 전체 OKR을 상속 받아서 '라인싸몰의 Home팀의 OKR'을 정하기.

<OKR> 이란?

Objective + Key Result

목표(Objective)를 어떻게 설정하고, 이 목표가 잘 달성되었는지 확인 할 수 있는 지표가 되는 핵심 결과(Key Result)를 설정해보도록 도와주는 목표 성과 관리 Framework이다.

Objective: should not be a task. Should be an ambitious goal
Key Results: “measurable” && “objective” results that can achieve the goal

예시

# OKR example: for Fantasy Football team

## General Manager
- Objective: Make $ for owner
- Key results
    - Win super bowl
    - Fill hoe stands to 90%

## Head Coach
- Objective: win super bowl
- Key results
    - Passing attack amasses 300+ yards per game
    - Defense allows fewer than 17 points per game
    - Special teams unit ranks in top 3 in punt return coverage

## Offensive Coach
- Objective: Generate 300+ yards-per-game passing attack
- Key results:
    - Achieve 65% pass completion rates
    - Cut interceptions to fewer than 1 per game
    - Hire new quarterbacks coach

Inception Workshop Day 2.

Day 2의 목표는 앞으로 있을 risk를 사전에 미리 예측을 해보고, 이 일들이 왜 일어났고, 이걸 어떻게 예방 할 수 있을지 도출해내는 것.

1. Heaven & Hell: 우리 팀의 최고의 순간과 최악의 순간을 상상해보자.

2. Problem Solving: 최악의 순간이 왜 생겼을지, 어떻게 해결해볼 수 있을지 상상해보고 논의해보자.

Inception Workshop Day 3.

Day 3의 목표는 프로젝트의 Scope를 정의하는 것.

1. 유저 시나리오를 생각해보면서 --> 2, 3. 우리의 핵심 기능이 뭔지 --> 4. 그 다음엔 우리의 핵심 기능에 어떤 약점이나 개선할 점이 있는지 알고 이 핵심 기능을 위해 어떤 일을 해야하는지 알면

프로젝트의 scope를 정할 수 있다.

Inception Workshop Day 4.

Day 4의 목표는 Day 3에서 <핵심 기능을 위해 우리가 어떤 일을 해야하는지> 에 대해 도출한걸 바탕으로,

RACI(R: Responsible, A: Accountable, C: Consulted, I: Informed) table을 구성하고,

table의 각 작업의 R&R(Role & Responsibility)를 명확히 해보는 것.

<RACI(R: Responsible, A: Accountable, C: Consulted, I: Informed) table>

이란, 업무에 대하여 관련자들이 담당하는 역할과 책임을 매트릭스 형태로 기술한 것이다.

Responseible(담당): 업무를 진행하는 실무 담당자
Accountable(책임): 결과물에 대해 책임을 지는 최종 결정권자
Consulted(조언): 업무가 결정되거나 수행되기 전 조언을 주는 자
Informed(통지): 업무와 진행 상황/수행 결과의 통보를 해주는 자

Inception Workshop Day 5.

마무리 정리, Wrap-up

애자일

₩1'시작'.

시작. 시작.. 그래 시작! 시작하려면 일단 이런 것들이 있어야 해요.애자일 팀의 '시작'. 시작. 시작.. 그래 시작! 시작하려면 일단 이런 것들이 있어야 해요.

애자일 팀의 '시작'. 시작. 시작.. 그래 시작! 시작하려면 일단 이런 것들이 있어야 해요.

[Agile] 애자일 팀의 시작. 라인싸몰 Case Study

HJChung — Sun, 28 Jan 2024 05:06:19 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

라인싸몰을 운영하는 가상의 팀을 통해 OKR을 설정하고 Portfolio Backlog를 설정하는 방법에 대해 알아보자.

가상의 애자일 조직을 만들어 보자.

우선 가상의 E-commerce 서비스를 만드는 가상의 팀이다.

서비스 이름은

<라인싸몰>

서비스의 컨셉은

"별로 필요는 없지만 인싸가 되는데 도움이 되는 지름신을 신속하고 편리하게 가라 앉혀주는 역대급 쇼핑몰" 이다.

조직 구성은

Lean Canvas, Business Canvas, 경영 전략

위 표에 있는 것들을 모두 종합해 봤을 때, 한마디로 라인싸몰을 정의하자면 (Unique value proposition high-level concept) '가상과 실제가 통합된 진정한 메타버스 쇼핑'

Strategic Theme, OKR, 전략 목표

Portfolio Backlog, Priority by Eisenhower Matrix, 목표들간의 우선순위

--> 이게 라인싸몰 전사의 우선순위가 된다.

그러면 라인싸몰의 각 조직들은 이에 맞춰서 각 조직의 프로젝트를 진행해는 기반이 된다.
이 우선순위는 누가 제시했는가? 당연히 Top management level에서 했겠죠.... 네..

라인싸몰의 <Portfolio Backlog,Key Result, Assignment>

OKR을 기준으로 각각의 Key Result는 뭐고, 이걸 어떤 조직팀들이 맡아서 할 것인가

Program Backlog

Commerce Tribe Program Backlog

위에서 라인싸몰의 <Portfolio Backlog,Key Result, Assignment>이 이러저러 하다 라는 게 정리해되어서 내려왔다.

그럼 우리 Commerce Tribe에서는 이걸 어떻게 정리할 것인가?

이 Commerce Tribe의 Program Backlog를 Objective으로 한 번, Team으로 한번 더 분류해서 세부 기능들(Program Backlog Items)를 다시 그려보면 아래와 같은 표가 나온다.

이런 item들이 sprint backlog화 되는 것이다.

--> 이제서야 sprint가 나온다!!!! 우린 앞의 것들이 있나???? 우린 왜 앞의 것들을 싸그리 다 무시하고 바로 'sprint'로 돌입하는가..........

[Agile] 왜 Agile? 어떻게 Agile Transformation?

HJChung — Sun, 28 Jan 2024 04:17:59 +0900

[LINE X 원티드] 애자일 방법론 무료 강의를 듣고 정리한 내용입니다.

1. 애자일이란?

애자일은 프로젝트를 더 작은 반복 주기로 나누는 프로세스다.

각 반복 주기의 결과물을 측정하여 지속적으로 일정을 평가하는 데 사용한다.

기능은 비즈니스 가치 순서대로 구현하므로 가장 중요한 것이 먼저 구현된다.

품질은 가능한 한 높게 유지한다.

일정은 주로 범위를 조절하여 관리한다.

이것이 애자일이다.

- Clean Agile, Robert C. Martin

2. 애자일의 장점

애자일을 하면 뭐가 좋아지지?

1) 민첩함과 유연함

숨겨진 고객의 니즈를 발굴하여 빠르게 시장에 내놓을 수 있음
달라지는 고객뿐만 아니라 조직원들의 요구에도 기민하게 반응
변화에 대해 민첩하게 반응함

2) 주도적인 팀

우리가 무엇을 하는지, 왜 하는지, 무엇을 할지 알게 된다.
원팀이 됨
목적에 포커스를 두는 팀
가시화가 됨
소통이 좋아짐
업무에 포커스
경직된 조직문화를 바꿀 수 있음

3) 성장을 위한 Mindset-shift

하나의 목적을 더 깊게 고민하고 협업하여 성과를 만들어 낼 수 었어서
더 큰 재무적 성과 뿐만 아니라 생산성을 증진
회고를 통해서 성장함

3. 애자일의 난관

구체적이지 않은 방법들의 나열이나 개념적인 이야기들만 하거나 --> 진짜!!!
사례를 들어서 알려준다고 해도 외국 사례 위주로만 소개하거나
당장 쓰고 싶은 how to 는 왜 안 알려주는거야!

그래서.. 어찌저찌해서 팀에 애자일을 도입한다고 해도 도입 이후 문제는 이것들이다.

생각 했던 대로 애자일이 작동하지 않음
데일리 스크럼을 하면 우리는 원팀이 될 줄 알았는데 다들 피곤해함(ㅋㅋ)
애자일을 하면 일잘러가 될 줄 알았는데, 우리가 바뀌거나 성장하는 느낌은 들지 않고 뭐가 달라졌는지 모르겠음. (ㅋㅋㅋ)
애자일은 얼마 지나지 않아서 짜증나는 프로세스로 바뀜
쪼는 방식만 바뀐 것 같음

4. 그럼 어떻게 해야하는가?

1) practice와 process를 같이 해야 함

왜냐면 의미와 목적이 없는 practice는 초반에만 반짝 효과가 있고 오래 가지 않는다.
목적과 의미와 방향성이 없는 '단순한 시도'는 '하나리까 한다..근데 해봤는데 별로던데?' 로 가기 쉽상이다.
더 나아가 조직 문화가 뒷받침이 안되는 애자일의 시도는 practice의 수행에 그친다.
그리고 또 process만 하게 되면 잘게 쪼갠 waterfall에 지나지 않는다. -> 맞아. 완전 공감.

2) Being Agile을 같이 해야한다.

--> 이렇게 Doing Agile과 Being Agile을 같이 하는 것을 'Agile Transformation' 이라고 한다.

5. Agile Transformation

어떤 조직에 '우리 애자일 제대로 해보자' 하면 Agile Transformation한다 라고 보고,

점차적으로 성숙 & 확대해나갈 수 있다.

6. Agile Transformation의 원칙

1. 리더십

Leader Circle for high alignment and collaboration

2. 전략 (비전 목표)

North Star with aspiration

OKR with agile

3. 조직 구조

Empowered team and self-organized

High alignment and collaboration

4. 프로세스

5. 사람에 대한 얘기

Continous improvement

이것들을 유지시켜줄 강한 조직 문화

Psychological Safety

---

리눅스 시스템 및 커널 전문가 스터디 시작

HJChung — Sun, 29 Oct 2023 18:39:16 +0900

10월 12일자로 프로그래머스에서 약 5개월간 진행하는 <리눅스 시스템 및 커널 전문가 과정> 에 참여하게 되었다.

목적

본 과정의 목적은

새로운 하드웨어에 리눅스 운영체제 기반 시스템을 설치하고, 서버를 작동시키고, 리눅스 운영체제 커널을 수정하여 새로운 기능을 추가하고, 성능을 최적화하고, 리눅스 기반 시스템의 오류를 찾고 디버깅할 수 있는 기술을 실습과 함께 5개월동안 학습하는 것이다.

목적이 거의 커리큘럼의 굵직한 주제들이 거의 나열해둔 것과 같아서, 내가 이해한 목적을 한 줄로 정리하자면,

리눅스 운영체제를 이해하고, 운영체제 커널의 기능 개발 및 성능 최적화, 트러블 슈팅을 실습을 통해 앞서 개념 이해 한 것을 적용할 수 있는 과정 이라고 생각한다.

커리큘럼

1. C/C++ 알고리즘 해결

2. 리눅스 시스템 설정 및 리눅스 명령어 사용법

3. 라즈베리 파이 기반 리눅스 구축

- 라즈베리 파이 하드웨어 구조의 이해

- 라즈베리 파이 상에 리눅스 시스템 설치, 작동, 설정 실습

- 임베디드 시스템 설계와 개발에 있어서의 최적화 기법 학습

4. 리눅스 네트워크 및 보안 설정

- 리눅스 네트워크 설정 방법

- 리눅스 보안 설정 방법

- 클라우드 컴퓨팅 인프라 기초 학습

5. 리눅스 시스템 프로그래밍

- 시스템콜의 역할 및 동작 원리 학습

- 시스템 프로그래밍 디버깅 기법 습득

- 과제를 통한 시스템 프로그래밍 실습

6. 리눅스 네트워크 프로그래밍

- 리눅스 네트워크 동작 원리

- 소켓 프로그래밍 실무

7. 운영체제 개념과 리눅스 커널

- 운영체제의 핵심 구성 요소 개념

- 리눅스 커널과 운영체제 핵심 요소의 관계, 커널 소스코드 구조

8. ARM 프로세서

- CPU 구조의 기본 개념 및 ARM 코어의 특징

- 프로그램 실행 모델과 APCS

- ARM 코어와 ARM Linux 커널의 관계

9. 프로세스, 메모리, 파일 시스템

프로세스

- 리눅스 프로세스 관리 구조

- 리눅스 프로세스 스케쥴러 동작 원리 및 활용 기술

메모리

- 리눅스 메모리 관리 동작 원리

- 가상 메모리 핵심 개념 학습

- 리눅스 메모리 관리 모니터링 기술

파일 시스템

- 리눅스 파일 관리 개념 및 파일 시스템 동작 원리

- 최신 저장장치 기술과 파일 시스템 구현 기술

10. 디바이스 드라이버

- 디바이스 드라이버의 구조 및 동작 원리

- 문자 디바이스 드라이버 구현 실무

11. 리눅스 컨테이너와 Docker 기술

- 리눅스 컨테이너 개념과 Docker 기술의 이해, 실무

- Docker 활용 기술 동향 및 관리 기술

12. AI 반도체, 최신 시스템 반도체와 리눅스 기술,

14. 리눅스 커널 프로그래밍

15. 리눅스 커널 덤프 분석

16. 리눅스 시스템 Troubleshooting

가 있다.

수업 방식

수업 방식은

동영상 수업
라이브 온라인 수업
실습
프로젝트 수행
특강, 세미나, 멘토링.. 등이 있다.

특히 강의, 특강, 세미나, 멘토링 등을 담당해주시는 강사분이나 참여 기업이 인상적이었다.

본 과정에 관심을 가지게 된 계기는 취업이나 시스템 엔지니어로의 커리어 변경 같은 거창한 것은 아니었고, 개인적인 흥미와 업무상에서 느낀 답답함이었다.

나의 이력서에서 확인할 수 있듯이, 회사에서 입사 초에는

AWS 인프라를 구축하고, 배포를 담당하는 등의 업무를 맡았고, 현재는 주로 AI 서비스를 안정적이고 효율적으로 제공하기 위한 백엔드 서비스 개발을 하고 있다. 그리고 서비스 안정성에 대해서는 개발 측면 뿐만 아니라 운영 측면, 즉 모니터링과 로깅으로 업무 확장이 되었고 (아직은 검토 단계이긴 하지만) 더 나아가 팀 리더 분과 MLOps까지 진행할 계획을 과 얘기를 나누었다.

이 모든 업무에서

리눅스
Docker
서버, 네트워크, 운영체제, 메모리 등의 컴퓨터 리소스 관리 등을 해야하는 일이 많다.

왜 기초가 중요한지, 학생때는 그렇게도 뜬 구름 잡기처럼 보이던 컴퓨터공학 과목들이 실무자가 되어서야 왜 그런 개념들이 필요한 건지, 왜 잘 배워둬야 했었는지 뼈져리게 느꼈다.

한정된 리소스 자원을 활용해야 하거나 성능 최적화를 위해 좀 깊이 이해하고 개발해야하는 업무를 맡거나, 깊이 이해하지 못하면 도대체 어디서부터 시작해야할 지 막막했던 디버깅을 하면서 항상 나를 턱턱 막히게 했던건 '컴퓨터 구조, 운영체제, 네트워크, 자료구조' 가장 기저에 깔린 '기본'이었다.

그래서 컴퓨터 구조와 운영체제, 네트워크 에 대해서 개인적으로 책으로 독학을 했는데, 하면서도 어플리케이션 개발자라서 그런지(그렇다는 핑계인지), 그 커널이 동작하는 방식이라는 것이, 컴퓨터 구조라는 것이, 프로세스 스케줄링 방식 구현이라는 것이,.... 많은 것들이! 눈으로 보이지 않고, 어떻게 구현되어있는지 코드나 동작을 확인하지 못하니까 답답함이 싸여져 갔다. 배운 내용과 활용에 자꾸만 괴리가 발생하고, 아직 학습이 덜 되었다는 증거일 수도 있겠지만 배운 내용이 실제 업무에 적용이 잘 되지 않았다.

그러던 중에 프로그래머스에서 <리눅스 시스템 및 커널 전문가> 과정을 진행한다는 배너를 보게 되었고,

상세 커리큘럼과 OT를 듣고나서, 위 커리큘럼에 빨간 색 글씨로 표시해 둔 것 처럼, 실습을 통해 직접 ‘구현’, ‘디버깅’, ‘분석’ 을 해보면서 이런 답답함을 조금이나마 해결해 줄 수 있거라는 생각이 들었다.

아직 2주차라 C/C++ 알고리즘 해결, 리눅스 시스템 설정 및 리눅스 명령어 사용법 에 대해서 배우고 있으며

앞으로 커리큘럼에 있는 많은 단계들이 남아있다.

이 과정들을 진행하면서의 과정과 개인 노션에만 적고 있었던

컴퓨터 구조
운영체제
네트워크
(생긴다면) 현업에서 이런 것들을 고려한 소프트웨어 개발 경험
실습 내용
프로젝트 내용

등을 블로그에 정리해보려고 한다.

시스템 엔지니어뿐만 아니라 애플리케이션을 개발하는 소프트웨어 엔지니어에게도 컴퓨터 구조와 운영체제의 학습은 문제 해결 능력을 강화하는 필수적인 요소라고 생각한다. 프로그램은 하드웨어에서 실행되며, 운영체제는 이를 조작하고 모니터링한다. 이를 통해 운영체제를 이해하면 문제 발생 시 실마리를 찾을 수 있다.

이를 학습하고 이해한다면,

운영체제가 제공하는 정보를 해석할 수 있고,
운영체제에게 필요한 정보를 요청할 수 있으며,
하드웨어 - 운영체제 - 응용 프로그램 간의 상호작용을 깊이 파악할 수 있다.

5개월 동안, 그리고 그 5개월 이후에는 이러한 역량이 확장 되어 있고, 보다 깊은 이해와 통찰력을 가지고 업무에 임하는 개발자가 되어있길 희망한다.

그리고 기회와 역량이 된다면 리더분(나의 팀 리더님은 Google, Microsoft, Qualcomm 본사에서 리눅스 및 커널 개발자셨다..)께서 추천해주신 https://www.outreachy.org/ 에도 참여해볼까 한다.

Windows 11 WSL2 및 Ubuntu 22.04에서 GPU 활용 Docker 실행 환경 세팅

HJChung — Thu, 26 Oct 2023 22:54:57 +0900

찾아본 대부분의 자료와 공식 문서가 영어로 되어있었기도 했고, 스위스 엔지니어에게 해당 방법을 알려줘야 했기 때문에 정리해 본 것이라 중간 중간 영어로 적힌 부분이 있다.

Environment

Ubuntu 22-04 혹은 Window WSL(Windows Subsystems for Linux)

wsl 설치 방법

$ wsl --list --online
$ wsl --install -d Ubuntu-22.04

Prerequisite

Check Hardware

아래의 모든 작업을 진행하기 전에 정말 기본적이지만 GPU 하드웨어가 있는지, 또한 사용가능한 형태로 설치되어있는지 확인해야 한다. 시스템에 어떤 그래픽 카드가 설치되어있는지 확인하려면 다음과 같은 명령어를 사용한다.

$ sudo lshw -C display

Installation

1. NVIDIA Driver

개념

NVIDIA driver는 NVIDIA GPU 하드웨어 리소스를 제어하고 관리하기 위한 프로그램이다. GPU와 OS(여기선 리눅스 서버)간의 통신을 중개하고, 작업을 실행하는데 필요한 라이브러리 및 도구를 제공한다. (참고)

따라서 리눅스 서버에서 NVIDIA GPU 하드웨어 리소스에 접근하기 위해서는 먼저 Driver가 설치 되어야 한다.

설치

nvidia driver installation이라고 검색하면 가장 먼저 나오는 이 자료 와 조금 다른 방법이다.

1. Find NVIDIA Drivers

Before a driver, you need to check if it is available in the package list on the ubuntu image. You can find all packages containing the text "nvidia-driver" by running the following commands:

$ apt search nvidia-driver
# Or
$ apt-cache search nvidia-driver

These commands will help you locate any packages related to NVIDIA drivers that are available for installation.

2. Update the package list and performing security upgrades (optional):

$ sudo apt update

$ sudo apt upgrade

3. Install NVIDIA Driver

Installing the driver using the found driver name. You can install it using the apt-get command:

$ sudo apt install -y nvidia-driver-450-server[VERSION]

Replace [VERSION] with the specific version number of the driver you want to install.

4. Reboot the server in host machine

$ wsl --shutdown ## this should happen on windows powershell
# OR
$ sudo shutdown -r now
# OR
$ sudo reboot

5. Done

After the reboot is complete, you should verify if the driver has been installed successfully. You can check the installation using the nvidia-smi command:

$ nvidia-smi

이런식으로 결과가 나오면 정상 설치 된 것이다.

2. Docker

아에 아무 것도 없는 clear한 서버에서 모든 것을 실행한다는 가정으로, Docker와 docker-compose 설치까지 진행해보았다.

특히, WSL 사용시 컨테이너 내에서 GPU 리소스를 사용하기 위해서는 특히나 Docker Desktop(GUI)를 사용해서는 안 된다. 자세한 내용은 모르겠지만 아직 지원을 하지 않는 것 같다. (참고 링크)

1. Uninstall Docker Engine

Uninstall the Docker Engine, CLI, containerd, and Docker Compose packages:

$ sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-ce-rootless-extras
# or
$ sudo apt-get remove docker docker-engine docker.io

Images, containers, volumes, or custom configuration files on your host aren't automatically removed. To delete all images, containers, and volumes:

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd
$ sudo apt-get update

You have to delete any edited configuration files manually.

2. Install Docker Engine

Docker-CE on Ubuntu can be setup using Docker’s official convenience script

$ curl https://get.docker.com | sh
$ sudo systemctl --now enable docker

아래 내용은 wsl Ubuntu-22.04에서 이 포스트 내용을 실행하고자 할 때 필요한 내용이다. If you met ‘Failed to connect to bus: Host is down Error’, please update iptables.

$ sudo update-alternatives --config iptables

and choose number1 option.

3. Post-install steps for Docker Engine

After install Docker, Do Linux post-installation steps for Docker Engine

Reference linke is this post-install documentation.

Create the docker group.

$ sudo groupadd docker

Add your user to the docker group.

$ sudo usermod -aG docker $USER

Log out and log back in so that your group membership is re-evaluated.

$ newgrp docker

Verify that you can run docker commands without sudo.

$ docker run hello-world

Configure Docker to start on boot with systemd

$ sudo systemctl enable docker.service

$ sudo systemctl enable containerd.service

4. Check Docker Daemon status

check your docker daemon status.

$ sudo service docker status

If Docker is not running, please start it.

$ sudo service docker start

And check status again.

$ sudo service docker status

Docker is running. Try to run simple 'hello-world' image to check docker daemon.

$ docker run --rm -it hello-world

3. Docker Compose

$ sudo curl -L https://github.com/docker/compose/releases/download/{proper docker compose version}/docker-compose-$(uname -s)-$(uname -m) \ -o /usr/local/bin/docker-compose

$ sudo chmod +x /usr/local/bin/docker-compose

$ docker-compose --version

4. NVIDIA Container Toolkit for Docker

개념

NVIDIA 컨테이너 스택은 NVIDIA GPU를 사용하는 Docker 컨테이너를 관리하기 위한 여러 구성 요소로 구성된다. 필수 구성 요소는 NVIDIA 드라이버, NVIDIA Container Toolkit, NVIDIA Container Runtime, NVIDIA Container Runtime Hook, 그리고 NVIDIA Container Library 및 CLI이다.

The main packages of the NVIDIA Container Toolkit are:

nvidia-container-toolkit
nvidia-cotnainer-toolkit-base
libnvidia-container-tools
libnvidia-container1

이러한 구성 요소를 올바르게 설치하고 설정하면 GPU를 사용하는 컨테이너를 실행할 수 있다.

NVIDIA Container Toolkit: NVIDIA 컨테이너 스택의 핵심 패키지 중 하나로, 다양한 구성 요소와 함께 패키징됩니다. 이 패키지는 NVIDIA GPU를 사용하는 컨테이너를 설정하고 관리하는 데 사용됩니다.
NVIDIA Container Runtime (nvidia-container-runtime): NVIDIA 컨테이너 스택의 중요한 구성 요소 중 하나로, 이 구성 요소는 OCI(Open Container Initiative)-호환 런타임으로 Docker나 Containerd와 통합됩니다. 이 런타임은 컨테이너 생성 및 실행 중 NVIDIA GPU 지원을 적용합니다.
NVIDIA Container Runtime Hook (nvidia-container-toolkit / nvidia-container-runtime-hook): NVIDIA 컨테이너 스택에서 컨테이너에 GPU를 주입하는 작업을 담당합니다. 이 훅은 컨테이너가 생성되고 시작되기 전에 실행되며, 컨테이너의 설정 정보를 기반으로 필요한 GPU 디바이스를 식별합니다.
NVIDIA Container Library and CLI (libnvidia-container1, nvidia-container-cli): 이 구성 요소들은 라이브러리와 간단한 CLI 도구로, GNU/Linux 컨테이너를 NVIDIA GPU와 자동으로 구성하는 데 사용됩니다. 라이브러리는 컨테이너 런타임과 독립적으로 동작하며, 컨테이너 런타임에 NVIDIA GPU 지원을 주입하기 위해 호출되는 API를 제공합니다.
1. 이 NVIDIA Container Library and CLI 패키지는 libnvidia-container-tools and libnvidia-container1 packages들로 구성되어 이를 패키징 한 것이다.

How these components are used depends on the container runtime being used.

더 자세한 내용은 https://docs.nvidia.com/datacenter/cloud-native/container-toolkit/1.14.3/index.html 여기를 확인 하면 된다.

추가로

- https://github.com/NVIDIA/nvidia-docker/issues/1268

- nvidia-docker 와 nvidia container runtime의 차이

두 글도 참고하기 좋다.

설치

1. Setup the package repository and the GPG key

$ distribution=$(. /etc/os-release;echo $ID$VERSION_ID) \\
      && curl -fsSL <https://nvidia.github.io/libnvidia-container/gpgkey> | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg \\
      && curl -s -L <https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list> | \\
            sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \\
            sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

2. Install the nvidia-container-toolkit package (and dependencies) after updating the package listing:

$ sudo apt-get update

$ sudo apt-get install -y nvidia-container-toolkit

3. Add the NVIDIA Runtime in Docker

The NVIDIA Container Toolkit provides different options for enumerating GPUs and the capabilities that are supported for CUDA containers. This user guide demonstrates the following features of the NVIDIA Container Toolkit:

Registering the NVIDIA runtime as a custom runtime to Docker
Using environment variables to enable the following:
- Enumerating GPUs and controlling which GPUs are visible to the container
- Controlling which features of the driver are visible to the container using capabilities
- Controlling the behavior of the runtime using constraints

방법 1) Daemon configuration file

The nvidia runtime can also be registered with Docker using the daemon.json configuration file. The NVIDIA Container Toolkit provides a utility to apply this configuration:

$ sudo nvidia-ctk runtime configure --runtime=docker

You can optionally set the nvidia runtime as the default runtime by specifying the --set-as-default flag:

$ sudo nvidia-ctk runtime configure --runtime=docker --set-as-default

And a --dry-run flag is also available to preview the changes before applying them.

To apply the new configuration, restart the docker daemon:

$ sudo systemctl restart docker
# or
$ sudo service docker restart
# and check docker status
$ sudo service docker status

방법 2) Command Line

Use dockerd to add the nvidia runtime:

$ sudo dockerd --add-runtime=nvidia=/usr/bin/nvidia-container-runtime

4. 끝이다. Windows 11 WSL2 및 Ubuntu 22.04에서 GPU 활용 Docker 실행 환경 세팅을 마쳤다.

잘 실행이 되는지 --runtime=nvidia 옵션을 준 nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04 Docker image를 사용하여 그 컨테이너를 실행한 환경에서 nvidia-smi 명령어를 실행해 보자.

$ docker run --rm --runtime=nvidia nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04 nvidia-smi

아래와 같은 결과가 나온다면 정상적으로 마친 것이다.