여러분은 이미 해보셨을 수도 있어 신선함은 없을지도 모르겠지만, 회의의 텍스트 변환(Transcription) 결과물로부터 의사록 및 Issue의 작성·업데이트를 수행하게 하는 실천 리포트입니다.

"텍스트 변환 결과물을 Claude에게 전달하면 편해지지 않을까"라고 시도해 보았더니, 상상 이상의 효과가 있었습니다. 쓰는 작업에서 손을 떼고, 회의에서는 논의 내용(Why·What·How)에 집중할 수 있게 되었습니다. 이를 위해 시행착오를 거치며 깨달은 점들을 공유합니다!

어떤 효과가 있었는지 먼저 읽고 싶은 분은 이쪽으로 이동해 주세요: "도입 후 변한 것".

환경은 Google Meet의 텍스트 변환, Claude, GitHub Projects를 통한 Issue 관리, Notion, Slack입니다. 같은 환경이라면 그대로 따라 할 수 있고, 다른 환경이라도 비슷한 방식은 가능할 것이라고 생각합니다.

🗒️ 의사록은 번호와 모드만 선택하면 끝

의사록 작성은 자체 제작한 스킬(meeting-log라고 부릅니다)을 실행하고, 제시되는 그날의 회의와 모드를 선택하기만 하면 됩니다. "1번 회의를 팀 내 모드로" 정도의 지시만 하면 충분합니다. 나머지는 Claude가 캘린더에서 텍스트 변환 결과물을 가져와 의사록을 구성하고, Notion에 의사록을 작성하며, Slack 공유까지 한 번에 수행하도록 설정해 두었습니다.

실행하면 그날의 회의 목록이 나타난다. 이후에는 「번호와 모드」를 전달하기만 하면 된다.

회의 직후에 지시하면 바로 다음 작업으로 돌아갈 수 있도록 설계했습니다. 텍스트 변환 결과물이 아직 생성되지 않았더라도 알아서 기다렸다가, 완료되면 작성을 시작합니다. 이전에는 "텍스트 변환 결과물이 아직 없음"으로 인해 멈추거나, 생성을 기다리는 동안 손을 놓게 되는 경우가 있었지만, 이제는 그런 일이 거의 발생하지 않습니다.

이 스킬의 만드는 법, 환경 구축 순서, 담아낸 노하우는 자매 글인 「의사록은 필요하다. 하지만 시간은 쓰고 싶지 않다. 거의 스킬 발동만으로 충분한 의사록을 손에 넣었다」에 정리해 두었습니다. 의사록 스킬 자체의 내용이나 만드는 방법에 관심이 있는 분들은 꼭 해당 글도 읽어주시면 감사하겠습니다.

✅ Issue는 "이것 좀 만들어줘/업데이트해줘"라고 전달하기만 하면 끝

Issue의 작성·업데이트는 훨씬 더 단순합니다.

"이 Issue, 방금 이런 이야기를 했으니 업데이트해줘", "이 이야기, 태스크로 만들어줘"라고 대상을 지목하며 텍스트 변환 결과물(대개 상관없는 부분까지 포함하여 전부)을 전달하여, 태스크나 스토리(Story)를 업데이트하거나 새롭게 기표(起票)하게 합니다.

업데이트의 경우

예를 들어, 이미 존재하는 Issue에 대해 회의에서 이야기했을 때는 결정된 사항을 짧게 전달하고 텍스트 변환 결과물을 통째로 전달합니다(/create-task는 Issue의 작성·업데이트를 맡기는 자체 제작 스킬입니다). 방침이나 배경을 포함하여 회의 내용의 세부 사항까지 Issue에 남기 때문에, 후속 작업에 매끄럽게 들어갈 수 있습니다.

/create-task
Issue #1356
A안은 불채택, B안으로 구현하기로 했습니다
...

