21세기 개발자들을 괴롭히는 12가지 윤리적 딜레마

출처: http://www.itworld.co.kr/news/87319

 

과거부터 IT 업계에는 권력은 넘치는 반면 그 권력의 결과에 대한 고려는 부족했다. 뭔가를 만들 수 있다면 그 기술을 애초에 구현해야만 하는지에 대한 생각은 둘째치고, 더 안전하고 정상적인 방법이 있는지에 대한 고려조차 없이 무조건 만들고 봤다. 소프트웨어가 만들어진다. 그 소프트웨어가 어디서, 어떻게 사용되는지에 대해서는 아무도 관심이 없다. 모두에게 그것은 '다른 곳의 누군가가' 해야 할 일일 뿐이다.

더 큰 문제는 윤리학 과정이 공학 학위를 취득하는 데 있어 중요한 요소가 되었다 해도, 컴퓨터 과학 분야의 교육에서는 여전히 환영 받지 못하는 예외적인 요소로 취급되고 있다는 점이다. 소프트웨어가 일상에서 차지하는 비중이 커지면서 프로그래머가 내리는 의사 결정의 윤리적 파급력도 커지고 있다. 이제 냉장고, 온도조절기, 화재 경보기에까지 코드가 사용되고 있다. 그만큼 프로그래머의 잘못된 행동, 근시안적 생각, 또는 엉뚱한 의사결정은 온갖 곳에서 사람들에게 피해를 줄 수 있다.

다음은 개발자들이 알게 모르게 매일 직면하는 윤리적 고민이다. 작업의 본질 자체가 매우 추상적이기에 이런 상황들에 대한 쉬운 답은 없다. 게다가 비즈니스가 컴퓨터 기술과 긴밀하게 연결된 지금은 관여한 모든 당사자의 요구와 동기 사이에서 균형을 잡으면서 오늘의 비즈니스 케이스가 내일의 악몽이 되지 않도록 막기란 몹시 어려운 일이다.

방법은 지금의 관점을 벗어나 지금 만드는 것이 미래에 과연 어떻게 이용될지를 예상하는 것이다. 말로는 간단하지 않은가? 이 글은 의사 결정을 위한 가이드가 아니라, 우리 일상의 일부가 되어야 하는 윤리적 고찰의 시작점이다.

윤리적 딜레마 1: 로그 파일 – 무엇을 저장하고, 어떻게 처리할 것인가
프로그래머는 이것저것 모으는 습성을 가진 산다람쥐와 같다. 온갖 것의 기록을 보관한다. 많은 경우 그것만이 시스템을 디버깅할 수 있는 유일한 방법이기 때문이다. 그러나 로그 파일은 사용자가 하는 모든 행위도 추적하므로 엉뚱한 사람 손에 들어갈 경우 사용자가 비밀로 지키고자 하는 정보가 노출될 위험도 함께 갖고 있다.

로그 파일 보호를 주 업무로 하는 기업들도 많다. 어떤 원격 백업 서비스 업체는 지리적으로 분산된 여러 위치에 부가적으로 복사본을 보관해 주기까지 한다. 그러나 이와 같은 철두철미함과는 반대되는 방향에서 답을 찾는 기업들도 있다. 예를 들어 스냅챗(Snapchat)은 오히려 데이터 백업을 하지 않는 방식의 비즈니스로 유명한데, 사용자들은 마음 편하게 잊어도 되는 그 자유로운 시스템에 매료되고 있다.

로그 파일은 그 존재 자체가 여러 가지 윤리적 질문을 던진다. 충분히 보호되는가? 누가 접근할 수 있는가? 로그를 삭제한다는 것은 정말 완전히 폐기하는 것을 의미하는가?

윤리적인 측면의 위험성을 감안할 때 쟁점은 보관할 가치가 있는 정보를 알아내는 것에 있다. 여기에 미래라는 요소가 문제를 더 복잡하게 만든다. 1960년대에는 흡연이 폭넓게 용인되었다. 사람들의 흡연 습관을 기록하면서 고민하는 사람은 아무도 없었다. 그러나 지금은 누군가의 흡연 행위에 대한 정보는 건강보험료 인상, 심지어 가입 거부에도 사용될 수 있다.

