로펌이 벤더의 제품을 고르는 대신, 자기 소송 노하우를 벤더와 함께 제품으로 만드는 사례가 늘고 있습니다. 이 역할 이동이 무엇을 얻고 무엇을 내주는 거래인지 분석합니다.
초록 법률 기술 시장에서 로펌의 자리는 오랫동안 구매자였습니다. 벤더가 만들고 로펌이 고르는 구조였고, 경쟁은 벤더 사이에서 벌어졌습니다. 그런데 최근 대형 로펌이 특정 벤더와 손잡고 자기 업무 방식을 제품에 직접 새겨 넣는 사례가 눈에 띕니다. 동시에 거대 기술 기업의 진입 소식과 기술 주권을 되찾자는 목소리도 함께 커지고 있습니다. 세 흐름은 분리된 것처럼 보이지만 하나의 질문을 공유합니다. 법률 조직이 자기 지식에 대한 통제권을 어디까지 유지할 것인가입니다. 이 칼럼은 공동개발이라는 선택이 그 질문에 어떤 답을 주는지, 그리고 그 답이 요구하는 대가가 무엇인지를 따집니다.
법률 기술을 둘러싼 논의는 대체로 무엇을 살 것인가의 문제로 다뤄져 왔습니다. 어느 제품이 더 정확한지, 어느 계약 조건이 유리한지를 비교하는 일이었고, 그 구도에서 로펌은 선택하는 쪽이었습니다. 그런데 최근 시장에서 나오는 소식들은 이 구도에 균열을 냅니다. 한쪽에서는 대형 로펌이 특정 벤더와 파트너십을 맺고 자기 소송 방식 자체를 제품에 반영하는 작업에 들어갔고, 다른 쪽에서는 거대 기술 기업의 본격 진입이 기존 법률 기술 사업자의 존립을 흔들 것이라는 전망이 나옵니다. 그리고 그 사이에서 기술 주권, 곧 자기 기술 미래에 대한 통제권을 되찾아야 한다는 주장이 힘을 얻고 있습니다. 이 세 가지는 각각 다른 뉴스로 보이지만, 겹쳐 놓으면 같은 압력에 대한 서로 다른 반응입니다. 오늘은 그중 공동개발이라는 선택지를 자세히 들여다보겠습니다.
로펌이 완성된 제품을 구매하는 대신, 자기 업무 방식과 축적된 판단 기준을 벤더에게 제공해 제품 설계에 반영시키는 협업 형태입니다. 로펌은 자기에게 맞는 도구를 얻고, 벤더는 현장에서 검증된 설계 지식을 얻습니다.
조직이 오랜 시간에 걸쳐 만든 판단 순서와 검토 기준을 소프트웨어의 구조로 옮기는 일입니다. 문서로 적힌 매뉴얼과 달리 실행되는 형태가 되므로 조직 밖으로 이전될 위험도 함께 커집니다.
자기 조직의 데이터와 업무 지식이 어디에 저장되고 누구에 의해 처리되는지를 스스로 결정할 수 있는 상태를 말합니다. 특정 공급자에 대한 종속을 줄이는 문제이자, 그 지식이 경쟁자에게 흘러가지 않도록 통제하는 문제이기도 합니다.
범용 모델의 성능이 평준화될수록 제품 사이의 차이는 모델이 아니라 그 모델을 무엇으로 감싸는지에서 나옵니다. 그런데 그 감싸는 지식, 곧 어떤 순서로 검토하고 무엇을 먼저 의심하며 어느 지점에서 멈추는지에 대한 판단은 벤더가 아니라 로펌 안에 있습니다. 벤더는 그것을 밖에서 추론할 수 있을 뿐이고, 추론된 워크플로는 어느 조직에도 딱 맞지 않는 평균값이 됩니다. 대형 로펌이 벤더와 손잡고 자기 소송 방식을 제품에 직접 반영하려는 움직임은 이 간극에서 나옵니다. 구매만으로는 평균값을 얻고, 공동개발을 하면 자기 값을 얻습니다. 이 차이는 도구의 편의 문제가 아니라 경쟁 우위의 문제로 인식되기 시작했습니다. 남들과 같은 도구를 남들보다 잘 쓰는 것과, 자기에게만 맞는 도구를 갖는 것은 다른 이야기이기 때문입니다.
공동개발은 대가 없는 선택이 아닙니다. 자기 업무 방식을 제품에 새겨 넣는다는 것은 그 방식이 조직 밖의 코드베이스에 존재하게 된다는 뜻입니다. 계약으로 배타성을 확보한다 해도 기간이 있고, 그 기간이 끝난 뒤 같은 구조가 다른 고객에게 제공되지 않으리라는 보장은 계약 문언의 정교함에 달려 있습니다. 더 미묘한 것은 학습의 문제입니다. 명시적으로 데이터를 넘기지 않아도, 함께 설계하는 과정에서 벤더는 그 영역의 문제를 어떻게 풀어야 하는지를 배웁니다. 이 학습은 계약으로 회수할 수 없습니다. 따라서 공동개발을 검토하는 조직은 두 가지를 구분해야 합니다. 내주어도 되는 일반적 업무 순서와, 내주면 안 되는 판단의 핵심입니다. 이 구분 없이 시작하면 협업의 범위가 자연스럽게 넓어지며 통제권이 조용히 이동합니다.
기존 법률 기술 사업자들이 대형 기술 기업의 진입 앞에서 살아남을 수 있느냐는 물음이 시장에서 제기되고 있습니다. 이 물음은 로펌의 공동개발 판단에도 직접 영향을 줍니다. 함께 제품을 만들기로 한 상대가 몇 해 뒤에도 독립적으로 존재할 것인지, 인수되어 다른 회사의 일부가 될 것인지에 따라 계약의 의미가 달라지기 때문입니다. 인수는 계약을 승계하지만 방향과 우선순위는 승계하지 않습니다. 함께 만든 기능이 새 소유자의 로드맵에서 후순위로 밀리거나, 반대로 더 넓은 고객층에 일반화되는 상황이 모두 가능합니다. 그래서 이 시장에서 공동개발 계약은 기능 명세보다 이전과 종료의 조건을 더 정교하게 다뤄야 합니다. 무엇을 함께 만들 것인가보다, 관계가 끝날 때 각자 무엇을 가지고 나가는가가 오래 남는 조항입니다.
기술 주권에 대한 요구는 종종 자체 구축이라는 결론으로 이어집니다. 그러나 모든 계층을 직접 만드는 선택은 대부분의 조직에게 비현실적이고, 그 결과 주권 담론은 구호로 끝나기 쉽습니다. 실무로 번역하려면 층위를 나누어야 합니다. 모델 계층은 사실상 외부에 의존할 수밖에 없고, 응용 계층은 벤더와 함께 만들 수 있으며, 지식 계층 곧 무엇이 검증된 근거인지에 대한 판단은 조직이 직접 통제할 수 있습니다. 통제권을 되찾자는 주장은 모든 층을 소유하자는 뜻이 아니라, 어느 층을 절대 내주지 않을지를 정하자는 뜻으로 읽어야 합니다. 저희가 검증 자산을 자체적으로 축적하고 그 판정 논리를 외부 서비스에 위임하지 않는 것도 이 층위 구분에 따른 선택입니다.
공동개발은 협상력이 있는 대형 조직의 선택지입니다. 벤더가 시간을 들여 함께 만들 이유가 있으려면 그만한 규모나 상징성이 필요하기 때문입니다. 그렇다면 그렇지 않은 조직은 평균값 제품을 쓰는 수밖에 없는가 하면, 반드시 그렇지는 않습니다. 자기 업무 방식을 제품 코드에 새기는 대신, 검증된 근거의 집합과 판단 기준을 자기 쪽에 두고 도구를 바꿔 끼우는 구조가 가능하기 때문입니다. 이 경우 우위는 도구의 독점이 아니라 축적된 자산의 품질에서 나오고, 도구는 언제든 교체 가능한 부품으로 남습니다. 규모가 작을수록 이 구조가 유리합니다. 협상력이 없는 조직이 특정 벤더에 깊이 결합하면 종속의 비용만 지불하고 배타성의 이익은 얻지 못하기 때문입니다.
예상 반론 공동개발은 결국 마케팅 수사에 가깝고, 실제로는 대형 로펌이 벤더에게 요구사항을 더 강하게 전달하는 것 이상은 아니라는 반론이 가능합니다. 어느 조직이든 자기 방식을 반영해 달라고 요구해 왔으며, 파트너십이라는 이름이 붙었다고 관계의 본질이 달라지지는 않는다는 시각입니다.
재반박 그러나 요구사항 전달과 설계 참여는 남는 것이 다릅니다. 요구사항은 기능 목록으로 소비되고 사라지지만, 설계에 관여한 판단 구조는 제품의 뼈대에 남아 다음 버전으로 이어집니다. 더 중요한 차이는 위험의 방향입니다. 요구사항을 전달하는 관계에서는 제품이 마음에 들지 않으면 떠나면 되지만, 자기 업무 구조가 반영된 제품을 떠나는 일은 그 구조를 두고 나오는 일이 됩니다. 이름이 바뀐 것이 아니라 이탈 비용이 바뀐 것이고, 그것은 관계의 본질에 속합니다.
앞으로 법률 조직과 기술 공급자의 관계는 단순한 구매·판매에서 몇 갈래로 분화할 것으로 봅니다. 규모와 협상력을 갖춘 조직 일부는 공동개발로 자기 방식을 새긴 도구를 갖게 되고, 다수의 조직은 표준 제품을 쓰되 그 위에 자기 자산을 얹는 구조를 택할 것입니다. 어느 쪽을 택하든 결정적인 질문은 같습니다. 관계가 끝날 때 무엇이 남는가입니다. 도구만 남고 지식이 상대편에 남는 구조라면 그 협업은 장기적으로 조직을 약하게 만듭니다. 반대로 도구는 바뀌어도 검증된 근거와 판단 기준이 조직 안에 남는다면, 공급자 지형이 어떻게 재편되든 조직은 그 변화를 견딜 수 있습니다. 법마디가 검증 자산을 스스로 축적하고 모델을 교체 가능한 부품으로 두는 이유도 여기에 있습니다. 저희가 만들고 싶은 것은 특정 모델 위에서만 작동하는 제품이 아니라, 어떤 도구를 쓰든 근거의 진위를 판정해 주는 층입니다.
"만드는 쪽으로 옮겨 간다는 것은 더 많은 통제권을 갖는다는 뜻이기도 하고, 더 깊이 묶인다는 뜻이기도 합니다. 두 해석 모두 맞습니다. 중요한 것은 어느 쪽인지를 계약과 구조로 미리 정해 두는 일입니다."