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

# 포트폴리오 학습일지

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

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로만 병합하기로 한 부분은, 얼마 전 배운 커스텀 훅이 실제 협업 규칙으로 살아나는 순간이라 반가웠다. 내일은 각자 기획서를 들고 와 주제를 정한다 — 이제 진짜 "우리 것"을 만들기 시작한다.

🏷️ 포트폴리오  |  팀 프로젝트  |  Git 컨벤션  |  협업  |  킥오프  |  학습일지