미래의 비즈니스 거래, 미래의 정부 규제, 예측하지 못한 새로운 매출원에 대한 절실한 필요성 – 지금은 아무런 문제도 없는 로그 파일이 미래에 문제가 되는 경우를 예측하기란 사실 불가능하지만 로그를 어떻게 취급할 것인지에 대한 윤리적 측면을 반드시 고려해야 한다.

윤리적 딜레마 2: 사용자를 상품으로 바꿀 것인가, 바꾼다면 어떤 방법으로 바꿀 것인가
벤처기업이 부흥했던 시절 흔히 했던 말로 '서비스에 돈을 지불하지 않는 사람은 고객이 아니라 상품'이라는 말이 있다.

인터넷에는 "무료" 서비스가 널렸다. 사실 돈이 어디서 나올 것인가라는 질문은 뒤로 미루는 경우가 많다. 그저 놀라운 무언가를 만들고, 사람들이 그것을 얼마나 사용하는지 지켜보고, 서버를 계속 가동하는 힘든 일은 다른 누군가에게 맡길 뿐이다. 가장 나쁜 요소는 넘쳐나는 광고다.

개발자들은 누가 자신의 작업을 지지하며, 돈은 어디서 나오는지에 대해 솔직해져야 한다. 충격과 역풍을 피하려면 모든 변경을 명확하게, 적시에 사용자에게 전달해야 한다. 사람들을 상품화하는 것은 결코 가볍게 여겨서는 안 되는 윤리적인 문제다. 은밀한 광고 거래, 은밀한 광고 네트워크 – 얼리 어댑터들의 무조건적 신뢰에 어떻게 보답해야 할지, 신중하게 생각할 필요가 있다.

윤리적 딜레마 3: 콘텐트는 얼만큼 자유로워야 하는가?
콘텐트를 만든 사람에게 돈을 지불하지 않고 그 콘텐트를 이용해 사업을 하는 기업들이 있다. 광고를 팔기도 하고, 콘텐트 접근에 대해 과금을 하는 경우까지 있다. 개발 비용을 정당하게 부담해야 한다면 이러한 기업들은 생존하지 못하고 매력적인 가격을 제안하지도 못할 것이다. 이들은 윤리적으로 문제의 소지가 있는 의사 결정을 감추기 위해 "공유" 또는 "공정한 사용"에 대한 합리화 근거를 그럴듯하게 만들어낸다.

개발자는 자신의 코드가 제작자부터 소비자에 이르는 먹이사슬의 모든 이를 어떻게 지원하는지 스스로에게 질문해야 한다. 콘텐트를 만드는 사람들이 이런 방식으로 자신의 작업물이 배포되기를 원하는가? 그 사람들은 유명세와 관심만으로 정말 만족하는가? 그들에게 공정하게 수익금을 분배하고 있는가?

이러한 질문을 배제하는 것은 해적 행위를 모른척하는 것과 다름없다. "무료가 되기를 원하지 않는" 정보도 있는 법이다.

윤리적 딜레마 4: 충분한 보호란 어느 정도의 보호인가
모든 데이터는 두 가지 알고리즘으로 두 번 암호화해서 하드디스크에 넣고 잠근 다음 하드디스크를 금고에 보관해야 한다는 사람도 있다. 물론 그로 인한 과부하는 시스템 속도를 극단적으로 늦추고, 개발 작업을 10배는 더 어렵게 만들 것이다. 게다가 하나의 비트가 틀어지거나 알고리즘의 한 부분이 잘못되면 암호화된 데이터를 해독할 수가 없으므로 모든 데이터를 잃게 된다.

반면 데이터 보호를 위한 노력을 전혀 하지 않는 사람들도 있다. 개발자는 '필요하면 다음에 작업을 넘겨받을 팀이 암호화를 추가하겠지'라고 생각하기도 한다. 또는 그 데이터에는 민감한 자료가 없다고 주장할 수도 있다. 이러한 책임을 무시하는 팀은 보통 대량의 코드를 쏟아내며 사람들이 좋아하는 멋진 기능을 많이 만들어낸다. 안전한지 여부 따위 누가 신경 쓴단 말인가?

