SK네트웍스 Family AI 캠프 1기 6주차 회고

Posted Jun 19, 2024

By J213h

17 min read

SK Networks AI Camp

Weekly 회고 - 6주차

포스트를 읽기 전에..
이 포스트는 SK네트웍스 Family AI 캠프를 다니면서 느낀 개인적인 생각을 정리한 포스트입니다.
배운 내용이나 스킬셋에 대한 설명은 별도로 작성하지 않았기 때문에, 그에 대한 정보는 다른 포스트를 참고해주세요!

Liked

팀 과제를 시작함.. 끝까지 화이팅!
처음엔 좋았는데 너무 바쁘다..

Learned

Vue

auto-grow

내용이 계속 길어질 경우, auto-grow 옵션을 설정하면 내용 입력 칸이 내용에 맞춰서 계속 길어진다.

Trigger

버튼에 트리거 연결
- @click=”메서드 이름” 을 입력하면 그 버튼이 눌렸을 때 해당하는 메서드가 작동하도록 할 수 있음

async 왜 쓰나요?

일단 비동기 처리를 수행하기 위해 async를 사용합니다.

동기 vs 비동기

동기
- 싱크를 맞춰야 되는 경우
- Ex) 전화 등
비동기
- 싱크를 맞출 필요가 없는 경우
- Ex) 카카오톡, 메일 등

비동기 처리

특징
- 비동기가 동기에 비해 속도가 매우 빠름
  - 너무 빨라서 데이터 처리가 제대로 되지 않는 경우가 발생할 수도 있습니다.
    - 위의 문제를 처리하기 위해 나온 의견
      Lock을 사용하자
      
      공유되는 자원들(Critical Section)에 접근을 제한하겠다는 의미
      
      동시에 멀티 스레드 상황에서 무분별한 Context Switching을 유발할 수 있음
      
      Watch Dog을 놓자
      준비가 되었는지 체크하겠다
      
      대기 시간을 놓자
      
      대기 시간보다 늦게 끝날 경우 문제가 발생할 수 있음
      
      대기 시간을 길게 잡으면 사실 여러분이 사용하는 서비스가 Timeout으로 터질 수도 있습니다(MSA 특성)
    - 실질적인 솔루션
      await 키워드를 사용해서 이 동작의 완료를 보장하도록 만듦
      실제 코드에선 아래와 같이 작성
      const board = await this.requestCreateBoardToDjango(payload)
      위의 코드에서 await가 걸렸다는 것은 this.requestCreateBoardToDjango(payload)가 비동기라는 뜻
      기본적으로 action에서 동작하는 코드들은 비동기로 동작합니다.
  - 결국 async는 비동기 데이터 처리를 할 때, 이에 대한 실행 보장을 위해 await를 사용하는 형태로 구성할 수 있음
  - 그렇다면 언제 주로 사용하게 될까?
    1. 요청은 axios 하나 꼴랑 보내고 끝나지만 응답을 하기 위해 많은 데이터를 소요해야 하는 것들
    2. 대표적으로 맵 정보나, 기타 데이터가 많은 것들
    3. 추가로 AI 관련 정보들이 여기에 속함
  - 추론에 소요 시간이 10분 걸리는 AI 알고리즘이 있을 때, 이 동작을 보장하기 위해 await를 사용하면 어떻게 될까요?
    10분이면 이미 모든 서비스가 터지고도 남을 시간! 어떻게 처리해야할까?
    1. Kafka와 AWS를 이용한 방법
    2. 첫 번째 방법보다 간단히 구성하는 방법

action과 mutation

action은 결국 비동기로 특정 행위(요청)을 하기 위해 구성합니다.
근데 mutations는 뭐냐?
- 앞서 살펴봤듯이 비동기의 문제점은?
  데이터의 무결성이 보장되지 않는다는 문제점이 있음
  데이터 무결성에 대해 생각한다면 이런 문제를 생각해볼 수 있습니다.
  비동기 코드가 돌 때 무결성을 보장하기 위한 장치들이 보장되지 않으면 1 + 1 = 2가 되지 않을수도 있음

데이터 무결성이란?

