설계는 유연하게, 의견은 치열하게

Design Council을 아시나요?

교육과정을 개발하다 보면 내가 만든 이 설계안이 정말 효과가 있을지 확신이 서지 않을 때가 많다. 이럴 때 설계 초기 단계에서 Design Council(설계 협의회)을 운영하면 교육과정의 품질을 확보하는데 효과적이다.

혹시 몰라서 Design Council에 대해 챗GPT에 물어보니 "설계 초안(Blue-print)을 놓고 전문가들이 모여 타당성을 검토하는 의사결정 협의체"라는 답변을 내놓는다. 하지만 내가 연수원 현장에서 선배들에게 배우고 직접 실행했던 Design Council은 조금 다르다. 그리고 감히 말하건대, 내가 경험한 이 방식이 교육의 질을 높이는 데 훨씬 효과적이다.

| Design Council 이란?

챗 GPT가 내놓았던 '설계 초안(Blue-print)을 놓고 관련 전문가들이 모여 타당성을 검토하는 의사결정 협의체'라는 것을 내가 알고 있는 Design Council과 비교해 보면...

"설계 초안을 놓고" → 이 부분은 동일하다. 핵심은 설계안이 '물렁물렁'해서 얼마든지 수정 가능할 때 실시해야 한다는 점이다. 이미 굳어진 설계는 협의가 아니라 일반적인 보고에 불과하기 때문이다.

"전문가들이 모여" → 여기서 '전문가'의 정의가 중요하다. 보통 보고 라인의 상사나 팀 동료를 떠올리기 쉽지만, 내가 했던 방식은 보고 라인의 상사는 참여시키지 않는 것을 원칙으로 한다.

"타당성을 검토하는 의사결정 협의체" → Design Council은 의사결정 기구가 아니다. 다양한 의견을 수집하는 '장'일 뿐이며, 어떤 의견을 수용하고 버릴지는 나중에 과정개발자가 결정한다.

| 참여자 선정

성공적인 Design Council을 위해서는 다각도의 시각을 가진 참여자 구성이 필요하다.

인원 구성: 보통 5~10명 사이가 적당하다.

선정 기준: 직급이나 보직보다는 '과정개발자가 보기에 이 과정에 좋은 인사이트를 줄 수 있는 사람'이면 누구든 상관없다.

상사의 제외: 과정개발자의 직속 상사는 제외한다. 상사가 있으면 자유로운 의견 개진이 어렵기 때문이다. 꼭 필요하다면 발언권이 없는 Observer로만 참석시킨다. 상사의 의견은 Design Council이 아닌 별도의 보고 자리에서 들으면 충분하다.

| 운영 프로세스

운영의 핵심은 참여자들이 자신의 역할에 몰입할 수 있는 환경을 만드는 것이다.

[사전 준비]

참여자들에게 '초대장'을 보내고 발표 자료를 준비한다. 이때 중요한 것은 과정개발자로서 현재 어떤 고민을 하고 있는지, 즉 참여자들에게 구체적으로 어떤 도움을 받고 싶은지를 자료에 반드시 포함해야 한다.

회의장은 서로 눈을 맞출 수 있는 U자 형태로 배치하고 명패와 다과를 준비해 수평적이고 편안한 분위기를 조성한다.

Observer가 있을 경우에는 별도로 분리된 자리를 준비한다.

[회의 진행: 안내 (10분)]

회의의 목적과 원칙을 명확히 공지한다. 예를 들어 "의사결정 회의가 아니니 자유롭게 발언해 달라"라고 안내하고, "Observer는 발언권이 없다"등의 규칙을 알려준다.

참여자들을 소개하고 각자에 대한 선정 이유(회의에서 어떤 점을 기여해 주기를 바라는지)를 함께 소개한다. 그래야 참여자들이 자신의 역할을 명확히 인지한다.

[회의 진행: 의견 교환 (40~50분)]

참여자들이 다양한 의견을 제시할 수 있도록 Facilitating 한다.

특히 중요한 점은 Design Council이 진행되는 회의장 안에서는 지위고하를 잊고 모두가 동일한 발언권을 갖는 것이다. 회의 진행자가 그 분위기를 조성하는 것이 매우 중요하다.(과정개발자가 회의를 직접 하기 어려울 경우 별도 회의 진행자가 진행하는 것도 가능함)

혹시 Observer가 발언을 원할 경우 과정개발자의 판단하에 발언을 허락할 수도 있다.

[마무리 및 Follow-up]

도출된 의견이 모두 반영되는 것은 아님을 리마인드 하며 감사를 전한다.

이후에도 관심을 가지고 추가 의견이 있을 경우 언제든지 의견을 제시해 달라고 당부한다.

회의 후 개발자는 수집된 아이디어를 선별하여 설계안을 보완하고 정교화하는 작업을 거친다.

| 성공을 위한 핵심!

내가 경험한 바를 토대로, 이 제도가 제대로 작동하기 위한 핵심 요소 3가지를 꼽자면 다음과 같다.

첫째, '심리적 안전감'이 확보된 수평적 환경을 조성하라.

보고 라인의 상사를 제외하고 Observer의 발언권을 제한하는 이유는 단 하나다. 참여자들이 이해관계의 눈치를 보지 않고 솔직한 의견을 내도록 하기 위함이다. 계급장을 떼고 토론할 수 있는 환경이 갖춰질 때 비로소 설계안의 허점이 드러난다.

둘째, 과정개발자가 '질문의 주인'이 되어야 한다.

단순히 "어떤가요?"라고 묻는 것이 아니라, "이 모듈에서 이런 사례가 적절할까요?", "현업에서 이 실습이 가능할까요?"와 같이 구체적인 고민을 던져야 한다. 개발자가 간절하게 도움을 요청할 때 참여자들도 단순한 비평가가 아닌 조력자로서 몰입하게 된다.

셋째, '수용의 주도권'은 오직 개발자에게 있다.

Design Council에서 나온 모든 의견을 반영해야 한다는 강박에서 벗어나야 한다. 그래야 참여자들도 자유로운 의견을 개진할 수 있다. 이 회의는 의사결정 기구가 아니다. 다양한 관점을 수집하되, 교육의 본질과 방향성을 고려해 최종적으로 무엇을 취하고 버릴지는 개발자가 주도적으로 판단해야 전문성 있는 교육이 완성된다.

Design Council은 단순히 설계도를 검토하는 시간이 아니다. 개발자의 고민을 나누고, 현장의 에너지를 설계안에 불어넣는 '생명 부여'의 과정이다. 내가 알고 있는 이 방식이 더 많은 HRD 현장에서 쓰이길 바란다.