개발자가 'AS IS'를 숭배해야 하는 진짜 이유

당신이 깃허브(GitHub)나 수많은 오픈 소스 라이선스 텍스트를 스크롤하다 보면, 반드시 마주치는 거대한 장벽이 있다. 소문자로 조곤조곤 이야기하던 텍스트가 갑자기 고함을 치듯 대문자로 돌변하는 구간이다. "THE SOFTWARE IS PROVIDED 'AS IS', WITHOUT WARRANTY OF ANY KIND..." 마치 개발자가 당신의 멱살을 잡고 소리치는 듯한 이 문구. 우리는 이것을 대충 "보증을 안 해준다는 뜻이겠지"라고 넘겨짚고 만다. 하지만 당신이 정말 궁금해해야 할 지점은 따로 있다. 왜 하필 'As Is'인가?

"No Warranty(보증 없음)"라는 직관적이고 쉬운 영단어가 있다. "No Responsibility(책임 없음)"라는 더 명확한 표현도 있다. 그런데 왜 굳이 문법적으로도 애매해 보이고, 직역하면 "있는 그대로"라는 뜬구름 잡는 소리 같은 단어가 전 세계 법조계와 소프트웨어 업계를 지배하게 되었을까? 이것은 단순한 관용구가 아니다. 이 두 단어는 수천 년을 이어온 상거래의 역사와, 자본주의의 법적 운영 체제인 '미국 통일상법전(UCC)'이 만들어낸 가장 강력하고 위험한 마법 주문이다. 오늘 나는 당신을 코딩의 세계가 아닌, 차가운 법의 역사 속으로 안내하려 한다. 이 지루해 보이는 법률 용어 속에 오픈 소스 생태계의 생존 본능이 숨어 있기 때문이다.

매수인이여, 조심하라: Caveat Emptor의 부활

시계바늘을 수천 년 전 로마 시대로 돌려보자. 당신이 말(Horse)을 한 마리 산다고 가정해 보자. 시장에서 말을 샀는데, 집에 와서 보니 이 말이 다리를 절뚝거린다. 당신은 당장 판매자에게 달려가 환불을 요구할 것이다. 하지만 로마법은 당신에게 차갑게 미소 지으며 이렇게 말한다. "Caveat Emptor(카비앗 엠터)." 라틴어로 "매수인이 주의하라(Let the buyer beware)"는 뜻이다. 물건을 살 때 꼼꼼히 살피지 않은 것은 당신의 잘못이며, 일단 돈과 물건이 오갔다면 그 뒤에 발견된 결함은 온전히 구매자의 책임이라는, 판매자에게 무한히 유리한 원칙이다.

이 야생적인 원칙은 근대 상법이 발달하면서 힘을 잃었다. 소비자를 보호해야 한다는 인식이 생겨났고, 판매자는 물건에 대해 '명시적으로 보증하지 않아도' 당연히 정상적인 물건을 팔아야 할 의무를 지게 되었다. 이것을 우리는 '묵시적 보증(Implied Warranty)'이라고 부른다. 당신이 마트에서 우유를 살 때 "이 우유는 상하지 않았습니다"라는 계약서를 쓰지 않아도, 상한 우유를 팔면 마트가 처벌받는 이유가 바로 이 묵시적 보증 때문이다.

그런데 소프트웨어, 특히 '무료'로 배포되는 오픈 소스 세계에서 이 '묵시적 보증'은 재앙이다. 개발자가 선의로 코드를 올렸는데, 누군가 그 코드를 쓰다 서버가 터졌다고 해서 "정상적인 물건을 팔 의무"를 들어 소송을 건다면? 전 세계 모든 개발자는 파산할 것이다. 그래서 변호사들은 고대의 'Caveat Emptor'를 현대적으로 부활시켜야 했다. 묵시적 보증을 0으로 만들고, 모든 위험을 다시 구매자(사용자)에게 떠넘기는 핵버튼이 필요했다. 그 핵버튼의 이름이 바로 'As Is'다.

UCC 제2-316조: 묵시적 보증을 살해하는 주문

