Daily ScrumとAI：なぜスタンドアップはステータスボットになってはいけないのか

これは、AIがクロスファンクショナルな開発チームの定番ミーティングをどう変えるかについてのシリーズ第3回の記事です。第1回では Backlog Refinement を取り上げ、AIは資料の準備を加速するが、チームによる意味の確認を置き換えるものではないことを示しました。第2回では Sprint PlanningAIは計画の下書きを作成できますが、チームのコミットメントを代行することはできません。ここでDaily Scrumに移り、ここでの最も危険な間違いが、生きた同期を自動ステータスボットに変えてしまうことである理由を見ていくのが論理的です。

Daily Scrumは自動化の理想的な候補に見えます。コミットはGitにあり、タスクはJiraにあり、pull requestはGitHubやGitLabにあり、インシデントはモニタリングにあり、やり取りはSlackやTeamsにあります。AIは簡単に簡潔な要約を作成できます。誰が昨日何をしたか、タスクで何が変わったか、どこにブロッカーがあるか、どのPRが長くレビューされていないか、どのチケットが動いていないか、現在の作業量の近くでどのバグが発生したか。

一見すると、これはほぼ明らかな利点に見えます。繰り返しのステータスが減ります。同期ミーティングが減ります。手動の言い換えが減ります。特に分散チームでは、人々が異なるタイムゾーンで働き、ツールで既に見えていることを毎日共通の時間枠で口にするのに費やしたくない場合に。

しかしここには重要な罠があります。

Daily Scrumは報告のために存在するのではありません。その目的は、開発者がSprint Goalへの進捗を確認し、Sprint Backlogを適応させ、直近の作業を調整できるようにすることです。もしAIがDaily Scrumを昨日の活動に関する自動レポートに変えてしまうと、チームはより正確なステータスを得られるかもしれませんが、最も重要なもの、すなわち問題の生きた発見、shared awareness、次のステップへの責任を失う可能性があります。

「AIはステータスのノイズの一部を取り除けますが、Daily Scrumの価値はステータスではなく計画の適応にあります。」

なぜDaily Scrumが必要なのか

В Scrum Guide 2020 Daily Scrumはかなり厳密に定義されています。開発者のための15分間のイベントであり、その目的はSprint Goalに向けた進捗を確認し、必要に応じてSprint Backlogを適応させ、直近の作業計画を変更することです。これはプロダクトオーナーへの報告ではありません。スクラムマスターによる朝の監視でもありません。タスクを順番に読み上げる場でもありません。そして毎日の稼働状況の議事録でもありません。

補足的な指針として、次も役立ちます。 Scrum Guide Expanded v2026.1ただし、これは新しい正典的なScrum Guideのバージョンではなく、あくまでcompanion（補助）資料としてです。この記事にとって重要なのは実践的な枠組みとしてであり、そこではDaily Scrumはactionable planの共同更新として説明され、フローの論理は非常に正確に定式化されています。つまり、「暇な」人ではなく、行き詰まった作業に目を向けるということです。AI支援のDailyではこれが決定的に重要です。AIはリスク、impediments、行き詰まったSprint Backlogの項目を浮き彫りにすべきであり、人々を日次報告の行に変えてはなりません。

Daily Scrumの意味は、チームが毎日実践的な問いを自分たちに投げかけるところに生まれます。前回から何を学び、それが次の24時間の計画をどう変えるのか。答えが「何も変わらない」なら、ミーティングは非常に短くて済みます。答えが「スプリントの目標にリスクがある」なら、Daily Scrumは素早い協働の場となります。誰が誰とミーティング後に同期するのか、どのブロッカーをエスカレーションするのか、何を作業範囲から外す必要があるのか、どの依存関係を確認するのか、どのタスクは始めない方がよいのか。

したがって、私はDaily Scrumの目的を5つの機能で説明したいと思います。

• Sprint Goalを中心としたチームの同期。
• 問題とブロッカーの迅速な特定。
• 直近の作業の調整。
• スプリントの状態に関する共有認識を維持すること。
• 単に情報を交換するだけでなく、計画を適応させること。

これはAIについて語る上で重要な枠組みです。ツールがチームのこれらの機能の遂行を助けるなら、それは有用です。単にステータス報告を見栄えよくするだけなら、便利ではあっても、デリバリーを必ずしも改善するわけではありません。

