tmdqls2257/gaja

📚 STACKS

client

---

server

gaja's Issues

[Sample] Dev-Log Template

오늘은 어떻게 프로젝트에 기여했나요?

• 작성해주세요.

오늘의 프로젝트에서 힘든 점은 무엇인가요?

• 작성해주세요.

function write () {
  console.log('Write your code here');
}

내일은 프로젝트에 기여하기 위해 무엇을 해야 하나요?

• Todo 형식입니다.
• 작성해주세요.

SR 기획

[Front & Back] 인턴십 탭

• API 호출
• 리스트업

[Sample] KPT Retrospect Template

팀원 중 한 분이 작성해주세요.
Keep, Problem 항목에 대해서 매주 정기적인 날에 회고를 진행하여 기록하고, 그것을 기반으로 Try (Action Items) 이슈를 생성해주세요.

Keep (유지할 항목)

Problem (문제라고 생각하는 항목)

Try (Action Items)

• Todo 형식으로 작성해주세요.
• Todo 형식으로 작성해주세요.
• Todo 형식으로 작성해주세요.

[Back] 에러 처리

• 에러 코드 전송
• Status 관리
• 리디렉션 처리

[KPT] First Project (정윤석)

Keep (유지할 항목)

• 커뮤니케이션을 할 때의 텐션을 향후에도 유지해야 할 것 같습니다.
• 다양한 경우의 수를 대입하여 에러 혹은 버그가 발생하는 부분을 잡아내는 자세를 유지할 필요가 있습니다.
• 건강 관리를 지속해야할 것 같습니다.
  비록 체력 관리에는 실패하여 피곤함은 있었지만, 아팠던 적은 없습니다.
  이 부분을 꾸준히 유지할 수 있도록 해야합니다.

Problem (문제라고 생각하는 항목)

• 다양한 스택들의 작동 원리나 사용법에 대해 아직 미숙한 부분이 많습니다.
• 시간 배분을 효율적으로 하지 못한 것 같습니다.
  원하는 기능 구현은 많은데, 그 기능들에 시간을 적절하게 배분하지 못하여 구현하지 못한 기능들이 있습니다.
• 시간 배분을 효율적으로 못하다보니 체력 관리를 잘하지 못한 것 같습니다.
  시간이 지날수록 피로가 누적되어 그 다음날에 작업 속도가 상대적으로 많이 떨어진다는 것을 경험했습니다.
• 배포를 시도해보지 못한 부분이 아쉽습니다.
• 기능이 세분화되지 않았다보니 하나의 기능에 대해 Front 와 Back 간의 의견차가 있었습니다.
  SR 단계에서 세분화를 진행하거나 혹은 개발 과정에서 틈틈이 진행 현황, 에러 등을 공유해야할 것 같습니다.
• API 호출에 대해 가볍게 생각했던 부분이 문제였습니다.
  단순하게 데이터를 호출하고, 리스트업하면 되겠다는 안일한 생각을 가졌습니다만
  리스트업을 하는 함수에서도 실수를 하였고, 호출 횟수에 제한이 있다는 사실도 이후에 알게 되었습니다.
  이 부분에 대해서는 담당 Engineer 님이 추천해주셨듯, DB 에 저장하는 방식을 시도해봐야할 것 같습니다.

Review (프로젝트를 통해 느낀점)

• 코드스테이츠를 통해 스택들의 활용법에 대해 배우고 Sprint 의 Bareminimum Reqiurements 에서도 사용해보았으나,
  정해진 가이드라인이 아닌 제가 원하는 방식으로 구현하려고 하니 생각보다 쉽지 않았습니다.
  프로젝트 팀원과 구글링을 통해 해결하긴 했으나, 제가 많이 부족하다는 것을 뼈저리게 깨달은 것 같습니다.
• 이전까지는 Client 와 Server 모두를 직접 만지면서 Pair Programming 을 통해 함께 구현했지만,
  이번 Project 에서는 각자의 지향성에 따라 Client / Server 로 분업되었으며,
  이후에 서로 작업물을 공유하였을 때 각기 다른 생각으로 구현했다는 것을 알게 되었습니다.
  ('회원정보수정' 에 대해 Front 는 비밀번호 수정을, Back 은 비밀번호/아이디/이름 수정을 생각하고 구현하였습니다.)
  Client 와 Server 를 합치는 과정에서 아이디는 수정이 불가능해야하고, 우선은 비밀번호 변경만 구현하도록 합의를 하였습니다.
  이러한 과정을 통해 Team Project 를 진행할 때 사람마다 생각이 얼마나 다른지, 그렇기에 의사소통이 얼마나 중요한지 깨달았습니다.