기존 Issue의 업데이트는 대개 부분적이고 핀포인트로 이루어집니다. 게다가 그 자리에서 팀과 이야기한 내용이므로 어긋남이 거의 발생하지 않습니다. 업데이트한 본인이 직접 확인하고 문제가 없다면 그대로 채택합니다.

새롭게 기표하는 경우

이 또한 텍스트 변환 결과물을 통째로 전달합니다(/create-product-backlog는 프로덕트 백로그 아이템(PBI)을 기표하는 자체 제작 스킬입니다).

/create-product-backlog 親#6, sprint 16
텍스트 변환 내용으로 이야기하고 있는 것을 프로덕트 백로그화하고 싶습니다
텍스트 변환 내용:
...

서두의 親#6, sprint 16은 기표할 백로그를 상위 Issue(Epic) 번호와 스프린트(Sprint)에 연결하기 위한 지정입니다. 이를 전달해 두면 완성된 Issue가 올바른 상위 항목 아래에 나열되며, 그대로 스프린트에 포함됩니다. 생략하면 연결 없이 기표됩니다.

새롭게 기표된 것은 작성한 본인이 먼저 읽고, 어딘가에서 전원이 확인하여 "Ready" 상태로 만든 뒤에 작업을 시작합니다. 착수 전에 방향성의 어긋남이나 관점의 누락을 해결하기 위해서입니다.

요령은 직접 대상을 지목하는 것입니다 (통째로 맡기는 것보다 타겟을 정해 전달하는 것이 더 정확합니다. 이유는 후술할 "Issue를 자동으로 업데이트하지는 않는다"에 있습니다).

/create-task와 /create-product-backlog의 내용 (따라 하고 싶은 분들을 위해)

둘 다 팀에서 정한 템플릿을 텍스트 변환 결과물로부터 채우는 자체 제작 스킬입니다. 하는 일은 거의 공통적이며, 출력이 태스크(Task)인지 PBI인지의 차이만 있습니다.

/create-task |
/create-product-backlog |
|
|---|---|
| 주요 용도 | 기존 Issue의 업데이트·태스크화 | PBI의 신규 기표 |
| 전달하는 것 (신규) | 상위 Issue + 스프린트 번호 + 지시 | 좌동 |
| ... |

공을 들이고 있는 부분은, 항목을 자유 기술하게 하지 않고, 팀의 템플릿(배경·수락 조건(Acceptance Criteria)·하지 않을 것 등)에 따라 채우도록 하는 것입니다. 이렇게 하면 입도가 일정해지기 때문에, 나중에 읽는 사람이 혼란을 겪지 않습니다.

🛠️ 시행착오 끝에 얻은 개선점

처음부터 순조롭게 잘 풀린 것은 아닙니다. 직접 해보면서 몇 가지를 수정하여 지금의 형태가 되었습니다.

Gemini의 자동 요약은 전달하지 않는다

가장 효과적이었던 깨달음이 이것입니다. Gemini가 자동으로 만드는 요약 메모(회의록 비슷하게 만든 것)는 오히려 노이즈였습니다. 요약을 읽히면 그쪽 내용에 끌려가서 출력이 얕아집니다. 게다가 요약 자체가 틀리는 경우가 있어, 그 오류에 출력이 휘말리기도 했습니다. 그래서 요약은 사용하지 않고, 발언 그대로의 전사(Transcription) 데이터만 Claude에게 전달하고 있습니다. Gemini의 자동 요약은 애초에 만들지 않도록 했습니다 (이 사실을 깨닫고 수정한 것은 2026년 4월경입니다. 그 이후 Gemini 측이 개선되었는지는 확인하지 못했으므로, 테스트할 때는 직접 확인해 보시기 바랍니다).

회의가 짧아질 줄 알았지만, 그렇지 않았다

