지식을 숨기지 않으면서도 고객과 동료의 비밀을 지키는 커뮤니티는 어디까지 공유하고 어디부터 보호하는가.
질문에서 시작합니다
Builder Circle의 월례 세미나에서 개발자 김 씨가 발표를 준비합니다. 지난 석 달간 한 유통사의 상품 추천 프로젝트를 했고, 배운 것이 많습니다. 어떤 임베딩 모델이 한국어 상품명에 잘 맞았는지, 어떤 프롬프트 구조가 실패했는지, 고객사 데이터 파이프라인이 얼마나 엉망이었는지, 그리고 고객이 내년에 추천 시스템을 자체 개발팀으로 내재화할 계획이라는 것까지.
김 씨는 어디까지 말해야 할까요. 아무것도 말하지 않으면 세미나는 뉴스 요약이 됩니다. 인터넷에서 얻을 수 있는 정보를 나누려고 회원들이 시간을 내지는 않습니다. 반대로 전부 말하면 고객은 자신의 내재화 계획이 외부에 알려진 것을 알게 되고, 커뮤니티에 다시 일을 맡기지 않을 것입니다.
이 긴장은 한국인공지능커뮤니티의 정체성 한가운데 있습니다. 우리는 실제로 해본 사람만 아는 경험을 나누기 위해 모였습니다. 동시에 우리는 고객과 동료의 비밀을 지키기 위해 울타리를 쳤습니다(제9장 참조). 이 장은 그 두 약속을 동시에 지키는 방법을 다룹니다. Confidential Community는 입을 닫는 커뮤니티가 아닙니다. 무엇을 열고 무엇을 닫을지 아는 커뮤니티입니다.
왜 이것이 문제인가
느슨한 커뮤니티에는 이 문제가 없습니다. 오픈채팅에는 보호할 정보가 없기 때문입니다. 아무도 고객 이름을 말하지 않고, 아무도 실제 숫자를 말하지 않습니다. 그래서 정보는 흐르지만 가치가 없습니다. 전통 기업에도 이 문제는 다른 형태로 있습니다. 회사 안에서는 정보가 공유되지만 회사 밖으로는 거의 나가지 않습니다. 경쟁사의 실패담을 들을 방법은 없습니다.
프로토콜 조직은 그 사이에 있습니다. 구성원은 각자의 회사와 고객을 가지고 있으면서 Project Cell(프로젝트 셀)로 결합합니다. 한 사람이 여러 셀에 속하고, 한 셀에는 서로 다른 회사 사람들이 있습니다. 정보는 사람을 따라 이동합니다. 김 씨가 유통사 프로젝트에서 배운 것은 다음 프로젝트에서 다른 고객을 위해 쓰입니다. 이것이 커뮤니티가 만드는 가치입니다. 동시에 유통사의 내재화 계획도 김 씨를 따라 이동할 수 있습니다. 이것이 커뮤니티가 막아야 하는 것입니다.
AI 시대는 이 문제를 두 방향으로 키웁니다. 첫째, 경험의 가치가 올라갔습니다. 모델과 도구는 누구나 쓸 수 있지만, 어떤 조건에서 무엇이 실제로 작동하는가는 해본 사람만 압니다. 이 지식은 논문에도 블로그에도 없습니다. 커뮤니티에서 공유되지 않으면 어디서도 공유되지 않습니다. 둘째, 유출의 비용이 올라갔습니다. 고객 데이터 한 조각, 미공개 모델 가중치 하나, 사업 전략 한 줄이 AI 도구와 결합하면 예전보다 훨씬 빠르게 경쟁자의 자산이 됩니다.
그래서 "알아서 잘 판단하라"는 답이 되지 않습니다. 김 씨는 선의로 발표를 준비했지만, 어디까지가 안전한지 기준이 없으면 두 가지 중 하나가 일어납니다. 너무 많이 말하거나, 두려워서 아무것도 말하지 않거나. 커뮤니티는 김 씨에게 기준을 주어야 합니다. 그 기준이 정보 등급과 세 가지 규약입니다.
우리의 철학
우리는 지식을 숨기는 조직이 아닙니다. 커뮤니티가 존재하는 이유는 실제로 해본 사람만 아는 경험이 신뢰 가능한 범위 안에서 흐르게 하는 것입니다. 공유는 기여이고, 기여는 기록되며, 기록은 신뢰가 됩니다. Knowledge 유형의 기여가 플랫폼에 기록되는 이유입니다. 기여한 사람을 잊지 않는다는 원칙은 발표한 사람, 실패담을 나눈 사람, 벤치마크를 공개한 사람에게도 적용됩니다.
동시에 우리는 고객과 동료의 비밀을 강력하게 보호합니다. 이 두 가지는 모순이 아닙니다. 공유해야 하는 것과 보호해야 하는 것은 종류가 다르기 때문입니다.
| 공유해야 하는 것 | 보호해야 하는 것 |
|---|---|
| 실제로 해본 사람만 아는 경험 | 고객의 이름과 식별 가능한 정보 |
| 워크플로우와 도구 조합 | 계약 조건, 단가, 금액 |
| 벤치마크와 성능 비교 결과 | 고객의 미공개 기술, 데이터, 모델 |
| 시장 인사이트와 수요의 방향 | 고객과 동료의 사업 전략 |
| 실패담과 원인 분석 | 개인정보, 인사 정보, 내부 갈등 |
| 프로젝트를 통해 만든 재사용 가능한 자산(Charter가 정한 범위) | Background IP와 아직 공개하지 않은 연구 |
기준은 단순합니다. 배운 것은 공유하고, 맡은 것은 보호합니다. 김 씨가 한국어 상품명 임베딩에서 배운 것은 김 씨의 경험입니다. 유통사의 내재화 계획은 김 씨가 맡은 것입니다. 전자는 공유해야 커뮤니티가 살고, 후자는 보호해야 커뮤니티가 삽니다.
이것은 프로토콜 조직의 설계 원리 중 "신뢰는 행동의 원장이다"와 직접 연결됩니다. 비밀유지는 Trust Capital의 항목입니다. 비밀을 지킨 기록이 쌓인 사람에게는 더 깊은 정보가 열리고, 더 깊은 정보가 열린 사람은 더 큰 프로젝트에 참여합니다. Restricted 등급의 프로젝트에 초대받는 것은 그 사람의 비밀유지 기록에 대한 신뢰의 표현입니다. Contribution creates Trust, not Permanent Privilege. 비밀유지도 기여입니다.
운영원칙: 정보 등급
커뮤니티의 모든 정보는 네 등급 중 하나에 속합니다. 등급은 정보를 만든 사람 또는 Project Lead가 정하며, 정하지 않은 정보의 기본값은 Community입니다.
| 등급 | 대상 | 누가 접근하는가 | 취급 규칙 |
|---|---|---|---|
| Public | 외부에 공개해도 되는 정보 | 누구나 | 커뮤니티 이름으로 발표·게시 가능. 개인 SNS 공유 가능 |
| Community | 회원 간 공유하는 경험·워크플로우·벤치마크·시장 인사이트 | 회원 전체 | 외부에 옮길 때 발언자와 출처를 특정하지 않음(Chatham House Rule). 회원이 아닌 사람에게 원문 전달 금지 |
| Cell-only | 특정 Project Cell 내부의 정보. 고객 식별 정보, 진행 상황, 산출물 | 해당 셀 참여자 | 셀 밖으로 나갈 때는 고객 식별 정보를 제거하고 Project Lead의 확인을 거침. Closed Room에서만 다룸 |
| Restricted | 계약 조건, 금액, 미공개 기술, 사업 전략, 개인정보 | Project Lead가 지정한 사람 | NDA 체결자만 접근. 메신저 전달 금지. 플랫폼의 접근 통제 영역에만 보관 |
등급 운영의 원칙은 다음과 같습니다.
- 낮은 등급으로 내리는 것은 어렵고, 높은 등급으로 올리는 것은 쉽습니다. Cell-only 정보를 Community로 낮추려면 Project Lead와 고객의 확인이 필요합니다. 반대로 어떤 회원이든 자신이 다루는 정보를 더 높은 등급으로 지정할 수 있습니다.
- 불확실하면 한 단계 위로 봅니다. 등급이 표시되지 않은 프로젝트 정보는 Cell-only로 취급합니다.
- 등급은 Project Charter에 적습니다. 프로젝트를 시작할 때 Confidentiality Checklist(비밀유지 체크리스트, Appendix F)를 작성하고, 어떤 정보가 어느 등급인지 참여자 전원이 확인합니다.
- 고객 식별 정보를 제거하면 등급이 내려갈 수 있습니다. "한 유통사의 상품 추천 프로젝트"는 Community 등급으로 공유할 수 있습니다. 회사 이름, 매출 규모, 담당자 이름이 없어야 합니다. 단, 업계가 좁아 식별이 가능하면 제거로 인정되지 않습니다.
- 프로젝트 종료 후에도 등급은 유지됩니다. 기본값은 종료 후 24개월이며, Charter로 조정합니다. 고객과의 계약이 더 긴 기간을 정하면 계약이 우선합니다.
운영원칙: 세 가지 규약
정보 등급이 "무엇을"이라면, 규약은 "어떻게"입니다. 커뮤니티는 세 가지 수단을 씁니다.
NDA(비밀유지계약)는 프로젝트 단위로 체결합니다. 커뮤니티 가입 시 회원은 Korea AI Community Charter(커뮤니티 헌장)에 서명하며, 헌장에는 일반적 비밀유지 의무가 포함됩니다. 그러나 Restricted 등급 정보를 다루는 프로젝트는 별도의 NDA를 체결합니다. NDA는 계약주체(Contracting Party)와 참여자 사이에 맺으며, 고객이 요구하는 NDA가 있으면 그것이 우선합니다. NDA 없이 Restricted 정보를 공유한 사람과 받은 사람 모두 책임이 있습니다.
Chatham House Rule은 모임에서 적용됩니다. 규칙은 하나입니다. 모임에서 들은 내용은 쓸 수 있지만, 누가 말했는지와 어느 조직의 이야기인지는 밝히지 않습니다. 이 규칙이 있어야 사람들이 실패담을 말합니다. "우리 회사가 이 모델로 3개월을 날렸다"는 이야기는 발언자가 특정되지 않을 때만 나옵니다. 커뮤니티의 모든 세미나, 원탁 모임, 식사 자리는 별도 표시가 없으면 Chatham House Rule이 적용됩니다.
Closed Room은 참여자만 접근하는 공간입니다. 플랫폼의 Project Cell 공간이 대표적입니다. Cell-only 이상의 정보는 Closed Room 안에서만 다룹니다. Closed Room에는 참여자 목록이 있고, 누가 언제 무엇을 보았는지 기록됩니다. 기록의 목적은 감시가 아니라 유출이 생겼을 때 범위를 빠르게 확인하기 위함입니다.
정보 등급 적용 규약 공간
─────────────────────────────────────────────────────────────
Public → 제한 없음 → 어디서나
Community → Chatham House Rule → 회원 공간, 모임
Cell-only → Chatham House Rule + Charter → Closed Room
Restricted → NDA → Closed Room 접근 통제 영역
모임에서 Chatham House Rule은 어떻게 작동하는가
규칙은 간단하지만 실제 적용은 상황마다 다릅니다. 커뮤니티의 세 가지 대표 모임에서 어떻게 작동하는지 봅니다.
세미나. 발표자는 발표 자료를 Community 등급으로 준비합니다. 고객 이름 대신 "제조 분야의 한 중견기업"으로, 실제 수치 대신 "약 30% 개선"처럼 상대 수치로 표현합니다. 질의응답에서 나온 이야기는 참석자가 자기 일에 쓸 수 있지만, "지난 세미나에서 김 씨가 A사 프로젝트에서"라고 옮길 수 없습니다. 발표 자료는 플랫폼에 Community 등급으로 올라가며, 회원이 아닌 사람에게 전달하지 않습니다. 발표 녹화는 발표자가 동의한 경우에만 하고, 동의해도 Community 등급을 유지합니다.
AI Table. 열 명 안팎이 한 주제로 깊게 이야기하는 원탁 모임입니다. 세미나보다 구체적인 이야기가 나옵니다. 여기서는 진행자가 시작할 때 규칙을 한 문장으로 확인합니다. "오늘 이야기는 쓸 수 있지만, 누가 어느 회사 이야기를 했는지는 밖으로 나가지 않습니다." 참석자가 "이건 여기서만"이라고 말하면 그 부분은 Cell-only에 준하는 것으로 취급하고 모임 밖에서 인용하지 않습니다. 모임 후 정리 노트는 진행자가 발언자를 제거한 형태로 작성하고, 참석자 확인 후 플랫폼에 올립니다.
Founder Dinner. Founder Circle의 저녁 모임입니다. 사업 이야기는 본질적으로 전략과 숫자를 포함합니다. 여기서는 규칙이 더 엄격하게 작동합니다. 매출, 투자 유치, 인력 문제 같은 이야기는 그 자리에서 끝납니다. 정리 노트를 만들지 않으며, 그 자리에서 들은 것을 근거로 다른 회원에게 투자나 채용을 제안하려면 발언자에게 먼저 동의를 받습니다. 저녁 자리에서 들은 정보로 상대의 고객에게 접근하는 것은 Chatham House Rule 위반이자 고객 우회입니다(제11장 참조).
세 모임에 공통되는 것이 있습니다. 규칙은 참석자를 침묵시키기 위한 것이 아니라 말하게 하기 위한 것입니다. 발언자를 보호해야 실패담이 나오고, 실패담이 나와야 커뮤니티에 올 이유가 생깁니다.
메신저와 플랫폼
현실의 대화는 카카오톡 같은 메신저에서 일어납니다. 프로젝트 팀은 메신저 방을 만들고, Circle은 단체방을 운영합니다. 커뮤니티는 이것을 막지 않습니다. 메신저는 빠르고 익숙하며, 실행은 빠르게 이루어져야 합니다. 그러나 원칙은 분명합니다. 대화는 메신저에서 하더라도, 관계와 기여와 기록은 플랫폼에 축적됩니다.
이유는 두 가지입니다. 첫째, 메신저는 기록이 아닙니다. 방이 사라지면 대화도 사라지고, 누가 무엇을 기여했는지 남지 않습니다. 기여한 사람을 잊지 않으려면 기여가 플랫폼에 있어야 합니다. 둘째, 메신저는 통제가 되지 않습니다. 누가 방에 있는지 확인하기 어렵고, 캡처 한 번이면 정보가 어디로든 갑니다. Cell-only 이상의 정보가 메신저에 있으면 그 정보는 사실상 등급을 잃은 것입니다.
메신저 방에서의 정보 취급 규칙은 다음과 같습니다.
| 항목 | 규칙 |
|---|---|
| 방 개설 | Project Cell 방은 Project Lead가 만들고, 참여자 목록을 플랫폼의 셀 기록과 일치시킴 |
| 초대 | 셀 참여자가 아닌 사람을 초대하려면 Lead 확인. 고객 담당자를 초대하는 방은 별도로 분리 |
| 등급 | 메신저 방은 Community 등급까지만 취급. Cell-only는 고객 식별 정보를 제거한 경우에 한해 허용. Restricted는 금지 |
| 파일 | 계약서, 단가표, 고객 데이터, 모델 가중치는 메신저로 보내지 않음. 플랫폼의 Closed Room 링크로 대체 |
| 결정 | 방에서 나온 결정(범위 변경, 역할 변경, 보상 변경)은 24시간 내에 플랫폼의 셀 기록에 옮김. 옮기지 않은 결정은 합의로 인정되지 않음 |
| 캡처 | 방의 대화를 캡처해 다른 방이나 외부로 옮기는 것은 등급과 무관하게 금지 |
| 종료 | 프로젝트 종료 시 방을 정리하고, 남길 기록은 플랫폼으로 옮김 |
이 규칙에서 Project Lead가 가장 자주 부딪히는 것은 "결정" 항목입니다. 메신저에서 "그럼 그렇게 하죠"로 끝난 보상 변경은 나중에 반드시 분쟁이 됩니다. 실행은 빠르게, 이해관계 변경은 합의로. 그 합의는 플랫폼에 있어야 합의입니다.
유출이 발생했을 때
유출은 일어납니다. 완전히 막을 수는 없으며, 중요한 것은 얼마나 빨리 알고 얼마나 정직하게 다루는가입니다. 대응 절차는 다음 순서를 따릅니다.
- 발견과 신고(즉시). 유출을 발견하거나 자신이 유출했음을 인지한 사람은 Project Lead에게 즉시 알립니다. 자진 신고는 제11장의 기준에 따라 실패 쪽에 놓입니다. 숨기다가 발견되면 부정직입니다.
- 범위 확인(24시간 이내). Project Lead는 무엇이, 어디까지, 누구에게 나갔는지 확인합니다. Closed Room의 접근 기록이 여기서 쓰입니다. 메신저 방이라면 방 구성원과 전달 경로를 확인합니다.
- 고객 통보(48시간 이내). Cell-only 이상의 정보가 나갔다면 계약주체가 고객에게 알립니다. 늦게 알리는 것이 유출 자체보다 관계를 더 크게 훼손합니다. 통보에는 사실, 범위, 조치를 담고, 추측은 담지 않습니다.
- 확산 차단. 전달받은 사람에게 삭제를 요청하고 확인을 받습니다. 외부로 나갔다면 계약주체와 고객이 함께 대응 방향을 정합니다.
- 원인 기록과 위원회 회부. Project Lead는 경위를 플랫폼에 기록합니다. 고의성이 의심되거나 피해가 발생했으면 윤리·분쟁위원회(Ethics & Dispute Committee)에 회부합니다. 판단 기준은 제11장의 실패·부정직 구분을 따릅니다.
- 재발 방지. 등급 지정이 불명확했는지, 메신저 규칙이 지켜졌는지, NDA가 있었는지를 확인하고 Charter를 수정합니다.
유출에 대한 제재는 제11장의 단계를 따릅니다. 고의가 아닌 유출을 스스로 알린 경우는 경고 이하입니다. 등급을 알면서 외부에 제공한 경우는 참여 제한 이상이며, 대가를 받고 제공한 경우는 제명 사유입니다. 단체방에서 유출자를 지목하는 것은 어떤 경우에도 금지됩니다. 그것 자체가 또 하나의 유출입니다.
Case: 세미나 발표 자료의 두 가지 버전
가상의 사례입니다. 크리에이터 윤 씨는 Creator Circle에서 한 화장품 브랜드의 AI 광고 영상 프로젝트를 마쳤습니다. 프로젝트는 Cell-only 등급이었고, 브랜드와 계약주체 사이에는 NDA가 있었습니다. Circle Leader가 윤 씨에게 세미나 발표를 제안했습니다. 윤 씨는 발표 자료 초안을 Project Lead인 마케터 조 씨에게 보냈습니다.
초안에는 다음이 있었습니다. 브랜드 이름과 제품 이미지, 영상 제작에 쓴 도구와 프롬프트 구조, 세 가지 스타일을 비교한 결과, 브랜드가 승인한 최종 영상, 제작비 1,500만원과 기존 실사 촬영 대비 절감률, 그리고 브랜드가 다음 분기에 AI 영상으로 전면 전환한다는 계획.
조 씨는 초안을 등급별로 나눴습니다. 도구와 프롬프트 구조, 스타일 비교 결과는 윤 씨가 배운 것이므로 Community 등급으로 공유 가능했습니다. 브랜드 이름과 제품 이미지는 고객 식별 정보였습니다. 최종 영상은 이미 공개된 광고였으므로 Public이었지만, 그 영상을 보여주면 브랜드가 특정되므로 발표에서는 뺐습니다. 제작비와 절감률은 계약 조건이므로 Restricted였습니다. 전면 전환 계획은 사업 전략이므로 Restricted였습니다.
윤 씨는 처음에 반발했습니다. "브랜드 이름 없이 광고 사례를 어떻게 발표합니까." 조 씨의 답은 이랬습니다. "회원들이 알고 싶은 것은 브랜드가 아니라 어떤 프롬프트 구조가 왜 실패했는지입니다." 윤 씨는 발표 자료를 다시 만들었습니다. "한 뷰티 브랜드"로 표현하고, 스타일 비교는 브랜드 요소를 제거한 테스트 영상으로 대체했습니다. 절감률은 "실사 촬영 대비 절반 이하"로만 표현하고 금액은 뺐습니다. 전면 전환 계획은 전부 삭제했습니다.
세미나에서 가장 반응이 좋았던 부분은 실패한 두 가지 스타일의 원인 분석이었습니다. 브랜드 이름은 아무도 묻지 않았습니다. 발표 자료는 Community 등급으로 플랫폼에 올랐고, 윤 씨의 기여 기록에 Knowledge 항목이 추가되었습니다. 두 달 뒤 윤 씨는 그 발표를 본 파운더의 제안으로 새 프로젝트에 참여했습니다.
같은 사례에서 윤 씨가 초안 그대로 발표했다면 어떻게 되었을까요. 브랜드는 자신의 전환 계획이 세미나에서 언급된 것을 알게 되었을 것입니다. 계약주체는 NDA 위반 책임을 졌을 것이고, 조 씨는 발표 자료를 사전에 확인하지 않은 책임을 졌을 것입니다. 윤 씨는 배운 것을 나누려 했을 뿐이지만, 커뮤니티는 고객 하나와 평판을 잃었을 것입니다. 발표 자료를 Lead가 먼저 보는 절차는 그래서 있습니다.
Remember
- 배운 것은 공유하고, 맡은 것은 보호합니다. 경험·워크플로우·벤치마크·인사이트·실패담은 공유의 대상이고, 고객정보·계약조건·미공개 기술·사업전략·개인정보는 보호의 대상입니다.
- 정보는 Public / Community / Cell-only / Restricted 네 등급 중 하나에 속하며, 불확실하면 한 단계 위로 봅니다.
- Chatham House Rule은 침묵을 위한 규칙이 아니라 발언을 위한 규칙입니다. 내용은 쓰되 발언자와 조직은 특정하지 않습니다.
- 대화는 메신저에서 하더라도 관계·기여·기록은 플랫폼에 축적됩니다. 플랫폼에 없는 합의는 합의가 아닙니다.
- 유출은 숨기지 않고 즉시 알립니다. 자진 신고는 실패이고, 은폐는 부정직입니다.
"Confidential Community는 입을 닫는 커뮤니티가 아니라, 무엇을 열고 무엇을 닫을지 아는 커뮤니티다."