엔지니어의 리더십: R&R을 명세(Spec)로 기술하라

작성자:

해외연구소장으로 있던 시절, 한 주재원이 본사에 보낼 불만 메일을 쓰고 있는 것을 본 적이 있습니다. 내용을 들여다보니 “본사 지원팀에서는 왜 이걸 이렇게 처리하느냐”는 이슈제기였습니다. 저는 상황을 정리해서 문제를 제기하는 것 자체는 좋지만, 그 전에 요청을 받는 쪽의 입장에서 한 번 더 생각해 보고 우리가 무엇을 원하는지를 명확하게 전달하는 게 먼저라고 일러 주었습니다.

회사나 큰 조직에서 누구나 각자의 자리에서 자기 일을 하고, 상대방이 우리 사정을 잘 알고 있을 거라고 기대하는 순간부터 이해관계의 불일치가 시작되기 때문입니다.

지나고 나서 보니, 그날의 장면은 소프트웨어 엔지니어에게 무척 익숙한 문제와 닮아 있습니다.

목 차

해외연구소에서 받았던 요청들

해외연구소는 그 특성상 본사의 여러 부서로부터 온갖 요청을 받습니다. 그중에는 우리 일과 전혀 무관한 것들도 적지 않았습니다. VIP 방문 의전을 맡아 달라거나, 사업부 협력사 관련 조사를 해 달라거나, 영업법인에 샘플을 전달해 달라거나, 외부 업체와의 협조를 주선해 달라는 식이었습니다. 해외연구소의 본래 역할은 본사의 요구사항을 받아 기술을 개발하는 것인데, 정작 들어오는 요청은 그 본업과 거리가 먼 경우가 적지 않았던 셈입니다.

흥미로운 것은, 이런 상황이 본사에서 근무할 때는 상대적으로 덜했다는 점입니다. 본사 부서 간에는 서로 가까이 있으면서 일상적으로 부대끼다 보니, 각자가 무엇을 하는 조직인지를 비교적 잘 이해하고 있습니다. 또 요청사항을 주고 받는 과정에서 보다 긴밀한 조율이 가능합니다. 그래서 무리한 요청이 오가는 일이 적습니다. 물론 아예 없다는 말은 아닙니다.

반면 본사와 해외 사이에는 물리적으로 거리가 있는 만큼 서로를 막연하게 확대해서 이해하기 쉽습니다. 해외 입장에서는 본사가 더 잘 지원해 주기를 바라고, 본사는 해외가 더 많은 역할을 해 주기를 기대합니다. 특히 대부분의 소통이 이메일이나 메신저로 이루어지다 보니, 속속들이 알기가 어렵습니다. 그렇게 양쪽의 기대가 각자의 방향으로 부풀어 오르면서 이해관계의 불일치가 생기는 것입니다.

결국 이것은 R&R, 즉 역할과 책임이 얼마나 명확하게 정의되어 있느냐, 그리고 그 정의가 서로에게 얼마나 정확히 이해되고 있느냐의 문제로 볼 수 있습니다.

조직을 모듈로, R&R을 인터페이스로

앞서, 누구나 각자의 자리에서 자기 일을 하는 것이라고 언급했습니다. 사실 이것은 소프트웨어의 모듈화(Modularization)에 해당하는 얘기입니다. 다시 말해, 큰 조직은 부서/업무/기능 단위로 모듈화되어 있습니다. 그렇다면, R&R은 그 모듈 사이를 잇는 인터페이스에 해당합니다. 그리고 소프트웨어를 설계해 본 사람이라면, 인터페이스 설계가 얼마나 중요한지 잘 알고 있습니다.

소프트웨어에서 모듈은 기본적으로 공개된 인터페이스를 통해서만 서로를 호출합니다. 그 안쪽의 내부 로직은 바깥에서 보이지 않도록 숨깁니다. 이것을 캡슐화(Encapsulation)라고 부릅니다. 호출하는 쪽은 무엇을 넣으면 무엇이 나오는지, 즉 인터페이스(Interface)만 알면 되고, 그 안에서 어떤 일이 벌어지는지는 신경 쓸 필요가 없습니다. 덕분에 호출하는 쪽은 복잡성에서 자유롭고, 만든 쪽은 인터페이스만 지키면 내부를 얼마든지 고칠 수 있습니다. 서로의 안쪽을 모른다는 것이, 잘 설계된 시스템에서는 약점이 아니라 강점인 셈입니다.