얼만큼 보호해야 하는가에 대한 간단한 답은 없다. 추정만 있을 뿐이다. 보호 수단은 많을수록 좋다. 그로 인해 데이터를 잃거나 제품 출시가 가로막히는 일이 생기기 전까지는.

윤리적 딜레마 5: 버그를 수정할 것인가, 그냥 둘 것인가?
당면한 의사 결정에 수반되는 윤리적 문제에 대한 협상도 어렵지만 더욱 어려운 것은 '언젠가 수정할 버그'라는 이름표를 붙여 문제를 미뤄두는 경우다. 실행 중인 코드에 존재하는 문제를 수정하는데 얼만큼의 노력을 기울여야 할까? 만사를 제쳐두고 수정해야 할까? 버그가 수정이 필요할 만큼 심각하다는 판단 기준은 무엇일까?

소설가 아이작 아시모프는 오래 전에 로봇에 적용되는 법칙에 대한 글을 쓰면서 이 문제에 직면했고, 로봇의 무행동으로 인해 인간이 해를 입을 수 있는 경우 로봇이 아무런 행동도 취하지 않는 것을 금지하는 법칙을 만들어 넣었다. 물론 아시모프의 로봇은 순간에 문제의 모든 측면을 꿰뚫어 보고 해결하는 양전자 두뇌를 가졌다. 개발자에게 이 질문은 너무 복잡하다. 누구나 생각조차 하기 싫어하기 때문에 많은 버그들이 무시되고 수정되지 않은 채 방치된다.

회사는 공정하게 목록의 우선 순위를 정할 수 있을까? 어떤 고객을 다른 고객보다 더 우선해도 될까? 버그를 취사선택하는 데 있어 프로그래머는 편파적일 수 있을까? 어떤 버그로 인해 나타날 피해의 정도를 예측하기가 어렵다는 사실을 인지할 때 이 문제는 더욱 어려워진다.

윤리적 딜레마 6: 악용을 방지하기 위한 코드는 얼만큼 작성(또는 타협)해야 하는가
최초의 애플 웹캠에는 전원이 꺼질 경우 물리적인 가림막이 렌즈를 막는 재치 있는 기계적 장치가 있었다. 가림막과 스위치는 서로 연결되어 있었기 때문에 사용자가 직접 가림막을 열지 않고는 카메라를 사용할 방법이 없었다.

요즘 나오는 웹캠 중 일부에는 카메라가 활성화될 때 조명이 켜지도록 설계된 LED가 붙어있다. 정상적이라면 설계대로 작동하겠지만 컴퓨터를 프로그램한 경험이 있는 사람이라면 누구나 카메라와 LED의 연결을 끊을 수 있는 코드가 어딘가 분명히 있다는 사실을 알 것이다. 그 코드를 찾을 수 있다면 카메라를 감시 장치로 만들 수도 있다.

엔지니어의 과제는 악용을 예상하고 그 악용을 차단하도록 설계하는 것이다. 애플의 가림막은 그러한 설계를 멋지게 구현하는 방법에 대한 아주 좋은 예다. 필자는 SAT 커닝에 대한 글을 쓸 당시 계산기에 네트워킹 소프트웨어를 추가하는 중이었던 한 해커를 만났다. 그 해커는 심사숙고 끝에 유선 프로토콜만 지원하기로 결심했다. 학생들이 와이파이를 탑재한 계산기를 가지고 들어가 시험에 이용할 가능성을 우려했기 때문이다. 유선 프로토콜만 지원했기 때문에 계산기를 사용하려면 근처의 컴퓨터에 직접 선을 연결해야만 했다. 이 해커는 무선 프로토콜을 생략하는 것을 몹시 아쉬워했지만 악용의 위험이 너무 크다고 판단했다.

