Post

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

Posted
By J213h
21 min read

SK Networks AI Camp

Main image

Weekly 회고 - 5주차

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

:thumbsup:Liked

6월 첫째 주 회고록입니다! 첫 회고록 작성할 때는 이렇게 시간이 빨리 갈거라고 생각 못했었는데.. 어느 덧 캠프에 참여한 지 5주나 지났네요! 남은 기간도 열심히 해서 좋은 결과 만들 수 있도록 하겠습니다!:grin:
이번 주에 좋았던 점은 강의의 진행 방식이 바뀌었다는 것입니다. 정확히 말하자면 강의에서 코드를 작성할 때, 어떤 것을 중요하게 생각할 지가 바뀌었다는 의미입니다. 이것 또한 이해가 안되시나요? 충분히 그럴 수 있습니다.
강의가 현재 지향하는 것은 객체 지향적이라는 것입니다. 객체 지향적인 코드 작성 방법을 좋은 점에 작성한 이유는 코드를 이해하기가 수월하기 때문입니다. 객체 지향적인 코드에서는 추상화를 이용하는데 추상화는 그 객체가 어떤 동작을 하는지 이해하기 쉽게 해줍니다.
또한 캡슐화를 사용하여 소프트웨어의 유지 보수 및 확장을 용이하게 하고 상속을 활용하여 메모리 효율을 높이는 등의 장점이 존재합니다. 이러한 장점들 덕분에 객체 지향적인 코드 작성 방법을 익힌다면 실무에서도 유용하게 사용할 수 있을 것이라고 판단하여 좋은 점에 적어보았습니다!
두 번째로 좋은 점은 Agile Process를 도입하였다는 것입니다. Agile Board를 활용하여 Backlog를 작성하며 개발을 진행하면 팀 단위 작업에서 유용하다고 생각이 되었고, 개인 프로젝트를 진행할 때에도 Github commit이나 버전 관리를 보다 깔끔하게 정리할 수 있다고 생각되어서 좋다고 판단하였습니다.

:books:Learned

강의에서 중요하게 생각하는 것이 바뀌어서 새로운 내용들을 많이 배웠기 때문에 하나하나 설명하기 보단 하루하루 정리했던 내용들을 여기에 작성해보고자 합니다.

Package 관리에 대해

Git commit 관점에서

Git에 commit할 땐, 내가 관심있고 주요하게 보는 것이 어떤 것인지
생각해야한다.

즉, Dice와 Player라는 패키지가 있다고 하면 두 가지 패키지는 한번에 작성되었더라도, 따로따로 commit되는 것이 맞다는 의미이다.

Git pull request 관점에서

각자 작업을 진행하고 pull request를 할 때,
팀장 또는 관리자가 request 요청한 commit를 보고
수정할 부분이 있는지 지금 당장 적용 가능한지 확인해야한다.
수정할 부분이 있다면 그 부분을 언급하고 request deny 하고,
당장 적용 가능하다면 merge request한다.

당장 적용 가능했다면 agenda를 Done으로 옮기고,
그것을 당장 적용할 여건이 되지 않는다면 Additional work로 옮겨서
여유 있을 때 추가로 작업할 수 있도록 관리한다.

Setter 관점에서

Setter는 가급적 지향되는 것이 좋다.

한번 설정된 값을 바꿔야하는 기능이 꼭 필요한 것이 아니라면
이미 설정된 값을 변경하는 메서드는 구현하지 않도록 하자.

그렇다면 처음에 값을 설정할 때는 어떻게 해야할까?
__init__ 으로 생성될 때 값을 할당하도록 하자.

Backlog
Backlog 작성 요령

how_to_write_Backlog

Top-down

큰 문제(대략적인 아이디어)를 제시하고 그 후에 작은 문제(세부 사항)를
해결해 나가는 방법

일반적으로 비즈니스는 이렇게 진행된다.

Bottom-up

작은 문제에서 시작해서 큰 문제로 나아가는 방법

Agenda
Agenda 작성 요령
  1. 주체를 명확하게 작성 할 것
Entity
Entity 작성 요령
  1. Entity에서는 어떠한 logic을 처리하는 코드를 작성하지 말자.
    Entity에는 오직 Data만 배치하는 것이 바람직하다.

    Dice 패키지라면 Entity에는 Dice만,
    Player 패키지라면 Entity에는 Player만 존재하도록 한다는 의미이다.

  2. Entity에는 get, set정도만 사용하도록 한다.

    하지만 setter는 가급적 지향해야 하기에,
    그 기능을 구현하는 데 setter가 꼭 필요한 지 고민해봐야한다.

  3. 만약 어떤 객체가 스스로 액션(행동)을 할 수 없는 경우엔
    그 액션을 Repository 또는 Service에 구현하도록 한다.
Server & Client 
현재 우리 관점에서 Server는 django 입니다.
그냥 웹 브라우저를 사용해도 되지만 UI도 필요합니다.
우리는 최소 비용, 최대 효과를 위해 Vue를 사용할 것입니다.
Vue를 사용하는 이유
  1. 러닝 커브가 짧음
  2. React로 전환하는 비용이 크지 않음