조직 내 부서 간에서도 이 원리는 똑같이 작동해야 합니다. 서로의 내부 사정을 시시콜콜 알지 못하더라도, 무엇을 주고받을지가 인터페이스로 분명하게 정의되어 있다면 협업은 매끄럽게 굴러갑니다.

인터페이스가 모호하면?

문제는 그 인터페이스가 불명확하거나 모호할 때 생깁니다. 무엇을 넘겨야 하는지, 결과가 어떤 형태로 언제 돌아오는지가 명확하지 않으면 양쪽의 기대가 어긋나고, 어긋난 기대는 오해를 낳고, 오해는 결국 이해관계의 불일치로 인한 충돌로 번집니다. 앞의 사례를 다시 보면, 본사와 해외연구소 사이에 오가던 무관한 요청들은 결국 두 조직 사이의 인터페이스가 명확하지 않았다는 것을 보여 줍니다.

직장 생활을 해 본 분들은 잘 아실 겁니다. 시스템이 제법 잘 갖춰진 대기업에서조차, 막상 들여다보면 담당자의 R&R과 업무 프로세스가 불명확한 경우가 의외로 많습니다. 조직도는 깔끔하게 그려져 있어도 “이 일은 어디까지가 누구의 역할인가”는 정작 합의되어 있지 않고, 그 빈틈, 소위 말하는 그레이 영역(Gray zone)에서 오해와 충돌이 반복됩니다. 맥킨지의 2023년 보고서 「조직의 현황」에서도 응답자의 40%가 불명확한 역할과 책임을 조직 비효율의 원인으로 지목했습니다.

그래서 효율적인 조직 구조를 만들기 위해 정말로 들여다봐야 할 곳은 사람이 아니라 조직과 조직 사이의 인터페이스입니다. 그것이 얼마나 명확하게 디자인되어 있는가가, 곧 그 조직의 생산성과 효율성을 가르는 척도가 됩니다.

인터페이스 설계 원칙과 팀API

소프트웨어를 설계할 때 우리는 명확한 인터페이스를 설계하기 위해 여러 원칙을 적용합니다. 그중 하나가 계약에 의한 설계(Design by Contract)입니다. 모듈 사이의 관계를 일종의 계약으로 보고, 호출하는 쪽은 약속된 입력을 지키고 제공하는 쪽은 약속된 결과를 보장하도록 하는 것입니다. 내부 구현은 숨겨도 좋지만 이 계약만큼은 분명해야 한다는 발상인데, 명세(Specification)란 결국 이 계약을 글로 적어 둔 것입니다.

이 외에도 각 모듈이 자기 관심사 하나에만 집중하게 하는 관심사의 분리(Separation of Concerns), 내부를 감추고 약속된 창구만 노출하는 정보 은닉(Information Hiding), 필요한 인터페이스에만 의존하게 하는 인터페이스 분리(Interface Segregation) 등 여러 원칙이 있습니다. 표현은 달라도 가리키는 곳은 하나입니다. 각자의 역할을 분명히 나누고, 내부보다 인터페이스를 먼저 명확하게 정의하라는 것입니다.

소프트웨어 쪽에서 이 원칙을 잘 보여주는 아마존의 사례가 있습니다. 2002년경, 제프 베이조스는 전 직원에게 한 통의 지시를 내린 것으로 알려져 있습니다. “베이조스 API 명령(Bezos API Mandate)”으로 불리게 된 이 사례는, 당시 아마존에서 일했던 엔지니어 스티브 예기가 2011년에 쓴 글을 통해 세상에 알려졌습니다. 내용은 단순합니다. 모든 팀은 자기 시스템의 데이터와 기능을 정해진 서비스 인터페이스를 통해서만 노출하고, 팀끼리는 오직 그 인터페이스로만 통신하라는 것이었습니다. 다른 팀의 데이터 저장소를 직접 들여다보거나 공유 메모리나 백도어(back door)로 주고받는 일은 허용되지 않았습니다.

e커머스를 확장하고, 아마존을 하나의 플랫폼으로 만들기 위한 목표로 진행된 일이지만, 그 부산물로 팀과 팀 사이의 경계가 뚜렷해졌습니다. 무엇을 요청하고 제공할 수 있는지 서로 잘 아는 팀들은 자료 요청을 위해 회의를 열 필요 없이 빠르게 움직일 수 있었고, 그렇게 아마존은 모든 것을 서비스 우선으로 사고하는 회사로 바뀌어 갔습니다.