よくある失敗

Daily Scrumの問題は、人々が「3つの質問」を知らないことにあるのではありません。問題は、イベントが時間とともに慣れた管理パターンへと劣化していくことです。つまり、各自が順番に、何をしたか、何をするか、ブロッカーがあるかを報告するのです。これは最小限の規律としては役立つこともありますが、非常に多くの場合、こうした形式はチームの協働を個人の報告義務にいつの間にかすり替えてしまいます。Scrum.orgはこのアンチパターンを次の資料で直接取り上げています。 Daily Scrum is not a status meeting：開発者が他の誰かに報告するとき、イベントは自己管理と計画の適応の仕組みではなくなります。

그러면 회의는 자신의 목적에 반하여 작동하기 시작한다. 개발자들은 서로가 아니라 스크럼 마스터나 매니저를 향해 말한다. 블로커는 너무 늦게 또는 너무 부드럽게 언급된다. 의존성은 “그건 이미 세부 사항”이라며 논의되지 않는다. 사람들은 활동을 나열하지만 Sprint Goal에 가까워졌는지는 말하지 않는다. 팀은 스프린트가 끝날 때에야 계획이 어긋났다는 것을 알게 되고, 그때는 품질 손실 없이 무언가를 적응시키기 어렵다.

AI-assisted 맥락에서 이 문제는 심화될 수 있다. 모델이 매일 Jira, Git, Slack을 바탕으로 간단한 요약을 생성하면, 팀은 “상태는 이미 수집되었다”는 생각에 빠르게 익숙해진다. 그러면 Daily Scrum은 더욱 형식적으로 변한다. 사람들은 AI 요약을 보고, 이를 확인하고, 때로 몇 마디 덧붙인 뒤 흩어진다.

효율적으로 보인다. 그러나 문제는 상태가 수집되었는지가 아니다. 문제는 현실이 바뀌었다면 팀이 자신의 계획을 바꾸었는지다.

AI가 실제로 도움이 되는 곳

Daily Scrum에서 AI에게는 충분히 실용적인 유용성 영역이 있다. 그것은 일상적인 상태 커뮤니케이션을 줄이고, 사람들이 매일의 흐름 속에서 쉽게 놓치는 신호를 표면으로 끌어올릴 수 있다. 이는 소스가 많은 팀에서 특히 가치 있다. issue tracker, pull request, CI/CD, incident management, product analytics, support ticket, 캘린더, 문서, 서신.

그러나 여기서 과도한 약속은 피해야 한다. 심지어 최신 DORA State of AI-assisted Software Development 2025 는 AI를 더 나은 delivery의 독립적 보장이라기보다 기존 조직 관행의 증폭기로 묘사한다. Daily Scrum에서 이는 간단한 의미를 갖는다. 팀이 이미 Sprint Goal, 리스크, 계획 적응을 논의할 줄 안다면 AI는 대화의 입구를 더 풍부하게 만들 수 있다. Daily가 오래전부터 상태 의례가 되었다면 AI는 그 상태 의례를 더 빠르고 더 예쁘게 만들 뿐이다.

좋은 AI 도우미는 Daily Scrum 전에 “누가 무엇을 했는지”가 아니라 조정을 위한 유용한 맥락을 모을 수 있다:

• 어떤 작업이 예상보다 오래 움직이지 않았는지;
• 어떤 pull request가 review를 필요로 하거나 다른 변경을 차단하고 있는지;
• 어떤 테스트나 빌드가 불안정해졌는지;
• 채팅에서 언급되었지만 Jira에 들어가지 않은 blocker는 무엇인지;
• 어떤 Sprint Backlog 항목이 더 이상 Sprint Goal을 직접 지원하지 않는지;
• 새로운 의존성, 리스크 또는 충돌하는 변경이 어디에서 나타났는지;
• 어제 비동기적으로 내려진 어떤 결정이 전체 팀에 보여야 하는지;
• 무엇이 전체 논의가 아니라 Daily 이후 짧은 follow-up을 필요로 하는지.

이런 방식에서 AI는 Daily Scrum을 대체하지 않는다. 그것에 대한 준비 비용을 낮춘다. 팀은 빈 기억이나 개인별 재요약이 아니라 이미 수집된 신호의 그림을 가지고 온다. 이는 사실을 복원하는 데 시간을 덜 쓰고 “이제 우리는 무엇을 하는가?”라는 질문에 더 많은 시간을 쓰게 한다.