윤리적 딜레마 7: 데이터 요청에 대해 얼마만큼 고객을 보호해야 하는가
데이터를 수집하는 기업이라면 언젠가는 분명히 고객과 정부 사이에서 선택해야 할 때가 온다. 사법기관에 데이터를 넘기라는 요구가 점차 보편화되고 있고, 그로 인해 소프트웨어 및 서비스 기업들은 법 앞에서 고객의 프라이버시를 어느 선까지 배신해야 할지 고민해야 하는 상황이다. 데이터 요청에 대해 면밀히 조사하고 더 나아가 변호사를 고용해서 데이터 요청이 정말 합법적인지 여부에 대해 법적으로 논쟁을 벌일 수도 있겠지만, 현실적으로 법원이 그 합법성에 대한 결론을 내리기 훨씬 전에 그 회사의 돈은 바닥날 것이다.

쉬운 답은 없다. 고객에게 거짓말을 하며 사업하느니 그 사업을 접는 쪽을 택하는 기업도 있고, 정부의 데이터 요청을 공개하려 노력하는 기업들도 있다. 다만 많은 경우 정부는 그러한 공개를 금지하려 든다.

윤리적 딜레마 8: 인터넷의 국제적인 속성에 어떻게 대처할 것인가
인터넷은 전통적인 국경의 장벽을 너머 어디로든 뻗어나간다. 이러한 이유로, 고객 A와 B가 서로 다른 국가에 있는 경우 법적인 고민거리가 발생하게 된다. 그게 끝이 아니다. 서버 C와 D 역시 서로 다른 국가에 위치하는 경우가 많다.

이러한 상황은 분명 윤리적 문제로 이어진다. 예를 들어 유럽은 개인 정보의 보관에 대한 엄격한 법률을 두고 있으며, 사생활 침해를 윤리적 실패로 간주한다. 그런가 하면 기업들에게 거래에 대한 방대한 기록을 보관하도록 요구하는 국가들도 있다. 고객이 여러 국가에 있다면 그 회사는 어느 나라의 법에 따라야 할까? 데이터가 서로 다른 국가에 존재한다면? 데이터가 국경 너머로 전송되는 경우에는?

모든 법적인 사태에 대비하기란 너무 어려운 일이고 그래서 많은 기업들은 그냥 현실을 외면하고 싶은 유혹에 빠진다.

윤리적 딜레마 9: 오픈 소스에 얼마나 되돌려줘야 하는가
모두가 알다시피 오픈 소스는 무료다. 아무런 비용도 지불하지 않으며 바로 그런 이유로 오픈 소스는 멋지고도 복잡하다. 그러나 모두가 이 무료 코드를 사용하는 데 따르는 윤리적 문제에 대해 고민하는 것은 아니다. 모든 오픈 소스 패키지에는 라이선스가 함께 제공되며 오픈 소스 사용자는 이 라이선스의 내용을 준수해야 한다.

일부 라이선스는 별다른 희생을 요구하지 않는다. 아파치 라이선스 또는 MIT 라이선스의 경우 그저 라이선스의 인정을 요구할 뿐이고 그 외에는 없다. 그러나 GNU 일반 공용 라이선스와 같이 코드에 대한 모든 개선 작업을 공유할 것을 요구하는 경우도 있다.

오픈 소스 라이선스 문구를 살펴보면 윤리적인 과제가 드러난다. 한 대형 공공 기업의 관리자가 필자에게 이렇게 말했다. "우리는 MySQL을 배포하지 않기 때문에 누구에게도 아무것도 빚지지 않았다." 그는 라이선스의 의무 사항을 소프트웨어 재배포 행위에 묶은, 수십 년 전에 만들어진 라이선스 구절에 초점을 맞춘 것이다. 이 회사는 웹 애플리케이션용으로 MySQL을 사용했으므로 그는 아무것도 기여하지 않고 가져가기만 해도 된다고 생각한 것이다.

윤리적인 의무를 측정하는 간단한 방법은 없고 많은 프로그래머들이 그 의미를 두고 해답 없는 논쟁을 벌이느라 시간을 낭비했다. 그러나 사람들이 기여를 중단한다면, 결국 모든 오픈 소스 노력은 서서히 그 움직임을 멈추게 될 것이다. 다행인 사실은 기여가 모두에게 최선의 이익인 경우가 많다는 점이다. 모든 사람들이 오픈 소스 소프트웨어가 자신이 사용하는 것과 호환성을 유지하기를 원하기 때문이다.