결론적으로 자원은 한정적이기 때문에 발생하는 문제입니다.
자원이 한정적이라는 것은 무엇을 의미하나요?
SW자원일 수도 있고 HW자원일 수도 있습니다.
가장 보편적인 자원 문제인 HW 차원의 자원 문제를 살펴보겠습니다.
- 범용 레지스터는 무슨 목적으로 사용하나요?
  컴퓨터 내부에서 동작하는 모든 연산에 사용합니다.
  - 범용 레지스터(General Purpose Register)
    컴퓨터에서 돌아가는 프로세스(각각의 메인이 존재하는)들은 서로 자원(범용 레지스터)를 차지하려고 함
```
  movl %ecx, $0x1    # 1
  movl %edx, $0x1    # 2
  add %ecx, %edx     # 3
        
  movl %eax, $0x3    # 4
  movl %edx, $0x7    # 5
  add %eax, %edx     # 6
```
    위와 같은 코드에서 1 ~ 6 순서대로 진행된다면 아무 문제 없을 것입니다.
    하지만, 1번 2번이 진행되고 우선순위가 4번 5번으로 넘어간 후, 3번 코드가 실행된다면 1 + 1을 수행하려고 한 결과가 1 + 7로 바뀌면서 8이라는 값을 도출하게 됩니다.
    즉, 데이터 무결성이 깨지는 상황이 연출됩니다!

Context Switching

위의 문제점을 해결하기 위한 방법이 바로 Context Switching입니다.

컨텍스트 스위칭은 앞서 확인했던 HW자원의 공유로 인한 데이터 무결성이 깨지는 상황을 완전히 방지하기 위한 목적으로 사용할 수 있습니다.
우선 문제를 해결하려면 HW 레지스터 정보를 메모리 공간에 복제시켜둘 필요가 있습니다.
제어권이 넘어갈 때, 메모리 정보를 저장해두었다가 제어권이 돌아올 때 저장했던 메모리 정도를 꺼내서 다시 HW에 설정합니다.
위의 메커니즘을 기반으로 앞서 살펴봤던 1 + 1, 3 + 7 문제를 살펴봅시다.
```
  movl %ecx, $0x1    # 1
  movl %edx, $0x1    # 2
  add %ecx, %edx     # 3
        
  movl %eax, $0x3    # 4
  movl %edx, $0x7    # 5
  add %eax, %edx     # 6
```
동일하게 A 프로세스가 1번 2번을 실행합니다.
ecx와 edx에는 숫자 1이 기록됩니다.
제어권이 넘어갈 떄 현재 레지스터 상태를 메모리에 저장합니다.

동일하게 B 프로세스가 4번 5번을 실행합니다.
eax는 3, edx는 7이 기록됩니다.
제어권이 넘어갈 때 현재 레지스터 상태를 메모리에 저장합니다.

제어권을 넘겨 받은 A 프로세스가 메모리에서 HW 레지스터 상태를 복원합니다.
이후 3번 작업을 진행하면 1 + 1을 온전히 유지할 수 있게 됩니다.

이와 같이 HW 레지스터 정보를 메모리에 저장하고 복원하는 과정 그 자체를 Context Switching 이라고 합니다.
OS Scheduler에서 진행하면 Context Switching, 프로세스에서 진행하면 mutations

Controller

view에 serializer가 필요한 이유

여러 라우터에서 데이터가 들어올 수 있기 때문에 그 데이터들를 일단 수집해야함

MySQL

권한 이전

// 계정에게 테이블의 모든 권한을 준다
grant all privileges on 테이블이름 to '계정명'@'localhost';

root를 사용하지 않는 이유?

root를 직접적으로 사용하면 보안에 취약함

DDD

자동화를 많이 하는 작업일수록 DDD가 유리함

불필요한 Domain이 없기 때문

Agile process vs Waterfall design

장단점 비교

장점
1. Agile process
  - 잘 모르는 새로운 작업을 할 때 높은 효율성
2. Waterfall design
  - 기존에 해왔던 작업을 재탕하는 경우 높은 효율성
  - 단발성 단순 작업들이 반복된다면 매우 효과적
