What If We Work Together? Fostering Reflections on Designer Inclusion in Open Source Software Through Speculative Design
본 논문은 오픈소스 소프트웨어 실무자들 사이에서 비판적 성찰을 촉발하기 위해 두 개의 가상의 사회를 통해 사변적 설계를 활용함으로써, 커뮤니티의 개발자 중심적 사고방식을 해소하고 디자이너들을 위한 보다 포용적인 환경을 조성하는 것을 목표로 한다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
오픈 소스 소프트웨어 (OSS) 를 거대하고 분주한 건설 현장으로 상상해 보세요. 수십 년간 이 현장은 건물의 구조적 안정성, 배관 시스템, 전기 흐름에 집착하는 엔지니어와 건축가들만이 운영해 왔습니다. 그들은 그 부분에서 매우 탁월합니다. 하지만 건물의 '내부'에 너무 집중하다 보니, 벽을 칠하거나 편안한 손잡이를 설치하거나 방이 쉽게 이동할 수 있도록 하는 일을 종종 잊어버립니다.
그 결과, 이 건물은 놀라울 정도로 강력하지만, 엔지니어가 아닌 사람이 안으로 들어오면 어둠 속에서 미로를 헤매는 듯한 느낌을 받습니다.
이 논문은 묻습니다: 만약 인테리어 디자이너들을 건설 현장으로 초대한다면 어떨까요?
연구자들은 디자이너들이 도움을 주고 싶어 하지만 환영받지 못한다고 느끼며, 도구들에 혼란을 겪고, 종종 자신의 작업이 '진짜' 작업이 아니라고 말받는다고 발견했습니다. 이를 해결하기 위해 연구자들은 단순한 규칙 목록을 작성하는 대신 **사유적 설계 (Speculative Design)**라는 방법을 사용했습니다. 이는 건설 팀에게 두 가지 완전히 다른 미래를 보여주기 위해 두 대의 '만일' 시간 여행을 구축하는 것과 같습니다. 이를 통해 그들을 깨우고 오늘날의 작업 방식에 대해 다르게 생각하게 하려는 것입니다.
두 가지 '만일' 세계
연구자들은 현재의 현실을 비추는 거울 역할을 할 두 가지 가상의 사회를 만들었습니다:
1. 허브 (Husia): 궁극적인 팀 하들
모든 사람이 하나의 거대하고 행복한 가족의 일부인 세상을 상상해 보세요. '내' 디자인이나 '너'의 코드라는 개념은 없으며, 모든 것이 그룹에 속합니다.
- 작동 방식: 새로운 디자이너가 도착하면 친근한 로봇 가이드 ('중앙 보드') 가 즉시 무엇을 해야 할지 정확히 보여주고, 그들이 잘하는 작업과 매칭해 줍니다. 그들은 벽이 사용자의 필요를 상기시켜 주는 하이테크 공간에서 작업합니다.
- 교훈: 이 세상에서는 누가 공로를 얻는지 싸우는 사람이 없습니다. 초점은 순수하게 커뮤니티를 돕는 데 맞춰져 있습니다.
- 현실 점검: 연구자들은 '공로 인정'이 중요하지만, 현재 시스템은 종종 디자이너들이 보이지 않는 존재처럼 느끼게 만든다는 점을 이 세계를 통해 보여주었습니다. 하지만 공로를 완전히 제거하면 일부 사람들은 "왜 그렇게 열심히 일해야 하지?"라고 의문을 품을 수도 있음을 보여주었습니다.
2. 평판 도시 (Reetar): 고위험 게임
이제 사회적 지위가 '평판 점수'라는 화폐인 세상을 상상해 보세요. 좋은 작업을 하면 점수를 얻고, 실수를 하면 잃습니다.
- 작동 방식: 이 세상에서 디자이너는 필수적입니다. 제품이 못 생기면 점수가 떨어지기 때문입니다. 개발자와 디자이너는 서로 긴밀히 협력해야 합니다. 그렇지 않으면 그들의 '점수'가 떨어지기 때문입니다. 이 시스템은 서로 대화하도록 강제합니다.
- 교훈: 이 세계는 디자이너들이 현재 과소평가되고 있음을 강조합니다. 이 미래에서는 그들의 작업이 생존의 열쇠입니다.
- 현실 점검: 연구자들은 이 시스템이 존중을 강제하지만, 동시에 사람들이 서로 돕는 것보다 '점수 따기'에 더 집중할 수 있는 치열한 환경을 조성한다는 점을 보여주었습니다.
이 세계들을 보여줬을 때 무슨 일이 일어났을까요?
연구자들은 실제로 오픈 소스 프로젝트에 참여하는 12 명 (디자이너 7 명, 개발자 5 명) 을 초대하여 이 두 세계를 방문하게 했습니다. 단순히 "이게 마음에 드세요?"라고 묻지 않고, "이것이 현재 일에 대해 어떻게 느끼게 합니까?"라고 물었습니다.
그 결과 모든 사람에게 전구가 켜지는 순간이 찾아왔습니다. 그들이 깨달은 바는 다음과 같습니다:
- '오픈' 신화: 모든 사람은 오픈 소스가 이미 모두에게 열려 있다고 생각했습니다. 하지만 이 세계들을 바라보며 그들은 "잠깐, 코드는 열려 있지만, 도구와 프로세스는 디자이너들을 겁나게 하는 기술 용어의 장벽 뒤에 잠겨 있구나"라고 깨달았습니다.
- 오해: 개발자들은 종종 디자이너가 단순히 '예쁘게 만드는' 역할이라고 생각한다는 점을 깨달았습니다. 시나리오는 디자인이 코딩과 마찬가지로 문제 해결에 관한 것임을 보여주었습니다.
- 공로 위기: 디자이너들은 자신이 인정받지 못한다고 느끼지만, 개발자들은 누가 무엇을 했는지 추적할 수 있는 방법이 없으면 누가 '감사'를 받아야 할지 알기 어렵다는 점을 깨달았습니다.
교훈: 건설 현장을 어떻게 고칠 것인가
이러한 극단적인 미래를 바라보며 참가자들은 현재 '건설 현장'을 디자이너에게 더 나은 곳으로 만들기 위한 실용적인 아이디어를 도출했습니다:
- 더 나은 환영 매트 구축: 허브의 '중앙 보드'처럼 프로젝트는 디자이너들이 코드 속에서 길을 잃지 않도록 명확하고 간단한 가이드가 필요합니다.
- 디자이너에게 자리 제공하기: 건물이 완성된 후에 디자이너를 불러 문장을 고치게 하지 마세요. 처음부터 청사진을 계획하는 데 그들이 참여하도록 하세요.
- '디자인 깃허브' 만들기: 개발자들은 코드 변경 사항을 추적하는 시스템을 가지고 있습니다. 디자이너들이 작업을 잃지 않고 그림을 저장, 공유, 업데이트할 수 있는 유사한 시스템이 필요합니다.
- 크게 '감사합니다'라고 말하기: 디자이너가 사용자 인터페이스를 수정할 때, 프로젝트는 개발자가 버그를 수정할 때와 마찬가지로 그것을 크게 알려야 합니다.
결론
이 논문은 단순히 사람들에게 "더 친절해지라"거나 "더 열심히 일하라"고 말하는 것만으로는 안 된다고 주장합니다. 문화를 바꿔야 합니다. 이러한 상상력 넘치는 '만일' 이야기를 통해 연구자들은 오픈 소스 커뮤니티가 자신의 맹점을 보도록 도왔습니다. 그들은 누구나 사용할 수 있는 소프트웨어를 만들기 위해서는 디자인을 사후 처리로 여기는 것을 멈추고 팀의 핵심 부분으로 여기기 시작해야 한다는 점을 깨달았습니다.
이는 집이 단순히 지붕과 네 개의 벽이 아니라 '집'임을 깨닫는 것과 같습니다. 그리고 집을 '집'으로 만들기 위해서는 엔지니어와 디자이너가 첫 벽돌부터 함께 일해야 합니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.