이는 시리즈의 이전 글들의 논리를 이어간다. refinement에서 AI는 논의할 자료를 모으는 데 도움을 주었다. planning에서는 계획의 대안들을. Daily Scrum에서는 스프린트 진행에 관한 신호를 모을 수 있다. 그러나 세 경우 모두 인간의 부분은 사라지지 않는다. 팀은 무엇이 중요한지, 무엇이 바뀌었는지, 어떤 결정을 내려야 하는지 확인해야 한다.

AI가 스탠드업을 상태 봇으로 만들면 안 되는 이유

AI-assisted Daily Scrum의 가장 위험한 버전은 매우 기술적으로 보인다. 매일 아침 봇이 각 참가자별 간단한 요약, 어제의 커밋 목록, 티켓 상태, 열린 PR, 가능성 있는 블로커, 작업량 완료 예측을 게시한다. 때로 봇은 각자에게 자신의 상태를 확인하거나 수정해 달라고 요청하기도 한다.

관리자 통제의 관점에서는 편리하다. Scrum의 관점에서는 퇴화일 수 있다.

첫째, 이런 형식은 Daily Scrum을 쉽게 개인별 보고로 되돌린다. 사람들은 팀이 Sprint Goal을 향해 어떻게 나아가는지가 아니라 AI가 자신의 개인 활동을 정확히 묘사했는지를 생각하기 시작한다. 주의는 조정에서 평판 방어로 옮겨간다. “봇이 내 review를 반영하지 않았다”, “나는 커밋이 없었지만 인시던트를 처리하고 있었다”, “Jira는 실제 작업을 반영하지 않는다”.

둘째, AI 요약은 공유된 인식이라는 잘못된 느낌을 만들 수 있다. 요약이 게시되면 모두가 다 안다고 느껴진다. 그러나 공유된 인식은 채널에 텍스트가 있는 것이 아니다. 무엇이 중요하고, 위험이 어디에 있으며, 누가 누구와 동기화해야 하고, 계획이 어떻게 바뀌는지에 대한 공통된 이해다.

셋째, 자동 상태는 약한 신호를 가릴 수 있다. 진짜 문제는 종종 Jira의 형식적 필드가 아니라 어조, 의심, 불확실한 표현, 짧은 “우리가 잘못 가고 있는 것 같아”, 작업 사이의 긴장, 보통 리스크를 빠르게 제기하는 사람의 침묵 속에서 드러난다. AI는 텍스트에서 그러한 신호의 일부를 찾는 데 도움을 줄 수 있지만, 문제 발견의 유일한 메커니즘이 되어서는 안 된다.

넷째, 팀이 소유권/책임을 도구에 위임하기 시작할 수 있다. 봇이 괜찮다고 말하면 괜찮은 것이다. 봇이 블로커를 표시하지 않았다면 블로커는 없는 것이다. 봇이 작업량 완료를 예측한다면 불편한 타협을 논의하지 않아도 된다. 이것은 Daily Scrum의 자동화가 아니라, 책임이 있을 수 없는 곳으로 책임을 옮기는 것이다.

“AI가 생성한 상태는 유용한 입력이 될 수 있다. 그것이 팀의 사고를 대체해서는 안 된다.”

사례를 계속하자: B2B LMS와 이메일 알림

처음 두 글의 같은 사례를 가져오자. B2B LMS 플랫폼, 필수 과정, 마감까지 필수 과정을 완료하지 않은 직원에게 보내는 이메일 알림. planning에서 팀은 좁은 Sprint Goal을 선택했다. 시스템이 마감까지 미완료 필수 과정이 있는 활성 직원에게 하나의 정확한 알림을 보내고 검증 가능한 발송 이력을 저장한다.

이런 스프린트에서 AI 없는 Daily Scrum은 빠르게 개인별 상태 나열로 변할 수 있다. 백엔드는 스케줄러를 만든다고 말한다. 다른 백엔드는 중복 제거/중복 제거 작업을 보고 있다고 말한다. QA는 시간대별 시나리오를 준비한다고 말한다. 프론트엔드는 이력 로그 API를 기다린다고 말한다. 제품 책임자는 듣는다. 스크럼 마스터는 시간을 지킨다. 형식적으로는 모두 좋다.

