wlsgk7779 님의 블로그

카테캠 1단계 1주 2회차 강의

wlsgk7779 — Thu, 2 Jul 2026 21:30:59 +0900

https://colab.research.google.com/drive/124xuFcS6BsCwfLiipltllz7llec_c9WW?usp=sharing

openai의 tool call 동작 코드

프롬프트와 관련하여 zero shot, few shot, instruction, CoT 등이 있다.

1. Zero-shot

예시 없이 바로 질문하는 것

"이 문장이 긍정인지 부정인지 말해줘.
오늘 날씨 정말 좋다"

→ AI: "긍정"

2. Few-shot

예시를 몇 개 보여주고 패턴을 따라하게 하는 것

"긍정이면  , 부정이면  

오늘 날씨 좋다 →  
기분이 별로야 →  

오늘 점심 맛있었어 → ?"

→ AI: " "

3. Instruction

AI한테 역할과 규칙을 명확하게 지시하는 것

"너는 일정 관리 AI야.
날짜는 반드시 YYYY-MM-DD 형식으로 써.
삭제 전에 반드시 목록을 먼저 조회해."

4. CoT (Chain of Thought)

단계별로 생각하게 유도하는 것

# CoT 없이
"15 * 27은?" → "405"

# CoT 있이
"15 * 27을 단계별로 계산해줘"
→ "15 * 20 = 300
   15 * 7 = 105
   300 + 105 = 405"

비교 정리

기법핵심언제 쓰냐

Zero-shot	예시 없이 질문	간단한 질문
Few-shot	예시 보여주기	특정 형식/패턴 원할 때
Instruction	역할/규칙 지시	AI 행동 제어할 때
CoT	단계별 사고 유도	복잡한 문제 풀 때

옛날 vs 요즘 프롬프트 방식

옛날 (모델 성능 낮을 때)

"너는 일정 관리 AI야.
일정 생성할 때는 이렇게 해.
일정 조회할 때는 이렇게 해.
날짜 형식은 이렇게 해.
절대 이건 하면 안 돼.
반드시 이 순서로 해.
..."
→ 처음부터 모든 규칙을 빽빽하게 써야 했음

요즘 (모델 성능 좋을 때)

1. 일단 기본 프롬프트만 주고 실행
         ↓
2. 문제 발생한 부분 발견
         ↓
3. 그 부분만 보완

이때 사용하는게 few shot과 CoT 등

few shot : 예시를 보여주는 것

CoT : 동작 순서를 알려주는 느낌

이런 식으로 언제 이 툴을 써야하는지 description에 써줄 수 있다. 예시 같은 것을.

카테캠 2주차 과제 진행

wlsgk7779 — Thu, 2 Jul 2026 09:48:26 +0900

1주차에서 아래 내용과 시스템 프롬프트를 좀 수정함

"tool_name" : personal_list_schedules.__name__,

카테캠 1주차 과제 진행

wlsgk7779 — Tue, 30 Jun 2026 10:15:11 +0900

0. 먼저 WSL (윈도우에서 리눅스 환경 쓰는거)를 우분투로 연결할건지 선택하기. (참고)

왜냐하면 ./run.sh --install 이런 명령어를 과제 준비할 때 써야하는데, 리눅스 터미널에서 쓸 수 있는거라서

윈도우에서 쓰려면 run.sh 파일 안에 있는 명령어들을 따로 하나하나 입력줘야 해서 불편할 수 있고,

매번 저런 명령어 만나면 AI한테 윈도우용 명령어로 바꿔달라고 해서 입력해야함.

만약 WSL 연결을 한다면, 우분투22.04 클릭해서 터미널 나오면 cd .. (이전 폴더로 가기) 랑 ls (하위폴더보기) 등으로 위로 나간다음에 아래와 같이 경로가 "/" 까지 간 후 ls 하면 아래와 같은 폴더들이 나옴.

이때 cd mnt 로 이동하면 그 안에 c 라는게 있는데 그게 윈도우의 c드라이브라서 거기서 쭉쭉 녕이 카카오 폴더? 있는 곳까지 이동해서 code . 하면 WSL 연결돼서 열린다. => 그러면 VScode 터미널이 리눅스 터미널로 열린다! => 그러면 ./run.sh --install

이런 명령어도 그냥 칠 수 있음!

진하는 아래와 같은 경로가 우분투에서의 윈도우 작업 폴더야 /mnt/c/Users/ASUS/kakao

저 /mnt 아래 c 부터는 윈도우 경로랑 같다고 보면 댐!

1. 노션에서 "클론코딩 프로젝트 PR/일정 안내" 확인하고 1-1 부터 1-4 까지 진행하기

1-1, 1-2 는 진행했겠지?

1-3 : chungnam-clone 레포들어가서 링크 복사 후 git clone 하기

1-4 : 이름/final 브랜치까지 만들고 push를 통해 깃허브에서 동일한 이름의 브랜치 만들기까지

*만약 WSL 연결해서 한다고 하면

1-2 push 인증 부분을 리눅스 환경에서 다시 진행해야한다! (윈도우로 할거면 안 해도 됨)

우분투 22.04 열어서 아래 2가지 명령어 입력해서 깃허브에 인증하면 됨
# gh 설치

sudo apt install gh

# GitHub 로그인

gh auth login

2. 노션 그 페이지 바로 밑에 이 부분에서 명령어 1, 2 진행하기 (3, 4는 나중에 완성하면 진행하는 것)

(이름/final 브랜치로 이동 후 최신상태 가져오고(git pull) 이걸 베이스로 이름/week1 브랜치 생성하는 과정임)

3. 과제 경로에서 해당 명령어 실행하기

./run.sh --install

sh 파일은 스크립트 파일인데, 여러 명령어들이 순서대로 모여있는거임!

이걸 저 ./run.sh 로 실행해서 안에 있는 명령어를 알아서 실행하게 할 수 있는데, sh파일은 리눅스의 스크립트 파일이라 윈도우에서 실행 안됨.

윈도우에서 실행하려면

uv sync

uv run python app.py

위 2가지 명령어 실행하면 되는 듯. (sh파일 내부를 AI한테 복붙해서 윈도우 명령어로 바꿔달라고 하면 됨)

--install이 붙어서 uv sync(패키지설치하기) 까지 하는 것이고,

앞으로 실행할 때는 uv run python app.py 치면될듯

4. 과제 경로에서 env 예시파일 복사해서 env 파일 만들기

cp .env.example .env

이거 입력해서 .env 파일 생성되면 어제처럼

여기에 API 키 넣으면 된다.

5. 공부 및 과제 진행하기

# [수강생 구현 가이드]
#
# 목표
#   Nana가 "내 일정 만들어줘/보여줘/지워줘" 같은 개인 일정 요청을 받았을 때
#   LLM이 직접 고를 수 있는 LangChain tool 3개를 완성합니다. Week 1의 일정은
#   앱 DB에 저장하지 않는 현재 대화 전용 임시 메모리입니다.
#
# 구현 위치와 사용할 코드
#   - 이 파일(student_parts/week01_wake_up_nana.py) 안의 @tool 함수 3개를 직접 구현합니다.
#   - 임시 저장소는 이 파일 상단의 PERSONAL_SCHEDULES 리스트입니다.
#   - JSON 문자열 반환은 이 파일의 _json(payload) helper를 사용합니다.
#   - 새 일정 ID는 _new_personal_id(), 생성 시각은 _now_iso()를 사용합니다.
#   - 현재 채팅 범위 분리는 fixed/session_scope.py의 current_session_scope() 값을
#     schedule dict의 session_id에 넣고, 조회/삭제 때 같은 session_id만 대상으로 삼아 처리합니다.
#   - week01_tools()가 세 tool을 LangChain agent에 공개하고, build_week01_agent()가 이 목록을 사용합니다.
#
# 구현 대상
#   1. personal_create_schedule
#      - title/date/start_time/end_time/attendees 인자로 schedule dict를 만듭니다.
#      - id는 "personal_" 접두어가 붙은 임시 ID, created_at은 현재 시각으로 채웁니다.
#      - attendees가 None이면 빈 list로 바꾸고, session_id=current_session_scope()를 함께 넣어
#        PERSONAL_SCHEDULES에 append합니다.
#      - 반환 JSON에는 ok, tool_name, created_schedule을 넣습니다.
#      - Week 1 반환에는 structured_request나 sqlite_save를 넣지 않습니다.
#
#   2. personal_list_schedules
#      - PERSONAL_SCHEDULES를 직접 수정하지 않고 현재 대화 범위의 일정만 조회합니다.
#      - date_from이 있으면 그 날짜 이상, date_to가 있으면 그 날짜 이하만 남깁니다.
#      - 날짜 비교는 YYYY-MM-DD 문자열 기준으로 충분합니다.
#      - 반환 JSON에는 ok, tool_name, schedules를 넣습니다.
#
#   3. personal_delete_schedule
#      - schedule_id가 일치하면서 현재 대화 범위에 속한 일정만 삭제합니다.
#      - 리스트 객체 자체는 유지해야 하므로 PERSONAL_SCHEDULES[:]에 새 목록을 대입합니다.
#      - 삭제 전후 길이 비교로 deleted 값을 만들고 JSON으로 반환합니다.
#      - 다른 대화 범위의 같은 ID는 삭제하면 안 됩니다.
#
# 중요한 반환 규칙
#   LangChain tool은 문자열 반환이 가장 안정적입니다. dict를 만든 뒤 _json(...)으로 감싸세요.
#   Week 1 도구는 현재 대화 안에서만 쓰는 임시 일정 dict만 반환하며 SQLite/App store를 호출하지 않습니다.
#
# 참고 코드
#   week01_system_prompt, week01_tools(), build_week_agent(), trace helper는 구현 대상이 아닙니다.
#   이 함수들은 "LLM이 어떤 tool을 볼 수 있는지"와 "trace를 어떻게 보여주는지"를 이해할 때 읽습니다.
#
# 검증 방법
#   앱을 ./run.sh --week1로 실행하고 채팅에 하네스 프롬프트를 넣습니다.
#   상세 trace에서 LLM이 personal_create_schedule/list/delete 중 어떤 tool을 골랐는지 확인합니다.
#   tool 결과 JSON에 created_schedule, schedules, deleted가 있는지도 확인합니다.
#
# 함수별 동작 설명
#   - join_system_prompt(parts)
#     여러 주차에서 만든 system prompt 조각을 하나의 문자열로 합칩니다. 뒤 주차 지시가 앞 주차 지시보다
#     우선된다는 공통 헤더를 붙여서, Week 2 이후 파일들이 같은 방식으로 prompt를 누적할 수 있게 합니다.
#
#   - _json(payload)
#     LangChain tool이 반환할 dict를 JSON 문자열로 바꿉니다. ensure_ascii=False를 사용해 한글 답변과
#     일정 제목이 escape되지 않게 합니다.
#
#   - _now_iso()
#     일정 생성 시각을 timezone이 포함된 ISO 문자열로 만듭니다. 학생 코드에서는 created_at 기록용으로만 사용합니다.
#
#   - _new_personal_id()
#     Week 1 임시 일정에 붙일 짧은 고유 ID를 만듭니다. DB ID가 아니라 현재 Python 프로세스 안에서 쓰는 임시 ID입니다.
#
#   - _schedule_scope(schedule)
#     일정 dict가 어느 대화 범위에 속하는지 읽습니다. 예전 테스트처럼 session_id가 없는 row는 기본 scope로 취급합니다.
#
#   - _current_session_schedules()
#     PERSONAL_SCHEDULES 전체 중 현재 conversation/session 범위에 속한 일정만 골라 반환합니다.
#
#   - personal_create_schedule(...)
#     LLM이 일정 생성이 필요하다고 판단했을 때 호출하는 tool입니다. 입력 인자로 schedule dict를 만들고
#     PERSONAL_SCHEDULES에 append한 뒤, 생성된 schedule을 JSON 문자열로 반환합니다.
#
#   - personal_list_schedules(date_from, date_to)
#     현재 대화 범위의 임시 일정만 읽고 날짜 범위 필터를 적용합니다. 리스트를 수정하지 않고 조회 결과만 반환합니다.
#
#   - personal_delete_schedule(schedule_id)
#     현재 대화 범위에서 schedule_id가 같은 일정만 제거합니다. 다른 대화 범위의 일정은 같은 ID처럼 보여도 지우지 않습니다.
#
#   - week01_tools()
#     Week 1 agent가 사용할 수 있는 tool 목록을 반환합니다. create_agent(...)가 이 목록을 보고 tool calling을 수행합니다.
#
#   - week01_system_prompt() / week01_prompt_parts()
#     Week 1 agent의 역할, 현재 날짜, tool 사용 규칙을 담은 system prompt를 만듭니다.
#
#   - build_week01_agent() / build_week_agent()
#     LangChain agent를 한 번만 만들고 재사용합니다. build_week_agent()는 실행기에서 공통으로 호출하는 표준 이름입니다.
#
#   - list_personal_schedule_dicts(...)
#     tool이 아닌 내부 helper입니다. 다른 주차 코드가 Week 1 임시 일정을 dict list로 바로 읽어야 할 때 사용합니다.
#
#   - ensure_demo_personal_schedule()
#     데모/테스트에서 빈 일정 저장소를 피하려고 기본 임시 일정을 하나 넣습니다. 이미 일정이 있으면 아무 일도 하지 않습니다.