• 시간분배가 정말 중요한 것 같습니다.
  A, B, C 기능을 구현한다고 가정했을 때, 마냥 A 가 구현되면 B 를 구현하겠다는 계획은 B, C 기능 구현을 미룰 뿐이었습니다.
  구체적으로 A 기능을 언제까지, 그리고 B 기능과 C 기능을 언제까지 어떻게 구현할 것인지에 대한 구체적인 계획을 세우는 것이
  기능 구현에 정말 큰 영향을 미친다는 것을 알게 되었습니다.

Todo & Not Todo 작성하기

[Back] Schema 작성

Wiki 기본 구성

[Front] 검색 기능

[Front] 페이지 구분

[KPT] First Project (윤녹두)

😃 Keep (유지할 항목)

• 계속 막히는 부분도 많았고 컴퓨터 끄고 그냥 자고 싶다고 생각한 적도 많았지만 어찌저찌 계속 이어갈 수 있었던 지속력,
• 하나 해결하면 또 모르는 부분이 계속 튀어나왔는데 그때마다 우선 먼저 검색해보고 꾸준히 관련 정보를 찾으려고 한 탐구력,
• 마지막으로힘들었지만 나름 웃어가면서 진행한 프로젝트 분위기 등 입니다.

🥲 Problem (문제라고 생각하는 항목)

• 아무리 잘 만들어도 배포가 않되면 아무것도 안됩니다. 저희는 배포를 어느정도 프로젝트를 진행하고 나서 배포를 구현해보자는 잘못된 판단을 하였고, 그래서 마지막에 가서야 발견한 에러는 코드 전체를 뒤엎어야 할 정도로 큰 것이 되어버렸습니다. 따라서 파이널때는 SR이 끝나면 가장 먼저 배포 환경부터 구현할 생각입니다. (크루분의 조언은 서버, 클라이언트 배포환경에서 Hello World 먼저 띄우는 것을 목표로 하기!)

• 외부 API에서 받아온 내용을 따로 저장하지 않고 매 렌더링 시마다 호출을 하는 식으로 구현하였는데, 이 또한 좋지 못한 판단이었습니다. 저희가 사용한 사람인 api 일일 요청횟수가 100회로 제한이 있었는데, 테스트 할때마다 매번 호출을 해 대니 일일 요청량을 다 써버려 더이상 요청을 못 받아오는 경우가 많았습니다. 따라서 한번 받아온다면 어딘가에 저장하여서 불필요한 호출을 줄이는 것이 좋을 것입니다.

• SR단계에서 기획했던 대다수의 기능들을 실제로는 구현하지 못하였는데, 이 또한 이상은 크지만 현실적인 부분을 고려하지 못한 판단을 했기에 그런 것 같습니다.. 마지막에 가서 제가 좀 힘이 빠진 것도 있지만 정말 안타깝습니다ㅜㅜ

• SR 에서 무.조.건 API 문서, 목업(실제랑 가까운 디자인)을 만들어 놓고 가야합니다. 저희는 SR은 기본적인 것만 작성하고 이후 코드 작성하면서 조금씩 작성하거나 수정해나가자는 생각을 했는데 이는 정말정말 좋지못한 생각이었습니다. 코드는 병합하거나 Pull받아올 때마다 충돌이 나기 일쑤고 의견충돌도 잦았습니다. 따라서 무.조.건. 확실히 하고 가야 합니다!!!

• SR단계 후부터는 백엔드 따로, 프론트 따로 해서 중간중간의 발생한 에러를 실시간으로 공유하지 못하였습니다. 선배 기수들의 team Rule을 보면 밥 먹는 시간을 제외하고는 항상 zoom 또는 meet에 참여하여 모각코 형식으로 프로젝트를 진행한 것 같습니다. 그렇게 하신분들의 프로젝트 결과물은 너무나도 멋지고 훌륭했구요. 이러한 점을 본받아 다음에는 좀더 까다로운 팀룰을 정해야 할 것 같습니다.