라우터가 여러 개 필요한 이유?
  1. 병목 현상을 대비하기 위함
  2. 자연 재해 등의 불의의 사고에 대응하기 위함
Server / Client 구조에서 가장 중요한 것

클라이언트가 요청을 보내면 서버는 응답함
응답 자체가 복잡하거나 이해 관계가 복잡할 경우 특정 비용을 지불할 수도 있다.

localhost:8000 의 의미
  • localhost : 127.0.0.1과 동일한 의미를 가집니다.
  • 8000 : 서비스 포트 번호
    • 서비스 포트 번호란? 서비스를 특정시켜주기 위한 번호
    • Ex) 3306(MySQL), 80(HTTP), 443(HTTPS)
Django

Django도 JPA와 같이 DB 자동 관리를 지원함
Java에서의 @Entity == Django에서의 django.db.models.Model
AutoField는 autoincrement
CharField는 varchar
TextField는 긴 문자, 즉 길이 제한이 애매할 때 사용

1
2

python3 manage.py make migrations # 변경 사항 확인
python3 manage.py make migrate # 위의 변경 사항을 토대로 변경 진행
controller

정석 방법은 Singleton을 구성하는 것
하지만 django가 알아서 구성해주기 때문에 views.py만 옮겨주면 된다.

Backlog
Backlog의 요소
  1. Success criteria
    • 이 부분에는 해당 Backlog의 성공 조건 및 어떤 과업을 달성해야
      성공으로 판정할 것인지 그 기준을 작성합니다.
    • 특히 다른 사람들과 함께 협업이 필요한 상황이라면
      여기서 성공 기준을 어떻게 잡아서 그것을
      ‘모두와 공유하는 공통의 목표로 만들 것인지’ 가 매우 중요합니다.
    • 성공 기준을 작성하는 시점 또한 Backlog 시점입니다.
  2. To-do
    • 어떤 성공 기준을 잡았으므로 이 성공 기준을 달성하기 위해
      어떤 작업들이 필요한지 리스트를 열거합니다.
    • 이 부분을 또 세부 사항으로 가득 채우면 안됩니다.

      ‘repository 개발, service 개발, controller 개발, entity 설계’
      이러면 안됩니다.

  • 성공 기준을 달성하기 위해 필요한 작은 덩어리 I
  • 성공 기준을 달성하기 위해 필요한 작은 덩어리 II
  1. Review
    • Status 관점에서는 Review 시점에 작성하게 됩니다.
    • 경우에 따라 자가 리뷰를 할 수도 있습니다(상황이 여의치 않거나 어쩔 수 없을 때)
    • 경우에 따라 팀장님이 진행하게 됩니다.
      (사실 팀장님이 이런 부분을 어느정도 신경 써 줄 수 있으면 좋긴합니다)
  2. Issue
    • 개발을 진행하면서 발생하는 이유 리스트들을 여기에 정리합니다.
      추후 포트폴리오 및 기술 포트폴리오를 작성하기 위해 필요한 작업입니다.
      나중에 가서 뭐 했었는지, 어떤 이슈가 있었는지
      기억을 못하거나 정보가 누락되는 문제가 있습니다.

      케이스 스터디1
      케이스 스터디2

    • Status 상황에서는 In Progress 부분에서 보편적으로 작성하게 됩니다. 혹은 팀장님이 PR에 대한 승인을 할 것인지 말 것인지 결정 할 때 작성하기도 합니다.
      즉, Review 상황에서도 작성될 수 있습니다.
    • 아주 간혹 Done 상황에서 예상하지 못한 이슈가 발생할 경우가 있는데
      이런 경우에도 작성 할 수 있습니다. 이 케이스는 문제가 없다 판단하였지만 의도치 않은 문제가 발생하는 경우입니다.
      (발생하면 제일 머리 아픈 부분 중 하나)
    • 부가적으로 상황에 대한 설명을 면접에서 사용할 수도 있기 때문에
      정리해두면 여러모로 유용합니다.
    • 또한 주변 사람들과 정보가 공유되기 때문에 빠른 속도로
      문제에 대응할 수 있습니다.
Backlog 작성법
  1. Domain을 작성할 때 다른 Domain와의 결합을 고려하지 않습니다.
    하나의 Domain의 기능과 역할에 집중하여 작성합니다.
    코드를 작성할 때도 그 기능과 역할을 하는 코드만 작성해야합니다.
Domain Initializer

Domain Initializer는 프로젝트가 끝날 때까지 계속 업데이트가 되는 항목입니다.
따라서 프로젝트 완료까지 Done이 되는 일이 없습니다.
만약 변경할 사항이 있다면 fixed 태그를 사용해서 팀원들에게 변경을 알려주어야 합니다.
이렇게 계속 업데이트가 되는 항목은 Review에 배치하도록 합니다.