일본문화

wlsgk7779 — Tue, 16 Jun 2026 07:42:13 +0900

챕터5

" 봄 연중행사 "

(1) 오쇼가쓰 1월 1일

1. 1월1일부터 3일까지 : 산가니치

2. 새해 : 오쇼가쓰

3. 정초에 참배하는 것 : 하쓰모데

4. 명절이나 설에 먹는 요리 : 오세치요리

5. 오세치요리 5가지 : 연근조림, 마른멸치조림, 다시마조림, 검은콩, 새우

6. 콩은 "마메"라고함, 성실하다는 "마메마메시이"

7. 기뻐하다는 "요로코부"인데 다시마는 "곤부" 뒤가 비슷함

8. 오쇼가쓰에 먹는 떡국 : 오조니

9. 오조니에 들어가는 둥글게 생긴 떡 : 가가미모치

10. 세벳돈 : 오토시다마

11. 도시가미 강림을 나타내는 소나무 대나무 장식 : 가도마쓰
12. 가가미모치는 "동거울"을 연상하게 한다.

13. 신년 장식물로서 볏짚을 왼쪽으로 꼬아 만든것 : 시메나와

14. 신을 모시는 선반 : 가미다나

15. 시메나와를 장식한 것 : 시메카자리

16. 시메카자리가 장식된 곳은 "신성한 장소" 이다.

17. 새해에 일본인들은 복주머니 같은 [ 후쿠부루로 ]를 산다.

(2) 세쓰분

1. 세쓰분은 원래 [ 춘하추동 ] 의 분기점이 되는 4가지를 의미한다.

2. 오늘날에는 봄의 세쓰분을 칭한다.

3. 세쓰분 전야의 콩 뿌리기를 [ 마메마키 ] 라고 부른다.

4. 콩을 뿌리는 이유는 [ 집안의 잡귀를 쫓아내려 한 것 ] 이다.

5. 콩을 뿌리는 역할은 [ 집주인 ] 이나 [ 그 해의 간지와 동일한 해에 출생한 사람 ]이 담당한다.

6. 볶은 콩을 먹으면 1년간 병이 들지 않고 건강하게 보낼 수 있다고 하여 [ 자기 나이 수만큼 ] 콩을 먹는다.

(3) 히나 마쓰리 3월 3일

1. 3월 3일에 열리는 여자 어린이들의 성장과 행복을 기원하는 전통행사이다.

2. 3월 3일 전후에 복숭아 꽃이 피는 까닭에 [ 모모노셋쿠 ] 라고도 한다.

3. 딸들의 축제라는 뜻에서 [ 온나노셋쿠 ] 라고도 한다.

4. 제일 윗 단에는 왕과 왕비를 나타내는 [ 이리비나 ] 두고,

5. 그 아래 단에는 궁녀 인형 3개인 [ 산닌간죠 ]

6. 그 아래에는 악기 연주하는 인형 5개인 [ 고닌바야시 ]

(4) 하나미

1. 벚꽃나무 밑에 자리 잡고 노는 잔치를 [ 하나미 ] 라고한다.

2. 벚꽃이 만개될 것으로 예상된 지역을 선으로 이은 것을 [ 사쿠라전선 ] 이라고 한다.

" 여름 연중행사 "

(1) 단고노셋쿠 5월 5일 (어린이날)

1. 단고노셋쿠에는 마당에 [ 고이노보리 ]를 매달고 목욕을 한다.

2. 잉어 깃발은 잉어가 폭포를 거슬러 가듯 [ 입신출세 ] 하라는 의미이다.

3. 잉어가 입신출세의 상징이 된 이유는 중국 고사에서 [ 등용문 ]이라는 말이 나왔기 때문이다.

4. 무사인형과 작은 갑옷, 투구를 둬서 강하게 자라기를 기원한다.

(2) 다나바타 7월 7일 (다시 나를 바타줘)

1. 견우와 직녀가 만들 수 있도록 까마귀와 까치가 [ 오작교 ]라는 다리를 놓아준다고 함

2. 저녁에 비가 오면 만났다는 기쁨의 눈물, 이튿날 새벽에 비가 오면 이별의 슬픈 눈물

3. 7월 7일 다나바타 마쓰리가 열리고, 소원을 적는 길고 가느다란 종이인 [ 단자쿠 ]

(3) 오본 (추석)

1. 오본은 달력에는 표시되지 않은 비공식적인 연휴지만, 샐러리맨들에게 긴 연휴의 기회이다.

2. 본이란 죽은 이의 영혼을 의미하는 [ 우라본 ] 이라는 불교용어에서 유래됐다.

3. 오본이 시작되는 13일 저녁 무렵이 되면 [ 무카에비 ] 라고 하여 조상의 영혼을 맞이하는 불을 피우는데 요즘은 전구를 쓰기도함

4. 불단 앞에 [ 본다나 ]라는 조상의 정령을 모시는 선반을 임시로 설치한다.

5. 16일에는 집이나 절 입구에 [ 오쿠리비 ]라는 조상의 영혼을 보내는 불을 피운다.

6. 본다나에 올린 음식을 강이나 바다에 띄어 보내는 [ 쇼로나가시 ] 를 한다.

7. 오본 기간동안, 밤에 동네 사람들이 모여 노래, 피리 북 장난에 맞춰 추는 춤을 [ 본오도리 ] 라고한다.

" 가을 연중행사 "

(1) 오쓰키미 음력 8월 15일 (달 보기) 오! 쓰키(달) 미 (아름답다)

1. 밝은 달은 감상하는 것을 [ 오쓰키미 ]라고한다.

2. 음력 8월 15일, 보름달이 떠오르는 날을 [ 십오야 ] 라고 하며, [ 쓰키미 단고 ] 등의 공양물을 놓고 달맞이를 함

"겨울 연중행사 "

(1) 시치고산 11월 15일

1. 시치고산은 11월 15일에 3세와 5세 남자아이, 3세와 7세 여자아이에게 나들이 옷을 입혀 마을의 수호신인

[ 우지가미 ]를 모시는 신사에 가서 액막이를 받는 행사이다.

2. 옛날에는 "일곱살까지는 신에게' 라고 할 정도로 유아의 사망률이 높아서 7세까지 무사히 살아 온 아이의 성장을 씨족신에게 보여 감사한다는 의미가 있다.

3. 또한 홀수를 행운의 수로 생각하여 [ 시치고산 ] 이라는 이름이 붙게 됐다.

4. 시치고산 때는 [ 지토세아메 ] 라는 시치고산 축하용 홍백의 가래엿을든 아이들의 모습을 볼 수 있다.

(2) 도시노세 12월 28~12월 31 ( 도시가미 신이 곧 노세~~ )

1. 12월 28일부터 12월 31일경으로 일년을 마무리하고 새해를 맞이하는 준비기간을 [ 도시노세 ] 라고한다.

2. 한해를 정리하고 새해를 새롭게 시작한다는 의미로 신년맞이 대청소인 [ 스스하라이 ]를 한다.

3. 섣달 그믐날 밤인 [ 오미소카 ]에는 제야의 종소리를 들으며 새해를 축하하는 메밀국수인 [ 도시코시소바 ]를 먹는다.

4. 또한 홍백가합전인 [ 고하쿠우타갓센 ] 을 본다.

5. 사찰에서는 오전 0시를 목전에 두고 제야의 종을 치기 시작해 108번을 울린다.

6. 도시코시소바는 긴 국수처럼 가족의 건강과 장수가 계속되길 기원하는 뜻과,

7. 국수가 잘 끊어지는 것에서 유래해 액운과 빚을 청산한다는 의미를 담고있다.

(3) 연하장

1. 12월이 되면 연하장을 쓰는데, 감사한 사람들 등에게 보내는 인사장이다.

2. 연하장은 추첨용 복권인 [ 오토시다마 쿠지 ] 가 붙어있어 행운도 전달할 수 있다.

3. [연하특별우편제도] 에 의해 연말까지 우체국에 모아둔 연하장을 설날아침에 일제히 배달한다.

[ 국 경 일 ]

1월 1일 : 오쇼가쓰 (새해)

1월 1일로 한 해의 시작을 축하한다.

1월 1일만 빨간날이지만 3일까지 공휴일이다.

조상들에게 추도를 표하고 새해에 신사나 절을 가기도 한다.

1월 둘째 주 월요일 : 성인의 날

전년도 4월 2일부터 그 이듬해 4월 1일까지 20세가 된 사람을 성인으로 인정하고 축하하는 날

이제 성인이 된 여성들은 성인의 날에 [ 후리소데 ] 를 입는다. 가장 화려하고 미혼 여성만 입을 수 있음

2월 11일 : 건국기념일

2월 23일 : 천황탄생일

2019년 5월에 즉위한 레이와일왕의 생일

3월 21일 : 춘분의 날

밤과 낮의 길이가 같은 날을 뜻한다.

춘분과 추분을 중심으로 한 전후 3일간의 1주일을 [ 히간 ] 이라고하며,

히간은 생사의 바다를 건너 도달하는 깨달음의 세계, 즉 저세상이다.

이 시간에는 사람들이 조상의 묘에 성묘하러 가고 일본 황실에서도 천황의 조상에 대한 제사

4월 29일 : 쇼와의 날 : 골든 위크 시작 날

현재 천황의 선친인 히로히토 천황의 생일

5월 3일 : 헌법기념일

5월 4일 : 녹색의 날

국경일의 3일과 5일 사이에 끼어있어서 국경일이 됨

5월 5일 : 어린이날 : 골든위크 마지막 날

7월 셋째 주 월요일 : 바다의 날

8월 11일 : 산의 날

9월 셋째 주 월요일 : 경로의 날

9월 23일 : 추분의 날

10월 둘째 주 월요일 : 스포츠의 날

11월 3일 : 문화의 날

11월 23일 : 근로감사의 날

유래는 가을에 수확한 곡물을 신에게 드리면서 감사하는 [ 니이나메사이 (궁중제사) ] 에서 비롯되었다.

[ 챕터 7 ] 애니

[애니메이션의 태동기]

본격적인 애니메이션의 시작은 [ 1940년대 ] 이다.

일본에서 처음 상영된 디즈니 장편 애니메이션은 [ 백설공주 ] 인데, 이는 애니메이션계 종사하는 사람들이게 신선한 충격..

제 2차 세계대전 이후 대형 영화사인 [ 도에 ] 는 1956년 자회사로 애니메이션 전문업체인 [ 도에동화 ] 를 설립했다.

도에동화는 1958년 일본 최초의 장편 컬러 애니메이션인 [ 백사전 ] 을 제작함

백사전은 중국의 민화를 제재로 한 러브스토리 애니메이션.

[애니메이션의 출발기]

1960년대에 만화가 겸 애니메이션 작가로 활동한 [ 데즈카 오사무 ]가 등장하여 흐름을 바꿈

데즈카 오사무는 1961년 [ 무시프로덕션 ] 을 설립하고,

일본 최초의 TV용 애니메이션인 [ 철완아톰 ] 을 제작.!!

적은 제작비와 부족한 시간을 해결하기 위해 [ 리미티드 애니메이션 기법 ] 을 시도해 대성공

[ 리미티드 애니메이션 기법 ] 이란 1초간 촬영하는 그림의 매수를 줄여 움직임에 절대적으로 필요한 캐릭터의 일부 동작과 키 포즈에 해당하는 움직임만을 그려내는 제작방식.

원래 [ 철완아톰 ] 은 데즈카 오사무가 14년간 연재하던 만화였는데 TV애니메이션 성공으로 인해 63년부터 66년까지 총 193화가 흑백으로 제작, 1980년에는 컬러로 리메이크됨.

애니메이션의 인기로 인해 아톰은 학용품이나 옷 등에 새겨지기도 함!

