yundlab 님의 블로그

[260803 25일차] 프로젝트 #6

yundlab — Mon, 3 Aug 2026 16:16:48 +0900

# 포트폴리오 학습일지

[프로젝트 6일차] 2주차 시작 · 화면 설계
+ 요구사항·ERD 정합성 검토 · Pulse UI 조립

2026.08.03 (월) · 2주차 킥오프(화면 목록·와이어프레임) + 문서 정합성 검토 + 개인 UI 작업(Figma)

오늘 다룬 것들

2주차 첫날. 팀은 화면 목록·와이어프레임·디자인 작업으로 넘어갔고, 협업 규칙(PR 템플릿·Squash and Merge)을 레포에 적용했다. 기획서 기준으로 요구사항 명세서·ERD 정합성을 검토해 모순·누락 항목을 정리했고, 개인적으로는 실시간 피드백 서비스 Pulse의 디자인 토큰부터 화면 조립까지를 Figma로 마무리해 갔다.

2주차 범위

화면 목록와이어프레임디자인

협업 적용

PR 템플릿Squash Merge

문서 검토

요구사항·ERD정합성

FE 역할

3축 재편

내 작업

디자인 토큰컴포넌트화면 조립

미니 프로젝트

코드 학습 도구

오전 공지 — 2주차 킥오프

1금주 범위화면 목록 / 와이어프레임 / 디자인 작업 + 프론트엔드 작업 분배(팀 R&R 참조)

2PR 템플릿팀원이 공유한 템플릿으로 레포에 적용

3머지 정책Squash and Merge로 확정 — GitHub 관련 설정도 함께 적용

4회의록오전 11:30 회의록 작성해 Notion 업로드 (플러그인으로 자동화)

5Notion 초대새로 만든 E조 페이지에 각자 개인 계정을 게스트로 초대(강사님 포함), 산출물은 "6. 산출물 관리" 섹션으로 이동

오늘/내일까지 결정할 항목
· (오늘) 전원 — 산출물(요구사항 명세서·데이터 모델링)의 "회의에서 결정할 것" 섹션에 의견 남기기
· (내일) FE 담당자 — 프론트엔드 각자 파트 분담 아이디어를 Slack/Notion에 공유

그 외 기타: 한국취업센터 1차 정규 상담이 팀원별 시간대로 배정됨 · AI API 지원 관련은 강사님 확인 후 공유 · 최종 발표 초청 희망 기업 조사(기한 미정).

‍ 팀장 멘토링 (13:00~13:30)

1미니 프로젝트2주차 "코드 학습 스터디 도구" 아이디어가 주제에 부합('학습의 큰 범위')한다고 강사님 동의 — Claude 스킬/플러그인으로 구현해도 무방

2교재공유 예정 교재는 아직 검토 단계, 완료되면 공유

3환경 세팅기획서 기반 산출물·규칙을 이번 주 수요일까지 확정하고 GitHub/CLAUDE.md 업데이트

프론트엔드 역할 분담 재편 — 3축 구조

기존 분담안의 약점을 Claude Code 자문으로 다시 짰다.

구분	구조	문제/개선
기존	한 명이 실제 기능이 없는 공통 작업에 배정	공통만 맡은 사람은 눈에 보이는 기능 성과가 없음
신규	공통 작업을 제외하고 기능 기준 3축으로 분할	모두가 실제 기능을 나눠 맡는 구조

요구사항 명세서 · ERD 정합성 검토

기획서를 기준으로 요구사항 명세서·ERD에 이상이 없는지 Claude Code로 대조 검토했다. 세 문서의 관계를 이렇게 이해하면 쉽다.

기획서 · 요구사항 명세서 · ERD = 같은 서비스를 점점 자세히 그린 세 장의 그림
· 기획서: "우리 서비스가 무엇을 하는지"의 큰 그림
· 요구사항 명세서: 그 그림을 "화면에서 어떤 순서·조건으로 동작하는지" 규칙으로 풀어쓴 것
· ERD: 그 규칙을 지키려면 DB에 어떤 표(테이블)·칸(컬럼)이 필요한지 그린 것
뒤로 갈수록 앞 내용을 빠짐없이 담고 있어야 한다. 검토는 세 문서를 나란히 놓고 대조해 서로 다르거나 사라진 부분을 찾는 작업이다.

발견한 문제는 세 종류로 나뉜다. 모순(문서마다 다른 답) → 누락(앞엔 있는데 뒤에서 사라짐) → 미확정(규칙은 있으나 DB에 적용하면 앞뒤가 안 맞음) 순으로 우선순위. 이 중 1번·6번이 구현에 가장 직접적 영향을 준다.

분류	항목	핵심 문제
모순	1. 감정 분석 실패 처리	실패 시 `NEU`(중립) vs `UNKNOWN`(판단 불가)이 절마다 다르고, 감정값이 3종 vs 4종으로 엇갈림. ERD는 옛 방식(NEU) 기준 → 진짜 중립 소감과 섞여 감정 비율·정확도 검증이 왜곡됨
누락	2. 이벤트 수정/삭제 규칙	기획서엔 이벤트 CRUD·삭제 권한이 있는데 요구사항엔 생성·시작/종료까지만. ERD엔 삭제 시 딸린 세션·소감 처리 규칙 없음
누락	3. 공유 링크·QR 생성 시점	기획서엔 필수인데 요구사항엔 설명 없음 — 생성 시점(생성 즉시/LIVE 전환 시)·저장 여부 미정
누락	4. 중복 제출 방지	기획서는 "결정 필요"로 표시했으나 요구사항엔 언급 없음. 반면 실시간 조회 절은 "제출 여부 추적"을 이미 전제로 함
누락	5. 어뷰징 제출 횟수	"IP/브라우저당 분당 `N`회"의 `N`이 빈칸 — 구현 시점에 즉흥 결정될 위험
누락	6. 태깅 버전 기록	`taggerVersion`을 항상 전송·없으면 거절한다면서, 정작 저장할 칸이 요구사항·ERD 어디에도 없음 → 받고 버려서 이력 추적 불가
미확정	7. 리포트 미생성 상태	ERD상 리포트 없으면 행 자체가 없는데, 요구사항은 "미생성"을 상태 기본값으로 설명 → 행 선생성 vs 버튼 시 생성 결정 필요
미확정	8. 세션 삭제 조건 충돌	"소감 없을 때만 세션 삭제" 규칙 + 소감은 소프트 삭제 → 한 번이라도 제출됐다 지워진 세션은 영영 못 지울 수 있음

배운 점 — 같은 서비스를 그린 문서인데도 절이 늘어나고 시점이 달라지면 조용히 어긋난다. 특히 "실패했을 때 어떤 값으로 저장하나", "이 데이터를 어디에 남기나" 같은 예외·저장 규칙이 문서 사이에서 가장 잘 사라진다. 구현 전에 세 문서를 대조하는 것만으로 나중의 재작업을 크게 줄일 수 있다.

내가 한 일 — Pulse: 디자인 토큰에서 화면 조립까지

실시간 이벤트 피드백 서비스 Pulse의 UI 작업. Foundations(색·타이포·간격 토큰) 등록을 끝낸 시점부터 컴포넌트를 만들고 화면을 조립하기까지의 과정과, 그 사이 내린 판단들을 정리했다.

1. 시작점의 착각 — "컴포넌트가 너무 적은데?"

토큰 등록 후 컴포넌트를 만들기 시작했을 때, 이전 프로젝트(Button·Chip·Modal·Toast… 수십 개)와 비교하며 다섯 개뿐이라 불안했다. 결론은 적은 게 아니라 순서가 다른 것이었다. 컴포넌트는 화면을 만들기 전에 다 예측해 채우는 게 아니라, 화면을 조립하다 "어, 이거 또 나오네" 싶을 때 뽑아 올리는 게 정상 흐름이다.

기준 — 지금 만들 화면 하나에 필요한 것만 먼저 만든다. 참가자 제출 화면 기준으로 보니 Chip은 있는데 정작 Textarea가 없었고, 감정 배지는 대시보드용이라 이 화면엔 안 쓰였다. "많고 적음"이 아니라 다음 화면에 필요한가가 판단 기준. 조립하며 Header·Banner·Hint·Toast·Stat·Thermometer·FeedItem·Alert·Logo 등이 그때그때 추가됐다.

2. 만든 컴포넌트

컴포넌트	형태	비고
Button	H 52/48/36, radius 8	primary / secondary / disabled
Chip	H 32, radius 999	default / selected
Badge	H 24, radius 999	positive / neutral / negative / toxic / none
Field/Input	H 48, radius 8	placeholder 속성
Field/Textarea	H 96, radius 8	소감·설명 입력
Header/Mobile · Desktop	H 56 / 64	로고 / 로고+계정 슬롯
Banner · Toast	padding 14/12 · 16/12	상태 배너 / 짧은 알림
Stat · FeedItem	padding 16/14 · 14/12	label+value / normal·flagged
Alert	W 360, padding 24	title+description
Logo/Lockup	Hug	마크 + 워드마크

토큰 고정값 — radius: 버튼·입력·박스 8 / 카드 12 / 칩·배지·온도계 999. 간격: 라벨↔요소 4, 칩·버튼 8, 카드 12, 폼 필드 16, 섹션 24, 큰 블록 32. 컨트롤 높이: 헤더 56·64, 입력 48, 버튼 52·48·36, 칩 32, 배지 24. 그리드: 모바일 393(4컬럼·마진20·거터16), 데스크톱 1440(12컬럼·마진80·거터24).

3. 완성한 화면

대상	화면
참가자 (모바일 393)	소감 제출 `/e/{code}` · 종료된 이벤트 · 실시간 반응 `/live` · 공개 리포트 `/report`
주최자 (데스크톱 1440)	로그인/회원가입 · 이벤트 목록 `/dashboard` · 이벤트 편집(기본/세션 추가·삭제 확인/이벤트 삭제 확인) · 실시간 대시보드(LIVE/QR 모달/복사 토스트/종료 확인) · 대시보드 ENDED(요약 전/생성 중/완료)

4. 하면서 내린 판단들

리포트는 모바일 우선 + SSR — 처음엔 데스크톱으로 그렸지만, 참가자 "종료된 이벤트" 화면에 "결과 리포트 보기" 버튼이 있어 되돌렸다. 리포트는 주최자 전용이 아니라 로그인 없이 열리는 공개 페이지라 모바일 기준. 또한 이 프로젝트에서 SSR이 실제로 값하는 유일한 화면이다(대시보드=CSR, 제출=단순). SEO·OG·빠른 첫 로드가 의미 있는 건 공유되는 리포트뿐.

카드 클릭 → 상태별로 다른 곳으로. 이벤트 목록에 "수정" 버튼을 따로 두지 않고 카드 전체를 클릭 가능하게 해 상태별로 목적지를 나눴다.

상태	이동 화면	이유
DRAFT	이벤트 편집	아직 시작 전이니 설정하러
LIVE	실시간 대시보드	진행 중이니 모니터링하러
ENDED	공개 리포트	끝났으니 결과 보러

클릭 힌트로 카드 오른쪽 끝에 화살표만 붙였다(hover만으로는 알기 어려움). 덕분에 DRAFT 대시보드 화면 자체를 없앨 수 있었다 — DRAFT 카드는 편집 화면으로 가므로 그 화면에 들어올 경로가 없어서.

위험도에 따라 피드백 방식을 나눔.

액션	방식	이유
세션 수정	인라인 입력행	되돌릴 수 있음
링크 복사	토스트	알림만 필요
세션 삭제	Alert	되돌릴 수 없음
이벤트 삭제	Alert(문구 더 무겁게)	소감·리포트까지 사라짐
이벤트 종료	Alert(버튼 빨강 아님)	상태 변경이지 파괴 아님
요약 생성	확인 없음 + 캡션	실패해도 다시 누르면 됨

빨강은 최종 확정 순간에만 — 삭제 버튼 위계를 두 단계로. 편집 화면의 "삭제"는 secondary(흰 배경)+빨간 글자로 왼쪽 끝에, Alert 안의 "삭제"만 primary+빨간 배경. 빨간 채움 버튼은 시선을 가장 먼저 끄는데, 편집 화면의 주요 액션은 "저장/시작"이지 삭제가 아니므로 삭제를 강조하면 위계가 뒤집힌다.

세션 추가는 모달 대신 인라인 — 세션은 필드가 제목 하나뿐이라 모달을 쓰면 Modal 컴포넌트가 더 필요. "+ 세션 추가"를 누르면 그 자리가 입력 필드+"확인" 버튼으로 바뀐다. 버튼 라벨을 "추가"가 아니라 "확인"으로 한 건 수정 때도 같은 UI를 재사용하려고 — 추가는 빈 필드, 수정은 기존 제목이 채워진 필드, 그것만 다르다.

요약 생성은 자동이 아니라 수동 — 종료 시 자동 생성도 가능했지만 주최자가 버튼을 눌러야 생성되게 했다. LLM 무료 티어 레이트리밋 때문에 종료마다 자동 호출되면 발표날 한도에 걸릴 수 있어서. 상태는 LIVE(disabled)/ENDED 요약 전(활성)/생성 중(disabled)/완료(요약 카드) 네 개로. "생성 시 공개 링크가 열려요" 캡션은 실수로 참가자 소감이 공개되는 걸 막으려고 남겼다.

워드클라우드는 Figma와 코드가 다르다 — Figma에선 단어를 Absolute로 흩뜨려 회전을 줘야 자연스럽지만, 실제 데이터는 개수·빈도가 매번 달라 좌표를 미리 못 잡는다. 구현은 두 갈래: ① 태그 클라우드(flex-wrap + 폰트 크기만 빈도 비례, CSS만으로) ② 진짜 패킹(d3-cloud로 겹침 방지·나선 배치). 시안 느낌은 1번으로 충분하고, 2번은 리사이즈·SSR·번들 크기가 붙어 MVP엔 과해서 미뤘다.

5. Figma 삽질 기록

같은 오류를 여러 번 반복했는데 원인은 대부분 두 가지로 수렴했다.

① Fill 옵션이 안 보인다 — Fill은 부모가 오토레이아웃일 때만 나타난다. 컴포넌트 원본은 부모가 없으니 안 뜬다 → 원본은 폭을 숫자로 고정하고, 화면에 인스턴스로 배치할 때 Fill로 바꾼다. 부모가 Hug면 자식만 Fill로 걸어도 안 늘어난다(부모부터 Fill).

② 요소가 엉뚱한 데 있다 — Absolute position이 켜져 있으면 오토레이아웃 흐름에서 빠져 좌표가 제멋대로가 된다(좌표가 마이너스거나 X/Y 직접 입력 가능하면 켜진 상태). 반대로 딤 배경처럼 화면 전체를 덮는 요소는 켜야 한다.

증상	원인 / 해결
요소가 안 보임	Opacity가 0%
라벨까지 가운데로 밀림	카드 전체에 중앙 정렬 → 가운데 정렬할 요소만 Fill 프레임으로 감싸기
텍스트 정렬이 안 먹음	텍스트가 Hug라 여백 없음 → 부모 프레임 정렬 변경
벡터 아이콘이 안 커짐	일반 리사이즈로는 패스가 안 바뀜 → Scale 툴(K)
체크 표시 색이 안 바뀜	✔️는 이모지 → ✓(U+2713) 또는 SVG
도넛 조각이 세로로 쌓임	오토레이아웃 안에선 Align이 안 먹음 → 밖에서 겹치고 그룹으로 묶기
variant 충돌 경고	값 이름 겹침 → `type=primary` 형식으로 각각 다르게
텍스트 속성이 안 만들어짐	컴포넌트화가 먼저, 속성 연결은 그다음

Ellipse Arc 함정 — Sweep은 각도가 아니라 퍼센트다. 58%를 넣으려고 208.8(=360×0.58)을 입력했다 한참 헤맸다. 그냥 58이 맞다. Ratio(도넛 구멍)는 조각 세 개 모두 같은 값이어야 구멍이 안 어긋난다.

6. 토큰을 정해놓고도 안 지키게 되는 순간