시작할 때는 '회의가 짧아지겠지'라고 생각했습니다. 손으로 쓰는 시간이 사라지니까 말이죠. 실제로는 짧아지지 않았습니다. 하지만 논의에 집중하면서도 성과물이 확실히 만들어진다는 강점을 발견했습니다 (자세한 내용은 '도입 후 변화된 점'에 기술).

마침 팀은 AI에게 맡김으로써 태스크(Task)가 빠르게 진행되었고, 회의에서 결정해야 할 사항들이 늘어나고 있었습니다. 그런 상황에서도 (오히려 회의 시간이 크게 늘어나지 않고) 운영될 수 있는 것은, 이 글에 쓴 프랙티스(Practice) 덕분이라고 느끼고 있습니다.

Issue의 자동 업데이트는 하지 않는다

처음에는 회의록을 전달하는 것만으로 Issue까지 자동으로 생성하거나 업데이트하게 했습니다. 하지만 다음과 같은 이유로 별로 쓸모가 없었습니다.

• 🙅‍♂️
  전부 한꺼번에 자동 생성: 그날의 이야기를 일괄적으로 보기 때문에 초점이 흐려집니다. 다른 Issue 내용이 섞일 수 있습니다. 백그라운드에서 업데이트되면 틀려도 알아채기 어렵습니다.
• 🙆‍♂️
  사람이 핀포인트로 지정: "이 Issue, 이걸로 업데이트"라고 목표를 하나로 좁힙니다. 문맥이 압축되므로 제대로 작성할 수 있습니다.

그래서 지금은 Issue의 자동 업데이트는 하지 않는 설계로 가고 있습니다. 완전 자동이라는 꿈보다는, 사람이 목표를 좁히는 반자동(Semi-automatic)을 선택했습니다.

📈 도입 후 변화된 점

• 회의록이 매번 제대로 남는다. 이전에는 유닛 내의 회의록을 거의 작성하지 않았지만, 지금은 아무리 짧은 회의라도 매일 작성됩니다 (오히려 남기기 위해 일부러 Google Meet에 들어가 있기도 합니다).
• 손으로 적는 것보다 상세하다. 전사(Transcription)가 전부 잡아내기 때문에, 회의 중에 정성스럽게 메모를 적지 않게 되었습니다. 그럼에도 불구하고 놓치는 부분은 오히려 줄어들었고, 직접 적지 않았을 법한 미묘한 뉘앙스까지 남게 되었습니다.
• Issue의 내용이 알차진다. 배경·할 일·하지 않을 것·관련 링크가 생성된 시점에 작성됩니다. 작업자가 필요한 정보가 갖춰진 상태에서 착수할 수 있습니다.
• 회의에서 논의에 집중할 수 있다. 쓰는 작업을 내려놓음으로써 Why·What·How에 에너지를 쓸 수 있습니다.

'Issue가 알차지는 것'은 다음 작업 공정에도 효과가 있습니다. 회의에서 가볍게 이야기한 배경·목적·작업 방침의 미묘한 차이·참고 자료까지 Issue에 들어가기 때문에, "Issue 번호만 전달하면 Claude에게 구현부터 리뷰까지 맡기는 메커니즘"이 원활하게 돌아가게 되었습니다. 그 상세한 내용은 이전에 쓴 글에 있습니다: 개발 플로우를 Claude Code 스킬로 만들었더니, 팀원 모두의 카레가 매번 맛있어졌다 레시피를 한 줄 고치면, 모두의 개발 플로우가 진화한다

숫자로도 확인해 보겠습니다.

Issue 내 기술량은 대략 5배로

GitHub의 Issue를 시기별로 샘플링하여 본문의 글자 수를 측정해 보았습니다. 작업 후의 추가 내용을 포함하지 않도록 '생성 시점의 본문'으로 비교했습니다. 결과는 중앙값 기준으로 약 240자에서 약 1,400자로(약 5.8배) 늘어났습니다. 배경·수락 조건·하지 않을 것, 원본이 된 회의록이나 Slack 링크까지 기표 시점에 채워지게 되었습니다.