최근에는 같은 발상을 조직 설계의 출발점으로 삼는 흐름도 생겼습니다. 매슈 스켈튼과 마누엘 파이스가 2019년에 정리한 팀 토폴로지(Team Topologies)가 대표적입니다. 이들은 각 팀이 자신의 “팀 API”를 한 장으로 적어 둘 것을 권합니다. 우리 팀이 어떤 서비스를 제공하는지, 무엇을 약속하는지(SLA), 관련 문서는 어디 있는지, 어떤 주기로 바뀌는지를 적은 가벼운 계약입니다. 소프트웨어 모듈의 API를 적듯, 팀의 R&R을 인터페이스로 적어 두는 것입니다.

그리고 이들이 좋은 인터페이스의 기준으로 삼는 것이 의미심장한데, 엔지니어링 배경이 없는 사람과 대화할 때에도 곧바로 이해될 수 있어야 한다는 것입니다. 명세가 뚜렷할수록 조직 경계를 넘는 정렬이 쉬워진다는, 이 글에서 제가 주장하는 이야기와 정확히 같은 결론입니다.

AX 시대, AI에게 모호함은 치명적이다

AX 시대 이야기를 하기 앞서, R&R에 대한 명세가 그렇게 중요하다면 왜 지금까지는 큰 문제 없이, 혹은 큰 문제가 드러나지 않고 운영되어 왔는지를 이해할 필요가 있습니다. 의외로 답은 단순합니다. 지금까지 조직 안의 인터페이싱은 결국 사람과 사람 사이의 일이었기 때문입니다.

앞서 본사 내부의 사례에서 언급했듯이 사람끼리는 인터페이스의 모호함이나 부족한 정보를 암묵지로 메웁니다. 눈치로 빈칸을 채우고, 맥락으로 상대의 의도를 짐작하고, 대화 몇 번으로 어긋난 기대를 조정합니다. “알아서 잘 해주겠지”가 통했던 것입니다. 명세가 다소 모호해도 사람의 경험과 직관이 그 여백을 가려 주었기에, R&R을 굳이 문서로 또박또박 적지 않아도 조직은 그럭저럭 돌아갈 수 있었습니다. 적어도 지금까지는 그랬습니다.

그런데 AX(AI Transformation) 시대로 들어서면 사정이 달라집니다. 사람들 사이에 AI가 플레이어로 합류하면서, 그동안 사람이 메워 주던 여백이 더 이상 저절로 채워지지 않기 때문입니다. 사람에게는 사소했던 모호함이 AI에게는 치명적입니다.

가령 새로 수집된 시장 결함을 자동으로 분류해 담당자에게 배정하는 AI가 있다고 해 봅시다. 만약 R&R이 어디에도 적혀 있지 않다면, 우리는 어떤 결함을 누구에게 보내야 하는지 모든 경우를 일일이 설명해 주어야 할 것입니다. 반대로 부서와 개인과 태스크별로 명세가 또렷이 정의되어 있다면, 그 배정의 정확도는 눈에 띄게 높아집니다.

회의록을 정리하고 액션 아이템을 뽑아 주는 AI도 마찬가지입니다. 참석자 각자가 무엇을 책임지는지 알고 있는 AI와 그렇지 못한 AI의 결과물은 품질에서 차이가 날 수밖에 없습니다. 사람이라면 회의 분위기와 경험을 바탕으로 미루어 짐작했을 부분을, AI는 짐작하지 않기 때문입니다.

그래서 이제는 사람과 사람 사이에서든 사람과 AI 사이에서든, 각자의 명세를 또렷이 적어 두는 일이 점점 더 중요해집니다.

명세로 모든 것을 정의할 수는 없다

다만, 소프트웨어 모듈과 달리, 조직과 조직 사이, 사람과 사람 사이의 일을 명세로 빠짐없이 정의하는 것은 불가능합니다. 아무리 촘촘하게 적어 두어도 명세에 없는 요구는 생기고, 미처 예상하지 못한 긴급한 요청이 끼어듭니다. 그래서 명세를 잘 적는 것만큼이나 중요한 것이, 명세에 기술하지 않은 일이 들어왔을 때 그것을 어떻게 다루느냐입니다. 여기에는 두 가지가 필요합니다.