하지만 팀은 핵심을 놓칠 수 있다. scheduler는 거의 준비되었지만 중복 제거는 이력 로그에 어떤 키가 들어갈지에 달려 있다. QA는 시간대가 어디에 저장되는지 결정되기 전까지 테스트 데이터를 준비할 수 없다. 프론트엔드는 API를 기다리지만 Sprint Goal에는 전체 UI가 어쩌면 전혀 필요 없을 수도 있다. 제품 책임자는 여전히 어떻게 해석할지 확인하지 않았다. expired, 팀은 이것을 범위 밖 작업이라고 생각하지만.

여기서 AI가 도울 수 있다. Daily 전에 신호를 수집한다. scheduler PR은 열렸지만 review가 없다. 어제 채팅에서 중복 리스크를 논의했다. 이력 로그 티켓은 업데이트되지 않았다. QA가 시간대에 대한 댓글을 남겼다. backlog item에 고객 지원 팀의 새로운 명확화가 추가되었다. 이것은 좋은 입력이다.

그러나 가치는 회의에서 팀이 다음 단계를 할 때만 생긴다. 누가 Daily 직후 중복 제거 키를 확인하러 앉을지, 누가 시간대 정책을 확인할지, Sprint Goal 범위에서 이력 로그에 충분한 것이 무엇인지, 그리고 팀의 가용 역량을 분산시키지 않기 위해 오늘 UI 작업을 멈춰야 하는지를 결정한다. AI는 신호를 주었다. 팀은 계획을 적응시켰다.

안티패턴

아래는 AI를 Daily Scrum에 도입할 때 내가 특히 주시할 몇 가지 안티패턴이다.

1. 봇이 팀 맥락 대신 개인별 보고를 수집한다

AI 요약이 Sprint Goal이 아니라 사람 중심으로 구성되면 팀은 빠르게 상태 보고 형식으로 흘러간다. 신호를 목표, 리스크, 의존성, 그리고 조정이 필요한 결정별로 묶는 것이 더 유용하다.

2. 팀이 계획을 적응시키는 대신 요약을 확인만 한다

Daily Scrum이 “네, 봇이 맞게 썼어요”로 변하면 이벤트는 의미를 잃는다. 좋은 질문은 “상태가 정확한가?”가 아니라 “이 중 무엇이 오늘 우리 계획을 바꾸는가?”이다.

3. AI가 마치 객관적 진실인 것처럼 스프린트 완료를 예측한다

예측은 유용한 신호일 수 있지만 리스크에 대한 대화를 대체해서는 안 된다. 특히 모델이 복잡성, 품질, 의존성, Definition of Done을 이해하지 못한 채 velocity, 닫힌 티켓 수, 저장소 활동에 의존하는 경우에는 더욱 그렇다.

4. 블로커를 시스템에서만 찾는다

모든 블로커가 디지털 흔적을 남기는 것은 아니다. 때로는 불명확한 결정, 불편한 질문을 꺼내는 것에 대한 두려움, 우선순위 갈등, 팀의 피로, 또는 팀 외부 사람에 대한 숨은 의존성이 문제다. AI는 도울 수 있지만, 도구에서 쉽게 추출되는 것만으로 주의 범위를 좁혀서는 안 된다.

5. Daily가 활동 통제 채널이 된다

AI가 커밋, 댓글, 닫힌 작업, 또는 응답 시간으로 사람들의 “유용성”을 측정하기 시작하면 팀은 빠르게 가시적 활동에 맞춰 최적화된다. 이는 신뢰를 무너뜨리고 사람들이 Daily Scrum에 가져오려는 정보의 질을 떨어뜨린다.

6. 비동기 요약이 조정이 필요한 곳에서 대화를 대체한다

비동기성은 사실 전달에 유용하다. 그러나 Sprint Goal에 대한 리스크, 의존성 갈등, 또는 계획을 빠르게 바꿔야 할 필요가 있다면, 실시간 대화가 긴 댓글 체인보다 보통 더 저렴하다.

역할은 어떻게 바뀔까

AI는 Scrum Team 내 역할을 없애지 않지만 일상적 조정에서의 초점을 바꾼다. 사실을 수동으로 다시 말하는 것의 가치는 줄어든다. 신호를 검토하고, 결정을 내리고, 팀 책임을 유지하는 것의 가치는 커진다.