'빠지는 것'을 실제로 세어 보았다

수기 메모와 생성된 의사록이 모두 남아 있는 회의를 5회분 수집하여, "Claude의 생성물에는 있지만 수기 메모에는 없는 의미 있는 항목"을 세어 보았습니다. 수기 메모가 평균 17개 항목, 생성물 측이 평균 21개 항목이었으며, 그중 수기에 없었던 것이 평균 4~5개 항목이었습니다. 생성물의 2~3할이 손으로 적을 때 누락되었다는 계산이 나옵니다.

예를 들어, 다음과 같은 내용이 누락되어 있었습니다.

• "이 업데이트는 일 년에 한 번만 실행되지만, 그때의 절차가 아직 정해지지 않았다"라는 단서
• "A는 반드시 포함하지만, B는 이번에 포함하지 않는다 (확실히 가져올 수 있다는 보장이 없기 때문)"라는 판단의 단서

휴가 중일 때 캐치업(Catch-up)이 쉬웠다

효과를 더 실감한 것은 본인이 휴가 중일 때였습니다. 그날의 의사록을 열어보면 무엇이 논의되었는지 알 수 있습니다.

실제로 휴가 복귀 후 읽어보니, 다른 사람이 내 작업을 인계받고 있다는 사실을 알 수 있었습니다. 덕분에 즉시 커뮤니케이션을 취하러 갈 수 있었습니다. 물론 조금 지나면 알아차렸겠지만, 알아차리기까지의 시간은 단연 빨랐습니다. 왜 인계했는지, 인계 범위가 무엇인지도 가볍게 정리되어 있어 큰 시간 단축이 되었습니다.

🗣️ 보너스: 모두가 AI를 향해 말하기 시작했다

"이것은 Claude를 위한 것입니다"라고 전제하고, 나중에 Claude가 읽을 것을 가정하여 "Issue 번호는 이것, 배경은 이러함"이라고 말하는 모습이 나타나기 시작했습니다. 인간이 AI에 맞추어 가고 있는 것입니다. 조금 흥미로운 변화입니다.

실제로 자매 기사에 썼듯이, Issue 번호로부터 내용을 가져와 의사록의 정밀도를 높이는 장치를 넣어두었기에 효과는 높습니다. 또한, 전사(Transcription) 데이터를 통째로 넘겨주어도 Claude가 해당 부분을 특정하기 쉬워지므로 정밀도 향상으로 이어지고 있다고 (추측하고 있습니다).

🤔 솔직한 과제와 요약

솔직히 말씀드리면, 너무 많이 만들어져서 다 읽을 수 없다는 것이 현재의 고민입니다. Issue도 의사록도 순식간에 늘어납니다. Issue는 업데이트하는 사람이나 작업하는 사람은 한 차례 다 읽지만, 다른 사람이 만든 것까지 100% 읽지는 못합니다. 의사록에 있어서는 "전부를 읽을 수는 없고, 요약은 참고 정도로만 한다"라고 팀 차원에서 타협하고 있습니다.

하루에 한 장의 의사록 요약이 있고 TODO를 잊지 않으면 된다. 작업을 AI에 맡길 때의 정밀도를 높이기 위해 배경이나 문맥을 충분히 전달할 수 있도록 해둔다.

이렇게 해석하고 있습니다만, 최선의 방법은 아직 찾아가는 중입니다. 마찬가지로 대량의 생성물과 씨름하고 계신 분이 있다면 노하우를 들어보고 싶습니다.

그럼에도 불구하고, 이전으로 돌아갈 수는 없습니다. 의사록이나 Issue를 쓰는 것은 수단일 뿐, 정말로 하고 싶은 것은 내용에 대한 논의(Why·What·How)와 개발일 것입니다. 그곳에 집중할 수 있는 환경이 조금씩 갖춰지고 있다고 느낍니다.

참고 링크

Discussion