작업 중반에 v2 HTML 목업 값을 그대로 옮기다 토큰에 없는 숫자를 심었다(상하 간격 18/20/24 제각각, 버튼 높이 44, 모더레이션 버튼 32). v2 목업은 토큰을 정하기 전 초안이라 값이 서로 안 맞았는데, 그걸 정답처럼 참조한 게 문제였다.

교훈 — 기준은 나중에 등록한 토큰 쪽. 간격은 전부 24, 버튼은 48·36으로 다시 통일했다. 시안이 여러 버전일 때 어느 쪽이 기준인지 먼저 정해두지 않으면 이런 일이 생긴다.

7. 남은 일

1Prototype카드 상태별 이동 경로를 실제 클릭으로 확인 가능하게 연결

2데이터 모델이벤트 날짜 필드 추가 여부 결정(현재 createdAt만 있음)

3컴포넌트 정리Section으로 묶어 이름표 노출

4개발 착수화면 완성 후 Contract-First 원칙에 따라 API 명세부터

✍️ 마치며

2주차 첫날은 "정리하고 넘어가는" 날이었다. 협업 규칙을 레포에 붙였고, 문서 세 장을 대조해 어긋난 부분을 8건 찾아냈다. 특히 "실패했을 때 어떤 값으로 저장하나" 같은 예외 규칙이 문서 사이에서 가장 잘 사라진다는 걸 배웠다. 개인 작업에서는 컴포넌트는 화면을 조립하며 뽑는 것, 빨강은 최종 확정에만, 요약은 레이트리밋 때문에 수동으로 같은 판단들이 남았다. 화면을 다 완성하면 그다음은 Contract-First로 API 명세부터다.

[260731 24일차] 프로젝트 #5

yundlab — Mon, 3 Aug 2026 16:16:04 +0900

# 포트폴리오 학습일지

[프로젝트 5일차] Figma UI · 머지 정책 확정
+ ERD id 타입 결정 · JWT 저장 전략

2026.07.31 (금) · 개인 작업(디자인) + 오전 공지·팀장 멘토링 + 기술 결정(ERD·머지·JWT)

오늘 다룬 것들

1주차 산출물 마무리 구간. 개인적으로는 Figma로 UI 작업을 이어갔고, 팀은 PR 템플릿·머지 정책(Squash)을 확정하고 ERD의 id 타입을 투표로 정했다. 팀장 멘토링에서 주간 미니 프로젝트 주제(2~6주차)와 Notion 워크스페이스 이슈가 공유됐고, 팀원이 학습한 JWT 저장 전략도 정리해 뒀다.

내 작업

Figma UI스크립트

협업 확정

PR 템플릿Squash merge

ERD 결정

id = bigintemail = 로그인 id

멘토링

발표 순서주간 도구 주제

인프라

NeonRender 배포

개념 학습

JWT 저장HttpOnly·CSRF

내가 한 일 — Figma UI

1UI 작업Figma로 화면 UI 제작 (진행중) — 어제 잡은 디자인 시스템·컴포넌트 기반으로 실제 화면 구성

2스크립트시간이 되면 발표/시연 스크립트까지 작성 예정

오전 공지 — 산출물·협업 규칙 확정

1일일 Recap팀원 recap을 취합해 Notion 팀 페이지 하단 별도 섹션에서 관리, 매일 오전 10시까지 공유

2PR 템플릿전날 팀원이 올린 pull_request_template.md를 그대로 레포에 적용

3머지 정책Squash vs Rebase → Squash로 확정 (어제 논의에서 Squash로 의견이 모였음)

구분	내용
1주차 산출물(이번 주)	기획서 · 요구사항 명세서 · ERD · API 명세서 초안 + 문서별 필요한 개념/기술 학습
2주차 예고(다음 주)	화면 목록 · 와이어프레임 · 디자인 작업, FE 작업 분배(팀 R&R 참조)

보안 메모 — 오후에 팀스페이스용 공용 Notion 계정 정보가 공유됐다. 자격증명(이메일·비밀번호)은 학습일지에는 남기지 않는다. 공용 계정은 노출되면 팀 전체가 영향을 받으므로 Slack 등 공유 채널에서만 확인하고, 문서·블로그에는 기록하지 않는 게 원칙.

‍ 팀장 멘토링 — 발표·주간 도구 주제

팀장 멘토링에서 나온 내용 공유. 우리 팀(E팀)은 1주차 미니 프로젝트 발표 2번째 순서로 정해졌다.

주간 미니 프로젝트 주제

각 도구는 우리 팀 프로젝트 안에 실제로 적용한 결과를 내야 하고, Before/After가 정량 수치로 나오면 좋다.

22주차코드 학습 스터디 도구 (예: "이 도구를 쓰면 파이썬을 쉽게 배울 수 있다")

33주차클린 코드를 위한 도구 (컴파일러/인터프리터 제작 X — 유명 클린코드 규칙을 발췌·적용하는 방식도 무방)

44주차코드 리뷰 도구 (예: PR 리뷰 봇)

55·6주차자율 주제

그 외 멘토링 이슈
① Notion 팀스페이스 — 현재 수강생+강사가 모두 '멤버'라, 무료 블록을 다 쓰면 멤버마다 비용이 청구됨. 해결안은 팀장이 새 워크스페이스를 만들고 기존 페이지를 복제(복제 후에도 무료 블록이 충분한지 확인 필요).
② AI API 지원금 — 성남시 최대 지원 금액을 강사님이 담당자에게 확인 예정.
③ 최종 발표 초청 희망 기업 — 원하는 기업이 있으면 자유롭게 공유(제출 기한 확인 예정).

기술 결정 — ERD id 타입 & BE 머지 규칙

엔티티를 짜면서 ERD를 다시 점검했다. 테이블 id를 UUID string으로 할지 bigint number로 할지가 쟁점이었다. (ERD에 string으로 적혀 있던 건 Mermaid 기본값이 id string이라 그렇게 나온 것.)

결정 — id는 bigint · 이유: 순차적으로 자동 생성이 가능해 다루기 편함. 투표 결과(Claude 의견 포함) 과반 동의로 확정, ERD의 string도 bigint로 수정. 부가로 로그인 시 email이 id 역할을 하고, userName 필드는 MVP에선 사소해 우선 넘어감(그라운드 룰에 따라 결정).

BE 브랜치 머지 설정

1PR 필수as-is 팀원 1명 승인 필수 → to-be 승인 수 0 (대신 CodeRabbit 리뷰 확인 + CI 통과로 대체)

2CodeRabbit대화(conversation) 전부 resolve 필요

3보호 규칙force push / 브랜치 삭제 금지 (유지)

4비상 탈출구admin 우회 가능은 유지

인프라 쪽은 Neon(PostgreSQL) 연결 + Render 무료 호스팅으로 스캐폴드 배포까지 진행, 엔티티 클래스는 package-by-feature 구조로 작성 중.

개념 정리 — JWT를 어디에 저장할까 (HttpOnly 쿠키 vs 헤더 vs localStorage)

팀원이 JWT 저장 전략을 파고들어 정리해 줬다. 핵심은 "토큰을 어디에 두느냐"가 곧 보안 성격을 결정한다는 것.

저장 방식	서버가 로그인 확인	주요 위험 / 특성
HttpOnly 쿠키 JWT	자동 (브라우저가 알아서 전송)	JS가 못 읽어 XSS 탈취에 강함 · 대신 CSRF 방어 필요
Authorization 헤더 JWT	가능, 단 JS가 매 요청마다 첨부해야 함	새로고침·SSR·미들웨어에서 번거로움 · JS가 토큰을 읽어 XSS 탈취 위험
localStorage + 헤더	가능	XSS에 특히 취약 → 보통 비권장

핵심 정리 — 일반 브라우저 웹 서비스(React/Next/Vue)라면 권장 기본값은 access JWT를 HttpOnly + Secure + SameSite 쿠키에 담고, 별도 CSRF 토큰을 X-CSRF-Token 헤더로 보내는 구성이다. "헤더에 실으면 로그인 상태를 못 판단한다"는 반만 맞는 말 — 서버는 Authorization: Bearer로도 당연히 확인하지만, 브라우저가 그 헤더를 자동으로 붙여주지 않는다는 것이 차이다. 쿠키는 해당 도메인 요청에 자동 전송되므로 서버가 곧바로 인증할 수 있다.

왜 localStorage는 비권장? — localStorage에 JWT를 넣으면 헤더 인증은 되지만, XSS 취약점이 한 번만 있어도 악성 JS가 토큰을 읽어 외부로 빼낼 수 있다. HttpOnly 쿠키는 JS가 읽을 수 없어 이 "토큰 탈취" 위험을 크게 줄인다. 단, 모바일 앱·외부 공개 API·타 도메인 클라이언트가 주 구조라면 Authorization 헤더 방식이 더 자연스러울 수 있다.

Spring Boot / Spring Security 메모 — 원칙은 동일하다. JWT를 쿠키로 보내면 SessionCreationPolicy.STATELESS여도 브라우저가 쿠키를 자동 전송하므로 CSRF 위험이 사라지지 않는다. 따라서 JWT 인증 필터 + CSRF 보호를 함께 적용한다. 관례: 인증 JWT 쿠키는 HttpOnly=true(JS 접근 차단), CSRF 토큰 쿠키(XSRF-TOKEN)만 HttpOnly=false로 두어 SPA가 읽어 X-XSRF-TOKEN 헤더로 옮기게 한다. __Host- 접두사를 쓰려면 Secure·Path=/·Domain 미설정 조건이 필요.

※ 팀원 B는 이 외에 서버 액션·zod도 학습했고, 상세 자료는 jwt_저장_전략.md로 팀에 공유됨.

주간 미니 프로젝트 발표 — meeting-notes

오늘 팀별로 1주차 미니 프로젝트를 발표했다. 우리 팀이 만든 건 meeting-notes — 회의록과 액션 아이템을 Notion에 자동으로 등록해 주는 Claude Code 슬래시 커맨드 플러그인이다.

항목	내용
프로젝트 기간	2026-07-27(월) ~ 2026-07-30(목)
프로젝트명	meeting-notes (Claude Code 슬래시 커맨드 플러그인)
주제	Notion MCP 연동으로 회의록·액션 아이템을 자동 등록하는 Claude Code 플러그인

사용 기술

1실행 플랫폼Claude Code 플러그인(슬래시 커맨드) — 별도의 서버·프론트엔드 코드는 없음

2외부 연동notion-team MCP 서버를 통한 Notion API 연동

3설정 관리config.json 파일에 팀원 정보를 저장해 관리

GitHub — github.com/ndopy/meeting-notes-plugin

✍️ 마치며

1주차의 마지막 날답게 "정하고 넘어가는" 결정이 많았다. 머지 정책은 Squash로, ERD의 id는 bigint로 못을 박았고, PR 템플릿까지 레포에 붙였다. 개인적으로는 Figma가 조금씩 손에 익어 실제 화면을 만들기 시작했다. 특히 팀원이 정리해 준 JWT 저장 전략이 인상 깊었다 — "토큰을 어디 두느냐"가 곧 XSS·CSRF 방어 설계로 이어진다는 걸 처음 구체적으로 이해했다. 다음 주 8/3부터 본격 구현이라, 이번 주에 잡아둔 문서·규칙이 그대로 뼈대가 된다.

[260730 23일차] 프로젝트 #4

yundlab — Fri, 31 Jul 2026 08:53:57 +0900

# 포트폴리오 학습일지

[프로젝트 4일차] 와이어프레임·디자인 시스템
+ Git 머지 정책 · 산출물 범위 확정

2026.07.30 · 개인 작업(디자인) + 오전·오후 팀 회의(산출물 범위·머지 정책)

오늘 다룬 것들

오늘은 개인적으로 와이어프레임·디자인 시스템·컴포넌트 같은 화면 기반을 잡았고, 팀 회의에선 1주차 기획 산출물 범위와 코드 작성 시작일(8/3)을 확정했다. 오후엔 Git 머지 정책(Rebase vs Squash)과 PR 템플릿을 논의했는데, 머지 전략 용어가 헷갈려서 이참에 개념을 정리했다.

내 작업

와이어프레임디자인 시스템컴포넌트

도구

FigmaFigma→JSON

오전 회의

산출물 범위8/3 코드 시작

머지 정책

Rebase vs Squash

협업

PR 템플릿Org Owner

미니 프로젝트

회의록 시스템시연 영상

내가 한 일 — 화면 기반 잡기

1와이어프레임/UIFigma로 작업(진행중) — 퍼블리싱은 늘 포토샵으로 해와서 아직 툴을 더듬더듬 익히는 중

2디자인 시스템색·타이포·간격 등 디자인 토큰 설정 (완료)

3컴포넌트 제작공통 컴포넌트 제작 (완료)

4문서 숙지기획서·요구사항 명세서 내용 정확히 숙지

왜 Figma로? — UI를 다 잡아두면 Figma에서 JSON으로 변환할 수 있고, 그 JSON을 Claude에게 주면 화면을 거의 똑같이 만들어 준다. 그래서 손으로 하나하나 퍼블리싱하는 대신, 디자인을 확정→JSON→구현으로 이어가려고 Figma를 익히는 중이다.

오전 회의 — 산출물 범위 & 일정

기획 산출물을 어디까지 이번 주에 낼지 확정했다.

구분	내용
1주차 산출물	기획서 · 요구사항 명세서 · ERD · API 명세 초안까지 마무리
2주차로 이월	화면 목록 · 와이어프레임 · 디자인 작업
작업 방식	기존과 동일하게 전원 공동 작업(각 문서 꼼꼼히 확인)
실제 코드 시작	기획서 기준대로 8/3(월)부터

오후 회의 — Git 머지 정책 & PR 템플릿

브랜치·PR은 정했는데, PR을 대상 브랜치에 어떻게 합칠지(머지 방식)가 남아 논의했다. 팀 안에서 "머지 커밋을 남기자", "요즘은 Squash가 일반적이다" 등 의견이 오갔고, Claude·GPT로 각 방식을 확인했다.

1머지 방식Rebase vs Squash 중 택1 → 잠정 Squash, 내일 오전 10시까지 이견 없으면 Squash and merge로 확정

2PR 템플릿팀원마다 PR 서식이 달라 통일용 템플릿 도입 (필요 시 협의 수정)

3Org 권한GitHub Organization 전원 Role을 Owner로 변경

개념 정리 — Merge 방식 3가지 (Merge / Squash / Rebase)

PR을 dev에 합칠 때 이력을 어떻게 남기느냐가 세 방식의 차이다. 결과 코드는 같지만 커밋 기록의 모양이 달라진다.

방식	대상 브랜치에 남는 이력	특징
Merge commit (Create a merge commit)	feature 커밋 전부 + 병합 커밋 1개	브랜치가 갈라졌다 합쳐진 모양이 그대로 보임. 이력이 풍부하지만 지저분해질 수 있음
Squash and merge	PR의 여러 커밋을 합쳐서 커밋 1개	이력이 아주 깔끔(PR=커밋 1개). 대신 개별 커밋과 커밋 컨벤션은 사라짐
Rebase and merge	feature 커밋들을 병합 커밋 없이 하나씩 재배치	선형(직선) 이력 + 커밋 개수·메시지 그대로 유지. 커밋 컨벤션이 살아있음

# 같은 PR(feature/login: 커밋 3개)을 dev에 합칠 때

# ① Merge commit
dev: ...─ Merge pull request #12  # 병합 커밋 + feature 3커밋 다 남음

# ② Squash and merge
dev: ...─ feat(auth): 로그인 기능 추가   # 3커밋 → 1커밋으로 합쳐짐

# ③ Rebase and merge
dev: ...─ WIP1 ─ WIP2 ─ 수정3   # 병합 커밋 없이 선형으로 그대로 얹힘

쉽게 요약 — Squash는 "PR 하나 = 커밋 하나"로 합쳐서 깔끔하게. Rebase는 병합 커밋을 안 만들고 커밋들을 직선으로 이어 붙여 개별 커밋·메시지를 그대로 살림. Merge commit은 갈래가 합쳐진 흔적(병합 커밋)을 남김.

