Report on the Designing Accountable Software Systems Workshop
미국 국립과학재단(NSF)의 지원을 받은 2024년 11월 '책임 있는 소프트웨어 시스템 설계(DASS)' 워크숍은 소프트웨어 책임성의 차원, 법적 프레임워크, 운영상의 과제를 탐구하기 위해 학제 간 이해관계자들을 소집하였으며, 궁극적으로 책임 소재를 명확히 하고, 소프트웨어 설계에 책임성을 통합하는 방안을 개선하며, 학제 간 협업의 독특한 요구사항을 해결하기 위한 핵심 연구 방향을 식별하였다.
원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기
당신은 거대하고 복잡한 로봇 도시를 건설하고 있다고 상상해 보세요. 이 도시에서는 소프트웨어가 신호등을 작동시키고, 은행 계좌를 관리하며, 대출 여부를 결정하고, 심지어 자동차를 운전합니다. 이 도시에 사는 사람들(사회)과 규칙을 만드는 사람들(정부)은 로봇 도시가 법을 준수하고 공정하게 행동하기를 기대합니다.
하지만 여기에 문제가 있습니다. 소프트웨어는 본래 "책임"을 지는 법을 알지 못합니다. 소프트웨어는 그저 시키는 대로 할 뿐입니다. 만약 실수를 저지른다면, 누구의 책임일까요? 개발자일까요? 회사일까요? 아니면 법일까요?
이 논문은 2024년 말, 컴퓨터 과학, 법학, 사회학, 경영학 분야의 전문가들이 모여 소프트웨어가 자신의 행동에 실제로 책임을 질 수 있도록 만드는 방법을 알아내기 위해 열었던 큰 회의(워크숍)에 대한 보고서입니다. 이것을 "설계자, 변호사, 도시 계획가들의 정상 회의"라고 생각하세요. 이들은 책임감 있는 로봇 도시를 위한 새로운 설계도를 구상하려 노력했습니다.
다음은 그들이 발견한 내용을 쉽게 설명한 것입니다.
1. "블랙박스" 문제
현재 소프트웨어가 규칙을 어길 때, 그것은 종종 블랙박스와 같습니다. 우리는 나쁜 결과는 보지만, 그것이 어떻게 일어났는지 또는 왜 일어났는지는 알지 못합니다.
- 비유: 어떤 요리사가 당신에게 독이 든 수프를 대접했다고 상상해 보세요. 만약 요리사가 단순히 "컴퓨터가 이 재료들을 섞으라고 해서 그랬다"라고 말한다면, 그것으로는 충분하지 않습니다. 우리는 소프트웨어 내부에 비행기처럼 모든 단계를 기록하는 "비행 기록 장치"가 있어서, 무슨 일이 일어났고 누가 책임이 있는지를 증명할 수 있어야 합니다.
- 발견 사항: 그룹은 소프트웨어가 자신의 행동을 자동으로 기록하는 '조작 불가능한' 일기를 작성하도록 설계해야 한다는 데 동의했습니다. 하지만 그들은 모든 것을 다 기록할 수는 없다는 점(데이터가 너무 많아짐)도 언급했습니다. 즉, 올바른 것들을 기록해야 합니다.
2. 언어의 장벽
가장 큰 장애물은 기술이 아니라, 전문가들이 서로 다른 언어를 사용한다는 점입니다.
- 비유: 변호사와 소프트웨어 엔지니어가 함께 다리를 건설한다고 상상해 보세요. 변호사는 "책임(liability)"과 "준수(compliance)"를 말하지만, 엔지니어는 "알고리즘(algorithm)"과 "지연 시간(latency)"을 말합니다. 그들은 "공정함"이나 "리스크"와 같은 같은 단어를 사용하지만, 의미하는 바는 완전히 다릅니다.
- 발견 사항: 연구자들은 이 그룹들이 함께 협력할 때 멋진 새로운 아이디어들이 나온다는 것을 발견했습니다. 그러나 서로의 어휘를 배우는 데는 오랜 시간이 걸립니다. 때로는 그들이 서로 읽는 사람이 없는 서로 다른 학술지에 논문을 쓰는 바람에 지식을 공유하기 어려워지기도 합니다.
3. "상징적" 함정
때때로 기업들은 실제로 책임을 지지 않으면서 책임지는 척만 하기도 합니다.
- 비유: 이는 가게 앞에 "우리는 안전을 중요하게 생각합니다"라는 표지판을 붙여놓고, 실제로는 비용을 아끼기 위해 뒷방에서 편법을 쓰는 것과 같습니다. 서류상으로는 좋아 보이지만(상징), 현실은 다릅니다.
- 발견 사항: 그룹은 우리가 단순히 "표지판"(감사 보고서)만 보는 것이 아니라, 실제 기계 장치를 들여다봐야 한다고 경고했습니다. 기업이 규칙을 따른다고 말하는 곳인지, 실제로 행하는 곳인지를 구별할 수 있는 도구가 필요합니다.
4. 움직이는 목표 (AI와 변화)
소프트웨어, 특히 AI는 끊임없이 변화합니다. 스스로 학습하고 적응합니다.
- 비유: 전통적인 안전 규칙은 레시피 북과 같습니다. "소금을 넣으면 수프가 짭짤해진다"와 같은 식이죠. 하지만 AI는 수프 맛을 보고 스스로 후추를 넣거나, 설탕을 넣거나, 식초를 넣기로 결정하는 요리사와 같습니다. 요리사가 요리하는 도중에 레시피를 계속 바꾸기 때문에 기존의 규칙들은 작동하지 않습니다.
- 발견 사항: 우리는 이 "학습하는" 소프트웨어가 여전히 규칙을 따르고 있는지 확인할 수 있는 새로운 방법이 필요합니다. 만약 소프트웨어가 마음을 바꾼다면, 그 과정에서 법을 어기지 않았음을 어떻게 알 수 있을까요?
5. "누가 책임자인가?"라는 퍼즐
문제가 발생했을 때, 책임을 규명하기 어려운 경우가 많습니다.
- 비유: 자율주행 자동차가 보행자를 쳤다면, 자동차의 잘못일까요? 지도 제작자의 잘못일까요? 차를 산 사람의 잘못일까요? 아니면 도로를 만든 도시의 잘못일까요?
- 발견 사항: 그룹은 소프트웨어를 만들기 전에 누가 책임을 질 것인지 명확히 정의해야 한다는 점을 깨달았습니다. 소프트웨어는 법에 책임을 져야 합니까? 대중에게 책임을 져야 합니까? 아니면 회사에 책임을 져야 합니까? 명확한 정의가 없다면 책임은 틈새로 빠져나가 버린다는 것을 발견했습니다.
6. "완벽함" 대 "현실 세계"
그룹은 결코 실수를 하지 않는 완벽한 소프트웨어를 만들 수는 없다는 점을 인정했습니다.
- 비유: 절대 사고가 나지 않는 자동차를 만들 수는 없지만, 사고가 났을 때를 대비해 에어백과 안전벨트가 있는 자동차는 만들 수 있습니다.
- 발견 사항: 소프트웨어가 절대 실패하지 않도록 만드는 대신, 혼란스러울 때 이를 인정하고, 인간이 개입할 수 있게 하며, 문제가 생겼을 때의 계획을 갖추도록 설계해야 합니다. 우리는 "불완전함"이 시스템의 일부임을 받아들여야 하지만, 그 결과는 반드시 관리해야 합니다.
핵심 요약
이 회의의 주요 결론은 소프트웨어의 책임 문제를 오직 코드만으로는 해결할 수 없다는 것입니다.
이것은 팀의 노력이 필요합니다. 도구를 만드는 컴퓨터 과학자, 규칙을 쓰는 변호사, 사람들의 반응을 이해하는 사회학자, 그리고 이를 실행에 옮기는 비즈니스 리더들이 모두 필요합니다. 만약 우리가 각자의 영역(silos)에서 따로 움직인다면, 우리는 실패할 것입니다. 소프트웨어의 미래는 이 서로 다른 집단들이 같은 언어를 배우고, 단순히 작동하는 것을 넘어 '제대로' 작동하는 시스템을 구축하는 데 달려 있습니다.
연구 분야의 논문에 파묻히고 계신가요?
연구 키워드에 맞는 최신 논문의 일일 다이제스트를 받아보세요 — 기술 요약 포함, 당신의 언어로.