Agile Board
Agile Board 작성법
  1. 코드에서 쓸모없는 부분을 제거하거나 변경할 때 chore 태그를 사용합니다.
Frontend
axios

관련 링크

export

외부로 내보내는 것
C에서의 구조체(Struct)

boardModule.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

import { BoardState } from "./states"

export interface BoardModule {
    // namespaced가 true가 되면 앞서 *.vue 코드에서 살펴봤듯이
    // 아래와 같은 문법이 허용됩니다.
    // const boardModule = 'boardModule'
    // ...mapState(boardModule, ['boards'])
    // 즉 boardModule 자체를 위와 같이 참조할 수 있다는 의미입니다.
    namespaced: true
    state: BoardState
    actions: boardActions
    mutatios: BoardMutations
}

const boardModule: BoardModule = {
    namespaced: true,
    state,
    actions,
    mutations,
}

파이썬에서 Singleton 객체 만드는 것과 유사함

env

궁극적으로 env를 작성해야됨. WHY?

AWS에 올리기 위함
정확히는 AWS에 올릴 때 IP를 감추기 위함

:face_with_spiral_eyes:Lacked

이번 주동안 스스로 느낀 부족한 점은 ‘이해도’ 입니다. 아무래도 새로 배우는 내용이 많고 여태까지 작성해왔던 코드 작성 방법이랑 결이 다르다보니 왜 이렇게 작성해야하는지, 작성한 코드를 어떻게 수정해야 더 깔끔한 코드가 될 지와 같은 고민이 많습니다. 혼자 생각하고 작성했을 때 “이정도면 나쁘지않은데?” 와 같은 생각을 하곤했는데, 강사님께서 코드 리뷰 해주실 때 피드백을 들어보면 부족한 부분이 많았구나 라는 생각이 듭니다. 그래도 항상 안한 것보단 어떻게든 완성한 게 중요하다 라고 말씀해주셔서 꾸준히 노력해야겠다는 생각이 듭니다!
부족한 부분을 채우기 위해서 열심히 과제를 해야함을 물론이고, 이미 제출했던 과제를 어떻게 하면 더 객체 지향적으로 작성할 수 있을지 고민해보는 과정을 거치고자 합니다. 또한, 복습 스터디를 적극적으로 이용하여 모르는 내용이나 부족한 부분을 채울 수 있도록 하겠습니다.:fire:
추가로 제 코드에 대한 강사님의 의견을 정리한 내용은 간략하게 적어보도록 하겠습니다.

Code Review - 1

코드 리뷰 링크

  1. Setter issue 존재
    • 생성자 부분의 수정이 필요할 것
  2. Dice와 Player가 서로 연결되어 있음
    • 결합성을 낮춘다고 생각
Code Review - 2

코드 리뷰 링크

핵심 키워드: 모호성
  1. 함수의 이름이 함수의 동작을 정확히 설명하지 못함
    • getProductList가 list를 받아오는 것이 아니라 list에 상품을 등록하는 registerProductList의 역할을 하고 있음
      • 협업 시, 잘못된 함수 이름은 팀원으로 하여금 잘못된 함수를 가져다 사용하게 합니다.
  2. Backlog의 이름이 한 가지 동작에 집중하지 않고 두 가지 동작을 설명하고자 함
    • Product 리스트를 생성하고 출력할 수 있습니다. [THIRD-EXER-1] 라고 두 가지 행동을 설명함
      • 모호성이 있는 코드를 작성할 확률이 높습니다.
  3. To-do에 너무 세부사항이 많이 들어간 부분이 존재함
    • 첫 번째의 경우, Success Criteria에 배치되는 것이 조금 더 좋습니다. (그렇지만 이것도 그렇게 좋은 것은 아닙니다.)

    • 두 번째, 세 번째의 경우엔 너무 세부적인 사항입니다.

:thought_balloon:Longed for

솔직히 강의의 진행 속도가 다소 빠르다는 생각을 한 적도 있습니다. 하지만 정해진 시간동안 최대의 효율을 뽑아내기 위해서라고 한다면, 강의 진행 속도의 문제가 아니라 제 스스로 공부하는 데에 시간을 덜 투자하는 것이 아닐까 라는 생각을 했습니다.
그래서 결과적으로 강의에서 바라는 점은 지금처럼 강의를 열심히 진행해주셨으면 하는 것이고, 스스로에게 바라는 점은 조금 힘들고 피곤하겠지만 조금만 더 악착같이 버텨보자 라는 것입니다!
최근에 바뀐 강의 방식을 쫓아가느라 캠퍼스에 늦게까지 남아있는 경우가 많아서 수면 시간이 부족해지고 있습니다.:sob:
그래도 포기하지 않고 노력한다면 언젠간 새로운 방식에 적응해서 피곤하지 않아도 잘 할 수 있는 때가 올 것이라고 믿습니다.

hard-days

SKN AI Camp, Remind
SKN AI Camp SK네트웍스 Family AI 캠프 회고 Weekly 회고
This post is licensed under CC BY 4.0 by the author.