우리 팀 논의 결론 — Squash는 커밋 컨벤션이 안 잡힌 팀에 특히 유용(어차피 1커밋으로 합치니까)하지만, 그만큼 커밋 컨벤션·개별 이력이 퇴색된다는 의견이 있었다. Claude는 "커밋 컨벤션이 정해진 팀이라면 Rebase and merge"를 추천했다. 우리는 커밋 컨벤션(feat·fix…)을 정해둔 상태라, 잠정 Squash로 모였지만 Rebase 여지도 함께 검토 중이다. (참고: 표준 흐름은 feature → dev PR, dev에 PR 없이 반영 금지·CI 필수·리뷰 1명 이상·직접 push 금지)

주간 미니 프로젝트 — 회의록 시스템

1기획·발표자료강사님 피드백 반영해 업데이트 후 구글 드라이브 업로드 (완료)

2시연플러그인 사용법·시연 영상 촬영 (완료)

‍ 오늘의 코드 리뷰 — 접었다 펴는 UI는 div가 아니라 details/summary다 (HTML 3일차)

브라우저에는 이미 "접었다 펴는" 위젯이 들어 있다. div로 흉내 내면 JS를 붙여야 하고, 붙여도 키보드·스크린리더는 그냥 빠진다.

❌ 문제 코드 (전체)

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>공지</title>
</head>
<body>
  <h1>공지</h1>
  <p>오늘 수업은 3시에 시작합니다.</p>

  <!-- ▼ 를 손으로 찍어 놓고 접힘은 아직 안 만든 상태 -->
  <div>▼ 더보기</div>
  <p>준비물: 노트북, 충전기. 지각 시 문자 주세요.</p>
</body>
</html>

무엇이 이상했나 — "▼ 더보기"라고 써 있는데 눌러도 아무 일이 없다. 내용은 처음부터 끝까지 펼쳐진 채고, Tab 키로 그 자리에 도달하지도 못한다. 여기서 "JS를 아직 안 붙였을 뿐이잖아" 하고 넘어가면 안 된다 — 그 생각 자체가 이 문제의 핵심이다. ▼를 손으로 찍고 접힘을 JS로 채우겠다고 마음먹은 순간, 브라우저가 공짜로 주는 태그를 두고 직접 만들기 시작한 것이다.

✅ 정답 (수정 부분)

  <!-- 접었다 펴는 건 details/summary 다 -->
  <details>
    <summary>더보기</summary>
    <p>준비물: 노트북, 충전기. 지각 시 문자 주세요.</p>
  </details>

왜 details/summary인가 — div는 "그냥 상자"라서 ▼는 글자일 뿐이고 접힘 동작은 어디에도 없다. 반면 details/summary는 브라우저가 세 가지를 공짜로 준다: ① 펼침/접힘 상태(open 속성이 알아서 켜졌다 꺼짐), ② 키보드 포커스(Tab 도달) + Enter/Space로 열고 닫기, ③ 스크린리더가 "접힌 항목"이라고 읽어줌(role). summary는 항상 details의 첫 자식이고 나머지가 접히는 내용이 된다. ▼도 직접 쓰지 않는다 — 브라우저가 삼각형을 그리고 방향까지 뒤집어 준다. 처음부터 펼쳐 두려면 <details open>. JS는 한 줄도 필요 없다.

확인 방법

방법	❌ 문제(div)	✅ 정답(details)
눌러보고 `Tab`으로도 눌러보기	클릭해도 안 접힘, Tab 포커스도 안 감, 내용 계속 보임	처음엔 접힘 → 클릭/Enter/Space로 열고 닫힘
Console: 키보드로 닿는 요소 세기 `$$('a[href],button,input,summary,[tabindex]').length`	`0` (키보드 사용자에겐 조작할 게 없음)	`1` (summary가 잡힘)
DevTools → Accessibility → Role	`generic` (그냥 글자 상자)	summary=`DisclosureTriangle`, details=`group`

실무에서는 이렇게 터진다 — FAQ·약관·상품 상세·필터 패널 등 접히는 UI는 어디에나 있다. div+JS로 만들면 JS가 늦게 뜨거나 에러 나는 순간 아무도 못 연다. 접근성 감사(a11y)에 그대로 걸리고, Ctrl+F로 검색해도 감춰 둔 내용이 안 잡히며, 인쇄하면 통째로 빠진다. details는 이 전부를 브라우저가 처리한다 — Chrome은 Ctrl+F로 접힌 안쪽 글자를 찾으면 알아서 펼쳐 준다.

같이 자주 틀리는 것
① 여기서 바로 onclick/JS부터 꺼내는 것("라이브러리 아코디언 쓰면 되지"도 같은 함정) — 직접 만들면 tabindex="0"(도달), keydown(Enter·Space 둘 다), aria-expanded 갱신, role 지정 넷을 다 해야 하고, 대개 Space나 aria-expanded에서 조용히 빠진다. details는 이 넷이 전부 기본값. 순서는 네이티브 먼저, 안 되는 것만 JS.
② div에 tabindex="0"만 붙이고 끝 — 포커스는 되지만 Enter/Space 처리·role은 여전히 없다(절반만 고침).
③ 기본 삼각형이 디자인과 안 맞는다고 div로 되돌아가는 것 — summary { list-style: none }으로 지우고 원하는 아이콘을 넣으면 된다.
④ 반대로 details를 만능으로 보는 것 — 부드러운 애니메이션, "한 번에 하나만 열리는" 아코디언, 마커 미세 조정이 붙으면 브라우저마다 손이 더 간다. 기본형을 details로 잡아 두고 그때 확장하면 된다.

✍️ 마치며

오늘은 "화면"과 "협업 규칙"을 동시에 다듬은 날이었다. Figma가 아직 손에 안 붙지만, 디자인을 JSON으로 뽑아 Claude로 구현하는 흐름을 알고 나니 툴 익히는 게 덜 막막해졌다. 그리고 머지 정책을 파보면서 "결과 코드는 같아도 이력의 모양이 달라진다"는 걸 처음 제대로 이해했다 — Squash는 깔끔함, Rebase는 커밋 이력 보존. 컨벤션을 정해둔 우리 팀엔 무엇이 맞을지 내일 결론이 난다. 다음 주 8/3부터 본격 구현이라, 지금 뼈대를 잘 잡아두는 게 중요하다.

[260729 22일차] 프로젝트 #3

yundlab — Thu, 30 Jul 2026 09:09:04 +0900

# 포트폴리오 학습일지

[프로젝트 3일차] 컨벤션 병합 · 레포 설정
+ 기획서·WBS·요구사항·ERD 작성

2026.07.29 · 오전 팀 회의(협업 규칙 확정) + 개인 산출물(기획 문서 4종)

오늘 다룬 것들

오늘 오전엔 협업 규칙을 실제로 확정했다. 1차로 병합한 CLAUDE.md를 함께 검토해 코드 컨벤션을 정하고, GitHub 레포를 백엔드/프론트로 분리하기로 했다. 오후엔 개인적으로 팀 기획서 마무리 + WBS + 요구사항 명세서 + 데이터 ERD까지 프로젝트의 뼈대 문서 4종을 작성했다. 회의로 "규칙"을 맞추고, 문서로 "설계"를 잡은 하루였다.

주간 미션

회의록 시스템기획서 제출

CLAUDE.md

1차 병합컨벤션 합의

코드 규칙

eslint-plugin-importTailwindCSS

레포 설정

BE/FE 분리

기획서

노션 템플릿공동 편집

내 산출물

WBS요구사항ERD

오전 회의 — 협업 규칙 확정

참석자 전원. 안건은 주간 미션 공유 · CLAUDE.md 병합 협의 · GitHub 레포 기본 설정 · 프로젝트 기획서 네 가지였다.

주간 미션 공유

회의록 시스템 관련 사항을 공유하고, 플러그인 개발과 기획서 제출을 완료했다.

CLAUDE.md 병합 협의

각자 만든 규칙을 1차로 병합한 CLAUDE.md를 함께 확인하고, 아래를 확정했다.

항목	결정
import 정렬 도구	`eslint-plugin-import` 사용
CSS 방법론	TailwindCSS 사용 (shadcn/ui 같은 라이브러리는 미사용)
백엔드 호스팅	Render vs AWS 프리티어 트레이드오프 확인 후 백엔드 담당이 결정

GitHub 레포 기본 설정

1진행 시점CLAUDE.md 업데이트 이후 레포 기본 설정 진행 (팀장 담당)

2레포 분리백엔드 레포 · 프론트엔드 레포를 분리

3CLAUDE.md 분리CLAUDE.md도 BE/FE로 나눠 각 레포에 설정

프로젝트 기획서

월 단위 기획서 제출 기한은 ~7/31. 정해진 서식이 없어, 내가 만든 노션 템플릿을 팀 공통 서식으로 쓰기로 했고, 팀원 전원이 그 페이지에서 공동 편집으로 작성하기로 했다.

결정 사항 · 액션 아이템

결정 사항
import 정렬 도구 = `eslint-plugin-import`
CSS = TailwindCSS (shadcn/ui 등 미사용)
백엔드 호스팅 = 담당자가 트레이드오프 확인 후 결정
월 단위 기획서 = 내가 만든 노션 템플릿 사용
기획서 = 전원 노션 공동 편집으로 작성

☐팀원 A(BE)백엔드 호스팅(Render vs AWS) 트레이드오프 확인 후 결정

☐전원GitHub 레포 기본 설정(BE/FE 레포 및 CLAUDE.md 분리)

☐전원월 단위 기획서 노션 템플릿으로 공동 작성·제출 — 기한 2026-07-31

내가 한 일 — 기획 문서 4종

오늘은 팀의 설계 뼈대를 세우는 문서들을 집중적으로 작성했다.

1기획서 마무리우리 팀 프로젝트 기획서를 마무리 (팀 공통 노션 템플릿 기반)

2WBS작업 분해 구조(Work Breakdown Structure) 문서 준비 — 할 일을 단위로 쪼개 일정·담당 정리

3요구사항 명세서기능/비기능 요구사항 정리

4ERD데이터 모델링 — 엔티티·관계 설계(ERD) 문서 작성

느낀 점 — 코드보다 문서를 더 많이 쓴 날이었지만, WBS로 "무엇을 언제 누가"를, 요구사항 명세로 "무엇을 만들지"를, ERD로 "데이터를 어떻게 담을지"를 먼저 정리해두니 앞으로의 구현이 훨씬 또렷해졌다. 특히 백엔드를 Claude로 구현할 계획이라, 이 문서들이 자세할수록 결과물 품질이 올라간다는 걸 체감했다.

‍ 오늘의 코드 리뷰 — 폼 값은 name 이 있어야 전송된다 (HTML 2일차)

2일차 코드 리뷰 주제는 "제출되는 건 name이 붙은 컨트롤의 값뿐". 로그인 폼에서 아이디·비밀번호를 다 채우고 눌러도 서버엔 빈 값이 도착하는 게 문제였다. 화면상 제출(새로고침)은 멀쩡히 일어나서 더 헷갈린다.

❌ 문제 코드 (전체)

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>로그인</title>
</head>
<body>
  <h1>로그인</h1>

  <form>
    <label for="userId">아이디</label>
    <input type="text" id="userId">   <!-- ❌ name 없음 → 전송 안 됨 -->

    <label for="userPw">비밀번호</label>
    <input type="password" id="userPw">  <!-- ❌ 여기도 name 없음 -->

    <button type="submit">로그인</button>
  </form>
</body>
</html>

✅ 정답 (수정 부분)

<!-- 전송이 필요한 입력마다 name 추가 → 서버가 읽는 키가 곧 이 name -->
<input type="text" id="userId" name="userId">
<input type="password" id="userPw" name="userPw">

왜 그런가 — 브라우저는 폼을 제출할 때 name 속성이 있는 컨트롤만 직렬화한다. id만 있고 name이 없으면 그 값은 제출 데이터에 안 담긴다. id는 label 연결(for)·CSS·JS 선택자용일 뿐 전송과는 무관. 그래서 "입력은 했는데 서버엔 안 온다"가 된다.

확인 방법

방법	문제(name 없음)	정답(name 있음)
채우고 로그인 → 주소창(URL)	`...?` 쿼리 비어 있음	`...?userId=...&userPw=...`
Console `[...new FormData(document.querySelector('form'))]`	`[]` (빈 배열)	`[['userId','...'],['userPw','...']]`
DevTools Elements	input에 `id`만	`name="userId"`·`name="userPw"`