🧐 느낀점

첫 프로젝트라고 해도 부족한 점이 너무 많았습니다...
비록 배포도 실패했고 성공적으로 마무리하지는 못했지만 지난 섹션 1,2,3 때 배운 부분을 전체적으로 복습할 수 있었던 좋은 기회였습니다.
다음 파이널 프로젝트 때에는 가장 먼저 배포환경부터 구성해야겠습니다. 명심! 🔔

[KPT] First Project (이민호)

팀원 중 한 분이 작성해주세요.
Keep, Problem 항목에 대해서 매주 정기적인 날에 회고를 진행하여 기록하고, 그것을 기반으로 Try (Action Items) 이슈를 생성해주세요.

Keep (유지할 항목)

• 체력 관리, 시간 관리
• 프로젝트 기간동안이라도 잠자기 전까지 프로젝트에 집중할것
• 적당한 혼자 해결시간을 가지고 안되면 팀원들에게 도움 요청하기 (너무 오랜시간 혼자 해결하려고 하지 말기)

Problem (문제라고 생각하는 항목)

• 배포는 마지막에 하는거라고 알고었지만 배포 환경은 미리 구현했어야 한다는것을 마지막에 알았습니다.
• 너무 api에 의존한다는 피드백을 받았지만 시간관계상 데이터테이블은 구현못한점
• 백엔드 코드를 구현하면서 완전히 백지장에서 시작해보지 못한점 ( token 스프린트를 보면서 구현한점)
• 코드가 복잡한점 (같은기능은 따로 구현해서 가져다 쓰는 방식을 사용하지 못한점 등등) ex) 토큰의 유무 response

느낀점

팀 프로젝트는 경험할수 있는 기회가 있어서 다행이다 라는 생각이 들고,
프로젝트를 진행하면서 아직 많이 부족하다고 느끼며 복습할수 있는 좋은 기회였다고 생각합니다.
first project를 기반으로 final project는 부족한점을 개선하며 발전하도록 노력해보겠습니다.

[Feedback] SR Fist Feedback To-do List

안녕하세요 Junior팀 여러분! 😄
코드스테이츠 교육 엔지니어 허재혁입니다.

보내주신 SR 기획 잘 보았습니다. 고생 많으셨습니다!
SR피드백 문서를 확인하시고 Notion 댓글 기능을 활용해 의견을 남겨주세요!

저도 Junior팀에 궁금한 점을 피드백 문서에 적어 두었으니
질문에 답변을 달아주시면 감사하겠습니다.

Idea

• 대학생들의 바쁜 생활, 부족한 시간에 도움을 주기 위한 따뜻한 아이디어라 기대됩니다. 👍
  또한, 퍼스트 프로젝트에 적합한 CRUD를 만들어 볼 수 있는 아이디어라고 생각합니다.
• 장학금 정보 제공에 관한 서비스는 Dreamspon(https://www.dreamspon.com/)이 있습니다.
  이 서비스와의 차이점은 어떤점이 있는지 고민해보며 기능을 구상한다면 좋은 학습 기회가 될 것 같습니다.
  Dreamspon과 GAJA 서비스의 차별점, 강점은 무엇인지 생각해 볼 필요가 있습니다.

• GAJA 서비스만의 차별점 및 강점 찾기

Home

• About에 남겨주신 문구는 감성적으로 멋집니다. 하지만 포트폴리오를 위한 퍼스트 프로젝트에서 감성적인 문구와 별개로 어떤 기획을 통해서 어떤 서비스를 제공하는지 개조식으로 적는다면 채용담당자가 프로젝트를 파악하기 좋습니다.

  모범 사례 1 https://github.com/codestates/art-ground/wiki

  모범 사례 2 https://github.com/codestates/devzine/wiki

• Wiki Home 에 기능적 측면에 대한 자세한 설명 추가

Team Rule

• 팀 프로젝트를 진행하다 보면 의사결정을 해야 하는 상황이 자주 있습니다.
  의사결정에 관한 룰을 추가해주시면 좋을 것 같습니다.
  ex) 다수결, 동률일 때 팀장이 결정, 사다리타기 등
• 휴식 시간, 주말 및 정규시간 이외의 규칙을 정하는 것도 갈등을 예방할 수 있습니다.

• Junior 팀의 의사결정에 관한 Team Rule 구체화

Requirements