프로덕션이 위치한 사이타마현에서 지역사회 특성화의 일환으로 아톰에게 특별주민등록증 발급해줌!

이 시기에 제작된 대표적인 애니로는 [ 거인의 별 ] [ 태양의 왕자 호루스의 대모험 ] 등

1969년부터 현재까지 매주 일요일 저녁 후지 TV에서 방영되고 있는 최장수 애니메이션인 [ 사자에산 ]

[애니메이션의 발전기]

[ 기동전사 건담 ]은 주인공을 중심으로 펼쳐지는 기존 틀을 깸. 로봇 또한 현실성이 중시되면서 [ 리얼 로봇물 ] 이라는 새 장르탄생

일본 최초 주제가 앨범이 제작되고 100만장 이상이 판매된 애니메이션은 [ 캔디 캔디 ]

소년들이 로봇물에 빠질 때, 소녀들은 캔디캔디에 빠졌다.

1978년 미야자키 하야오 감독이 단독 연출을 맡은 [ 미래소년 코난 ]은 데뷔작이자 NHK 최초의 애니메이션 연속물이다.

[애니메이션의 전성기]

1980년대는 내용과 기술면에서 큰 발전을 거둔 애니의 전성기이다.

방송 목적이 아니라 판매 목적으로 나온 OVA(original vidio animation)가 출현한 것도 이때이다.

1983년 오시이 마모루가 감독한 지구인과 달 이주민 사이의 정체성의 대립을 그린 [ 달로스 ] 가 OVA 애니메이션의 최초 작품이었지만 흥행 실패 ㅠㅠ

그러나 다나카 요시키 소설이 원작인 [은하영웅전설]은 큰 성공.

-> 110화가 OVA로 제작되었고 외전도 나옴, 만화책이나 컴퓨터게임으로도 나옴!

1980년대에는 가이낙스 와 스튜디오 지브리의 설립!!

이 스튜디오를 통해 원작을 만화에 의지하지 않는 오리지널 스토리의 극장용 애니메이션 작품이 다수 제작!

[애니메이션의 세계화]

1990년대 특징으로 [ 오타쿠 ]문화를 대두로 들 수 있다.

[ 오타쿠 ]란 특정 분야나 취미에 열중하는 사람을 가리키는 일본어로 광적인 매니아라고 할수있따.

[ 오타쿠 ] 는 원래 '당신', '댁' 이라는 뜻을 지닌 대명사이다.

[ 오타쿠 ] 라는 말은 1983년 일본에서 처음 사용되었는데, 만화나 애니, 게임, 비디오 등 서로 관련있는 대중 문화에 몰두하여 같은 취미를 가진 사람들이 동호회에서 만나 예의를 지키고 존중하는 의미에서 오타쿠라고 불렸다.

이러한 오타쿠 문화를 발전시킨 것은 1995년에 방영된 [ 신세기 에반게리온 ] 이다.

신세기 에반게리온은 가이낙스의 에바 프로젝트에 의해 제작되었는데 TV방영 당시엔 그닥 주목 받지 못함.

그러나 뒤늦게 오타쿠의 관심대상이 되면서 [ 에바 신드롬 ] 을 불러일으켰다!

오타쿠들은 작품에서 전달하고자 하는 수수께끼를 푸는 재미에 열광하였고, 1997년에는 극장판까지 만들어짐

[ 공각기동대 ] 도 선풍을 불러일으킴. 참신한 기술과 완성도 높은 내용으로

1996년 미국 빌보드지의 비디오 차트에서 1위를 하였고 수많은 영향을 미쳤다.

2004년 속편으로 [ 이노센스 ] 가 나왔는데, 이는 칸느 영화제에 출품되어 높은 평을 받았고, 미국평론가들에게 2004년 최고의 애니로 뽑혔다.

지브리의 애니메이션도 디즈니 보급망을 타고 세계 애니메이션 시장에 수출되었다.

[ 챕터 9 ] 기모노

중요한 거 같은 것만.

1. 헤이안 시대에는 천황과 귀족들은 자신의 부와 권력을 상징하기 위해 겹쳐입는 옷으로 형태가 발전함

대표적으로 귀족 가문의 남자 정장인 [ 소쿠타이 ]

여성 귀족용 복식인 [ 주니히토에 ]

둘 다 소맷부리가 크고 넓다. 가장 기본 속옷으로 [ 고소데 ] 입음

2. 무사시대일때 무가의 여자들은 고소데 위에 더 긴 고소데를 걸쳐입는 [ 우치카케 ] 입음

계급층은 쇼군으로서의 위엄과 무사로서의 활동성을 겸하여 [ 가타기누 ] 입은 후 얇은 [ 오비 ] 로 마감함

[ 가타기누 ] 의 특징은 어깨선에 각을 넣어 왜소한 체격을 커버할 수 있다!!

아따 (어깨) 기누~ 로 가타기누 외우기.

3. 메이지나 다이쇼 시대 학교 안팎에서는 여학생들이 일상적으로 [ 하카마 ] 라는 넓은 치마를 즐겨입음.

이게 문화가 되어서 현재도 입학식이나 졸업식에 [ 하카마 ]를 정장으로 입기도함

다이쇼 후기에는 하카마를 대신해 세라복이라고 불리는 세알러칼라가 달려있는 교복등장

[ 하카마 ]는 [ 넷카마 ] 와 말이 비슷!

4. 기모노의 종류 1 ( 하오리와 하카마 )

남자들의 옷은 보통 [ 나가기 ] [ 하오리 ] [ 하카마 ] 로 크게 구분할 수 있다.

1). [ 나가기 ] : 발목까지 옷자락이 닿는 길이의 기모노

2). [ 하오리 ] : 보통 무릎 위 중간까지만 오는 겉옷?느낌

이 중 [몬쓰키하오리] 는 결혼식이나 중요한 행사에 예장으로 입는 것으로, 양쪽 가슴에 가문의 문장을 넣는다!!

몬쓰키하오리 중 가장 정식 형태는 [ 구로몬쓰키하오리 ] 라고 하고, 보통 결혼식 때 일생에 한번 입을 정도임

원래 방한용으로 입기 시작한 하오리는 고소데 위에 입는 나가기 바깥에 겁쳐 입으며, 하오리의 길이도 유행이 바뀌는 양상이다.

3) [ 하카마 ] : 다이쇼시대부터 여학생도 입음. 약간 통이 넓은 치마바지 같은 형태임!!

처음에는 기모노를 보호하거나 보온용 목적이었지만,

현재의 하카마는 남성이 결혼식을 할 대나 다도회 등이 있을 때 예장용으로 주로 입는다.

검도 등을 할 때 입는 도복도 하카마를 변형한 것!

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

기모노의 종류 2 : 도메소데와 후리소데

여성의 기모노는 소매 길이를 보면 그 여성이 기혼인지, 미혼인지 알 수 있다.

[ 도메소데 ] : 기혼 여성이 입는 기모노로, 소매의 길이가 짧고, 품격을 중요시하여 결혼식이나 중요 의식에 주로 입는다.

검은 색 바탕으로 아랫 자락에 한폭의 그림과 같은 무늬가 들어가고, 어깨 앞쪽으로 가문을 상징하는 문양이 장식되는 것이 보통이다.

[ 후리소데 ] : 미혼 여성이 입는 기모노로, 도메소데에 비하면 훨씬 길이가 긴 예복용 기모노를 입는다.

길고 우아하게 늘어뜨릴 수 있는 이 소매에까지 염색이나 자수로 화려함을 더한다.

기혼 여성들은 소매가 길면 기능적인 면에서 활동이나 작업하기가 불편하기 때문에 소매가 짧아지는게 당연하고,

반대로 미혼여성들은 젊은 화려함을 부각시키는데 넓은 소매를 멋스럽게 장식하는 것이 자연스러운것이다.

-----------------------------------------------------

기모노의 종류 3 : 유카타

유카타는 헤이안시대에 귀족들이 목욕할 때 입었던 속옷 겸 목욕타운이었다!

에도시대에 서민들의 목욕문화가 보편화 되며 하얀색 목면 기모노를 유카타라고 불렀다.

오늘날의 [ 유카타 ] 는 유난히 무덥고 습기가 많은 일본의 여름을 시원하게~보낼 수 있는 계절의상으로,

정식 기모노에 비해서 입는 법이 간단하고 가격이 저렴하면서 재질과 색감이 다양하다.

특히 7월과 8월에 마쓰리나 불꽃놀이를 즐기는 곳에서 화려하고 다양한 유카타를 입은 남녀노소가 있따.

캐릭터 인형이나 부채 등을 등 뒤 오비 매듭에 꽂고 다니면서 손을 편하게 하는동시에 형식에 구애받지 않아 마쓰리(축제)와 뗄 수 없는 아이템이다!

다른 한편 유카타를 목욕가운으로 쓰는 곳은 일본의 전통 숙박시설인 [ 료칸 ] 이다.

-----------------------------------------------------

기모노의 종류 4 : 오비와 게타

[ 오비 ] 는 기모노를 입을 때 마무리로 허리춤을 감아 여미는 넒은 폭의 천이다.

기모노를 완성하는데 꼭 필요한 요소이다.

현재는 벨트보다는 다양한 무늬와 색감과 재질을 사용해 기모노에 포인트를 주는 역할이다.

[ 다비 ] 는 기모노를 입을 때 신는 것이다.

다비는 엄지와 나머지 네 발가락으로 나뉘어 있는데, 전통 신발인 게타와 조리와 맞춰 착용하며, 발꿈치 쪽에서 후크로 고정한다.

기본은 흰색이다. 여러 디자인이 있음

[ 게타 ] 는 전통 신발로, 나무판 위에 있는 세 개의 구멍을 끈으로 연결하여 발을 고정하는 형태로 바닥에는 "하" 라고 하는 돌기부분이 있따. 바닥이 높게 고안된 것은 여름에 비가 많고, 자갈길이 많은 풍토 지형적 특성 때문이다.

[ 조리 ] 는 게타보다는 격식이 있어 정장용으로 맞춰 신는 것이다.

[ 챕터 10 ] 요리

[자연을 살린 요리]

1. 일본은 식재료 본연의 맛을 살리는 것을 중요시한다.

2. 그래서 향신료나 양념을 많이 사용하지 않는다.

3. 신선한 소재의 맛을 살리는 조미료와 육수가 발달했다.

4. 일본식 조미료 종류에는 설탕, 소금, 식초, 미소, 소유, 미린, 와사비 등이 있다.

5. 조미료는 넣는 순서는 히라가나 사 행의 사(사토, 설탕) 시(시오, 소금) 스(스, 식초) 세(세유,쇼유,간장) 소(미소, 된장) 이다.

[동서양을 절충한 요리]

1. 일본 음식 문화의 특징은 일본요리와 서양요리를 절충해 새로운 스타일의 [ 양식 ] 을 만들어낸것이다.

2. [ 양식 ] 요리의 특징은 기본 룰은 그대로 지키면서 주식인 밥에 맞도록 바꾼것!

3. 오므라이스, 카레라이스, 고로케, 하야시라이드, 돈가스 등이 양식 요리로 있다.

[인스턴트 식품과 도시락]

1. 청일 전쟁 때 중국군의 비상식량인 건면에서 아이디어를 얻어 세계 최초의 인스턴트 라면인 [닛신 치킨 라면] 이 탄생

2. 닛신 식품에서 세계 최초의 컵라면도 출시!

3. 이 외에도 냉동식품이나 레토르트 식품 등이 널리 보급되고 인기를 끌었는데, 인스턴트 식품에서는 느낄 수 없는 진짜에 가까운 맛 때문이다!

4. 백화점 지하의 고급 식품관을 [ 데파치카 ] 라고한다. 데파트 와 지카의 합성어

5. 편의점이나 슈퍼마켓에서 도시락을 사다가 사무실이나 집에서 먹는 것을 [ 나카쇼쿠 ] 라고 한다.

6. 역에서 파는 도시락이라는 뜻의 [ 에키벤 ]은 각 고장의 특산물을 활용한 도시락이다.

[일본의 보존식품]

1. 일본에서는 기후와 풍토에 알맞은 보존 음식이 발달했다.

2. 호시모노, 쓰케모노, 시오카라, 낫토 등이 있다.

3. 호시모노는 햇빛에 말리는 건조법

4. 쓰케모노는 야채를 소금이나 간장, 된장 등에 절인 음식

5. 시오카라는 젓갈

6. 낫토는 삶은 콩에 낫토균을 배양해 발효시킨 것이다.

[전통 요리]

1. 일본은 전통적인 향응을 위한 기본 요리로 3 종류가 있는데, 혼젠요리, 차카이세키 요리, 가이세키 요리가 있따.