미국의 상거래를 지배하는 가장 권위 있는 법전인 '미국 통일상법전(Uniform Commercial Code, UCC)'을 펼쳐보면, 제2-316조에서 우리는 이 기묘한 단어의 정체를 마주하게 된다. 이 조항의 제목은 "보증의 배제 또는 수정(Exclusion or Modification of Warranties)"이다.

법은 기본적으로 구매자 편이다. 판매자가 "나는 보증 안 해!"라고 작게 속삭여도, 법은 "아니, 너는 상인니까 기본은 책임져야지(상품성 보증)"라고 강제한다. 이 강력한 법적 강제를 무력화하려면, 법이 인정한 특수한 '면책 언어'를 사용해야 한다. UCC 제2-316조 3항 a호는 놀라울 정도로 구체적으로 이렇게 명시하고 있다.

"All implied warranties are excluded by expressions like 'as is', 'with all faults' or other language which in common understanding calls the buyer's attention to the exclusion of warranties and makes plain that there is no implied warranty."

번역하자면, "'있는 그대로(as is)', '모든 결함이 있는 채로(with all faults)' 같은 표현을 사용하면 모든 묵시적 보증은 배제된다"는 것이다. 즉, 'As Is'는 단순한 단어가 아니라, 법전에 박제된 '코드(Code)' 그 자체다. 당신이 라이선스 파일에 'No Warranty'라고 쓰면 법정에서 다툼의 여지가 생길 수 있다. 판사가 "무슨 보증이 없다는 거지? 명시적 보증만 없다는 건가? 묵시적 보증은 남아 있는 거 아닌가?"라고 태클을 걸 수 있다.

하지만 'As Is'라고 쓰는 순간, 게임은 끝난다. 이것은 법이 공인한 치트키다. 이 단어가 등장하면 판사는 더 이상 묻지 않는다. "아, 판매자는 물건의 상태에 대해 입을 닫았고, 구매자는 그 위험을 알고 가져갔군." 판결은 거기서 종료된다. 이것이 리누스 토발즈부터 거대 IT 기업의 변호사들까지 모두가 약속이나 한 듯 'As Is'를 고집하는 이유다.

언어의 논리: 상태(Condition)와 행동(Action)의 괴리

당신은 여전히 억울할 수 있다. "있는 그대로"라는 말이 어떻게 "품질 보증 배제"가 되는가? 언어학적으로 파고들어 보자. 'As Is'는 "As it is"의 줄임말이다. "그것이 존재하는 상태 그대로"라는 뜻이다.

일반적인 거래에서 판매자는 물건에 '가치'를 더해서 판다. 검수를 하고, 닦고, 포장한다. 즉, '완벽한 상태(To Be)'를 지향한다. 그러나 'As Is'는 이 지향성을 거부한다. "나는 이 물건이 어때야 한다(Should be)고 말하지 않겠다. 나는 오직 지금 내 눈앞에 있는 이 상태(Is)로만 넘긴다."

이것은 묘한 논리적 도약을 만들어낸다. "현재 상태 그대로 넘긴다"는 말의 이면에는 "나는 이 물건이 작동한다고 말한 적 없다", "나는 이 안에 바이러스가 없다고 말한 적 없다", "나는 이것이 당신의 컴퓨터를 폭파시키지 않는다고 말한 적 없다"는 함의가 깔려 있다.

법률적으로 이것은 '진술(Representation)'의 부재를 의미한다. 판매자가 물건에 대해 아무런 진술도 하지 않았으므로, 거짓말을 한 적도 없게 된다. 사기죄나 계약 위반이 성립하려면 "좋은 물건이라고 속였다"는 전제가 있어야 하는데, "쓰레기일 수도 있는 상태 그대로 가져가라"고 했으니 속인 게 없다. 'As Is'는 개발자를 '거짓말쟁이'가 될 수 없는 위치로 피신시키는 완벽한 알리바이다. 당신이 수정을 하든 말든, 그건 물건을 가져간 이후의 당신 사정이고, 개발자는 물건을 넘기는 그 순간의 '정지 화면'에 대해서만 이야기하는 것이다.

왜 대문자로 소리치는가: '현저성'의 미학

이제 마지막 의문이 남는다. 왜 항상 대문자(ALL CAPS)인가? 소스 코드를 열어보면 라이선스 부분만 마치 캡스락(Caps Lock) 키가 고장 난 것처럼 대문자로 가득하다. 개발자들이 화가 나서 그런 게 아니다. 이 역시 법 때문이다.