역할	나쁜 AI 시나리오에서의 리스크	성숙한 AI 활용
개발자	AI 요약을 수동적으로 확인하고 Sprint Backlog를 스스로 적응시키는 습관을 잃는다.	AI 신호를 입력으로 사용하지만, 계획에서 무엇이 바뀌는지, 누가 누구와 동기화하는지, 어떤 타협이 필요한지는 스스로 결정한다.
제품 책임자	편리한 daily report를 받고 Daily Scrum을 자신을 위한 투명성 채널로 보기 시작한다.	팀에 Sprint Goal 관련 리스크가 생기면 가치, 작업량, 범위 밖 작업을 빠르게 명확히 하도록 돕는다.
스크럼 마스터	퍼실리테이션을 봇에게 넘기고 사람들이 상태를 업데이트하는지만 확인한다.	Daily Scrum이 보고로 변질되는 것을 막고, 팀이 위험, 블로커, 계획 적응을 논의하도록 돕는다.
품질 엔지니어 / QA 엔지니어	AI가 생성한 긴 체크 목록을 받고 커버리지가 있는 것처럼 보이게 만든다.	예비 위험을 찾기 위해 AI를 사용하지만, 테스트 가능성, 관찰 가능성, 데이터, 실제 실패 모드는 수동으로 검증한다.
UX/UI 디자이너	AI 요약이 코드, PR, 개발 작업에 초점을 맞추기 때문에 Daily에서 빠진다.	UX 의존성, 작업 범위 결정, Sprint Goal과 사용자 가치에 영향을 미치는 질문을 부각한다.
엔지니어링 리드 / 테크 리드	AI 요약을 활동 관리 대시보드처럼 읽기 시작한다.	기술적 위험, 리뷰 병목, 통합 충돌, 숨은 의존성을 조기에 발견하기 위해 요약을 활용한다.

AI 지원 Daily Scrum을 위한 실용적 필터

나는 "AI 스탠드업 봇" 도입부터 시작하지 않을 것이다. 더 좁은 질문부터 시작할 것이다. 어떤 신호가 팀이 스프린트 계획을 더 빨리 적응시키는 데 도움이 되는가? 그다음에 AI를 이벤트의 대체가 아니라 준비 계층으로 사용할 수 있다.

Daily 전 AI 요약은 다음 질문에 답하는 데 도움이 될 때 유용하다:

• Sprint Goal 달성 위험이 바뀌었는가?
• 무엇이 차단되었거나 곧 차단될 것인가?
• 오늘 살아 있는 조정이 필요한 의존성은 무엇인가?
• 비동기적으로 내려진 어떤 결정이 팀 전체에 가시화되어야 하는가?
• Jira 상태와 실제 작업 상태 사이에 괴리가 있는 곳은 어디인가?
• Daily 이후 어떤 후속 대화가 필요하고 누가 참여하는가?
• Sprint Goal이 위험에 처했을 때 팀이 그만두어야 할 일은 무엇인가?

반대로 AI 요약이 주로 "누가 무엇을 했는가"라는 질문에 답한다면 그것은 Daily Scrum이 아니다. 그것은 보고다. 조직에서 필요할 수는 있지만, 팀의 점검과 적응과 혼동해서는 안 된다.

관리와 데이터 위생

Daily Scrum은 데이터에 특히 민감하다. AI 요약이 개인 메시지, 캘린더, 리뷰 코멘트, 프로덕션 인시던트, 지원 티켓, 내부 논의에서 정보를 쉽게 수집하기 시작하기 때문이다. 접근 범위가 넓을수록 요약은 더 설득력 있어진다. 그러나 과도한 관찰, 맥락 유출, 확신에 차 있지만 불완전한 모델 출력에 대한 과도한 의존의 위험도 커진다. 바로 이러한 위험 분류가 잘 설명되어 있다: NIST Generative AI Profile 및 OWASP Top 10 for LLM Applications 2025.