2. [ 혼젠 요리 ] 는 정식 연회에서 차려지는 요리이다.

3. [ 차카이세키 요리 ] 는 다도에서 차를 내기 전에 간단하게 내는 요리이다.

4. [ 가이세키 요리 ] 는 연회요리로서 일반적으로 이용되는 요리이다.

5. 혼젠 요리는 주로 관혼상제 때 쓰인 정식식단으로써, 차리기가 매우 복잡하나 일본음식의 기초적 식단으로 구성된다.

혼젠 요리라는 이름은 손님 대접을 위한 상차림에서 중앙에 놓는 밥상을 ' 혼젠 ' 이라고 부른 것에서 왔다.

6. 차카이세키요리는 선종의 수행 승려들이 공복감을 막기 위해 가슴에 따뜻한 돌을 품었다는 데서 유래

7. 에도시대 연회에서 식사를 즐긴 것에서 유래된 가이세키 요리는 혼젠요리 형식의 차카이세키요리 형식을 가미한것.

[외식 문화]

카테캠 2차과제

wlsgk7779 — Mon, 8 Jun 2026 23:03:46 +0900

새 폴더를 만들어서 vite와 tailwind 세팅함
기존 UI를 컴포넌트 단위로 나누려고 AI에게 트리구조를 그려달라고 하고, 그대로 폴더와 파일을 생성해달라고 했음.

todo-react/
    2 ├── public/
    3 │   └── image/ (둥둥이 이미지 파일들)
    4 └── src/
    5     ├── App.jsx (메인 레이아웃 및 상태 관리)
    6     ├── App.css (기존 바닐라 스타일)
    7     └── components/
    8         ├── Header.jsx
    9         ├── DateNavigator.jsx
   10         ├── CalendarModal.jsx
   11         ├── TodoInput.jsx
   12         └── TodoList.jsx

이런 구조로 컴포넌트를 나눔

CRUD기능을 마이그레이션 함

제시해주신 CRUD(Create, Read, Update, Delete) 핵심 기능을 React 방식으로
  완벽하게 마이그레이션했습니다!

   ️ 구현된 주요 기능

   1. Create (생성):
       * TodoInput.jsx에서 text 상태를 관리하며, 입력값이 비어있을 경우 "⚠️ 할
         일을 입력해야 둥둥이가 춤을 춰요!"라는 안내 메시지를 표시합니다.
       * 엔터 키를 누르거나 '추가' 버튼을 클릭하면 새로운 Todo가 생성됩니다.

   2. Read (조회 & 필터):
       * App.jsx에서 localStorage를 활용해 데이터를 유지하며, 현재 선택된 날짜와
         필터(전체/진행 중/완료)에 맞는 목록만 계산해서 보여줍니다.
       * 필터 상태에 따라 빈 화면의 메시지(둥둥이 멘트)가 동적으로 변합니다.

   3. Update (수정):
       * 인라인 수정 UI: TodoItem.jsx 내부에 isEditing 상태를 두어, '수정' 버튼
         클릭 시 prompt() 대신 즉시 입력창으로 전환됩니다.
       * 텍스트뿐만 아니라 카테고리도 수정 모드에서 함께 변경할 수 있습니다.

   4. Delete & Toggle (삭제 및 완료 처리):
       * 삭제 버튼 클릭 시 즉시 목록에서 제거됩니다.
       * 체크박스를 통해 완료 상태를 토글할 수 있으며, 완료 시 기존 CSS 테마에
         따라 취소선 및 투명도 처리가 시각적으로 적용됩니다.

   확인 포인트
   * useState 활용: App.jsx에서는 전체 데이터(배열)를 관리하고,
     TodoItem.jsx에서는 각 항목의 '수정 중 여부'와 같은 로컬 UI 상태를 관리하여
     역할이 명확히 분리되었습니다.
   * 선언적 UI: 바닐라 JS처럼 직접 DOM을 조작(appendChild, remove)하지 않고,
     오직 상태(todos, isEditing)만 변경하면 React가 화면을 자동으로 그려줍니다.

다음단계도 됨

네, 맞습니다! 방금 진행한 CRUD 마이그레이션 단계에서 상태별 필터링 기능도 함께
  구현을 완료했습니다.

  이미 구현된 내용을 바탕으로 확인해 드릴게요:

   필터링 기능 구현 확인

   1. 필터 상태 관리 (useState):
       * App.jsx에 const [filter, setFilter] = useState('all');가 선언되어 있어
         현재 어떤 탭이 선택되었는지 기억하고 있습니다.
   2. 탭 전환 후 Todo 추가 시 유지:
       * 탭을 전환하면 filter 상태가 바뀌고, 그 상태에서 할 일을 추가해도
         App.jsx의 filter 값은 그대로 유지되므로 새로 추가된 할 일도 필터 규칙에
         따라 자동으로 보이고 숨겨집니다.
   3. 시각적 구분:
       * TodoList.jsx에서 className={filter === 'active' ? 'active' : ''}와 같은
         코드를 통해 현재 선택된 버튼에만 active 스타일(흰색 배경 + 그림자)이
         적용되도록 처리했습니다.

---일간뷰 마이그레이션 완료 --

일간 뷰(Daily View) 기능을 성공적으로 마이그레이션했습니다!

   ️ 구현된 내용
   1. 날짜 이동 로직: DateNavigator의 좌우 화살표 버튼을 클릭하면 selectedDate
      상태가 하루씩 앞뒤로 변경되도록 구현했습니다.
   2. 동적 Todo 목록: 날짜가 바뀌면 App.jsx에서 filteredTodos를 자동으로 다시
      계산합니다. 즉, 해당 날짜에 저장된 Todo만 화면에 나타납니다.
   3. 날짜별 할 일 저장: 새로운 Todo를 추가할 때 현재 보고 있는
      날짜(selectedDate)가 자동으로 함께 저장됩니다. (어제 날짜를 보면서
      추가하면 어제 날짜로 저장돼요!)
   4. 한국어 날짜 표시: 2026년 6월 8일 (월)과 같이 기존 바닐라 프로젝트와 동일한
      친숙한 형식으로 날짜를 표시합니다.

   확인 포인트
   * 날짜 이동: 화살표를 눌렀을 때 상단 날짜 텍스트가 잘 변하는지 확인해 보세요.
   * 데이터 분리: 오늘 할 일을 추가하고 어제 날짜로 이동했을 때, 오늘 추가한 할
     일이 사라지고(숨겨지고) 깨끗한 화면이 나오는지 확인해 보세요.

-------------주간뷰 완료

주간 뷰(Weekly View) 마이그레이션을 완료했습니다! ️

   ️ 구현된 주요 기능

   1. 주간 날짜 트랙: 이번 주 월요일부터 일요일까지 7일간의 날짜를 한눈에
      보여줍니다.
   2. Todo 개수 표시: 각 날짜 아래에 해당 날짜에 할 일이 몇 개 있는지 실시간으로
      계산해서 보여줍니다. (바닐라 JS의 복잡한 DOM 조작 없이 React의 filter로
      간단히 해결!)
   3. 날짜 동기화: 주간 뷰의 특정 날짜를 클릭하면 아래 일간 뷰와 목록이 즉시
      해당 날짜로 업데이트됩니다.
   4. 주 단위 이동: 좌우 화살표를 통해 이전 주나 다음 주로 편리하게 이동할 수
      있습니다.
   5. 오늘 & 선택 날짜 강조: 오늘 날짜에는 노란색 동그라미 스타일이, 현재 선택한
      날짜에는 흰색 카드 스타일이 적용되어 시각적으로 구분됩니다.
   6. 상태 유지: 새로고침을 해도 내가 보고 있던 주차와 선택한 날짜가 그대로
      유지되도록 로컬 스토리지와 연동했습니다.

   핵심 포인트 (Vanilla JS와 비교)
   * 바닐라 JS에서는 주간 뷰를 그릴 때마다 innerHTML을 통째로 갈아 끼웠지만,
     React에서는 todos나 selectedDate 상태가 바뀔 때마다 개수와 스타일만 쏙쏙
     효율적으로 다시 그려집니다.

---------------

현재까지의 진행 상황 요약
  나중에 기억나지 않으실 때를 위해 제가 정리해 드릴게요.
   1. 컴포넌트 구조화: App, Header, DateNavigator, TodoInput, TodoList,
      TodoItem으로 분리 완료.
   2. CRUD 마이그레이션: 생성, 조회, 수정(인라인), 삭제 기능 완료.
   3. 필터링 & 날짜: 전체/진행중/완료 필터 및 일간 뷰(좌우 이동) 완료.
   4. 주간 뷰: 요일별 트랙 및 날짜별 Todo 개수 표시 완료.
   5. 카테고리: 카테고리 추가, 삭제(일반으로 이관) 기능 완료.
   6. 데이터 보존: localStorage 연동으로 새로고침해도 유지됨.

  남은 작업: 한 달 치 날짜를 보여주는 달력 모달(CalendarModal)의 상세 로직 구현

추가 기능 구현----------

1. 카테고리 별로 Todo와 주간뷰, 월간뷰에서 개수를 볼 수 있도록 함.

---------------------------------------

dateUtils.js는 프로젝트 내 여러 곳에서 공통으로 사용되는 날짜 관련 로직을 한데
  모아 관리하는 유틸리티 파일입니다.

   왜 만들었나요? (필요성)
  기존에는 App.jsx, DateNavigator.jsx, CalendarModal.jsx 등 여러 컴포넌트에서
  각자 동일한 날짜 포맷팅 함수를 중복해서 정의하고 있었습니다. 이를 한곳으로
  통합함으로써:
   1. 코드 중복 제거: 똑같은 코드를 여러 번 쓸 필요가 없습니다.
   2. 유지보수 용이: 날짜 표시 방식을 바꾸고 싶을 때 이 파일 하나만 수정하면
      모든 화면에 적용됩니다.
   3. 일관성: 앱 전체에서 날짜가 동일한 규칙(형식)으로 계산되고 표시됨을
      보장합니다.
   주요 기능 (함수 설명)
   1. formatDate(date): Date 객체를 2026-06-09와 같은 표준 문자열 형식으로
      변환합니다. 주로 할 일 데이터를 저장하거나 비교할 때 사용합니다.
   2. formatDateKorean(date): 2026년 6월 9일 (화)와 같이 사용자가 보기 편한
      한국어 형식으로 변환합니다. 화면 상단 날짜 표시에 사용됩니다.
   3. getMonday(date): 특정 날짜가 속한 주의 월요일 날짜를 계산해줍니다. 주간
      뷰(7일 단위)를 정확하게 그리거나 주를 이동할 때 핵심적인 역할을 합니다.

--------컴포넌트 구성요소-----

UI 컴포넌트 (src/components/)
   * Header.jsx: 앱의 제목과 둥둥이 캐릭터 이미지를 표시합니다.
   * DateNavigator.jsx: 상단 주간 7일 트랙과 일간 이동 버튼을 포함한 날짜
     탐색기입니다.
   * CategoryFilter.jsx: 카테고리별로 모아볼 수 있는 칩(Chip) 형태의 필터
     UI입니다.
   * TodoInput.jsx: 새로운 할 일을 입력하고, 카테고리를 추가/삭제하는 입력
     영역입니다.
   * TodoList.jsx: 상태 필터(전체/진행 중/완료)와 할 일 목록, 그리고 할 일이
     없을 때의 빈 화면을 렌더링합니다.
   * TodoItem.jsx: 개별 할 일 항목입니다. 체크박스, 텍스트 수정, 삭제 기능을
     담당합니다.
   * CalendarModal.jsx: 월별 달력을 보여주는 팝업 모달입니다.

운영체제 기말내용 정리 (크게크게)

wlsgk7779 — Sun, 7 Jun 2026 22:36:42 +0900

1. 파일시스템

● 파일시스템이란 ' 운영체제가 저장장치에 데이터를 저장하고 관리하는 방식 '

● 보조기억장치인 디스크를 논리적으로 나눠서 각 파티션마다 파일시스템을 만들 수 있다. (예시 C드라이브 D드라이브)

● 파일시스템의 구성 : boot block, super block, FCB list, data blocks

1. boot block은 패스

2. super block은 파일시스템에 대한 메타 정보 저장

3. FCB list (inode list) 는 FCB들을 배열로 저장한 것.

4. Data Blocks는 실제 파일 내용이 저장되는 공간임

Data blocks에서 파일을 할당하는 3가지 방법

1. Contiguous allocation : 연속 할당 방식

