diff --git a/draft/42seoul_draft/2022-02-01-42sub_born2beroot_result.md b/draft/42seoul_draft/2022-02-01-42sub_born2beroot_result.md
deleted file mode 100644
index f17fe97..0000000
--- a/draft/42seoul_draft/2022-02-01-42sub_born2beroot_result.md
+++ /dev/null
@@ -1,83 +0,0 @@
----
-title: "42Seoul [born2beroot]"
-excerpt: " "
-
-categories:
- - C
-tags:
- - [C, 42Seoul]
-
-toc: true
-toc_sticky: true
-
-date: 2022-02-01
-last_modified_at: 2022-02-01
----
-
-## 평가지 내용
-
-1. 프로젝트 개요
-
-- 가상머신은 어떻게 동작하는가?(가상머신이란?)
- - 가상머신이란 가상으로 구현된 소프트웨어 컴퓨터로 간단하게 컴퓨터안의 다른 컴퓨터가 존재한다고 생각한다. 하이퍼바이저 기술을 통해서 동작하며 물리적컴퓨터에서 동작한다고 물리적 컴퓨터인것은 아니며 가상으로 물리 리소스를 사용하는 것
- 이러한 가상머신을 생성하고 실행하는 것이 하이퍼바이저이며 리소스를 가상으로 지원해준다. '
- 현재는
-- 어떤 운영 시스템을 선택했는지?
-- 가상머신의 목적
-
-- aptitude vs apt
-- AppArmer 설명
-- 모니터링 정보 출력
-
-1. 기본설정
-
-- 처음 실행할 때, 가상머신으로 로그인(root x)
-- 비밀번호가 정책에 맞는지
-- ufw, ssh 실행 확인
-- os확인
-
-3. 사용자
-
-- 평가받는 사용자가 sudo, user42그룹에 속하는지 체크
-- 새로운 유저를 생성한 뒤 정책에 맞는 비밀번호인지 체크하고 설정방법 알려주기
-- 사용자를 추가할 때 비밀번호 양식이 지켜졌는지 설명하고 해당 비밀번호가 왜 유리한지
-- 'evaluating그룹에 속하는지 확인'
-
-4. 호스트명 변경
-
-- 기존 호스트서버명이 (intraID)42를 만족하는지 확인하기
-- 호스트명 변경 후 reboot하여 호스트명 변경 확인하기
-- lsblk로 파티션 확인하고 비교
-- lvm에 대해서 설명하기
-
-5. SUDO
-
-- sudo설치 확인
-- sudo그룹에 새로운 유저를 할당하는 것
-- sudo를 사용하는 이유
-- log내역 확인하기
-
-6. ufw
-
-- 설치 확인 및 동작 체크
-- ufw의 기능
-- ufw활성화 규칙들 나열 4242포트도 보여주기
-- 8080포트를 열어서 새로운 규칙을 추가하기
-- 삭제까지
-
-7. ssh
-
-- 설치 및 동작 체크
-- ssh의 기능과 장점 설명
-- ssh가 4242포트만 사용하는지 확인하기
-- root로 접근이 불가능한지 확인, 새롭게 생성된 유저에 로그인확인
-
-8. Script Monitoring
-
-- 스크립트가 어떻게 동작하는지 확인
-- cron이 무엇인지
-- 10분마다 실행되는 것 왜 그렇게 실행되는지
-
-## 마치며
-
-+ 평가 끝난후 작성
\ No newline at end of file
diff --git a/draft/42seoul_draft/2022-06-21-42sub_minitalk.md b/draft/42seoul_draft/2022-06-21-42sub_minitalk.md
deleted file mode 100644
index 081ee09..0000000
--- a/draft/42seoul_draft/2022-06-21-42sub_minitalk.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: "42Seoul [minitalk]"
-excerpt: " "
-
-categories:
- - C
-tags:
- - [C, 42Seoul]
-
-toc: true
-toc_sticky: true
-
-date: 2022-06-21
-last_modified_at: 2022-06-21
----
-
-## 평가지 내용
-
-
-## dd
-
-
-https://www.joinc.co.kr/w/Site/system_programing/Book_LSP/ch06_Signal
-
-https://github.com/Ahngbeom/42-minitalk
\ No newline at end of file
diff --git a/draft/BRIDGE/Archive/BRIDGE_Archive.md b/draft/BRIDGE/Archive/BRIDGE_Archive.md
deleted file mode 100644
index a188a08..0000000
--- a/draft/BRIDGE/Archive/BRIDGE_Archive.md
+++ /dev/null
@@ -1,133 +0,0 @@
-# BRIDGE_Archive 기획서
-
-# BRIDGE_Archive
-
-브릿지 아카이브란, 브릿지 프로그래머들이 공유하고자 하는 지식을 남겨 도서관을 만드는 장소입니다.
-
-## What?
-
-1. 게임 개발에 관련된 주제를 선택합니다.
-2. 싸이클에 맞게 각자 지정된 날짜에 글을 업로드 합니다.
-3. 다른분들의 글이 올라오면 피드백과 코멘트를 남깁니다.
-
-## Why?
-
-다른 동아리나 프로그래머 지식 아카이브를 보게 되면 수많은 기여자들이 좋은 글을 작성하고 지식을 저장하여 글을 읽고 같이 성장하는 선순환 구조를 가지고 있습니다.
-
-브릿지 DEV조직을 포함하여 브릿지에서 나오는 다양한 유용한 정보를 기록하고자 만들었습니다.
-
-[Example01](https://github.com/Integerous/goQuality-dev-contents)
-[Example02](https://80000coding.oopy.io/)
-
-좋은 글을 작성하는 과정에서 자신이 알고 있는 지식을 정리하고 그것을 남에게 설명하기 위해 짜임새를 가다듬는 과정은 단순한 경험이 아닙니다.
-
-프로젝트에 적용하기 위해 사용법을 알아본 것과 적용하고 그것에 대해 정리하고 기록하는 것에 대한 경험적 차이는 엄청납니다.
-
-따라서 BRIDGE_Archive는 규칙적으로 다른 사람이 작성한 글을 보고 인사이트를 얻고, 피드백을 건네줍니다.
-
-이후 자신의 글을 회고하며 좋은 글을 작성해내는 것을 목표로 합니다.
-
-[좋은 개발 글을 작성하는 법](https://f-lab.kr/blog/developer-blog-tips)
-
-## How?
-
-1. 각자 글을 업로드할 날짜를 선택합니다.
-2. 해당 날짜로부터 글 주제를 고민하고 2주 뒤에 글을 작성하여 업로드합니다.
-3. 2주 단위로 스프린트를 돌립니다.
-4. 참여중인 다른 사람들의 글에 대한 코멘트를 남깁니다.
-5. 자신이 작성한 글에 대한 피드백을 보고 회고합니다.
-
-- 업로드 날짜는 OT날 겹치는 날 없도록 결정합니다.
-- 한 사람마다 2주마다 글을 작성한다고 생각하면 됩니다.
-- 참여중인 다른 사람들의 글의 코멘트엔 되도록 피드백을 위주로 작성합니다.
-- 글 작성은 해당 레포에 해도 좋고 개인 블로그, 카페를 통해 작성하셔도 좋습니다.
-
-## Rule
-
-업로드하는 글은 다음 규칙을 따릅니다.
-
-- 단순한 알고리즘 풀이나 간단한 정보글은 지양합니다.
-- 자신이 어떠한 과정을 거쳐서 문제를 해결하는지 드러내는 글
-- 학습한 내용에 대해서 다른 사람도 이해하기 쉽게 정리한 글
-- 기술에 대한 깊은 고찰이 있는 글
-- 이외에도 본인이 읽고 싶은 글
-
-*꼭 프로그래밍에 국한된 내용이 아닌 게임에 관련된 내용이라면 뭐든지 상관없습니다.*
-
-단순 .md파일이 아닌 카페 글이나 본인 블로그에 글을 작성하여 링크를 걸어주셔도 됩니다.
-
-또한 꼭 스프린트에 탑승하지 않으시고 글을 올려주셔도 됩니다.
-
-참여하시다 불참, 중도 포기하셔도 전혀 불이익 없습니다.
-
-## Q/A
-
-Q. 깃허브에서 자세한 진행방식을 알려주세요.
-A. Project를 활용하여 개인 스프린트를 부여하고 이후 정리된 내용을 README 및 DEV에 반영합니다.
-
-Q. 스터디 종료 일자가 정해져 있나요?
-A. 참여자가 존재하는 한 계속 굴러갈 것 같습니다.
-
-Q. 정기 미팅이 있나요?
-A. 자료 공유나 사담을 위한 디스코드방은 존재하나 회의는 없습니다.
-
-### 이유
-
-최근에 블로그나 제가 작성한 글에 대해 회고를 해보니 영양가 없는 글이 90%을 넘어간다는 사실을 알았습니다.
-
-좋은 개발자로 성장하기엔 글쓰기는 필수적이라고 생각하지만, 단순 글 수를 늘리기 위한 알고리즘 풀이, 이미 널려있는 지식 그대로 작성 등등..
-
-*실제로 트래픽을 뜯어봐도 스파인, 시네머신같이 궁금하거나 작업하면서 얻었던 지식을 나누는 글만 올라가는게 보였습니다.*
-
-그렇다면 좋은 개발 글은 무엇일까요?
-
-지금까지 제 생각은 다음과 같은 글들입니다.
-
--
- - 개발하면서 겪게 되는 문제점들에 대한 분석, 해결과정
- - 또는 더 좋은 방법이나 +a
-- 복잡한 로직을 구현하거나 다룬 내용
--
--
-
-위에 정리된 내용이 필수적인 내용은 아니지만 지키면 좋은 글을 쓸 수 있다고 생각합니다.
-
-저도 좋은 글을 써보고 싶고, 작성된 내용을 기반으로 다른 분들과 이야기 나누고 피드백을 받고 싶습니다.
-
-- 좋지 못한 글: 알고리즘 24번 문제 풀이
- - but 해당 문제에 대한 알고리즘에 대한 깊이 있는 고찰이라면 가능 ex) 24번 문제에 대한 다양한 접근
-- 좋은 글: toy프로젝트를 진행하며 느낀 UniRx의 한계, 오픈소스 쉐이더 코드 분석
-
-스스로 읽어보고 싶은 글과 생각없이 지나가는 글을 나눠봐도 어느정도 분석이 가능해지는 것 같습니다.
-
-그렇다면 프로그래밍 관련 글만 적어야 하느냐?
-
-아닙니다.
-
-게임 로직에 대한 세세한 분석도 좋고, 프로젝트를 진행하며 얻은 교훈도 좋습니다.
-
-주제에 벗어나지 않는 글이라면 누구나 참여 가능합니다.
-
-### 참여하면 좋은 점
-
-정말 간단합니다.
-
-남이 본다는 압박감과 `떠벌리기 효과`의 영향을 받을 수 있습니다.
-
-또한 정기적으로 좋은 글을 작성하는 경험을 할 수 있습니다.
-
-프로젝트 진행 중 필요해진 라이브러리에 대해서 혼자 공부하고 적용하는 것과 적용해보고 그것을 글로 적어 기록하는 것에 경험적 차이는 엄청납니다.
-
-### 카톡 홍보용
-
-안녕하세요 10기 프로그래머 이정안입니다.
-
-이번에 BRIDGE_Archive에서 인원을 모집합니다.
-
-자세한 모집내용, 설명은 아래 링크를 통해서 확인해주시면 됩니다.
-
-많은 관심 부탁드립니다.
-
-(카페에도 올라가 있습니다.)
-
-https://github.com/orgs/BRIDGE-DEV/discussions/15
diff --git a/draft/BRIDGE/Archive/BRIDGE_Archive_OT.md b/draft/BRIDGE/Archive/BRIDGE_Archive_OT.md
deleted file mode 100644
index f91749c..0000000
--- a/draft/BRIDGE/Archive/BRIDGE_Archive_OT.md
+++ /dev/null
@@ -1,53 +0,0 @@
-# BRIDGE_Archive_OT
-
-## 목차
-
-1. BRIDGE Archive 소개
-2. 진행 방식 소개
-3. 요일 선정
-4. 좋은 글 작성에 관한 이야기
-5. Q/A
-
-## 소개
-
-- 나 이름과 기수 등등 어떤 사람인지 소개
-
-다음으로 BRIDGE Archive에 대한 소개 진행
-
-이 때, 화면 공유로 진행
-
-README.md 파일을 보여주며 설명
-
-내가 왜 시작했는지에 대한 이야기도 풀기
-
-- 싸구려 글을 쓰고 있었다.
-- 기억에 남는 지식은 내가 잘 쓴글에서 나온다. (연결 문서)
-- 적어둔 피드백과 결과에 대한 정리
-- 어떤 도전(알을 깨는 행위에 대한 생각)
-- 해봤던 경험 되게 좋은 경험들 위주로
-
-## 진행 방식 소개
-
-Project를 활용해서 진행하는 것 보여주기
-
-이번에 처음 만든 스터디 형식이라 약 1달간 선발대 느낌으로 진행하고 결과가 쌓이면 피드백을 받고 이후 상시 모집으로 전환
-
-2주 사이클에서 가장 중요한 부분 -> 피드백은 필수인 부분을 고지
-
-패널티는 없다 -> 자유의지가 가장 중요한 채찍과 당근의 길이, 멀리 가기 위해 스스로 의지로 하는 부분이 필요함
-
-하지만 사회적인 관계의 압박은 있음 누군가 하면 해야할 것 같고, 이런 부분은 디스코드와 깃헙 연동을 통해 해결할 예정
-
-사용에 제한되는, 깃허브 사용에 어려움 설명하기
-
-## 좋은 글 작성에 관한 이야기
-
-좋은 글에 대한 이야기 디스커션 글 읽으면서 설명하기
-
-## Q/A
-
-질문 받기
-
-## 진행하고 싶은 사람 선발 / 요일 선정
-
-진행하고 싶은 요일을 각자 선택하는 방식
\ No newline at end of file
diff --git a/draft/BRIDGE/BookClub/BRIDGE_BookClub.md b/draft/BRIDGE/BookClub/BRIDGE_BookClub.md
deleted file mode 100644
index 1922e90..0000000
--- a/draft/BRIDGE/BookClub/BRIDGE_BookClub.md
+++ /dev/null
@@ -1,111 +0,0 @@
-# BRIDGE_BookClub 설명글
-
-It's a study where you read and discuss books.
-
-## Collaborator
-
-*굵은 글씨는 완주자입니다.*
-
-## Wath?
-
-1. **한 싸이클**로 **개발**에 관련된 한 가지 책을 정합니다.
-2. 해당 책을 정해진 분량을 정해진 기간까지 읽고 **정리 및 느낀 점**을 작성합니다.
-3. 이후 정해진 시간에 읽은 부분에 대한 **논의 내용**을 가지고 이야기를 진행합니다.
-
-## Why?
-
-성장하는 개발자가 되기 위해선 여러 가지 프로젝트를 해보는 것도 중요하지만 공부도 꾸준히 병행해야 합니다.
-
-혼자 책을 읽는 것도 좋지만 남들과 같이 읽고 이야기를 나누는 행위 자체가 혼자 읽는 것보다 몇 배는 좋다고 말할 수 있습니다.
-
-정리는 자유이지만 토론을 하려면 책을 읽고 와야 하기에 어느정도 강제성을 느낄 수 있습니다.
-
-하지만 참여는 100% 자율이기 때문에 스스로 압박을 느끼지 않고 꾸준하게 하셨으면 좋겠습니다.
-
-## How?
-
-1. OT 때 읽을 책을 **같이** 선정합니다.
-2. 격주 단위로 약 100~120쪽 분량 **약 4시간 정도** 집중하면 읽을 분량으로 선정합니다.
-3. 정해진 시간, 장소에서 **온라인**에서 진행합니다.
-4. 각자 작성한 논의사을 기준으로 하고 싶은 내용을 **토론**합니다.
-
-* 싸이클은 책 1권을 의미합니다.
-* 정리 및 느낀 점은 자유입니다. 1줄만 작성하셔도 됩니다.
-* 마찬가지로 참여와 퇴장, 복귀는 자유입니다.
-* 논의 내용은 **권장 사항**입니다.
-* 온라인 모임은 디스코드를 사용합니다. 마이크와 카메라는 필수는 아니지만 **권장 사항**입니다.
-* OT는 한 싸이클이 종료되면 남은 인원들끼리 상의 후 다음 싸이클 시작 전에 생성됩니다.
-
-## Rule
-
-룰은 없습니다.
-
-위에서 말한 사항들은 사실 기본적인 프로세스입니다.
-
-참여하시다 힘드시면 중도 포기하시고 이후에 다시 참여하셔도 됩니다.
-
-자유의지로 굴러가는 스터디이기 때문에 패널티 또한 없습니다.
-
-*100% 자율로 굴러가는 스터디입니다.*
-
-## Q/A
-
-Q. 100~120쪽을 2주.. 너무 짧다
-A. 개발관련 책은 에세이나 소설이 아니라 적은 분량으로 이야기할 내용도 많고 정리해야할 내용도 많다고 생각합니다.
-++ 시험기간에는 한 템포 쉬어갑니다.
-*OT때 이야기를 해보고 분량을 같이 정함*
-
-Q. 스터디가 언제 끝나는지..
-A. 한 사이클이 끝나게 되면 3주의 휴식을 가지고 다시 OT를 통해 다음 사이클을 시작합니다.
-
-Q. 마이크 카메라가 필수인가요?
-A. 되도록이면 사용하고 싶습니다. 이야기를 하는 자리이다 보니 마이크 카메라를 키고 토론을 진행합니다.
-
-Q. 온/오프라인?
-A. 끝까지 온라인으로 진행할 것 같습니다. 기회가 된다면 오프라인도 생각해보겠습니다.
-
-Q. 논의사항 작성은 필수인가요?
-A. 권장사항입니다. 사람마다 이해도가 다르거나 논의 내용이 중복되는 경우에 따라 작성하지 않으셔도 됩니다.
-
-Q. 작성된 내용은 공개되나요?
-A. 기본적으로 Public이고 동아리내 Organizaiton에서 진행하기 때문입니다.
-
-# BRIDGE_BookClub 모집 글
-
-# BRIDGE_BookClub 3rd 모집
-
-안녕하세요 10기 프로그래머 이정안입니다.
-
-이번 2회차가 마무리되어 3회차 인원분들을 모집합니다.
-
-간단하게 [**BRIDGE_Book Club**](https://github.com/BRIDGE-DEV/BRIDGE_BookClub)이란,
-
-1. 개발에 관련된 한 가지 책을 정합니다.
-2. 해당 책을 정해진 분량을 정해진 기간까지 읽고 정리 및 느낀 점을 작성합니다.
-3. 이후 정해진 시간에 읽은 부분에 대한 논의 내용을 가지고 이야기를 진행합니다.
-
-**더 자세한 내용은 아래 링크를 통해 README를 참고해주시면 됩니다.**
-
-[README](https://github.com/BRIDGE-DEV/BRIDGE_BookClub#readme)
-
-## 모집 일정
-
-- 2023-10-12 [22:00] OT 진행
-
-저번 모집과 달리 참여 인원 수요 조사 없이 OT에 참석해주시면 됩니다.
-
-OT 참석 이후 참여 의사를 알려주시면 되겠습니다.
-
-## 모집 인원
-
-현재 제한 없습니다.
-
-## 실제 진행 방식 참고용
-
-[PR 링크](https://github.com/BRIDGE-DEV/BRIDGE_BookClub/pulls?q=)
-
-위 진행 방식은 비동기적으로 온라인에서 이뤄지는 논의사항 리뷰이고 이후 디스코드를 통해 온라인 토론을 진행합니다.
-
-## 참여 방법/OT 링크
-
-- https://github.com/BRIDGE-DEV/BRIDGE_BookClub/issues/55
\ No newline at end of file
diff --git a/draft/BRIDGE/BookClub/BookClubOT.md b/draft/BRIDGE/BookClub/BookClubOT.md
deleted file mode 100644
index 988b134..0000000
--- a/draft/BRIDGE/BookClub/BookClubOT.md
+++ /dev/null
@@ -1,39 +0,0 @@
-# BookClub OT
-
-목차
-
-- BookClub 소개, 개인 소개
-- 책 리뷰 방식 소개
-- 선정 책 소개
-- 모임 시간 및 분량 설정
-- Q/A
-
-## BookClub 소개, 개인 소개
-
-개인 소개(10기~~, 뭐하고 있고, ~~)
-
-레포에 대한 소개만 간략하게
-
-## 책 리뷰 방식 소개
-
-레포 진행 방식, 지금까지 진행된 방식
-
-어렵다는 것을 미리 알려줄 것
-
-디스코드로 소통, 논의 날짜
-
-## 선정 책 소개
-
-클린코더에 대한 내용, 리뷰
-
-비 개발에 관한 내용을 왜 읽어야 하는지
-
-개발자 마인드셋이 중요한 이유등을 설명
-
-## 모임 시간 및 분량 설정
-
-같은 목요일로 2주를 돌리며 진행
-
-## Q/A
-
-내용 기록
diff --git a/draft/BRIDGE/DEV/Bridge_Dev.md b/draft/BRIDGE/DEV/Bridge_Dev.md
deleted file mode 100644
index 298259b..0000000
--- a/draft/BRIDGE/DEV/Bridge_Dev.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# BRIDGE_DEV 조직 회의록
-
-## 23-09-05 회의
-
-- 다른 깃허브 조직 참고해서 조직 운영에 대한 아이디어 정리
-- 모집에 대한 기간, 양식이 미흡
-
-다음주까지 다른 조직 운영방식 알아오기
-
-## 23-09-19
-
-- 반응
- - 운영진 모집글인줄 알았다.
-
-- 모집글 회원 모집글로 카페, 활동 홍보글 (카톡, 카페)
-
-
\ No newline at end of file
diff --git a/draft/BRIDGE/DEV/Organization.md b/draft/BRIDGE/DEV/Organization.md
deleted file mode 100644
index 1e7e6fe..0000000
--- a/draft/BRIDGE/DEV/Organization.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# 브릿지 동아리 깃허브 조직 모집 글
-
-안녕하세요 10기 프로그래머 이정안입니다.
-
-이번 23-2학기부터 BRIDGE-DEV라는 깃허브 조직을 활성화하려고 합니다.
-
-목차는 다음과 같습니다.
-
-- BRIDGE-DEV에 대한 설명
-- 들어오면 좋은 이유
-- 어떻게 들어오는지
-- BRIDGE-DEV 목표
-- BRIDGE-DEV 활동
-- 운영진 관련
-
-## 1. BRIDGE-DEV에 대한 설명
-
-BRIDGE-DEV란, 브릿지 동아리에서 개발자들이 모여 정보를 나누고 서로 도움을 주고받는 공간입니다.
-
-타 동아리에 비해 개발자간의 정보 교류가 적다고 생각되어 이를 해결하고자 만들게 되었습니다.
-
-오픈소스 마인드로 참여해 주시면 좋겠습니다.
-
-## 2. 들어오면 좋은 이유
-
-### 서로가 서로의 멘티, 멘토가 되어 정보를 빠르게 주고받을 수 있다
-
-개발자들이 겪는 고민의 90%는 이미 누군가 겪었던 고민이라고 생각합니다.
-
-서로가 서로의 멘티, 멘토라는 점은 레이싱 게임을 개발해 본 개발자와 RPG게임의 개발자의 경험은 다르다는 것을 의미합니다.
-
-개발에 있어서 막히는 부분에 관해 물어보거나 설명하면서 같이 성장할 수 있는 기회가 되면 좋겠습니다..!
-
-### 이후에도 좋은 본보기가 될 수 있다
-
-위에서 말한 저런 질문들을 디스코드나 카페에 질문하기엔 제한이 있다고 생각합니다.
-
-지금까지 이런 창구도 없었기 때문에 오로지 구글링을 통해서만 정보를 취득할 수 있었습니다.
-
-하지만 해당 조직의 Discussions를 통해 질문을 하고 답변을 받으면 이후에도 같은 질문을 하는 사람들에게 좋은 본보기가 될 수 있습니다.
-
-예시
-
-
-
-
-
-
-
-이 문제는 재귀함수, 완전탐색을 사용하여 전체 단어의 수를 찾는 문제이다..!
-
-c언어로 풀려고 하니 막히는 부분이 많지만..! 끝까지 풀어보는걸로,,!
-
-```c
-#include
-#include
-#include
-
-int main(){
- int i,j;
- int wordNum,arrNum;
- char **str;
- char arr[5][5];
-
- scanf("%d",&wordNum);
- str = (char **)malloc(sizeof(char*) * wordNum);
- if(str == NULL)
- return 0;
- for (i = 0; i < wordNum; i++){
- str[i] = (char *)malloc(sizeof(char) * 9);
- if (str[i] == NULL)
- return 0;
- scanf("%s",str[i]);
- }
-
- scanf("");
-
- scanf("%d",&arrNum);
-
- while (arrNum)
- {
- for (i = 0; i < 4; i++){
- scanf("%s",arr[i]);
- }
-
- arrNum--;
- scanf("");
- }
-
- for (i = 0; i < wordNum; i++)
- {
- printf("%s ", str[i]);
- printf("%d\n",_msize(str[i]));
- }
-
- for (i = 0; i < 4; i++)
- {
- printf("%c\n",arr[i][0]);
- }
-
- return 0;
-}
-```
-
-진행중 ㅠㅠ..
\ No newline at end of file
diff --git a/draft/Blog/2022-07-21-Useful_Site.md b/draft/Blog/2022-07-21-Useful_Site.md
deleted file mode 100644
index 89f3fc4..0000000
--- a/draft/Blog/2022-07-21-Useful_Site.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-title: "유용한 사이트 모음"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-07-21
-last_modified_at: 2022-07-21
-
----
-
-도트 변환 사이트
-
-https://app.monopro.org/pixel/
-
-유니티 오픈소트 사이트
-
-https://linuxpip.org/open-source-unity-games/
-
diff --git a/draft/Blog/2022-11-05-unity_Editor.md b/draft/Blog/2022-11-05-unity_Editor.md
deleted file mode 100644
index 4b0cc30..0000000
--- a/draft/Blog/2022-11-05-unity_Editor.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-title: "[Unity] Editor"
-excerpt: " "
-
-categories:
- - Unity
-tags:
- - [Unity, Dev]
-
-toc: true
-toc_sticky: true
-
-date: 2022-11-05
-last_modified_at: 2022-11-05
----
-
-# Custom Editor
-
-유니티에서 Editor를 사용자에 맞게 생성하거나 편집하는 방법은 크게 두가지로 나뉘는 것 같다.
-
-wizard editor를 이용하거나 editor를 커스텀 에디터를 만들거나..
-
-그 전에 Editor라고 한다면 개발 과정에서만 사용되는 `툴`이기 때문에 레벨을 잘 생각해야 한다.
-
-따라서 빌드시에는 제외해야 하기 때문에 Editor이라는 폴더에 넣어서 스크립트를 관리한다.
-
-## [ExecuteInEditMode]
-
-[ExecuteInEditMode] 애트리뷰트는 play가 아니더라도 유니티 이벤트를 받아서 실행한다. 즉, 에디터레벨에서도 스크립트가 동작하게 할 수 있다.
-
-
-
----
-
-https://docs.unity3d.com/kr/2020.3/Manual/editor-CustomEditors.html
diff --git a/draft/Blog/2023-01-19-unity_.md b/draft/Blog/2023-01-19-unity_.md
deleted file mode 100644
index ec3a33b..0000000
--- a/draft/Blog/2023-01-19-unity_.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: "[Unity] "
-excerpt: " "
-
-categories:
- - Unity
-tags:
- - [Unity, Dev]
-
-toc: true
-toc_sticky: true
-
-date: 2023-01-19
-last_modified_at: 2023-01-19
----
-
-#
\ No newline at end of file
diff --git a/draft/Blog/2023-06-03-BTree.md b/draft/Blog/2023-06-03-BTree.md
deleted file mode 100644
index fa220a0..0000000
--- a/draft/Blog/2023-06-03-BTree.md
+++ /dev/null
@@ -1,17 +0,0 @@
----
-title: "BTree"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2023-06-03
-last_modified_at: 2023-06-03
-
----
-
diff --git a/draft/Blog/2023-06-29-memoir.md b/draft/Blog/2023-06-29-memoir.md
deleted file mode 100644
index 9a8773f..0000000
--- a/draft/Blog/2023-06-29-memoir.md
+++ /dev/null
@@ -1,208 +0,0 @@
----
-title: "나의 1년 회고록"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2023-06-29
-last_modified_at: 2023-06-29
-
----
-
-# 회고
-
-갑자기 회고를 작성하는 이유는 지금 방향을 제대로 잡아야 할 것 같다는 생각이 들어서이다.
-
-최근 우선순위가 여러 개 생기면서 공부해야 하는 방향도 제대로 못 잡고 내가 단순 게임 프로그래밍을 좋아하는지 게임 개발을 좋아하는지 또 개발을 단순하게 좋아하는지 매니징하는 걸 좋아하는지.. 헷갈리기 시작해서 크게 약 1년간 기록을 되돌아보려고 한다.
-
-갈피를 못 잡고 있는 저에게 회고라는 기회와 지금까지 잡아주신 멘토님에게 다시 한번 감사드립니다.
-
-## 1년 전
-
-일단 약 1년전 게임 프로그래머가 되어야겠다고 생각한 뒤 지금까지의 과정을 되짚어 보고 앞으로 어떻게 해야 할지 생각해보려고 한다.
-
-여러 소개서(자기소개서)에도 많이 작성한 내용이지만 막연하게 창작하는 것을 좋아해서 게임개발자가 되어야겠다고 중학교 때 생각했다.
-
-그 뒤로 정말 생각 없이 살다가 대학교를 소프트웨어학과로 전공하게 된 것 같다.
-
-이후에도 생각없이 학교를 다니다 군대에 가고 복학을 하니 코로나 때문에 비대면으로 학교를 다녀야한다는 약간의 스트레스가 있었다.
-
-마음 잡은 일은 그래도 끝까지 가는 성격인지라 휴학을 하고 보이는 공모전이나 게임잼을 전부 지원한 것 같다.
-
-그 당시 나는 아무것도 몰랐기 때문에 당장 뜨거운 경험이 필요했다.
-
-게임을 어떻게 만드는지 다른 사람과 어떻게 협업하는지 정말 하나도 모른 상태로 뛰어들었다.
-
-그렇게 운 좋게 처음 지원하게 된 프로젝트가 스마일게이트에서 주최한 스마일게이트 챌린지였다.
-
-처음 보는 사람들과 약 4개월간 개발 프로젝트를 하는 경험은 정말 정말 좋았다.
-
-학교도 안 가고 집에서 오로지 개발에만 몰두 할 수 있었으니.. 그리고 그 프로젝트가 잘되어서 우수 팀에 선정되어 SGM 14기에 합격하기도 했다.
-
-이맘때쯤 멘토님을 만나게 되었고 가장 큰 터닝포인트라고 생각한다.
-
-SGM붙게 되면서 여러 우여곡절이 있었고 가장 큰 배움은 인간관계 스킬이였던 것 같다.
-
-게임은 혼자 개발할 수 없으며 다른 사람과 협업이 필요하다는 점과 게임 개발에서 프로그래밍은 내가 생각한 것 보다 더 작은 영역에 불과하다는 사실을 알게 된 시기이다.
-
-사람들이 모여 아트, 기획, 사운드, 프로그래밍이 각자의 생각과 도전과제를 각자의 도구로 표현하여 하나로 합치는 그 과정이 생각보다 더 현실적이고 어려운 일이라는 것을 알게 되었다.
-
-물론 그 과정이 짜릿하고 가장 큰 원동력이기도 하다.
-
-그렇게 약 챌린지 + SGM + 멘토링으로 성장을 하면서 깨달은 사실은 내가 모르는 게 정말 많았다는 것이다.
-
-게임 개발도 물론이지만 내가 사용하는 도구도 제대로 못 다루고 있는데 "뭘 할 수 있을까?"라는 생각에 갈팡질팡하던 시기에 멘토님께서 여러 좋은 말씀과 조언을 해주셨다.
-
-지금 나에게 가장 큰 도움이 된 책은 `프로그래머의 길, 멘토에게 묻다`로 이 책은 처음 오프라인 멘토링 때 선물 받았다.
-
-정말 좋은 책이고 프로그래머(게임 개발자, 게임 프로그래머가 아닌)로서 마인드 셋, 패턴에 관한 내용이다.
-
-이때부터 멘토님이 말씀해 주신 경험과 공부의 밸런스를 지키고 싶어서 다양한 프로젝트에도 도전해 보고 동아리도 들어가고, 스터디도 만들고, 책도 꾸준하게 읽고 있다.
-
-지금 작성하고 있는 회고와 경험을 모두 관통하는 말은 사실 반복에 가깝다.
-
-뭐든지 꾸준하게 해야 하는데 그 당시에는 너무 쉽게 얻으려고 했던 것 같기도 하다.
-
-어리숙해서 보여주기식으로 뭔가를 하려고 하고 실질적인 깨달음보단 얕은 지식을 얻으려고 했던 것 같다.
-
-과거에 작성한 블로그 글만 해도 누군가를 따라 하거나 내가 깨달은 지식이 아닌 정말 의미 없는정보글인 걸 봐도 알 수 있다.
-
-실상 200개의 글 중 영양가 있는 글은 약 10개도 안 되는 것 같다는 생각..
-
-내가 어떤 문제에 부딪혀 거기서 어떤 깨달음을 얻고 생각하게 되었는지 왜 그렇게 글을 막 썼는지.. ㅠㅜ
-
-거기서 얻은 경험과 이전에 얻은 경험을 비교하거나 더 나은 점이 무엇인지 생각하고 그런 과정들을 글로 남겼으면 더 나에게 도움이 되었을 것 같다.
-
-지금 회고를 하고 있지만 사실 남은 기록이 그렇게 크지 않다.
-
-블로그의 작성된 몇 가지 글과 Bookreview 몇 개, codeReview 몇 개..
-
-좀 더 나의 일정과 경험, 얻은 결과들에 집중할 필요가 있어 보인다.
-
-그렇다면 이런 내가 앞으로 나아가야 할 방향은 무엇인가?
-
-## 앞으로 나아갈 방향
-
-### 1. 어딘가의 꼬리 칸에 서고 싶다.
-
-사실 나는 아직도 나의 기술의 깊이가 매우 얕다고 생각한다.
-
-아직은 배워가는 단계이기에 내가 하고 싶은 분야 일의 기술의 깊이를 더 파고 싶다.
-
-*물론 개발자로서 기술의 넓이도 중요하다고 생각한다.*
-
-하지만 아직도 부족함을 많이 느끼기에 실제 게임 회사의 개발 프로세스나 개발팀의 개발 과정을 경험해 보고 싶다.
-
-그러기 위해선 내가 몰입하고 제대로 배울 수 있는 **꼬리 칸**이 필요하다.
-
-따라서 정규 인디게임팀에 들어가서 경험을 위주로 쌓고 싶은데 아직은 대학생 3학년 신분이라 어려울 것 같다는 생각도 든다..
-
-반대로 매니징 능력, 대인관계 능력에 집중하고자 한다면 동아리에 남아서 다른 프로젝트의 매니징을 하면 좋을 것 같다는 생각도 든다.
-
-아직 방향은 못 정했지만, 목표는 동일하다.
-
-> 게임에 대해 더 공부하고 싶다는 목표
-
-### 2. 회고는 주기적으로..!
-
-지금, 이 글을 쓰면서 어지러워진 나의 머릿속을 제대로 정리하고 있다.
-
-처음으로 범위를 크게 잡고 해보는 거라 그동안 왜 안했을까..? 이 생각뿐이다.
-
-회고를 좀 더 자동화해서 CI/CD처럼... ㅋㅋ 하면 너무 좋을 것 같다는 생각..?
-
-아직은 어렵지만 이런 메타인지를 키우는 게 나에게 큰 도움이 된다는 사실은 알고 있다.
-
-이번 회고는 약 1년이지만 앞으로는 경험마다 그리고 한 달마다 회고를 해야겠다는 생각이 든다.
-
-`역사는 현재와 과거의 대화다`
-
-무지했던 나를 알고 있는 내가 만나서 얻는 인사이트가 핵심
-
-또한 지금 내가 가고자 하는 길에 과연 과거의 했던 내용이 도움이 되는지 판단이 서게 되면 방향이 점점 확실해진다.
-
-지금은 너무 큰 범위의 회고, 거의 인생에 대한 글을 쓰고 있는 거라 회고 방법을 적용하기 어렵지만
-
-앞으로는 YWT, AAR같은 회고 방법도 한 번씩 찍어 먹어 볼 생각이다.
-
-### 3. 생각하고 글을 쓰자
-
-나를 표현하기 가장 좋은 포트폴리오는 사실 Github와 블로그가 전부이다.
-
-그런데 작성한 글 중에 나에 대해서 표현한 글, 내가 얻은 깨달음에 대한 글이 전무하니..
-
-앞으로 작성되는 글은 전부 회고 형식의 글이 될 것 같다.
-
-그래야 내가 나중에 볼 때도 도움이 되기에
-
-물론 기술적인 글도 작성할 것이다. (Effective C#같은...)
-
-기술적인 글은 실제로 내가 다시 찾아보기 때문에..
-
-글만 읽어도 내가 어디에 관심이 있고 뭘 하고 있는지 알 수 있는, 남들에게 도움이 되는, 내가 겪은 문제들을 위주로 작성할 예정
-
-### 4. CodeReview, BookReview 활성화
-
-클린코드나 좋은 코드, 나쁜코드 개발 관련 책을 읽다 보니 내가 작성했던 코드를 다시 찾기가 쉽지 않다.
-
-분명 좋았던 코드도 있고 아쉬웠던 코드도 있어서 그런 코드를 리펙터링하고 싶다는 생각은 들었지만, 그 흔한 핑계인 시간 때문에 하지 못했던 것 같다는 생각이다.
-
-실제 깃헙에 CodeReview라는 레포가 있어서 대부분의 공부 내용을 넣어뒀었는데 프로젝트를 진행하면서 배운 코드들에 대한 기록이 너무 적다.
-
-따라서 앞으로는 프로젝트나 좋은 코드 위주로 등록할 것 같다.
-
-BookReview는 사실 제대로 쓰고 있는 것 같아서 그냥 계속 쓰면 될 것 같다.
-
-하지만 읽고 있는 책의 우선순위는 다시 정하고 좀 더 계획적으로 주에 어떤 책을 몇 시간 읽을 것 인지 정해야겠다.
-
-*여기서 말하는 계획은 달에 몇 권 읽겠어! 이런 계획이 아닌 꾸준하게 책을 읽는 계획이다.*
-
-### 5. 스터디 정리
-
-지금 내가 진행하고 있는 스터디는 총 3개이다.
-
-책 읽기 모임이 2개, 모각코 진행중이다.
-
-개인적으로 책 읽기 모임은 두 개 정도가 적당한 것 같고 모각코로 개인적인 공부를 하기에도 적합하다.
-
-뒤에서 말하겠지만 게임엔진 관련 스터디를 들어가고 싶다.. 개인적인 흥미와 공부하고 싶은 분야이기도 하다.
-
-Godot엔진에 관심이 많아서 해당 관련 스터디를 알아보고 있다.
-
-### 6. 개인적인 공부 방향
-
-지금의 내가 지금 관심 있는 분야를 정리한다면
-
-1. 꾸준하게 공부하고 있는 OOP 관련 공부
-2. 게임 프레임워크/아키텍처 (게임 제작 방법)
-3. 게임엔진 관련 공부
-
-이렇게 3가지가 있다.
-
-물론 개발 인사이트 관련 책은 계속 읽어나갈 것이고 미디엄에서 게임 개발 관련 글도 꾸준하게 접하고 있다.
-
-위에서 말한 게임 프로젝트에 관한 내용으로 넘어와서 사실은 아직은 어떻게 할지 잘 모르겠지만 진행 중인 프로젝트가 마무리되는 대로 다른 게임 프로젝트에 합류하고 싶다.
-
-## 정리
-
-일단 지금의 넘쳐나는 생각과 공부해야 할 것들에 대해 그냥 부딪혀 보자.
-
-나는 아직 대학생이기 때문에 시간적인 여유가 많다.
-
-이때 아니면 공부 못해보는 게 많고 다양하게 시도해 보고 내가 더 좋아하는 게 뭔지 찾을 수 있는 시간으로 보내려고 한다.
-
-지금은 그 과정을 어떻게 그리는지에 대한 회고 글을 작성한 것이다.
-
-정리하자면 앞으로 좀 더 고차원의 게임 프로젝트에 참여하고 싶고, 내가 가진 무기들을 최대한 나에게 이점이 되게 활용할 것이다.
-
-그 과정에서 얻는 다양한 경험들을 회고 형식으로 작성할 것이다.
-
-물론 얻어 가는 기술이나 궁금한 기술 또한 테크블로그 느낌으로 잘 정리해서 올릴 것이다.
-
-이런 과정들이 나의 또 다른 터닝포인트가 될 것이라고 생각한다..!
diff --git a/draft/Capstone/CareerPlan.md b/draft/Capstone/CareerPlan.md
deleted file mode 100644
index aa2c966..0000000
--- a/draft/Capstone/CareerPlan.md
+++ /dev/null
@@ -1,118 +0,0 @@
-# 1. 진로설계서
-
-## 1.1. 희망 진로
-
-- **희망 진로**: 인디 게임 개발자
-
-인디 게임 개발자가 희망진로이지만 최종적인 목표는 인디 게임회사의 일원이 되는 것
-
-*인디게임: 적은 인원으로 개발되는 게임*
-
-아직 취업을 해본적 없기 때문에 게임회사에 취업하여 다양한 경험을 하고 스타트업이나 인디게임 스튜디오에 들어가 원하는 개발을 하고 싶음
-
-## 1.2. 희망 진로 달성 전략
-
-앞서 말한 인디 게임 스튜디오의 개발자 일원이 되기 위해서 다양한 전략을 계획하고 실천중
-
-최종 진로를 가기 위해선 일단 회사에 취업하는 목표와 인디 게임회사에서 원하는 다양한 능력을 갖추는 것이 중요하다고 생각
-
-### 1.2.1. 개발자로서의 역량
-
-스스로 생각하는 개발자로서의 가장 중요한 역량은 끊임없는 학습, 그걸 뒷받침하는 꾸준함이 가장 중요하다고 생각
-
-현재는 공부하고 있는 분야에 대한 관심사를 많이 보여주고 기록하려고 노력함
-
-#### 1.2.1.1. 테크 블로그
-
-게임 개발자에 대한 생각을 정한지 2년정도 되면서 관련 내용에 대한 테크 블로그를 운영하고 있음
-
-오늘을 기점으로 약 190개의 게시물을 올렸으며 약 한달에 10개 정도의 게시물을 작성함
-
-*현재 캡스톤에 관련된 내용도 포스팅 중*
-
-https://fkdl0048.github.io/
-
-
-
-#### 1.2.1.2. 개인 프로젝트
-
-대외적인 프로젝트를 다양하게 경험하는 것이 매우 중요하다고 생각
-
-SGM(스마일게이트 멤버심) 수료작, 메인 프로젝트, 사이드 프로젝트 등 약 3개의 프로젝트를 경험 4개의 프로젝트를 진행중에 있음
-
-아직 3학년이기 때문에 4학년까지 장르를 불문하고 다양한 프로젝트로 좋은 결과를 얻고 싶음
-
-깃허브에서 진행중인 다양한 프로젝트를 확인 가능
-
-https://github.com/fkdl0048
-
-
-
-#### 1.2.1.3. 개인 공부 및 스케줄링
-
-개인적으로 공부하는 시간을 많이 가지고 있음
-
-개발자로서 학습하는 방법은 크게 프로젝트로 실전경험, 책을 읽어 개발자 스킬 취득정도로 생각이 되는데 평소에도 개발자 관련 책을 많이 읽고 있음
-
-이번년도 기준으로 약 6권의 책을 읽었고 지금도 다양한 책을 읽고 있음
-
-
-
-
-*클린코드, 좋은 코드 나쁜코드, 소프트웨어 아키텍처 101등등..*
-
-자신의 작업을 스케줄링하고 시간에 맞게 할당하는 능력또한 매우 중요하다고 생각
-
-
-
-깃허브 Project를 사용해서 프로젝트의 일정이나 개인 일정을 할당하고 매일 Todo를 작성함
-
-### 1.2.2. 업계 정보 수집
-
-개발자로서의 역량을 키우는 것도 중요하지만 자신이 희망하는 분야에 대한 정보를 수집하는 것도 중요하다고 생각
-
-#### 1.2.2.1 SGM
-
-스마일게이트 멤버십 수료작을 진행하면서 다양한 정보를 얻을 수 있었고, SGM14기로 소속되며 인디게임 정보를 얻을 수 있는 기회를 얻음
-
-내부에서 다양한 스터디, 대외 활동을 진행중이며 많은 도움이 되고 있음
-
-#### 1.2.2.2 게임 개발 연합 동아리 브릿지
-
-국내 게임 개발 연합동아리 브릿지에 소속되어 활동중
-
-프로젝트를 경험하기에 한 가지 대학에 소속되어 정보를 얻기 매우 힘듬
-
-다양한 대학생과 현업자들의 정보를 교류하고 피드백을 많이 받음
-
-## 1.3. 본인 소개서
-
-스스로 자신을 소개하고 목표지점을 명확하게 하고자 함
-
-### 1.3.1. 취업 목표
-
-취업 목표는 인디 게임회사에 취업하는 것이 목표
-
-시간이 날 때 마다 인디게임을 사서 하루만에 클리어하는 것을 즐기고 적은 인원으로 최고의 결과물을 내는 것을 매우 좋하기에 일찍이 목표가 정해짐
-
-최고의 복지가 동료라고 생각되는 만큼 스스로 최고의 동료가 되기 위해 노력하고 그런 집단에 속하고 싶음
-
-### 1.3.2. 전문성
-
-AI가 발달함에 따라 단순 코더들은 빠르게 줄어들 것으로 예상..
-
-데브옵스쪽이나 아키텍처파트가 가장 오래 유지될 것으로 예상되기에 그런쪽의 공부도 빼지 않고 하고 있음
-
-### 1.3.3. 강점
-
-희망 진로 달성 전략에서 많이 보여줬지만 꾸준함을 최고의 강점이라고 생각하고 있고 그에 대한 증명을 매일 하는 중
-
-스스로 자신을 일정을 관리하는 능력이 매우 중요하다고 생각함
-
-### 1.3.4. 약점 보강
-
-현재는 공부하며 다양한 프로젝트를 진행중이라 가로로 길어지는 기분이지만 기술이나 지식적으로 세로로 길어지고 싶은 욕심이 있음
-
-모든 능력치가 b인 사람과 한가지 능력이 매우 출중한 사람의 차이는 크다고 생각
-
-
diff --git a/draft/Capstone/CareerPlan.pdf b/draft/Capstone/CareerPlan.pdf
deleted file mode 100644
index 842ce20..0000000
Binary files a/draft/Capstone/CareerPlan.pdf and /dev/null differ
diff --git a/draft/CodeRaid/presentation_1.md b/draft/CodeRaid/presentation_1.md
deleted file mode 100644
index ba96228..0000000
--- a/draft/CodeRaid/presentation_1.md
+++ /dev/null
@@ -1,12 +0,0 @@
-# 1회차 발표 자료
-
-블로그 양식에 이런 내용이 궁금, 공부하고 싶어서 발표를 준비
-해당 과정을 준비하면서 블로그 글로 작성한다는 것을 명시할 것
-
-- github action
- - 이미 블로그 정리 완
-- Game CI/CD 내용
- - 유용한 정보 자세히 공부하고 정리
- - 이후에 포스팅하고 프레젠테이션 자료로 만들 것
-
-
diff --git a/draft/EnglishStudy/English_Study_01.md b/draft/EnglishStudy/English_Study_01.md
deleted file mode 100644
index f023a9f..0000000
--- a/draft/EnglishStudy/English_Study_01.md
+++ /dev/null
@@ -1,36 +0,0 @@
-# English Study
-
-- 2023-09-12
-
-- 스터디 진행 방식
- - 각자 어떤 공부할지 말하고 2시간 후 어떤걸 했는지 말하기
- - 모각코랑 같은 진행방식
-
-- 내가 진행할 공부 방식
- - 첫날이라 오늘은 2시간동안 할 수 있는 공부 찾기
- - 영어 기본적인 부분이 많이 부족하여 처음부터 공부하기로 함
- - 기본적으로 뽀모도르로 시작
-
-- 공부영역
- - 구글링으로 처음 시작하는 사람에게 유용한 커리큘럼 찾기
- - 강의 형식 x
- - 없을 경우 현재 가지고 있는 책으로 일단 시작
-
-## 공부 방식
-
-인터넷의 글을 참고
-
-지금 내가 공부에 대한 동기, 흥미가 크게 없음
-
-- 영어의 100%를 이해하는 것이 목표가 아님
-- 생활영어만 되어도 만족
-
-따라서 좋아하는 책을 읽으며 공부하려고 함 (영어원서)
-
-[기억 전달자, The Giver](https://www.yes24.com/Product/Goods/13901514)
-
-주에 2시간씩 읽으며 문법 단어를 집중적으로 학습하며 실제 쓰이는 영어를 공무
-
-이후 연장되어 실생활에서도 적용 가능.
-
-이후에는 책 이름으로 md를 만들어서 기억나는 부분이나 읽고 나서 정리본을 첨부할 예정
diff --git a/draft/EnglishStudy/THE GIVER.md b/draft/EnglishStudy/THE GIVER.md
deleted file mode 100644
index 50920ff..0000000
--- a/draft/EnglishStudy/THE GIVER.md
+++ /dev/null
@@ -1,19 +0,0 @@
-# THE GIVER
-
-## INTRODUCTION: THE GIVER
-
-Twenty year? No Kidding: twenty years? It's hard to bliever.
-
-20살? 농담이 아닌 20살? 믿기 어렵다.
-
-Twenty years ago, I was-well, I was much younger.
-
-20년전, 내가 잘 지내고, 아주 어렸을 때
-
-My parents were still alive.
-
-부모님이 아직 살아계실 때.
-
-Two of my grandchildren had not yet been born, and another one, now in college.
-
-내 두 손자가 아직 태어나기전 그리고 한명은 대학에 있을 때
diff --git a/draft/KraftonJungle_GameLab/Note.md b/draft/KraftonJungle_GameLab/Note.md
deleted file mode 100644
index 2b29f09..0000000
--- a/draft/KraftonJungle_GameLab/Note.md
+++ /dev/null
@@ -1,77 +0,0 @@
-# 지원서
-
-## 지원동기에 대해 설명해주세요. (500자 이내)
-
-```
-게임 제작을 하고 싶다는 생각이 중학생 때부터 있었지만, 게임 개발을 진심으로 시작한 시기는 약 1년 전인 것 같습니다. 여러 가지 동아리, 프로그램에 도전하며 게임개발을 지속해 왔고 간단한 포트폴리오가 아닌 인디게임 스튜디오 수준의 게임을 만들어 보고 싶었습니다. 평소에 스팀에서 인디게임을 구매한 날에 바로 엔딩까지 보는 플레이를 주로 합니다. 그중에서도 마음에 드는 게임은 업적까지 다 깰 정도로 좋아하는 편인 것 같습니다. 게임 자체에 몰입하여 재미를 느끼고 팬이 될 수 있던 이유는 게임 자체가 재밌었고 그 재미 속에 자신들이 하고 싶은 이야기를 숨겨놨기 때문에 대부분의 사람들이 플레이하고 그중에서도 몇 명은 게임의 팬이 되는 것 같습니다. 지금까지 말한 이런 게임을 만들기 위해선 같이 게임을 만들어 갈 동료들이 필요합니다. 게임업계에서 배워가는 과정 자체가 너무 좁고, 한정되어 있기에 항상 몰입할 수 있는 환경과 마음이 맞는 동료를 계속 찾아다녔습니다. 그러던 도중 크래프톤 정글 게임 랩을 알게 되어 지원하게 되었습니다.
-```
-
-## 14.게임 제작에 도전한 경험에 대해서 적어주세요. (500자 이내)
-
-게임 제작 관련 포트폴리오 링크가 있다면 함께 명시해주세요. 게임 제작 경험이 없다면 게임 제작을 위해 공부 또는 노력하고 있는 점들을 설명해주세요.
-
-- 포폴 링크
-
-```
-약 1년 전 게임 개발을 제대로 시작해야겠다고 마음을 먹고 바로 게임잼이나 프로젝트성 공모전을 알아봤습니다. 그 당시에 지원할 수 있는 게임잼이 프로젝트에 참여하여 게임을 개발하는 과정과 협업하는 방법에 대해 많이 배운 것 같습니다. 그중 가장 기억에 남는 스마일 게이트 챌린지팀이 있는데 그 프로젝트가 처음으로 진행하게 된 프로젝트였습니다. 게임 제작에 대한 프레임워크나 아키텍처 지식도 없고 협업하는 방법도 몰랐던 저라 팀에게 피해가 갈까 봐 정말 보이는 대로 공부하며 게임을 완성해 나갔습니다. 결국 우수 팀에 선정이 되었고 이후 SGM에도 붙게 되면서 장기프로젝트로 전환하게 되었습니다. 그때 당시 취업 준비를 하던 프로그래머가 취업하게 되면서 프로그래머가 혼자 남게 되어 모든 영역에서 배움을 얻게 된 게 가장 큰 경험이었습니다. 쉐이더부터 시스템, 플레이어, 맵등 꼭 코딩이 아니더라도 아트적인 부분까지 세세하게 만들어 가며 '게임'이라는 판매할 수 있어야 하는 소프트웨어에 대한 고찰을 진지하게 하게 되었습니다.
-```
-
-1. 처음이였던 내가 다양한 직무에 노출되며 여러가지를 만들게 되었다
-2. 단기에서 장기로 바뀌며 프로젝트의 성질이 바뀌며 느낀점
-3. 팀원간의 갈등
-
-SGM 동아리 활동
-
-SGM
-
-## 15.기억에 남는 팀워크 경험을 적어주세요. (300자 이내)
-크래프톤 정글 게임랩의 교육은 대부분 팀 프로젝트로 이루어 집니다. 지원자가 이룬 팀 단위 성취를 중심으로 당시 역할, 본인의 장점이 기여한 바를 함께 적어주세요.
-
-```
-SGM에 붙게 되면서 장기 프로젝트로 가져가야 하는 상황이 나오게 되면서 다양한 의견이 나오게 되었습니다. 당시 팀은 3개월 프로젝트를 개발한 상태이기에 6개월 이상 프로젝트로 가져가기엔 다시 개발하는 게 훨씬 효율이 높을 것이라 판단했던 것 같습니다. 기획부터 전부 다시 만드는 과정이 시작되었는데 이때 발생한 문제점이 서로 친하다 보니 해야 할 말을 하지 못한다는 것이었습니다. 필요한 부분도 상처가 될까 봐 쉽게 말하지 못하고 의견을 내게 되면 그 의견을 모두 수용하려다 보니 뼈대를 만들고 살을 붙여야 하는 게임에서 살만 붙이는 누더기 골렘 같은 형태의 게임이 나오게 되었습니다. 모두 힘이 빠지는 상황에서 먼저 나서서 다시 처음으로 돌아가 재점검하자는 의견을 통해 개발을 이어 나갔습니다.
-```
-
-PM, 스케줄링, 이상과 현실을 보는 법, 꾸준함
-
-사실은 우리도 소프트웨어 판매자라고 생각 즉, 재미가 있어야함
-
-자신이 원하는 그림을 보여주고 싶다면 그 그림을 재밌게 그려놔야 사람들이 본다
-
-## 16.지원자를 반드시 뽑아야 하는 이유를 설명해주세요. (300자 이내)
-크래프톤 정글 게임랩에서 기대하는 바와 방향성이 어떤 이유로 본인과 적합하다고 생각하시는지 설명해주세요.
-
-나의 장점 어필, 몰입하고 싶어하는 의지
-
-나는 게임을 제작할 때 일정을 맞추고 게임의 전체적인 그림을 잘 그리는 편이라고 생각한다. 그래서 게임의 방향이 전체적인 그림에서 멀어질 것 같다고 생각이 들면 다시 잡아주곤 하는데 이런 능력도 매우 중요하다고 생각한다. PM적인 능력이라고 말할 수 있을 것 같은데 6명의 팀원이 원하는 모든 사항을 다 넣은 게임은 잘될 수 없다고 생각한다. 다양한 의견을 받아내고 게임에 필요한 부분만 넣어 하나의 소프트웨어를 만드는 작업이라 생각된다.
-
-하지만, 정글랩에서 진행하는 합숙, 게임잼은 조금 다를 수 있다고 생각한다. 일정을 조율하고 아이디어를 추가 못하는 이유 중 가장 큰 이유는 시간이 부족해서인데 정글랩은 합숙하며 팀원과 몰입하는 환경을 조성하기 때문에 팀원이 원하는 다양한 아이디어를 뿜어내며 거기서 나오는 포텐셜이 엄청날 것 같다는 생각이다.
-
-그 사이의 줄타기를 하며 전체적인 그림을 보며 팀원들과 이야기 하며 게임을 만들어보면 나에게 매우 좋은 경험이 될 것 같다고 확신한다.
-
-```
-저는 게임을 제작할 때 일정을 맞추고 게임의 전체적인 그림을 잘 그리는 편이라고 생각합니다. 그래서 게임의 방향성과 전체적인 그림을 항상 생각하곤 하는데 회사나 인디게임 팀에서는 필요한 PM 적인 능력이라고 봅니다. 앞서 말한 기본적으로 우리는 하고 싶은 이야기를 하는 것도 중요하지만 판매해야 하는 직업이기에 이런 시각을 포기할 수 없었던 것 같습니다. 하지만 정글은 합숙과 지속적인 커뮤니케이션(게임잼)을 기본으로 하므로 앞서 말한 제한점이 없을 것 같다는 생각입니다. 팀원과 몰입하는 환경에서 나오는 팀원들이 원하는 다양한 아이디어 그리고 거기서 나오는 잠재력이 엄청 기대됩니다. 저는 그 사이에서 줄타기하며 게임을 바라보며 팀원들과 게임을 만들면 좋은 경험이 될 것이라고 확신합니다.
-```
-
-## 17.크래프톤 정글 게임랩에 기대하는 바와 앞으로의 포부를 알려주세요. (200자 이내)
-
-좋은 팀원을 만나 인디게임 팀을 만들어보고 싶다
-
-가장 부럽다고 생각하는 팀
-
-```
-게임랩 내에선 재밌는 게임을 만들기 위해서 다양한 사람들과 교류하며 쉬지 않고 달려 나가며 생각했던 틀을 부숴 게임에 대한 생각을 구체화하고 싶습니다. 제가 개인적으로 좋아하는 인디게임 팀 `후추 스튜디오`는 소규모의 인디게임 스튜디오이지만 좋은 성과와 퀄리티 좋은 게임들을 뽑아내는 곳입니다. 저는 게임랩에서 그런 팀을 만들 수 있는 동료를 만나고 나아가 마음이 통하는 동료를 만나게 되면 게임랩이 아닌 밖에서도 좋은 동료로서 게임을 만들어 가는 일을 할 것입니다.
-```
-
-## 자기소개 대본
-
-안녕하십니까 저는 크래프톤 정글 게임랩에 지원하게된 이정안이라고 합니다.
-
-지금까지 다양한 게임을 만들어 봤지만 좋은 게임은 아직까지 만들어 본적이 없습니다. 그렇다고 정글 게임랩에 들어가 좋은 게임을 만들 수 있다고 생각하지도 않습니다.
-
-다만 제가 게임랩에 붙어 얻고자 하는 중요한 한가지는 믿을 수 있는 동료입니다.
-
-다양한 이유가 있겠지만 아직까지 같이 몰입할 수 있는 동료를 만나보지 못했던 것 같습니다. 그러던 도중 크래프톤 정글 게입랩이라면 5개월간 합숙하며 좋은 동료를 만나기에 충분한 시간이라고 생각이 듭니다.
-
-저와 비슷한 생각을 가지고 게임을 만들어갈 동료를 찾아 좋은 게임을 만들어 보고 싶습니다.
-
-이상입니다.
\ No newline at end of file
diff --git a/draft/KraftonJungle_GameLab/Note2.md b/draft/KraftonJungle_GameLab/Note2.md
deleted file mode 100644
index 4b4946e..0000000
--- a/draft/KraftonJungle_GameLab/Note2.md
+++ /dev/null
@@ -1,21 +0,0 @@
-# 크래프톤 정글 게임랩 제출 게임 설명서
-
-## 게임 소개
-
-- **Climbing challenge**
-
-### 컨셉 및 제작 의도
-
-- **컨셉** : 높은 곳을 목표로 하는 클라이밍 게임
-- **제작 의도** : 요즘 유행하는 Only Up이나 항아리 게임, Alt+F4와 같은 게임을 생각하여 플레이어의 도전 욕구를 겨냥한 게임입니다.
-
-### 게임 진행
-
-게임 내에 간단한 설명이 있지만, 오른쪽 왼쪽 화살표로 이동/ 스페이스 바로 점프입니다.
-
-### 게임 규칙
-
-갈수록 경사가 급격해지는 언덕을 넘어가 스테이즈를 클리어하고 자신에게 유리한 업그레이드를 진행하세요.
-
-- **클리어 조건**: 내려오는 장애물을 피해 스테이지를 다 클리어하세요
-- **게임 오버 조건**: 장애물에 부딪히거나, 떨어지면 게임 오버입니다.
\ No newline at end of file
diff --git "a/draft/KraftonJungle_GameLab/jam0_\354\235\264\354\240\225\354\225\210(fkdl000048).pdf" "b/draft/KraftonJungle_GameLab/jam0_\354\235\264\354\240\225\354\225\210(fkdl000048).pdf"
deleted file mode 100644
index 6141a24..0000000
Binary files "a/draft/KraftonJungle_GameLab/jam0_\354\235\264\354\240\225\354\225\210(fkdl000048).pdf" and /dev/null differ
diff --git a/draft/NEXON_GameJam/Note.md b/draft/NEXON_GameJam/Note.md
deleted file mode 100644
index c6fec02..0000000
--- a/draft/NEXON_GameJam/Note.md
+++ /dev/null
@@ -1,163 +0,0 @@
-# NEXON_GameJam
-
-*각 조의 발표를 정리*
-
-## 1조. 단풍과 낙엽을 이용한 게임
-
-낙엽과 단풍을 흩날려서 목표에 도달하는 게임
-
-퍼즐 컨셉
-
-## 2조. 미제
-
-미니 2인 멀티 게임(경쟁)
-
-공격을 사용해 보스에게 마지막 타격을 입히는 사람이 승리
-
-ex) 강타싸움
-
-시간에 따른 체력 감소를 두명의 플레이어가 공격의 쿨타임을 생각해서 일격을 넣는 플레이어가 승리
-
-단풍 -> 메이플스토리의 미니게임
-
-매 플레이마다 증강체 시스템으로 다른 시스템을 넣는다.
-
-## 3조. 단풍이의 첫번 째 땅
-
-2D 어드벤처
-
-단풍이라는 날아가는 소재와 스토리형 귀여운 그래픽
-
-농업 마을과 어업 마을이라는 두 미니게임 시스템에서 재화를 획득 -> 재화를 얻어 마을 탈출
-
-## 4조. 시럽 시럽 메이플 시럽
-
-턴제 디펜스 시뮬레이션
-
-깔끔한 조작감, 계속되는 위험(긴장), 제작하는 재미를 위해
-
-시간 상의 이유로 차라리 블록 이동으로 조작감을 잡고,
-
-행동이 시간 단위로 이루어진다.
-
-크게는 두 가지 시스템 타이쿤, 디펜스 게임
-
-단풍 -> 메이플 시럽
-
-## 5. Last Leaf
-
-2D 스토리 퍼즐
-
-텍스트 선택형 게임 + 미니게임(퍼즐)
-
-스토리 몰입에 집중
-
-## 6. 다람이의 단풍
-
-단풍 -> 다람쥐
-
-플랫포머 액션 게임
-
-단풍 아이템에 따라 플레이어가 변신할 수 있음
-
-각 속성에 따라 강화가 있고, 맞는 속성을 먹어야 스테이지를 넘어갈 수 있게 강제
-
-## 7. 나혼자만 1렙 몬스터
-
-빌런이 주인공으로 최종보스가 되는 목표
-
-각 스테이지를 선택 전투를 시작
-
-몬스터라는 특성 -> hp 3, 원거리
-
-기믹으로만 잡을 수 있음
-
-미니 게임의 보스 클리어 게임성 참고
-
-모험가또한 점점 강해짐 (레벨 디자인)
-
-## 8. 미정
-
-뱀서 라이크
-
-스킬 조합형태의 게임
-
-플레이의 다형성을 위해 기술을 섞어가며 구현
-
-기술 세분화 + 전직
-
-## 9. 메이플의 비행
-
-제한시간 내에 단풍씨앗을 목표지점까지 이동 시켜 잔여 hp기준으로 단풍나무를 개화시킨다.
-
-각 스테이지 마다 hp마다 외형이 다르며 스토리도 다르다.
-
-수집욕구, 호기심 자극
-
-## 10. 미정
-
-메이플게임 내의 미니게임
-
-슬라임 앵그리 버드 게임
-
-단풍 -> 메이플 스토리
-
-최종 점수로 승리를 체크하여 승리를 구분
-
-이후 콤보, 아이템까지 생각..
-
-## 11. 메이플 포레스트
-
-단풍나무가 씨앗을 뿌려 단풍나무 숲을 만드는
-
-횡 스크롤식 디펜스
-
-## 12. Key-Card
-
-카드 게임(슬레이어 스파이어)
-
-단풍 -> 게임의 단서
-
-전체적으로 어두운 게임
-
-기존 기획에서 단서만 단풍으로 교체 -> 이후 단서를 주제로 교체 (스토리)
-
-플레이어는 명탐점 상대는 범인
-
-무죄와 유죄를 입증 하는 게임
-
-연출이 핵심
-
-범인의 알리바이를 플레이어가 상쇄시키는 것이 방어
-
-공격은 범인의 범죄사실을 입증
-
-대화 도중 카드를 수집
-
-15분 플레이 타임.
-
-```
-생각
-
-단풍이라는 매개체와 범인과의 대결에서 단서로 활용된다면 괴리감을 어떻게 해결할지 오히려 괴리감을 줄 수도
-
-계절은 겨울인데 단풍이 등장?
-```
-
-## 13. 펜케이크 vs 쉐프
-
-캐주얼 2인 대결 게임
-
-## 14. 단풍분재 키우기 게임
-
-3D 로우폴리
-
-단풍 분재를 키우는 게임.. 일주일 동안 성장시키고 나무는 일주일 마다 성장
-
-원하는 만큼 성장 시키는 게임
-
-정해진 엔딩 x
-
-단풍의 종류 어필
-
-모뉴먼트 밸리 레퍼런스 디자인
diff --git a/draft/NEXON_GameJam/Note.pdf b/draft/NEXON_GameJam/Note.pdf
deleted file mode 100644
index 34f2806..0000000
Binary files a/draft/NEXON_GameJam/Note.pdf and /dev/null differ
diff --git a/draft/NEXON_GameJam/Note2.md b/draft/NEXON_GameJam/Note2.md
deleted file mode 100644
index a496211..0000000
--- a/draft/NEXON_GameJam/Note2.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# 스토리 시놉시스
-
diff --git a/draft/README.md b/draft/README.md
deleted file mode 100644
index 47fc059..0000000
--- a/draft/README.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Draft
-
-블로그 레포가 무거워지고 있어서
-
-여기에 글을 작성하고 완성한 뒤에 옮겨서 포스팅하는 공간입니다.
-
-임시작성 파일들을 관리합니다.
\ No newline at end of file
diff --git a/draft/book_report/2023-01-05-bookreview01.md b/draft/book_report/2023-01-05-bookreview01.md
deleted file mode 100644
index 30a9c1a..0000000
--- a/draft/book_report/2023-01-05-bookreview01.md
+++ /dev/null
@@ -1,850 +0,0 @@
----
-title: "BookReview [Apprenticeship Patterns]"
-excerpt: " "
-
-categories:
- - Bookreview
-tags:
- - [Bookreview, Study]
-
-toc: true
-toc_sticky: true
-
-date: 2023-01-05
-last_modified_at: 2023-01-05
----
-
-# Apprenticeship Patterns
-
-> 프로그래머의 길, 멘토에게 묻다.
-> 데이브 후버, 애디웨일 오시나이 지음 | 강준빈 옮김
-
-## 📖 책을 고른 이유(동기)
-
-멘토님에게 멘토링 5회차로 선물 받은 책이다.
-
-받았을 때는 몰랐는데 매우 유명한 책이라는 사실을 나중에 알게 되었다.
-
-멘토님이 이 책은 지금 개발자를 꿈꾸는 상태에서 읽어보고 3~4년뒤 다시 읽어보면 느끼는 점이 많을 것이라고 추천해주셨다.
-
-앞서 말한 밸러스를 지키기 위한 독서이지만 이 책은 개발자자체의 삶을 살아가는 방법에 대한 책이다.
-
-*길잡이 책*
-
-책을 정리하며 몇년 뒤 다시 읽었을 때 지금의 생각을 다시 한번 떠올리기 좋을 것 같다는 생각이 들었다.
-
-## 머리말
-
-아직은 여기서 말하는 패턴이 무얼 의미하는지 깨닫지는 못했지만 성장해 나가는 패턴정도로 생각된다.
-
-> 알지도 못하며 그 사실도 모르는 자, 바보로다 - 그를 멀리하라!
-> 알지 못하나 그 사실을 아는 자, 못 배운 자로다 - 그를 가르치라!
-> 알고 있으나 그 사실을 모르는 자, 잠든 자로다 - 그를 깨우라!
-> 알고 있으며 그 사실을 아는 자, 깨우친 자로다 - 그를 따르라!
-
-지은이의 글 첫 번째 글귀이다.
-
-여기서 `알지 못하나 그 사실을 아는자, 못배운 자`는 날 의미하는 것 과 같고 `알고 있으며 그 사실을 아는 자, 깨우친 자`는 멘토님을 말씀하시는 것 같다.
-
-내 시점에선 깨우친 자는 누군지 보이기 때문에 그를 따를 것이고 멘토님 시선에선 마찬가지로 못배운 자는 내가 되니 나를 가르친 것이다.
-
-항상 궁금했던 점은 멘토님은 목적없이 나에게 귀한 시간을 내주시면서 왜 선의를 배푸는 걸까?
-
-감사하는 마음과 꼭 보답하겠다는 마음은 항상 가지고 있고, 닮아가고 싶은 롤 모델이기도 하다.
-
-물론 배품을 좋아하셔서 봉사활동의 일환이라고 생각하실 수 있다.
-
-*(지식의 나눔을 정말 좋아하시는 것 같다.. 지식의 나눔이라는 추상적인 것 보다 낚시하는 방법에 대해서 많이 길을 잡아주신다. 똑바로 서있을 수 있도록 자세를 교정해주시는 느낌)*
-
-지금까지 크게 생각해본적 없이 이런 멘토링을 받았는데 위의 글귀를 읽고 다시 생각해보게 된 것 같다.
-
-멘토링이란 `경험과 지식이 많은 사람이 스승 역할을 하여 지도와 조언으로 그 대상자의 실력과 잠재력을 향상시키는 것 또는 그러한 체계`라고 한다.
-
-아직 책을 다 읽지 않았고 추측에 불과하지만 함께 자라기, 멘토링, 컨퍼런스등 이런 활동을 지속하시는 이유는 가르치면서 멘토님도 성장을 목적에 둔게 아닌가라는 생각이 든다.
-
-이러한 생각을 지속하다 보니 이게 사실이 아니라도 멘토와 멘티의 관계에 있어서 선순환은 존재해야 한다는 생각 든다.(받기만 하는 관계 x)
-
-지금까지 멘토링을 너무 생각없이 받은게 아닌가라는 생각도 들고 좀 더 다른 시선이나 내 생각을 이야기 나누며 다른 맛?을 필요로 하실까? 라는 고민이 생겼다.
-
-생각을 정리해보니 멘토님이 내게 바라는 것은 성장일 것이고 이런 관계에 대한 책임감도 조금 달라진 것 갇다.
-
-정리해보면서 든 생각이지만 멘토님은 `호밀밭 파수꾼`의 주인공의 꿈과 똑같다.
-
-> 몇천 명의 아이들이 있을 뿐 주위에 어른이라곤 나밖에 아무도 없어.
-> 나는 아득한 낭떠러지 옆에 서 있는 거야.
-> 내가 하는 일은 누구든지 낭떠러지에서 떨어질 것 같으면 얼른 가서 붙잡아 주는 거지.
-> 애들이란 달릴 때는 저희가 어디로 달리고 있는지 모르잖아?
-
-## 1장 들어가는 글
-
-> 견습과정은, 기예를 통달하겠다는 필생의 열정을 서서히 불어넣는다는 점에서 중요하다. 이는 끊임없이 배우고자 하는 열정을 점점 쌓이게 하며, 그런 과정 속에서 견습생은 탁월한 개발자가 될 수 있다.
-
-이 책은 소프트웨어 개발에 이제 막 제대로 발을 들인 개발자들을 위한 책이라고 설명한다.
-
-먼저 경험한 수많은 개발자들이 남긴 기록들 중 비슷한 내용들을 패턴으로 분류하여 올바른 길, 더 나은 길을 설명해준다.
-
-### 견습생이란?
-
-> "기본적으로 견습과정이란, 내가 지금 하고 있는 일을 항상 **좀 더 좋고** **세련되고** **빠르게** 해결하는 방법이 있을 거라고 생각하는 태도가 아닐까요?"
->
-> "견습과정은 당신이 발전해 가면서 더 나은 방법을 찾아 가는, 그리고 더 좋고 세런되고 빠른 방법을 배우도록 만드는 사람, 회사 혹은 상황을 찾는 상태이자 과정이라고 봅니다"
-
-책은 다양하게 쏟아지는 훌룡한 개발자가 되기 위한 방법으로 `사고방식`에 초점을 두는 것 같다.
-
-이러한 사고방식을 견습과정 패턴이라고 정의하였고 실제로 주위에서 많이 사용되고 있음을 말한다.
-
-이러한 패턴의 특징은 `생성적(generative)`이라는 점이다.
-
-### 느낀점
-
-읽으면서 저자가 패턴을 찾아가는 과정에서 또 다른 패턴을 발견했다 문장이 되게 익숙하게 느껴졌다..
-
-과거에 `The Secret`이라는 책을 읽은 적있는데 1장 내용의 느낌이 많이 비슷한 느낌을 받았던 것 갇다.
-
-머리말부분에도 말했지만 내가 견습과정(개발자의 길로 들어가는 첫 스테이지..?)의 시작은 스스로 견습과정이라고 생각할 때 시작되는 것 같다.
-
-스스로 얼마나 우물안 개구리였는지 깨닫는 과정에서 오는 학구열 그리고 좌절에서 많이 배우고 성장을 해야겠다는 생각이 든다.
-
-## 2장 잔을 비우다.
-
-> 잔이 가득 차서 넘치고 있지 않습니까?
-
-시작부터 정곡을 찌르는 짧은 이야기로 시작한다.
-
-이 이야기를 읽고 든 생각은 읽는 사람에 따라 정말 다양한 해석이 나올 것 같다는 생각이 들었다.
-
-나는 지식의 허영심을 버리지 않고 대화를 이어가고 싶기 때문에 단편적이고 짧은 지식들을 테이프로 연결한 카세트라고 생각하고 실제로도 일상생활에서 자주 그러한다고 말할 수 있다.
-
-물론 도움이 된 적도 있겠지만 결과적으로는 전혀 도움이 되지 못하는 행위임을 알게되기 까지 오래걸린 것 같다.
-
-내가 채워온 잔은 정말 내가 채워온 잔이기 때문에 제대로 된 배움을 얻기 위해선 비울 필요가 있다.
-
-최근에 들은 말 중 가장 인상 깊은 말인 "코드를 평가함에 있어서 평가란 사람 자체를 평가하는게 아닌 더 좋은 소프트웨어를 위한 평가이다."
-
-*듣는 사람과 말하는 사람 둘 다 알고있어야 하는 말인 것 같다..!*
-
-### 첫 번째 언어
-
-> 언어를 하나 선택하고, 그 언어에 능숙해져라.
-
-어디서 읽은 글이였는데 컴퓨터 언어도 언어의 일종이기 때문에 한가지 언어를 어느정도 숙달이 된 상태여야 다른 언어의 습득이 쉽다는 내용이였다.
-
-코딩을 할때 기본적인 사고방식을 해당 언어로 하기 때문인 것 같다.
-
-여기서도 테스트코드의 중요성을 이야기하는데 정말 아직까지도 테스트코드의 중요성을 알지 못하는 것 같다.
-
-언어 습득관련에서 테스트 코드의 용이함이 나오는 걸 봐서는 테스트코드가 언어, 프로젝트의 구조를 파악하기 정말 좋겠다는 생각이 든다.
-
-지금은 C#을 공부하는 중인데 객체지향의 개념이 어느정도까지 올라간다면 함수형 프로그래밍도 도전해보고 싶다.
-
-언어는 C++로..
-
-오픈소스관련해서 최근 진행하게 된 유니티 커스텀 에디터 스터디에서 사람들이 커스텀한 패키지들을 볼 수 있는 사이트를 추천해주신 분이 계시다.
-
-https://openupm.com/
-
-이름부터가..
-
-그 동안 깃헙으로 봤던 UniRx나 UniTask관련 패키지도 존재하고 통과된 커스텀 패키지들도 다양하게 볼 수 있었다.
-
-이러한 패키지를 열어서 뜯어보고 공부해보면 좋을 것 같다.
-
-*해당 패키지를 열어서 테스트코드를 작성해본다..등등*
-
-### 흰 띠를 매라
-
-새로운 시작을 하기전에는 내가 알고 있던 지식들을 잠시 내려놓는 편이 좋음을 말한다.
-
-좋은 방법으로 내가 만든 프로그램을 다른 프로그래밍 패러다임으로 똑같이 만들어봄을 추천한다.
-
-다른점에 대한 부분도 명확하게 들어오고, 장점과 단점도 확연하게 볼 수 있는 정말 좋은 방법같다.
-
-
-### 열정을 드러내라
-
-여기서 말하는 팀은 뭔가 한국에서 쉽게 찾을 수 있을 것 같지는 않다.
-
-이상한 사람 취급을 받아야하는 상황은 유쾌하지 않은 경험이니 쉽게 열정을 드러내거나 다양한 방법을 적용해볼 기회가 있을까? 라는 생각이 먼저 든다.
-
-그럼에도 내가 만약 인디게임팀을 들어간다면 적은 규모의 개발자동료라면 충분히 시도해보고 싶다는 생각이 든다.
-
-꼭 팀이 아니더라도 스터디나 그룹, 동아리등 다양한 단체에서 열정을 드러내고 활동하는 것에 대한 이점은 최근에 들어서 많이 느끼는 것 같다.
-
-동아리에서 만든 깃헙에서 Discussions에 위에서 말한 스터디 모집글을 올렸는데 비슷한 맥락인 것 같다.
-
-먼저 열정을 드러내니 숨어있던 분들도 나와서 비슷한 이야기를 할 수 있었고 여기서 말하는 집단지성을 제대로 활용해볼 생각이다.
-
-### 구체적인 기술
-
-*모든 패턴을 현재의 나를 대조하면서 생각하게 된다.*
-
-마찬가지로 커스텀 에디터를 만들어 본다는 기술 자체가 좋은 경험이라고 생각한다.
-
-한번 익혀놓으면 기회가 될 때 추가적인 개발도 가능해지고 나름대로 어필할 수 있는 기술이라고 생각한다.
-
-이러한 어필할 수 있는 기술에 대한 살을 붙이는 과정또한 중요한 것 같다.
-
-독서토론중에 나온 이야기로 `스팟보너스?`잘 기억은 나지 않지만 매니저레벨에서 평가때 좋은 기술을 적용하거나 특출난 개발자에게 주는 보너스정도라고 한다.
-
-사실 보너스라고 해도 몇만원되는 돈이기 때문에 크지 않다고 생각할 수 있는데 돈보다는 공인의 효과가 더 큰것 같다.
-
-어떤 기술을 적용해서 좋은 성과를 얻었다고 했을 때 그것에 대한 보상이 증명되기 때문에 좋은 것 같다.
-
-### 무지를 드러내라
-
-제목자체가 내용을 정말 잘 설명하는 것 같다.
-
-비슷한 문장으로 "평생바보로 사는 것 보다 한번 바보가 되는게 좋다"
-
-가장 가깝게 갈 수 있는 길이 있음에도 돌아가는 이유는 사회적인 동물이기 때문에 본능의 영향도 있을 것이라고 생각한다.
-
-그 이전에 사실 내 스스로가 다른 사람의 무지를 비웃거나 무시했기 때문일 것이다.
-
-스스로 무지를 드러냄에 대한 걸리는 점이 없다면 쉽게 성장했을 것이다.
-
-자기 자신을 먼저 제대로 바라보는게 먼저인 것 같다..!
-
-### 무지에 맞서라
-
-무지에 맞서라는 패턴은 무지를 드러내는 패턴과 균형을 잘 맞춰야 함을 강조한다.
-
-무지에 맞서서 학습하는 과정에서도 무지를 드러내고 다시 맞서는 태도가 중요하다.
-
-책에서 말하는 정보탐식가, 자기비하등을 예로 들어 극닥저인 패턴의 예를 보여준다.
-
-이 패턴이 `무지를 드러내라`패턴 뒤에 등장한 이유는 학습함에 있어서 명확해지는 부분인 것 같다.
-
-자신이 알고 모르고 정확하게 바라본 뒤 필요하다고 생각되는 부분을 학습해 나가야 하는 것 같다.
-
-지금 진행중인 스터디 또한 동아리 깃헙에서 레포를 파서 전체적 동아리 내부사람들에게 진행상황또한 공유할 것 같다.
-
-여기서 오는 공개적인 학습에 대한 긍정적인 효과도 기대가 된다..
-
-### 깊은 쪽
-
-> 무참한 실패를 맛본 적이 한 번도 없다면, 당신은 퀀가 가치 있는 일을 시도했던 적이 한 번도 없었다고 봐야 한다.
-
-나에게 두드러지는 역할이나 어려운 문제가 주어진다면, 그 기회를 놓치지 말고 두 손으로 꼭 잡아라 두렵게 생각되는 일을 맡고 능력을 넘어서는 듯한 일을 실제로 함으로써만 당신은 성장할 수가 있다.
-
-정말 공감이 많이 가는 말이다.
-
-항상 안정을 추구하는 타입이지만 게으름이 너무 싫어서 큰 일을 벌려놓는 성격이다.
-
-스터디 모집또한 같은 맥락으로 현재 진행중인 프로젝트 또한 2가지이다..
-
-물론 기회가 된다면 더 할 생각도 있으며 두렵지만 나에게 도움이 된다는 걸 너무 잘 알기에 성장할 수 있는 기회 + 강제성이 부여되는 일을 좋아하는 것 같다.
-
-혼자서는 잘 안하게 되는 타입이라..
-
-### 한 발 물러서라
-
-자신의 무지함을 깨닫는 곡선을 본적이 있다.
-
-정말 많이 공감이 되는 내용이였는데 이제 어느정도 알겠다는 순간이 오는데 그때가 정말 아무것도 모르는 상태라는 것..
-
-프로젝트를 진행 후 내가 얼마만큼의 길을 왔고 지금 현재 역량은 어느정도인지 깨닫는 과정이 정말 중요하다는 것
-
-이 과정은 회피할 수 없으며 무지를 드러내고 무지에 맞서는 과정을 이어주는 다리이다.
-
-### 느낀점
-
-정말 뼈를 때리는 말들이 많아서 많이 아팠다..
-
-정확한 자기평가에 대한 중요성을 강조하며 이번 장을 마무리한다.
-
-*다시한번 메타인지를..ㅠ*
-
-## 3장 긴 여정을 걷다.
-
-데이브의 사례를 읽고 든 생각은 이론도 매우 중요하지만, 프로젝트나 개발자 커뮤니티등 헤엄칠 수 있는 공간이 있어야 성장할 수 있음을 말하는 것 같다.
-
-### 긴 여정
-
-> 눈을 감고, 앞으로 10년 동안 당신이 맡을 거라 생각되는 역할 중에서 가장 기묘한 것을 떠올려 보라.
-
-프로그래머로써 기술적 성장은 언제나 설레는 일이다.
-
-하지만 현실에서는 기술을 공부할 시간 보다 개인적인 시간, 업무에 시간이 많이 뺏기게 되며 성장할 기회를 잃어버린다.
-
-견습과정에서는 학습과 장기적인 성장에 관점을 두고 장기적인 목표를 세우라고 말한다.
-
-내가 지금 걸어갈려고 하는 프로그래머의 길을 다시 한 번 생각해보고 목표는 어디까지이고 뭘 하고 싶은지에 대한 생각을 정리하자..
-
-지금의 나는 뭘 하고 싶고 어떤 기술을 공부하고 싶지만 그 기술을 나름 마스터했다고 생각했을 땐 또 다른 벽이 기다리고 있을 것
-
-몇년 개발하고 그만둘게 아니라면 스스로의 지도를 그리고 긴 여정을 떠나야 한다.
-
-### 예술보다 기예
-
-> 나는 프로그래밍을 일종의 공예로 본다. 공예는 예술의 일종이기는 하나 순수 예술은 아니다.
-
-검증된 해결 방법 VS 신 기술 도입
-
-물론 새로운 기술 공부는 개발자로서 언제나 궁금한 영역이고 기분좋은 일이다.
-
-하지만 판매하는 직업이기 때문에 이를 쉽게 결정해서는 안된다.
-
-이기심을 선택하지 말고 고객에게 가치를 제공하는 데 집중하라
-
-소프트웨어 장인의 길을 가고 싶다면 예술이 아닌 기예에 집중해야 하며 스스로 함정에 빠진 적 없는 지 점검해야 한다.
-
-글 중에 50줄 짜리 게임과 백만줄 짜리 게임의 결과물로 봤을 때 고객은 해당 코드의 퀄리티를 모르는 것이 핵심이다.
-
-그렇다고 모든 코드를 저품질 코드라도 상품성에 집중하라는 것이 아닌 균형을 잘 잡아나가는게 중요하다.
-
-설계에 대한 고민을 충분히 하는 것은 매우 중요하지만 개발기간의 3/2을 생각만 하며 고민하는 것은 직업정신이 빠진 사람으로 장인으로 볼 수 없다.
-
-또한, 여기서 오는 이점도 언급을 하는데 `수리를 통한 동작 이해`이다.
-
-### 지속적인 동기 부여
-
-> 프로그래머가 일하는 모습을 본 적이 있는 사람이라면, 자기 방식대로 일할 수 있는 기회가 주어졌을 때 프로그래밍은 그 자체로 가장 큰 동기를 부여한다는 것을 알 수 있다.
-
-나에게 빗대어 설명하자면 번 아웃이 오는 경우인 것 같다.
-
-프로젝트의 방향이 자꾸 변하게 된다면 프로젝트에 대한 애정, 흥미도 떨어지면서 자연스럽게 할애하는 시간도 줄어든다.
-
-개발 자체에 흥미가 떨어지는 시점은 누구나 오기 마련인 것 같고.. 이 때 처음 프로젝트를 완성했을 당시나 코드가 자연스럽게 흐르는 과정을 생각해보면 도움이 된다.
-
-견습생인 지금은 다양한 코드를 만지고 접하는 게 재밌고 흥미로울 수 있지만 회사나, 프로젝트의 요구에 따라 현실을 위한 코드를 짜야한다.
-
-그런 코드들은 대부분 재미가 없고 다른 이들도 피하는 작업이기 때문에 이런 갈등이 생길 수 있다.
-
-책에서 등장하는 키워드인 `황금 족쇄`는 `"뭔가 새로운 걸 배우고는 싶지만 내가 이미 알고 있는 것들로 벌이가 너무 좋다."`
-
-대부분의 프로그래머들이 취업준비를 하며 회사에 맞게 공부하고 취업 후 실력이 퇴보되는 경우를 예로 볼 수 있을 것 같다.
-
-스스로 긴 여정에 대한 질문을 던져봤다.
-
-오비 페르난데스의 경우 이미 전문가임에도 새내기에 도전했다는 생각을 했을 때 만약 나라면 그런 선택을 할까..?
-
-지금의 나라면 다른 기술이나 언어가 궁금해서 어느정도 학습은 하겠지만 완전하게 내 전문성은 내려놓지 못할 것 같다.
-
-황금 족쇄가 왜 무거운 황금 족쇄인지 이름을 참 잘지었네..
-
-### 열정을 키워라
-
-> 신은 인류의 아주 일부에게만, 설령 얻는 것이 없더라도 열정으로 했을 일을 하면서 생계도 유지하는 특권을 주었다.
-
-열정을 질식시키는 환경에서 나의 열정을 보호할 안전장치를 마련해라
-
-사나운 관리자, 냉소적인 동료, 계층 사다리 등 회사의 업무환경에서는 필연적으로 마주치기 마련이다.
-
-이러한 열정 종식자들을 스스로 뛰어 넘기 위해선 안전장치가 필요하다.
-
-1. 스스로 좋아하는 일을 하라
-
-내가 만약 현실의 벽에 부딪쳐 작은 게임사가 아닌 회사에 입사하게 된다 해도 사이드 프로젝트로 인디게임 개발을 이어가는 것
-
-회사에서 받은 스트레스와 식은 열정을 집에서 불태우며 장인의 길을 걷는다.
-
-2. 마음 맞는 사람들을 찾아라
-
-냉소적인 동료가 아닌 성장하고 싶고 배움을 좋아하는 동료나 사람을 찾아라 지역 커뮤니티가 될 수 있다.
-
-사이드 프로젝트를 비슷한 동료와 진행하거나 타인과 공유하면서 피드백을 받는다.
-
-3. 배운 것을 공유하라
-
-스터디를 예로 들 수 있고, 진행중인 블로그도 포함이 된다.
-
-4. 고전을 읽어라
-
-고전 책을 좋아해서 자주 읽을려고 하는 편인데 다시 한번.. 복기...
-
-고전 책의 경우 정말 다양한 면으로 해석이 가능하기 때문에 때때로 지금의 문제에 대한 해결책을 제시해주거나 마인드를 바로잡아 주기도 한다.
-
-5. 나만의 지도를 그려라
-
-상반되는 목표를 받았을 경우 자신만의 길을 위해 걸어가는 것이 좋다.
-
-어느정도 소신은 당연하게 있어야 한다고 생각한다. 한국회사에선 힘들 수.. 있겠다는 생각이 들지만
-
-스스로에 대한 실력이 확실하다면 그런 것에 대한 걱정은 무의미하다.
-
-### 자신만의 지도를 그려라
-
-> 헐뜯기 좋아하는 사람들을 조심해라.
-
-공감이 많이 되는 말이다.
-
-실제로 정말 많다고 생각하며 자신의 지식을 공유의 목적보단 우위에 서고 싶어하는 경우가 많기 때문이다.
-
-게임개발 공부를 시작한지 이제 1년이 거의 되가는 것 같은데 초반에 공부에 어려움이 있어서 도움을 요청할 때 많이 만나봤던 것 같다.
-
-느낀점은 헐뜯기 좋아하는 사람들이 바뀌기를 기대하는 것 보단 스스로 틈을 보이지 않는 것이 더욱 중요하다.
-
-어느정도 표준화된 지도가 있지만 그 지도를 모두가 따라야 하는 것은 아니다. 때로는 특이한 지도가 성공에 더욱 가깝기도 하다.
-
-지도는 가치관이나 주변사람들에 의해서 언제든지 수정될 수 있고, 항상 성장을 바라보고 그려나가야 한다.
-
-책에서 예시로 나온 사례들을 보면 대부분 제자리 걸음에 대한 스트레스로 한계를 뛰어넘는 경험을 하였다.
-
-스스로 정체되어 있다고 느낄 때는 과감하게 내려놓을 필요가 있다.
-
-### 직위를 지표로 이용하라
-
-> 자네를 선임 엔지니어에서 수석 엔지니어로 승진시켰네, 급여는 그대로지만 사람들이 자네를 덜 무시할거야.
-
-직위라는 문자열에 속지마라
-
-남들이 그럴 자격이 있다고 해도 견습과정이 끝난 것은 아니다.
-
-하지만 직위라는 타이틀로 스스로가 얼마나 부족한지는 깨닫게 해준다.
-
-### 전장에 머물러라
-
-> 소비 제일과 임시변통이 판치는 이 사회의 유혹에 넘어가서 우리는 가끔 잘못된 길을 선택하는데, 거기서는 단지 성취의 환상, 만족의 그림자를 얻을 뿐이다.
-
-프로그래머가 10년차정도까지 가게되면 PM정도의 직급을 얻을 것 이다.
-
-시니어 개발자로 계속 근무하며 신입들고 같은 레벨에 머무리지 않고 전체적인 프로젝트를 관리하게 될 것
-
-> "숙련됨은 연습을 중단하는 그 시점부터 퇴보하기 시작한다."
-
-스스로의 선택에 따라 갈리겠지만 책에서 말하는 숙련공이 되기 위해선 전장에 머무르는 편이 좋다.
-
-물론 회사쪽에 타협점을 제시할 수 있다.
-
-### 또 다른 길
-
-> 당신이 가는 길로 가지 않는다고 해서 그 사람들이 길을 잃은 것은 아니다.
-
-위에서 말한 다른 길에 대한 내용이 여기서 나올 줄 몰랐다.
-
-다른 길은 항상 존재하지만 걷기 전에 내가 그 길을 선택했던 이유를 떠올려라
-
-### 느낀점
-
-긴 여정이지만 대부분 내가 지금 걷고 있는 (공부하는 대학생,,?) 길에 대한 내용이며 지속적인 성장을 위한 조언들이 있었다.
-
-아직은 회사에 들어가지 않아서 대부분의 회사에 관련된 내용은 프로젝트정도의 볼륨으로 생각했다.
-
-## 4장 정확한 자기 평가
-
-빠르게 학습하는 사람들의 주된 위험중에 하나가 좁은 연못 속 커다란 물고기가 되어버리는 것이다.
-
-좁은 연못, 큰 물고기라고 해서 크게 문제가 되지 않지만 큰 물고기가 큰 연못이 있다는 사실을 모르는 것은 문제가 될 수 있다.
-
-그 큰 연못에는 더욱 거대한 물고기들이 살고 있다..
-
-소프트웨어분야는 특히 약간 앞서 나간 정도로 만족해 버리기 때문에, 범용함을 넘어서기는 아주 쉽다.
-
-따라서 항상 큰 연못들을 방문하여 큰 물고기들을 만나봐야 하며 배움을 얻어야 한다.
-
-### 가장 뒤떨어진 이가 되라
-
-> 여우의 머리가 되기보다 사자의 꼬리가 되어라!
-
-더 이상 배움이 진전이 없을 때의 문제이다.
-
-해결방법은 간단하다. 주변을 당신보다 뛰어난 개발자들로 채워라.
-
-현재 팀에서 가장 성장한 개발자가 되었다면 팀을 과감하게 벗어나 가장 뒤떨어진 멤버가 되는 팀으로 들어가라
-
-가장 재밌다고 해야 할까.. 매번 시도해보고 싶은 패턴, 기억에 남을 것 같은 패턴이다.
-
-뛰어난 개발자를 항상 모방하고 성장하며 나눠주고 다시 배움을 얻고 이 방법이 가장 빠르게 성장하는 방법이란 것을 알기에 패턴이 크게 와닿는 것 같다.
-
-당연하게 부작용은 있다. 내가 들어가게 되면 해당 팀에 퍼포먼스가 크게 저하될 수 있고 신기술이나 배움이 느리다면 제외가 될 수 있다.
-
-다른 시각으로 바라보면 동기로 작용하여 학습에 좋은 영향이 될 수 있다.
-
-### 멘토를 찾아라
-
-정말 공감 100% 삽질에 대한 생각은 많이 변화했지만 삽질은 좋은 효과를 가져온다. 혼자 학습하는 방법, 새로운 지식을 얻는 방법등 다양한 효과가 있는데 멘토는 그걸 한번에 해결해준다.
-
-멘토를 찾아라는 사실 `좋은 멘토를 찾아라`의 경우로 스스로 걸어갈 수 있게 만들어 주는 멘토를 만나는게 매우매우 중요하다.
-
-내가 가야하는 길을 이미 앞서 지나가본 사람들이기 때문에 찾아가서 배워야 한다.
-
-### 마음 맞는 사람들
-
-> 연관된 문제를 풀기 위해 힘을 모으고 있는 인재들의 커뮤니티보다 강력한 것은 없다.
-
-스터디를 혼자 진행하다가 이번에 모집으로 교체하고 다른 한분과 같이 진행중인데 정말 모집하길 잘했다는 생각이 든다.
-
-혼자서 볼 수 없는 부분, 동일한 목표, 서로를 감시, 성장하는 기분 등등 집단지성이 정말 굳굳,,
-
-### 팔꿈치를 맞대고
-
-> 나는 뭔가 해석하거나 알아내기 위해서 어느 정도 자유가 주어지는 것이 즐겁지만, 누군가와 함계 일하는 것도 즐겁다.
-
-지금 진행중인 스터디가 좋은 예제이다.
-
-같이 새로운 UI Toolkit, 패키지 릴리스 등 경험해보지 못한 기술이지만 같은 흥미와 목표를 가지고 있어서 공부하기에 적합하다.
-
-`짝 프로그래밍`실제로 42서울을 진행할 때 진행하시는 분들의 간증을 들어봤는데 추천하시는 분들의 비율이 정말 높았다.
-
-머리가 하나에서 두개로 늘어났을 뿐인데, 실제로 돌아가는 머리는 2개보다 더 많이 돌아가는 기분이였다고..
-
-아마도 서로 목표가 확실하고, 자아성취..?, 나누고 싶은 마음등등 2명이서 마음만 잘 맞으면 나머지는 다 따라오는 사항들이니 속도는 분명하게 붙었을 것이다.
-
-### 바닥을 쓸어라
-
-> 장인적인 전통에서, 새내기는 마스터의 견습생으로 시작한다. 그들은 쉬운 일을 거드는 것부터 시작하고, 숙달되어가면서 점차로 더 크고 복잡한 작업으로 옮겨간다.
-
-팀적인 조언으로 스스로 뭔가를 해낼 수 있는 일원임을 즘명하라
-
-팀에 새로 합류하게 되었다면 이미 진행중인 프로젝트가 있을 것이고 받은 역할이 없다면 반드시 해야하는 일에 지원하여 스스로를 증명하는 것이다.
-
-### 느낀점
-
-겸손은 성공적인 견습과정의 토대 중 하나다.
-
-이번 년도 목표를 되게 잘 세웠다고 생각했는데 3,4장을 읽고 나서는 조금 더 구체화를 할 필요가 있다고 느꼈다.
-
-지금의 목표는 그냥 당장 하고싶은 목표들이지만 숙련공이 되기 위한 목표가 많이 부족하고 납득이 되어야 함을 느낀다.
-
-## 5장 끊임없는 학습
-
-> 만일 그래도 괜찮다면, 우리는 일을 진지하게 시작하기도 전에 늘 뭔가 주의를 돌릴 만한 일이 일어나지 않을까 하고 기다려 볼 것 이다.
-> 큰 성취를 이루는 사람들이란 지식을 너무나 갈망하여 좋지 않은 여건에서도 그것을 탐구하는 이들이다.
-> 여건이 좋을 때란 결코 오지 않는다.
-
-매우 찔리는 문장으로 시작하는데 사람은 다 비슷한것 같다.
-
-나는 항상 밥을 먹고 나선 바로 공부나 작업에 들어가지 않고 어느정도 휴식을 취하는데 그 부분에서 오는 자기합리화를 벗어난 적이 없다.
-
-흔히 `딴짓`을 하는 나를 막을 수 없기 때문에 예전에 읽은 `인생의 12가지 법칙`의 책상부터 정리하는 것 즉, 최대한 딴짓을 할 수 없는 환경을 만드는 것이 중요하다.
-
-지금 이 글을 쓰며 진행중인 모각코(모여서 각자 코딩..)의 프로그램도 어느정도 서로 감시하며 도서관분위기를 조성해 딴짓을 못하게하는.. 지금의 상황에 잘 맞는 말인 것 같다.
-
-책에서 말하는 배우는 방법을 먼저 터득해야하는 것은 전적으로 동의한다.
-
-지금은 어느정도 궤도에 오른 것 같지만 항상 이렇게 공부하는 방법이 맞을까? 라는 의문이 생길 때가 있다.
-
-주위의 숙련공들은 항상 학습을 달고 사는데 그에 비해 새로운 것을 배우고자 하는 방법(태도)이 부족한 것을 알고 있다.
-
-### 능력의 폭을 넓혀라
-
-> 모르는 것을 배우는 일이, 어떻게 하는지 이미 아는 일을 행하는 것보다 더 중요할 때가 흔히 있다.
-
-소프트웨어 전반적인 정보, 사용하고 있는 언어, 툴의 신기술의 범위는 정말 엄청나게 넓다. 당장 검색만 해도 쏟아지는 정보들이 넘친다.
-
-한가지 기술에 대해서 탐구하고 공부하라는 것이 아닌 능력의 전반적인 폭을 넓히는 과정이다.
-
-여기서는 새로운 지식과 경험을 찾아가는 활동이 수반되는데 책에서는 커뮤니티, 블로그, 지역모임등 다양한 정보를 얻을 수 있는 창구를 활용하길 적극 권하고 있다.
-
-자신만의 정보를 축적하는 것은 현시대에서 정말 멍청한 짓이라고 할 수 있다.
-
-뒷 부분에 나오지만 견습과정을 버리고 정보의 바다에 휩쓸려 한가지만 집중적으로 탐구하고 개발하는 사람들은 당장 깃허브만 봐도 넘친다.
-
-하루 이틀 따라간다고 해서 따라갈 수 있는 수준이 아니며 그들이 정리해놓은 정보를 적극적으로 활용해야 한다.
-
-책의 사례말고도 깃허브의 `Explore`를 잘 활용하면 관심사를 star로 수집할 수 있고 topic도 등록하면 비슷한 정보들을 보여준다.
-
-실제로 잘 활용하고 있다.
-
-이외에도 레딧, 동아리, 개발자 모임톡 등 2023년에는 더욱 많은 정보를 얻을 수 있는 기회가 있다.
-
-그렇지만 취업한 친구들을 보면 어느순간 소방호스를 끄는 순간이 오는 것을 볼 수 있는데 책에서 그런 부분까지 언급하니 신기했다.
-
-* 어떻게 능력의 폭을 넓힐지 이해했다면 언제 그것을 실행으로 옮길 것인지 알아야 한다..!
-
-### 연습, 연습, 또 연습
-
-> 우리가 마스터라고 알고 있는 사람들은 어떤 특정한 기술에 더 능숙해질 목적으로 거기 전념하지는 않는다.
-> 사실 그 사람들은 연습하는 것 자체를 좋아하며, 이 때문에 그들이 점점 더 능숙해지는 것이다.
-> 그리고 더 능숙해질수록 기본적인 동작을 더 즐기게 되는 선순환이 완성된다.
-
-연습자체에 대한 시선을 다르게 하는 것이 중요한 것 같다.
-
-한가지 문제에 대해서 여러번 풀어보고 다른 방식으로 풀어보고 반복하는 과정을 42서울때 몇번 경험을 해봤는데 그 때 생긴 기예?는 아직까지 기억에 남고 잘 활용하고 있다.
-
-정말 귀찮고 짜증나는 일이라는 프레임이 항상 씌워져 있지만 실제로 작업할 때는 마감도 없고, 평가도 없기 때문에 온전히 몰두할 수 있는 환경이 생기게 된다.
-
-지금은 객체지향을 잘 활용하고 싶어서 다양한 알고리즘을 c#으로 짜보는 연습을 하고 있는데 정말 다양한 방법이 나온다..
-
-조금 더 익숙해지면 멘토님이 예전에 말씀해주신 수학문제를 푸는 코딩..?
-
-코딩테스트형식의 암기가 아닌 진짜 문제를 해결하기 위해 고민하고 수학적 공식을 가져와 코드로 만들고 표현하는 방법이 재밌을 것 같다는 생각이다.
-
-항상 새로운 기술을 공부하다 보면 기반이 튼튼하지 못해서 뒤로 다시 돌아가는 문제가 생겼는데 그 때 마다 그냥 정리된 글만 보고 눈으로 이해정도까지 가는 레벨이였다면 연습, 또 연습은 실제로 활용해보고 완전히 다시 풀어보는 과정이 가장 쉽게 기억에 각인됨을 알고 있다.
-
-### 부숴도 괜찮은 장난감
-
-> 어떤 일이든 간에 사랑하지 않고서는 정말로 잘 할 수가 없다.
-
-경험은 실패로 부터도 얻어지고 종종 무언가를 배울 수 있는 가장 좋은 방법이 되기도 한다.
-
-책에서 나온 저글링의 비유가 참 마음에 든다.
-
-앞서 나온 패턴들에서 언급한 것 처럼 `예술보다 기예` 새로운 기술을 적용해보고 싶다고 진행중인 프로젝트에 무작정 도입할 수 없다.
-
-저글링을 3개로 하던 내가 5개를 실제 공연에서 할 수 없듯이 5개를 돌리기 위한 개인적인 연습공간이 필요하다.
-
-그런 연습공간은 개발자는 항상 가까이 두어야 하고 그런 연습공간에선 부숴지는 것에 대한 걱정이 없어야 한다.
-
-나만의 장난감을 만드는 것에 대한 두려움이 없어야 하고 그것을 온전히 즐겨야한다..ㅜ
-
-### 소스를 활용해라
-
-> 프로그래머가 되고자 준비하는 가장 좋은 방법은 프로그램을 짜는 것이며, 다른 사람들이 작성한 뛰어난 프로그램을 공부하는 것이다.
-
-다른 책에서도 나오는 라이브러리를 최대한 활용해봐라 라는 내용인 줄 알았는데 (오픈)소스코드를 전체적으로 분석해보고 과거 이력을 따라가며 왜 그렇게 했을 지 생각해봐야 한다는 내용이다.
-
-다른 사람들이 작성한 내용을 전반적으로 파악했다면 코드의 리펙터링을 시도해본다.
-
-리펙터링과정에서 자기 생각과 다르다고 느끼는 지점이 불가피하게 도달하게 될 것인데 이때 스스로 자문해보는 것이다.
-
-개발한 사람들이 내가 알지 못하는 무언가를 알고 있었을지 혹은 그 반대인지 생각해보고 이를 기록으로 남겨놓는 것도 좋은 방법이다.
-
-이런 과정을 반복하다 보면 다른 사람들의 코드에서 얻어낸 미묘함과 요령으로 채워진 도구상자를 가지게 된다.
-
-이 도구상자는 작은 문제를 빠르게 푸는 능력을 연마하게 해주는데 이는, 비슷한 문제를 예전에 보았기 때문이다.
-
-### 일하면서 성찰하라
-
-> 자기 성찰은 쉽지 않은 일이지만, 우리는 자신의 성공보다 실패를 연구함으로써 더 많이 배울 수 있다고 나는 믿는다.
-
-### 배운 것을 기록하라
-
-> 쓰는 행위 자체가 가진 힘 역시 과소평가해서는 안 된다.
-> 당신은 더 큰 목적의식을 잃어버릴 수도 있을 텐데, 쓴다는 행위는 한 발짝 물러서서 문제에 대해 깊이 생각할 수 있도록 해 준다.
-> 앞뒤 없는 비난의 글을 쓰는 사람이라도 어느 정도 생각을 해야만 한다.
-
-정말 뼈저리게 느끼고 기록을 습관화하고 있다.
-
-대학생시절에는 배우고 나서 1달만 지나도 가짜기억만 남고 제대로 기억하지 못해서 그 때 당시에는 다시 학습을 반복했는데 뭔갈 뚜렷하게 개발했다기 보다 배우는 방법을 몰라서 그냥 외우는 식의 공부만 반복했다.
-
-지금은 블로그, 깃허브에 항상 기록을 해두는데 점점 익숙해질 수록 내 기억처럼 꺼내서 쓰고 있다는 점이 너무 좋다.
-
-읽은 책을 기록하는 BookReview, 좋은 코드를 기록하는 CodeReview, 하루 스케줄/월 스케줄/ 목표를 관리하는 Todo, 좋은 내용들을 정리해서 올리는 테크블로그까지 다양한 방법으로 발자취를 남기고 있다.
-
-### 배운 것을 공유하라
-
-> 너그러운 마음이 행우을 가져다준다는 것은 아무리 얘기해도 과장이 아닐 것입니다. 당신 주위에서 제일 운이 좋다고 하는 생각하는 사람들을 한번 살펴보세요.
-> 모두가 부러워하고, 늘 무엇이든 자기 뜻대로 되는 것처럼 보이는 그런 사람들 말입니다.
-> 그런 사라믈이 단순히 운이 좋았다고 치부하기는 어려울 겁니다.
-> 내가 아는 사람들은 항상 준비가 되어있고, 기예를 위해 노력하며, 주변의 사람들로 하여금 운이 좋다고 느끼게 하는 사람들이었습니다.
-
-지금 나에게 가장 좋은 형태는 아카데미 컨퍼런스 모임, 스터디인것 같다.
-
-아카데미 컨퍼런스모임은 격주로 분량의 책을 읽고 서로 느낀점, 논의사항을 나누며 지식을 나누는 자리인데 정말 많은 도움이 된다.
-
-대부분 현직자분들이 많아서 듣고 있기만 해도 도움이 되는 내용이고.. 못 알아듣는다고 쓸모없는 내용이 절대 아니다.
-
-그분들은 나에게 배운 것을 공유하는 중이고 나는 줄의 맨 끝자리에 서있는 셈이다.
-
-42서울에서도 동료평가를 가장 이상적인 예로 들 수 있을 것 같다.
-
-자신이 공부한 것에 대해 동료에게 설명하고 토론하는 것이 가장 효과적인 학습법임을 알기 때문에 세계적으로 진행중인 것이다.
-
-### 피드백 루프를 만들어라
-
-> 우리 소프트웨어 업계 종사자들은 어느 정도는 눈에 보이지 않는 제품을 가지고 일하지만, 눈에 보이지 않는다는 점 때문에 피드백에 대한 필요성은 오히려 커진다.
-
-`일하면서 성찰하라`와 비슷한 내용인 것 같은데 확실히 이 두가지 내용은 아직은 이해하기 어려운 부분인 것 같다.
-
-경험적인 부분이 없어서 이해가 아직 되지는 않지만 내 레벨에선 풀리퀘를 통한 코드리뷰정도인 것 같다.
-
-### 실패하는 법을 배워라
-
-> 천재성은 종종 잘못 이해된다. 그것은 탁월한 지적 능력의 문제가 아니라 성격의 문제이다. 천재성은 무엇보다도 기꺼이 실패를 인지하고, 미봉책으로 가리려 하지 않으며, 변화하고자 하는 의지를 필요로 한다.
-> 그것은 실패에 대한 의도적이고 심지어는 강박적인 성찰과, 새로운 해법에 대한 지속적인 탐색에서 비롯된다.
-
-실패를 두려워하지 않을려면 실패에서 오는 배움을 깨닫고 그것이 오히려 좋은 경험이 될 수 있음을 인지해야 한다.
-
-책에서 나온 실천방안의 내용이 앞서 나온 `연습, 연습, 또 연습`의 내용과 비슷해 보이지만 스스로 실패에 대한 생각을 전환할 수 있는 방법같다.
-
-### 느낀점
-
-책에서 말하는 끊임없는 학습에 대한 저주 또는 축복이라는 말이 개발자로써는 항상 가지고 가야하는 말인 것 같다.
-
-실패와 자기 객관화(메타인지)를 통해 자신의 약한 부분을 알아보는 것이 표면상으로는 부정적일 수 있으나 이러한 패턴들을 활용하여 무지함을 줄여나갈 수 있다..!
-
-만약 성자하는 개발자, 소프트웨어 장인정신으로 향하지 않고 적당한 취업, 전문적인 영역에 특화되고 싶다면 알고있는 것에만 집중할 수 있는 것 같다.
-
-이번 장은 `연습, 연습, 또 연습`, `부숴도 괜찮은 장난감`, `소스를 활용해라`를 최대한 활용하고 싶다는 생각이 들었다.
-
-게임에 대한 개발 프레임워크가 부족하다는 생각이 있어서 다양한 오픈소스의 게임들을 분석할려고 생각만 했는데 오늘 이 패턴을 엮어서 나만의 루틴을 만들 수 있을 것 같다.
-
-오픈소스게임을 뜯어서 나만의 연습공간을 만들고 직접 리펙토링을 해보고 더 좋은 방법을 기록하고 공부해보는 것이 지금에서는 가장 흥미로운 작업일 것 같다.
-
-## 6장 학습 과정의 구성
-
-> 이제 그는 평가가 아니라 지식에 의해 동기를 얻는 사람이 될 것이다. 그가 학습하는데 외부의 압력 같은 것은 필요하지 않다.
-> 압력은 오히려 그의 내부에서 생겨난다.
-> 일단 자리를 잡으면, 이런 유의 동기 부여는 기세로 타오른다.
-
-지금은 정보화 시대로 정말 많은 정보가 넘치는 세상이다.
-
-궁금한 정보가 있다면 10초도 안걸려서 내용을 확인할 수 있다..
-
-학습과정에서 추천도서를 찾고 구성하는 것은 스스로 해야하는 일이다.
-
-### 도서 목록
-
-> 누구라도 한 번에 모든 것을 배울 수는 없다. 하지만 오늘은 이것 조금 내일은 저것 조금 한다든지,
-> 전에는 아무도 생각하지 않았던 순서로 학습해 간다든지,
-> 마음 내키는 데까지 공부한 다음에 다른 주제로 옮겨간다든지 하는 견습생을 제지하는 어떤 규칙이나 원칙이 있는 건 아니다.
-> 견습생이 뭔가 배우고자 할 때는 일정상 미리 조율된 시간이 될 때까지 기다릴 필요는 없다.
-> 그리고 배울 준비가 아직 안 됐거나 재미 없거나 두렵거나 불필요하다고 생각되는 것들을 배울 필요도 없다.
-> 배우는 사람은 자기만의 학습 계획을 스스로 세운다.
-
-어느정도 언어의 익숙해지고 개념이 정리된 순간이 온다면 읽어야 하는 책, 정보의 양이 엄청난 것을 알 수 있다.
-
-아직 언어에 능통한 것도 아니지만 공부해야할 지식을 적어둔 리스트만 봐도 숨이 막힌다..
-
-해결 방법으로 독서목록유지를 말한다.
-
-지금 작성중인 md파일로 github 그리고 블로그에 글을 만들어 공유의 목적과 목록유지를 이루고자 하는데 이 패턴 자체가 이런 상황을 말하는 것 같다.
-
-뒤를 돌아서 읽은 날짜나 내용을 다시 본다면 스스로의 독서 습관을 성찰하는 좋은 방법이다.
-
-또한 내용을 다시 본다면 그때 빠진 내용이나 공통되게 나타나는 패턴과 동향을 알 수 있다.
-
-이러한 정보를 공유하고 있다고 할 때 다른 사람이 내용을 보고 흥미롭게 생각해 좋은 관계로 이어갈 수 있거나 자신과 다른 생각을 말해줄 수 있다.
-
-> 책과 책사이의 숨겨진 연관성이나 드러나지 않은 보석을 발견하게 될 수도 있다.
-
-내가 세운 독서목록은 항상 우선순위 큐의 형태를 유지해야하고 쏟아지는 정보의 양에 의해 뒤로 점점 밀리는 책이 존재할 것이다.
-
-이는 좋은 일이며 잠재적인 지식의 홍수에서 우선순위를 매겨 걸러내는 방법을 제시하는 것이 목적이기 때문이다.
-
-이 패턴을 실천할 때 어려운 점은 책을 읽을 때 어떤 기준이 존재해야 하는데 그 기준을 정하려면 해당 주제를 깊이 이해하고 있어야 한다는 점이다.
-
-우선 그 주제를 개괄적으로 이해할 수 있도록 해주는 책을 한권 골라서 읽고, 그 다음에 흥미를 끄는 세부 주제에 대해서 더 자세히 다룬 책들을 고르는 것이다.
-
-**다른 방법으로 마음 맞는 사람들과 멘토들에게 의지하는 것이다.**
-
-멘토들은 필독서를 추천해 줄 것이고, 동료 견습생들과의 토론은 그 책들을 어떤 순서로 읽을지 정하도록 해줄 것이다.
-
-또한 사람들이 공개해둔 독서목록을 활용하는 방법도 있다.
-
-[https://github.com/miloyip/game-programmer](https://github.com/miloyip/game-programmer)
-
-*실제로 게임 프로그래머의 독서 목록이 이 패턴에 맞게 순위 별로 정리된 것도 있다.*
-
-### 꾸준히 읽어라
-
-> 좋은 프로그래밍 책을 두 달에 한 권, 즉 일주일에 대략 35페이지 정도만 읽어도,
-> 당신은 이내 이 분야에 대해서 확실한 감을 갖게 될 것이며 주변의 거의 모든 이들과 구별되는 수준으로 올라설 것이다.
-
-지금 참여중인 모각코시간을 원래는 블로그 포스팅이나 알고리즘 문제풀기 정도로 사용을 했는데 좀 더 일정한 관리를 하고 싶어서 주에 딱 2시간 토요일 10:30~12:30까지는 책을 읽는 시간으로 두기로 했다.
-
-당연하게 개발관련 책들이고 멘토님이 추천해주신 책들로 읽고 있다.
-
-대략 50쪽 분량을 읽고 정리중이다..
-
-### 고전을 공부하라
-
-> 당신의 직업이나 관심 분야에서 위대한 저작들, 즉 지금까지 있었던 가장 훌룡한 책과 기사, 연셜문등을 찾아서 그것을 짖지하게 공부하기 시작하라
-
-정말 공감되는 패턴이다.
-
-대학교에서 소프트웨어과에 진학했을 때 1학년은 정말 죽어라 공부를 하지 않았다..
-
-학교에선 고전 책을 읽어야 졸업을 시켜준다고 들어서 다양한 고전 책들을 접했는데 그 때 고전책들의 매력에 빠진 것 같다.
-
-왜 고전이 고전인지 알고 책을 다시 보면 읽을 때 마다 새롭고 다양한 해결책을 주며 동반자를 만들어 준다.
-
-고전 소설의 경우에는 주인공을 나의 동료로 만들어서 생각의 방향을 전환해준다..
-
-가장 재밌고 기억에 남는 책들은 `앵무새죽이기`, `예루살렘의 아이히만`, `좁은 문`, `인간실격` 등등..
-
-아직까지도 많은 도움이 되고 벅차오른다.
-
-요즘엔 많이 못 읽었는데 고전 책 독서모임같은 모임도 들어가고 싶다.
-
-주마다 일정시간 읽고 토론하는.. 시간이 된다면
-
-### 더 깊이 파고들어라
-
-> 실무에서는 대형 프로젝트의 초반에 알고리즘 때문에 문제가 생기지 않는다.
-> 오히려 프로그래머가 더 이상 어떻게 진행해야 할지 모르게 되거나 현재 짜 놓은 프로그램이 부적합하다는 사실이 갑자기 명백해질 때
-> 하위 문제로 모습을 드러내곤 한다.
-
-각종 도구를 사용할 때 지금하는 작업을 완료하는 데 필요한 정도로만 배우고 있다.
-
-내재된 이슈도 무시하고 제공된 튜토리얼이나 장난감 예제를 통째로 복사하여 사용한다면 수많은 도구들을 사용하더라도 피상적인 지식만 존재하기 때문에 미묘한 버그나 깊은 지식이 필요한 일에는 해결하지 못하는 문제가 발생한다.
-
-먼저 도구, 기술분야, 기법같은 것을 깊이 파고는 방법을 배워라 왜 그런식으로 되어 있고 알게 될 때까지 깊이 들어가는 것이다.
-
-같이 적용하기 좋은 패턴은 `연습, 연습, 또 연습`을 적용해서 다른 방법으로도 접근해보고 깊이를 탐구하는 것이 좋다.
-
-어중간한 지식, 피상적인 지식보다 해당 분야에 깊이 있는 지식을 가졌다면 엄청난 자신감을 주며 새로운 깊이있는 지식에 도전할 때도 도움이 된다.
-
-앞에서 다룬 학습하는 방법에 일환으로 깊이 있는 지식을 배우는 방법이 학습되는 것이다.
-
-### 익숙한 도구들
-
-> 바퀴 자국안에 빠지게 되면 바퀴를 아무리 돌려도 계속 제자리고, 유일한 진척이라고는 거 깊게 파이는 자국뿐이다.
-> 홈은 다르다 바퀴가 홈에 맞물리면 당신은 힘들이지 않고 앞으로 직진한다.
-> 확실히 믿을 수는 있지만 당신과 세상이 어떻게 변했는지는 감안하지 않은 그런 방식들에 집착한다면 결국은 바퀴 자국에 빠지게 될 것이다.
-
-읽으면서 `예술보다 기예`라는 패턴이 생각났다. 차이점은 프로젝트와 기술적인 부분인 것 같다.
-
-내가 사용중인 도구들은 지금에선 익숙한 도구들이라 아직 책에서 말한 실전경험이 없지만 도구를 쉽게 버리고 새롭게 배우는 것에 대한 패턴..
-
-깊이 파고들어 한가지 도구에 익숙해지면 도구를 사용한 쉬운 해결방법이 보이게 된다.
-
-하지만 더 쉬운 도구, 대중성 있는 도구가 나와도 인지하지 못한다고 한다..
-
-### 느낀점
-
-학습과정의 구성에 대해서 멘토님에게 질문글을 달았는데
-
-내가 물어볼려고 했던 내용이 책에서 많이 나와서 당황했다..
-
-정보를 수집하고 공부하는 과정에서 밀려드는 정보의 양에 놀란적이 나만 있는 것이 아닌 공통된 견습생의 패턴으로 보이는게 신기하다.
-
-> 당신은 계속되는 자기 교육 과정에 능동적으로 참여할 필요가 있다.
-
-## 7장 맺는 글
-
-> 장인들은 원숙해지는 솜씨에 가장 자부심을 느낀다.
-> 단순한 모방이 지속적인 만족을 줄 수 없는 것은 이런 이유 때문이다.
-> 기술은 점차 발전해 가야만 한다.
-
-마스터는 없다 아직까지는..
-
-지금까지 소프트웨어의 역사는 100년 정도라고 할 수 있다..
-
-한 인간이 태어나고 죽을 때까지 100년이라고 한다면 지금은 아직도 개발되어야 하고 많은 역사나와야 한다.
-
-저자는 `스트라디바리`의 이야기처럼 지식의 전달을 강조한다.
-
-저자는 `제멜바이스`의 이야기처럼 설득의 필요성도 강조한다.
-
-우리가 마스터를 분간할 수 있는 방법 중 하나는 그의 학생들이 야망과 성취라는 측면에서 마침내 스승을 능가하는지를 보는 것이다.
-
-소프트웨어의 역사가 더욱 발전하기 위해선 견습생이 계속해서 마스터를 뛰어 넘어야 하고 발전해나가야 한다.
-
-### 패턴 목록
-
-* 가장 뒤떨어진 이가 되라(Be the Worst): 주변의 모든 이들을 일찌감치 앞서버리면서 당신의 학습은 더디어졌다.
-* 고전을 공부하라(Study the Ckassics): 당신과 함께 일하는 경험 많은 사람들은, 당신이 이미 읽었을 것이라고 여기는 책에서 나오는 개념들을 계속 언급한다.
-* 구체적인 기술(Concrete Skills): 뛰어난 개발 팀에서 일하고 싶지만, 당신에게는 아주 적은 실무 경험밖에 없다.
-* 꾸준히 읽어라(Read Constantly): 신속하게 숙련도를 끌어올렸지만, 당신에게 보이지 않는 심오하고 더욱 근본적인 개념들이 어디선가 끝없이 흘러가고 있는 것 같다.
-* 긴 여정(The Long Road): 당신에게는 소프트웨어의 명장이 되고자 하는 포부가 있다. 비록 사람들이 당신에게 기대하는 것은 그게 아닌 것 같지만.
-* 깊은 쪽(The Deep End): 당신은 자신의 경력이 안정 상태에 접어든 것이 아니라 실은 틀에 박힌 듯 정체된 것이 아닌가 두려워지기 시작한다.
-* 능력의 폭을 넓혀라(Expand Your Bandwidth): 소프트웨어 개발에 대한 당신의 이해는 좁으며 일상 작업에 관련된 저수준의 세부사항에 맞춰져 있다.
-* 독서 목록(Reading List): 읽어야 할 책의 권수가 당신의 책 읽는 속도보다 더 빠르게 늘어간다.
-* 또 다른 길(A Different Road): 당신이 가려는 방향은 소프트웨어 장인정신으로 향하는 길과 다르다는 것을 알게 되었다.
-* 더 깊이 파고들어라(Dig Deeper): 당신은 많은 도구와 기술이나 기법에 대해 피상적인 지식밖에 가지지 못했고, 좀 더 어려운 문제들과 씨름하면서 계속 장애물에 부딪하고 있다.
-* 마음 맞는 사람들(Kindred Spirits): 당신은 멘토도 없이 궁지에 빠져 있으며 당신의 포부와는 어울리지 않는 분위기 속에 놓여 있음을 알게 되었다.
-* 멘토를 찾아라(Find Mentors): 당신은 이미 있는 것을 다시 만들고 장애물에 부딪히느라 많은 시간을 소모하고 있지만, 어디쯤에서 안내를 받기 위해 방향을 틀어야 할지 확신하지 못한다.
-* 무지를 드러내라(Expose Your Ignorance): 당신의 지식에 큰 틈이 있음을 발견 했고, 당신이 하고 있는 일에 대해서 잘 모른다고 사람들이 생각할까봐 두렵다.
-* 바닥을 쓸어라(Sweep the Floor): 당신은 미숙한 개발자이며 팀으로부터 신뢰를 얻고자 한다.
-* 배운 것을 공유하라(Share What you Learn): 주변의 사람들이 당신처럼 빠르게 학습하지 못하는 것 같아서 좌절하고 있다.
-* 배운 것을 기록하라(Record Whar you Learn): 당신은 같은 교훈을 계속 되풀이해서 배우지만, 도무지 몸에 붙지를 않는 것 같다.
-* 부숴도 괜찮은 장난감(Breakable Toys): 실패가 허용되지 않는 환경에서 일하지만, 당신에게는 여전히 안전하게 학습할 데가 필요하다.
-* 소스를 활용하라(Use the Source): 주변에 좋은 코드와 나쁜 코드를 구별할만한 사람이 없다면, 당신이 짜 놓은 것이 좋은지 어떤지 어떻게 알 수 있을까?
-* 실패하는 법을 배워라(Learn How You Fail): 당신의 학습 역량은 성공적인 부분을 향상시켰지만, 실패와 약점은 그대로 남아 있다.
-* 연습, 연습, 또 연습(Practice, Practice, Practice): 당신의 일상적인 프로그래밍 작업은 실패하면서 배울 수 있는 여지를 제공해 주지 않는다.
-* 열정을 드러내라(Unleash Your Enthusiasm): 당신은 팀에 맞추기 위해서 소프트웨어 개발에 대한 흥분과 호기심을 숨기고 지내게 되었다.
-* 열정을 키워라(Nurture Your Passion): 당신은 기예에 대한 열정을 질식시키는 환경에서 일하고 있다.
-* 예술보다 기예(Craft over Art): 고객에게 해결책을 주기로 했는데, 단순하고 검증된 해법을 선택할 수도 있고, 뭔가 새롭고 환상적인 것을 만들 기회로 삼을 수도 있다.
-* 익숙한 도구들(Familiar Tools): 당신이 사용하는 도구와 기술들이 너무 급속히 바뀌어서, 작업을 추산하는 데 어려움을 느낀다.
-* 일하면서 성찰하라(Reflect as You Work): 지금의 지위에서 보낸 햇수와 수행한 프로젝트 개수가 늘어가면서, 당신은 마치 마법처럼 `경험이 쌓이게`만들어 줄 계시의 순간을 기다리고 있음을 깨닫는다.
-* 자신만의 지도를 그려라(Draw Your Own Map): 고용주가 제시하는 어떤 경력경로도 당신에게 맞지 않는 것 같다.
-* 전장에 머물러라(Stay in the Trenches): 승진 제안을 받았지만, 그 자리로 가면 프로그래밍과 멀어지게 된다.
-* 지속적인 동기 부여(Sustainable Motivations): 당신은 계속 바뀌고 상충되는 요구사항을 가져오는 고객을 위해 아리송하게 명세된 프로젝트라는 죄절스러운 현실에서 일하고 있음을 깨닫는다.
-* 직위를 지표로 이용하라(Use Your Title): 공시적인 자리에서 자신을 소개할때면 왠지 사과를 하거나 당신의 실제 기술 수준과 직무 내용간의 격차에 대해 변명을 해야 할 것 같은 생각이 든다.
-* 첫 번째 언어(Your First Language): 당신은 몇몇 언어에 익숙하지만, 그 어느 것에도 능통하지 않다.
-* 팔꿈치를 맞대고(Rubbing Elbows): 뭔지 알 수는 없지만 더 상급의 테크닉과 접근 방식이 있을 것이란 느낌을 갖고 있다.
-* 피드백 루프를 만들어라(Create FeedBack Loops): 당신은 자신이 `인식하지 못한 무능력`으로 고통 받고 있는지 알 수가 없다.
-* 한발 물러서라(Retreat into Competence): 너무나 광대한 자신의 무지에 직면하면서 당신은 압도됨을 느낀다.
-* 흰 띠를 매라(The White Belt): 당신이 가진 경험이 새로운 기술의 습득을 더 어렵게 하는 것 같아서 학습에 애를 먹고 있다.
diff --git a/draft/book_report/2023-01-05-bookreview02.md b/draft/book_report/2023-01-05-bookreview02.md
deleted file mode 100644
index b5a3e68..0000000
--- a/draft/book_report/2023-01-05-bookreview02.md
+++ /dev/null
@@ -1,2120 +0,0 @@
----
-title: "BookReview [GoodCode, BadCode]"
-excerpt: " "
-
-categories:
- - Bookreview
-tags:
- - [Bookreview, Study]
-
-toc: true
-toc_sticky: true
-
-date: 2023-01-05
-last_modified_at: 2023-01-05
----
-
-# GoodCode, BadCode
-
-> Good Code, Bad Code
-> 좋은 코드, 나쁜 코드(프로그래머의 코드 품질 개선법)
-> 톰 롱 지음 / 차건회 옮김
-
-## 📖 책을 고른 이유(동기)
-
-멘토님께서 추천해주신 아카데미 컨퍼런스라는 독서모임에 들어가게 되면서 책 세권을 6개월 동안 격주로 읽고 토론할 수 있는 기회를 얻었다..!
-
-대부분 현직자분들이 많아서 많은 도움이 될테지만 반대로 '폐만 끼치지 말자'라는 생각 + '내가 뭔데'라는 생각..ㅋㅋ
-
-하지만 그럼에도 하고 싶은 이유는 앞 포스팅에서 말한 **성장하는 개발자**가 되기 위해 밸런스를 잡기 위한 발판이다.(습관으로 만들기 위해..)
-
-++ 매우 좋은 기회라는 것을 알기 때문에
-
-나름 어필한다면 아직 대학생이기 때문에 다른 시선이나 남들이 생각하지 못한 시선..?
-
-## 머리말
-
-### 논의 사항
-
-> "협업은 다른 팀원과의 협력이기도 하지만, 미래의 나 혹은 과거의 나와의 협력입니다."
-
-1. 항상 과거의 코드를 보게 되면 코드가 이해가 안가는 부분이 많습니다..! 다른 분들은 이러한 문제를 줄이는 방식이 궁금합니다.
-
-### 책의 내용 및 정리
-
-저자는 남들이 나의 코드를 수정해도 여전히 동작해야 한다고 말한다.
-
-최근에 과거에 푼 알고리즘 문제 풀이를 보게 되었는데 문제를 읽어도 코드가 이해가 되지 않았다..
-
-이유는 복잡한 문제에 인풋값을 알파벳 순서로 처리하고 주석 또한 존재하지 않아서 전혀 어떤 동작을 하는지 감이 안잡혔다.
-
-물론 코딩테스트에서는 위의 방법처럼 풀겠지만 혼자 풀이하는 과정에서는 좋은 방법은 아니였던 것 같다.
-
-기술의 습득에 있어서 매우 오랜시간이 걸린다고 한다.
-
-그때 그때 임시변통으로 자신이 저지른 실수에서 배우거나(반면교사..) 함께 일하는 선임자, 동료로 부터 단편적인 배움을 얻는다.
-
-좋은 코드를 한줄 쓰기 위해서 많은 경험들이 필요하다고 했을 때 이 책은 저자가 몇 십년간 배운 '좋은 코드'의 한 방법이다.
-
-위에서 방법이라고 생각한 이유는 저자가 계속 강조하는 **정답은 없다**이다.
-
-정답에 근접하기 위한 여러가지 방법은 존재하지만 인생도 그렇고 어디에나 정답은 없다고 생각한다.
-
-이 책은 그러한 방법 중 '좋은 코드'로 가기 위한 좋은 방향 중에 하나라고 생각한다.
-
-모든 예제가 의사코드로 되어 있고 열린 마인드..?로 하셨다고 하니.. 기대가 된다.
-
-## 1장 코드의 품질
-
-> 서두르지 않으면 더 빠르다.
->
-### 논의 사항
-
-1. 10쪽에서 보여주는 극단적인 시나리오 A와 B이러한 절충점을 찾을 때는 프로젝트와 조직문화에 달려있다고 합니다.
-
-이러한 극단적인 사례를 경험 해보셨는지 경험 해보셨다면 과정과 결과 그리고 회고가 궁금합니다.
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 코드 품질이 중요한 이유
-* 고품질 코드가 이루고자 하는 네 가지 목표
-* 고품질 코드 작성을 위한 높은 수준에서의 여섯가지 전략
-* 고품질 코드 작성이 어떻게 중장기적으로 시간과 노력을 절약할 수 있는지
-
-#### 좋은 소프트웨어와 끔찍한 소프트웨어
-
-생각해보니 사용하기 정말 불편했던 소프트웨어와 문제를 찾아볼 수 없고 편의성이 높았던 소프트웨어는 확연하게 구분된다.
-
-게임을 예로 들자면 퀼리티나 편의성은 정말 사소한 디테일에서 나온다고 매번 생각한다.(게임에 한정되지 않지만)
-
-간단한 기능이라도 예외를 두고 만들었다면 해당 기능이 예외가 발생했을 때의 사용자는 불만도가 급격하게 상승하는 것 같다..
-
-반대로 편의적인 사소한 디테일을 경험할 때는 안정감을 느끼는 것 같다.
-
-이러한 차이의 근본이 여기서 말하는 확장성이 좋은 고품질의 코드가 아닐까..
-
-#### 소프트웨어가 만들어지는 과정
-
-1. 코드베이스(codebase): 소프트웨어를 빌드할 수 있는 코드가 저장된 저장소(git, perforce 등) Version Control System
-2. 코드 제출(submitting code): 커밋, 풀리퀘라고 불리기도 한다. 로컬에 저장된 내용을 코드베이스에 제출을 의미
-3. 코드 검토(code review): 제출전에 다른 동료들이 변경된 내용을 검토한다
-4. 제출 전 검사(pre-submit check): 병합 전 훅, 병합 전 점검, 커밋 전 점검이라고 하기도 하며 테스트가 실패하거나 컴파일 오류 시 병합되지 않도록 관리한다.
-5. 배포(release): 소프트웨어는 코드베이스의 스냅숏을 기반으로 빌드한다. 특정 버전을 가져와서 배포하는 프로세스를 배포 브랜치 만들기(cutting release)라고 한다.
-6. 프로덕션(production): 소프트웨어가 서버나 시스템에 배포될 때, 테스트 환경과 같이 내부적으로 사용하는 것이 아닌 실제 서비스되는 환경을 가리킨다.
-
-#### 코드품질을 점검하는 방법
-
-코드 자체를 고품질 저품질로 정의하는 것 자체가 주관적인 행동이지만 이러한 주관을 좋은 방향으로 다듬기 위해선 다양한 경험이 필요하다.
-
-저자는 **코드**가 정말로 달성하려는 것이 무엇인지 생각해보는 것을 말한다.
-
-목표를 달성함에 있어서 도움이 되는 코드는 높은 품질의 코드이고, 방해가 된다면 낮은 품질의 코드이다.
-
-며칠 전 멘토링을 받으며 객체지향에 대해서 이야기 했을 때 멘토님이 클래스의 이름과 public method만 나열해서 본다면 해당 객체의 목적을 알 수 있다고 해주셨다.
-
-마찬가지로 좋은 품질의 코드를 작성하기 위해선 목적과 존재의 이유가 명확해야 한다.
-
-**코드 작성의 베이스 룰(상위 수준)**
-
-1. 작동해야 한다.
-2. 작동이 멈춰서는 안 된다.
-3. 변화하는 요구 사항에 적응해야 한다.
-4. 이미 존재하는 기능을 또다시 구현해서는 안된다.
-
-#### 코드 품질의 핵심 요소
-
-1. 코드는 읽기 쉬워야 한다.
-2. 코드는 예측 가능해야 한다.
-3. 코드는 오용하기 어렵게 만들라
-4. 코드를 모듈화하라
-5. 코드를 재사용 가능하고 일반화할 수 있게 작성하라
-6. 테스트가 용이한 코드를 작성하고, 제대로 테스트하라
-
-**재사용성과 일반화성의 차이**
-
-* 재사용성(reusability): 문제를 해결하기 위한 것이 여러가지 다른 상황에서도 사용될 수 있음을 의미
-* 일반화성(generalizability): 개념은 유사하나 서로 미묘하게 다른 문제들을 해결할 수 있음을 의미
-
-드릴의 경우 구멍을 뚫는 다는 기능이 있어서 여러 곳에 적용할 수 있다.(재사용성)
-드릴이 앞에 파츠만 교체한다면 나서도 박을 때 사용이 가능하다.(일반화성)
-
-### 느낀점
-
-머리말에서 말했던 정답은 없다 이후에 상당히 조심스러운게 느껴져서 재밌다.
-
-객체지향에 한정되긴 하지만 언어의 가능성을 열어두고 과학, 물리와 같은 법칙이 없음을 강조한다.
-
-스스로 절충점과 선을 찾아서 **선택과 집중**을 해야하는 점..!
-
-예를 들어서 보여주는 상황들이 전부 재밌는 내용이라 집중이 잘되는 것 같다.. ~~초코 브라우니~~
-
-## 2장 추상화 계층
-
-> 코드 작성의 목적은 문제해결이다.
-
-### 논의 사항
-
-함수부분과 클래스부분을 읽으며 좀 더 극단적으로 가게된다면 함수형 프로그래밍으로 이어질 것 같다는 생각이 듭니다.
-명확한 차이점이 있겠지만 다른 분들이 느끼는 차이점이 궁금합니다.
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 깔끔한 추상화 계층을 통해 문제를 하위 문제로 세분화하는 방법
-* 추상화 계층이 코드 품질의 요소를 달성하는 데 어떻게 도움이 되는지
-* API 및 구현 세부 사항
-* 함수, 클래스 및 인터페이스를 사용해 코드를 추상화 계층으로 나누는 방법
-
-#### 문제의 단위
-
-상위 수준의 문제를 해결하기 위해선 여러개의 작은 하위 문제들이 필요하다.
-
-범용적인 내용인 것 같다.
-
-일을 처리함에 있어서 단위를 나누는게 마치 인터페이스로 세분화하여서 모듈화를 목적에 두는? 일상 생활도 마찬가지라는 생각이 든다.
-
-멘토링에서 처리해야 하는 일에 대해서 시간 단위로 일을 처리함을 물어보았는데 일에 단위를 시간으로 계산하기 보다 난이도로 결정하는게 좋을 것 같다고 하셨다.
-
-난이도를 [1 3 5 7]정도로 구분한다면 미리 쌓아둔 데이트를 기반으로 나누고 5, 7의 경우 다시 1 3 5정도로 세분화를 하는 것이다.
-
-하루 일에 대한 형태가 대충 트리형태로 그려지는 방법이였는데 매우 좋은 방법인것 같다.
-
-그렇다고 해서 극단적인 세분화또한 독인 것 같다..(스스로 1 3 5 7에 대한 설계가 되어야함,, 0.2 0.1 이런 수준 x)
-
-#### 추상화 계층 구축의 장점
-
-1. 가독성: 코드베이스의 모든 세부사항을 이해하는 것은 불가능하지만 몇가지 높은 계층의 추상화를 이해하고 사용하는 것은 상당히 쉽다. 깨끗하고 뚜렷한 추상화 계층은 적은 개념을 다루기만 할 수 있다.
-2. 모듈화: 추상화 계층이 하위 문제에 대한 해결책을 깔끔하게 나누고 구현 세부 사항이 외부로 노출되지 않도록 보장할 때, 다른 계층에 영향을 미치지 않고 계층 내에서만 구현을 변경하기가 쉬워진다.
-3. 재사용성 및 일반화: 하위 문제에 대한 간결한 추상화 계층으로 제시되면 하위 문제에 대한 재사용하기 쉬워진다. 그리고 문제가 적절한 추상적인 하위 문제로 세분화된다면, 해결책은 여러 가지 다른 상황에서 유용하게 일반화될 가능성이 크다.
-4. 테스트 용이성: 하위 문제에 대한 해결책이 견고한지 테스트를 해야하는데 코드가 추상화 계층으로 깨긋하게 분할되면 하위 문제에 대한 해결책을 완벽하게 테스트하는 것이 쉬워진다.
-
-계속 같은 목적을 이야기 하니까 슬슬 어느정도 청사진이 그려지는 것 같다.. 좋은 코드, 클린코드를 가지기 위해서 좀 더 생각해보고 지금까지 만든 코드를 반면교사로 삼아야겠다..
-
-#### API(application programming interface)
-
-코드를 작성할 때 고려해야 하는 측면이 두가지가 있다.
-
-1. 코드를 호출할 때 볼 수 있는 내용
-2. 코드를 호출할 때 볼 수 없는 내용
-
-볼 수 있는 내용은 공개수준을 따라간다.
-
-* 퍼블릭 클래스, 인터페이스 및 메서드
-* 이름, 입력 매개변수 및 반환 유형이 표현하고자 하는 **개념**
-* 코드 호출 시 코드를 올바르게 사용하기 위해서 알아야 하는 정보
-
-반대로 볼 수 없는 내용은 **구현 세부 사항**이다.
-
-private아래 가려진 내부 함수와 변수들은 구현 세부 사항에 속하며 의존 하는 것 또한 세부 사항이다.
-
-++ public 메서드라고 해도 이름, 반환값, 인수, 문서를 제외한 함수 내부는 세부사항이다.
-
-#### 함수
-
-정말 객체지향에서 함수가 가져야 하는 기본적인 성격에 대해서 쉬운 기준을 보여주며 설명하지만 막상 내가 할 땐 왜이렇게 어려운지 모르겠다.
-
-지키겠다고 생각하지 않고 급하게 개발을 해서 결과물 위주의 코딩을 반복해서 그런 것 같다.
-
-읽기 좋은 함수를 짜고 확장성에 용이하고, 모듈화, 재사용성/일반화가 높은 수준의 함수를 요구한다.
-
-막상 그러한 함수를 짜더라도 어느정도 커플링이 존재하기 때문에 점점 거대해지는 것 같다..
-
-시간이 아주 조금 더 걸리더라도 헬퍼클래스로 빼거나 함수를 분리해야하는 정신이 필요하다.
-
-최종적으로는 글을 읽듯이 함수를 순차적으로 읽을 수 있게 되는게 현재로서는 가장 나에게 필요한 형태인듯 하다.
-
-#### 클래스
-
-단일 클래스에 대한 크기는 정말 밭을 가는 행위인 것 같다.
-
-초장에 쉽게 갈려고 대충 갈고 농작물을 심어도 이후에 2배 3배로 고생하니 추상적 관계에 대해서 다시 고민하게 된다.
-
-위와 같은 과정을 이미 여러번 직면해보니 꼭 필요한 과정이라고 생각한다.
-
-왜 처음부터 구조를 생각해야 하는지 그 프로젝트를 보고 그 중간점을 찾는게 경험에서 나오는 능력인 것 같다.
-
-지금 진행중인 프로젝트를 열어보니 가장 긴줄이 700줄 정도가 되는 클래스라니..
-
-이걸 처음부터 수정을 할 생각을 해보기도 했지만 멘토님이 그 비용을 잘 생각해보고 이후에 좋은 반면교사로 활용해서 들고다니면 좋을 것이라는 이야기를 듣고 사이드 이펙트나 문제가 될만한 부분만 수정하고 그대로 두고 프로젝트를 마감할 생각이다..
-
-책에서 말하는 300줄의 경우 절대적인 지표가 될 수 없지만 경고의 역할이 좋아보인다.
-
-자신의 코드를 비판적으로 바라볼 때 줄수또한 좋은 지표가 되지 않을까.. (그렇다고 닌자코드나 줄 수를 줄이라는 노력이 아닌 것을 안다. 설계단계의 기준)
-
-> 한 클래스는 오직 한 가지 일에만 관심을 가져야 한다.
-> 클래스는 응집력이 있어야만 한다.
-
-위와 같이 `좋은 코드`를 위한 지표도 존재하지만 책에선 근본적인 핵심을 먼저 이행하길 권한다.
-
-1. 코드 가독성: 단일 클래스에 담겨 있는 개념이 많을수록 해당 클래스의 가독성은 저하된다. 인간은 기본적으로 멀티에 약하다. 자신도 이해하기 힘든 코드는 남들이 볼 땐 2~3배 읽기 힘들 것이라는 사실을 알아야 한다.
-
-사람들이 3줄요약을 좋아하는 이유도 비슷한 이유일 것.
-
-2. 코드 모듈화: 클래스 및 인터페이스의 사용은 코드 모듈화를 위한 좋은 방법 중 하나이다. 하위 문제에 대한 해결책이 하나의 클래스로 구현되어 있고, 다른 클래스와의 상호작용을 준비된 퍼블릭 메서드로만 이루어진다면 해결책에 대한 문제가 발생했을 때 쉽게 교체가 가능해진다. 말그대로 부품정도로..
-
-3. 코드 재사용성 및 일반화: 어떤 문제를 해결할 때 두 가지 하위 문제를 해결해야 하는 경우, 두가지 문제에 대한 해결책을 한 클래스로 묶어 둔다면 이후에 한가지 문제가 발생해도 다른 한가지 해결책을 사용할 기회가 줄어든다..
-
-4. 테스트 용이성 및 적절한 테스트: 마찬가지로 하위단위로 세분화가 된다면 테스트의 용이성으로 이어진다.
-
-#### 인터페이스
-
-인터페이스는 추상화 계층을 깔끔하게 구현하는 코드를 만드는데 있어 매우 유용한 도구이다.
-
-주어진 하위 문제에 대해 두가지 이상의 서로 다른 구헌이 가능해지고 이를 통해 모듈화를 실현할 수 있다.
-
-**하나의 인터페이스 및 단일 구현**
-
-인터페이스를 구현하는 클래스가 유일하다고 해도 이는 매우 유리하게 작용한다.
-
-**장점**
-
-1. public API를 명확하게 보여준다.
-
-인터페이스를 상속받은 클래스가 인자로 사용하게 된다면 해당 클래스에 퍼블릭함수를 추가하더라도 상위 클래스는 인터페이스만을 의존하기 때문에 해당 퍼블릭함수는 노출이 되지 않는다.
-
-2. 한 가지 구현만 필요하다고 잘못 추측한 것일 수 있다.
-
-원래 코드를 작성할 때는 또 다른 구현이 필요하지않을 것이라는 확신을 하더라도 한 두달 후엔 후회할 수 있다
-
-3. 테스트를 쉽게 할 수 있다.
-
-구현 클래스가 복잡하거나 네트워크 I/O에 의존하는 경우 목이나 페이크객체로 대체할 수 있다.
-
-4. 같은 클래스로 두 가지 하위 문제를 해결 할 수 있다.
-
-한 클래스가 두 개 이상의 서로 다른 추상화계층에 구현을 제공할 수 있다.
-
-장점이 있다면 단점도 물론이다.
-
-**단점**
-
-1. 더 많은 작업이 필요하다.
-
-말 그대로 인터페이스를 정의할려면 코드를 더 작성해야 한다.(생각도 더 해야한다.)
-
-2. 코드가 복잡해질 수 있다.
-
-다른 개발자가 코드를 볼 때 하위 문제를 이해하기 위해선 클래스가 아닌 인터페이스 먼저 봐야한다.(해당 인터페이스를 구현하는 클래스를 봐야댐)
-
-> 인터페이스만을 위한 인터페이스를 작성해서는 안된다.
-
-이러한 단점도 존재하지만 장점도 명확하기 때문에 이 또한 절충점(선)을 잘 찾아야 할 것 같다.
-
-기본적인 스탠스로 클래스를 설계할 때 인터페이스를 붙이는 것이 어렵지 않게 설계해야 한다.
-
-> 너무 비대한 계층 때문에 발생하는 문제는 너무 얇은 계층 때문에 발생하는 문제보다 더 심각하다. 확실하지 않은 경우에는 남용의 위협에도 불구하고 계층을 얇게 만드는 것이 좋다
-
-### 느낀점
-
-클래스를 많이 만드는 것에 대한 **무서움**을 줄여보자..(무작정 많이 만드는 것이 아닌 설계에 따라서)
-
-과연 내가 많이 만드는 것에 대한 무서움을 느낀 것인지 그냥 귀찮아서 인지는 아직까지 잘 모르겠다.
-
-읽다보니 많이 부끄러워지기도 하고 개발을 1년하고 그만두는게 아니니까.. 문제점을 제대로 직면했다는 것이 중요하다.
-
-이번 챕터는 실제로 코드를 작성해보고 저자가 소개한 다양한 방법을 적용해보기 좋은 것 같다. 매우매우
-
-일단 기억나는대로 룰을 지켜가며 코딩한 뒤 다시 가독성, 모듈화, 재사용/일반화, 테스트 용이성을 토대로 비판적인 시각으로 바라보면 답이 쉽게 나올 것 같다.
-
-아직은 DI나 인터페이스자체를 상속, 인터페이스를 가지는 인터페이스등 다양하게 활용 경험이 없어서 조금 어려운 부분이 있다.
-
-내용을 정리해보며 공부하고 다시 포스팅 예정
-
-개념은 잡힌 상태지만 활용아직 미숙..
-
-## 3장 다른 개발자의 코드 계약
-
-> 자신이 작성한 코드를 다른 개발자가 작업해야 하고 반대로 다른 개발자가 작업한 코드를 자신이 작업해야 한다.
->
-### 논의 사항
-
-객체지향에 맞게 명확한 목적을 가진 클래스가 설계했다면 주석이 필요 없을까요?
-
-하위단부터 추론이 가능한 1단계 이름부터 잘 설계되었다면 클래스를 거슬러 올라가는 불편함은 있겠지만 목적이 분명하다면 주석이 필요 없을 것 같다는 생각이 듭니다.
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 다른 개발자들이 코드와 어떻게 상호작용하는지
-* 코드 계약과 코드 계약의 세부 조항
-* 세부 조항을 최소화하는 것이 어떻게 오용과 예측을 벗어나는 코드를 예방하는 데 도움이 되는지
-* 세부 조항을 피할 수 없다면 체크와 어서션을 어떻게 사용할 수 있는가?
-
-#### 자신의 코드와 다른 개발자의 코드
-
-1장에서 설명한 `예측 가능한 코드를 작성하라`와 `코드를 오용하기 어렵게 만들어라` 이 두가지 원칙은 다른 사람과 상호작용할 때 일어날 수 있는 일이다.
-
-따라서 협업의 경우에는 아래 규칙을 고려하는 것이 좋다.
-
-1. 자신에게 명백하다고 해서 다른 사람에게도 명백한 것은 아니다.
-2. 다른 개발자는 무의식중에 여러분의 코드를 망가뜨릴 수 있다.
-3. 시간이 지남에 따라 자신의 코드를 기억하지 못한다.
-
-**자신에게 명백하다고 해서 다른 사람에게도 명백한 것은 아니다.**
-
-자신의 로직에 너무 익숙해져 모든 것이 분명해 보이기 때문에 과정에 대해서 망각하게 된다.
-
-어느 시점부터는 다른 개발자가 작성한 코드와 상호작용하거나 변경할 수 있다는 점을 인지해야 한다.
-
-그렇다고 코드에 주석을 많이 달라는 것이 아닌 코드 자체를 읽기 쉽게 만들어야 한다.(본인이든 남이든)
-
-**다른 개발자는 무의식중에 여러분의 코드를 망가뜨릴 수 있다.**
-
-내가 작성한 코드는 생각보다 많은 의존성을 가지게 될 것이다.
-
-또한 코드자체도 환경이나 요구사항으로 인해 많이 변화할 것이기 때문에 병합전에 이런 문제를 제대로 확인하고 넘어가야 한다.
-
-의도지 않게 문제가 발생하게 되면 찾기 쉽지 않기 때문에..
-
-**시간이 지남에 따라 자신의 코드를 기억하지 못한다.**
-
-당장 저번달 작성한 코드도 기억안나고 읽히지도 않기 때문에..ㅜ
-
-#### 여러분이 작성한 코드의 사용법을 다른 사람들은 어떻게 아는가?
-
-API 공개수준이외에도 내가 작성한 코드가 무슨 목적을 가지고 있는지 파악해야 한다.
-
-* 여러 가지 상황에서 어떤 함수를 호출해야 하는지
-* 클래스가 무엇을 나타내는지 그리고 언제 사용되어야 하는지
-* 어떤 값을 인수로 사용해야 하는지
-* 코드가 수행하는 동작이 무엇인지
-* 어떤 값을 반환하는지
-
-> 1년이 지나면 자신이 작성한 코드라도 까먹기 때문에 미래의 자신은 본질적으로 다른 개발자라고 간주한다.
-
-따라서 다른 개발자가 내가 작성한 코드를 알아내기 위해선 다음과 같은 추리를 한다.
-
-1. 함수, 클래스, 열거형 등의 이름을 살펴본다.
-2. 함수와 생성자의 매개변수 유형 또는 반환값의 유형 같은 데이터 유형을 살펴본다.
-3. 함수/클래스 수준의 문서나 주석문을 읽어본다.
-4. 직접 와서 묻거나 채팅/이메일을 통해 물어본다.
-5. 여러분이 작성한 함수와 클래스의 자세한 구현 코드를 읽는다.
-
-이름 짓기의 경우 농담식으로 가장 오래걸리는 코딩작업이라고 한다.
-
-그만큼 다른 개발자(미래의 나)가 볼 때 직관성 띄기 때문에 바로바로 추론이 가능하다.
-
-멘토님의 말대로 클래스 이름과 퍼블릭 메서드만 나열해도 해당 클래스의 목적이 보여야 한다.
-
-#### 코드 계약
-
-계약에 의한 프로그래밍(programming by contract) 또는 계약에 의한 디자인(design by contract)라는 용어를 접해본적이 있을 것이다.
-
-~~나는 없다..~~
-
-이 방법론은 서로 다른 코드 간의 상호작용을 마치 계약처럼 생각한다는 점이다.
-
-계약은 3가지 범주로 나뉜다.
-
-* 선결 조건: 코드를 호출하기 전에 사실이어야 하는 것, 예를 들어 시스템이 어떤 상태에 있어야 하는지, 코드에 어떤 입력을 공급해야 하는지와 같은 사항
-* 사후 조건: 코드가 호출된 후에 사실이어야 하는 것, 예를 들어 시스템이 새로운 상태에 놓인다든지..
-* 불변 사항: 코드가 호출되기 전과 후에 시스템 상태를 비교해서 변경되지 않아야 하는 사항
-
-개발자가 계약의 일부 혹은 모든 조건을 알지 못하면 코드 계약에 문제가 발생한다.
-
-따라서 계약내용이 무엇일지, 코드를 사용하는 사람이 계약을 파악하고 따라갈 수 있을지에 대한 생각을 해야한다.
-
-코드를 오용할 수 있는 방법이 많을수록 실제로 오용되고 버그가 많이 있음을 시사한다.
-
-따라서 방어적인 프로그래밍 자세를 취하는게 좋아보인다.
-
-세부조항으로 문서나 주석을 통해 경고하는 것 보다 애초에 불가능하게 만드는 것이 좋다.
-
-내부적으로 예외를 많이 두어서 다른 방향으로 오용된다면 다른 개발자는 버그라고 생각
-
-*책에서는 생성자를 가려서 애초에 원하는 방법으로 객체를 생성하게 막아둠*
-
-#### 상태와 가변성
-
-객체지향에서 상태는 객체가 담고있는 어떤 값이나 데이터를 말한다. 이러한 상태를 생성 이후에 수정이 가능하다면 가변적, 반대로 수정이 불가능 하다면 불변적이라고 칭한다.
-
-### 느낀점
-
-세부조항의 부분이 많이 생각하게 된다.
-
-이전에 기본 c라이브러리 함수를 구현한 적이 있는데 완벽한 함수를 만들겠다고 null에대한 예외처리 등 들어오는 값에 대한 예외를 되게 크게 잡았다.
-
-이후에 그게 틀렸다는 것만 알고 있었는데 이제와서 정리가 되는 것 같다.(의도하지 않은 동작, 오용)
-
-지금 생각해보면 좋은 경험이였다.
-
-뒤쪽의 체크, 어서션은 읽어도 이해가 잘 되지 않아서 어려웠다..ㅠ
-
-## 4장 오류
-
-> 코드가 실행되는 환경은 불완전하다.
-
-### 논의 사항
-
-실제로 예외를 구현해서 사용하는 경우가 많나요?
-
-대분의 예외는 만들어져있다고 알고 있었습니다.
-
-필요에 의해서 만들어진 예외는 어떤 경우가 있는지 궁금합니다.
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 시스템이 복구할 수 있는 오류와 복구할 수 없는 오류의 구분
-* 신속하게 실패하고 분명하게 실패함
-* 오류를 전달하기 위한 다양한 기법과 선택을 위한 고려 사항
-
-#### 복구 가능성
-
-소프트웨어에 대해 생각할 때, 특정 오류가 발생한 경우 복구할 수 있는 오류와 복구할 수 없는 오류가 있다.
-
-즉, 오류가 발생했을 때 무엇을 할 것인지 결정하기 위해서는 자신의 코드가 어떻게 사용될 것인지 신중하게 생각해야한다.
-
-* 복구 가능한 오류
-
-전화번호를 예로 유효하지 않은 입력값이 들어왔을 때 전체시스템 작동을 멈춘다면 문제가 될 수 있다.
-
-따라서 오류메세지를 제공하고 다시 요청하는 것이 낫다.
-
-이 내용을 읽고 처음 든 생각은 하나의 함수 자체에서 널값이 들어왔을 때 `nullreferenceexception`이 발생하고 예외처리를 따로 하지 않았다면 시스템자체가 멈추게 된다.
-
-이러한 예외를 막고자 앞에서 말했던 방어적 프로그래밍으로 일어날 수 있는 예외를 사전에 미리 차단하는 것도 중요하다.
-
-그렇다면 여기서 또 의문이다. 3장에서 말했던 광범위한 함수 내부에서 예외처리를 하게 된다면 함수를 오용하게 되고 함수 자체의 성격도 옅어지게 된다.
-
-이러한 문제에서 절충점이 뭘까 생각하니 위에서 말한 함수내부에서 처리하지 않고 외부로 반환값을 줘서 해당 경우에 대한 예외레벨에서 처리하는 것이다.
-
-이게 맞는 방법인지는 잘모르겠지만.. 지금의 생각은 이렇다..
-
-* 복구할 수 없는 오류
-
-오류가 발생하고 시스템이 오류를 복구할 수 있는 합리적인 방법이 없을 때가 있다.
-
-대부분 프로그래밍 오류때문에 발생한다.
-
-* 코드와 함께 추가되어야 하는 리소스가 없다.
-* 어떤 코드가 다른 코드를 잘못 사용한다.(잘못된 인수, 사전에 초기화 작업x)
-
-개발자가 이러한 오류를 해결하는 방법인 일찍이 오류를 발견하고 해결하는 것..
-
-> 신속한 실패
-
-#### 견고성과 실패
-
-소프트웨어가 오류가 발생한다면 실패와 견고성중 하나를 선택해야 한다.
-
-실패의 경우는 더 높은 계층이 오류를 처리하게 하거나 전체 프로그램의 작동을 멈추게 한다.
-
-오류는 처리하고 계속 진행한다.
-
-후자의 경우는 실행자체에 문제가 없으니 견고한 코드라고 볼 수 있지만 위험부담을 그 만큼 가지고 갈 수 있다.
-
-**신속하게 실패하라**
-
-말 그대로 실패를 두려워 하지 않고 오류를 훌룡하고 안전하게 복구할 수 있는 기회라고 생각하는 것이다.
-
-이 또한 계층을 나누고 세분화를 통해 모듈화를 하게 되면 테스트에 용이하고 이 처럼 실패를 쉽게 만날 수 있다.
-
-**요란하게 실패하라**
-
-오류가 발생하는데도 불구하고 아무도 모르는 상황을 막고자 하는 것이다.
-
-이를 위한 가장 명백한 방법은 예외를 발생해 프로그램이 중단되게 하는 것
-
-오류를 서버에 기록하는 방식의 내용이 나왔는데 가끔 프로그램에서 오류가 발생하면 해당 로그를 보내달라는 메세지같이 오류를 수집하는 내용도 흥미로웠다..
-
-#### 오류를 숨기지 않음
-
-오류를 숨겨서 프로그램의 동작이 문제가 없어 보여도 오류를 숨기는 것은 복구할 수 있는 오류와 복구할 수 없는 오류 두가지 문제를 모두 일으킨다.
-
-**기본값 반환**
-
-오류가 발생하고 함수가 값을 반환할 수 없을 때 기본값을 반환하는 것은 간단하고 쉬운 해결책처럼 보일 수 있다.
-
-이는 오류를 숨기는데 있어서 호출하는 쪽에서는 모든 것이 정상처럼 작동한다.
-
-당장 치명적인 오류를 가져올 수 있고 이후에 찾기 힘든 오류로 전락할 수 있다.
-
-**널 객체 패턴**
-
-개념적으론 기본값과 유사하지만 이것을 더 확장하여 더 복잡한 객체를 다룬다.
-
-널 객체는 실제 반환값처럼 보이지만 모든 멤버 함수는 아무것도 하지 않거나 의미 없는 기본값을 반환한다.
-
-**아무것도 하지 않음**
-
-코드가 무언가를 반환하지 않고 단지 어떤 작업을 수행하는 경우, 문제가 발생할 때 가능한 한 가지 옵션은 오류가 발생했다는 신호를 보내지 않는 것이다.
-
-#### 오류 전달 방법
-
-오류가 발생하면 일반적으로 더 높은 계층에게 알려야 한다.
-
-오류로부터 복구할 수 없는 경우 일반적으로 훨씬 높은 계층에서 실행을 중지하고 오류를 기록하거나 프로그램의 종료하는 것을 의미한다.
-
-* 명시적 방법: 코드를 직접 호출한 쪽에서 오류가 발생할 수 있음을 인지할 수 밖에 없도록 한다.
-* 암시적 방법: 코드를 호출하는 쪽에 오류를 알리지만, 호출하는 쪽에서 그 오류를 신경쓰지 않아도 된다.
-
-#### 예외
-
-예외라는 개념은 코드에서 오류나 예외적인 상황이 발생한 경우 이를 전달하기 위한 방법으로 고안되었다.
-
-일반적으로 예외 또한 충분한 기능을 가진 클래스로 구현되며, 요구사항에 맞춰 예외를 정의하고 구현할 수 있다.
-
-* 명시적 방법: 검사 예외
-
-컴파일러는 검사 예외에 대해 호출하는 쪽에서 예외를 인지하도록 강제적으로 조치하는데, 호출하는 쪽에서 예외 처리를 위한 코드를 작성하거나 자신의 함수 시그니처에 해당 예외 발생을 선언해야 한다.
-
-*함수 시그니처란? 함수 원형에 명시되는 매개변수 리스트를 가리킨다.*
-
-* 암시적 방법: 비검사 예외
-
-비검사 예외를 사용하면 다른 개발자들은 코드가 이 예외를 발생시킬 수 있다는 사실을 전혀 모를 수 있다.
-
-이 경우에는 함수에서 어떤 예외를 발생시키는지 문서화를 하는 것이 바람직하지만 이 과정조차도 잊어버릴 때가 있다.
-
-하지만 이러한 문서화 작업은 앞서 다룬 세부조항이기 때문에 신뢰할 방법이 아니다.
-
-따라서 비검사 예외는 오류가 발생할 수 있다는 것을 호출하는 쪽에서 인지하리라는 보장이 없기 때문에 오류를 암시적으로 알리는 방법이다.
-
-* 명시적 방법: 널값이 가능한 반환 유형
-
-함수에서 널값을 반환하는 것은 특정값을 계산하거나 얻는 것이 불가능함을 나타내기 위한 효과적이고 간단한 방법이다.
-
-*구현 내용 ](https://fkdl0048.github.io/patterns/Patterns_Builder/)
-
-* 쓰기 시 복사 패턴
-
-이 패턴의 핵심은 앞서 다룬 `messageBox.renderTitle()`의 객체의 필드 값을 건드리기 때문에 애초에 새로운 불변 클래스를 생성하여 반환하는 것이다.
-
-애초에 생성 시 기본 생성자에선 필수로 필요한 필드만 초기화를 하고 가변되어 생성될 필드는 null 초기화한다.
-
-이후 메서드를 통해 사이즈나 폰트를 매개변수로 넘겨 새로운 객체를 반환하는 것
-
-원래 생성한 객체는 불변성을 유지할 수 있게 된다.
-
-#### 객체를 깊은 수준까지 불변적으로 만드는 것을 고려하라
-
-앞선 조언들을 따라서 불변성의 이점을 지키더라도 무심코 클래스가 가변적으로 될 수 있는 미묘한 경우를 간과하기 쉽다.
-
-이는 일반적으로 **깊은 가변성**때문이다.
-
-##### 깊은 가변성은 오용을 초래할 수 있다
-
-예제에서 처럼 참조로 인한 깊은 가변성이 발생할 수 있다.
-
-TextOptions클래스는 참조를 가지고 있기 때문에 다른 코드에서 해당 참조를 가지고 있다면 변경에 따른 영향을 받을 수 있다.
-
-실제로 경험해본 문제라 찾기도 힘들었고 참조에 대한 문재점도 다시 생각해본 예제이다.
-
-두가지 시나리오지만 결국 동일한 참조를 가지고 있다는 점이 핵심이다.
-
-##### 방어적으로 복사하라
-
-동일한 참조를 가지는 것이 의도되었다면 유연한 기능이지만 이 처럼 오용될 수 있다면 치명적이다.
-
-따라서 얕은 복사가 아닌 깊은 복사를 통해 유일성을 확보한다.
-
-객체를 생성할 때 생성자로 리스트에 대한 참조를 받지만 생성 단계에서 copy하여 가지고 있고, getter을 통한 접근은 새로운 객체를 생성하여 반환한다.
-
-getter로 접근할 때 마다 새로운 객체가 생성되는 점에서 약간 위험할 수 있다는 생각이 든다..
-
-`readonly`라고 해서 불변성이 보장된다는 것이 아니라는것에 명심해야 한다.
-
-##### 불변적 자료구조를 사용하라
-
-앞서 말한 복사본을 생성하지 않아도 되는 경우가 자료구조 자체가 불변적이라면 객체자체를 전달할 수 있다.
-
-따라서 불변적인 자료구조를 사용하는 것은 클래스가 깊은 불변성을 갖도록 보장하기 좋은 방법 중 하나다.
-
-#### 지나치게 일반적인 대이터 유형을 피해라
-
-정수, 문자열 및 리스트 같은 간단한 데이터 유형은 코드의 기본적인 구성 요소 중 하나다.
-
-쉽게 사용가능하고 다재다능하지만 정수나 리스트와 같은 유형으로 표현이 가능하다고 해서 그것이 반드시 좋은 방법이 아니다.
-
-설명이 부족하고 허용하는 범위가 넓을수록 코드 오용은 쉬워진다.
-
-##### 지나치게 일반적인 유형은 오용될 수 있다
-
-이 내용의 핵심은 앞 장에서 설명한 다른 개발자가 읽자마자 알수있어야 한다는 점이다.
-
-위치를 사용할 때 `List`가 아닌 `Position`이라는 새로운 클래스나 구조체를 사용하는 것 처럼 오용되기 쉬운 일반적인 데이터를 피해야 한다.
-
-함수자체에서 문서나 명명된 인수를 사용할 수 있지만 좋은 방법은 아닌 것 같다..
-
-##### 페어 유형은 오용하기 어렵다
-
-페어 유형자체를 처음 봤다.
-
-튜플과 비슷한 것 같다..?
-
-내용의 핵심은 마찬가지로 문서가 필요하고 여전히 의미를 이해하기 어렵다는 점이다.
-
-##### 전용 유형 사용
-
-새로운 클래스나 구조체를 정의하는 것이 많은 노력이 들어가고 블필요해보일 수 있지만 보기보다 쉽고 버그의 가능성을 줄여준다.
-
-예제와 같이 위도와 경도를 나타내는 클래스를 정의하여 사용
-
-마찬가지로 같은 자료형이라고 Vector를 사용하거나, Position클래스를 다시 사용하는게 아닌 새로 정의하는 것이다.
-
-#### 시간 처리
-
-시간을 다룰 때 코드를 잘못 사용하고 혼동을 일으킬 여지가 굉장히 많다.
-
-* 절대적인 시간과 상대적인 시간의 표현법
-* 시간의 양을 표현
-* 표준시간대, 윤년등 다양한 시간 개념
-
-##### 정수로 시간을 나타내는 것은 문제가 될 수 있다
-
-시간을 나타낼 때 일반적으로 정수나 큰 정수를 사용한다.
-
-이것으로 한순간을 의미하는 시각과 시간의 양을 표현한다.
-
-* 순간으로서의 시간은 유닉스 시간(unix epoch)인 1970년 1월 1일 00:00:00 UTC 이후 몇 초로 표현한느 경우가 많다.
-* 양으로서의 시간은 초 혹은 밀리초 단위로 표시할 때가 많다.
-
-정수는 매우 일반적인 유형이기 때문에 시간을 나타내는 데 사용하는 경우 코드가 오용되기 쉽다.
-
-한순간의 시간인지, 아니면 시간의 양인가?
-
-책에서 보여주는 예처럼 매개변수로 시간을 전달할 때 해당 시간이 순간인지 양인지는 정수로 표현하면 알 수 없다.
-
-문서를 작성하는게 되면 세부조항이 늘어나고 좋은 방법이 아니다.
-
-코드에서 사용하는 초만 따져도 millisecond, second, microsecond와 같은 단위도 사용한다.
-
-함수이름이나 매개변수, 주석문으로 방어한다고 해도 여전히 코드를 오용하기 쉽다..
-
-**시간대 처리 오류**
-
-예제와 같이 같은 시간이라도 다른 표준 시간대로 설정한 경우에는 잘못된 값을 받을 수 있다.
-
-##### 적절한 자료구조를 사용하라
-
-우리가 알 수 있듯이 시간을 다루는 것은 복잡하고 까다로운 일이며 혼란의 여지가 많다.
-
-C#의 Noda..? [관련 링크.. ](https://nodatime.org/)
-
-이러한 강력한 외부 라이브러리를 사용하여 알맞은 자료구조를 사용하면 나타내고자하는 바가 명백하다.
-
-물론 필요에 의해 제작할 수 있지만, 대부분 시간에 관한 내장라이브러리나 외부 라이브러리를 활용하자..
-
-#### 데이터에 대해 진실의 원천을 하나만 가져야 한다
-
-코드에서 숫자, 문자열, 바이트 스트림과 같은 종료의 데이터를 처리하는 경우가 많다.
-
-데이터는 종종 두 가지 형태로 제공된다.
-
-* 기본 데이터: 코드에 제공해야 할 데이터, 코드에 이 데이터를 알려주지 않고는 코드가 처리할 방법이 없다.
-* 파생 데이터: 주어진 기본 데이터에 기반해서 코드가 개선할 수 있는 데이터
-
-간단한 예제로 은행계좌시스템에 대변금액과 차변금액은 기본 데이터, 계좌 잔액은 파생데이터로 대변에서 차변을 뺀 금액이다.
-
-기본데이터는 프로그램의 **진실의 원천**이 된다.
-
-##### 또 다른 진실의 원천은 유효하지 않은 상태를 초래할 수 있다
-
-다른 예제로 `Vector3`라는 구조체가 x, y, z의 값을 들고 있을 때 x, y, z는 기본 데이터가 되고 이에 대한 방향 벡터를 구한다고 한다면
-
-기본데이터의 연산을 통해 구해야 정확할 것이다.
-
-하지만 해당 값을 매번 계산하는 것이 아닌 데이터에 담아두게 된다면 맞니 않는 값을 갖게 되고 이것이 두개의 진실의 원천을 같는 예이다.
-
-```cs
-public float magnitude { get { return Mathf.Sqrt(x * x + y * y + z * z); } }
-public MyVector normalized => new MyVector(x / magnitude, y / magnitude, z / magnitude);
-```
-
-*파생 데이터는 매번 계산하는 것이 바람직하다.*
-
-##### 기본 데이터를 유일한 진실의 원천으로 사용하라
-
-예제와 같이 생성자로 불변성을 확보한 필드를 각각 계산하여 파생데이터를 반환한다.
-
-하지만 데이터의 계산에 비용이 많이 드는 경우에는 그 값을 지연계산한 후 결과를 캐싱하는 것이 좋다.
-
-동작과정이 Linq와 비슷하다는 생각이 들었다..
-
-Linq또한 값을 확인 할 때 동작한다고 알고 있는데 연관이 있는지 궁금하다..
-
-마찬가지로 데이터가 불변적이 아니라면 더욱 복잡해지기 때문에 앞서 다룬 객체를 불변적으로 다뤄야 한다는 것 의미한다.
-
-#### 논리에 대한 진실의 원천을 하나만 가져야 한다
-
-진실의 원천은 코드에 제공된 데이터에만 해당되는 것이 아니라 코드에 포함된 논리에도 적용된다.
-
-##### 논리에 대한 진실의 원천이 여러개 있으면 버그를 유발할 수 있다
-
-이런 경우가 있을지 모르겠지만 대규모 프로젝트의 경우에는 발생할 수 있는 문제인 것 같다..
-
-Json파일을 직렬화 역직렬화하는 과정에서 서로 다른 유틸리티를 사용하거나.. CSV를 통한 Read에서 다른 논리를 사용한다면 문제가 될 수 있다.
-
-##### 진실의 원천은 단 하나만 있어야 한다
-
-예제와 같이 동일한 진실의 원천을 가질려면 동일한 클래스를 가지는 것이다.
-
-하위문제를 담당하는 클래스를 상위 수준 문제에서 동일한 로직으로 가지게 된다면 코드는 더욱 견고해진다.
-
-### 느낀점
-
-코드를 오용하기 어렵게 만드는 방법을 읽고 느낀점은.. 어렵고 불편하게 만들어야 단단하고 가독성이 올라가는 것 같다.
-
-시작할 때 나온 말처럼 결국 가장 빠른길이 가장 느린길이였다는 생각이 드는 파트..
-
-다양한 방법들이 있지만 전부 명백해야 하고 어려운 구조를 가져야 한다.
-
-*유일성*
-
-## 8장 코드를 모듈화하라
-
-> 요구사항이 어떤 식으로든 바뀐다는 점은 확신할 수 있다.
-
-### 논의 사항
-
-데이터 객체에 대한 생각이 궁금합니다.
-
-저는 데이터객체를 사용하는 것이 바람직하다고 생각은 들지만 만약 소프트웨어의 덩치가 커짐에 따라 데이터 객체가 많이 세분화 되거나 하나의 데이터객체가 점점 커져서 필요 이상의 덩치를 가지게 될 것 같다는 생각이 듭니다.
-
-그대로 진행하게 되면 너무 세분화된 데이터 클래스가 많아서 헷갈리게 되면 결국 문서화로 이어지게 되고 한가지 데이터 객체가 너무 많은 부담을 받아서 문제가 발생한 경우에는 수정하기 어려움도 커질 것 같습니다.
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 모듈화된 코드의 이점
-* 이상적인 코드 모듈화가 되지 않는 일반적인 방식
-* 코드를 좀 더 모듈화하기 위한 방법
-
-모듈화의 주된 목적 중 하나는 향후에 어떻게 변경되거나 재구성될지 정확히 알지 못한 상태에서 변경과 재구성이 용이한 코드를 작성하는 것이다.
-
-이를 달성하기 위해선 각각의 기능이 코드베이스의 서로 다른 부분에서 구현되어야 한다는 것이다.
-
-이것이 달성된다면 요구 사항 중 하나가 변경된다면, 코드 베이스에서 그 요구 사항이나 기능과 관련된 부분만 수정하면 된다.
-
-즉, 추상화 개념이 핵심이며 하위 문제에 대한 해결책의 자세한 세부사항들이 독립적이고 서로 밀접하게 연관되지 않도록 하는 것(디커플링)으로 귀결된다.
-
-이렇게 하면 적응성이 뛰어난 코드가 될 뿐만 아니라 소프트웨어 시스템에 대한 추론을 쉽게 해준다.
-
-모듈화된 코드는 재사용과 테스트에 더욱 적합하기 때문에 많은 이점을 가진다.
-
-#### 의존성 주입의 사용을 고려하라
-
-일반적으로 클래스는 다른 클래스에 의존한다.
-
-높은 수준의 문제를 하위 문제들로 나눠서 해결하는 방법을 알아봤다.
-
-여기서 하위 문제에 대한 해결책이 항상 하나만 존재하는 것은 아니므로 하위 문제를 재구성할 수 있는 방식으로 코드를 작성하는 것이 유용할 수 있다.
-
-*DI(dependency Injection)*
-
-[DI 정리글 ](https://fkdl0048.github.io/patterns/Patterns_DI/)
-
-##### 하드 코드화된 의존성은 문제가 될 수 있다
-
-하드코드로 구현된 종속성코드의 예제로 나름 인터페이스를 사용해서 클래스를 구현했지만 생성자에서 의존성을 따로 주입하지 않았기 때문에 코드 자체에 하드코딩이 들어갔다.
-
-이렇게 구현할 일이 있을까 싶다가 앞서 말한 요구사항을 생각하지 않고 급하게 만들면 이렇게 할수도 있겠다는 생각이..
-
-##### 의존성 주입을 사용하라
-
-의존성 주입을 사용하게 되면 일단 디커플링이 이뤄낼 수 있고 다형성을 가져갈 수 있다.
-
-인터페이스로 추상화까지..
-
-또한 의존성 주입을 통한 팩토리함수를 사용하여 입구와 출구를 하나로 만들어서 쉽게 관리할 수 있다.
-
-여기 나온 내용이 저번 아카데미 컨퍼런스에서 끝나고 이야기를 나눴던 내용인 것 같다..
-
-[Factory Method Pattern 정리글 ](https://fkdl0048.github.io/patterns/Patterns_FactoryMethod/)
-
-그나저나 `CreateDefaultNorthAmericaRoutePlanner()`메서드 명이 진짜 길다.
-
-필수로 들어가야하는 내용은 잘 들어간 것 같은데 이 정도면 길다고 말할 수 없는건지 궁금하다.
-
-**의존성 주입 프레임워크**
-
-의존성 주입은 클래스를 좀 더 변경할 수 있게 해주는 장점이 있지만, 생성하는 부분의 코드는 더 복잡해진다는 단점이 있다
-
-이를 해결하기 위해 팩토리 함수를 작성할 수도 있지만 그 또한 대응되는 클래스를 만들어야하고 반복적으로 작성하는 코드가 많아질 수 있다.
-
-**제네릭을 사용한다면..?**
-
-아직 의존성 주입 프레임워크를 많이 접해보지 못해서 어떤 형태로 존재하는지 모르겠다..
-
-검색해도 안나오다니..
-
-##### 의존성 주임을 염두에 두고 코드를 설계하라
-
-코드를 작성할 때 의존성 주입을 사용할 수 있다는 점을 의식적으로 고려하는 것이 유용할 때가 있다.
-
-코드를 작성하다 보면 나중에는 의존성 주입을 사용하고 싶어도 사용이 거의 불가능한 코드가 짜여질 수 있기 때문이다.
-
-처음부터 정적함수에 의존하는 형태로 작성한 예를 보면 의존성 주입을 넣고 싶어도 넣지 못하는 문제가 발생한다.
-
-하위 문제를 해결할 때 그것이 문제에 대한 유일한 해결책이라고 생각하기 쉽다.
-
-이러한 문제를 해결할 때 쉽게 정적함수로 해결하면 쉽게 해결되기 때문에 별 생각없이 `정적 매달림`에 빠질 수 있다.
-
-정적함수는 대부분 Util성격의 함수로 구성된 하나의 해결책만 있는 근본적인 하위 문제를 다루는 것이 좋다.
-
-#### 인터페이스에 의존하라
-
-의존할꺼면 인터페이스에 의존해라..!!
-
-앞서 다룬 예제와 같이 모듈화를 위해선 인터페이스를 정말 잘 활용해야 한다.
-
-##### 구체적인 구현에 의존하면 적응성이 제한된다
-
-앞서 다룬 안좋은 예제의 버전 2다..
-
-생성자 자체를 클래스로 가져가기 때문에 (추상클래스 제외)적응성이 제한되게 된다.
-
-##### 가능한 경우 인터페이스에 의존하라
-
-구체적인 구현 클래스에 의존하면 인터페이스를 의존할때 보다 적응성이 제한되는 경우가 많다.
-
-인터페이스는 하위 문제를 해결하기 위한 추상화 계층을 제공하는 것으로 생각할 수 있다.
-
-**클래스가 인터페이스를 상속받아 구현하고 인터페이스가 필요한 동작을 정의한다면 이것은 곧 다른 개발자가 해당 인터페이스에 대해 다르게 구현한 클래스를 작성할 수 있다는 것을 강력하게 시사한다.**
-
-*의존성 역전 원리: 보다 구체적인 구현보다는 추상화에 의존하는 것이 낫다는 생각의 핵심*
-
-#### 클래스 상속을 주의하라
-
-대부분 객체지향 프로그래밍 언어의 핵심 기능 중 하나는 한 클래스가 다른 클래스를 상속할 수 있다는 것이다.
-
-클래스 상속은 확실히 쓸모가 있고 때로는 적합한 도구이다.
-
-두 가지 사물이 진정한 is-a 관계를 갖는다면 상속이 적절할 수 있다.
-
-상속은 강력한 도구지만, 몇 가지 단점이 있고 상속이 야기하는 문제가 치명적일 수 있기 때문에 한 클래스가 다른 클래스를 상속하는 코드를 작성하는 것에 대해서는 신중하게 생각해야 한다.
-
-상속을 사용할 수 있는 많은 상황에서 구성을 상속 대신 사용할 수 있다.
-
-클래스를 확장하기보다는 인스턴스를 가지고 있음으써 한 클래스를 다른 클래스로부터 구성할 수 있다.
-
-구성도 멘토님과 추상클래스에 대해서 조언을 구할 때 알려주신 방법으로 상속이 익숙하지 않다면 먼저 해볼 것을 추천해주셨다.
-
-**구성**은 컴포넌트 패턴과 같은 개념인 것 같다..
-
-[Component 정리글 ](https://fkdl0048.github.io/patterns/Patterns_Component/)
-
-처음 한 10개월 전에 C#을 공부하기 시작하면서 "상속은 좋은 거구나..!"하며 뭔갈 해볼려고 상속을 무작정사용하던 생각이 난다..
-
-지금도 상속을 잘 사용하고 싶지만 어렵지만 반드시 상속을 해야하는게 아니라는 것을 알게된 것 같아서 좋다.. 그래도..
-
-##### 클래스 상속은 문제가 될 수 있다
-
-상속의 예로 많이 나오는 Animal이나 Vehicle예제는 상속의 의미자체는 잘 전달하지만 개발자들이 만나게 되는 함정을 설명하기엔 너무 추상적이다.
-
-상속에서 발생하는 현실적인 문제들을 다룬 예를 살펴보자
-
-쉼표로 구분된 정수를 가지고 있는 파일을 열어서 정수를 하나씩 읽어 들이는 클래스를 작성해야 한다고 가정해보자.
-
-이 문제에 대한 하위 문제는 다음과 같다.
-
-* 파일에서 데이터를 읽는다.
-* 쉼표로 구분된 파일 내용을 개별 문자열로 나눈다.
-* 각 문자열을 정수로 변환한다.
-
-*지금보니 하위문제를 추출하는 방법으로 상위문제에 대한 하위문제를 이 처럼 글로 나열하는 방법이 다시한번 좋다는 걸 알았다.*
-
-상속에서 가장 강조되는 부분은 **확장**의 개념이다.
-
-**상속은 추상화 계층에 방해가 될 수 있다.**
-
-한 클래스가 다른 클래스를 확장하면 슈퍼클래스의 모든 기능을 상속한다.
-
-이러한 기능은 유용할 때가 있지만, 원하는 것보다 더 많은 기능을 도출할 수도 있다.
-
-이로 인해 추상화 계층은 복잡해지고 구현 세부 정보가 드러날 수 있다.
-
-물론 추상화 클래스를 잘 설계하여 상속 받아서 만든다면 문제가 세부정보를 가릴 수 있다.
-
-하지만 요구사항이 변동되거나 데이터를 예측하기에 어렵고, 순수한 추상클래스를 만들기 어렵다.
-
-**상속은 적응성 높은 코드의 작성을 어렵게 만들 수 있다.**
-
-요구사항이 변동되어 쉼표뿐만 아니라 세미콜론으로 구분된 값도 읽을 수 있어야 한다고 가정해보자.
-
-그런데 이미 세미콜론으로 구분된 값을 읽을 수 있는클래스가 있다는 것을 알게 됐다.
-
-따라서 쉼표구분클래스 대신 세미콜론클래스를 상속하도록 바꾸면 될 것 같지만 그렇지 않다.
-
-유일한 해결방법은 새 클래스를 만들어 상속받아 구현하는 것이다.
-
-하지만 만들고 본다면 중복되는 코드들이 눈에 보일 것이고.. 유지보수 비용과 버그 발생 가능성을 높이기 때문에 바람직하지 않다.
-
-##### 구성을 사용하라
-
-상속을 원래 사용한 동기는 쉼표로 구분하여 읽는 클래스의 일부 기능을 재사용하는 것이었다.
-
-앞서 발견한 몇 가지 단점이 존재하기 때문에 쉼표 클래스의 기능을 재사용하는 방법으로 구성을 사용하는 것이다.
-
-즉, 클래스를 확장하기보다 해당 클래스에서 인스턴스를 가지고 있음으로써 하나의 클래스를 다른 클래스로부터 **구성**한다는 것을 의미한다.
-
-8.15예제 정말 깔끔하다ㅠ..
-
-**더 간결한 추상화 계층**
-
-상속을 사용할 때 서브 클래스는 슈퍼클래스의 모든 기능을 상속하고 외부로 제공한다.
-
-이것은 외부로 노출하고 싶어하지 않는 API까지 만들어진다.
-
-상속 대신 구성을 사용하면 클래스가 전달이나 위임을 사용하여 명시적으로 노출하지 않는 한 해당 클래스의 기능이 노출되지 않는다.
-
-**적응성이 높은 코드**
-
-여기서 쉼표나 세미콜론에 해당되는 인터페이스를 기능으로 구분하여 제공하면 좀 더 적응성이 높은 코드로 이어진다.
-
-##### 진정한 is-a 관계는 어떤가?
-
-앞 서 두 클래스가 진정한 is-a 관게를 맺고 있다면 상속이 타당할 수 있다고 언급했다.
-
-Car is a Vehicle의 관계는 명확하기 때문에 확장할 수 있다.
-
-하지만 앞서 다룬 예제는 is-a관계라고 보기 어렵다.
-
-*FileHandler -> 관계의 파생은 괜찮아 보인다.*
-
-내 생각은 기능적인 부분이기 때문에 인터페이스를 통한 (각각의 명확한 기능을 명시) 구성이 제일 좋아보이는데 책에서 말하는대로 답은 없으며 주어진 상황과 작업중인 코드에 따라 다르다.
-
-진정한 is-a관계라도 상속하는 것에 대한 여전히 문제가 될 수 있음을 알아야 한다.
-
-다음과 같이 몇가지 주의할 점이 있다.
-
-* **취약한 베이스 클래스 문제**
-
-서브클래스가 슈퍼클래스에서 상속되고 해당 슈퍼클래스가 나중에 수정되면 서브클래스가 작동하지 않을 수도 있다.
-
-* **다이아몬드 문제**
-
-일부 언어는 두 대 이상의 슈퍼클래스를 확장할 수 있는 **다중 상속**을 지원한다. 여러 슈퍼 클래스가 동일한 함수의 각각 다른 다른 버전을 제공하는 경우에 어떤 슈퍼클래스로부터 함수를 상속받아야 하는지 모호하기 때문이다.(죽음의 다이아몬드라고 알고 있었다.)
-
-* **문제가 있는 계층 구조**
-
-많은 언어가 다중 상속을 지원하지 않으므로 클래스는 오직 하나의 클래스만 직접 확장할 수 있다. 이를 **다중상속**이라고 하며 다른 유형의 문제가 발생할 수 있다.
-
-Car라는 클래스와 AirCraft라는 클래스가 있다고할 때 FlyingCar는 어떤 클래스를 상속받아야 할까?
-
-따라서 단일 상속만 가능한 경우 논리적으로 둘 이상의 클래스에 속할때 문제가 발생할 수 있다.
-
-때로는 계층 구조를 피할 수 없는 경우도 있다.
-
-클래스 상속에 숨어 있는 많은 함정을 피하면서 계층 구조를 달성하기 위해선 다음과 같은 것을 할 수 있다.
-
-* 인터페이스를 사용하여 계층 구조를 정의한다.
-* 구성을 사용하여 코드를 재사용한다.
-
-#### 클래스는 자신의 기능에만 집중해야 한다
-
-모듈화의 핵심은 목표 중 하나는 요구사항이 변경되면 그 변경과 직접 관련된 코드만 수정한다는 것이다.
-
-이는 단일 개념이 단일 클래스 내에 완전히 포함된 경우라면 이 목표를 달성할 수 있다.
-
-어떤 개념과 관련된 요구 사항이 변경되면 그 개념에 해당하는 단 하나의 클래스만 수정하면 된다.
-
-이것과 반대되는 상황이 하나의 개념이 여러 클래스에 분산되는 경우다.
-
-해당 개념과 관련된 요구 사항을 변경하려면 관련된 클래스를 모두 수정해야 한다.
-
-이 때 개발자가 관련 클래스 중 하나를 잊어버리고 수정하지 않으면 버그가 발생할 수 있다.
-
-클래스가 다른 클래스의 세부 사항에 지나치게 연관되어 있을 때 이런 일이 흔히 일어날 수 있다.
-
-##### 다른 클래스와 지나치게 연관되어 있으면 문제가 될 수 있다
-
-책에서 주어진 예제와 같이 책과 챕터를 나타내는 클래스가 있다고 할 때 책클래스에 챕터 클래스가 **구성**되어 있다고 해서 구성된 클래스만을 다루는 코드를 책 클래스 내부에 만들게 되면 문제가 될 수 있음을 나타낸다.
-
-##### 자신의 기능에만 충실한 클래스를 만들라
-
-코드 모듈화를 유지하고 한 가지 사항에 대한 변경 사항이 코드의 한 부분만 영향을 미치도록 하기 위해, Book과 Chapter클래스는 가능한 란 자신의 기능에만 충실하도록 해야 한다.
-
-따라서 예제의 경우는 Book클래스에서 Chapter클래스의 함수를 사용하여 값을 반환한다.
-
-즉, 장의 단어를 세는 논리는 챕터클래스가 기능에 충실하게 가지고 있고 책은 해당 컨테이너의 역할로 존재
-
-**디미터의 법칙: 한 객체가 다른 객체의 내용이나 구조에 대해 가능한 최대한으로 가정하지 않아야 한다는 소프트웨어 공학 원칙이다.**
-
-클래스는 서로에 대한 어느 정도의 지식을 필요로 할 때도 있지만, 가능한 한 이것을 최소화하는 것이 좋을 때가 많다.
-
-이를 통해 코드 모듈화를 유지할 수 있으며 적응성과 유지 관리성을 크게 개선할 수 있다.
-
-#### 관련 있는 데이터는 함께 캡슐화하라
-
-2장에서 다룬 한 클래스가 대한 책임이 많아질수록 야기될 수 있는 문제점을 살펴보았다.
-
-너무 많은 것들을 한 클래스에 두지 않도록 주의해야 하지만 한 클래스안에 함께 두는 것이 합리적일 때는 그렇게 하는 것의 이점을 놓쳐서도 안 된다.
-
-서로 다른 데이터가 서로 밀접하게 관련되어 있어 그것들이 항상 함께 움직여야 할 때가 있다.
-
-이 경우에는 클래스로 그룹화하는 것이 합리적이다.
-
-이렇게 하면 코드는 여러 항목의 세부사항을 다루는 대신, 그 항목들이 묶여 있는 단일한 클래스가 제공하는 상위 수준의 개념을 다룰 수 있다.
-
-이를 통해 코드는 더욱 모듈화하고 변경된 요구사항을 해당 클래스에서만 처리할 수 있다.
-
-##### 캡슐화되지 않은 데이터는 취급하기 어려울 수 있다
-
-책에서 보여주는 예처럼 `displayMessage()`함수의 경우 uiSettings의 값을 읽어와서 전달한다.
-
-여기서 생기는 문제점은 새로운 renderType이 필요할 경우 매개변수를 하나 늘려서 UserInterface를 수정해야 하는 것을 의미한다.
-
-모듈화의 핵심은 요구사항에 발맞춰서 해당 부분만 수정해야 하지만, 서로 다른 데이터를 다룰 때 현재 메서드처럼 연관되어 있다면 전부 따라 올라가며 수정을 해줘야 한다.
-
-지금은 하나의 예지만 실제 프로젝트에선 더욱 다양한 값들을 추척해야 할것이다.
-
-*책에선 이러한 상황을 세부사항, 세부적인 내용으로 다룬다.*
-
-간단한 예시로 택배기사, 웨이터등 캡슐화된 데이터를 전달할 때는 해당 데이터가 뭔지 몰라야한다.
-
-하지만 지금의 형태는 displayMessage()함수는 전달하는 내용을 정확하게 알고 있어야 한다.
-
-##### 관련된 데이터는 객체 또는 클래스로 그룹화하라
-
-TextOptions 캡슐화 클래스를 만들어서 텍스트 사이즈, 폰트 등등을 캡슐화하여 인스턴스로 전달할 수 있다.
-
-이렇게 만들어 displayMessage()함수는 캡슐화된 데이터만 전달해주는 택배기사와 동일하다.
-
-#### 반환 유형에 구현 세부 정보가 유출되지 않도록 주의하라
-
-간결한 추상화 계층을 가지려면 각 계층의 구현 세부 정보가 유출되지 않아야 한다.
-
-구현 세부 정보가 유추되면 코드의 하위 계층에 대한 정보가 노출될 수 있으며, 향후 수정이나 재설정이 매우 어려워질 수 있다.
-
-코드에서 구현 세부정보를 유출하는 일반적인 형태 중 하나는 해당 세부 정보와 밀접하게 연결된 유형을 반환하는 것이다.
-
-##### 반환 형식에 구헌 세부 사항이 유출될 경우 문제가 될 수 있다
-
-말 그대로 반환 형식에 세부 구현 사항이 유출될 경우 문제가 될 수 있다.
-
-이는 앞서 다룬 참조에도 해당되는 이야기이며 세부 사항은 세부사항으로 만든 이유가 있기 때문이다.
-
-##### 추상화 계층에 적합한 유형을 반환해라
-
-외부로 노출할 개념을 최소화하는 유형을 새로 정의해 사용하면 좀 더 모듈화된 코드와 간결한 추상화 계층을 얻을 수 있다.
-
-#### 예외 처리 시 구현 세부 사항이 유출되지 않도록 주의하라
-
-구현 세부 정보가 유출될 수 있는 또 다른 일반적인 경우는 예외를 발생할 때다.
-
-##### 예외 처리 시 구현 세부 사항이 유출되면 문제가 될 수 있다
-
-비 검사 예외의 핵심 기능 중 하나는 예외가 발생하는 위치나 시기, 코드가 어디에서 그 예외를 처리하는지 등에 대한 그 어떠한 것도 컴파일러에 의해 강제되지 않는다는 것이다.
-
-인터페이스를 구현하는 클래스가 반드시 인터페이스가 규정하는 오류만 발생시켜야만 하는 것은 아니다.
-
-##### 추상화 계층에 적절한 예외를 만들라
-
-구현 세부 사항의 유츨을 방지하기 위해 코드의 각 계층은 주어진 추상화 계층을 반영하는 오류 유형만을 드러내는 것이 이상적이다.
-
-### 느낀점
-
-모듈화에 대한 지식이 뽝..!
-
-가장 신경써서 읽은 챕터중에 하나로 뒷 부분의 8.7 예외부분은 이해하기 어려웠고 중간에 서버관련 반환값도 조금 어려웠다.
-
-다른 예제는 직관적이고 이미 지키고 있거나 비슷한 예가 많아서 이해가 더 잘된 것 같다.
-
-오용과 마찬가지로 전체적으로 말하고자 하는 줄기는 비슷한 것 같다.
-
-앞의 내용들을 좀 더 세분화하여 예제로 보여주는 것 같았다.
-
-## 9장 코드를 재사용하고 일반화할 수 있도록 하라
-
-> 간결한 추상화 계층을 만들고 코드를 모듈화하면 하위 문제의 해결책이 서로 느슨하게 결합하는 코드로 나뉘어지는 경향이 있다.
-> 이렇게 되면 보통 코드를 재사용하고 일반화하기 휠씬 더 쉽고 안전해진다.
-
-### 논의사항
-
-실제 대형 프로젝트에는 전혀 전역상태가 없는 것인지 궁금합니다.
-
-흔히 말하는 싱글톤 == 안티패턴의 경우처럼 몇 백명이 모이면 확실히 없어야 안전하다는 생각은 들지만 진짜로 없는지 우회하거나 제한을 거는지 궁금합니다아
-
-### 책의 내용 및 정리
-
-핵심 주제
-
-* 안전하게 재사용할 수 있는 코드 작성 방법
-* 다양한 문제를 해결하기 위해 일반화된 코드를 작성하는 방법
-
-2장은 상위수준으 문제를 해결하기 위해 하위 문제로 세분화하는 방법에 대해 알아봤다.
-
-프로젝트를 연이어 하다 보면 종종 동일한 하위문제들이 계속해서 나오는 것을 발견한다.
-
-다른 개발자가 이미 주어진 하위 문제를 해결했다면, 해당 문제에 대한 해결책을 재사용하는 것이 바람직 하다.
-
-그렇다고 해서 항상 재사용할 수 있는 것은 아니다.
-
-다른 개발자가 구현한 해결책이 자신의 사례와 맞지 않는 가정을 하거나, 그 해결책에 자신에게 필요 없는 다른 기능과 함께 구성된 경우 이러한 문제가 발생할 수 있다.
-
-#### 가정을 주의하라
-
-코드를 작성 시 가정을 하면 코드가 더 단순해지거나, 더 효율적으로 되거나, 둘 다일 수도 있다.
-
-그러나 이러한 가정으로 인해 코드가 더 취약해지고 활용도가 낮아져 재사용성하기에 안전하지 않을 수 있다.
-
-이러한 점을 고려할 때, 코드 작성 시 가정을 하기 전에 그 가정으로 초래될 비용과 이점을 생각해봐야 한다.
-
-코드 단순화 또는 효율성의 명백한 이득이 미미하다면 늘어난 취약성으로 인한 비영이 장점을 능가하기 때문에 가정을 하지 않는 것이 최선일 수 있다.
-
-범용적인 클래스를 만들고 싶어서 여러가지 가정을 하거나 예외를 생각하지 않고 짧고 간결하게 짜고 싶은 생각에서 오는 문제..
-
-##### 가정은 코드 재사용 시 버그를 초래할 수 있다
-
-가정하여 상황에 맞게 코드를 제작하고 동작에 문제가 없었지만 코드를 재사용한다면 이야기가 달라진다.
-
-코드를 일반화, 재사용하기 위해선 낮은 수준의 추상적인 문제들로 구성되어야 안전하고 쉽다.
-
-하지만 예제와 같은 코드는 재사용하기 전에 문제가 발생하지 않았다고 해서 좋은 코드가 아니다.
-
-요구사항이 변경되거나, 다른 쪽에서 재사용될 때 발생할 수 있는 문제이다.
-
-##### 불필요한 가정을 피하라
-
-따라서 비용과 이익을 따져가며 가정을 하는 것 자체가 버그를 불러올 수 있다는 점을 알아야 한다.
-
-**섣부른 최적화**
-
-섣부른 최적화를 피하려는 열망은 소프트웨어 공학과 컴퓨터 과학 내에서 잘 정립된 이론이다.
-
-최적화를 거듭할 수록 생산성은 떨어지고 생산성이 올라갈수록 최적화와 거리가 멀어진다.
-
-따라서 큰 효과가 없는 코드 최적화를 하느라 애쓰기보다는 코드를 읽을 수 있고, 유지보수 가능하며, 견고하게 만드는 데 집중하는 것이 좋다.
-
-프로그램에 의심될 만한 깃발들을 세워두고 해당 기준이 넘거나 큰 효과를 볼 수 있을 때 최적화 작업을 해도 무방하다.
-
-##### 가정이 필요하면 강제적으로 하라
-
-때로는 가정이 필요하거나 가정으로 얻는 이득이 비용을 초과할 정도로 코드가 단순해질 수 있다.
-
-코드에 가정이 있을 때, 다른 개발자들이 그것을 여전히 모를 수 있다는 사실을 염두에 두어야 한다.
-
-그래서 우리가 상정한 가정으로 인해 다른 개발자들이 무의식중에 곤란을 겪지 않도록 하기 위해 가정을 강제적으로 시행해야 한다.
-
-* 가정이 '깨지지 않게' 만들라
-
-가정이 깨지면 컴파일 되지 않는 방식으로 코드를 작성할 수 있다면 가정이 항상 유지될 수 있다.
-
-* 오류 전달 기술을 사용하라
-
-가정이 깨는 것이 불가능하게 만들 수 없는 경우에는 오류를 감지하고 오류 전달 기술을 사용하여 신속하게 실패하도록 코드를 작성할 수 있다.
-
-#### 전역 상태를 주의하라
-
-전역변수는 프로그램 내의 모든 콘텍스트에 영향을 미치기 때문에 전역변수를 사용할 때는 누구도 해당 코드를 다른 목적으로 재사용하지 않을 것이라는 암묵적인 가정을 전제한다.
-
-이전 절에서 봤듯이 가정에는 비용이 수반된다.
-
-전역 상태는 코드를 매우 취약하게 만들고 재사용하기도 안전하지 않기 때문에 일반적으로 이점보다 비용이 더 크다.
-
-##### 전역 상태를 갖는 코드는 재사용하기에 안전하지 않을 수 있다
-
-어떤 상태에 대해 프로그램의 여러 부분이 공유하고 접근할 필요가 있을 때 이것을 전역변수에 넣고 싶은 마음이 들 수 있다.
-
-이렇게 하면 코드의 어느 부분이라도 그 상태에 접근하기가 아주 쉽다.
-
-그러나 방금 언급했듯이 이렇게 하면 코드를 재사용하는 것이 안전하지 않을 수 있다.
-
-두개의 코드가 동일한 전역 상태를 읽고 수정한다면 의도하지 않은 결과를 초래한다..
-
-##### 공유 상태에 의존성 주입하라
-
-의존성 주입을 통한 객체의 공유는 같은 장바구니를 공유한다.
-
-이렇게 의존성 주입을 사용하여 공유한다면 재사용성 또한 올라간다.
-
-전역상태를 의존성주입 형태로 관리하는게 귀찮고 간편한 전역을 사용하고 싶어할 수 있다.
-
-그렇지만 재사용성 측면과 다른 개발자와 코드계약에 있어서 안전하지 않고 쉽게 사이드 이펙트를 유발한다.
-
-프로그램간의 서로 다른 상태를 공유해야 할 경우, 의존성 주입을 사용해 보다 통제된 방식으로 수행하는 것이 안전하다.
-
-읽으면서 다양한 생각을 해봤는데 게임의 경우 싱글톤을 사용하여 전체적인 게임을 관리하는 매니저를 자주 사용하게 된다.
-
-게임의 흐름을 관리하기 위해선 내 생각에 필수적인것 까진 아니더라도 퍼포먼스나 개발 속도에선 매우 좋은 방법이라고 생각한다.
-
-인디게임이나 적은 규모의 팀이라면 적극 사용할 것 이다.
-
-물론 모든 공유를 매니저로 처리하는 것이 아닌 공유되는 인벤토리같은 기능은 위와 같은 방법을 사용하는 방법이 있다.
-
-책에서 말하는 것처럼 장점과 이점을 항상 생각하고 제한적으로 만든다면 입구나 출구를 하나로 둘 수 있기 때문에 관리에 더욱 용이해진다.
-
-#### 기본 반환값을 적잘하게 사용하라
-
-합리적인 기본값은 사용자 친화적인 소프트웨어를 만들기 위한 좋은 방법이다.
-
-워드의 예로 사용자의 편리를 위한 기본값은 유용하다. 생성자의 오버로딩, 선택적 매개변수의 예이다.
-
-기본값을 제공하려면 종종 다음과 같은 두 가지 가정이 필요하다.
-
-* 어떤 기본값이 합리적인지
-* 더 상위 계층의 코드는 기본값을 받든지 명시적으로 설정된 값을 받든지 상관하지 않는다.
-
-##### 낮은 층위의 코드의 기본 반환값은 재사용성을 해칠 수 있다.
-
-낮은 층위의 코드는 근본적인 하위 문제 해결에 더 많이 사용되고 따라서 상위 계층의 문제를 해결하기 위해 재사용될 가능성이 높다.
-
-즉, 하위 문제를 해결하기 위해 생각한 가정이 많은 상위 계층에 양향을 미친다.
-
-##### 상위 수준의 코드에서 기본값을 제공하라
-
-간단한 방법으로 하위 수준에서는 null을 반환하고 상위 수준에서 해결하는 것이다.
-
-기본값 또한 캡슐화 클래스로 만들어 의존성 주입을 통해 값을 가지고 있는다.
-
-상위 수준에서는 해당 값이 널이라면 기본값으로 만들어둔 캡슐화 클래스를 반환한다.
-
-C#의 ??를 사용하여 반환 값이 null이라면 디폴트 객체를 반환한다.
-
-#### 함수의 매개변수를 주목하라
-
-함수가 데이터 객체나 클래스 내에 포함된 모든 정보가 있어야 하는 경우에는 해당 함수가 객체나 클래스의 인스턴스를 매개변수로 받는 것이 타당하다.
-
-이렇게 하면 함수의 매개변수의 수가 줄어들고 캡슐화된 데이터의 자세한 세부 사항을 처리해야 하는 코드가 필요 없다.
-
-그러나 함수가 한두 가지 정보만 필요로 할 때는 객체나 클래스의 인스턴스를 매개변수로 사용하는 것은 코드의 재사용성을 해칠 수 있다.
-
-##### 필요 이상으로 매개변수를 받는 함수는 재사용하기 어려울 수 있다.
-
-예제와 같이 필요 이상의 매개변수를 받게 되면 재사용하기 어려울 수 있음으로 해당 getter함수로 필요한 인자값만 넘기고 필요한 매개변수만 받으면 된다.
-
-#### 제네릭의 사용을 고려하라
-
-클래스는 종종 다른 유형 혹은 클래스의 인스턴스나 참조를 갖는다.
-
-대표적인 예로 리스트 클래스로 문자열과 정수를 저장하기 위한 완전히 다른 별개의 리스트 클래스를 가진다면 상당히 번거로울 것이다.
-
-*제네릭,템플릿*
-
-다른 클래스를 참조하는 코드를 작성하지만 그 클래스가 어떤 클래스인지 신경 쓰지 않는다면 제네릭의 사용을 고려해야 한다.
-
-제네릭을 사용하면 아주 적은 양의 추가 작업이 있긴 하지만 코드의 일반화가 크게 향상된다.
-
-##### 특정 유형에 의존하면 일반화를 제한한다.
-
-RandomizedQueue클래스는 string에 대한 의존도가 높기 때문에 다른 유형을 저장하는 데는 사용하지 못한다.
-
-##### 제네릭을 사용해라
-
-예제에서 제공된 클래스는 제네릭을 도입하기 아주 쉬운 구조이다.
-
-하지만 만약 게임의 요구사항의 변경되어 문자열을 반환하기 전에 출제자의 난이도 또한 올려서 문자열에 단어 몇가지만 삭제된 상태로 반환된다고 한다면 제네릭은 사용할 수 없다.
-
-즉, 해당 자료형에 대한 성격이 확실하다면 도입하기 어렵고 제네릭 자체가 사용하기 어려운 것 같다.
-
-좀 더 생각해봐서 위의 경우처럼 삭제후 반환까지 제네릭을 도입한다면 RandomizedQueue클래스에 반환 전 삭제에 관련된 기능을 다루는 인터페이스를 의존성 주입 후 삭제 부분에서 다룬다면 9.21예제와 같이 사용도 가능하다..
-
-### 느낀점
-
-**가정**부분도 생각도 못하고 있던 부분이라 도움이 되었고
-
-공유를 다루기 위해 의존성 주입또한 고질적인 문제점을 해결하기 좋아보인다.
-
-++ 상위 계층에서 기본값을 처리하기도 굳굳
\ No newline at end of file
diff --git a/draft/project/2022-02-24-project_cherry.md b/draft/project/2022-02-24-project_cherry.md
deleted file mode 100644
index 74a2ef0..0000000
--- a/draft/project/2022-02-24-project_cherry.md
+++ /dev/null
@@ -1,97 +0,0 @@
----
-title: "프로젝트 체리 정리"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-02-24
-last_modified_at: 2022-02-24
-
----
-
-# 220223 팀 빌딩 회의
-
-### 팀 빌딩 아이디어 회의
-
-- 게임 장르: 2D 횡스크롤 퍼즐 액션
-- 플랫폼: PC
-- 컨셉: 디스토피아/ 어두운, 황폐한, 외로운
-- 배경: 시민이 3등급으로 구분되는 계급 사회. 차별이 만연한 분위기 속에서 3등시민 헥터는 1등시민 구역의 청소부로 살아간다. 헥터의 곁에는 언제나 청소 전용 안드로이드 체리가 함께한다. 그러던 어느 날, 정부에서 구형 안드로이드를 모두 처분하라는 지침이 내려오는데...
-- 목표: 자살 폭탄으로 개조되기 전에 체리를 구출하라!
-- 배경 시나리오
-
- [해피 뉴이어_최지우.hwp](https://s3-us-west-2.amazonaws.com/secure.notion-static.com/ad0ec4d1-9d82-4b89-add6-c3b9fa03b19f/해피_뉴이어_최지우.hwp)
-
-- 레퍼런스
- - 우산금지
- - 샐리의 법칙
- - 오리와 도깨비 불
- - 리틀 나이트메어
- - 그 외) 롤 자운/ 월E/ 애니매트릭스/ 총몽
-- 아이디에이션
-
-
- 💡 액션 요소가 극대화되게끔 시스템 설계
-
-
-
- - 주인공 상황
- - 주인공 헥터가 체리를 업고 스테이지를 통과하는 구조
- - 초반에는 심장만 옮기다 부품을 수집하면서 완전체를 옮기는 식(무게 증가)
- - 체리는 자살 폭탄으로 개조될 위험에 처해있음
- - 개조 정도에 따라(선함/악함??) 엔딩이 둘로 분화
- - 엔딩: ①체리를 무사히 구출 ②자살 폭탄이 된 체리
- - 엔딩 전 플레이어에게 대화식 선택지 제공→선택에 따라 달라지는 엔딩
- - 스테이지 구성
- - ++ 초반 튜토리얼 및 스토리 설명
- - 맵 테마→스토리 정비 후 순서 결정
- - 1등 시민 구역: 화려한, 부유한, 깨끗한/ 분수, 광장, 사립학교, 무자비한 경찰들
- - ++ 가치
- - 2등 시민 구역: 평범보다 못한, 악착같은, 사각지대가 있는/ 콘크리트 건물, 구룡성채
- - ++ CCTV 감시
- - 3등 시민 구역: 비루한, 허름한, 적개심이 가득한/ 쓰레기 매립지, 오염된 강, 지하도
- - ++ 관심없는 더러운, 포기한
- - 구성: 액션+스토리 및 퍼즐/ 스테이지 끝에는 보스 등장
- - 보스 캐릭터 및 몬스터 배치를 위해서 세계관 검토 필요
- - 액션 요소
- - 체리를 활용한 기믹→무게 증가(방해요소)/ 부품 획득으로 캐릭터 강화
- - Ex) 엔진을 얻으면 고공 점프
- - 신체 부위를 이용한 주인공 강화(신체 일부=무기로 기능)
- - 스테이지가 진행되며 or 보스 스테이지에 진입하기 전 무기 승급 등
- - 주인공과 일정 시간 떨어져있으면 폭발
- - 시스템 가이드: 레슬리
- - 상점 or NPC로 작동
- - 각 구역에서 만나볼 수 있는 레슬리
- - 주인공이 나아갈 길을 알려줌(퍼즐 힌트)+무기 사용 방법 가이드
- - 레슬리 추가 사항
- - ++ 게임내에 재화(톱니바퀴(나사), 돈)을 통해서 레슬리에서 원하는 체리의 형태로 업그레이드 가능
- - ++ 음성 업그레이드, 공격성(팔 다리 등등), 이펙트 강화를 위해 폭탄 로봇의 형태도 좋아보임
- - ++ 충전용액의 개념으로 체리를 충전해야함..?
- - 생각 정리..?
- - ++ 계급사회에서 존재하는 특별한 이름 체리
- - ++ 이전에 느꼈던 불평등에 대해서 이미 수용하고 별 생각이 없었지만 친구인 체리(자신의 전부?)가 피해를 입자 사회에 맞서는
- - ++ 각자의 삶에 철저한 개인주의 성향을 가지는 사람들, -> 자신과 대화를 이어가주는 체리(기계에 불과하지만)
- - ++ 스토리 전개상 등장하는 인간은 따로 존재하지 않기 때문에 외로운 느낌과 체리와 유대감, 레슬리라는 이름의 샵, 보이지 않는 최고 악역, 현 대통령(현 상황을 외면하고 같은 실수를 반복하지 않기 위해 철저한 계급, 분리, 차별)
- - ++ 생각한 스토리라인 (1)
- - 외출 사이의 정부의 정책으로 3등시민 구역 폐기장에서 버려진 체리를 발견 -> 1등시민 구역으로 가서 (폭탄 or 설득) -> 3등시민 구역에서 1등시민구역으로 향하는 계단라인(오르며) -> 해당 테마를 진행하고 스토리, 체리 강화(이때 플레이어 성향에 따라 갈림) -> 1등시민 구역 도착 후 성향에 따라 폭탄엔딩, 설득엔딩
- - 각 테마 구성은 3등시민 구역의 ai경찰은 낡고 녹슬어 기능이 약함(난이도, 마찬가지로 상향식 성장), 보스는
-
----
-
-- 2/24(목) 개인 과제
- - 레퍼런스 게임 2개 이상 추려오기(혹은 레퍼런스 게임 플레이 후 아이디어 정리)
- - 시스템/ 스토리 제안
- - 위 회의록 내용 자유롭게 수정
- - 잘못되거나 논의가 필요한 사항은 빨간색 표시
- - 빠트린 내용과 보충하고 싶은 내용 색깔 표시
-- 추후 논의사항
- - 예산 사용
- - 역할 분담(서기, 일정 관리 등)
- - 정기회의 시간 및 방식
- - 멘토에게 피드백 받고 싶은 내용 정리
diff --git a/draft/project/GameOverProject/FeedBack/Event Flow.md b/draft/project/GameOverProject/FeedBack/Event Flow.md
deleted file mode 100644
index e7b25d8..0000000
--- a/draft/project/GameOverProject/FeedBack/Event Flow.md
+++ /dev/null
@@ -1,24 +0,0 @@
-# 사건 플로우 피드백
-
-러프, 미완이지만 벌써 완성도가 느껴짐 특히 사건의 초반 시놉시스
-
-아직 러프라 추가되면 좋은 부분도 보이지만 2차 수정 이후에 회의를 통해 말해도 좋을 듯
-
-- 4의 발단의 A, B, C의 서브시스템 분할부분의 명칭을 분할하여 좋음
-
-해당 형태에 대한 각각의 설명도 있으면 좋을 것 같음
-
-- 6의 위기부분에 등장해야 하는 (필연적으로 리소스 숭배자들과 같은 부분은 필요하다고 생각) 리소스 숭배자들의 가치관이나 설명이 궁금
-
-사건 플로우 부분은 너무 좋음 특히 미니게임 부분의 아이작 오마주 부분(개발 난이도도 간단하고 단순 반복성과 색다른 시스템의 결합으로 해석해도 좋을 듯)
-
-어색한 부분 엘프 여성의 억지? 리소스홀에서 널린게 게임이라면 (물건으로 칭한 주인공) 자신보다 가치가 있는 물건을 찾아 오라는 부분? 좀 더 자연스럽게 설명이 필요할 듯
-
-이상 현상으로 접속이 발생한 부분, 이 부분은 기획 단계에서 좀 더 구체화가 있어야 납득이 가능할 듯
-
-- 만약 엘프 여성이 그런 억지를 부리는 것이 가능한 세계관이라면 문제 없을 듯
- - 이후에 마을에서 보여주는 생활이 위 행동이 납득 가능한 선이라면
-
-주인공이 게임이라면 접속이 가능한 부분을 복선으로 남겨두기 위해서 설명을 지금처럼 이상현상쯤으로 남겨두는 것도 좋은 방법 같음
-
-챕터내 반복적인 요소는 위의 서브시스템일텐데 그에 따른 서브시스템 문서도 따로 만들어야 할 듯
\ No newline at end of file
diff --git a/draft/project/GameOverProject/FeedBack/character planning.md b/draft/project/GameOverProject/FeedBack/character planning.md
deleted file mode 100644
index 8e10d8b..0000000
--- a/draft/project/GameOverProject/FeedBack/character planning.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# 캐릭터 기획 피드백
-
-## 주인공
-
-- 라플리 replay, 리플리 증후군등 다양한 연결 가능
-
-성격, 말이 없었으면 좋겠다.
-
-얼굴 묘사도 적으면 더 좋을 듯
-
-플레이어가 게임이기 때문에 자신이 인식하는 모습에 따라 달라질 수 있는?
-
-좀 더 관념적인 플레이어의 모습이어야 하지 않을까?
-
-대신 현재 기획과 같이 대외적으로 보여줄 이미지가 필요
-
-성격이나 가치관 습관등은 원래 자신의 게임의 형태에서 따오면 좋을 듯
-
-어떤 식으로 전개되어 갈지 모르겠지만, 라플리 자체가 게임
-
-라플리라는 게임이 오래되어 잊혀진 게임이라면 오래된 스타일이 좋을 것 같고
-
-이 GG타운에 리소스홀을 통해 내려온 첫 인간이라는 설졍이라면 원래 어떤 게임이였는지에 대한 구체화가 필요해보임
-
-그 구체화에 따라 캐릭터의 외형적인 모습이 해당 게임의 색을 잘 담고 있다면 좋을 것 같다.
-
-## 심마니
-
-NPC 개개인의 개성도 좋지만 이후에 구체화되면 좋겠다고 생각하는 부분은 신념적인 부분
-
-사회에도 다양한 신념이 존재하듯이, 현 사회에서 누구 맞고 틀리고를 떠나 쉽게 결정하기 어려운 부분이 존재
-
-개인적인 아이디어로 각 NPC마다 ~~주의와 같이 성격적인 부분이나 가치관이 있으면 좋을 것 같다.
-
-- 이데올로기로 성격적 해석을 한다면?
- - NPC1: 자유주의
- - NPC2: 보수주의
- - NPC3: 공산주의
- - NPC4: 민주주의
- - NPC5: 군주제
- - NPC6: 무정부주의
- - NPC7: 이슬람
- - ...
-
-그대로 따라가는게 아닌 참고용으로 성격적 해석을 가져가도 매력적으로 느껴질 것 같다.
-
-- 참고: https://ko.wikipedia.org/wiki/%EC%9D%B4%EB%8D%B0%EC%98%AC%EB%A1%9C%EA%B8%B0_%EB%AA%A9%EB%A1%9D
-
-심마니의 땀수건과 같은 통일적인 부분도 매우 재밌어 보임
-
-- 걱정되는 부분은 너무 한국적인 해석이 되지 않을까?
-- ++ 반대로 외국의 심마니처럼 금속탐지기를 들고 다니는 심마니도 있으면 재밌을 듯
-
-모두가 심마니의 형태를 가져가는 통일성도 좋지만 서브 NPC들도 있어야 할 것 같다는 생각 - 같이 논의해보면 좋을 듯
-
-확실이 NPC, 캐릭터 부분은 주관적인 부분이 매우 강해서 기획하기 가장 어려운 부분이라는 생각이..
-
-**다른 게임의 레퍼런스를 참고해서 매력적인 캐릭터들을 분석하는 것도 좋아보임**
-
-주인공의 성격을 죽이고 NPC, 세계관에 집중하기로 한 만큼 이 부분에 있어서는 캐릭터 NPC가 매력적으로 뽑혀야 할 것 같다는 생각
-
diff --git a/draft/project/GameOverProject/Note.md b/draft/project/GameOverProject/Note.md
deleted file mode 100644
index 6a57f6d..0000000
--- a/draft/project/GameOverProject/Note.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# 컨셉아트 기획
-
-컨셉아트란, 게임속 세계관이나 환경 등에 영향을 받아 만들어지는 그림을 의미
-
-- [블로그 글_1](https://m.blog.naver.com/wnrud948/220803299843)
-- [블로그 글_2](https://heeddoen.tistory.com/65)
-
-현재 게임에 컨셉아트가 매우 필요한 이유는 명확하게 존재했던 세계관이나, 유사한 문화가 없기 때문에 창조영역에 가까움
-
-3가지 핵심 요소가 필요함
-
-- 보여주고 싶은 세계관을 담아야함
-- 변하지 않을 내용을 담아야함
-- 게임의 전체적인 분위기를 담아야함
-
-## 컨셉아트가 필요한 이유
-
-- 분위기 설정
-- 참조 포인트(참고)
-- 일관성 유지
-- 이해관계자에게 설명을 위한 자료
-
-## 컨셉아트를 결정하기 위한 내용
-
-아트 풍은 게임 자체가 장르에 국한되지 않기에 컨셉아트만의 아트스타일로 가져가도 크게 문제 없음
-
-다만, 다음과 같은 사항은 지켜지면 좋음
-
-- 블랙앤 화이트(명도는 조절)
-- 게임이 주고자 하는 세계관
-- 게임의 분위기
-
-### 1번 아이디어
-
-블랙앤 화이트는 그대로 가져가고 게임이 주고자하는 세계관에 맞게 압도적인 게임산을 보여주는 것
-
-등장인물은 없는 것으로 처리하고 꼭 등장해야 한다면 흑백으로 처리
-
-게임의 요소로 이루어진 산으로 특별한 세계관이 설명 가능하기에
-
-분위기는 등장인물이 없고(있다면 흑백) 게임의 요소, 쓰레기의 산이기 때문에 당연하게 어두울 수 밖에 없음
-
-차라리 압도감을 주는 듯한 느낌을 주는게 좋음
-
-
-#### 문제점
-
-- 너무 큰 비율 인물과 산의 비율이 너무 크게 나와서 그리는 비용이 너무 클 것 같음
-- 산 전체를 게임의 요소로 채우기 힘듬
-### 2번 아이디어
-
-산에서 눈을 뜬 주인공 시점
-
-리소스 홀에서 떨어진 주인공이 눈을 뜨는 순간
-
-산의 모습을 1인칭 시점으로 보여주는 것
-
-### 3번 아이디어
-
-망가진 게임 UI
-
-게임의 요소 중 하나인 UI창이 망가진 상태의 이미지
-
-
-
-블랙배경의 땅에 컬러감 있는 UI창의 이질적인 이미지
-
-게임의 요소를 설명하기에 적합해 보임
-
-#### 문제점
-
-너무 이질적인 디자인으로 가면 붕 떠보일 수 있음...?
-
-UI창의 디테일한 부분의 설계 미흡
-
-### ETC
-
-위 아이디어로 퀄리티가 좋게 나온 컨셉아트라면 충분히 활용 가치가 높음
-
-단순하게 쓰고 버려질 느낌보다 지속적으로 활용될 가능성이 매우 큼
-
-### 생각 정리
-
-
-
-### 4번 아이디어
-
-
-
-저니의 형태로 마을의 형태나 산의 웅장함, 전체적인 비율을 보여주기에도 좋음
-
-### 5번 아이디어
-
-
-
-좋은 디자인 레퍼런스로 아이디어 자체도 비슷함
-
-구도, 색감, 후처리등을 참고하기 좋음
\ No newline at end of file
diff --git a/draft/project/GameOverProject/TeamMeeting.md b/draft/project/GameOverProject/TeamMeeting.md
deleted file mode 100644
index 6732297..0000000
--- a/draft/project/GameOverProject/TeamMeeting.md
+++ /dev/null
@@ -1,50 +0,0 @@
-안녕하세요 팀장 이정안입니다.
-
-프로젝트 개설 관련 공지사항입니다.
-
-지금 톡방에 계신분들은 전부 2차 팀빌딩 지원을 확정해주셔서 현재 인원으로 진행될 것 같습니다.
-
-프로젝트 정식 시작일은 다음주 월요일입니다.
-
-따라서 온라인 카톡으로 두가지 사항을 정해야 합니다..!
-
-1. 정기 비대면(온라인) 회의 날짜와 시간
-2. 다음 대면 회의 날짜와 시간
-
-1번 사항은 월요일이 가장 적합해 보이는데 `월요일 10시` 불가능하신 분 있나요?
-
-2번 사항은 한번은 꼭 필요한 대면 회의 시간을 정해야 할 것 같습니다.
-
-팀원간의 친목, 프로젝트 방향성, 팀 이름 정하기..! 등등 다양한 이유로 대면 회의가 필요할 것 같습니다.
-
-다만 아직 2차 팀빌딩전이라 아트한분이 들어오실 가능성이 있어서 1번에서 정해지는 정기 회의에서 정하면 될 것 같습니다.
-
-약 두달간은 정기 비대면 회의를 주에 1회씩 진행할 예정이고 이후 프로세스가 고착화 된다면 2주에 1회로 변경될 것 같습니다.
-
-- 작업 방식
-
-정기회의에서 다시한번 말씀 드리겠지만 3가지 사항은 기본 뼈대 프로세스로 잡고 이후에 추가적으로 필요한 사항들에 대해 추가해나갈 예정입니다.
-
-1. 프로젝트 진행 상황 공유
- - 가장 중요한 진행 상황 공유입니다. 각자 어떤 부분을 진행했는지, 어떤 부분을 진행할 예정인지 등등을 공유합니다.
-2. 다음 회의까지 진행할 사항 공유
- - 다음 회의까지 진행할 사항을 공유합니다. 1주간의 스케줄을 만들고 다음 회의까지 어떤 부분을 진행할 것인지 공유합니다.
-3. 결과물을 회고
- - 위에서 진행한 사항에 대해서 회고합니다. 어떤 부분이 잘 되었고, 어떤 부분이 잘 안되었는지 등등을 공유합니다.
- - 이때 프로세스에 대한 수정이나, 작업 방식에 대한 문제점을 찾아냅니다.
-
-이 부분은 인터뷰때 전달드린 내용입니다.
-
-처음에는 어색할 수 있지만 천천히 맞춰갈 예정이며, 저도 그렇고 다 처음이라 처음에는 어색할 수 있습니다.
-
-조금 멀리, 길게 보면서 맞춰나가는 것이 좋을 것 같습니다.
-
-- 동호님 따로 전달
-
-동호님 다음주 월요일 작업전에 하루정도 시간을 내서 프로젝트 기획에 관한 내용을 조금 정리하는 시간이 있으면 좋을 것 같습니다.
-
-다른 분들은 다음주 월요일부터 시작하시게 되실텐데 그전에 아트나 사운드에 영향이 갈 수 있는 기본적인 디자인, 레퍼런스에 대한 이야기를 같이 정리하면 될 것 같습니다.
-
-이번주 가능하신 시간을 알려주실 수 있나요?
-
-저는 주말이 편합니다..!
diff --git a/draft/project/GameOverProject/TeamMeeting.pdf b/draft/project/GameOverProject/TeamMeeting.pdf
deleted file mode 100644
index fe89165..0000000
Binary files a/draft/project/GameOverProject/TeamMeeting.pdf and /dev/null differ
diff --git a/draft/project/GameOverProject/TeamMeeting_1.md b/draft/project/GameOverProject/TeamMeeting_1.md
deleted file mode 100644
index 91e83c5..0000000
--- a/draft/project/GameOverProject/TeamMeeting_1.md
+++ /dev/null
@@ -1,40 +0,0 @@
-# 기획 회의
-
-- 23-09-22
-
-## 메인시스템
-
-단순 2D, 3D가 아닌 장르의 변화를 주고자 함
-
-텍스트 알피지 -> 비쥬얼 노벨 -> 언더테일(2D 사이드 뷰)
-
-## 게임이 주고자 하는 분위기
-
-- 블랙앤 화이트 컬러 이질적인 다른 게임 요소의 디자인
-- 메인 시스템 레퍼런스: 주먹왕 랄프, 언더테일, 에보랜드
-
-블랙앤 화이트는 등장인물, 배경, 오브젝트만 가져가고
-
-UI는 그 게임 성격에 맞게
-
-## 게임 엔딩, 목표
-
-- 멀티 엔딩희망
-
-## 지금 당장 정해야 하는 것
-
-### 마을 분위기 -> (사운드, 아트 작업)
-
-
-
-### 게임 아트 레퍼런스
-
-산에 둘러싸인 마을에서 게임 팩을 줍고 있는 주민 디자인
-
-### 게임 사운드 레퍼런스
-
-스타일로폰사운드
-
-기계적인
-
-https://www.youtube.com/watch?v=4ujd5pti0ZI
\ No newline at end of file
diff --git a/draft/project/GameOverProject/TeamMeeting_1.pdf b/draft/project/GameOverProject/TeamMeeting_1.pdf
deleted file mode 100644
index a02b842..0000000
Binary files a/draft/project/GameOverProject/TeamMeeting_1.pdf and /dev/null differ
diff --git a/draft/project/GameOverProject/TeamMeeting_2.md b/draft/project/GameOverProject/TeamMeeting_2.md
deleted file mode 100644
index 4251d82..0000000
--- a/draft/project/GameOverProject/TeamMeeting_2.md
+++ /dev/null
@@ -1,201 +0,0 @@
-# 정기 회의
-
-23-09-25
-
-- 금일 회의 목차
- - 간단한 자기소개
- - 인터뷰 내용 다시 한번 공지
- - 이번 주 예정 목표 (연휴라 생각해서)
- - 협업 방식 => 천천히 맞춰나갈 것 생각
- - 서류 작성
-
-### 카톡 공유용
-
-안녕하세요 팀장 이정안입니다.
-
-금일 오후 10시에 디스코드로 비대면 온라인 회의가 예정되어 있습니다.
-
-인터뷰때 안내 드린대로 오프라인 회의이지만 캠과 마이크 사용을 권장합니다. (필수가 아닙니다..!)
-
-첫 회의라 처음부터 너무 많은 내용을 진행하지 않고 다음 주 회고를 위한 첫 싸이클을 돌려본다고 생각하시면 좋을 것 같습니다.
-
-회의 목차는 다음과 같습니다.
-
-- 팀원 간단한 자기소개
-- 짧은 인터뷰 내용 다시 한번 공지
-- 팀 이름, 게임 이름 (임시라도) 정하기
-- 서류 작성
-- 협업 방식 설명
-- 이번 주 목표 Task 설정
-
-### 대본
-
-안녕하세요!
-
-#### 자기소개
-
-아아 소개
-
-#### 인터뷰 내용 공지
-
-급하게 가면 분명 넘어진다.
-
-제대로 걷는 연습부터 하고 달려나갈 것
-
-언제든지 힘들면 따로 말해줘야 한다. (팀에서 혼자 고민하는건 좋지 못하다.)
-
-하나의 팀으로 인식해주면 좋을 것 같다.
-
-말한대로 2달간은 계속 연습의 연속일 것
-
-1달마다 1대1 미팅을 진행할 것
-
-앞서 말한대로 개인적으로 요청해도 됨
-
-개인적인 문제가 생겨 힘들 경우 팀원 모두가 아는게 좋다.
-
-발 맞춰가는 과정에선 주에 1번씩 온라인 회의를 진행
-
-다양한 시도를 통해 우리 팀에 맞는 스타일을 찾아나갈 것
-
-1. 프로젝트 진행상황 공유
-2. 다음 회의까지 진행할 사항 공유
-3. 결과물을 회고
-
-이 뼈대는 유지한 채로 추가적인 사항을 더해나갈 것
-
-#### 팀 이름, 게임 이름 정하기
-
-팀 이름을 임시라도 정해야 함 제출할 서류가 있고 레포 관리에 있어서
-
-게임 이름도 임시라고 생각 정해주면 좋을 것 같다.
-
-GG studio
-
-#### 서류 작성
-
-서류 카톡에 올림
-
-구드 공유
-
-개인적인 중요한 서류는 구드를 통해 공유 (구드에 들어가는 내용은 외부 공유 x)
-
-인터뷰내용도 정리해서 구드에 올라갈 예정 혹시 걸리는 부분있다면 이야기
-
-협업 툴로 구드를 사용할 생각이 없지만 이처럼 특별한 경우에만 공유 목적으로 사용
-
-문제되는 서류나 피드백은 언제나 환영
-
-#### 협업 방식 설명
-
-일단 공지한대로 협업은 깃허브를 통해서만 진행
-
-- 궁금증 노션, 지라같은 좋은 협업 툴이 있지 않느냐?
-
-대부분의 기능을 지원하고 작업 중인 레포에서 버전관리에 더 탁월함
-
-- 궁금증 배우는데 힘들 것 같다. 어려울 것 같다.
-
-노션, 지라 배우는 것과 똑같은 맥락이다.
-
-당연하지만 일정을 공유하고 작업 사항을 알려면 협업 툴이 필요하다.
-
-마찬가지로 학습 코스트가 들지만 우리는 배우는 것이 아니라 사용하는 것일 것
-
-따라서 처음부터 다 사용하는게 아닌 필요에 의해 조금씩 배워나가면 좋겠다.
-
-간단한 사용법은 다 알려주면서 진행
-
-- 궁금증 깃허브를 사용하는데 어떤 장점이 있느냐?
-
-작업한 내역을 다 알 수 있고, 처음에는 조금 어색할 수 있지만 되게 간단하다.
-
-그리고 나중에 포폴로 내기도 편할 것(실제 작업물과 게임이 한 공간에 위치)
-
-- 여기서 플래닝, 스탠드업 미팅, 마일스톤 설명
-
-플래닝은 깃허브를 통해 제가 생성한 마일스톤에 각자 할당된 일정을 적어주시면 됩니다.
-
-마일스톤은 해당 목표를 명확하게 하고 길을 잃어버리지 않게 합니다.
-
-마일스톤을 먼저 만들고 일정을 세웁시다.
-
-하루에 한번씩 스탠드업 미팅을 진행합니다. (오후 10시)
-
-스탠드업 미팅은 간단한 질문을 통해 진행합니다.
-
-스탠드업 미팅이 필요한 이유 설명
-
-팀원들이 서로 무슨일을 하는지 모르면 오히려 정기 회의시간이 길어진다.
-
-지금은 첫 정기 회의라 이런 사항을 전달하느라 시간이 길어지지만 회의는 대부분 비정기적, 비동기로 이뤄져야 한다.
-
-하루에 간단한 사항이라도 공유하는게 좋다.
-
-회사에선 15분 정도 온라인으로 진행하지만 우리는 처음이니 카톡이나 디스코드로 간단하게 진행해보려 한다.
-
-데일리 미팅을 시작한 후 마침 김창준 님의 애자일 키워드라는 팟방을 듣게 됐는데요. 데일리 미팅을 하는 가장 큰 이유는 일정 공유보다는 팀원 개개인의 감정을 학습하는 것이라고 합니다.
-
--> 가능하다면 아침 10시에 온라인으로 진행하고 싶다.
-
-- 어제 한 일
-- 오늘 할 일
-- 장애물
-- 추가적인 이야기
-
-#### 이번 주 목표 Task 설정
-
-오늘은 간단하게 작업 내용만 마일스톤에 기록하고 이번 주는 작업 내용 공유만 진행
-
-아트, 사운드, 기획분들이 자료를 레포에 올리는 방법은 다음 회의때나 따로 설명하겠습니다.
-
-각자 주에 작업 가능한 시간과 작업 예정 시간을 적어서 만들어 보기 실습..!
-
-- 플밍: 기초 설계 CI/CD, new Input System, 기초 프로젝트 탬플릿 작업
-- 기획: 세계관, 게임 기획서 초안 작성
-- 아트: 게임 컨셉아트, 게임 레퍼렌스 디자인 설정
-- 사운드: 게임 컨셉 사운드
-
-각자 파트에 대한 의견 공유
-
-더 효율적인 방법 고민
-
-#### 마무리
-
-인사~~
-
-다른 사람들의 작업속도와 작업물에 대한 지식이 없기 때문에 좀 더 알아가면 졸을 것 같다.
-
-게임에 대한 브레인 스토밍을 좀 더 진행해보자.
-
-같이 게임에 대한 회의
-
-세화님, 민서님, 팀장 회의
-
-우연님 정안님
-
-오프라인 회의 필수
-
-인터뷰 내용 공유 14일 만남 정리
-
-## 게임이름 아이디어
-
-cinerefta [시네레프타]
-
-ænd -> 게임이 이어진다.
-
-해야할 일
-
-디코 업데이트
-
-회의록 정리
-
-개인 회의 정리 ->
- - (아트는 나중에 하는게 좋은지 지금 나누는게 좋은지 이야기하기)
- - 플밍 작업 방식 전달
- - 기획서 양식 만들기
-
-오프라인 회의 날짜 정하기
-
-다음 회의때 까지 안건 -> 지금 필요한 부분(이야기 해야하는 부분 정리)
-
diff --git a/draft/project/GameOverProject/Temp.md b/draft/project/GameOverProject/Temp.md
deleted file mode 100644
index e69de29..0000000
diff --git a/draft/project/GameOverProject/TempInterview.md b/draft/project/GameOverProject/TempInterview.md
deleted file mode 100644
index 320c655..0000000
--- a/draft/project/GameOverProject/TempInterview.md
+++ /dev/null
@@ -1,187 +0,0 @@
-# 프로젝트 인터뷰 질문
-
-## 사전 공지
-
-- 실제 회사와 비슷한 프로세스를 가져갈 것이다.
-- 현업자의 멘토링을 받을 것
-- 단순 포폴용이 아닌 실제 출시를 목적으로 설계를 기획한다.
-
-## 기본질문
-
-- 프로젝트 경험
- - 프로젝트에서 담당했던 역할
- - 프로젝트 진행에 어려웠던 점
-- 이후에 진로에 대한 생각
-- 6개월 후 스케줄
-- 주에 몇시간 투자 가능한지
- - 주 개발 시간을 최소를 맞추고 (최대는 의지치) 제일 작게 부른 사람..
-- 의견 충돌에 대한 해결방법
-- 작업 스타일
-
-직접적으로 물어보기
-
-- **계획적으로 하는 걸 해봤는지**
- - 보통은 없다
- - (이 프로젝트가 계획적으로 진행된다는 걸 설명하기)
- - 디테일한 작업 계획은 개인이 가져가야함, 큰틀은 목록으로 뽑는다.
-
-- 진행상황 공유
- - 자신의 능력치를 제대로 인지하는지
- - 매일 매일 진행상황을 공유하는 것에 대한 생각
-
-- 꾸준한 프로젝트를 지향한다
- - CI/CD, 프로젝트 목표, 회고를 명확하게 할 것을 사전에 고지
- - 다같이 확인해야함
- - 이게 되어야 예측이 가능함
-
-**애자일의 스크럼 방식 -> 스프린트 방식**
-
-## 프로젝트
-
-- 비슷한 게임에 대한 생각
-- 제안서를 읽고 궁금한 점
-- 문제점이라고 생각된 부분
-
-## ETC
-
-- 수익, 저작권 관련
- - 수익은 균등이 가장 바람직
-
-## 09/17
-
-정우연 플밍
-서민지 아트
-이동호 기획
-송기화 사운드
-
-안녕하세요 GameOver 프로젝트 제안자 10기 프로그래머 이정안이라고 합니다.
-
-오늘 지원해주셔서 정말 감사합니다.
-
-아직 2차 팀빌딩 전이라 정식적인 팀이 아닙니다..
-
-원래 팀빌딩 이후에 다같이 디코에서 인사하면서 전달사항과 개개인 인터뷰를 진행하려고 했습니다.
-
-2차 팀빌딩 이전에 다른 팀의 프로젝트나 제안하시고 싶은 제안서가 생길 수 있고,
-
-인터뷰를 통해 팀에 맞지 않는다고 판단되시는 분이 생길 수 있다고 생각됩니다.
-
-따라서 내일부터 가능하신분들 차레로 인터뷰를 진행하려고 합니다.
-
-인터뷰는 프로젝트에 영향이 있는게 아닌 모든 질문은 작업 스타일을 이해하고 맞춰가가 위한 것으로 생각해주시면 됩니다..!
-
-ex) 평소 작업 스타일이나, 주에 작업하는 시간 등등
-
-약 10분정도씩 진행하려고 하는데 내일 오후 10시 이후로 가능하실까요?
---
-
-- 공동 질문
-
-모든 질문은 작업 스타일을 이해하고 맞춰가기 위한 작업으로 질문하는 것
-
-솔직하게 주에 몇시간 쓸 수 있는지
-
-나도 몇시간인지 말하고 주에 정기적으로 몇시간 쓸 수 있는지 체크
-
-물론 필 타면 작업 시간이 늘어날 수 있는데 공동된, 연관된 작업 때문에 주에 몇시간을 쓸 수 있는지 알아야 함
-
-현재 진행중인 프로젝트 - 질문
-
-진행했던 프로젝트 - 담당했던 역할, 어려웠던 점, 후회되는 점
-
-이후 진로에 대한 생각
-
-6개월 스케줄 (정기 여행, 예정된 일정)
-
-의견 충돌에 대한 해결 방법
-
-실제 작업 시작전에 저작권, 수익배분 관련 서류를 작성하고 시작하려고 함 (의견)
-
-작업 스타일 (몰아서, 꾸준히, 집중 시간 등등)
-
-계획적인 작업을 해봤는지
-
-- 디테일한 작업은 본인이 가져가야 함, 큰틀은 목록으로 뽑아 문서화하여 모두 확인한다.
-
-진행상황 공유
-
-- 가장 중요한 포인트 진행상황 공유
-
-자신의 능력치를 제대로 인지하는 것이 중요하다.
-
-매일매일 진행상황을 공유하는 것에 대한 생각 궁금
-
-- 꾸준한 프로젝트를 지향
-
-카페에 적어 놨지만 약 2달간 발을 맞추는 작업을 먼저 진행하려고 함
-
-개발 속도에 복리를 붙이는 방법으로 진행하려고 하는데 처음에는 어려울 수 있지만 이후에는 훨씬 더 쉬워질 수 있다는 점
-
-멘토링때 이야기 하겠지만 미리 이야기 하자면
-
-우리가 미래의 작업을 예측하기 위해선 자료가 필요함
-
-지금 당장 6개월 이후에 프로토 타입을 뽑는다는 대부분의 기획서는 말이 안댐
-
-해당 목표까지 달려가다 퀄리티 저하, 로직 망가짐, 번아웃등이 올 수 있음
-
-2주의 작업을 계획하고 진행하고 회고하면 다음 2주의 작업이 대략적인 예측이 가능해짐
-
-마찬가지로 1달 뒤의 작업또한 예측이 가능해지게 된다.
-
-- 아트 질문
-
-평소 어떤 작업 스타일을 사용하는지
-
-레퍼런스의 정도 -> 앞서 말한 나는 같이 개발하는 과정을 선호하여 디테일 적인 부분은 개인이 가져가야 한다.
-
-형태, 색, 디자인, 레퍼런스는 가능하지만 이후 디테일적인 부분을 본인이 작업
-
-- 플밍 질문
-
-개발하면서 어려웠던 부분
-
-다른 엔진을 공부하며 사용하기 어려운지 (그냥)
-
-- 기획
-
-프로젝트 목표 - 이 부분은 공동으로 공지 사항
-
-출시, 완성도 있는 프로젝트 무조건 예정
-
-우리의 프로젝트에 팬이 생기는 것이 목표
-
-성공시킬 자신이 있으니 믿고 따라와주면 좋겠다.
-
-따라서 서로 솔직한 문화를 구축하고 싶다.
-
-서로 놀땐 놀고 작업할 땐 작업하는, 친한 문화
-
-서로에게 피드백을 솔직하게 주는 대신에 어떠한 문제도 개인화하지 않았으면 좋겠다,.
-
-우리는 팔 수 있는 상품을 만드는거지 서로에게 상처주기 싫어하는게 아니다.
-
-피드백 하는 사람도, 받는 사람도 용기가 필요하기에 이런 프로세스를 구축하는데 2달 정도 소요 예정이다.
-
-따라서 다른 프로젝트부터 진도가 느릴 수 있다.
-
-(프로그래밍 파트 또한 이런 문제 때문에 자주 넘어진다.)
-처음부터 좋은 구조를 만들고 시작할 것
-
-본인도 완성된 작품에 어울리지 않는 아트, 시스템, 로직이 존재한다면 거슬리고, 포폴로서 가치가 없지 않을까?
-
-좋은 프로젝트, 완성된 프로젝트를 위해 솔직한 문화는 필수불가결이라고 생각한다.
-
-좋은 문화, 프로세스를 구축하기 위해 실제 회사 프로세스를 많이 도입하려고 한다.
-
-개인적으로도 협업으로써도 좋은 경험이 될 것
-
-++ 이 부분에 있어서 실제 PM분의 멘토링을 받을 예정인데 가능한지 체크 개인 질문으로
-
-두 번째로 프로젝트 애정을 붙이는 것이 먼저라고 생각
-
-말한대로 완성된 프로젝트를 만들 자신이 있기 때문에 결과를 기대하며 작업하면 좋을 것 같다.
-
-프로젝트, 팀에게 애정을 붙이는 행위로 다 같이 MT도 좋고 게임잼에 팀으로 나가는 것도 좋다.
-
-프로젝트 시작전 발 맞추기 느낌으로 간단한 게임잼을 나가보는 것도 좋을 것 같다고 생각
diff --git a/draft/project/GameOverProject/TempInterviewData.md b/draft/project/GameOverProject/TempInterviewData.md
deleted file mode 100644
index db34c1f..0000000
--- a/draft/project/GameOverProject/TempInterviewData.md
+++ /dev/null
@@ -1,54 +0,0 @@
-## 플밍 정우연
-- 주에 사용가능하신 시간 약 10시간
-- 프로젝트 진행하면서 아쉬웠던점
- - 팀장이 아닌 프로젝트를 진행했을 때 외주같이 프로그래밍만 한 느낌이라 아쉬웠다.
- - 적극적으로 기획에 참여하는 프로젝트를 선호함
-- 현재 진행중인 프로젝트
- - 마무리 단계인 프로젝트 제외하고 없음
-- 진로
- - 게임 개발자(클라)
-- 정기 스케줄
- - 월화 알바 3~9시
-
-## 사운드 송기화님
-- 주에 사용가능하신 시간 약 10시간
-- 프로젝트 진행하면서 아쉬웠던점
- - 첫 프로젝트라 아직은 없음
-- 진로
- - 게임 사운드로 고민하고 있음
-
-## 기획 이동호님
-- 주에 사용가능하신 시간 약 20시간
-- 현재 진행중인 프로젝트
- - 없음
-- 프로젝트 진행하면서 아쉬웠던점
- - 항상 기획, 팀장 역할이였지만 이번엔 기획에 집중해볼 수 있을 것 같다.
-- 진로
- - 아직은 고민 중 이지만 11월달 결과때 프로젝트 방향성을 보고 결정
-
-## 아트 서민지님
-- 주에 사용가능하신 시간 약 6시간 정도
-- 현재 프로젝트
- - 데드넷 프로젝트
-- 정기적 스케줄
- - 화수금~ 5시 10시, 일요일 1~3시
-- 프로젝트 진행하면서 아쉬웠던점
- - 시간에 쫓겨서 다 못보여주는 점 구현의 한계, 조율할 수 있는 점 조율, 결과물이 나와야 실감이 남
-- 진로
- - 게임 아트
-- 의견 충돌
- - 결론을 나올때까지 이야기한다.
- - 설득이 필요한 경우 타당한 근거를 제시하여 설득
-
-## 아트 송세화님
-- 주에 사용가능하신 시간 약 8시간
-- 현재 진행중인 프로젝트
- - 없음
-- 진로
- - 고민중
-- 프로젝트 진행하면서 아쉬웠던점
- - 단기간 프로젝트라 급하게 제작되어서, 수정을 못한게 아쉬웠다.
-- 정기적 스케줄
- - 수목금 오후 5~9시
-- 의견 충돌은 양보를 많이 하는편
-- 작업 스타일 몰아서
diff --git a/draft/project/GameOverProject/TempProjectIdea.md b/draft/project/GameOverProject/TempProjectIdea.md
deleted file mode 100644
index 572a230..0000000
--- a/draft/project/GameOverProject/TempProjectIdea.md
+++ /dev/null
@@ -1,164 +0,0 @@
-# 브릿지 23-2 프로젝트 제안
-
-## 기획서
-
-- 타이틀(제목, 이름)
- - 게임의 무덤?
- - 10기 프로그래머 이정안
-- 팀장소개 (경험, 성향, 팀장이 된 이유 -> 실제 회사에서 하는 애자일 스크럼, 제대로 출시까지 가고 싶어서)
- - 장기 프로젝트 (6개월 이상) 4개
- - 사이드 프로젝트 4개 이상
- - 일상은 P, 작업은 J
- - 처음 만드는 게임 10개는 똥이라는 말, 이번에는 제대로된 개발 프로세스, 방법론을 도입해서 제대로 출시까지 갈 자신이 있음
-
-### 기획의도
-
-어떤 게임인지 앞서서 기획의도
-
-- 요즘에 유행하는 인디게임들 특징을 살리고, 과거의 잊혀진 추억의 게임들
-- 저격한 포인트는 공감성, 병맛, 숨겨진 스토리 등등
-- 반복도 좋지만 적은 코스트로 다양한 경험을 주고 싶어서
-
-(키워드 는 둥둥)
-
-- 키워드
- - 공감, 블랙앤 화이트, 이미테이션,
-
-### 게임설명
-
-- 게임 시스템 (핵심, 서브)
-- 게임 플레이 flow
-
-- 텍스트 콘솔, 2D, 3D, 비쥬얼 노벨
-- 다크 판타지, 퍼즐
-
-#### 게임 스토리
-
-
-
-잊혀진 게임들이 있는 마을인 `퀘렌시아`에 접속한 플레이어 게임을 플레이하며 마을의 비밀을 파헤친다.
-
-처음 접속하니 콘솔창에서 Text로 플레이를 하며 XX게임에서 튀어나온 용을 물리쳐야 한다.
-
-처음에는 깰 수 없는 구조로 만들어져서 죽음을 반복하여 캐릭터를 새로 만들고 플레이하게 된다.
-
-마을의 고물상이 파는 아이템을 사서 플레이하며 마을의 비밀을 파헤쳐라!
-
-고물상은 아이템을 파는데 아이템이 다른 잊혀진 이미테이션 게임들의 설정창(리듬 게임), 인벤토리(RPG), 스탯창(비쥬얼 노벨) 등등을 판매하는
-
-```대본
-되게 웃기게 스탯창을 안팔아서 비쥬얼노벨 스탯창을 구매해서 매력을 올리던가
-
-게임의 상식에서 벗어난 다양한 `N`스러운 아이디어가 되게 많다.
-
-사운드 팩도 상점에서 구매하여 적용해야 열리는 기믹이 있다던가 정말 다양하게 가지를 뻗을 수 있음
-```
-
-해금 조건은 마을 주민들의 퀘스트를 수행하여 얻을 수 있다 -> 어떤 미니게임의 아이템을 얻어오는 것
-
-#### 메인 시스템
-
-게임 자체가 한 마을에서 이뤄지고 마을 자체를 변경해가면서 플레이 해야함
-
-- 콘솔 텍스트, 2D, 3D등 다양한 플랫폼을 옮겨다녀야 하는데 이는 메인 스트림을 통해 진행됨
-
-ex) 상점에서 구매한 설정창 아이템에서 2D -> 3D로 변경하여 플레이 자체의 환경을 변환
-
-: 한 마을에 대한 지루한 느낌보다 색다른 느낌으로 플레이 가능
-
-메인 스트림을 진행하기 위해서 서브 시스템을 클리어하여 조건을 충족하여야 함
-
-#### 서브 시스템
-
-마을 주민들의 부탁으로 잊혀진 게임들(병맛)을 플레이하여 필요한 아이템을 수급
-
-ex) `빨간 모자를 쓴 남성의 콧수염`같은
-
-이런 퀘스트를 클리어 하면서 게임의 숨겨진 의미, 스토리를 자연스럽게 노출
-
-게임은 팩맨이라고 한다면 팩맨의 유령으로 플레이하는 씩의 병맛적인 요소, 무너지는 테트리스 등등
-
-숨겨진 업자 이미테이션게임을 만드는?
-
-### 게임 아트, 레퍼런스
-
-- 게임 아트 스타일
- - 기본적으로 블랙 앤 화이트
- - 포인트되는 부분은 색상을 넣어서 이질감을 줌(텍스트 알피지인데 설정창은 고퀄게임의 설정창 등등)
- - 전체적으로 실제 연극같은 아트풍(돈 스타브, 램오브 컬트 등등)
-- 언더테일, 스톤알피지, 드래곤 퀘스트
-- 그 외 매우 다양한 이미테이션 게임
-
-- 개인적으로 담고싶은 스토리
- - 죽음과 삶
- - 이상과 현실
- - 아나키스트의 마을 (왕이 없는 마을)
-
-BUT 게임에 스토리를 담고 싶으면(하고 싶은 말을 하고 싶다면) 게임이 기본적으로 재밌어야 한다.
-
-블랙앤 화이트라 개발 비용이 적음
-
-### 개발 방식
-
-```대본
-스케일이 크다고 생각할 수 있는데 게임 설계 자체가 구조적으로 독립된 형태라 되게 간단함
-
-다양한 게임에 대해 찍먹으로 제작한다는 느낌으로 여러 경험을 할 수 있음
-
--> 이미 유명한 게임들의 이미테이션이라 정보도 많음
-```
-
-실제 현업에서 사용하는 애자일 스크럼 방식을 도입하여 개발
-
-*도입하여 팀에 맞게 변화하여 적용*
-
-- 현업 개발 PM분의 멘토링을 받을 예정 (격주 단위로)
- - 프로젝트를 성공시키는 법에 대한 이야기
- - 효과적인 개발적인 개발 방법에 대한 이야기
-
-단순 포폴이 아닌 실제 출시를 목적으로 설계를 하고 기획
-
-```대본
-- **계획적으로 하는 걸 해봤는지**
- - 보통은 없다
- - (이 프로젝트가 계획적으로 진행된다는 걸 설명하기)
- - 디테일한 작업 계획은 개인이 가져가야함, 큰틀은 목록으로 뽑는다.
-
-- 진행상황 공유
- - 자신의 능력치를 제대로 인지하는지
- - 매일 매일 진행상황을 공유하는 것에 대한 생각
-
-- 꾸준한 프로젝트를 지향한다
- - CI/CD, 프로젝트 목표, 회고를 명확하게 할 것을 사전에 고지
- - 다같이 확인해야함
- - 이게 되어야 예측이 가능함
-
-**애자일의 스크럼 방식 -> 스프린트 방식**
-
-설계하고 실행하고 회고한다.
-```
-
-### 모집
-
-- 기획 : 1명
-- 프로그래밍 : 1명
-- 아트 : 2명
-
-강조하고 싶은 것
-
-비슷하고 별 다른 100개의 게임보다 제대로 된 1개의 게임을 만들고 싶다면 참여
-
-잘 만들 자신이 있다.
-
-### 목표
-
-1년 이상을 생각, 스튜디오 개설까지
-
-- 중간 중간 목표 설정
- - 내년 SGM, GDC, E3 등등 무조건 지원
-
-- 중간 중간 워크숍은 열리는 게임잼을 같이 나가면 좋을 듯 하다.
-
-### 문의 창구
-
-- 인터뷰 예정, 카카오톡 알려주기
\ No newline at end of file
diff --git a/draft/project/GameOverProject/image-1.png b/draft/project/GameOverProject/image-1.png
deleted file mode 100644
index ac56528..0000000
Binary files a/draft/project/GameOverProject/image-1.png and /dev/null differ
diff --git a/draft/project/GameOverProject/image-2.png b/draft/project/GameOverProject/image-2.png
deleted file mode 100644
index 1731386..0000000
Binary files a/draft/project/GameOverProject/image-2.png and /dev/null differ
diff --git a/draft/project/GameOverProject/image.png b/draft/project/GameOverProject/image.png
deleted file mode 100644
index c4e0782..0000000
Binary files a/draft/project/GameOverProject/image.png and /dev/null differ
diff --git "a/draft/project/GameOverProject/\355\224\204\353\241\234\354\240\235\355\212\270 \354\240\234\354\225\210\354\204\234.pdf" "b/draft/project/GameOverProject/\355\224\204\353\241\234\354\240\235\355\212\270 \354\240\234\354\225\210\354\204\234.pdf"
deleted file mode 100644
index 7a6a42e..0000000
Binary files "a/draft/project/GameOverProject/\355\224\204\353\241\234\354\240\235\355\212\270 \354\240\234\354\225\210\354\204\234.pdf" and /dev/null differ
diff --git a/draft/project/IntroduceSelf.md b/draft/project/IntroduceSelf.md
deleted file mode 100644
index 3a1f0d4..0000000
--- a/draft/project/IntroduceSelf.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-title: "자기소개 정리.."
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-01-01
-last_modified_at: 2022-01-01
-
----
-
-# 브릿지
-
-저는 스스로 말의 무게를 아는 사람이라고 생각합니다. 사람이 입 밖으로 뱉은 말에 대한 책임은 무거우며 영향이 큽니다. 이러한 성격을 말하는 이유는 제 성격의 장점이라고 자부할 수 있기 때문입니다. 약속을 어기거나 가벼운 말을 하지 않기 때문에 원만한 인간관계를 유지할 수 있다고 생각합니다. 하지만 말의 무게를 알기에 쉽게 선택하지 못하는 경우가 종종 있습니다. 이러한 단점을 해결하기 위해 사람들과 섞여서 선택에 대한 고민을 많이 하고 있습니다.
-사람들과 어울리는 것을 좋아하고 뭐든지 배우려고하는 성격입니다. 최근에는 스마일게이트 챌린지의 우수 팀으로 선정되어서 스마일게이트 멤버십프로그램을 진행중에 있습니다. OBT행사나 다른 팀들과의 교류도 서슴지 않고 먼저 나서는 편이며, 서로에게 도움이 되는 환경을 조성합니다.
-게임은 제가 보여주고 싶은 걸 보여주는 것. 영화, 드라마 등과 크게 다르지 않다고 생각합니다.
-인디게임 개발자로 성장하기 위해 동아리에 지원하게 되었습니다.
-
-
-개발 중에도 삽질을 굉장히 좋아하지만 나 혼자서 하는 삽질에서 한계를 느낀 것 같습니다.
-제가 하는 있는 방식에 대한 피드백이나 다른 파트와의 교류 그리고 같은 게임개발자들과 교류하고 싶은 마음이 가장 큽니다. 작년에 지원하고 싶었지만, 따로 포트폴리오나 자신을 피력할만한 것들이 없어서 지원하지 못한 마음이 있어 이번이 기회라고 생각했습니다.
diff --git a/draft/project/OZ_Challenge.md b/draft/project/OZ_Challenge.md
deleted file mode 100644
index 63b80e9..0000000
--- a/draft/project/OZ_Challenge.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: "웅진씽크빅 게임 기획서"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-07-29
-last_modified_at: 2022-07-29
-
----
-
-# 목차
-
-1. 게임 개요
-2. 게임 컨셉
-3. 세계관
-4. 게임 구조
-5. 핵심 게임 플레이
-
-## 게임 개요
-
-게임 이름: 넘버릭
-게임 주제: 수의 개념을 이해
-게임 소재: 양수와 음수 그리고 사칙연산
-게임 장르: 디펜스 게임으로 플랫폼형 슈팅게임
-게임 시점: 2D 탑뷰
-플랫폼: 모바일
-대상층: 초등학생(8~16)
-
-## 게임 컨셉
-
-터치로 조작하며 2D 도트 디자인을 차용
-일반적인 디펜스게임 공격력을 사용하는 것이 아닌
-기본적인 음수의 개념을 위해 몬스터가 양수의 범위나 양수의 범위를 지닌다.
-해당 수에 맞는 타워를 조합하여 공격한다.
-
-음의 타워(-타워), 곱하기 타워, 나누기 타워등 ..
-
-사칙연산을 여러가지로 조합할 수 있는 타워로 구분하고 기본적인 사칙연산의 조합을 통해 수의 개념을 확장.
-ex) 음수로 변환의 경우 수가 반대로, 나누기의 경우 결과값이 달라지는 법칙을 설명
-
-## 게임 세계관
-
-디펜스 게임이기 때문에 세계관은 목적성만 부여
-
-숫자마을에 침략온 몬스터무리를 지키는 기본적인 내용
-
-## 게임 구조
-
-
-
-아직은 구체화되지 않았지만 추후 업그레이드 예정.
-
-## 핵심 게임 플레이
-
-디자인된 레벨의 퍼즐 의도, 해당 맵에 컨셉에 맞게(양수의 숲, 음수의 늪지대..) 플레이한다.
-
-초반 이후로 증가되는 난이도 몬스터에 맞게 플레이 방식을 변화해야 한다.
-
-숫자의 개념이기 때문에 몬스터가 요구하는 숫자를 맞춰서 공격해야 한다.
-
-다양한 숫자포탑, 부호, 연산을 조합하는 유동성이 존재한다.
diff --git a/draft/project/SGM_Team.md b/draft/project/SGM_Team.md
deleted file mode 100644
index 4579838..0000000
--- a/draft/project/SGM_Team.md
+++ /dev/null
@@ -1,41 +0,0 @@
-체리케이크팀이 어떤 팀인지 물으신다면..!
-대답해드리는게 인지상정
-SGM의 참여를 위해
-SGM의 밝은 미래를 위해
-게임 출시와 판매를 목표로 게임을 만드는
-인디게임 개발팀의 귀염둥이 악당
-디자인의 유나, 용현
-프로그래밍의 수용, 정안
-기획의 정훈, 지우
-우주를 누비는 우리 개발단들엔
-아름다운 미래, 밝은 내일이 기다리고 있다!
-안녕하십니까! SGM에 지원하게 된 '체리 케이크'팀입니다.
-저희 팀은 스마일게이트 챌린지에서 결성된 팀으로 이번 SGM에 지원하게 되었습니다.
-체리 케이크 팀을 키워드로 표현하자면 크게 '브랜드', '마라톤', '청소기'입니다.
-
-첫 번째, '브랜드'는 팀원 개개인의 색이 확실하다는 점이 브랜드 고유특성과 유사하다는 점입니다.
-각자의 색으로 블랜딩 되어 게임을 바라봐서인지 초기부터 다양한 아이디어가 교류되었습니다.
-이러한 과정에서 나온 피드백들은 기발한 아이디어로 성장하였고 전혀 섞이지 않을 것 같던 성격들이 잘 스며들어 특별한 게임을 만들어 나가고 있습니다.
-지금 '체리케이크'라는 팀으로 하나의 브랜드로 만들어지는 과정에 있습니다.
-
-두 번째, '마라톤'은 완주를 목표로 하는 달리기 경기로 저희 팀은 각자의 자리에서 최선을 다했다는 점입니다.
-마라톤이라 해서 개인의 경쟁이라고 생각할 수 있지만 팀원 모두가 발맞춰 걸으며 '완성'이라는 목표로 쉬지 않고 달려갔습니다.
-달려가는 과정에서 발을 맞추는 방법은 온라인 오프라인 회의도 있었지만, 합숙이라는 24시간 개발과정이 큰 힘이 되었습니다.
-2달간의 챌린지가 종료되고 모두가 가장 먼저 든 생각은 팀원 개인의 퍼포먼스적인 부분이 100% 그 이상으로 발휘되었다는 점입니다.
-개인의 능력이 좋았던 이유는 당연하게 팀원을 신뢰했기 때문에 가능했다고 생각합니다.
-저희 팀은 이미 마라톤을 한번 달려 완주해봤기 때문에 자신 있습니다.
-
-세 번째, '비빔밥'이 마지막 키워드인 이유는 앞서 설명한 브랜드라는 개인의 색이 뚜렷하지만 잘 섞이는 과정에 있다고 말했습니다.
-다양한 재료가 황금비율로 섞여서 맛있는 맛을 내는 비빔밥처럼 저희는 다양한 재료를 사용하여 요리를 진행 중이지만 맛이 뚜렷하고 능력을 최대로 발휘했기 때문에 정리가 필요합니다.
-이 과정을 주마다 회의를 진행하며 진행 상황을 공유하고, 파트에 상관없이 게임에 대한 애정을 원동력으로 즉각적인 피드백을 진행했습니다.
-맛이 과하거나 재료가 많이 들어가는 경우는 회의를 통해 정리해가며 게임의 완성도를 높였습니다.
-아직도 요리 중이며, 넣고 싶은 재료가 많이 남아있습니다.
-
-저희 팀은 스마일게이트 챌린지에서 프로젝트 진행, 운영, 협력을 배웠다면 이젠 SGM을 통해 게임 고도화, 출시 단계로 나아가고 싶습니다.
-
-세 번째,'비빔밥'는 집이 더러워졌을 때나 물건을 많이 사 와서 한 번에 청소할 때 청소기를 많이 사용합니다.
-물건이 많아져도 청소를 한번 한다면 집이 훨씬 더 정돈되어 보입니다.
-마지막 키워드가 청소기인 이유는 앞서 말한 2가지 때문입니다.
-팀원 개인의 색이 뚜렷하고 능력을 최대로 발휘했기 때문에 정리가 필요합니다.
-이 과정을 주마다 회의를 진행하며 진행 상황을 공유하고 파트에 상관없이 즉각적인 피드백을 진행했습니다.
-필요에 따라서는 자발적으로 합숙을 진행하였고 이러한 과정에서 회의가 귀찮거나 싫다는 생각보다는 필요한 과정, 설레는 순간으로 바뀌게 되었습니다.
diff --git a/draft/project/SmileCherry_idea.md b/draft/project/SmileCherry_idea.md
deleted file mode 100644
index 947bcbf..0000000
--- a/draft/project/SmileCherry_idea.md
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: "프로젝트 체리 아이디어 정리"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-07-15
-last_modified_at: 2022-07-15
-
----
-
-# 정리 이유
-
-SGM미팅에서 얻은 지식을 정리하여 효과적으로 프로젝트를 진행하기 위해서
-
-## 살려야 하는 게임특색
-
-1. 스토리중심의 진행
-
-이전 게임에서는 스토리중심 게임이라고 하지만 게임성을 살리기 위해서 스토리 진행라인을 많이 버리고(ex. 카메라 워킹, 라이트 노벨식 게임 진행등)진행하여 가독성, 몰입도가 많이 떨어짐
-
-2. 증강체(기계화 게이지)
-기계화 게이지에 따른 엔딩, 플레이 방식등이 달라져야 한다.
-현재는 수치로만 존재하고 플레이에 직접적인 영향이 없어서 그 효과가 미비하다. 따라서 높아짐이나 낮아짐을 조절하여 플레이에 직접적인 영향을 끼치는것이 중요해 보임, 꼭 기계화 게이지가 아니더라도 직접적인 선택에 따른 영향을 주는 수치는 필요하다.
-++ 증강체 아이템을 추가하여 좀 더 다양한 효과를 주는게 중요함
-
-
-
-
-
-
-
-
-
-스토리 아이디어 노트
-
-기계간의 사랑
-인트로에서 ai실험영상을 보여주면서 호기심을 자극하면 좋을 듯함
-
-리얼돌 스토리
diff --git a/draft/project/SmileCherry_idea_2.md b/draft/project/SmileCherry_idea_2.md
deleted file mode 100644
index 31a170c..0000000
--- a/draft/project/SmileCherry_idea_2.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-title: "프로젝트 체리 아이디어 정리"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-07-21
-last_modified_at: 2022-07-21
-
----
-
-# 스토리 2
-
-1. 헥터는 기계다.
-헥터는 원래 인간이였지만 운이 좋게 3등시민들에게 2등시민으로 갈 수 있는 기회? 티켓?을 받아서 정부로 인솔된다.
-(아일랜드 느낌..)
-
-2. 눈을 뜨다.
-헥터가 눈을 떠보니 쓰레기 장이다.
-주위에는 온통 망가진 로봇들이다.
-대사 -> " 뭐지..?"
-주위를 둘러보던 도중 어디선가 말소리가 들린다.
-체리 대사 -> " 헥터? 헥터 너 맞아?"
-
-불현듯 스치는 기억
-
-------------------------------
-0. 체리는 헥터의 히로인
-헥터는 기억이 잘 나지 않지만 체리는 자신의 좋은 친구였다는 기억이 남아있다.
-(잔상)
-------------------------------
-
-체리를 기억해낸 헥터가 여기가 어딘지 묻다가 자신의 몸을 발견한다.
-
-3. 망가진 기계가 되어버린 헥터.
-
-헥터가 비명을 지린다. "으어어어어어!ㅋ"
-체리가 진정시키며 "한참 동안 널 찾았어 헥터"라고 말한다.
-헥터가 무슨일인지 묻자 체리는 지금은 2189년이라고 대답하며 이야기를 설명해준다.
-- 헥터가 티켓을 받은지 무려 30년(100년..?)이라는 시간이 흐른 뒤였다.
-- 정부는 3등시민들을 착출하여 기계에 사람의 몸을 결합하는 실험을 하고 있었다.
-- 헥터의 이름은 CK_0927이다.
-
-4. 3등시민 구역 외곽 (정부의 은밀한 기계처리장)
-
-헥터는 체리의 말을 듣고 1등 시민으로 가서 (자신의 몸? OR 복수?)를 꿈꾼다.
-
-(헥터 자체도 무기로 만들어짐. 근처 망가진 기계 또한)
-
-자신과 비슷하게 생긴 기계들이 널브러져 있다.
-
-체리가 말한 대로 자신의 몸을 찾기 위해선 정부의 비밀 관리시설로 가야한다.
-
-움직임을 체리를 통해서 배우던 도중 멀리서 기계가 다가온다.
-
-"제 이름은 CK_1921... ㅈ...우..지우입니다.."
-거의 다 망가져서 같은 자리를 몇번 씩 왕복하며 자신의 이름을 기억하려 하는 모습이다.
-
-지나쳐서 갈려하던 도중
-"원칙에 위배되는 모듈 장착 확인."
-지우가 눈이 빨개져서 다가온다..
-(체리로 부터 튜토리얼 진행 앞 부분은 이동,, 지금은 공격)
-중간 중간 체리와 대화 -> 과거에 있었던일 어릴 때 뭐뭐~~
-헥터는 전혀 이상함을 못느끼고 공감한다.
-
-5. 정부에 가까워 질 수록 강해지는 몬스터
-
-몬스터를 잡기 위해선 파츠를 강화할 필요가 있어 "헥터"
-
-"지금 까지 잡은 몬스터에서 나온 '볼트'로 공격력을 강화해봐"
-(상점 시스템 / 튜토리얼 튜토리얼)
-"지금은 겨우 정신을 유지중이지만 업그레이드(모듈)진핼할 수록 점점 인간성을 잃어버릴 꺼야"
-기계화 게이지가 증가함에 따라 다른 부품으로 교체 가능(공격방식 변화)
-
-헥터 -> "체리 진짜 고마워 너 밖에 없다..!"
-"근데 너는 지금 어디있는거야?"
-(자신만 생각하다보니 체리가 걱정되는 헥터)
-
-6. 체리의 행방은?
-
-"지금은 '퀘렌시아'에서 일하고 있어"
-
-"ㅇㄷ?"
-
-"정부밑에서 심부름을 하는 곳?"
-
-블라블라
-
-점점 가까워 질 수 록 과거의 사건을 자주 언급하는 체리
-
-7. 보스전
-
-보스전 촤약 촤약 액션
-
-8. 엔딩
-
-내용 : 체리라는 존재는 처음부터 없으며 헥터를 실험하기 위한 정부 ai의 테스트(정부 보안 시스템? 좀 더 서사 필요)
-
-1. 헥터가 체리를 만나 자신의 몸을 찾는 엔딩 (기계화 게이지 40%~60% 정부 보스 처치) 노말엔딩
- - 어느정도 기계화 되었기 때문에 체리가 헥터에게 환상을 보여준다.
-2. 헥터가 체리의 정체를 발견하는 엔딩(기계화 게이지 30%미만 정부 보스 처치) 진엔딩
- - 헥터에게 환상을 보여줄려고 하지만 전원이 꺼지지 않고 자아가 명확하게 존재
- - 스스로 이미 인간으로 돌아갈 수 없음을 깨달음
- - 체리 진 보스 만남
- - 스토리가 없어지고 처음부터 다시 깨고 보스가 추가되는 엔딩도 재밌을 듯
-3. 헥터가 강화된 기계무기로 정부의 개가됨(기계화 게이지 70% 이상) 배드엔딩
- - ai의 성공적인 실험이였고 인간성을 평가하는 지표가 됨
- - 강력한 만큼 명령에 충실하게 정부를 지킴
-
-기계화 게이지에 따라 헥터의 말이 어눌해지고 화면이 지지직 거림 (플레이어가 헥터)
-
-워딩 설정
-정부,
-
-
-
-
-
-
diff --git a/draft/project/SmileCherry_idea_3 copy.md b/draft/project/SmileCherry_idea_3 copy.md
deleted file mode 100644
index 3c9e60e..0000000
--- a/draft/project/SmileCherry_idea_3 copy.md
+++ /dev/null
@@ -1,26 +0,0 @@
----
-title: "프로젝트 체리 아이디어 정리"
-excerpt: " "
-
-categories:
- - Blog
-tags:
- - [Blog]
-
-toc: true
-toc_sticky: true
-
-date: 2022-07-22
-last_modified_at: 2022-07-22
-
----
-
-#
-
-
-
-
-
-
-
-
diff --git a/draft/sitemap.xml b/draft/sitemap.xml
deleted file mode 100644
index 45c473e..0000000
--- a/draft/sitemap.xml
+++ /dev/null
@@ -1,104 +0,0 @@
----
-layout: compress
-
-# The Sitemap template
-# v2.0
-# https://github.com/cotes2020/jekyll-theme-chirpy
-# © 2017-2019 Cotes Chung
-# MIT License
----
-
-
-
-{% for post in site.posts %}
- {% unless post.published == false %}
-
- {% capture lastmod %}
- {% if post.lastmod %}
- {{ post.lastmod }}
- {% elsif post.date %}
- {{ post.date }}
- {% else %}
- {{ site.time }}
- {% endif %}
- {% endcapture %}
-
-
- {{ site.url | append: site.baseurl | append: post.url }}
- {{ lastmod | date_to_xmlschema }}
-
- {% if post.sitemap.changefreq %}
- {{ post.sitemap.changefreq }}
- {% else %}
- monthly
- {% endif %}
-
- {% if post.sitemap.priority %}
- {{ post.sitemap.priority }}
- {% else %}
- 0.5
- {% endif %}
-
- {% endunless %}
-{% endfor %}
-
-{% for page in site.pages %}
-
- {% assign pass = false %}
-
- {% for fuzzy in site.sitemap_exclude.fuzzy %}
- {% if page.url contains fuzzy %}
- {% assign pass = true %}
- {% break %}
- {% endif %}
- {% endfor %}
-
- {% unless pass %}
- {% for accurate in site.sitemap_exclude.accurate %}
- {% assign len = accurate | size %}
- {% capture beg %}{{ 0 | minus: len }}{% endcapture %}
- {% capture tail %}{{ page.url | slice: beg, len }}{% endcapture %}
-
- {% if tail == accurate %}
- {% assign pass = true %}
- {% break %}
- {% endif %}
-
- {% endfor %}
- {% endunless %}
-
- {% if pass %}
- {% continue %}
- {% endif %}
-
- {% capture lastmod %}
- {% if page.lastmod %}
- {{ page.lastmod }}
- {% elsif page.date %}
- {{ page.date }}
- {% else %}
- {{ site.time }}
- {% endif %}
- {% endcapture %}
-
-
- {{ site.url | append: site.baseurl | append: page.url | remove: "index.html" }}
- {{ lastmod | date_to_xmlschema }}
-
- {% if page.sitemap.changefreq %}
- {{ page.sitemap.changefreq }}
- {% else %}
- monthly
- {% endif %}
-
- {% if page.sitemap.priority %}
- {{ page.sitemap.priority }}
- {% else %}
- 0.3
- {% endif %}
-
-
-{% endfor %}
-
-
\ No newline at end of file
diff --git a/draft/unity_in_sort/2022-02-23-unity_in_wwwww.md b/draft/unity_in_sort/2022-02-23-unity_in_wwwww.md
deleted file mode 100644
index 5564e27..0000000
--- a/draft/unity_in_sort/2022-02-23-unity_in_wwwww.md
+++ /dev/null
@@ -1,161 +0,0 @@
----
-title: "[Unity] "
-excerpt: " "
-
-categories:
- - Unity
-tags:
- - [Unity, Dev]
-
-toc: true
-toc_sticky: true
-
-date: 2022-02-23
-last_modified_at: 2022-02-23
----
-
-# 정리
-
-## 유용한 팁 정리
-
-* 해당 오브젝트 선택 후 f로 찾아가기 할 수 있다.
-* 게임실행 도중에 ff키로 게임 오브젝트를 따라가기할 수 있다.
-
-
-* Tag, Sorting Layer, Layer관련 식별자는 대문자로 작성한다.
- * 스크립트에서 문자열로 비교하기 때문에 오류를 줄이기 위해
-
-
-
-
-# 유니티
-
-## 에디터 구조
-
-### 하이러키
-
-* 하이어라키창에서 계층화(오브젝트간의 부모, 자식)기능을 `페어런팅`이라 함
-* 또한 부모 오브젝트의 레이어를 상속 받는다.
-
-#### 락킹 기능
-
-* 해당 오브젝트를 하이어라키를 통해서만 선택할 수 있다. 즉, 씬에서 선택 불가능
-
-#### 씬 가시성 기능
-
-* 해당 기능을 통해 해당 오브젝트를 잠시 꺼두고 작업할 수 있다.
-
-### 인스펙터 뷰
-
-씬, 하이러키, 프로젝트에서 선택된 오브젝트의 속성을 보여주고 수정할 수 있다.
-
-### 게임 뷰
-
-개발 중인 게임을 미리 볼 수 있으며 다양한 해상도로 볼 수 있다.
-
-* 씬 뷰에 있는 메인카메라의 시야로 랜더링 해서 보여준다.
-
-### 콘솔 뷰
-
-* 디버깅시 출력하는 메시지로 정보, 경고, 오류등을 출력한다.
-
-에러 발생 시 해결 순서는 위에서 부터 순차적으로 해결한다.
-
-> Ctrl + shift + C
-
-### 툴바
-
-* Q(View): 씬뷰의 이동으로 사용
- * v키를 통해서 스내핑기능을 사용가능하다.
-* W(Move): 선택한 게임오브젝트의 좌표축으로 이동시킨다.
-* E(Rotate): 선택한 게임오브젝트를 회전시킨다.
- * 일정각도를 회전하는 snap은 ctrl를 누르고 회전한다.
-* R(Scale): 선택한 게임오브젝트의 스케일을 변경한다.
-* T(Rect): 선택한 UI객체의 이동, 회전, 스케일을 변경한다.
-* Y(Transform): 선택한 객체의 이동, 회전, 스케일을 변경한다.
-
-### 피봇/센터
-
-pivot으로 설정하면 원점 좌표로 설정한 위치가 원점으로 설정되며 center의 경우 중앙으로 무조건 설정된다.
-
-### 로컬/글로벌
-
-로컬 좌표와 글로벌 좌표는 따로 포스팅에 자세하게 다룸.
-
-[좌표 관련 포스팅](https://fkdl0048.github.io/unity/unity_in_coordinates/)
-
-### play/pause/step
-
-플레이 버튼과 중지 버튼은 지금까지 많이 사용했지만 step버튼은 한 프레임단위로 실행할 수 있는 유용한 버튼이다.
-
-> play: Ctrl + P
-> pause: Ctrl + Shift + p
-> step: Ctrl + Alt + P
-
-### 검색
-
-매우 유용한 기능으로 리소스 검색이나 필요한 키를 검색하여 사용 가능하다.
-
-> Ctrl + K
-
-## 유니티 기능
-
-### 텍스처
-
-유니티는 오브젝트에 다양한 이미지파일을 매핑시킬 수 있는데 이를 간단하게 텍스처를 입힌다고 한다.
-
-> 유니티가 지원하는 다양한 이미지 파일 형식 png, jpg, tiff, gif, bmp, tga 등등
-
-유니티에서는 텍스처의 원본을 건드리지 않고 압축하여 용량을 줄이기 때문에 이를 유용하게 사용가능하다.
-
-2ⁿ형태일 때 압축을 지원(모바일의 경우 필수적)
-
-### 머티리얼
-
-머티리얼은 텍스처를 반복, 재질등의 표현방식을 정리한 속성이다.
-
-### 모델
-
-모델의 크기를 수정할 때에는 Scale Factor를 수정하자..!
-
-
-## 유니티 정보
-
-### 컴포넌트
-
-* 유니티 컴포넌트중 transform은 절대로 삭제할 수 없다.
-
-## 스크립트
-
-* public으로 선언한 변수는 인스펙터 창에서 보이게 되고 자동 첫글자 대문자 키워드 사이 공백출력으로 바뀐다. (창에서만)
-* 인스펙터창에 노출된 변수의 값이 우선순위를 가지며 스크립트 내부의 변수값이후에 설정이 되기 때문에 값 설정에 있어서 오류가 빈번하게 발생
-
-
-
-## 3D Object
-
-3D오브젝트들은 항상 Mesh Filter와 Mesh Renderer컴포넌트를 가지고 있다. Mesh Filter컴포넌트는 3차원 형상인 메시데이터를 가지고 있고 해당 메시정보를 바탕으로 화면에 랜더링 하는 컴포넌트가 Mesh Renderer이다.
-
-~Renderer컴포넌트들은 대부분 Materials속성을 가지고 있다.
-
-### 랜더링 관련
-
-랜더링 관련 정보는 좀 더 공부를 해야하는 부분
-
-\
-
-
-## attribute
-
-* [Space] 빈공간 한칸 삽입
-*
-
-
-증강체 아이템
-
-기본 캐릭터: 이동속도, 점프 높이, 점프 속도 + 2, 대쉬 속도, 최대 체력
-
-공격: 공격력, 레어(공격 범위(크기)) + 기계화 10, 공격 속도
-
-치료 아이템 기계화 -5
-
diff --git a/draft/unity_in_sort/2022-08-04-unity_in_feedback.md b/draft/unity_in_sort/2022-08-04-unity_in_feedback.md
deleted file mode 100644
index 7d5eb56..0000000
--- a/draft/unity_in_sort/2022-08-04-unity_in_feedback.md
+++ /dev/null
@@ -1,68 +0,0 @@
----
-title: "[Unity] 유니티 피드백"
-excerpt: " "
-
-categories:
- - Unity
-tags:
- - [Unity, Dev]
-
-toc: true
-toc_sticky: true
-
-date: 2022-08-04
-last_modified_at: 2022-08-04
----
-
-# 피드백
-
-
-## 유니티 스터디 피드백
-
-### 08/03 피드백
-
-실제로 현업에서도 유니티 프로파일러가 자주 쓰이나요?
-
-> 그렇습니다. 평소에는 잘 안보다가 특정 구간에서 frame이 떨어진다던가 메모리 관련 예외가 나면 그때서야 찾아보기 시작하는 거 같아요. 그런데 그런 것도 겪다 보면 자연스럽게 방어적으로 프로그래밍을 하게 되는 것 같습니다.
-
-조금 벗어난 질문이긴 하지만 c#은 namespace의 경우 중첩을 해도 크게 문제가 없는거 맞나요?
-내부과정이 궁금합니다.
-
-> 네 괜찮습니다. 말 그대로 class나 enum 같은 것들을 묶어 두기 위한 공간이라고 보시면 되요. Java의 package와 달리 물리적 폴더 구조가 아닌 논리적 namespace 정의를 따릅니다. 즉 파일들이 다른 폴더 구조를 갖고 cs 파일 이름 같거나 다르다고 하더라도 같은 namespace 안에 정의된 class 라면 using 문을 사용할 때 문제는 없습니다.
-
-유니티 함수 내부는 가려둔게 맞나요? (선언부로 이동은 가능한데 항상 동작코드)
-
-> .NET 참조 때문에 가려져 있는 게 맞습니다. 그런데 .NET이 오픈 소스라 그냥 github 가서 보시면 볼 수 있습니다.
-
-게임쪽 질문이라 애매할 수 있지만... 물어보겠습니다..
-데이터를 다룰 때 scriptableobject가 적합한지 Json이 적합한지.. 궁금합니다.
-케이스 바이 케이스일까요?
-
-> ScriptableObject는 에디터에서만 동작한다는 한계가 있으므로 적합하지는 않을 거고요. Json도 그냥 쓸 수 없으므로 Json serialize해서 객체로 만들어서 많이 씁니다.
-
-c# lock의 경우 왜 파라미터로 object가 들어가는지.. 궁금합니다
-제가 이해를 못한걸 수 있는데 여러 쓰레드가 한번에 접근하지 못하도록 하는건 알겠지만 왜 파라미터로 뜬금없는 object가 들어가는지..ㅠ
-
-> 요거는 일단 microsoft 공식 문서를 보고 그 다음에 얘기를 해보면 될 거 같습니다.
-https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/statements/lock
-변경이 불가능한 인스턴스만 할당하면 맞는 거 같은데 거기에 적합한 것이 readonly object 타입인 것이죠
-
-컴포넌트를 참조할 때 (시작할 때 1회) 방법이 여러가지 있을 경우 어떤 걸 선택해야하는지 모르겠습니다..
-(find, SeralizeField, GetComponet 등등..)일반적으로 사용되는 방식이 궁금합니다.
-
-> 편한 방식으로 사용하시면 좋습니다. 예제로 많이 나오는 방식은 GetComponent니까 GetComponent를 사용하면 좋겠네요.
-
-충돌에 관한 처리를 할때 플레이어 <-> 오브젝트의 관계에서 어디에 제어를 두는게 좋은지..
-(제어라 함은 플레이어에게 스크립트, 오브젝트에게 스크립트)
-
-> 저라면 오브젝트 쪽에 둘 거 같은데 이유는 플레이어는 처리해야 할 것들이 너무 많기 떄문에 관련 있는 오브젝트 쪽에 플레이어 정보만 넘겨주고 처리하는게 좋기 때문입니다.
-
----
-
-평소에 궁금한 것들이 많이 있어서 좋은 것 같습니다.
-뜬금 없는 질문도 괜찮으니까 많이 물어보세요!
-
-1. 방어적 프로그래밍에 대해서 좀 더 알아보고 적용해보도록 노력하겠습니다..!
-2. namespace의 정의에 대해서 좀 더 공부할 것!
-3. Json강의 공부 후 확실하게 정리하기
-4.
\ No newline at end of file
diff --git a/draft/unity_in_sort/Localization.md b/draft/unity_in_sort/Localization.md
deleted file mode 100644
index 6017a23..0000000
--- a/draft/unity_in_sort/Localization.md
+++ /dev/null
@@ -1,142 +0,0 @@
-# 현지화를 위한 작업
-
-- 여러 방법이 있지만 유니티에서 지원해주는 방법을 사용
-
-Localization 패키지(자동으로 바인디되어 어드레서블 패키지도 같이 들어옴)
-
-## 설정
-
-
-
-- CommandLine Locale Selector: 커맨드 라인에서 지역을 선택
-- System Locale Selector: 해당 시스템(안드로이드에서 선택된 지역)
-- **Specific Locale Selector**: 게임내에서 언어를 바꿈
-
-Locale Generator로 사용할 언어파일을 만들 수 있음(따로 세팅)
-
-Project Locale Identifier: 프로젝트에서 기본으로 사용할 언어 설정
-
-Windows -> Asset Manangement -> Localization Table을 통해 테이블 설정 가능
-
-### Table
-
-
-
-Localization Table을 통해 테이블을 만들면 설정된 언어에 따라 +1개의 테이블이 만들어짐(관리, 언어당 한개)
-
-구조는 딕셔너리와 같이 Key와 Value로 이루어져 있음
-
-각 언어에 대해서 메타데이터를 설정할 수 있고, 따로 언어의 value마다 하나씩 설정할 수 있음
-
-### 적용 (Event)
-
-
-
-string Reference를 통해 사용할 Key, Table을 설정하고 값을 직접 확인할 수 있음
-
-해당 컴포넌트에서 Update String을 통해 변경할 String값을 이벤트로 설정가능
-
-Runtime Only에서 -> Editor and Runtime으로 변경하면 에디터에서도 확인 가능
-
-RunTime중에 이제는 오른쪽 위에 있는 툴바를 통해 언어를 변경 가능
-
-오브젝트에서 직접 추가도 가능함
-
-### Asset Table
-
-string뿐만 아니라 지역에 따른 다른 Asset을 사용할 수 있음(sprite, audio 등)
-
-해당 에셋의 점 세개의 설정으로 가서 rocalize를 누르면 맞는 이벤트를 생성해줌
-
-### Localization Scene Controls
-
-
-
-Windows -> Asset Manangement -> Localization Scene Controls
-
-Editor단계에서도 언어를 변경하여 체크할 수 있음
-
-**중요**
-
-- TrackChange: 언어가 변경되었을 때 이벤트를 발생시킴
-
-자동으로 인스펙터의 변경사항을 저장하여 이벤트로 생성해줌 즉, 에디터 단계의 직접적인 수정을 이벤트로 바인딩하여 기록
-
-편리함
-
-### Smart
-
-내부 스트링에 들어가는 문자열의 경우 값을 받아와서 사용가능한 형태
-
-"(Plaer_name)이 입장하셨습니다"와 같은 형태
-
-만약 싱글플레이의 경우 플레이어를 전역으로 다루기 때문에 사용은 간단함
-
-따로 variables Group을 만들어서 사용하면 된다.
-
-
-
-### Script
-
-스크립트에서 접근하는 방법은 LocalizationSettings를 통해 접근
-
-```c#
-using System.Collections;
-using UnityEngine;
-using UnityEngine.Localization.Settings;
-
-public class LocaleController : MonoBehaviour
-{
- bool isChanging = false;
-
- public void ChangeLocale(int index)
- {
- if (isChanging)
- return;
-
- StartCoroutine(ChangeLocaleCoroutine(index));
- }
-
- IEnumerator ChangeLocaleCoroutine(int index)
- {
- isChanging = true;
-
- yield return LocalizationSettings.InitializationOperation;
- LocalizationSettings.SelectedLocale = LocalizationSettings.AvailableLocales.Locales[index];
-
- isChanging = false;
- }
-}
-```
-
-- 지역화 초기화 기간동안은 변경이 불가능하므로 기다려야함
- - 해당 값은 LocalizationSettings.InitializationOperation으로 확인 가능
-- 지정된 지역은 인덱스로 접근하여 변경 가능
-
-다음은 데이터를 가져오는 방법
-
-```c#
-LocalizationSettings.StringDatabase.GetLocalizedString("Table", "Key", "current locale");
-```
-
-위와 같이 사용은 못하지만 예시로 사용할 Table에서 Key값을 넣고 현재 지역을 넣어주면 해당 값을 가져올 수 있음
-
-## Extentions
-
-가장 중요한 데이터 처리부분
-
-두가지 형태를 지원 csv, google sheet
-
-### CSV
-
-
-
-- CSV 파일을 만들어서 사용
-
-사용에 매우 간편하지만 보안에 취약하고, 수정이 불편함
-
-이후에 좀 고민해보면 좋을 문제
-
-table자체를 성격에 따라 분리하여 csv로 관리하면 매우 편할 듯 하다.
-
-나중에 대화 시스템을 만들게 된다면 다른 패키지와의 결합이 가장 문제일 듯
\ No newline at end of file
diff --git a/draft/unity_in_sort/NewInputSystem.md b/draft/unity_in_sort/NewInputSystem.md
deleted file mode 100644
index 37ee4ce..0000000
--- a/draft/unity_in_sort/NewInputSystem.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# New Input System
-
-프로젝트 초기 세팅으로 작업하기 위해 정리
-
-## 정리
-
-해당 게임이 다양한 디바이스에 동작할 수 있도록 해주는 래퍼라고 생각하면 됨
-
-설정창에서 설정하고 init하는 과정은 블로그 참고
-
-- Action Maps
- - Scene마다 입력방법이 달라지거나, 캐릭터마다 달라져야 하는 경우
- - 현재 게임에서 챕터마다 달라질 수 있는 키로 지정하면 될 듯
-- Action
- - 입력방법
- - 키보드, 마우스, 조이스틱 등
-- Properties
- - 입력방법에 대한 세부 설정
-
-## 사용
-
-다양한 Input 바인딩 확인
-
-플랫폼 지원이 후작업으로 가능하기 때문에 키보드만 생각하고 작업해도 좋을 듯
-
-## 참고
-
-- https://d-dl.tistory.com/139
\ No newline at end of file