첫 번째는 예외처리 프로세스입니다. 명세에 없는 요구가 들어왔을 때 그것을 흘려보내거나 만만한 누군가에게 떠넘기는 대신, 정해진 경로로 가져가 다룰 수 있어야 합니다. 어디로 가져가서 누가 판단하고, 기존 우선순위를 어떻게 조정해 받을지 말지를 정하는 절차가 있어야 한다는 뜻입니다. 소프트웨어로 치면, 인터페이스에 정의되지 않은 입력이 들어왔을 때 그냥 멈춰 버리는 것이 아니라 예외를 붙잡아 처리하는 핸들러를 두는 것과 같습니다. 이 경로가 있으면 긴급한 요청도 비공식 통로로 새거나 한 사람에게 쏠리지 않고, 조직 차원에서 받아들여진 뒤 필요하다면 명세에 새로 반영됩니다.

두 번째는 두터운 신뢰 문화입니다. 사실 예외처리 프로세스도 그 바탕에 신뢰가 깔려 있어야 제대로 작동합니다. 상대가 명세 밖의 요청을 보냈을 때 “또 떠넘기는구나” 하고 의심부터 들면 매번 마찰이 생기고, 그렇다고 무엇이든 다 받아 주면 명세가 금세 무너집니다. 신뢰가 두터운 조직에서는 “이번 건은 명세 밖이지만 저쪽에 그럴 만한 사정이 있을 테니 받자”와 “이건 우리 일이 아니니 정중히 돌려보내자”를 큰 감정 소모 없이 판단할 수 있습니다.

다만 이런 신뢰는 한순간에 생기지 않습니다. 평소에 주기적으로 소통하며 서로의 사정과 제약을 이해해 두는 일이 바탕이 되고, 이해가 엇갈려 한쪽이 일방적으로 부담을 지게 될 때는 리더들이 나서서 상호간에 만족할 수 있는 합의를 이끌어 주어야 합니다. 그리고 명세 밖의 일을 떠안아 준 기여가 당연한 것으로 묻히지 않도록, 그것을 제대로 평가하고 보상하는 장치도 필요합니다. 이런 것들이 쌓여야 신뢰는 비로소 예외를 빠르고 건강하게 처리하도록 돕는 윤활유가 됩니다.

이 둘은 함께 가야 합니다. 프로세스는 예외를 다룰 길을 깔고, 신뢰는 그 길 위에서 마찰 없이 움직이게 합니다. 잘 설계된 코드는 정의되지 않은 입력 앞에서도 멈추지 않듯이, 사람으로 이루어진 조직도 이 두 가지 장치를 잘 만들어 둔다면 부족한 명세의 빈자리를 유연하게 메워 나갈 수 있습니다.

맺음말

이렇게 보면, AX로의 전환에 앞서 정작 먼저 해야 할 일이 분명해집니다. 거창한 도구를 들이기 전에, 우리가 지금 하고 있는 일과 일하는 방식을 밖으로 드러내어 글로 기술하는 것, 그것을 팀과 조직과 개인의 스펙으로 적어 두는 일입니다. 이 작업이 선행될수록 AX 전환이 성공할 확률도 그만큼 높아집니다.

좋은 스펙의 기준은 의외로 분명합니다. 그 업무의 배경을 전혀 모르는 사람이 읽어도 바로 이해할 수 있어야 한다는 것입니다. 물론 스펙을 어떻게 하면 잘 만들 수 있을지는 각 조직의 특성에 맞게 따로 고민해 봐야 할 문제이고, 이를테면 LLM이 함께 읽고 쓰는 LLM wiki 같은 형태가 하나의 방법이 될 수도 있을 것입니다.

다시 서두에 언급한 그 주재원에게 돌아갑니다. 그날의 불만은 누가 나빠서 생긴 것이 아니었습니다. 본사와 해외연구소 사이의 R&R이 모호했고, 그래서 양쪽의 기대가 제멋대로 부풀어 어긋났던 것뿐입니다. 받는 쪽의 입장에서 다시 생각해 보라던 조언도, 따지고 보면 상대의 명세를 확인해 보라는 말이었습니다.

좋은 조직은 서로의 안쪽을 속속들이 들여다보는 조직이 아니라, 또렷한 명세 위에서 서로를 신뢰하는 조직입니다. 그리고 AI가 동료가 되는 시대에, 이 명세를 적는 일은 더 이상 미룰 수 없는 숙제가 되었습니다.

변화의 시작은 거창하지 않습니다. 지금 내가 하고 있는 일의 명세부터 한 장 적어 보는 것, 무엇을 받아 무엇을 내놓고 있는지를 적어 보는 것, 거기서부터 시작하면 됩니다.

명세를 적는 일은, AI 시대의 가장 빠른 준비입니다.

ChulJoo Kim (김철주)

※ 참고문헌

ckarch.kr © 2026 is licensed under CC BY-NC-SA 4.0 CC BY NC SA

댓글 남기기