단점
1. Agile process
  - 초반 구축 비용이 꽤 들어감(개발 문화, 사람들의 인식, 커뮤니티, 협업 환경, 개발 방법론 등)
    - 그렇기 때문에 단발성으로 프로젝트를 한번만 하고 끝내는 경우 적합하지 않은 것이 사실
    - Ex) 외주 개발의 경우.
2. Waterfall design
  - 정해진 루틴을 무조건 따라가야함
    - 개발하다가 이슈가 발생해서 우회하거나 더 좋은 방향으로 개선이 필요한 경우에도 이를 변경하는 것이 꽤 어려움
      보편적으로 외주 개발이 되는 상황이기 때문에 연계 업체들과의 소통이 필요한 상황이 발생하게 됨
      이 소통 비용이 생각보다 거대해지는 경우가 빈번함
  - 궁극적으로 장기전으로 가는 경우, 생산성이 급격히 하락됨
  - 극 초반에 개발하는 사람수에 비례하여 빠르게 생산성이 증가할 수 있지만
    초반 이후부터는 생산성이 유지되는 수준이다가 점점 생산성이 감소하는 구조로 진행됨

기획 및 설계 단계의 차이점

Agile process
- 부분적인 기획과 설계가 그때 그때 진행되는 것
- 부분적인 기획과 설계가 바로 스크럼(Scrum) 15분 스탠딩 업 회의
- 우선 ‘비즈니스에 어떤 것이 있으면 좋겠다’ 라는 아젠다를 던짐(Backlog)
- Scrum을 진행하면서 Backlog의 정보를 Sprint Term으로 가져옴(주간 작업 일정과 유사) 작업이 하드한 경우 Ex) HW는 격주 간격으로 진행하기도 함
- Sprint Term에서 각자 팀원들이 자신이 하고 싶은 주게를 가져와서 In Progress에 걸게함
- 작업 중 이슈가 발생하여 어떤 작업을 진행하는 사람과 논의가 필요하다면 담장자를 보고 그 작업에 대한 이슈 사항을 같이 논의함
  불필요하게 전직원 회의, 모든 팀 회의 같은 것을 빈번하게 진행할 필요 없음
- In Progress에서 작업이 완료되면 Review에 넣고 PR 진행
- 팀장 혹은 몇몇 리뷰어 역할을 하는 사람들이 들어온 PR을 보고 승인 및 거절
  이 때, 왜 거절했는지에 대한 피드백이 Review에서 진행돼야함
- 승인되면 Done으로 옮김
- 중간에 갑자기 급한 일이 발생하면 작업 내역이 잠시 Blocking 될 수도 잇음
- 괜찮은 아이디어인데 당장 진행은 어려울 것 같다면 Additional Work등으로 빼기도 함
- 프로젝트가 자유분방하게 진행되기 때문에 Agile process에서 중요한 것은 ‘역할과 책임’ 이기도 함
Waterfall design
- 모든 기획과 개발에 필요한 모든 지식 리스트와 모든 자료들을 미리 준비해놓고 가야함
  시장에 대한 빠른 대응이나 시장 진입 속도를 고려하지 않고 있다는 것
- 개발이 진행되면 담당 업무를 배정
  - ‘나’는 담당받은 업무만 처리하면 됨
- 위의 방식대로 진행하기 때문에 중간에 변경이 발생하는 것을 극도로 꺼림 변경이 발생하면 회의를 자주 진행해야하고, 여러 사람들과 관련 업체들을 불러모아야 하기 때문

결 론

처음 시도하는 새로운 작업을 하는 경우 Agile process가 무조건 유리
해왔던 작업의 반복이라면 Waterfall design을 선택
절대적으로 하나가 좋다고 할 수 없고, 상황에 따라 선택해야함
하지만 두 가지 진행 방식이 하나의 팀 내부에 공존하긴 어려움
어떤 프로젝트를 진행하는가에 따라 두 가지 중 하나를 선택할 수 있어야 하며, 그 후엔 일관성 있게 진행하는 것이 중요하다고 판단됨

Queryset
Entity가 없는 경우 controller에서 직접 queryset을 설정할 수 없음
- 그런 경우 basename에 패키지를 지정하여 알려줘야함

Lacked

시간이 부족해..

Longed for

끝까지 포기만 하지 말자!!

SKN AI Camp, Remind

This post is licensed under CC BY 4.0 by the author.