• 요구 사항을 기능별로 잘 적어주셨습니다. 각 기능을 구현하기 위해 어떤 작업을 할지 적어주면 좋습니다.

  모범 사례 https://github.com/codestates/devzine/wiki/Requirements

• 각 기능에 대한 조금 더 세부적인 작업을 명시

DB schema

• 스크린샷으론 테이블들 간의 관계 파악이 어렵습니다 작성하신 DB스키마 링크도 알려주세요
• intern 테이블은 join 된 테이블이 없는데 즐겨찾기 기능 장학금만 가능하고 인턴채용 현황은 즐겨찾기 할수 없는 것인가요?
• user 테이블의 id와 license 테이블의 userid는 다른것인가요?

• DB Schema 정리
• DB Schema 에 대한 url 도 첨부하여 작성

Prototype & Wireframe

• 작성해주신 Prototype과 Wireframe으로는 웹인지, 모바일 앱인지, 반응형 웹인지 파악하기 어렵습니다.
  강요는 아니지만 더미데이터를 이용해서 여러분의 프로젝트 화면을 스크린샷으로 찍은 것처럼 Prototype을 만든다면 프로젝트 진행을 하는데 도움이 됩니다.
  (Miro 나 Figma 등의 툴로 제작할 수 있습니다.)

  모범사례 https://github.com/codestates/devzine/wiki/Prototype

• 프론트엔드 포지션 분들은 Figma 등의 툴을 이용해 UI 디자인이 완료되고 난 후 코드작업을 진행하는걸 추천드립니다. UI 디자인을 완료하지 않은 상태로 코드작업에 들어가면 협업 과정에서 디자인이 변경되고 작업량이 많아질 수있습니다.

• Prototype 과 Wireframe 을 직관적으로 제작

API

• 회원탈퇴 Delete 요청에 Body가 있습니다. 이는 RESTful 하지 못한 API작성입니다.
  Delete 메서드에 body가 있다면 요청이 거절될 수도 있습니다.
• Responses를 자세히 작성해 주셔야 개발과정에서 에러를 파악할 수 있습니다.
• 데이터를 넘겨 받아와야 하는경우 데이터가 어떤식으로 들어오는지 구체적인 예시를 넣어주시는게 좋습니다.
• 즐겨찾기와 자격증 관련, Delete API가 없습니다.
• 로그인 요청시 토큰 발급은 이루어지나요?
• 잘 작성된 API만으로 프론트엔드와 백엔드의 커뮤니케이션이 될 수 있습니다.
  유어클래스 섹션2 [HTTP/네트워크] 실습 파트를 참고해 주세요.

• RESTful 한 API로 재작성 및 각 메서드에 대한 재검토
• 자격증 기능에 Delete API 추가
  (* 즐겨찾기는 Advanced로 수정하였습니다. )
• 로그인 요청시 토큰 발급 검토

Task card

• 현재 이슈카드 템플릿이 생성되어 있지 않은것으로 보입니다.
  깃헙 이슈 탭안에 Task card 템플릿, dev-log , 에러 핸들링 로그, KPT 회고 템플릿을 생성해 주세요.
• 핵심 기능의 개발과정과 부족하다고 느낀점, 차후 개선점에 대한 생각들을 모아 둘 수 있는 dev log도 기록하는 것을 추천드립니다.

• GAJA 의 issues 메뉴에 각 주제에 대한 템플릿 작성하기

엔지니어의 의견이 반드시 정답은 아닙니다.
피드백을 통해 전달드린 의견은 Junior팀에서 검토한 후 반영해 주세요! 👍

코드스테이츠 교육엔지니어 허재혁 드림

[KPT] 1주차 수요일

Keep (유지할 항목)

• 서로 팀을 결성한 지 2일밖에 안 됬지만 서로 농담도 주고받을 정도의 분위기
• 현재 SR을 계속 진행 중인데 팀원들의 집중력
• 피드백을 적극적으로 꺼내는 열린 환경 (좋은 커뮤니케이션)
• 팀장님의 결정력(리더쉽), 행동력, 실행속도
• 각 팀원들간의 배려

Problem (문제라고 생각하는 항목)