2. Chained allocation (Linked allocation) : 블록에 다음 블록을 가리키는 포인터를 둬서 연결하는 방식

3. indexed allocation : 한 파일에 대한 블록들의 위치를 저장하는 인덱스 블록을 사용하여 저장

Free Space 관리하는 4가지 방법

1. Counting : 빈 블록의 번호와 연속된 길이는 저장. Contiguous allocation 방식과 비슷함

2. Linked list (free list) : 빈 블록마다 다음 빈 블록을 가리키는 포인터를 둬서 연결하는 방식. Chained allocation과 비슷함.

3. Grouping : 인덱스 블록을 사용해서 빈 블록의 위치를 저장하는 방식. indexed allocation과 비슷.

4. bit vector (bit map) : 각 블록에 대한 할당/비할당 여부를 1비트로 표시하는 배열을 사용하는 방식. 단점은 크기가 너무 커짐.

2. 파일시스템 예시

UNIX의 파일 관리

파일의 종류 : 일반파일, 디렉토리, 스페셜파일로 구성

파일시스템의 구성 :

1. 부트블록

2. 슈퍼블록

3. inode list (inode table)

4. data blocks

UNIX에서 Data Blocks을 할당하는 방식 :

indexed allocation 방식을 약간 변형하여 사용한다.

이유 : 일반적인 indexed 방식은 인덱스 블록 -> 실제 블록 이렇게 두번 이상 접근해야함.

변형 : 각 파일의 FCB에 첫 10개의 블록을 따로 저장한 후, 이후 것들에 대해서는 인덱스 블록에 저장하고, FCB에 인덱스 블록을 저장한다.

인덱스 블록을 중첩적으로 둬서 큰 파일도 저장할 수 있지만, 그정도로 커질빠에는 나눠서 저장하는 게 좋다.
> 이유는 한 파일이 너무 크면 속도가 느리기에, 나눠서 저장하는게 읽거나 쓰는 것이 빠르기 때문이다.

리눅스의 Virtual File System

파일시스템은 여러개를 사용할 수가 있다.

이때 사용자 프로그램에서 여러 파일시스템에 대한 조작법을 다 알고 있어야 할까?
> 아니다! VFS를 통해서 일관적인 인터페이스를 제공한다. 사용자 프로그램은 어떤 파일시스템이든 동일한 systemcall을 사용할 수 있게 해주는게 VFS이다.

리눅스의 Inode (FCB)

리눅스의 FCB는 Inode라고 부르며, UNIX와 다른 점은 다이렉트로 접근할 수 있는 블록 개수가 10개에서 12개까지 늘어났다는 점

최대 저장 크기도 뭐 8KB (2블록크기) 정도 늘어났을거야.

3. I/O관리와 디스크 스케쥴링

▶ 먼저 I/O 디바이스라는건 입출력 장치이다.

이 I/O 장치는 기계파트와 전자파트(컨트롤러)로 이루어져 있다.

컨트롤러는 제어 레지스터(명령함), 상태 저장 레지스터, 내부 버퍼 등으로 구성된다.

컨트롤러는 폴링이나 인터럽트에 의해 제어된다.

I/O시스템의 구성요소는
1. 커널에 있는 I/O management = kernel I/O subsystem

2. Device deriver interface

3. Device drivers

디바이스 드라이버 인터페이스는?

OS가 연결가능한 모든 I/O 장치에 대해서 알 필요가 없도록하는 표준 인터페이스!

디바이스 드라이버 인터페이스에게 요청하면 이 녀석이 해당 디바이스 드라이버와 연결

그래서 실제 디바이스에게 명령함

디바이스 드라이버는?

I/O 장치를 제어하는 기능들의 모음이다!

모듈 형식이라 필요할 때만 커널에 올라간다.

Kernel I/O management의 6가지 기능

1. 장치예약 - Device reservation : 장치를 한 가지 프로세스만 사용할 수 있도록

2. 디바이스 스케쥴링 - Device scheduling : 한 장치에 대해 여러 프로세스가 요청할 때 큐를 통해 순서관리

3. 오류처리 - Error Handling : I/O 처리 과정에서 오류 발생하면 적절히 조치를 취함

4. 버퍼링 : 장치간 데이터를 전송하는 동안 메모리에 저장

5. 캐싱 : 자주 쓰는 데이터를 캐시에 복사본으로 저장 (원본 x)

6. 스풀링 - Spooling : 출력을 디스크에 대기열로 저장

중

3-1. Interrupt Handling

▶커널로 들어가는 3가지 방법

1. Interrupt : 하드웨어 신호

2. Trap : CPU가 거는 인터럽트 (소프트웨어 신호)

3. System call

1. 인터럽트

인터럽트란 장치가 OS에게 비동기적인 이벤트를 알리는 방법

중첩되어 발생하거나 처리가 가능하다.

예를들어 타입 인터럽트, 키보드 입력, 마우스 입력 등이 있다.

타입 인터럽트가 자주 발생하는 이유 > 더 자주 커널을 실행하기 위해서이다!

기본적으로 CPU는 명령어를 1개 수행한 후에 인터럽트가 걸렸는지 확인한다.

▶인터럽트를 처리하는 방법

1. 유저모드라면 모드체인지하여 커널모드로 진입

2. 커널스택에 현재 문맥을 저장한다. (레지스터 값 등)

3. 인터럽트 핸들러가 누가 인터럽트를 걸었는지 확인

4. IDT(interrupt descriptor table)에서 해당 인터럽트의 ISR을 실행

5. 이때 최소한의 일(급한일)만 해준다.

6. 처리 중 인터럽트가 또 발생하면 위 과정을 반복

7. 모든 ISR처리가 끝나면 특별코드블록을 실행하여, 남은 부분을 처리하고 ready로 상태를 변경하는 등의 일을 한다.

8. 스케쥴러를 실행한다. (이때 문맥전환이 일어날 수도, 아니면 기존 프로세스가 계속 실행될수도)

2. 트랩

Trap은 CPU가 발생시키는 동기적인 이벤트로 이벤트 발생 시점을 예측할 수 있다.

프로그램 실행 중 특정 명령어에서 Trap이 발생한다.

트랩의 예시 :

* 0으로 나누기

* 잘못된 명령어

* 세그먼테이션 폴트 (허용안된 메모리 접근시도)

* protection fault (읽기 전용인데 쓰려고할때)

> page fault 실행해야할 부분이 메모리에 안 올라와 있을 때.

page fault를 제외하면 모두 강제 종료 시킨다.

트랩의 처리 방식은 인터럽트와 비슷하게 IDT에서 ISR을 실행하여 처리한다.

3. 시스템콜

시스템콜은 프로세스가 커널 기능을 요청하는 것

내부적으로는 인터럽트를 발생시켜 IDT에서 system_call() 이라는 부분으로 들어가고,
그 안에 sys call table에서 요청한 기능을 수행한다.

3-2. OS가 I/O 제어하는 3가지 방법

1. Polling

2. Interrupt Driven I/O

3. Direct Memory Access (DMA)

1. Polling (=Programmed I/O)

프로그램을 실행함으로써 I/O 상태를 확인하는 방식.

디바이스 드라이버가 디바이스에게 일을 시키는데,
디바이스의 컨트롤러 부분에 4가지 주요 레지스터가 있음

1. Status register : 디바이스의 상태 저장 (Commend-ready, Busy, Error)

2. Control register : 디바이스 드라이버가 어떤 명령을 할 지 저장
3. Data-in register : 장치를 통해 입력할 내용

4. Data-out register : 장치를 통해 출력할 내용

결국 디바이스 드라이버가 일을 시키고 계속 컨트롤러의 상태 레지스터를 확인하면서
상태 레지스터의 Busy가 1에서 0이 될 때를 기다린다! -> busy waitng 함

I/O가 일찍 끝나는 경우, 문맥전환이 없는 방식이기 때문에 효과적이다.

하지만 오래 걸리는 I/O의 경우에는 그동안 CPU가 계속 상태 확인만 하기 때문에 다른일을 할 수 없다.

2. Interrupt Driven I/O

인터럽트를 통해 해당 I/O가 끝났는지 확인하는 방식

1. 유저 프로세스에서 systemcall로 요청하면

polling방식과 똑같이 디바이스 드라이버가 장치에게 명령을 함!

2. 그 다음에 프로세스 관리로 넘어가서 해당 프로세스를 block상태로 바꾸고,

문맥전환을 통해 다른 프로세스를 실행한다.

3. 만약 해당 I/O가 끝나면 CPU에게 인터럽트를 건다!
4. CPU는 커널로 들어가 해당 인터럽트를 ISR로 처리하고, 상태를 ready로 바꿔준다.

5. 이후 스케쥴러를 실행하여 우선순위에 따라 실행될 프로세스가 결정된다!

3. Direct Memory Access (DMA)

DMA는 위와 좀 다른 성격이다.

DMA를 안 쓰면 장치의 결과를 CPU가 직접 레지스터를 통해 메모리로 옮겨야 한다.

그러면 CPU가 거기에 시간을 많이 잡아먹기 때문에 다른 일을 할 수가 없다..

> 그래서 이를 대신 해줄 DMA 컨트롤러 라는게 나왔고, CPU는 DMA 컨트롤러에게 대신 메모리에 저장하라고 명령한다.

이를 통해 CPU는 이 일을 하지 않고 DMA가 입출력 장치 <-> 메모리(RAM) 사이에 데이터를 전달해준다.
그리고 일을 다 하면 다 했다고 CPU에게 인터럽트를 건다!

3-3. 디스크 스케쥴링

OS의 논리적인 디스크의 최소 단위는 블록이고,

실제 디스크의 물리적인 최소 단위는 섹터이다.

< 디스크 구조 알아보기 >

> 섹터 : 디스크의 물리적 최소 단위

> 트랙 : 디스크의 한 줄 (원), 트랙에는 여러 섹터가 있다. 그리고 하나의 디스크 표면에는 여러 트랙이 있다.

> 헤드 : 디스크 면을 읽어서 섹터의 데이터를 읽는다.

> 디스크 암 : 디스크를 읽는 팔 역할로, 끝에는 헤드가 있다.

디스크 드라이버는 논리 블록의 1차원 배열로 주소를 지정한다.

실제로는 여러 디스크면, 트랙, 섹터들 등 여러 차원으로 구성되지만, 이를 간단하게

하나의 배열로 블록 주소를 지정한다.

섹터 크기 = 블록 크기라고 할때

1. 바깥쪽트랙부터 다 읽고

2. 아랫면도 같은 트랙 읽고

3. 그 아래 디스크의 같은 트랙 읽고 . . 모두 읽으면

4. 첫 디스크의 하나 안쪽 트랙으로 넘어가서 읽는다! 반복

위 과정을 배열로 담아서 쓰는거임!!

< 디스크 I/O의 시간 >

디스크를 읽거나 쓸 때 걸리는 시간에 대해 알아보자.

1. Seek Time : 탐색시간, 헤드가 트랙에 찾아가는 시간 (가장길다)

2. Rotational Delay : 회전지연, 헤드에 읽어야할 섹터부분이 회전하며 오는데 걸리는 시간

3. Data Tranfer Time : 실제 데이터 전송이 발생하고, 데이터를 읽거나 쓰는 시간

이 중 Seek Time이 성능 차이의 주 원인이 됨!!

단일 디스크에 대해서 여러 I/O 요청이 발생하는데, 이때 무작위로 선택하면 성능저하가 발생하니

디스크 스케쥴링이 필요한 것이다...!!

< 디스크 스케쥴링 방식 3가지 >

1. FIFO : 요청이 들어온대로 접근하기 > 랜덤에 가까워서 오래걸림

2. SSTF (Shortest Seek Time First) : 현재 헤드가 있는 부분에서 가장 가까운 트랙을 우선으로 접근하여 처리

-> 대신 우선순위를 기반으로 하기 때문에 기아상태 문제 발생 가능

3. SCAN(엘리베이터, LOOK) : 한쪽 방향으로 쭉 이동하면서 처리하기 > 기아상태 없어!

-> 이동 방향에 더이상 읽을 섹터가 없으면 방향을 바꾼다!

< 디스크 캐시 > = page cache, buffer cache

프로그램이 같은 블록을 요청할 수 있으니, 최근 불러온 블록을 캐시에 저장하여 사용한다.

< 캐시가 가득 찰 때 대체하는 방식 >

1. LRU - Least Recently Used : 가장 오래된 블록을 버리자.

2. LFU - 가장 적게 사용된 블록을 버리자.

[카테캠] 프리코스 2주 1일차 - SQL 조회와 조작

wlsgk7779 — Sat, 30 May 2026 06:23:12 +0900