앞서 언급한 UCC와 미국 법원들은 면책 조항이 효력을 발휘하기 위한 조건으로 '현저성(Conspicuousness)'을 요구한다. 소비자의 권리를 제한하는 중요한 내용은 깨알 같은 약관 속에 숨겨두면 안 되고, 누가 봐도 눈에 띄게, 시각적으로 두드러지게 작성해야 한다는 원칙이다.

만약 당신이 소심하게 소문자로 "this software is provided as is..."라고 적어두었다면? 영악한 변호사는 법정에서 이렇게 주장할 것이다. "존경하는 판사님, 제 의뢰인은 시력이 좋지 않아 그 중요한 면책 조항을 미처 보지 못했습니다. 이것은 은폐된 조항이므로 무효입니다."

그래서 개발자들은 소리쳐야 한다. 텍스트 파일에서 시각적으로 두드러지는 가장 확실한 방법은 대문자뿐이다. 볼드체나 색상을 쓸 수 없는 텍스트 파일(txt)의 한계 속에서, 대문자는 "나 여기 있다! 제발 읽어라! 나중에 딴소리하지 마라!"라고 외치는 법적 안전장치다. 그 투박한 대문자 덩어리들은 개발자의 게으름이 아니라, 살벌한 소송 전쟁터에서 살아남기 위한 처절한 비명인 셈이다.

국제 무역과 소프트웨어의 기묘한 동거

재미있는 사실은, 소프트웨어는 물리적인 물건(Goods)이 아님에도 불구하고 물건을 다루는 상법의 적용을 받는다는 점이다. 초기에 법원은 소프트웨어를 '서비스'로 볼지 '상품'으로 볼지 혼란스러워했다. 서비스라면 전문가로서의 엄격한 책임(의사가 수술을 잘못하면 책임지듯)을 져야 한다. 하지만 오픈 소스 진영과 소프트웨어 기업들은 필사적으로 소프트웨어를 '상품'의 범주, 그중에서도 '중고차'와 같은 범주로 밀어 넣었다.

서비스는 '과정'을 팔지만, 상품은 '결과물'을 판다. 'As Is'는 결과물에 대한 책임을 끊어내는 칼이다. 이 전략이 성공했기에 오늘날의 IT 산업이 있다. 만약 윈도우나 리눅스가 '서비스'로 분류되어 버그 하나마다 제조물 책임법의 적용을 받았다면, 윈도우 95는 출시되지 못했을 것이고 리눅스 커널은 1.0 버전에서 멈췄을 것이다.

당신이 오늘 마주한 그 'As Is'라는 두 단어는, 사실 "나는 당신을 돕고 싶지만, 당신 때문에 파산하고 싶지는 않다"는 개발자의 솔직한 고백이다. 그것은 무책임의 선언이 아니라, 자유(Free Software)를 지속 가능하게 만드는 유일한 타협점이다.

그러니 이제 라이선스 파일의 대문자 문단을 볼 때, 쫄지 말고 수정 금지라고 오해하지도 말라. 그저 고개를 끄덕이며 이렇게 생각하면 된다. "오케이, 이 코드는 방금 막 전장에서 돌아온 중고 탱크구나. 엔진이 터질 수도 있지만, 고쳐서 쓰면 내 것이 되는구나." 그 쿨한 합의가 바로 오픈 소스의 시작이다. 보증서를 잃는 대신 자유를 얻는다. 그 정도면 꽤 괜찮은 거래 아닌가?

3줄 요약

1. 'As Is'는 단순한 단어가 아니라 미국 상법(UCC)이 공인한, 모든 묵시적 보증을 단번에 날려버리는 법적 마법 주문이다.
2. 이 용어는 물건의 품질(Future)이 아닌 현재 상태(Present)만을 정의함으로써, 개발자가 거짓말쟁이로 몰릴 가능성을 원천 봉쇄한다.
3. 라이선스가 대문자로 쓰인 이유는 화가 나서가 아니라, 법적으로 '눈에 띄게(Conspicuous)' 작성해야만 면책 효력이 발생하기 때문이다.