FormData는 name이 있는 컨트롤만 담으므로, 값이 안 실리는 직접 증거가 된다. (file://로 열면 쿼리가 안 보일 수 있어 Live Server 권장 — 콘솔 확인은 어느 쪽에서도 확실)

실무에선 이렇게 터진다 — 백엔드에서 req.query.userId/req.body.userId가 계속 undefined. 프론트는 "분명히 입력했는데" 서버는 빈 값이라 원인을 한참 못 찾는다. name 오타(user_id↔userId)는 더 악질 — 렌더·제출은 되는데 서버가 기대하는 키와만 안 맞아 조용히, 에러 없이 실패한다.

같이 자주 틀리는 것 — ① id로 값이 전송된다고 착각(전송은 오직 name), ② name을 서버 기대 키와 다르게(오타·대소문자·스네이크/카멜 혼용), ③ 로그인 폼을 GET(기본값) 그대로 두기 → 비밀번호가 URL·기록에 남으므로 실무는 method="post", ④ checkbox·radio는 name이 없으면 값은커녕 그룹조차 안 묶인다.

✍️ 마치며

오늘은 "손으로 코드를 짜는" 날이 아니라 "프로젝트의 뼈대를 세우는" 날이었다. 컨벤션(eslint·Tailwind)과 레포 구조(BE/FE 분리)를 팀이 합의하고, 나는 기획서·WBS·요구사항·ERD로 설계의 밑그림을 그렸다. 규칙과 설계를 먼저 맞춰두면 나중에 각자 병렬로 달릴 때 충돌이 줄어든다는 걸 다시 느꼈다. 내일부터는 이 문서들을 기준으로 실제 구현에 들어간다.

[260728 21일차] 프로젝트 #2

yundlab — Tue, 28 Jul 2026 16:38:01 +0900

# 포트폴리오 학습일지

[프로젝트 2일차] 주제 선정 · 회의록 시스템 미션
Git 전략 · 하네스 엔지니어링

2026.07.28 · 오전·오후 팀 회의 (주제 확정 → 협업 규칙·운영 방식 결정)

오늘 다룬 것들

오늘은 프로젝트 주제를 확정하고, 그걸 어떻게 굴릴지 운영 방식까지 못 박은 날이었다. 오전엔 팀원 각자가 준비해 온 기획을 소개·투표해 주제를 골랐고, 오후엔 확정된 주제와 함께 주간 미션(회의록 시스템), Git 브랜치 전략, 그리고 프로젝트 운영에 하네스 엔지니어링을 도입하기로 했다. "무엇을 만들지"에서 "어떻게 같이 만들지"로 넘어가는 단계였다.

주제 선정

기획 4개투표

확정 주제

실시간 피드백 모니터링

주간 미션

회의록 시스템플러그인Notion MCP

Git 전략

main/devfeature/**PR 보호

운영

하네스 엔지니어링

기타

API 계약서issue-log 연동

오전 회의 — 주제 선정

안건은 "주제 선정을 위한 팀원별 기획 소개". 각자 준비한 기획을 발표하고, 서로의 기획을 상세히 검토한 뒤 투표하기로 했다.

제안자	기획 주제
팀원 A	실시간 이벤트 피드백 모니터링 서비스
팀원 B	실시간 협업 여행 계획 서비스
팀장	반려동물 동반 여행 가이드 서비스
나	AI 기반 감정 일기장 서비스

오전 액션 아이템

1검토·투표오전 11:30까지 다른 팀원 기획을 상세 검토 후 투표

2Claude 검토전체 기획 문서를 Claude에 전달 → "4주·4명" 팀 상황에 맞게 구현 가능한 주제인지 검토 요청

3API 계약서주제 선정 후, 생성형 모델 API 호출 계약서용 범주 설정

API 계약서 범주 — 생성형 모델을 쓴다면 사용처 · 예상 월 금액 · 과금 책임 여부를 정해 계약서(제약서)에 담아야 한다. 주제를 고를 때 "AI를 어디에·얼마나 쓰는가"를 함께 따져야 한다는 점이 인상적이었다.

✅ 오후 회의 — 주제 확정

참석자 전원. 오전 검토·투표 결과, 주제는 「실시간 피드백 모니터링 서비스」(팀원 A 제안)로 확정됐다.

주제 확정 — 실시간 피드백 모니터링 서비스. 4주·4명이라는 팀 상황과 구현 가능성을 함께 고려한 결과였다.

주간 미션 — 회의록 시스템

이번 주 미션은 "회의록 시스템". raw 회의록 마크다운을 넣으면 정해진 서식으로 정리해 주는 도구를 직접 만든다.

1정리raw 회의록 .md를 전달하면 정해진 서식에 맞게 섹션 분리·정리

2자동 작성Notion MCP 연결로 팀스페이스 '회의록' 섹션에 페이지 자동 생성

3액션 아이템회의록의 액션 아이템을 '액션 아이템' 섹션에 자동 추가

4형식Claude Code에서 쓰는 플러그인 방식

왜 플러그인 방식인가 — ① 도구 최소화(Notion 팀스페이스로 관리 플랫폼 통합), ② 배포·사용 편의(GitHub repo로 배포, 몇 줄 명령어로 설치). 며칠 전 배운 플러그인·MCP가 바로 팀 도구로 이어졌다.

기한 — 팀장이 7/29(수) 15:00까지 회의록 플러그인 기획서를 작성·제출한다.

Github Repo & 브랜치 전략

1직접 권한Organization Repo에서 fork 없이, 각 멤버에게 쓰기 권한 부여 → 같은 repo에 직접 접근

2브랜치 보호main·dev에 바로 병합 못 하게 보호 장치 필요 (Claude로 방안 확인·검토 예정)

3브랜치 전략main·dev 기본 + feature/**·refactor/** 를 만들어 PR/커밋

4issue-logissue-log 플러그인과의 연동 고려

# 브랜치 전략
main      # 안정 버전
 └ dev    # 통합 개발
    ├ feature/**    # 기능 개발
    └ refactor/**   # 리팩토링
# main·dev 직접 병합 금지 → PR로만

PR 메시지에 하네스 엔지니어링 적용 — Claude와 함께 구현한 코드 중 "이해가 잘 안 된 부분"도 PR에 명시하기로 했다. AI가 짠 코드를 그냥 넘기지 않고, 모르는 곳을 드러내 팀이 함께 검토하는 안전장치 — 하네스의 감각을 협업 규칙으로 옮긴 셈이다.

환경 설정 — 하네스 엔지니어링 도입

프로젝트 운영 자체에 하네스 엔지니어링을 도입하기로 했다. 각자 하네스에 추가할 환경설정 항목을 검색·조사해 오고, 오후 15:30에 다시 모여 어떤 항목을 넣을지 결정한다.

결정 사항 · 액션 아이템

결정 사항
주제: 실시간 피드백 모니터링 서비스 선정
Repo: Organization Repo에서 fork 없이 멤버별 쓰기 권한 부여
브랜치 전략: `main`·`dev` + `feature/`·`refactor/`
PR 메시지에 이해 안 되는 부분 명시하는 하네스 엔지니어링 적용
프로젝트 운영에 하네스 엔지니어링 도입

☐팀장회의록 플러그인 기획서 작성·제출 — 기한 2026-07-29

☐전원main·dev 병합 보호 장치 방안 확인·검토 (Claude 활용)

☐전원하네스 환경설정 항목 검색·조사 — 기한 2026-07-28

‍ 오늘의 코드 리뷰 — label vs p (HTML 1일차)

7/28부터 매일 코드 리뷰가 시작됐다. 첫 주제는 "입력칸의 이름표는 <p>가 아니라 <label>로 붙인다". 겉으론 멀쩡한 회원가입 폼인데, "아이디" 글자를 눌러도 입력칸에 커서가 안 들어가는 게 문제였다.

❌ 문제 코드 (전체)

<!DOCTYPE html>
<html lang="ko">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>회원가입</title>
</head>
<body>
  <h1>회원가입</h1>

  <form action="/signup" method="post">
    <p>아이디</p>              <!-- ❌ 이름표를 p 로 -->
    <input type="text" id="userId" name="userId" required>

    <p>비밀번호</p>            <!-- ❌ 여기도 p -->
    <input type="password" id="userPw" name="userPw" required>

    <button type="submit">가입하기</button>
  </form>
</body>
</html>

✅ 정답 (수정 부분)

<!-- p → label 로, for 의 값은 input 의 id 와 같게 -->
<label for="userId">아이디</label>
<input type="text" id="userId" name="userId" required>

<label for="userPw">비밀번호</label>
<input type="password" id="userPw" name="userPw" required>
<!-- for 의 값 = input 의 id (한 글자만 달라도 안 묶임) -->

왜 label이어야 하나 — label에 for를 쓰면 브라우저가 그 입력칸과 한 쌍으로 묶어준다. 그래서 ① 글자를 클릭하면 입력칸에 커서가 들어가고, ② 스크린리더가 "아이디, 입력"처럼 무슨 칸인지 읽어준다. for에 적는 값이 곧 입력칸의 id라, id가 필요했던 것.

확인 방법

방법	문제(p)	정답(label)
글자 클릭	아무 일 없음	입력칸에 커서 들어옴
Console `document.querySelector('#userId').labels.length`	`0` (연결된 이름표 없음)	`1` (이름표와 묶임)
F12 → Accessibility → Name	비어 있음	"아이디"

실무에선 이렇게 터진다 — 화면이 멀쩡해 보여 끝까지 발견 안 됨. 모바일에선 label이 묶여 있어야 글자 영역까지 눌러 커서를 넣을 수 있어 오탭이 준다. 스크린리더 사용자에겐 이름 없는 칸이 되어 가입 자체가 막힌다. 입력칸을 만들 때마다 label을 같이 쓰는 습관이 필요.

같이 자주 틀리는 것 — ① placeholder로 이름표를 대신하기(입력하면 사라져 무슨 칸인지 모름 → label 대체 불가), ② for에 name 값 적기(for는 id를 가리킨다, name 아님).

✍️ 마치며

주제를 정하는 것보다 인상 깊었던 건, "AI로 짠 코드를 어떻게 우리 것으로 만드느냐"를 규칙으로 못 박은 부분이었다. PR에 이해 안 된 부분을 일부러 적는 하네스 방식은, 며칠 전 배운 개념이 실제 팀 워크플로로 살아나는 순간이라 반가웠다. 회의록 시스템 미션도 결국 우리가 배운 플러그인·MCP를 팀 도구로 만드는 일이라, 배운 게 곧바로 쓰인다는 게 좋았다. 내일은 각자 하네스 항목을 들고 와 운영 규칙을 확정한다 — 판이 점점 갖춰지고 있다.

[260727 20일차] 프로젝트 #1

yundlab — Tue, 28 Jul 2026 11:02:15 +0900

# 포트폴리오 학습일지

[킥오프] 팀 프로젝트 시작
조 편성 · 협업 컨벤션 · 팀 멘토링

2026.07.27 · 학습 범위: 포트폴리오 프로젝트 킥오프 (팀 세팅·Git 규칙·멘토링)

오늘 다룬 것들

오늘부터 포트폴리오 팀 프로젝트가 시작됐다. 코드를 배우는 날이라기보다, 같이 일할 판을 짜는 날이었다. 팀을 꾸리고, 소통·갈등 조정 방식을 정하고, Git 브랜치·커밋·코드 스타일 같은 협업 컨벤션을 합의했다. 오후엔 팀 멘토링으로 Github 관리·API 비용·코드 리뷰·주간 미션 범위 같은 실무 규칙도 확인했다. 혼자 코딩하던 것과 달리 "규칙부터 맞추고 시작한다"는 감각이 새로웠다.

팀 구성

팀장 선정Slack

Git 브랜치

main→dev→featurePR 병합

커밋

Conventionalfeat·fix·docs

코드 스타일

PrettierESLint

멘토링

레포 관리API 제약서

다음 할 일

기획서28일 투표

팀 세팅

먼저 팀을 꾸렸다. 팀명·로고는 무겁게 가지 않고 후보만 가볍게 정한 뒤 확정은 뒤로 미뤘고(임시), 팀장도 정했다(실명은 생략). 소통은 Slack 채널로 하기로 했다.

갈등 조정 규칙 (개발자스러운 재치) — 의사결정 기준을 삼항 연산자로 정리했다:

isCritical ? "클로드 포함 5인 다수결" : "사소한 건 팀장 자율"

중요한(critical) 사안은 Claude까지 포함해 5인 다수결, 사소한 건 팀장이 빠르게 판단. "무엇이 중요한 결정인가"를 먼저 나눈 게 핵심이었다.

Git & 협업 컨벤션

브랜치 전략

main → dev → feature 3단 브랜치로 가기로 했다. 기능은 feature에서 만들어 dev로 모으고, 안정된 것만 main으로 올린다. (모노레포 여부는 기획이 확정된 뒤 결정)

메인 브랜치 직접 푸시 금지 — main에는 직접 push하지 않고 PR(Pull Request)을 통해서만 병합한다. 실수 방지를 위해 hook으로 한 번 더 체크하기로 했다(며칠 전 배운 커스텀 훅이 실제 협업 규칙으로 이어진 셈).

커밋 컨벤션 (Conventional Commits)

커밋 메시지는 컨벤셔널 커밋 형식을 따르고, 타입 태그를 붙인다. 커밋 본문 내용 형식까지는 아직 강제하지 않기로 했다.

타입	설명
`feat`	새로운 기능 추가
`fix`	버그 수정
`docs`	문서 수정 (코드 변경 없음)
`style`	포맷팅·세미콜론 등 스타일 변경 (논리 변경 없음)
`refactor`	리팩토링 (기능 변화 없음)
`test`	테스트 코드 추가/수정
`chore`	빌드·패키지 설정 등 기타 작업
`design`	CSS 등 UI 디자인 변경
`comment`	필요한 주석 추가/변경

코드 스타일

포매터·린터로 스타일을 통일해 "누가 짜도 같은 모양"이 되게 맞췄다.

1Prettier코드 자동 포매팅

2ESLint문법·규칙 검사

3세미콜론문장 끝 세미콜론 사용

4싱글 쿼트문자열은 작은따옴표

5들여쓰기4칸(스페이스)

팀 컨벤션 (소통)

1공개 소통1:1 DM 지양, Slack 채널에서 소통 — 모두가 진행상황·피드백 공유

2확인 표시공지·게시물 확인 후 체크 이모지 남기기

API 비용 관련 방향 — 운영 측에 문의한 결과 추가 비용 지원이 현실적으로 어렵다는 답을 받아, 일단 생성형 모델 API 호출이 없는 기획 쪽으로 방향을 잡는 것을 고려하기로 했다.

‍ 팀 멘토링 정리 (2026-07-27)

주제	내용
Github 관리	별도 HANCOM organization 없음. 팀장이 레포 생성 → 팀원을 collaborator로 초대. 강사님이 각 팀 레포 주소를 수집. 레포 관리 방식은 기획 완료 후 협의.
Claude API 비용 지원	"제약서" 작성 필요 — 기획에서 "API를 어디에·얼마나 활용할지"를 알려야 함. 정확한 서식은 미전달, 일단 제출 후 피드백받기.
코드 리뷰	(주의) 팀 프로젝트 코드를 리뷰하는 게 아님! 강의에서 배운 내용(예: JS의 class)에 대한 코드를 리뷰하는 방식.
주간 미션 "회의록 시스템 개발"	개발에 도움이 되는 도구를 직접 만들어보는 경험이 목적. 웹 서비스가 아니어도 되고, 플러그인 등 형태는 팀 내 결정.
Notion	초대된 HANCOM 팀스페이스의 "E조_한컴" 문서 사용.
기획 규모	기획에 시간·노력이 많이 듦. "기획→구현" 반복은 선호되지 않음 → 결국 팀 내 결정이 최선.

참고 — 팀원이 만든 이슈 로그 플러그인 — 프로젝트 진행하며 매일 이슈를 기록하려고, Notion MCP로 현재 세션의 이슈를 정해진 형식으로 개인 노션 페이지에 써주는 플러그인을 만든 팀원이 있었다(github.com/kimnioyh/issue-log). 며칠 전 배운 플러그인·MCP가 바로 팀 협업 도구로 이어지는 게 인상적이었다.

팀장 멘토링 — 일정 · 서버

팀장 멘토링에서 공유된 제출 일정과 서버 방식을 정리했다. 주 단위(회의록 시스템)와 월 단위(미정 프로젝트) 기획안 마감이 각각 잡혔다.

서버가 필요할 때 — 남는 PC에 리눅스 OS를 설치하거나 AWS 프리티어 등을 사용한다. 정답은 없고 팀에 맞는 방식을 고르면 된다.

구분	마감 · 내용
주 단위 — 회의록 시스템	7/29(수)까지 기획안 제출 · Notion 팀 페이지 "미니 프로젝트" 섹션에 작성
월 단위 — 미정 프로젝트	7/31(금)까지 기획안 제출
중간 발표	약 3주 뒤 진행 예정 (정확한 일정은 추후 안내)
최종 발표 채점 기준	추후 안내 예정

✅ 다음 할 일

1기획서각자 프로젝트 주제 및 기획서 작성해오기 (중요)

2주제 투표28일(화) — Claude 포함 총 5명 투표로 주제 결정

✍️ 마치며

그동안은 "무엇을 어떻게 만드느냐"를 배웠다면, 오늘은 "여럿이 어떻게 같이 만드느냐"를 정하는 날이었다. 브랜치 전략·커밋 컨벤션·코드 스타일처럼, 혼자면 안 정해도 되는 것들을 미리 합의해두는 게 결국 나중의 충돌을 줄인다는 걸 느꼈다. 특히 main 직접 푸시를 훅으로 막고 PR로만 병합하기로 한 부분은, 얼마 전 배운 커스텀 훅이 실제 협업 규칙으로 살아나는 순간이라 반가웠다. 내일은 각자 기획서를 들고 와 주제를 정한다 — 이제 진짜 "우리 것"을 만들기 시작한다.

[260724 19일차] Claude Code 심화

yundlab — Tue, 28 Jul 2026 11:00:08 +0900

# AI 도구 · 자동화 학습일지

[Claude Code 심화]
커스텀 훅 · 플러그인 · MCP 자동화

2026.07.24 · 학습 범위: Claude Code 도구·명령어(advisor·caveman·skills.sh 등), 커스텀 훅(PreToolUse), 플러그인 제작, MCP

오늘 다룬 것들

오늘은 "Claude Code를 내 손에 맞게 길들이는" 하루였다. 세션을 관리하는 CLI 명령어부터, 위험한 명령을 자동으로 가로채는 커스텀 훅, 스킬·훅·에이전트·MCP를 한데 묶은 플러그인 제작, 그리고 노션 MCP를 연결해 이 학습일지를 자동으로 쓰는 자동화까지 직접 만들어봤다. 어제까지 도구를 "쓰는" 쪽이었다면, 오늘은 도구를 "만드는" 쪽으로 넘어간 느낌이었다.

CLI 명령어

/rename/resume@agent

커스텀 훅

PreToolUsestdin JSONexit code

안전 가드

rm -rfgit resetDROP

플러그인

스킬훅에이전트MCP

배포

마켓플레이스

자동화

notion MCP/daily-log

Claude Code CLI — 세션 다루기

세션을 오래 쓰다 보면 대화가 여러 개로 쌓인다. 오늘은 그 세션을 이름 붙이고 다시 찾아 들어가는 명령어를 익혔다.

명령어	역할
`/rename`	현재 세션에 제목을 붙여 나중에 알아보기 쉽게 함
`/resume`	이전 세션 목록을 모두 보고 원하는 세션으로 찾아 들어감

/resume은 "어제 하던 그 작업"으로 정확히 되돌아갈 때 유용하다. 세션마다 /rename으로 제목을 붙여두면, 나중에 목록에서 헤매지 않고 바로 골라 이어갈 수 있다.

@에이전트로 홈페이지 만들기

@에이전트이름으로 특정 서브에이전트를 호출해 작업을 통째로 맡길 수 있다. 오늘은 @"늙크크" 에이전트를 불러 홈페이지(index.html) 한 벌을 만들어봤다. 프롬프트로 일일이 지시하는 대신, 목적에 맞게 설계된 에이전트에게 "만들어줘" 한 번으로 결과물이 나온다는 게 편했다.

Claude Code 도구·명령어 모음 (허브 카드)

Claude 학습 허브에는 Claude Code를 확장하는 슬래시 명령어·도구 카드가 잔뜩 있었다. 오늘 핵심 실습(훅·플러그인·MCP)과 함께 이 도구들도 한 바퀴 훑었다.

명령어 / 도구	역할
`/advisor`	더 강한 모델을 조언자로 붙여 중요한 순간에 한 번 더 검토 (실험적·API 전용, 토큰 별도 과금)
`/init`	코드베이스를 분석해 `CLAUDE.md` 자동 생성 (새 저장소 첫 명령)
`/statusline`	하단 상태줄(컨텍스트·비용·git 브랜치·모델)을 자연어로 설정
`/insights`	내 사용 패턴·마찰 지점을 스캔해 리포트(HTML) 생성
`/powerup`	Claude Code 기능을 짧은 인터랙티브 레슨(약 30분)으로 학습
`/team-onboarding`	최근 30일 이력으로 팀 온보딩용 `ONBOARDING.md` 생성
`/radio`	프롬프트에 입력하면 유튜브 BGM 재생 (작업용 배경음악)
`/grill-me`	계획·설계를 공유 이해에 도달할 때까지 집요하게 인터뷰 (질문 하나씩 + 추천답변)

Caveman Mode — 토큰 절약 — 원시인처럼 군더더기 빼고 핵심만 답하게 하는 모드. 답이 길수록 청구서가 두꺼워지는데, 짧게 답하도록 강제하면 평균 65% 토큰 절감(때론 정확도도 오름). /caveman으로 켜고 stop caveman(노말모드)으로 끈다.

skills.sh & PICKS(스킬 8선) — AI 에이전트용 재사용 스킬을 모아둔 오픈 디렉터리. npx skills add <owner/repo> 한 줄로 설치한다. "매일 손이 가는 스킬 8선"(Karpathy Guidelines·Superpowers·Humanizer 등) 같은 큐레이션도 있어, 필요한 절차적 지식을 골라 붙일 수 있다.

GitHub × Claude Code — 저장소 만들기 → clone → 커밋·push → PR까지의 흐름을 익혔다. 압권은 PR·이슈 댓글에 @claude만 적으면 GitHub Action이 자동으로 코드를 고쳐 PR을 올려주는 것(ANTHROPIC_API_KEY 시크릿 등록 필요).

TIPS(단축키·프롬프트) · HORROR — Shift+Tab(권한 모드 순환)·!(셸 즉시 실행)·@(파일 첨부)·ultrathink(그 질문만 깊게) 같은 단축키/프롬프트 꿀팁 모음. HORROR는 재미로 넣은 이스터에그 카드다. MCP는 USB-C처럼 외부 도구(노션·카카오 등)를 통일 규격으로 연결하는 것으로, 오늘 자동화(아래)에서 직접 사용했다.

bkit — 프로세스가 있는 AI 개발(플러그인) — "AI한테 그냥 시키는 개발"을 PDCA(Plan-Do-Check-Act) 프로세스가 있는 개발로 바꿔주는 Claude Code 플러그인. 기능마다 문서(PRD·설계·분석·보고서)가 나오고, 코드가 그 문서와 맞는지 자동 검증한다(내부적으로 44스킬·34에이전트·11품질게이트 조합).

claude plugin install bkit
/pdca pm my-feature   # PRD→설계→개발→검증→보고
/pdca team            # 전문가 에이전트 팀 병렬 소환

기능마다 PRD·설계 문서가 남아 팀/강의 프로젝트의 공유·리뷰·평가에 그대로 쓸 수 있다는 점이 인상적이었다.

정리하면 — 허브 화면의 15개 카드를 한 바퀴 훑었다: /advisor·/init·/statusline·/insights·/powerup·/team-onboarding(ONBOARDING)·/radio·/grill-me· CAVEMAN· SKILLS.SH· PICKS· GITHUB· TIPS· HORROR· BKIT· MCP. 슬래시 명령어부터 토큰 절약·스킬 생태계·협업 자동화까지, Claude Code를 "확장하는 도구"가 이렇게 많다는 걸 이번에 제대로 알았다.

커스텀 훅 — Dangerous Command Guard

오늘의 핵심 실습. Claude Code가 복구 불가능한 Bash 명령을 실행하려 할 때, 자동으로 가로채서 사용자가 그 명령을 직접 타이핑해야만 실행을 허용하는 안전 가드 훅을 만들었다. 훅(Hook)은 Claude가 특정 행동을 하기 직전/직후에 끼어드는 내 코드다.

동작 방식

1시도Claude가 Bash 툴로 명령 실행을 시도

2이벤트PreToolUse 이벤트 발생 → 훅 스크립트 자동 실행

3감지위험 패턴 감지 시 실행 중단 + 터미널에 경고 출력

4확인사용자가 명령어를 그대로 타이핑하면 허용, 아니면 차단

5기록시도 결과(차단/허용)를 로그 파일에 남김

차단 대상 명령어

패턴	위험 이유
`rm -rf`	파일·디렉토리 강제 삭제
`git reset --hard`	미저장 변경사항 전체 파기
`git push --force`	원격 히스토리 덮어쓰기
`DROP TABLE`	DB 테이블 삭제
`DROP DATABASE`	DB 전체 삭제

구성 요소

~/.claude/
├── hooks/
│   └── dangerous_guard.py   # 훅 스크립트 (Python)
├── settings.json            # PreToolUse 이벤트 등록
└── logs/
    └── dangerous_guard.log  # 시도 기록

훅은 settings.json의 PreToolUse에 Bash 툴을 matcher로 걸어 등록한다. Bash 실행 시도마다 이 파이썬 스크립트가 먼저 돌아간다.

"hooks": {
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [
        {
          "type": "command",
          "command": "python \"C:/Users/Har06/.claude/hooks/dangerous_guard.py\""
        }
      ]
    }
  ]
}

확인 방식 · 로그

사용자가 위험 명령어를 토씨 하나 안 틀리고 그대로 타이핑해야 실행이 허용된다. 틀리거나 빈 입력이면 차단된다.

⚠️  위험 명령어 감지: [rm -rf]
   명령어: rm -rf ./dist

실행하려면 명령어를 그대로 입력하세요 (취소: Enter만 누르기):
> rm -rf ./dist     ← 정확히 입력 시 허용

2026-07-24 14:32:11 | BLOCKED | rm -rf ./dist
2026-07-24 14:35:02 | ALLOWED | git reset --hard HEAD~1

핵심 기술

항목	내용
이벤트	`PreToolUse` — Bash 툴 실행 전에 가로채기
언어	Python
입력	stdin으로 JSON 수신 (`tool_input.command` 필드)
콘솔 입력	`CONIN$` 직접 열기 (stdin이 이미 소비된 상태에서 사용자 입력 받기)
종료 코드	`0` = 허용, `2` = 차단

막혔던 지점 — stdin으로 이미 JSON을 다 읽어버린 뒤라, 같은 stdin으로 다시 사용자 키 입력을 받으려 하면 안 된다. 그래서 Windows 콘솔의 입력 버퍼인 CONIN$를 직접 열어서 타이핑을 받아야 했다. 종료 코드로 허용/차단이 갈린다는 것(2면 Claude 쪽에서 실행이 막힘)도 이 실습으로 확실히 이해했다.

솔직한 후기 — 훅 실습을 로드맵 20번부터 끝까지 마저 진행했는데, 실행이 너무너무 느려서 훅이 제대로 걸린 건지 애매했다 ㅠㅠ. 개념과 흐름은 확실히 잡았지만, 실제 반응 속도 때문에 "정말 동작하는가"를 눈으로 확신하긴 어려웠던 부분이 아쉬웠다.

커스텀 플러그인 제작

훅 하나로 끝이 아니라, 스킬 · 훅 · 에이전트 · MCP를 한 묶음으로 담은 커스텀 플러그인을 만들어봤다. 여러 요소를 조합해 하나의 기능 패키지로 굳히고, 마켓플레이스 배포 방식으로 배포까지 진행했다.

구성 요소	역할
스킬(Skill)	반복 작업을 `/명령어`로 굳혀 재사용
훅(Hook)	특정 행동 직전/직후에 내 코드가 자동 개입
에이전트(Agent)	목적별 서브에이전트에게 작업을 통째로 위임
MCP	노션·카카오 등 외부 도구를 통일 규격으로 연결

느낀 점 — 스킬·훅·에이전트·MCP가 따로 놀던 개념이었는데, 플러그인이라는 그릇에 한꺼번에 담아 배포할 수 있다는 걸 알고 나니 "내 워크플로 전체를 하나로 패키징한다"는 그림이 잡혔다. 마켓플레이스로 배포한다는 건, 결국 내가 만든 도구를 남도 쓸 수 있게 상품처럼 유통한다는 의미였다.

실제 배포 & 설치 방법

Claude Code의 마켓플레이스는 특별한 서버가 아니라 깃허브 저장소 하나다. 플러그인 파일과 marketplace.json을 담은 repo를 푸시하면 그 자체가 배포다. 오늘 만든 daily-log 플러그인을 yundlab/claude-marketplace 저장소에 올렸고, 다른 사람은 아래 두 줄로 바로 설치해 쓸 수 있다.

# 1) 마켓플레이스(깃허브 repo) 등록
/plugin marketplace add yundlab/claude-marketplace

# 2) 플러그인 설치
/plugin install daily-log@yundlab-marketplace

설치하면 /daily-log 스킬, journal-writer 에이전트, 노션 MCP 설정이 한꺼번에 딸려 온다. 사용 전 노션 Integration 토큰을 NOTION_TOKEN 환경변수로 넣어주면(setx NOTION_TOKEN "ntn_xxx") 준비 끝. 내가 만든 자동화를 명령어 두 줄로 남에게 그대로 넘길 수 있다는 게 신기했다.

MCP 연결 → 학습일지 자동화

마지막으로, 재시작된 세션에서 /mcp로 notion MCP가 초록불(연결됨)인지 확인한 뒤 /daily-log를 실행했다. 노션의 오늘 메모와 코드 변경을 읽어, 지금 보고 있는 이 학습일지 HTML을 자동으로 만들고 커밋까지 이어지는 흐름이다.

# MCP 연결 확인 → 자동화 스킬 실행
/mcp          # notion 초록불 확인
/daily-log    # 오늘 메모 + git 변경 → 학습일지 HTML 생성·커밋

오늘 배운 스킬 · 훅 · 에이전트 · MCP가 결국 이 /daily-log 한 줄에 전부 모여 있다. 노션 MCP로 메모를 읽고, 서브에이전트가 글을 쓰고, 스킬이 전체 절차를 묶고, 커밋 형식 검증 훅이 마지막을 지킨다 — 오늘 실습이 하나의 자동화로 합쳐지는 게 눈에 보였다.

✍️ 마치며

어제까지가 Claude Code를 "쓰는" 법이었다면, 오늘은 "뜯어고쳐 내 것으로 만드는" 법을 배웠다. 위험 명령을 직접 타이핑해야만 통과시키는 안전 가드 훅을 만들면서, AI에게 자율권을 주되 돌이킬 수 없는 순간엔 사람이 한 번 더 확인하게 만드는 하네스의 감각을 손으로 익혔다. 스킬·훅·에이전트·MCP를 플러그인으로 묶어 배포하고, 그 조합이 /daily-log 자동화로 합쳐지는 걸 보며 "도구를 만드는 사람"의 시야가 조금 열린 하루였다. 훅 실행이 느려 아쉬웠던 부분은, 다음에 더 가벼운 구조로 다시 확인해볼 생각이다.

[260723 18일차] Streamlit · Gradio · Claude Code

yundlab — Thu, 23 Jul 2026 16:05:11 +0900

# AI 웹앱 · 도구 학습일지

[Streamlit · Gradio · Claude Code]
Python 웹앱 만들기 + AI 코딩 CLI

2026.07.23 · 학습 범위: Streamlit, Gradio, Claude Code(로드맵 01~19)

오늘 다룬 것들

오늘은 "내가 만든 AI를 화면으로 보여주는" 하루였다. Python만으로 웹 대시보드를 만드는 Streamlit, 함수 하나로 웹앱을 뚝딱 만드는 Gradio로 CCTV 실시간 탐지·번역기·YOLO 탐지기를 웹으로 띄웠다. 그리고 지금 이 실습을 도와준 도구인 Claude Code(AI 코딩 CLI) 자체의 명령어·CLAUDE.md·프롬프트·협업까지 로드맵으로 정리했다.

Streamlit

st.emptycolumnsplotly

Gradio

gr.Interfacegr.Blockslaunch

웹앱 예제

CCTV 탐지번역기YOLO

Claude 명령어

/init@파일/model

CLAUDE.md

메모리@import200줄

프롬프트

위치지정역할단계분해

Streamlit — Python 대시보드

Streamlit은 Python만으로 웹 앱을 뚝딱 만드는 도구. HTML·CSS·JS를 몰라도 AI 데모·대시보드를 즉시 만들고, streamlit run 파일.py 한 줄로 브라우저에서 실행된다.

# 가상환경 활성화
conda activate pyweb310

# 설치
pip install streamlit
pip install ultralytics streamlit

# 실행
streamlit run v19_01_streamlit_b.py

함수	역할
`st.set_page_config()`	페이지 레이아웃·제목 설정(코드 최상단)
`st.empty()`	나중에 채울 빈 공간(placeholder) 예약
`st.columns(n)`	화면을 n개 컬럼으로 분할
`placeholder.image()`	예약 공간에 이미지(프레임) 갱신
`placeholder.plotly_chart()`	예약 공간에 Plotly 그래프 갱신

① 기본 CCTV 실시간 탐지

빈 액자(st.empty())를 만들어 두고, 루프에서 YOLO 탐지 결과를 그 액자에 한 장씩 덮어써 슬라이드 쇼처럼 실시간 영상을 보여준다.

import streamlit as st
from ultralytics import YOLO
import cv2

st.set_page_config(layout="wide")      # 넓게 (반드시 맨 위)
frame_placeholder = st.empty()          # 사진 갈아끼울 빈 액자
cap = cv2.VideoCapture(stream_url)
model = YOLO("yolo11n.pt")

while cap.isOpened():
    success, frame = cap.read()
    if not success: break
    annotated = model(frame)[0].plot()
    frame_placeholder.image(annotated, channels="BGR")  # 액자 갱신

set_page_config(layout="wide")는 반드시 코드 최상단에 있어야 동작한다. OpenCV는 색 순서가 BGR이라 channels="BGR"를 명시해야 Streamlit에서 색이 제대로 나온다. st.empty() placeholder를 루프에서 .image()로 계속 덮어써야 실시간 효과가 난다.

② 컬럼 레이아웃 + 실시간 그래프

화면을 좌우 2칸으로 쪼개 왼쪽엔 영상, 오른쪽엔 탐지 개수 막대 그래프를 동시에 갱신한다. Plotly로 종류별 개수를 매 프레임 다시 그린다.

col1, col2 = st.columns(2)          # 좌·우 2칸
with col1: frame_placeholder = st.empty()
with col2: chart_placeholder = st.empty()

@st.cache_resource                  # 무거운 모델은 1회만 로드
def load_model(): return YOLO("yolo11n.pt")
model = load_model()

# 탐지된 클래스 이름 모으기 → 개수 집계 → 막대그래프
labels = [model.names[int(c)] for c in results[0].boxes.cls]
df = pd.DataFrame({"Object": labels}).value_counts().reset_index(name="Count")
fig = px.bar(df, x="Object", y="Count", color="Object", text="Count")
chart_placeholder.plotly_chart(fig, key=f"chart_{time.time()}")

@st.cache_resource는 무거운 AI 모델을 딱 한 번만 불러온다(화면 조작으로 스크립트가 재실행돼도 캐시에서 즉시 반환 → 안 쓰면 매번 새로 읽어 느림). Plotly 차트는 매 프레임 key=f"chart_{time.time()}"로 고유 key를 줘야 위젯 충돌이 안 난다.

Gradio — 함수 하나로 웹앱

Gradio는 Python 함수만 있으면 웹 화면을 만들어주는 도구. HTML·CSS 없이 AI 데모를 만들고 launch(share=True)로 인터넷 주소까지 발급한다.

# 설치
pip install gradio deep-translator

⚠ import 하자마자 ImportError: numpy.core.multiarray failed to import가 나면 — gradio 잘못이 아니라 numpy 2 버전 충돌이다(numpy 2부터 numpy.core→numpy._core로 바뀜, 옛 pandas·matplotlib이 옛 이름을 부름). gradio는 내부에서 pandas를 불러오다 터지는 피해자. 해결: pip install -U pandas matplotlib로 최신판으로 갈아끼운다(numpy를 1.x로 내리는 건 비권장).

파라미터	역할	예시
`fn`	실행할 함수	`fn=say_hello`
`inputs`	입력 컴포넌트	`"text"`, `gr.Image(type="numpy")`
`outputs`	출력 컴포넌트	`"text"`, `gr.Image()`
`launch(share=True)`	공개 URL 생성(72시간)	—

① 기본 웹앱 (Hello)

함수 정의 → gr.Interface 연결 → launch 세 단계로 끝나는 가장 쉬운 첫 웹앱.

def say_hello(name):
    return "Hello, " + name

gr.Interface(fn=say_hello, inputs="text", outputs="text").launch(share=True)

② 번역 웹앱

구글 번역 라이브러리에 Gradio 화면만 입혀 5줄로 완성한 영한 번역기.

from deep_translator import GoogleTranslator
def trans_en_to_ko(text):
    return GoogleTranslator(source="en", target="ko").translate(text)

gr.Interface(fn=trans_en_to_ko, inputs="text", outputs="text",
             title="번역기", description="영어 → 한국어").launch()

③ YOLO 이미지 탐지

사진을 올리면 YOLO가 사물을 찾아 박스를 그려준다. gr.Image(type="numpy")로 이미지를 숫자 배열로 받아 모델에 바로 넘긴다.

def det_image(image):
    return model(image)[0].plot()

gr.Interface(fn=det_image, inputs=gr.Image(type="numpy"), outputs=gr.Image(),
             title="YOLO 이미지 객체 탐지").launch()

gr.Image(type="numpy") — type을 안 적으면 PIL 객체로 들어가 오류가 난다. YOLO엔 숫자 배열(numpy)로 넘겨야 한다. 출력의 gr.Image()는 배열도 자동으로 그림으로 표시한다.

④ gr.Blocks 통합 앱 (탭 3개)

인사·번역·YOLO를 탭 3개로 묶어 한 앱에 담았다. 함수는 그대로 두고 화면 짜는 부분만 gr.Blocks로 바꾼다.

with gr.Blocks() as gr_web:
    gr.Markdown("# 내가 만든 AI 앱 모음")
    with gr.Tab("번역"):
        en = gr.Textbox(label="영어")
        ko = gr.Textbox(label="한국어")
        gr.Button("번역").click(trans_en_to_ko, en, ko)  # (함수, 입력칸, 출력칸)
gr_web.launch()

비교	gr.Interface	gr.Blocks
화면	Gradio가 알아서	내가 쓴 순서대로 배치
기능 개수	1개	여러 개(탭·행·열)
실행 시점	입력하면 자동	`.click()`으로 내가 정함

자주 하는 실수 — 탭마다 칸 이름을 똑같이 지으면(name_box) 나중 것이 앞 것을 덮어써 엉뚱한 칸에 결과가 나온다. .click()은 칸을 만든 with 블록 안에, launch()는 with 밖에 둔다. 버튼만 만들고 .click()을 안 붙이면 눌러도 아무 일이 없다.

Claude Code — AI 코딩 CLI (로드맵 01~19)

Claude Code는 Anthropic이 만든 터미널용 AI 코딩 도구. 지금 이 정리도 Claude Code로 만들고 있어서, 도구 자체를 제대로 뜯어봤다.

# 01 설치 (Node.js 18+)
npm install -g @anthropic-ai/claude-code
claude --version   # 확인 후 claude 로 실행

02~03 · 명령어

세션 안에서 쓰는 슬래시 명령어. 새 프로젝트는 /init으로 시작한다.

명령어	설명
`/init`	CLAUDE.md 자동 생성(프로젝트 설정)
`/help` · `/clear`	도움말 · 대화 초기화
`/compact`	긴 대화 요약·압축(컨텍스트 절약)
`@파일`	특정 파일만 수정 지정(`@src/main.py`)
`!` prefix	터미널 명령 즉시 실행(`!ls -la`)
`/model` · `/btw`	모델 전환 · 작업 중단 없이 간단 질문

04 · 14 · 15 — 작동 모드 · 모델 · Effort

Shift+Tab으로 작동 모드 3가지를 순환한다: default(매번 확인) → auto(자동 수행) → plan(계획 먼저 작성 후 승인). 작업 성격에 따라 모델(Opus=복잡, Sonnet=일반, Haiku=빠름)과 Effort(low~max, 높을수록 깊은 사고·토큰↑)를 고른다.

고급 설정 — 자율권과 안전 — Claude에게 주는 자율권을 조절하는 장치다. 신입에게 "매번 확인받고 진행"시키다 신뢰가 쌓이면 "알아서 해"로 바꾸는 것과 같은데, 자율권 ↑ = 속도 ↑ = 위험 ↑이라 실수를 되돌리기 어려워진다. 극단이 claude --dangerously-skip-permissions(bypassPermissions) — 모든 작업을 확인 없이 자동 실행하므로 신뢰 가능한 격리 환경(도커·VM)에서만 써야 한다. "큰 힘에는 큰 책임이 따른다."

05 — 이미지 사용

스크린샷을 채팅창에 드롭하면 분석한다. "이 UI 오류 고쳐줘", "이 시안대로 HTML 만들어줘", "이 에러 원인이 뭐야?"처럼 화면을 그대로 넘길 수 있다.

06 · 07 — 용어

용어	설명
Context Window	AI가 한 번에 처리할 수 있는 최대 텍스트 길이
Token	텍스트 처리 최소 단위(약 0.75단어)
Hallucination	사실 아닌 내용을 자신 있게 생성하는 현상
MCP	USB-C처럼 통일 규격으로 외부 도구 연결

프롬프트 엔지니어링 vs 컨텍스트 엔지니어링 — 전자는 무엇을 물어볼지(질문·지시를 잘 쓰기), 후자는 어떤 정보를 줄지(CLAUDE.md·@파일로 대화에 담을 정보를 구성)에 집중한다.

08 — AI 도입 3단계 여정

새 도구를 채택할 때 누구나 거치는 과정(Mitchell Hashimoto): ① 비효율의 기간(기존보다 느리고 어색) → ② 적절성의 기간(비슷한 효율) → ③ 발견의 기간(워크플로가 바뀌는 생산성 도약).

하네스 엔지니어링 (Harness Engineering)

하네스(Harness)는 AI 에이전트가 오랜 시간 일할 때 방향을 잡아주고 실수를 감지하는 관리 기술이다. 마치 등산 안전줄처럼 — AI가 자유롭게 일하되, 위험한 순간엔 자동으로 제동이 걸리게 만드는 제어 시스템이다. 프롬프트/컨텍스트 엔지니어링이 "한 번의 요청을 잘 만드는" 것이라면, 하네스 엔지니어링은 "장시간 자율 실행되는 에이전트를 안전하게 굴리는" 상위 관점이다.

참고: Anthropic — Effective Harnesses for Long-Running Agents. 그리고 하네스 엔지니어링 이후, 요즘은 루프 엔지니어링(Loop Engineering)이라는 개념도 새로 등장했다. 에이전트가 관찰 → 행동 → 피드백을 반복하는 실행 루프 자체를 설계·최적화하는 접근으로, 언제 멈추고 언제 다시 시도할지, 어떤 신호로 루프를 조율할지에 초점을 둔다.

09 · 10 · 11 — CLAUDE.md 메모리

CLAUDE.md는 모든 세션 시작 시 자동으로 컨텍스트에 로드된다. 200줄 이하로 유지해야 지침 준수율이 높다. 초과 내용은 @import로 분리한다.

# CLAUDE.md 안에서 다른 파일 참조
@docs/git-instructions.md
@.claude/rules/testing.md

넣을 것 — 빌드·테스트·린트 명령, 코드 스타일, 브랜치 규칙. 뺄 것 — 코드 보면 아는 것, 자주 바뀌는 정보. 강조는 IMPORTANT·YOU MUST로. 개인 설정은 CLAUDE.local.md(gitignore), 팀 공유는 git 커밋.

12 · 13 · 16 — 프롬프트 잘 쓰는 법

1위치 지정"auth.js에서 비밀번호 찾기 버튼 오류 수정" — @파일로 콕 집기

2역할 명확화"당신은 시니어 백엔드 엔지니어, 성능 최적화 중심으로"

3금지사항 명시"새 패키지 추가 금지, 동작하는 기능은 건드리지 말 것"

4단계별 분해"분석 → 방법 설명 → 코드 작성 → 저장 순서로"

5검증 수단 제공"수정 후 자동 검사 돌려 기존 기능 문제없는지 확인"

# 구조화 템플릿
[ROLE: 시니어 백엔드 엔지니어]
[GOAL: 로그인 버그 수정]
[CONSTRAINTS: Python만, 새 패키지 금지]
[CONTEXT: auth.py 245번 줄 오류]
[QUESTION: 원인과 수정 방법은?]

17 — 세션 관리

종료했다 다시 시작해도 문맥을 유지한다. claude --resume으로 최근 세션 목록에서 골라 이어가거나, --continue로 최근 세션을 바로 잇는다.

18 · 19 — 스킬 & 협업

자주 쓰는 작업을 .claude/skills/이름.md에 저장하면 /이름으로 바로 실행하는 나만의 슬래시 명령어가 된다. 나아가 Claude App + Chrome 확장 + MCP를 연결하면 "뉴스 요약해서 카톡으로 보내줘" 같은 복합 자동화도 가능하다.

# .claude/skills/translate-ko.md → /translate-ko 로 실행
주어진 텍스트를 자연스러운 한국어로 번역합니다.
- 구어체보다 문어체 우선
- 전문 용어는 원문 병기

직접 스킬 만들기 실습 — 이론만 보지 않고, .claude/skills/ 폴더에 이름.md 파일을 만들어 작업 지시를 적고 /이름으로 실행되는 나만의 스킬을 직접 만들어봤다. 자주 반복하는 프롬프트를 한 번 스킬로 굳혀 두니, 다음부턴 명령어 하나로 똑같은 작업을 재현할 수 있어서 편했다.

스킬도 사고판다 — 잘 만든 스킬은 상품이 되기도 한다. skills.ag 같은 마켓에서는 검증된 AI 에이전트 스킬을 판매·구매한다. "반복 작업을 절차적 지식으로 굳혀 재사용한다"는 스킬의 개념이, 이제 하나의 생태계·시장으로 커지고 있다는 게 인상적이었다.

✍️ 마치며

Streamlit·Gradio를 보면서 "AI 모델을 만드는 것"과 "그걸 사람이 쓰게 만드는 것"은 다른 일이라는 걸 느꼈다. 함수 하나에 gr.Interface 몇 줄만 붙여도 친구에게 링크로 보낼 수 있는 웹앱이 된다는 게 특히 인상적이었다. 그리고 그동안 무심코 써온 Claude Code 자체를 뜯어보니, 결국 핵심은 "무엇을 시키느냐(프롬프트)"보다 "어떤 맥락을 주느냐(CLAUDE.md·@파일)"라는 컨텍스트 엔지니어링이었다. 도구를 아는 만큼 더 잘 쓸 수 있다는 걸 체감한 하루였다. 다음엔 만든 앱들을 실제로 배포해 링크로 공유해볼 생각이다.

[260722 17일차] OpenAPI · HuggingFace · Transformers · OCR

yundlab — Wed, 22 Jul 2026 17:28:14 +0900

# AI 활용 학습일지

[OpenAPI · HuggingFace · Transformers · OCR]
공공 API · LLM · NLP · 문자 인식

2026.07.22 · 학습 범위: 공공 OpenAPI(ITS CCTV), HuggingFace, Transformers, OCR

오늘 다룬 것들

오늘은 "이미 만들어진 AI·데이터를 가져다 쓰는" 하루였다. 공공기관의 OpenAPI로 전국 CCTV 영상을 받아 YOLO로 분석하고, HuggingFace로 LLM 채팅과 이미지 생성을, Transformers로 문장 유사도·감정분석·요약·번역을, 마지막으로 OCR로 이미지 속 글자까지 뽑아봤다. 모델을 직접 학습하지 않아도 API·라이브러리 몇 줄로 이만한 걸 한다는 게 신기했다.

공공 API

apiKeyurllibjson_normalize

LLM 채팅

InferenceClientDeepSeek

이미지 생성

FLUX.1text_to_image

NLP

pipeline유사도감정분석

요약·번역

t5-smalldeep_translator

문자 인식

Tesseractpytesseract

공공 OpenAPI — ITS CCTV

OpenAPI는 정부·공공기관 데이터 창고의 자동문 같은 것. 사람이 직접 가지 않고 프로그램이 인증키(열쇠)를 들고 필요한 데이터만 꺼내온다. 오늘은 국토교통부 ITS(지능형교통시스템)에서 전국 도로 CCTV 영상 주소를 받아왔다.

# 설치 (urllib·json은 파이썬 기본 내장)
pip install pandas ultralytics opencv-python

곁들여 배운 개념 — MCP — AI에 새 능력을 더해주는 "USB-C 같은 약속". 도구마다 다른 연결 방식을 하나의 표준으로 통일한 것으로, AI가 혼자 모르는 것도 도구(기상청·노션·캘린더 등)를 꽂으면 진짜 정보를 가져와 할루시네이션(그럴듯한 거짓말)을 줄인다. OpenAPI가 "데이터를 직접 호출"하는 방식이라면, MCP는 그걸 AI가 알아서 쓰게 연결하는 상위 개념.

① API 키 · 요청 URL

인증키를 발급받고, 도로 유형(its 일반 / ex 고속)·관심 영역(경위도 범위)·응답 형식(json)을 붙여 요청 URL을 조립한다.

url_cctv = (
    f"https://openapi.its.go.kr:9443/cctvInfo"
    f"?apiKey={key}&type={Type}&cctvType=1"
    f"&minX={minX}&maxX={maxX}&minY={minY}&maxY={maxY}"
    f"&getType={getType}"
)

② 응답 처리 (urllib → JSON → DataFrame)

URL로 요청을 보내 받은 응답을 bytes → str → dict → 표(DataFrame) 순으로 가공한 뒤, 원하는 CCTV의 스트림 주소를 골라낸다.

response = urllib.request.urlopen(url_cctv)          # 요청 → 응답
json_str = response.read().decode("utf-8")         # bytes → str
json_object = json.loads(json_str)                  # str → dict
cctv_play = pd.json_normalize(json_object["response"]["data"])  # dict → 표
test_url = cctv_play["cctvurl"][77]                   # 77번 CCTV 선택

왜 두 번 변환? — 서버는 전송용 bytes(0·1)로 보내니 사람이 읽으려면 decode로 str(글자)로 풀고, 값을 꺼내려면 json.loads로 dict(사전)로 바꿔야 ["키"]로 접근된다. CCTV 목록이 response → data 안에 숨어 있어서 pd.json_normalize로 평평한 표로 펴 인덱싱했다.

③ 함수화 + YOLO 통합

반복되는 API 호출을 its_cctv(번호) 함수로 묶으니, 다른 파일에서 import 한 줄로 CCTV 주소를 얻어 바로 YOLO에 연결할 수 있었다.

from v15_03_cctv_its_def import its_cctv  # 만들어 둔 함수 재사용

test_url = its_cctv(50)              # 17줄 코드가 1줄로
cap = cv2.VideoCapture(test_url)
model = YOLO("yolo11n.pt")
# while 루프에서 프레임마다 model(frame)로 실시간 탐지

함수화의 장점 — 재사용(import 한 줄), 매개변수(번호만 바꿔 다른 CCTV), 가독성(메인 로직에서 API 세부 숨김), 유지보수(주소·키 바뀌면 함수 1곳만 수정). 참고로 알라딘·기상청·카카오·네이버도 같은 방식(키 발급 → URL/헤더에 담아 요청 → JSON 파싱)으로 쓴다.

HuggingFace — LLM · 이미지 생성

HuggingFace는 전 세계 AI 모델·데이터셋을 무료 공유하는 최대 허브. InferenceClient 한 줄로 GPT급 LLM이나 이미지 생성 모델을 바로 호출할 수 있다.

pip install huggingface_hub   # HuggingFace 공식 SDK → InferenceClient·model_info·login 등 일체 제공

토큰은 .env에 — HuggingFace 토큰은 절대 코드·주석에 직접 쓰지 말고 .env(gitignore됨)에 저장한다. load_dotenv()로 읽어 os.environ["HF_TOKEN"]으로 꺼내 쓴다. 키가 코드에 박히면 GitHub에 그대로 노출된다.

① LLM 채팅 (DeepSeek)

chat.completions.create로 DeepSeek 모델에 질문을 보낸다. ChatGPT와 동일한 messages(role + content) 패턴이다.

client = InferenceClient(provider="auto", api_key=os.environ['HF_TOKEN'])
completion = client.chat.completions.create(
    model="deepseek-ai/DeepSeek-V3.2:novita",  # :novita → 무료 라우팅
    messages=[{"role": "user", "content": answer}],
)
print(completion.choices[0].message)   # 후보 중 첫 응답

provider="auto"는 가장 빠른 무료 서버를 자동 선택. LLM은 단일 질문이 아니라 대화 이력(messages 리스트)을 입력받고, 답은 후보 N개 중 choices[0].message로 꺼낸다.

② 이미지 생성 (Text-to-Image, FLUX)

텍스트 설명을 주면 FLUX.1-dev가 그림을 그려 PIL.Image 객체로 돌려준다. 그대로 .save()하면 파일로 저장된다.

image = client.text_to_image(answer, model="black-forest-labs/FLUX.1-dev")
image.save("tti_result.jpg")

프롬프트는 영어로 쓰면 품질이 오른다. 스타일 키워드(anime style, photorealistic)와 품질 키워드(high quality, 4K, detailed)를 붙이면 좋다. 무료 서버 기준 1회 1~3분 걸린다.

Transformers — 자연어 처리(NLP)

pipeline은 모델 로드 + 토크나이저 + 후처리를 한 줄로 묶어주는 진입점. 태스크 이름만 주면 알맞은 모델을 자동으로 붙여준다.

pip install transformers
pip install -U "transformers==4.46.3"
pip install deep-translator

① 문장 유사도 (SentenceTransformer · 코사인)

문장을 임베딩(숫자 벡터)으로 바꾸고, 두 벡터 사잇각의 코사인 유사도로 의미가 얼마나 비슷한지 수치화한다. 단어가 달라도 의미가 같으면 1에 가깝다.

pip install sentence-transformers   # 문장 임베딩 전용 패키지

model = SentenceTransformer("all-MiniLM-L6-v2")   # 경량 임베딩 모델
emb1 = model.encode(sen1, convert_to_tensor=True)
emb2 = model.encode(sen2, convert_to_tensor=True)
cos_sim = util.pytorch_cos_sim(emb1, emb2)
# -1 반대 · 0 무관 · 1 완전히 동일

임베딩 = 문장을 의미 좌표로 — "강아지"와 "개"는 가까운 점, "강아지"와 "비행기"는 먼 점이 된다. 코사인 유사도는 두 화살표의 각도만 보므로(길이 무시) 문장 길이에 영향받지 않는다. 실제로 어순만 다른 문장은 0.94, 무관한 문장은 0.15가 나왔다.

② 감정 분석 (Sentiment)

영어 문장을 POSITIVE / NEGATIVE로 판별하고 신뢰도(0~1)를 준다.

classifier = pipeline("sentiment-analysis")
results = classifier("I feel calm")
print(results[0]['label'], results[0]['score'])  # POSITIVE 0.8280

score는 softmax를 통과한 확률값(모든 값 합=1)이라 "확신도"로 읽을 수 있다. 단, 기본 모델은 영어 전용이고 중립·복합 감정은 잘 못 잡는 한계가 있다.

③ 텍스트 생성 (GPT-2 / KoGPT2)

시드 문장을 주면 뒤 단어를 한 토큰씩 예측해 이어붙인다. 한국어는 skt/kogpt2-base-v2를 썼다.

generator = pipeline("text-generation", model="skt/kogpt2-base-v2")
results = generator(answer, max_new_tokens=50, num_return_sequences=1, truncation=True)

max_new_tokens는 생성 길이 상한(안 주면 무한 생성 위험), truncation=True는 입력이 모델 최대 길이를 넘으면 잘라준다. (1 토큰 ≈ 영어 4글자)

④ 요약 (T5-small)

긴 영어 단락을 핵심만 뽑아 다시 쓴다. T5는 모든 작업을 "텍스트 → 텍스트"로 통일한 모델이다.

summarizer = pipeline("summarization", model="t5-small")
summary = summarizer(text, min_length=20, max_length=60, do_sample=False)
print(summary[0]['summary_text'])

Task Prefix — T5는 "summarize: 원문"·"translate English to Korean: ..."처럼 앞머리(접두사)로 작업을 지시받게 학습됐다. 한 모델로 요약·번역·분류가 다 되는 비결. pipeline("summarization")이 "summarize: "를 자동으로 붙여준다. do_sample=False는 매번 같은 결과(결정적 생성).

⑤ 요약 + 한국어 번역

T5는 영어만 잘하니, 요약(영어) 결과를 deep_translator의 GoogleTranslator로 한국어로 옮겨 한계를 보완했다(API 키 불필요).

from deep_translator import GoogleTranslator

def translate_ko(sentence):
    return GoogleTranslator(source='en', target='ko').translate(sentence)

ko_sum = translate_ko(sum_text)   # 영어 요약 → 한국어

파이프라인 흐름: 원문(영) → T5 요약 → 요약(영) → GoogleTranslator → 요약(한). 무료·키 불필요·다국어라 편했지만, 인터넷이 필요하고 호출이 많으면 차단될 수 있다.

OCR — 이미지 속 글자 읽기

OCR(광학 문자 인식)은 사진 속 글자를 읽어내는 기술. 구글 Tesseract 엔진을 파이썬 pytesseract로 감싸 사용한다.

① OCR 개요 & 설치

설치 순서 — ① Tesseract 실행 파일 설치 → ② Python 라이브러리 설치 → ③ 실행 파일 경로 지정

# ① Tesseract-OCR 설치 (Windows)
# 공식 설치 경로: https://github.com/UB-Mannheim/tesseract/wiki
# 설치 후 기본 경로: C:/Program Files/Tesseract-OCR/tesseract.exe
# (한국어 인식은 설치 시 Korean 언어팩 체크)

# ② Python 라이브러리 설치
pip install pytesseract pillow

pytesseract — 파이썬에서 Tesseract를 부르는 통역사. PIL(pillow) — 사진 파일을 여닫는 파이썬 이미지 도구.

② 이미지 텍스트 인식 (v18_01_ocr_img.py)

PIL로 사진을 열고 image_to_string으로 글자를 뽑아내는 4단계 흐름이다.

1경로 지정tesseract_cmd로 Tesseract 실행 파일 위치 알려주기

2이미지 열기Image.open(경로)로 사진 파일 불러오기

3OCR 수행image_to_string(image, lang)으로 글자 추출

4결과 출력추출된 문자열 print

import pytesseract
from PIL import Image
import os

# 1. Tesseract 실행 파일 경로 지정
pytesseract.pytesseract.tesseract_cmd = "C:/Program Files/Tesseract-OCR/tesseract.exe"

# 2. 이미지 불러오기
image = Image.open("image.png")

# 3. OCR 수행
results = pytesseract.image_to_string(image, lang='eng')

# 4. 결과 출력
print(results)
# Optical Character
# Recognition (OCR)

핵심 함수
· pytesseract.tesseract_cmd — Tesseract 실행 파일 위치 알려주기
· Image.open(경로) — PIL로 사진 파일 열기
· image_to_string(image, lang) — 사진에서 글자 뽑아 문자열로 반환
· lang='eng' — OCR이 쓸 언어 지정 (언어팩 설치 필수)

③ lang 파라미터 & 결과 해석

lang은 OCR에게 읽을 언어를 알려주는 값. +로 여러 언어를 동시에 인식할 수 있다(예: eng+kor).

lang 값	설명	예시 코드
`eng`	영어 (기본값, 별도 설치 없이 사용 가능)	`lang='eng'`
`kor`	한국어 (언어팩 별도 설치 필요)	`lang='kor'`
`eng+kor`	영어 + 한국어 동시 인식	`lang='eng+kor'`
`chi_sim`	중국어 간체	`lang='chi_sim'`
`jpn`	일본어	`lang='jpn'`

# 영어 + 한국어 동시 인식
results = pytesseract.image_to_string(image, lang='eng+kor')
print(results)

· 결과에 줄바꿈(\n)이 포함됨 → .strip()으로 공백 제거
· 사진 해상도가 낮거나 글꼴이 특수하면 인식률 저하 → 전처리(흑백 변환·크기 조정)로 개선
· tesseract_cmd로 엔진 실행 파일 위치를 먼저 지정해야 함(설치 필수)
· 더 똑똑한 대안: 딥러닝 기반 EasyOCR · PaddleOCR

✍️ 마치며

오늘은 "밑바닥부터 만들기"가 아니라 "잘 만들어진 걸 조립하기"의 힘을 느낀 하루였다. 공공 API로 실시간 데이터를 끌어오고, HuggingFace·Transformers로 남이 학습해 둔 거대 모델을 몇 줄로 불러 쓰고, OCR로 이미지를 텍스트로 바꾸는 것까지 — 결국 중요한 건 각 도구의 입력·출력 형태(JSON 파싱, messages 리스트, 임베딩 벡터, lang 옵션)를 이해하고 이어 붙이는 감각이었다. .env로 키를 안전하게 관리하는 습관도 오늘 확실히 챙겼다. 다음엔 이 조각들을 엮어 작은 AI 서비스를 만들어볼 생각이다.

[260721 16일차] YOLO 심화

yundlab — Wed, 22 Jul 2026 16:46:26 +0900

# YOLO 학습일지

[YOLO 심화] 히트맵·보안·카운팅
+ SAHI·속도추정·FastSAM

2026.07.21 · 학습 범위: YOLO 심화 02~19 (solutions · SAHI · FastSAM · OpenVINO)

오늘 다룬 것들

어제 추적(Tracking)에 이어, 오늘은 YOLO를 감싼 ultralytics solutions 모듈을 파고들었다. 코드 몇 줄로 히트맵·보안 알람·블러·거리 측정·영역/출입 카운팅·속도 추정 같은 실전 기능이 뚝딱 나온다는 게 놀라웠다. 후반엔 작은 물체를 놓치지 않는 SAHI, 텍스트로 물체를 잘라내는 FastSAM까지 다뤘다. 라이브러리가 얼마나 많은 걸 대신해 주는지 체감한 하루였다.

실시간 분석

HeatmapSecurityAlarmObjectBlurrer

거리·영역

DistanceRegionCounterObjectCounter

작은 물체

SAHI슬라이싱

속도 · 분할

SpeedEstimatorFastSAM

환경

conda py39pip sahi

공통 패턴

solutions(frame).plot_im

ultralytics.solutions 클래스 모음

from ultralytics import solutions 하나로 실전 기능들이 클래스로 들어 있다. 오늘은 이 중 여러 개를 직접 써봤다.

✓Heatmap물체가 자주 나타난 곳을 열지도로 시각화 (오늘)

✓SecurityAlarm특정 클래스 감지 시 이메일 알림 (오늘)

✓ObjectBlurrer탐지 영역만 자동 블러 (오늘)

✓DistanceCalculation두 객체 중심점 사이 픽셀 거리 (오늘)

✓RegionCounter다각형 영역 안 객체 수 집계 (오늘)

✓ObjectCounter선을 넘는 IN/OUT 카운팅 (오늘)

✓SpeedEstimator차량 등 이동 속도(km/h) 추정 (오늘)

·AIGym운동 자세·반복 횟수 카운팅

·Analytics탐지 결과를 그래프로 통계화

·ObjectCropper탐지 영역만 잘라 저장

·ParkingManagement주차 구역 점유 관리

·QueueManager대기열 인원 관리

·TrackZone특정 구역 안에서만 추적

·VisionEye시점 기반 객체 매핑

·SearchApp / Inference이미지 검색 · Streamlit 추론 UI

공통 사용 패턴 — 오늘 계속 나온 형태 — solutions 객체는 일반 추론(model())과 조금 다르다. 프레임을 직접 넣어 호출하고(results = 객체(frame)), 결과가 그려진 이미지는 results[0].plot()이 아니라 results.plot_im으로 꺼낸다. show=True면 창을 알아서 띄우고, show=False면 cv2.imshow(..., results.plot_im)으로 직접 띄운다.

실시간 분석 솔루션

02 — 히트맵 (Heatmap)

물체가 자주 지나간 곳을 빨강(자주)~파랑(드묾) 열지도로 누적 시각화한다. 매장 동선 분석 등에 쓴다.

heatmap = solutions.Heatmap(
    model="yolo11n.pt",
    colormap=cv2.COLORMAP_MAGMA   # 색상 지도(MAGMA=보라~노랑)
)
results = heatmap(frame)
cv2.imshow("HEATMAP", results.plot_im)  # 누적 결과

03 — 보안 알람 (SecurityAlarm)

특정 클래스(예: 자동차)가 감지되면 이메일을 자동 발송한다. 탐지 → 추적 → 누적 카운트 → SMTP 메일 발송이 내부에서 한 번에 처리된다.

alarm = solutions.SecurityAlarm(
    model="yolo11n.pt", show=False,
    records=2,       # N회 감지 시 1회 메일(오탐 방지)
    classes=[2]      # 2 = car
)
alarm.authenticate(from_email, password, to_email)  # SMTP 로그인
results = alarm(frame)

Gmail 앱 비밀번호 필수 — 2단계 인증을 켠 뒤 앱 비밀번호(16자리)를 발급받아 password에 넣어야 한다. 일반 로그인 비밀번호로는 SMTP 인증이 막힌다. 실무에선 비밀번호를 코드에 직접 쓰지 말고 환경변수로 분리하는 게 안전하다.

04 — 블러 (ObjectBlurrer)

방송의 모자이크처럼, 탐지된 물체 영역만 골라 자동으로 흐리게 처리한다. 좌표를 직접 계산할 필요가 없다.

blurrer = solutions.ObjectBlurrer(
    model="yolo11n.pt", show=False,
    blur_ratio=0.5   # 0.1~1.0, 높을수록 더 흐림
)
results = blurrer(frame)
cv2.imshow("BLUR", results.plot_im)

거리 · 영역 · 출입

05 — 거리 계산 (DistanceCalculation)

영상 위에서 마우스로 객체 2개를 클릭하면 두 중심점 사이의 픽셀 거리를 실시간으로 잰다.

distance = solutions.DistanceCalculation(model="yolo11n.pt", show=True)
distance(frame)  # 좌클릭 2회로 대상 선택 → 거리 표시

06 — 거리 상태 분류 (실습)

거리 값을 꺼내 신호등처럼 안전/경고/위험으로 분류하는 실습. 여기서 solutions 객체를 process()로 호출하면 결과 객체가 나오고, 거기서 pixels_distance를 꺼낼 수 있다는 걸 배웠다.

results = distance.process(frame)         # 결과 객체 반환
d = results.pixels_distance               # 두 점 사이 픽셀 거리

if d is None or d == 0:
    print("입력 안됨"); continue   # 아직 선택 전
elif d >= 150: status = "Safe"
elif d >= 100: status = "Warning"
else:          status = "Danger"

distance(frame) vs distance.process(frame) — 앞엣것은 화면에 그려 주기만 하고, 뒤엣것은 결과 객체를 돌려줘 pixels_distance 같은 값을 코드로 꺼내 조건 분기에 쓸 수 있다. 상태를 판단해야 하니 process()를 썼다. 임계값(150·100)은 카메라 위치·줌에 따라 달라져 직접 보정해야 한다.

07 — 영역 카운팅 (RegionCounter)

다각형 영역(4점)을 정의하고, 그 안에 들어온 객체만 센다. 좌표는 화면 해상도에 맞춰야 해서 프레임을 640×480으로 통일했다.

region_points = { "region-01": [(179,114), (173,466), (636,359), (217,133)] }
region = solutions.RegionCounter(
    model="yolo11n.pt", show=False,
    region=region_points, conf=0.4   # CCTV 저화질 대응
)
re_frame = cv2.resize(frame, (640, 480))  # 좌표계 통일 필수
results = region(re_frame)

08 — 마우스로 영역 좌표 추출 (get_region)

영역 좌표를 코드에 하드코딩하지 않고, 화면을 클릭해서 좌표를 뽑는 방법. setMouseCallback에 콜백을 연결해 좌클릭한 (x, y)를 리스트에 모은다.

points = []
def mouse_callback(event, x, y, flags, param):
    if event == cv2.EVENT_LBUTTONDOWN:   # 좌클릭 감지
        points.append((x, y))
        print(f"클릭 좌표: {x, y}")

cv2.namedWindow("GET_X_Y", cv2.WINDOW_NORMAL)
cv2.setMouseCallback("GET_X_Y", mouse_callback)
# 좌상단→좌하단→우하단→우상단 순서로 4점 클릭 → region_points로 복사

콜백 인자 5개는 순서 고정 — event(무슨 일)·x, y(어디)·flags(같이 누른 키)·param(밖에서 넘긴 값). 안 써도 자리는 비워두면 안 된다(OpenCV 호출 규칙). 그리고 좌표 측정 창과 실제 카운팅 코드의 resize 크기가 같아야(640×480) 영역이 안 어긋난다.

09 — 출입 카운팅 (ObjectCounter)

화면에 선(2점)을 긋고 그 선을 넘는 사람·차를 세어 IN/OUT을 집계한다. 4점을 주면 RegionCounter처럼, 2점을 주면 선 카운터로 동작한다.

count_points = [(231,465), (637,418)]  # 점 2개 = 선 1개
counter = solutions.ObjectCounter(
    model="yolo11n.pt", show=False,
    region=count_points
)
results = counter(re_frame)  # 탐지+추적+선통과+IN/OUT 한 번에

선은 사람 다니는 길에 직각으로 그어야 잘 세고, IN/OUT이 반대로 나오면 두 점의 순서만 바꾸면 된다. 같은 사람은 처음 넘는 순간 한 번만 카운트된다(내부에서 ID로 잠금).

SAHI · 속도 · FastSAM

환경 준비 — SAHI는 별도 가상환경에서 실습했다. conda activate py39로 Python 3.9 환경에 들어가 pip install sahi로 설치. (버전 호환 때문에 전용 환경을 쓰는 게 편했다.)

10 — SAHI 데이터 준비

멀리 있는 작은 차·사람은 일반 YOLO가 잘 못 본다. SAHI로 해결하는데, 먼저 테스트용 이미지를 내려받았다.

from sahi.utils.file import download_from_url

download_from_url(
    ".../demo_data/small-vehicles1.jpeg",  # 작은 차량
    "demo_data/small-vehicles1.jpeg",
)

11 — SAHI 기본 추론 (비교용)

사진을 통째로 한 번 추론해 탐지 개수를 세어 둔다. 이 숫자를 다음 슬라이싱 결과와 비교하면 SAHI 효과가 한눈에 보인다.

model = YOLO("yolo11n.pt")
results = model("demo_data/image_1.png")
detected = len(results[0].boxes)   # 탐지 수 기억!
print(f"탐지수 : {detected}")

12 — SAHI 슬라이싱 추론

사진을 작은 타일(200×200)로 잘라 각 조각마다 추론한 뒤 결과를 합친다. 큰 그림을 돋보기로 한 칸씩 보는 셈이라 작은 물체 탐지가 확 늘어난다.

from sahi.predict import get_sliced_prediction
from sahi import AutoDetectionModel

det_model = AutoDetectionModel.from_pretrained(
    model_type="ultralytics", model_path="yolo11n.pt",
    confidence_threshold=0.4
)
results = get_sliced_prediction(
    "demo_data/image_1.png", det_model,
    slice_width=200, slice_height=200,      # 타일 크기
    overlap_width_ratio=0.1, overlap_height_ratio=0.1  # 경계 10% 겹침
)
results.export_visuals(export_dir="sahi/")

타일을 작게 할수록 더 작은 물체를 잡지만 타일 수가 늘어 처리 시간이 증가한다(트레이드오프). 경계에 걸친 물체를 놓치지 않도록 overlap을 10~20% 준다.

13 — 속도 추정 (SpeedEstimator)

실시간 CCTV에서 차량 속도를 km/h로 추정한다. 핵심은 픽셀을 실제 거리로 바꾸는 meter_per_pixel 보정값.

speed = solutions.SpeedEstimator(
    model="yolo11n.pt", show=False,
    classes=[2],            # car만
    max_speed=120,          # 상한 km/h
    meter_per_pixel=0.5     # 1픽셀 = 0.5m (환경별 보정 필수)
)
results = speed(frame)
cv2.imshow("Speed", results.plot_im)

meter_per_pixel은 화면 1픽셀이 실제 몇 m인지의 환산 계수다. 도로 점선 한 칸(3m)이 화면에서 6픽셀이면 3 ÷ 6 = 0.5. 카메라 높이·각도·렌즈마다 달라서 직접 측정해야 하고, 원근 왜곡 때문에 도로 면 근처에서 재야 정확하다.

15 — FastSAM (텍스트로 잘라내기)

SAM(Segment Anything)은 학습 없이 모든 물체를 분할하지만 무겁다. FastSAM은 그걸 YOLO 골격으로 갈아 끼워 훨씬 빠르게 만들고, "cat"처럼 텍스트 한 단어로 원하는 물체만 콕 집어 잘라낸다.

from ultralytics import FastSAM

model = FastSAM("FastSAM-s.pt")          # s=소형·빠름
results = model("img_cat.jpg", texts="cat") # "cat"만 분할
cv2.imwrite("result.jpg", results[0].plot())

SAM은 "모든 물체"를 다 자르고, FastSAM은 "말로 시킨 것만" 빠르게 자른다. (실습 땐 인증서 오류가 나서 ssl·CA_BUNDLE 관련 설정으로 다운로드를 우회했다.)

⚡ 모델 최적화 · 웹 UI

16 — OpenVINO 변환

OpenVINO는 Intel이 만든 CPU 전용 부스터. PyTorch .pt 모델을 변환하면 GPU 없이 CPU만으로도 2~3배 빠른 추론이 가능하다.

model = YOLO("yolo11n.pt")
model.export(format="openvino")   # → yolo11n_openvino_model/ 폴더 생성

format은 "openvino" 외에 "onnx"·"tensorrt" 등도 된다. GPU가 없는 노트북에서 빠르게 돌리고 싶을 때 변환이 유용하다.

17 — PT vs OpenVINO FPS 비교

FPS(초당 프레임 수)로 원본과 변환본의 속도를 겨뤄봤다. 한 프레임 추론에 걸린 시간을 재서 1초로 나누면 FPS가 나온다.

start = time.time()
results = model(frame, verbose=False)
fps = 1 / (time.time() - start)   # 1초 ÷ 1장 걸린 시간
cv2.putText(annotated, f"{fps:.1f} FPS", (10,30), cv2.FONT_HERSHEY_SIMPLEX, 1, (0,255,0), 2)

모델만 yolo11n.pt ↔ yolo11n_openvino_model/로 바꿔 같은 코드로 비교한다. CPU 환경일수록 OpenVINO 효과가 커서 보통 2~3배 빨라진다. verbose=False는 콘솔 로그를 꺼 측정을 깔끔하게 하려는 용도.

18 — 이미지 검색 (SearchApp)

"내 사진첩 전용 구글". 폴더를 주면 "cat" 같은 단어로 비슷한 이미지를 찾아주는 웹앱이다. 내부에 CLIP 임베딩 + FAISS 인덱스가 들어 있어 "비슷한 그림" 찾기가 된다.

app = solutions.SearchApp(
    data="demo_data",   # 검색 대상 이미지 폴더
    device="cpu"          # GPU면 "cuda"
)
app.run(debug=False)     # 브라우저에서 자동 오픈

Flask 앱이라 python 파일.py로 실행한다(streamlit run 쓰면 오류). 여기서도 HuggingFace 모델 다운로드 인증서 문제로 ssl·CA_BUNDLE을 우회 설정했다.

19 — Streamlit 추론 UI

코드 두 줄로 뜨는 YOLO 대시보드. 모델 선택·웹캠 입력·결과 표시를 solutions.Inference가 알아서 그려준다.

inf = solutions.Inference(model="yolo11n.pt")
inf.inference()   # 실행: streamlit run 파일.py

STEP 18 SearchApp이 "이미지 검색"이라면, Inference는 "실시간 객체 탐지 UI". 실행 명령이 python이 아니라 streamlit run이라는 점만 주의하면 된다.

✍️ 마치며

어제까지는 "YOLO로 박스 그리기"였는데, 오늘 solutions를 보니 히트맵·알람·카운팅·속도까지 실제 서비스에 쓸 법한 기능이 이미 클래스로 다 만들어져 있었다. 결국 중요한 건 각 클래스가 어떤 입력(영역 좌표·이메일·보정값)을 필요로 하는지, 그리고 결과를 results.plot_im·process()로 어떻게 꺼내 쓰는지를 아는 것이었다. SAHI의 "잘라서 보기"나 FastSAM의 "말로 자르기"처럼, 문제를 바라보는 관점 자체가 새로워서 재미있었다. 마지막엔 OpenVINO로 속도를 끌어올리고 SearchApp·Streamlit으로 웹 UI까지 붙여봤다. 다음엔 SAM 본체와 직접 모은 데이터로 커스텀 학습을 이어서 해볼 예정이다.

yundlab 님의 블로그

[260803 25일차] 프로젝트 #6

[프로젝트 6일차] 2주차 시작 · 화면 설계+ 요구사항·ERD 정합성 검토 · Pulse UI 조립

오늘 다룬 것들

오전 공지 — 2주차 킥오프

‍ 팀장 멘토링 (13:00~13:30)

프론트엔드 역할 분담 재편 — 3축 구조

요구사항 명세서 · ERD 정합성 검토

내가 한 일 — Pulse: 디자인 토큰에서 화면 조립까지

1. 시작점의 착각 — "컴포넌트가 너무 적은데?"

2. 만든 컴포넌트

3. 완성한 화면

4. 하면서 내린 판단들

5. Figma 삽질 기록

6. 토큰을 정해놓고도 안 지키게 되는 순간

7. 남은 일

✍️ 마치며

[260731 24일차] 프로젝트 #5

[프로젝트 5일차] Figma UI · 머지 정책 확정+ ERD id 타입 결정 · JWT 저장 전략

오늘 다룬 것들

내가 한 일 — Figma UI

오전 공지 — 산출물·협업 규칙 확정

‍ 팀장 멘토링 — 발표·주간 도구 주제

주간 미니 프로젝트 주제

기술 결정 — ERD id 타입 & BE 머지 규칙

BE 브랜치 머지 설정

개념 정리 — JWT를 어디에 저장할까 (HttpOnly 쿠키 vs 헤더 vs localStorage)

주간 미니 프로젝트 발표 — meeting-notes

사용 기술

✍️ 마치며

[260730 23일차] 프로젝트 #4

[프로젝트 4일차] 와이어프레임·디자인 시스템+ Git 머지 정책 · 산출물 범위 확정

오늘 다룬 것들

내가 한 일 — 화면 기반 잡기

오전 회의 — 산출물 범위 & 일정

오후 회의 — Git 머지 정책 & PR 템플릿

개념 정리 — Merge 방식 3가지 (Merge / Squash / Rebase)

주간 미니 프로젝트 — 회의록 시스템

‍ 오늘의 코드 리뷰 — 접었다 펴는 UI는 div가 아니라 details/summary다 (HTML 3일차)

❌ 문제 코드 (전체)

✅ 정답 (수정 부분)

확인 방법

✍️ 마치며

[260729 22일차] 프로젝트 #3

[프로젝트 3일차] 컨벤션 병합 · 레포 설정+ 기획서·WBS·요구사항·ERD 작성

오늘 다룬 것들

오전 회의 — 협업 규칙 확정

주간 미션 공유

CLAUDE.md 병합 협의

GitHub 레포 기본 설정

프로젝트 기획서

결정 사항 · 액션 아이템

내가 한 일 — 기획 문서 4종

‍ 오늘의 코드 리뷰 — 폼 값은 name 이 있어야 전송된다 (HTML 2일차)

❌ 문제 코드 (전체)

✅ 정답 (수정 부분)

확인 방법

✍️ 마치며

[260728 21일차] 프로젝트 #2

[프로젝트 2일차] 주제 선정 · 회의록 시스템 미션Git 전략 · 하네스 엔지니어링

오늘 다룬 것들

오전 회의 — 주제 선정

오전 액션 아이템

✅ 오후 회의 — 주제 확정

주간 미션 — 회의록 시스템

Github Repo & 브랜치 전략

환경 설정 — 하네스 엔지니어링 도입

결정 사항 · 액션 아이템

‍ 오늘의 코드 리뷰 — label vs p (HTML 1일차)

❌ 문제 코드 (전체)

✅ 정답 (수정 부분)

확인 방법

✍️ 마치며

[260727 20일차] 프로젝트 #1

[킥오프] 팀 프로젝트 시작조 편성 · 협업 컨벤션 · 팀 멘토링

오늘 다룬 것들

팀 세팅

Git & 협업 컨벤션

브랜치 전략

커밋 컨벤션 (Conventional Commits)

[프로젝트 6일차] 2주차 시작 · 화면 설계
+ 요구사항·ERD 정합성 검토 · Pulse UI 조립

[프로젝트 5일차] Figma UI · 머지 정책 확정
+ ERD id 타입 결정 · JWT 저장 전략

[프로젝트 4일차] 와이어프레임·디자인 시스템
+ Git 머지 정책 · 산출물 범위 확정

[프로젝트 3일차] 컨벤션 병합 · 레포 설정
+ 기획서·WBS·요구사항·ERD 작성

[프로젝트 2일차] 주제 선정 · 회의록 시스템 미션
Git 전략 · 하네스 엔지니어링

[킥오프] 팀 프로젝트 시작
조 편성 · 협업 컨벤션 · 팀 멘토링

[Claude Code 심화]
커스텀 훅 · 플러그인 · MCP 자동화

[Streamlit · Gradio · Claude Code]
Python 웹앱 만들기 + AI 코딩 CLI

[OpenAPI · HuggingFace · Transformers · OCR]
공공 API · LLM · NLP · 문자 인식

[YOLO 심화] 히트맵·보안·카운팅
+ SAHI·속도추정·FastSAM