1. SQL 시작하기

1-1. SQL이란?

▶ 데이터베이스란?

여러 사람이 공유해서 사용할 목적으로 통합하여 관리되는 데이터의 모음!

데이터베이스의 종류에 따라 사용방법이 조금씩 다르지만 검색과 분석에 사용되는

기본적인 방법은 데이터베이스 종류와 상관없이 동일하다!

▶ SQL

Structed Query Language의 약자로

데이터베이스에 접근하고 조작하기 위한 표준 언어

▶ SQL이 할 수 있는 것

1. 데이터 검색

2. 데이터 삽입

3. 데이터 수정

4. 데이터 삭제

5. 데이터베이스 생성

6. 테이블 생성

7. 등

1-2. 테이블에서 데이터 검색하기

▶ 관계형 데이터 베이스

하나 이상의 테이블로 이루어지며

서로 연결된 데이터를 가지고 있음!

SQL을 통해 제어 가능 !

▶ 테이블의 구성요소

컬럼 : 주제, 제목 같은 것

레코드 : 내용, 값 같은 것

▶ 테이블에서 데이터를 가져오기

SELECT : 검색 명령어
FROM : ~로 부터
WHERE : 조건

SELECT 검색대상1, 검색대상2.. FROM 테이블명;

테이블에서 검색 컬럼에 대한 모든 정보 검색하기 !* 을 통해 모든 컬럼에 대해 정보를 가져올 수 있다 !

▷DISTINCT : 컬럼내용 중복제거 !

검색할 컬럼에 대한 내용에 중복이 있을 경우 한가지만 보여준다.DISTINCT 뒤에 2개 이상의 컬럼을 적으면,

한 쪽 컬럼에 중복이 있어도 다른 쪽 컬럼의 값이 다르면 다르게 취급 !

SELECT DISTINCT 제목, 저자 FROM book;

"어린왕자", "김진하"
"어린왕자", "황은영"

위 상황처럼 한 쪽 컬럼에 중복이 있어도,
다른 쪽 컬럼의 값이 다르면 다르게 취급 !

1-3. 조건을 추가하여 검색하기

▶ WHERE : 조건을 만드는 방법

검색하고자 하는 데이터의 조건을 설정할 수 있는 명령이다.

SELECT * FROM book WHERE title = '돈키호테';

book 테이블에서 title 속성이 '돈키호테'인 모든 컬럼 검색

1-4. 여러 개의 조건 추가하기

국어성적이 90점 이상이거나 수학 성적이 80점 초과인 데이터를 검색하는 등,

여러 개의 조건을 검사하여 검색하는 것을 알아보자.

▶비교연산자

> , <

>= , <=

SELECT * FROM score WHERE korean >= 90;

▶복합조건 연산자

AND, &&

OR, ||

NOT, !

SELECT * FROM score WHERE korean >= 90 OR math > 80;

▶기타 연산자

BETWEEN

SELECT * FROM score WHERE math BETWEEN 80 AND 90;
math에서 80과 90사이에 값 (80과 90도 포함)

A IN B
A에서 B에 해당하는 것

NOT IN

A NOT IN B
A에서 B에 없는 것

2. 데이터를 제어하는 DML

2-1. 테이블에서 유사한 값 찾기

▶LIKE : 특정 문자가 포함된 문자열을 찾고 싶을 때 사용하는 명령

WHERE 뒤에서 사용할 수 있다!

▷와일드카드 %

문자열에서 특정 문자열을 포함하는 것을 찾고 싶을 때 LIKE와 함께 사용한다 !

SELECT * FROM book WHERE title LIKE '어린왕자'; - title에서 '어린왕자'를 찾기
SELECT * FROM book WHERE title LIKE '왕자%'; - title에서 '왕자'로 시작하는 것 찾기
SELECT * FROM book WHERE title LIKE '%왕자'; - title에서 '왕자'로 끝나는 것 찾기
SELECT * FROM book WHERE title LIKE '%왕자%'; - title에서 '왕자'가 들어가는 것 찾기

2-2. 데이터 정렬하기

▶ORDER BY : 데이터를 검색할 때 정렬하여 결과를 추출하는 명령어

WHERE을 쓰는 자리에 ORDER BY를 쓴다!

SELECT * FROM score ORDER BY math DESC; - 수학 과목을 기준으로 내림차순 정렬
SELECT * FROM score ORDER BY math ASC; - 수학 과목을 기준으로 오름차순 정렬

2-3. 테이블에 데이터 삽입하기

▶INSERT INTO : 테이블에 새 데이터 삽입하기

INSERT INTO book(id, title, author, publicher)
VALUES('3', '햄릿', '윌리엄 셰익스피어', '엘리스 출판');

INSERT INTO book  --( )를 안 적을 경우 정의한 순서대로 데이터 넣으면 됨 !
VALUES('3', '햄릿', '윌리엄 셰익스피어', '엘리스 출판');

[카테캠] 프리코스 1주 5일차 - DB와 SQL 기초

wlsgk7779 — Fri, 29 May 2026 00:52:13 +0900

1. 데이터베이스 소개

데이터 : 현실 세계에서 수집된 단순한 사실과 값정보 : 데이터를 특정 목적에 의해 해석하거나 가공한 형태

▶데이터베이스의 정의데이터들의 집합.한 조직 안에서 여러 사용자와 응용 프로그램이 공동으로 사용하는 데이터들을통합하여 저장하고 운영하는 데이터

▶데이터베이스의 필요성

파일처리 시스템 : 각 프로그램이 자기만의 파일을 직접 만들어서 데이터를 저장하고 관리하는 방식

▷ 파일처리 시스템의 한계

- 데이터 종속의 문제 : 데이터의 구조가 바뀌면 그걸 사용하는 응용 프로그램의 구조도 바뀌어야 함

- 데이터 중복의 문제 : 응용 프로그램 별로 데이터를 생성할 수도 있는데 이때 데이터가 중복될 수 있음

- 데이터 무결성 문제 : 중복으로 저장되어 있으니, 김민준 이라는 학생의 정보가 바뀌면 모두 바꿔줘야함

▶데이터베이스의 특징

- 실시간 접근성 : 사용자가 원할 때 언제든지 접근가능해야함

- 지속적인 변화 : 데이터 삽입, 삭제, 갱신을 통해 최신 데이터를 유지해야함

- 동시 공유 : 여러 사용자가 동시에 이용할 수 있어야 함

- 내용에 대한 참조 : 데이터가 저장된 물리적 위치가 아닌 값을 가지고 검색할 수 있어야 함

2. 데이터베이스의 종류

▶RDB와 NoSQL

RDB와 NoSQL의 핵심적인 차이는 "관계"이다.

▷RDB (Relational DataBase) :

- 관계형 모델을 기반으로 SQL을 이용해 데이터를 관리함

▷NoSQL (Not only SQL) :

- 데이터 간 관계를 정의하지 않고, 그래서 RDB보다는 유연한 모델을 이용

▶관계형 데이터베이스 (RDB)

- 데이터를 행과 열을 가지는 테이블로 표현한다.

- 테이블 간의 관계를 이용해서 데이터를 효과적으로 관리해 무결성을 보장

- 정의된 테이블(스키마)에 맞게 데이터가 삽입되므로 데이터의 안정성을 보장- 데이터의 구조가 일관적인 경우에 주로 사용한다.

▷RDBMS(Relational Database Management System)의 종류

RDBMS란 관계형 데이터베이스 관리 시스템으로 MySQL, PostgreSQL, MariaDB 등이 있음.

▶NoSQL

- 데이터를 저장할 수 있는 유형의 제한이 없음!

- 새로운 유형의 데이터를 추가하기가 용이

- 데이터의 구조가 일관적이지 않고 자주 변경되는 경우 적합

- 대용량의 데이터(이미지, 동영상 등)를 더 빠르게 처리할 수 있음

▷NoSQL의 종류

MongoDB, Redis, Apache Cassandra 등이 있음.

3. 관계형 데이터베이스 만들기

▶ 구성요소

▶ 관계

배달 앱 같은 곳에서 주문번호는 계속해서 생겨나는데 고객의 이름이나 ID는 거의 바뀌지 않음.

이때 ID 이름 주소와 함께 주문번호도 같이 저장한다면 ID, 이름, 주소는 주문번호가 생길 때마다 중복해서 생겨남.

그래서 이를 ID라는 하나의 속성으로 테이블을 연결해서 효과적으로 관리할 수 있다!!

▶ SQL을 통한 테이블 관리 알아보기 !

▷ SQL 작성 규칙

▷ 테이블 정의하기

CREATE TABLE 테이블명 ( 속성 1 데이터타입 1, 속성 2 데이터타입 2, ...);

CREATE TABLE customer(
    id      VARCHAR(10),
    name    VARCHAR(10),
    address VARCHAR(30)
);

▷ 정의한 테이블 확인하기

SHOW TABLES; - 생성된 모든 TABLE을 확인하기

DESC 테이블명; - 특정 테이블에 대한 정보를 확인하기

-- 현재 데이터베이스에 있는 모든 테이블 목록 보기
SHOW TABLES;

-- customer 테이블의 구조 보기 (컬럼명, 타입, 제약조건 등)
DESC customer;

▷ 데이터 삽입하기

INSERT INTO 테이블명 ( 속성1, 속성2, ...) VALUES( 속성값1, 속성값2, ...);

INSERT INTO customer (id, name, address)
VALUES('kmax6', '김민준', '서울시 관악구 신림동');

-- 속성의 순서는 중요하지 않음
INSERT INTO customer (name, address, id)
VALUES('이서연', '서울시 동작구 대방동', 'flykite');

-- 모든 속성을 순서대로 입력하는 경우 속성 목록은 생략 가능
INSERT INTO customer
VALUES('freeman123', '박서준', '서울시 관악구 신림동');

* 속성을 정의한 순서와 관계없이 새로운 순서를 인자로 받아 VALUES 순서와 매치해주면 된다!
* 모든 속성에 대해 추가를 할 것이면 ( )를 적지 않고 테이블명만 적은 후 VALUES에 정의한 순서대로 값을 넣어주면 된다!

▷ 데이터 출력하기

SELECT 속성 1, 속성 2, ... FROM 테이블명;

SELECT id, name, address FROM customer;

-- 출력하고 싶은 속성 조정 가능
SELECT address, name FROM customer;

-- "*"을 이용해 모든 속성 출력 가능
SELECT * FROM customer;

▶ 데이터베이스 정의어, 조작어, 제어어

관계형 데이터베이스를 활용하기 위해 사용하는 표준 언어로 아래와 같은 것들이 있다.

데이터 정의어(DDL, Data Definition Language) : 테이블과 같은 데이터 구조 정의

데이터 조작어(DML, Data Manipulaion Language) : 데이터 조회 및 탐색

데이터 제어어(DCL, Data Control Language) : 데이터베이스에 접근하는 권한 관리

▷ 데이터 정의어에 대해 알아보기

0. 먼저 데이터 타입에 대해 알아보자.

이 외에도 TINYINT, BIGINT, TIME, DATE 등이 있음!

자료형은 DBMS마다 차이가 있을 수 있다.

1. 테이블 정의하기

CREATE TABLE customer(
    id      VARCHAR(10),
    name    VARCHAR(10),
    address VARCHAR(30)
);

2. 테이블 수정하기

-- 컬럼 추가
ALTER TABLE customer ADD COLUMN birthday DATE NULL;
-- 컬럼 수정
ALTER TABLE customer MODIFY COLUMN id varchar(15) NULL;
-- 컬럼 이름 변경
ALTER TABLE customer CHANGE COLUMN name korean_name varchar(10) NOT NULL;
-- 컬럼 삭제
ALTER TABLE customer DROP COLUMN address;
-- 테이블 이름 변경
ALTER TABLE customer RENAME member;

* 주의해야 할 점은

MODIFY, CAHNGE 는

한 속성에 대해 새로 정의하는 느낌이라 속성의 한가지만 바꿔도 다른 것들도 다시 정의를 해줘야한다!!

(NULL / NOT NULL 명시 안 하면 기본값 NULL 적용됨)

* MODIFY는 이름을 제외한 속성의 내용을 바꿀 때 사용하고,

* CHANGE는 속성의 이름까지 바꿀 수 있다.

3. 테이블 삭제하기

DROP TABLE 테이블명

4. 데이터베이스 구성하기

▶ 제약 조건

제약조건이란 "테이블에 잘못된 데이터가 입력되는 것을 방지하기 위한 규칙"으로 제약조건을 통해 무결성을 지킬 수 있음.