팀은 AI에 어떤 소스가 허용되는지, 어떤 필드가 제외되는지, 누가 요약을 보는지, 얼마나 오래 보관되는지, 개인 생산성 평가에 사용할 수 있는지를 미리 합의해야 한다. 마지막 항목이 결정적이다. 사람들이 Daily AI 요약이 효율성 통제의 대리 지표로 사용된다고 느끼면, 지표에 맞춰 행동을 최적화하기 시작하고 불편한 신호를 가져오지 않게 된다. 이것은 이미 "편리한 스탠드업"의 문제가 아니라 근로자 모니터링의 문제다. ICO monitoring at work impact assessment 및 EDPB Opinion 28/2024 같은 규제 지침은 이 글의 법적 지침서가 아니라 필요성, 비례성, 데이터 최소화, 투명성의 필요성에 대한 상기로서 유용하다.

실무적으로 이는 다음을 의미한다: 불필요한 개인 데이터를 모델에 끌어들이지 말고, 명확한 근거 없이 사적 대화를 분석하지 말고, 활동 순위를 만들지 말고, 딜리버리 신호와 성과 관리를 섞지 말고, 사실과 가정을 분리하라. AI는 팀이 작업을 보도록 도와야 하며, 사람을 감시하는 메커니즘이 되어서는 안 된다.

실용적 결론

AI는 실제로 Daily Scrum을 더 유용하게 만들 수 있다. 반복적인 상태 보고의 일부를 제거하고, 사실을 미리 수집하고, 블로커를 부각하고, 리뷰 병목을 찾고, 작업과 현실 사이의 괴리를 발견하고, 어제의 결정을 상기시키고, 조정을 위한 짧은 주제 목록을 준비할 수 있다.

그러나 이것은 팀이 경계를 이해할 때만 작동한다. AI는 입력을 준비하지 Daily Scrum을 진행하지 않는다. 신호를 보도록 돕지만 그 신호로 무엇을 할지는 결정하지 않는다. 요약을 제안할 수 있지만 공유 인식 자체를 만들어내지는 않는다. 위험을 발견할 수 있지만 계획 적응에 대한 책임을 지지는 않는다.

따라서 핵심 명제를 이렇게 정리하겠다: AI는 상태 커뮤니케이션 비용을 줄여 팀이 조정에 더 많은 주의를 쏟을 수 있게 해야 한다. 반대로 되어 Daily Scrum이 AI 생성 상태 보고로 변하면, 팀은 그 이벤트가 존재하는 바로 그 이유, 즉 살아 있는 동기화, 문제의 조기 발견, 공동 책임, 계획을 빠르게 바꾸는 능력을 잃는다.

성숙한 팀은 "스탠드업을 봇으로 대체할 수 있는가?"라고 묻지 않는다. 대신 이렇게 묻는다: "AI가 어떤 상태 잡음을 제거해야 우리 Daily Scrum이 Sprint Goal과 가까운 계획에 대한 더 정직한 대화가 될 수 있는가?" 이것은 훨씬 덜 화려한 표현이다. 대신 실제 딜리버리 실무에 더 가깝다.

출처 및 지침

• Scrum Guide 2020 — Daily Scrum, Sprint Goal, Sprint Backlog, 개발자, 점검과 적응.
• Scrum Guide Expanded v2026.1 — Scrum Guide 2020 기반 companion-소스: Daily Scrum의 실무적 프레이밍, 실행 가능한 계획, 리스크 / 장애요인 및 “idle work, not idle people” 흐름 접근법.
• Scrum.org: Daily Scrum이란 무엇인가? — Daily Scrum의 목적과 Sprint Goal과의 연관성에 대한 실무적 설명.
• Scrum.org: Daily Scrum은 상태 회의가 아니다 — Daily Scrum이 개인별 보고로 변질되어서는 안 되는 이유.
• NIST AI 리스크 관리 프레임워크 1.0 — 관리 / 규제, 책임 / 책무, 인간과 AI 상호작용 구성.
• NIST 생성형 AI 프로필 — 과도한 의존, confabulation / 확신에 찬 날조, 프라이버시 및 인간 통제.
• OWASP Top 10 for LLM Applications 2025 — 민감 정보 노출, misinformation, excessive agency 및 LLM 애플리케이션의 운영 리스크 공개.
• DORA State of AI-assisted Software Development 2025 — AI는 조직 관행의 증폭기이며, delivery 개선을 독자적으로 보장하는 수단은 아님.
• EDPB Opinion 28/2024 및 ICO monitoring at work impact assessment — 개인정보, 최소화, 투명성 및 근로자 모니터링에 관한 지침.