• (윤녹두 개인 문제) 정해진 일과 시간이 끝나면 약간 풀어지는 거 같다. 지금의 난 팀으로 움직이고, 내가 대충하면 팀원들이 피해를 본다는 점을 잊지 말자.
• 데이터베이스를 위해 scheme을 구상하는 단계에서 많이 막힌 것 같다. 역시 공부는 끝이 없다.
• 지금까지 배운 내용들 중에서 완전히 내것으로 만들지 못하고 피상적으로만 아는 부분들이 있었다.

Try (Action Items)

• 컨디션, 건강 관리 잘하기
• 하루에 한번씩 DevLog를 issues 란에 작성하기 (한줄이라도?)
• 지금까지 배운 내용들 훝어보기

[Sample] Error Handling Log Template

어떤 에러인가요?

• 에러 메시지

$ 터미널의 에러 코드를 여기 넣어주세요.

에러 핸들링 방법

• 핸들링 방법에 대해서 간단하게 기록해보세요.

// 코드가 들어가도 좋아요!

에러 핸들링을 위해 참고한 레퍼런스 링크

링크

[Front & Back] 회원 기능

• 로그인
• 로그아웃
• 회원가입
• 회원탈퇴

[Sample] Issue Task Card Template

ISSUE

• Group: client, server, sr
• Type: bug, feature, delete
• Detail: fix actions from client redux

TODO

• Job1
• Job2
• Job3

Estimated time

Pick one

0.5h

1h

1.5h

2h

2.5h

3h

Labels

• Estimated time: E: 1h
• Group : client, server
• Sprint: Sprint__NUMBER__
• Urgency: High, Middle, Low

[Front & Back] 마이페이지 구현

• 사이드바
• 개인정보 수정
• 자격증 기록
• 즐겨찾기 (Advanced)

[KPT] 2주차 목요일

Keep (유지할 항목)

• 정규시간 끝나서도 프로젝트에 계속 임하는 집중력
• 모르는 것은 계속 묻는 점

Problem (문제라고 생각하는 항목)

• 배포를 결국 성공하지 못한게 너무 아쉽다..
• 일부 기능(검색 등)은 포기해야 할 것 같다.

Try (Action Items)

• 건강 챙기기
• 마지막까지 최선을 다하기
• [ ]

[Feedback] SR Second Feedback To-do List

안녕하세요 Junior팀 여러분! 😄
코드스테이츠 교육 엔지니어 허재혁입니다.

수정사항을 잘 반영하여 주셨습니다. 2차 피드백을 준비했습니다.
SR피드백 문서를 확인하시고 Notion 댓글 기능을 활용해 의견을 남겨주세요!

저도 Junior팀에 궁금한 점을 피드백 문서에 적어 두었으니
질문에 답변을 달아주시면 감사하겠습니다.

Idea