-> 한마디로 속성에 대한 값에 올 수 있는 조건을 걸어 제약을 두는 것 !

▷ NOT NULL

널(NULL) 값을 비허용하는 것

아무 데이터도 입력하지 않으면 에러 발생

NOT NULL을 명시하지 않으면 기본적으로 NULL 허용이다!

id VARCHAR(16) NOT NULL

▷ UNIQUE

한 테이블에서 중복되는 속성 값을 가지는 것을 비허용하는 것

한 속성에 대해 같은 값이 존재하면 에러 발생*NULL 값은 비교가 불가능하므로 중복되어도 됨

id VARCHAR(10) UNIQUE

▷ DEFAULT

아무 값도 들어오지 않았을 때의 기본 값을 지정할 수 있다.

id VARCHAR(16) DEFAULT '기본값'

▷ CHECK

들어올 수 있는 값의 범위를 제한하여 특정 값만 허용하는 것

제한한 값이 아닐 경우에 에러 발생

age INT CHECK(age>19)

---------------------------------------------------------------------

▶ 제약 조건 정의 (CONSTRAINT)

속성을 정의할 때 붙이는 것과 다른 방법으로 CONSTRAINT를 사용할 수 있다.

CONSTRAINT를 사용하면 해당 제약조건의 이름을 정할 수 있다.

사용법 :

CONSTRAINT 제약조건이름 제약조건 (적용할 속성)

--테이블 정의하는 부분 안에 사용 'CONSTRAINT 제약조건이름 제약조건 (적용할 속성)'
CREATE TABLE customer(
    id	VARCHAR(10),
    age INT,
    CONSTRAINT id_unique UNIQUE (id),
    CONSTRAINT age_check CHECK (age>=10)
);

▶ 제약 조건 추가

제약 조건을 추가할 수 있다.

사용법:

ALTER TABLE 테이블명 ADD CONSTRAINT 제약조건이름 제약조건 (적용할 속성);

**DEFAULT 제약조건수정은 조금 다르다.

ALTER TABLE ALTER 속성 SET DEFAULT 기본값;

ALTER TABLE customer
ADD CONSTRAINT address_unique UNIQUE (address);

ALTER TABLE customer
ADD CONSTRAINT customer_chk_2 CHECK (age >= 19 AND name = '김민준');

ALTER TABLE customer
ALTER address SET DEFAULT '주소 없음';

▶ 제약 조건 삭제

사용법 :

ALTER TABLE 테이블명 DROP CONSTRAINT 제약조건이름;

DEFAULT 제약 조건 삭제 :

ALTER TABLE 테이블명 ALTER 속성 DROP DEFAULT;

ALTER TABLE customer DROP CONSTRAINT customer_chk_2;

ALTER TABLE customer
ALTER address DROP DEFAULT;

5. 데이터베이스의 키

▶ 키란?

조건에 만족하는 튜플을 찾거나, 정렬할 때 기준이 되는 속성

- 기본키

- 외래키

- 후보키 : 기본키가 될 수 있는 키로 유일성과 최소성(최소한의 속성)을 만족

- 대체키 : 후보키지만 기본키가 아닌 키

- 슈퍼키 : 튜플을 식별할 수 있는 유일성은 만족하지만 최소성은 만족하지 않는 키

▷기본키

서로 다른 튜플을 유일하게 식별할 수 있는 기준이 되는 속성

- 중복되는 값을 가질 수 없음 (UNIQUE)

- 널 값을 가질 수 없음 (NOT NULL)

- 한 테이블 당 1개만 설정 가능하다 !

위 표의 경우 이름과 주소는 중복될 수 있으므로 ID가 기본키로 가장 적합하다.

▷외래키

다른 테이블의 기본키를 참조하는 속성으로 테이블의 관계를 정의

- 참조되는 테이블의 기본키에 없는 값은 지정할 수 없다! (NULL은 가능)

- 기본 키와 다르게 2개 이상의 값을 가질 수 있다.

왼쪽 표에서 ID가 기본키라고 가정할 때,오른쪽 표에서 ID가 기본키를 참조하는 외래키가 될 수 있다.

▷SQL로 키를 지정하는 법

기본키 설정 : PRIMARY KEY

외래키 설정 : FOREIGN KEY (외래키로 만들 속성) REFERENCES 참조되는 테이블(참조되는 속성)

CREATE TABLE customer(
    id      VARCHAR(10) PRIMARY KEY,
    name    VARCHAR(10),
    address VARCHAR(30)
);

CREATE TABLE order_history(
    customer_id VARCHAR(10),
    order_id    VARCHAR(14),
    FOREIGN KEY (customer_id) REFERENCES customer(id),
    CONSTRAINT order_history_pk PRIMARY KEY (customer_id, order_id)
);

위 코드에서 보이듯이 CONSTRAINT를 통해 기본키를 등록할 수 있는데,

이때 기본키에 대한 속성으로 2개를 넣는 모습을 볼 수 있음 !!!

- > 고객ID와 주문ID가 있는 경우, 같은 고객에 대해서 많은 주문 ID가 생길 수 있다.

- > 이 경우 고객ID만으로는 특정 튜플을 식별할 수 없음 !!!

- > 그래서 주문ID까지 기본키로 설정해야 특정 튜플을 식별 가능하다!!

▷ 무결성 제약 조건 : 데이터가 올바르고 일관되게 유지되도록 강제하는 규칙 !

- 개체 무결성 : 기본키는 널 값과 중복된 값을 가질 수 없음

- 참조 무결성 : 외래키는 널이거나 참조되는 릴레이션의 기본키 값과 동일

(고객ID라는 기본키를 참조하지만, 비회원인 경우 고객ID가 NULL일 수 있으니 허용)

------------------------------------------------------------------------------------------------------------

- 도메인 무결성 : 특정 속성값은 그 속성이 정의된 도메인에 속한 값이어함

- NULL 무결성 : 특성 속성값은 널 값을 가질 수 없음

- 고유 무결성 : 각 튜플이 가지는 속성값들은 서로 달라야 함 (모두 같으면 안됨)

- 키 무결성 : 테이블에 최소 한 개 이상의 키가 존재

6. 데이터 모델링

현실 세계에 존재하는 데이터를 데이터베이스화 하는 과정

▶ 데이터 모델과 구성요소

현실 세계의 데이터를 단순화, 추상화하여 표현한 모델

- 개체(Entity) : 데이터로 표현하고자 하는 현실 세계의 개념이나 정보의 단위 (ex. 킥보드, 회원) - 명사로 생각하기

- 속성(Attribute) : 개체에 대한 정보 (ex. 킥보드의 브랜드/이용가격, 회원의 아이디/이름)

- 관계(Relationship) : 개체 간의 연관성 (ex. 고객은 킥보드를 대여한다) - 동사로 생각하기

▶ 데이터 모델링 과정

개념적 설계 > 논리적 설계 > 물리적 설계

- 개념적 설계 : 현실 세계를 추상적 개념으로 표현하는 과정

사람이 이해하기 쉽게 추상적으로 표현( 고객 --주문한다--> 상품)

- 논리적 설계 : DBMS가 처리할 수 있는 데이터 구조(스키마)를 설계

실제 DB로 저장할 구조로 표현 ( 고객(id, 이름, 주소), 주문(주문번호, 고객id, 상품id) 등)

- 물리적 설계 : DBMS에 테이블을 저장할 구조를 설계

실제 컴퓨터에 어떻게 저장될지 표현 → 파일 구조, 인덱스 등 실제 저장 방식

[카테캠] 프리코스 1주 2일차 - 비동기와 테스트

wlsgk7779 — Thu, 21 May 2026 23:11:31 +0900

1. 비동기 입문 - 개념과 문법

비동기 프로그래밍 : 하나의 작업이 응답을 기다리는 동안, 다른 작업을 먼저 진행하는 것

비동기는 단일 쓰레드에서 이루어지며 I/O 대기를 최소화 하는 방법

비동기는 동시에 여러 연산을 하는 것이 아니라, 대기 상태에 빠진 작업이 다른 작업에게 실행 권한을 양보하는 구조

비동기 프로그래밍을 하려면 asyncio 패키지를 import 해야한다.

asyncio 패키지를 통해 할 수 있는 것들

▷코루틴 : 비동기로 동작하는 함수

태스크 : 루프에 예약되어 실행 대기 중인 작업

루프 : 모든 비동기 작업을 지휘하는 중앙 엔진

▷비동기 함수 :

async def로 정의할 수 있다.

비동기 함수를 호출하면 실행되는 것이 아닌, 비동기적으로 실행될 수 있는 상태인 코루틴을 반환

▷await :

작업이 끝날 때까지 기다리되, 다른 작업이 있으면 먼저 하라는 의미

반드시 async def 로 정의된 비동기 함수 안에서만 사용할 수 있다

기다릴 수 있는 대상 (비동기 처리 가능 대상이나 Awaitable 객체) 앞에 붙일 수 있다

▷asyncio.run(코루틴) :

새로운 이벤트 루프를 생성하여 코루틴을 실행하고 루프를 종료한다.

프로그램에서 딱 한 번만 호출한다.

이미 루프가 실행 중이면 런타임에러 발생

▷create_task :

코루틴을 태스크 객체로 감싸서 이벤트 루프에 즉시 실행을 예약한다

명시적으로 await를 호출하여 기다리지 않아도 루프에 여유가 생기면 백그라운드에서 실행

태스크의 생성은 task = asyncio.create_task(코루틴) 으로 할 수 있다.

await와 달리 해당 코루틴 동작을 멈추지 않고 아래 문장을 쭉 실행하게 된다.

또한 실행한 task에 반환값이 있다면 r = await task로 반환값을 기다려 받을 수 있고,

만약 이미 task 실행이 완료된 상태라면 바로 반환값이 나오게 된다.

▷await asyncio.sleep() :

이 문구는 time.sleep() 과 다르게 해당 쓰레드 동작이 멈추지 않고, 이벤트 루프에게 제어권을 넘겨줘

이벤트 루프가 다른 task를 실행할 수 있도록 한다.

2. 동시처리 극대화

여러 개의 독립적인 비동기 작업을 한 번에 묶어서 실행하는 것

전체 실행 시간은 가장 오래 걸리는 단일 작업의 시간과 동일하다

▶첫 번째 방법 : gather() - 결과를 한 번에 모으는 수집가

▷asyncio.gather()을 사용하면 여러 코루틴을 한 번에 실행한다.

▷모든 작업이 끝나면 그 결과들을 리스트 형태로 모아서 반환

▷단, 이전 작업의 결과가 다음 작업에 필요한 경우(의존성이 있는 경우) 순차 실행을 해야한다.

▷gather()은 인자로 받은 코루틴들을 동시에 실행하고 전부 끝나면 리스트로 결과를 수집하는데,

이때 결과 리스트는 실행한 순서를 보장한다. (호출한 순서대로 결과를 저장)

▷어떤 task에서 오류가 발생하면 나머지는 그냥 실행함

gather() 사용 예시

▶두 번째 방법 : TaskGroup() - 안전한 울타리를 제공하는 관리자

▷관련된 작업들을 하나의 그룹으로 묶어 더 안전하게 생명주기 관리

▷모든 작업이 완료될 때까지 기다리고, 예외 발생 시 모든 작업을 안전하게 취소한다.

▷모든 예외를 ExceptionGroup으로 묶어서 발생시키고 except* 문법으로 타입별 분리 처리

▷async with asyncio.TaskGroup() as tg : 와 같이 async with 구문을 사용해야함!

▷task에 대한 결과 값은 개별적으로 t1.result(), t2.result()로 조회할 수 있다.

TaskGroup() 사용 예시

except* 을 이용한 예외그룹 처리 예시

▶ asyncio.gather()와 asyncio.TaskGroup() 비교

3. 안정적인 비동기 : 예외와 타임아웃

단일 코루틴에서는 비동기도 익숙한 try/except가 동일하게 적용됨!

하지만 여러 작업을 동시에 gather() 등으로 실행한다면 어떻게 될까?

▶gather()에서의 예외

▷먼저 asyncio.gather의 기본 동작은 예외 전파이다.

-> 예외 전파란 하나의 예외가 발생하면 즉시 호출자에게 전파되며, 나머지 Task는 계속 실행

▷예외를 수집하는 옵션도 있는데 이는 "return_exceptions=True" 이다.

이 옵션은 예외를 '반환 가능한 결과값'의 하나로 취급하도록 하여 결과 리스트에 오류를 저장한다

▷위 옵션을 통해 작업별 상태를 확인하고, 선택적으로 재시도하고, 성공한 결과는 먼저 활용할 수 있다.