윤리적 딜레마 10: 모니터링은 어디까지 정당화되는가
사장은 고객이 회사의 수익을 갉아먹지 않기를 원한다. 개발자는 그저 하는 일에 대해 대가를 받기를 원한다. 정부 관리가 말하길 악당을 잡으려면 백도어를 설치해야 한다고 한다. 어떤 경우든 백도어가 마치 슈퍼맨의 힘처럼 진실과 정의를 위해서만 사용될 것이라는 보장이 넘쳐난다. 정치적 적을 향해, 또는 약자를 향해 사용되지 않을 것이라고 한다. 독재적인 정권에 팔리지 않을 것이라고 한다.

그러나 만일 악당이 숨겨진 문을 발견하고 직접 그 문을 사용하는 방법을 알아낸다면? 백도어가 거짓과 부당을 위해 사용된다면? 코드는 스스로 윤리적 결정을 내릴 수 없다. 그건 개발자들이 해야 할 일이다.

윤리적 딜레마 11: 코드의 방어 능력은 어느 정도여야 하는가
물론 최소한의 계산, 단순한 데이터 구조, 무식하게 밀어붙이는 접근 방법은 문제의 규모가 작은 데모에서는 잘 통한다. 사용자들은 코드를 실험해보고 "아주 빠른데!"라고 말한다. 몇 달 후, 시스템에 충분한 데이터가 로드되자 싸구려 알고리즘의 약점이 드러나고 코드의 속도는 한없이 느려진다.

개발자는 최종 제품을 위해 얼만큼 노력을 기울일지 결정해야 하는 경우가 많다. 빠르고 저렴한 솔루션을 막 쏟아내는가, 아니면 극한의 경우에도 대처하는 튼튼한 코드를 추가하기 위해 몇 주를 소비하는가? 물론 클라이언트와 사용자도 요구 사항 전달 시점에 일부분 책임이 있겠지만 실행 코드의 잠재적인 문제점을 예측하는 데 있어 아무래도 개발자가 더 유리한 위치에 있는 경우가 많다.

윤리적 딜레마 12: 미래에 나타날 결과가 현재의 의사 결정에 얼만큼 영향을 미쳐야 하는가
대부분의 프로젝트에서 정보는 한 번 들어가면 밖으로 새나오지 않는다. 그러나 일부 정보는 스스로 생명력을 갖고 밖으로 뛰쳐나와 막대한 해를 입힌다. 보안, 침투 테스트, 간첩 활동 –코드의 부수적인 피해를 고려하기 위한 확실한 후보들이다.

이란의 우라늄 정화에 사용되는 원심분리기를 공격하기 위한 도구라고 간주되는 바이러스인 스턱스넷을 보자. 그 목적은 달성했을지도 모른다. 그러나 그 이후 지금도 살아남아서 전세계 윈도우 시스템 사이를 떠다니고 있다.

대부분의 개발자에게 부수적인 피해는 명확하게 다가오지 않는다. 우리는 지금을 위해 코딩하지만(그것만으로 충분히 힘들다) 미래도 고려해야만 한다.

예를 들어 일부 프로그래머는 운영체제와 통합되어 새롭거나 더 복잡한 드라이버를 설치하는 복잡한 코드를 즐겨 작성한다. 그 코드가 미래에도 작동할까? 다른 새로운 드라이버들과 잘 연동될까? 차세대 OS에서 작동할까? 아니면 수시로 장애를 일으키는 느려터진 컴퓨터를 사람들에게 남겨주게 될까?

보기에는 단순하지만 API를 고수할지 또는 표준에 따를지 여부의 선택은 윤리적인 의사 결정이다. 물론 기술은 빠르게 발전하고 과거에 노예처럼 헌신하는 것은 발전을 저해할 수 있다. 그러나 긴 수명을 가진 코드를 만들 때 개발자가 할 일에 대해 생각해야 하며, 정도를 벗어나는 의사 결정을 결코 가볍게 여겨서는 안 된다. 개발자는 필요하면 언제든 표준 또는 API에 변경을 요청할 수 있다.