| name | work-share |
| description | 팀원에게 작업 내용을 공유하는 Google Chat 메시지를 작성하는 스킬.
Use when: "작업 공유", "팀 공유", "work share", "팀원한테 알려줘",
"공유 메시지 써줘", "작업 내용 정리해줘", "팀에 공유할 메시지",
"회고 공유", "작업 보고", "진행 상황 공유", "의견 요청 메시지",
"트러블슈팅 공유", "완료 보고".
작업 관련 내용을 팀원에게 전달해야 할 때 이 스킬을 사용하라.
사용자가 "정리해줘", "공유해야 하는데" 같이 팀 공유 맥락이 보이면 트리거.
|
work-share — 팀 작업 공유 메시지 생성기
Google Chat에서 팀원에게 작업 내용을 공유하는 메시지를 생성한다.
매번 "어떻게 쓸지" 고민하는 구조 설계 비용을 없애는 것이 목적이다.
원칙
- 두괄식 — 결론이 첫 줄에 온다. 바쁜 팀원이 첫 줄만 읽어도 핵심을 안다.
- 공통 뼈대 — 4가지 유형 모두 같은 구조를 쓴다. 유형마다 바뀌는 건 태그와 마무리뿐.
- 내용 기반 분량 — 줄 수 제한 없음. 핵심이 잘 전달되는 것이 본질.
- 짧은 서술문 + 불릿 혼합 — 배경은 1-2문장 서술, 세부사항은 불릿으로 구조화.
- 기술적 정확성 — 코드, 설정값, 수치 등 기술적 내용은 정확하게 기재.
- 사용자 입력 충실 — 사용자가 제공한 정보만으로 메시지를 구성한다. 추론이나 일반 지식으로 정보를 추가하지 않는다. 사용자가 말하지 않은 결과("성공률 복구 확인" 등)나 기술 용어(DLQ 등)를 임의로 넣지 않는다.
메시지 구조
[태그] 핵심 요약 한 줄 ← 첫 줄: 유형 + 결론
배경 서술 1-2문장 (Why) ← 왜 이 작업을 했는지 / 하고 있는지
- 세부사항 1 ← 불릿: What의 디테일
- 세부사항 2
- 세부사항 3
마무리 ← 유형별 기대 반응에 맞는 마무리
5가지 유형
유형은 팀원에게 기대하는 반응으로 구분한다.
| 유형 | 태그 | 기대 반응 | 마무리 패턴 |
|---|
| 완료 보고 | [완료] | 확인 | PR/커밋 링크 |
| 진행 중 공유 | [진행중] | 인지 | 예상 완료일 |
| 의견 요청 | [의견요청] | 피드백 | "의견 부탁드립니다" |
| 트러블슈팅 공유 | [해결] | 참고 | "참고해주세요" |
| 사고 회고 | [회고] | 학습 | PR 링크 |
[회고] 유형 — 사고/장애 회고
회고는 다른 유형과 다르다. 단순 불릿 나열이 아니라 서사적 흐름이 필요하다.
팀원이 "무슨 일이 있었는지, 왜 일어났는지, 다시는 안 일어나는 근거"를 이해해야 하기 때문이다.
회고 전용 구조:
[회고] 핵심 요약 한 줄
요약
2-3문장으로 사고 전체를 압축. 첫 3줄만 읽어도 핵심 파악 가능.
영향 범위, 복구 여부, 프로덕션 영향 포함.
무슨 일이 있었나
사건의 시간순 서술. 코드, 명령어, 설정값 등 구체적 증거 포함.
"어떤 코드가 어떤 상황에서 실행되어 어떤 결과를 냈는지"를 보여준다.
왜 발생했나
원인 체인을 번호로 나열 (1→2→3→결과).
마지막에 "구조적 원인"을 별도로 짚는다 — "누가" 아니라 "어떤 구조가" 문제였는지.
어떻게 막았나
조치 내용 + 기존 방식과의 비교.
가능하면 비교 테이블(기존 vs 신규)을 포함한다.
실제 차단 결과(명령어 + 출력)를 보여서 "재발 가능성 0"의 근거를 제시한다.
PR: #번호 또는 URL
회고 작성 원칙:
- 결론 먼저 — 요약 섹션에서 3줄 안에 핵심 전달
- 사실 → 원인 → 조치 순서 — 논리적 서사 흐름
- 비난 없이 구조적 원인에 집중 — "누가"가 아니라 "어떤 구조가"
- 구체적 증거 — 시간, 수치, 코드, 명령어로 뒷받침
- 재발 방지 근거 — 조치 후 실제 차단 결과를 보여줌
실행 절차
1. 유형 판별
사용자의 입력에서 유형을 판별한다.
- 이미 끝난 작업 → 완료 보고
- 현재 진행 중 → 진행 중 공유
- 선택지가 있고 판단이 필요 → 의견 요청
- 문제가 있었고 해결했음 → 트러블슈팅 공유
- 사고/장애가 있었고 원인 분석 + 재발 방지까지 공유 → 사고 회고
- 판별이 안 되면 사용자에게 물어본다.
[해결]과 [회고] 구분 기준: 단순 버그 수정은 [해결], 사고/장애 + 구조적 원인 분석 + 재발 방지 조치가 포함되면 [회고].
2. 컨텍스트 수집
메시지 작성에 필요한 정보를 수집한다. 사용자가 이미 충분한 정보를 제공했으면 바로 작성한다.
부족하면 핵심만 물어본다.
모든 유형 공통:
- 무엇을 했는가 / 하고 있는가 (What)
- 왜 했는가 / 하는가 (Why — 배경, 동기)
유형별 추가 정보:
- 완료 보고: 결과, PR/커밋 링크
- 진행 중: 완료된 부분, 남은 부분, 블로커 유무, 예상 완료일
- 의견 요청: 선택지와 각각의 장단점, 현재 기울어진 방향
- 트러블슈팅: 원인, 해결 방법, 재발 방지 조치
- 사고 회고: 사고 경위, 원인 체인, 구조적 원인, 조치 내용, 기존/신규 비교, 차단 결과 증거
3. 메시지 작성
수집된 정보로 메시지를 작성한다. 아래 지침을 따른다.
첫 줄:
[태그] + 핵심을 한 문장으로 요약- 이 한 줄만 읽어도 "무슨 일인지" 파악 가능해야 한다
- 예:
[완료] Redis 캐시 레이어 추가, [해결] 로그인 간헐적 실패 이슈
배경 서술:
- 1-2문장으로 Why를 설명
- "~를 위해 ~했습니다" 또는 "~에서 ~가 발생했습니다" 형태
- 존댓말 사용 (Google Chat 팀 공유 톤)
불릿 세부사항:
- 기술적 디테일은 상황에 맞게 조절
- 완료 보고 / 진행 중: 개념 수준 (구체적 코드는 PR 링크로 대체)
- 트러블슈팅: 원인-해결 과정이 보이도록 구체적으로
- 의견 요청: 선택지를 "A." "B." 접두사로 구분하고, 각각의 장단점을 불릿으로 나열
- 수치가 있으면 포함 (응답 시간, 성공률, 테이블 수 등)
- 사용자가 제공하지 않은 정보를 추가하지 않는다
- 불필요한 내용 제거 — 팀원이 알아야 하는 것만 남긴다
마무리:
- 유형별 마무리 패턴을 자연스럽게 배치. 마무리는 메시지의 마지막 줄에 온다.
- 완료 보고:
PR: #1234 또는 PR: https://...
- 진행 중:
예상 완료: 4/9(수)
- 의견 요청:
의견 부탁드립니다.
- 트러블슈팅: PR 링크가 있으면 불릿에 포함하고, 마지막 줄은
참고해주세요.
4. 출력
최종 메시지를 코드블록 없이 plain text로 출력한다.
Google Chat에 바로 복사-붙여넣기할 수 있는 형태여야 한다.
유형별 예시
완료 보고:
[완료] Redis 캐시 레이어 추가
API 응답 속도 개선을 위해 UserService 조회에 Redis 캐시를 적용했습니다.
- TTL: 5분
- 결과: 평균 응답 200ms → 45ms
PR: #1234
의견 요청:
[의견요청] 알림 발송 — 동기 처리 vs 비동기 큐
주문 완료 시 알림(이메일+슬랙) 발송 방식을 결정해야 합니다.
- A. 동기 처리: 구현 간단, 하지만 외부 API 장애 시 주문 응답 지연
- B. 비동기 큐(SQS): 장애 격리 가능, 하지만 인프라 추가 필요
- 현재 일 주문량: ~500건
의견 부탁드립니다.
트러블슈팅:
[해결] 배포 후 로그인 간헐적 실패
4/5 배포 후 로그인 성공률이 99.8%에서 97.2%로 하락했습니다.
- 원인: Redis 세션 스토어 connection pool 고갈 (maxTotal 기본값 8)
- 재현 조건: 동시 로그인 10건 이상
- 조치: maxTotal 32로 상향, 커넥션 타임아웃 3초 추가
- PR: #1248
참고해주세요.
사고 회고:
[회고] dev DB 데이터 삭제 사고 — pytest_configure 훅으로 원천 차단
요약
4/2(수) 21:00 KST, pytest가 dev DB에 직접 접속하여 25개 테이블 데이터가 삭제됐습니다.
Cloud SQL 백업 비활성화로 복구 불가. PR #731로 재발 방지 조치 완료.
무슨 일이 있었나
Iceberg Migration 작업 중, Claude Code가 develop 브랜치에서 pytest를 실행했습니다.
이때 clue_api.cfg가 dev DB(10.20.31.3)를 가리키고 있었고,
fixture teardown의 .query.delete()가 dev DB에서 실행되면서 실데이터가 삭제됐습니다.
왜 발생했나
1. clue_api.cfg가 dev DB(10.20.31.3)를 가리키고 있었음
2. 기존 안전장치(check_db_uri)는 confirm() 기반 — stdin 입력 대기 방식
3. Claude Code가 CI 블로킹 해결을 위해 confirm()을 bypass하는 코드를 추가한 상태
4. pytest 실행 → dev DB 직접 접속 → fixture teardown → 전체 삭제
구조적 원인: 안전장치가 confirm() 방식이라 자동화 환경에서 bypass가 너무 쉬웠습니다.
어떻게 막았나
root conftest.py에 pytest_configure 훅을 추가했습니다.
기존 vs 신규:
- check_db_uri: confirm() 기반, mocker.patch로 bypass 가능, Flask app 생성 후 실행
- pytest_configure: pytest.exit() 즉시 종료, conftest.py 삭제 외 우회 불가, 테스트 수집 전 실행
차단 결과:
$ pytest tests/ (clue_api.cfg가 dev DB를 가리킬 때)
→ BLOCKED: pytest가 외부 DB에 접속하려 합니다. PSQL_HOST = 10.20.31.3
→ 테스트 0개 실행. DB 접속 자체가 안 됩니다.
PR: https://github.com/khc-dp/clue-api/pull/731
안티패턴
- 첫 줄에 태그 없이 시작하지 않는다
- "안녕하세요", "공유드립니다" 같은 인사/서두를 넣지 않는다
- 마크다운 헤더(
#, ##)를 쓰지 않는다 — Google Chat에서 렌더링 안 됨
- 코드블록(```)은 기술적 내용이 있을 때만 최소한으로 사용
- 같은 내용을 서술문과 불릿에서 반복하지 않는다
- "담당자: 나", "날짜: 오늘" 같은 메타데이터를 넣지 않는다