• 장학금 정보 제공에 관한 서비스는 Dreamspon(https://www.dreamspon.com/)이 있습니다.
  이 서비스와의 차이점은 어떤점이 있는지 고민해보며 기능을 구상한다면 좋은 학습 기회가 될 것 같습니다.
  Dreamspon과 GAJA 서비스의 차별점, 강점은 무엇인지 생각해 볼 필요가 있습니다.

• GAJA 서비스만의 차별점 및 강점 찾기

Home

• 개조식으로 잘 변경해 주셨습니다.

  모범 사례 1 https://github.com/codestates/art-ground/wiki

  모범 사례 2 https://github.com/codestates/devzine/wiki

Team Rule

• 의사결정에 관한 규칙과 쉬는시간 규칙을 잘 정해주셨습니다

Requirements

• 요구 사항을 기능별로 잘 적어주셨습니다. 장학금 API와 인턴십 API 호출부분이 외부 API를 사용하는지 궁금합니다.

DB schema

• 장학금과, 인턴십에 관한 정보는 외부 API로 받아오나요?
  외부 API를 받아오더라도 매번 새로 요청하는 것은 지나치게 외부 API에 의존하게 됩니다.
  이 점을 참고하여 파이널 프로젝트 때에는 외부 API에 대한 데이터 테이블을 만들어 저장하는 방법을 고려해 보세요.

• DB를 보면 즐겨찾기 기능을 구현할 수 없는데 즐겨찾기 기능 구현 예정은 없나요?

• license는 자격증에 관련된 테이블이고 마이페이지에서 유저의 자격증들을 볼 수 있는 기능으로 보입니다.
  user 1과 자격증 N의 관계로 이런경우 license에 user의 id를 FK로 참조하여 표현할 수 있습니다.
  참고자료 (https://urclass.codestates.com/1d0e1f9a-f7be-4967-8b11-2e47cdba7cdb?playlist=555)

• 장학금, 인턴십 정보를 외부 API로 받아오는지에 대해 답변 댓글로 남기기

• 즐겨찾기 구현에 관한 답변 댓글로 남기기

• License 와 User Id 간의 관계 및 기능 재검토

Prototype & Wireframe

• UI디자인이 깔끔하게 잘 되었네요. 해당 디자인을 기준으로 작업해 주세요

API

• Responses 를 잘 구현해 주셨습니다.
• Rest API 참고자료(https://www.redhat.com/ko/topics/api/what-is-a-rest-api)
• GAJA 서비스와 비슷한 구조의 API 문서입니다. 회원탈퇴, 북마크 기능을 참고해 보세요
  https://rec-fffixing.gitbook.io/webmarker/reference/api-reference/users

Task card

• 현재 이슈카드 템플릿이 생성되어 있지 않은것으로 보입니다.
  (https://urclass.codestates.com/e80664b0-49c5-44f5-9a6a-4a34ed056985?playlist=965)
  해당 유닛을 참고하여 템플릿을 생성해 주세요.

• 이슈카드 템플릿 작성하기

엔지니어의 의견이 반드시 정답은 아닙니다.
피드백을 통해 전달드린 의견은 Junior팀에서 검토한 후 반영해 주세요! 👍

코드스테이츠 교육엔지니어 허재혁 드림

[Back] 외부 API 설정 및 문서화

[Front] 시작페이지 구현

[Front & Back] 장학금 탭

• API 호출
• 리스트업

[Front] 페이지 구성 & Mock-Up 구성

[KPT] First Project (홍승빈)

팀원 중 한 분이 작성해주세요.
Keep, Problem 항목에 대해서 매주 정기적인 날에 회고를 진행하여 기록하고, 그것을 기반으로 Try (Action Items) 이슈를 생성해주세요.

Keep (유지할 항목)

• 체력 관리 건강관리
• 에러를 스스로 해결할 수 있는 능력

Problem (문제라고 생각하는 항목)

• 배포의 실패 이번에는 실패 하였지만 다음에는 꼭 배포까지 할 수 있도록 진행하자
• finalProject에서는 내가 배운 모든 것을 사용할 수 있도록 해야겠다.
• 실시간으로 소통을 많이 하지 않다는 점
• sr을 좀 더 세분화(개인 정보 수정이면 어떠한 개인 정보 수정인지, 버튼을 누가 만들지 등등)

느낀점

배포 실패, 원하는 기능을 전부 구현하지도 못하였지만 백엔드의 전체적인 과정을 이해할 수 있는 좋은 기회였습니다.

[KPT] 2주차 수요일

Keep (유지할 항목)

• 정규시간 끝나고도 계속 작업하는 집중력
• 에러가 수 없이 발생해도 포기하지 않는 점(결국은 해결되더라)
• 자신만 알지 말고 항상 팀원이랑 정보 공유

Problem (문제라고 생각하는 항목)

• 아직 aws pipeline 구축하지 못하였다.
• 클라이언트에서 못 구현한 기능들이 많다(검색, 뷰카드, 모달 등).
• 비슷한 에러를 계속 겪는데 정리를 해놓지 않아 계속 새롭게 검색하는 느낌이 있다.

Try (Action Items)

• 건강 챙기기
• aws pipeline 구축하기
• clients 마무리

[KPT] 2주차 월요일

Keep (유지할 항목)

• 적극적인 의견교환 (정규 시간이 지나더라도 모르는 부분은 열심히 묻는 점)
• 모르는 부분을 넘어가지 않고 검색을 통해 반드시 확인하는 점
• 화상으로 회의를 정기적으로 가지는 점

Problem (문제라고 생각하는 항목)

• (프론트) css에서 좀 모르는 부분이 많은 점.
• (백엔드) accessToken, refreshToken 이 모두 만료되었을때 어떻게 처리할것인지.

Try (Action Items)

• 컨디션, 건강 관리 잘하기
• 하루에 한번씩 DevLog를 issues 란에 작성하기 (한줄이라도?)
• 지금까지 배운 내용들 훝어보기