▷위 사진처럼 다중 코루틴 예외를 처리할 때는 상황에 따라 적절한 것을 선택하여 사용할 수 있다.

▶비동기 time out 설정

▷비동기 방식에서는 하나의 지연이 전체 흐름에 영향을 미친다.

▷이때 Timeout을 설정하여 일정 시간 이후에 다른 대응을 할 수 있도록 제한을 둘 수 있다.

▷asyncio.wait_for()을 이용하여 구현할 수 있다.

asyncio.wait_for() 사용 예시

▷위 사진과 같이 인자로 실행할 코루틴과 timeout 값을 설정하여 사용할 수 있다.

이때 timeout으로 설정한 시간보다 작업 시간이 길면 asyncio.TimeoutError 가 발생하기 때문에

try-except 문으로 감싸서 처리해줘야 한다.

▷Timeout이 없을 때는 전체 시스템 흐름이 꼬이고 사용자 경험이 악화되지만,

Timeout이 있다면 빠른 피드백을 제공하고, 시스템 리소스도 보호할 수 있다.

4. 비동기 심화와 유의사항

▶cancel()

어떤 task에 대해 더 이상 필요가 없어진다면 시스템 자원 확보를 위해 즉시 중단해야한다.

이때 cancel() 을 사용할 수 있음!

task.cancel() 을 하면 해당 task에 대해 취소 요청을 하는 것이다. (즉시 중단은 아님)

그리고 await task를 한다면 해당 task는 취소 되었으므로 asyncio.CanceledError 가 발생하게 됨.

여기서 task는 create_task()를 통해 반환된 Task 객체이다.

task.cancel() 사용 예시

▶asyncio의 주요 에러 정리

▶세마포어

무한한 동시성은 시스템 파괴를 부른다.

그래서 허락된 만큼만 통과시키는 톨게이트 역할이 필요한데 이를 Semaphore라고 한다.

이를 통해 비동기의 장점을 살리되, 외부 서비스에 과도한 부담을 주지 않도록 동시 실행 수를 엄격하게 조절한다.

sem = asyncio.Semaphore(최대 접근 수)로 세마포어 객체를 받은 후에

async with sem: 구문 안에 내용을 쓰면 해당 구문 안을 실행하는 최대 task 수는 세마포어 수로 제한이 되고, 이를 초과하면 대기를 한다.

API호출이나 DB연결 등 실무에 필수적이다.

세마포어 사용 예시

▶async with 구문

열어둔 문은 자원의 누수로 이어진다.

비동기 코드를 다루는 네트워크 클라이언트나 데이터베이스 연결 객체는 단순한 변수가 아닌 물리적 자원이다.

비동기로 열었다면, 반드시 비동기로 닫아야한다.

async with는 작업 중 에러가 발생하더라도 자원 정리 단계를 반드시 보장하는 비동기 패턴이다.

async with 구문 사용 예시

▶위 3가지 정리

▶동기식 블로킹 함수 대처

동기식 블로킹 함수가 실행되면 이벤트 루프 전체가 멈춰버리는 (Freezing) 치명적 병목이 발생한다.

해결책으로는 run_in_executor를 사용하여 블로킹 함수를 메인 루프가 아닌 별도의 스레드 풀로 격리하여 실행한다.

사용법으로는 먼저 loop = asyncio.get_event_loop()로 현재 사용 중인 루프를 가져오고,

await loop.run_in_executor(executor, 동기함수, 인자)로 별도 스레드 풀에서 동기함수를 실행할 수 있다.

인자 1 executor는 보통 None으로 둬서 기본 스레드풀을 사용하게 한다. (지정해줄 수 있음)

인자 2 동기함수는 ( ) 없이 써줘야 한다!

run_in_executor() 사용 예시

핵심 포인트는 동기함수를 별도 스레드에서 실행해서 루프 블로킹을 방지하고,

비동기 전환이 안 되는 옛 코드를 대처할 수 있다 등

* 비동기는 무조건 빠른 것이 아니다!

* 단일 요청의 처리 속도를 높이는 것이 아니라, 동시에 처리할 수 있는 요청의 수(처리량)를 극대화하는 기술이다.

* 부하 상황에서는 지연 시간의 변동성이 커질 수 있음을 설계 시 인지해야한다.

5. 테스트의 개념과 pytest 시작하기

프로젝트가 커질수록 기능 추가나 구조 변경 시 기존 기능이 깨지는 일이 빈번하게 발생

테스트 없는 코드 수정은 예기치 않은 오류를 반드시 동반

▶테스트란?

어떤 입력을 넣었을 때, 기대한 결과가 정확히 나오는지 코드로 검증하는 과정

단위 테스트(Unit Test) : 개별 코드 단위 (메서드, 클래스) 검증, 격리된 환경에서 빠르게 실행, 회귀 테스트 기반(?)

통합 테스트(Integration Test) : 모듈 간 상호작용 검증, 데이터 흐름 및 인터페이스 확인, 종속성 및 외부 시스템 통합 확인

시스템 테스트(System Test) : 전체 시스템 기능 검증, 실제 운영 환경과 유사한 조건, 성능-부하-스트레스 테스트 포함

인수 테스트(Acceptance Test) : 최종 사용자 관점의 검증, 비즈니스 요구사항 충족 확인, 알파-베타 테스트 및 인수 기준 검증

▶테스트 코드를 작성하는 이유

▷문제점 조기 발견

▷리팩토링 용이성

▷개발 효율성 극대화 : 어느정도 개발 단계 이후에는 사용하는게 디버깅 시간을 압도적으로 단축

▶테스트의 3단계 핵심 구조 (AAA)

준비 (Arrange) : 테스트를 위한 초기 상태 설정 (a=2, b=3 등)

실행(Act) : 검증할 대상 기능 호출 (add(a,b) 등)

검증(Assert) : 예상된 결과와 실제 결과 비교("결과는 예상대로 5이다" 등)

▶unittest vs pytest

pytest 방식에서는 assert 문 하나로 모든 비교 연산 (==, !=, <, in) 가능 !!

또한 간결함, 호환성, 확장성 등의 이유로 pytest를 사용

▷pytest의 명칭 규약

pytest가 테스트를 자동으로 수집하기 위한 필수 조건!

test_*.py 또는 *_test.py 로 모듈 이름을 짓기
테스트 함수 명은 반드시 test_ 로 시작하기
클래스로 묶을 경우 이름을 'Test'로 시작하고 상속은 불필요

6. 예외처리와 경계값 테스트

테스트의 진짜 목적은 '성공'을 확인하는 것이 아니다.

테스트는 코드가 올바르게 실패하는지 검증하고,

미래의 코드 수정을 위한 안전망이며,

더 나은 소프트웨어 구조를 강제하는 설계 도구이다.

정상적인 케이스만 확인하는 것은 절반의 테스트이며, 잘못된 입력에서 올바르게 실패하는가?도 확인해봐야한다.

의도된 에러를 낚아채는 예외 처리를 확인하기 위해서는 with pytest.raises()를 사용할 수 있다.

▷with pytest.raises()

특정 코드를 실행했을 때 의도한 예외가 발생하는지 명시적으로 검사하는 것이다.

with pytest.raises(예외이름, 예외객체, match == " ") : 구문을 이용할 수 있는데 이 안에 예외를 유발하는 실제 함수를 호출하면 된다.

단순히 에러의 종류만 포착하는 것이 아니라, match 인자를 통해 발생한 에러 메시지가 특정 문자열을 포함하는지도 알 수 있다.

with pytest.raises() 사용 예시

7. 테스트 자동화하기

테스트를 하나하나 매개변수만 바꿔가면서 테스트 하는 것은 시간도 많이 걸리고 비효율적일 수 있다.

이를 해결할 수 있는 두 가지 핵심 기능이 있는데 바로 Fixture와 Parametrize이다.

▶Fixture (사전 준비)

Fixture는 테스트 전 필요한 준비 작업 (DB연결, 객체 생성 등)을 한 번만 정의할 수 있도록 하는 것이다.

conftest.py파일에 작성하면 모든 파일에서 import 없이 즉시 자동 공유가 가능하다.

Fixture 문법은 @pytest.fixture 인데 ( ) 안에 데코레이터 옵션도 넣을 수 있다.

위 사진처럼 일반 함수 위에 @pytest.fixture를 붙여준 다음, 테스트 함수 인자로 Fixture 함수 이름을 넣어주면 된다.

그러면 테스트 함수 안에서 인자로 받은 fixture함수의 return 값이 자동으로 주입된다.

▷conftest.py

conftest.py는 Fixture 공유 파일이다.

한마디로 conftest.py 안에 있는 fixture들은 같은 폴더나 하위 폴더 파일들에서 별도로 import하지 않고 사용가능하다.

여러 테스트 파일이 같은 fixture을 사용해야 할 때 쓸 수 있다.

이때 파일 이름은 반드시 conftest.py 로 해야한다.

▶parametrize

하나의 테스트 함수에 여러 입력값을 주입하여 반복 테스트를 간결하게 수행할 수 있게 해주는 마커이다.

일단 Marker라는 것은 pytest에서 테스트 함수에 메타데이터를 붙이거나 동작을 제어하는 데코레이터이다.

@pytest.mark.마커이름 으로 사용할 수 있는데 이 중 parametrize는 여러 입력값과 결과 값을 전달하여 중복코드를 제거하고, 케이스를 확장할 수 있다.

위 사진처럼 매개변수에 첫번 째로 "인자이름1, 인자이름2 .. " 처럼 사용할 변수들을 쓰고, 두번째로는 튜플을 감싸는 리스트를 적는데, 각 튜플은 테스트할 값들이다. 하나의 튜플이 하나의 테스트 케이스가 되는 것이고, 튜플 안의 값들이 변수로 들어가는 것처럼 동작한다.

8. 실전테스트

▶Mock

테스트를 할 때 실제 환경에 영향을 주는 위험한 로직은 가짜 객체인 'Mock'으로 대체하여 완벽하게 고립시켜야한다.

1. 대체 : unittest.mock.patch를 사용해 특정 모듈이나 함수를 Mock 객체로 전환

2. 검증 : assert_called_once_with(인자)를 사용해 해당 함수가 기대한 인자와 함께 정확히 호출되었는지 확인

Mocking의 원리는 의존성을 격리하는 것이다.

테스트 대상이 외부 의존성(API, DB)에 요청을 보낼 때 이를 Mock이 가로채서 가짜 응답을 만들어 반환한다.

▷Mock 패밀리 : Mock , MagicMock , patch

Mock : 최소형 가짜로 호출과 반환만 흉내내는 기본 가짜이다. 매직 메서드(__len__, __iter__)은 사용불가하다.

MagicMock : 매직 메서드를 자동 처리해주는 Mock이다.

patch : 가짜를 꽂는 도구로 실제 코드 위치에 MagicMock을 주입하고, 테스트가 끝나면 자동으로 원래 함수를 복구한다.

(*보통 직접 import 하는 것은 patch이고, 그 결과 객체는 자동으로 MagicMock이 된다.)

▷가짜로 바꾸는 법 ! @unittest.mock.patch

실제 테스트에서 특정 모듈이나 함수를 patch를 통해 mock으로 바꾸는 법은

1. 먼저 from unittest.mock import patch 를 통해 patch를 import하고,

2. Mock을 주입할 테스트 함수 위에 @patch("가짜로 바꿀 위치")를 쓰고, 함수에는 def 테스트함수(mock)으로 MagicMock을 변수로 받아와 사용할 수 있다.

▷가짜 응답 제어 : return_value 와 side_effect

mock.return_value = (설정값) 을 통해 정답 응답을 고정값으로 설정한다. 이 경우 인자가 뭐가 오든 같은 값을 반환한다.

mock.side_effect = [ ... ] 을 통해 mock을 호출할 때마다 순차적으로 리스트 안 값을 호출한다.

▷patch의 2가지 사용법

1. 위와 같이 @patch(" ")을 사용하는 방법으로, 이 경우 함수 전체에 패치를 적용하며 mock을 자동으로 주입한다.

2. 테스트 함수 안에 with patch() as mock: 문을 사용하여 해당 구문 안만 패치하고, as로 mock을 받을 수 있다.

-> 공통점으로는 범위 종료 시 자동으로 복구된다. with문 같은 경우 with문 위와 탈출 후에는 mock이 적용되지 않는다.

* 함수 전체를 가짜로 -> @patch()

* 일부 구간만 가짜로 -> with patch() as

* 여러 곳을 패치할 땐 @patch() 를 중첩하여 사용하며, 인자 순서 = 아래에서 위 이다.

▷호출 검증 메서드 비교