Ch25 협상과 리더십 스킬

한 줄 정의

협상과 리더십 스킬은 아키텍트가 이해관계자·다른 아키텍트·개발자 사이에서 의견 충돌을 풀어내고 팀을 이끌기 위해 갖춰야 하는 하드 스킬(hard skill)입니다.

쉽게 말하면

아키텍트가 내리는 거의 모든 결정은 누군가의 반대에 부딪힙니다. 비용이 너무 많이 든다는 부사장, 일정이 너무 길다는 PM, 자기가 더 잘 안다고 생각하는 개발자가 항상 등장합니다.

이 충돌을 정면으로 받아치면 관계가 망가지고, 그렇다고 그냥 넘기면 아키텍처가 무너집니다. 협상(negotiation) 과 촉진(facilitation) 은 양쪽 다 피하면서 모두가 동의할 수 있는 해답으로 사람들을 데려가는 기술입니다.

리더십도 같은 결입니다. 직책으로 사람을 움직이는 게 아니라 솔선수범으로 신뢰를 얻는 일이 핵심입니다.

왜 중요한가?

해결하는 문제: 아키텍처 결정에는 항상 반대자가 따라붙습니다. 기술적으로 옳다고 강요해도 사람이 움직이지 않으면 아키텍처는 종이로만 남습니다.
이게 없다면: 아키텍트는 상아탑(Ivory Tower)에 갇혀 결정만 던지는 사람이 되고, 개발 팀은 존경심을 잃고, 시스템은 모두가 이의를 제기하지 못한 채 우발적 복잡성으로 무너집니다.

핵심 내용

비즈니스 이해관계자와의 협상

수석 아키텍트가 부사장 같은 비즈니스 이해관계자와 협상해야 하는 상황은 흔합니다. 책임자는 자기주장이 강하고 지적당하는 것을 극도로 싫어하기 때문에, 정면으로 반박하면 관계만 망가집니다.

시나리오 1 — '파이브 나인'을 요구하는 부사장

제품 스폰서 파커(Parker) 부사장은 신규 글로벌 트레이딩 시스템이 99.999%(파이브 나인) 가용성을 반드시 만족해야 한다고 주장합니다. 아키텍트는 글로벌 마켓 간 트레이딩이 이루어지지 않는 시간이 두 시간씩 존재하므로 99.9%(스리 나인)만 되어도 충분하다는 사실을 알고 있습니다. 문제는 파커가 자신을 무시하거나 깔본다고 느끼면 더 심하게 반응한다는 점입니다.

1단계: 유행어와 단서 듣기

협상에 들어가기 전에 상대가 쓰는 유행어, 전문 용어, 심지어 의미 없어 보이는 말까지 유심히 들어야 합니다. 그 안에 협상의 실마리가 담겨 있을 때가 많습니다.

가령 “말씀하신 기능이 언제 필요한지요?”라고 물었을 때 “어제 필요했다”라고 답했다면, 어제로 돌아갈 수는 없지만 그 이해관계자가 출시 시점을 얼마나 중시하는지 파악할 수 있습니다.

같은 방식으로 “이 시스템은 번개처럼 빨라야(lightning fast) 한다”는 표현은 성능 요구가 매우 중요하다는 뜻이고, “제로 다운타임(zero downtime)” 역시 정말 0이어야 한다는 뜻이 아니라 가용성이 매우 중요함을 강조하는 표현입니다.

Tip

협상에 들어가기 전에 가능한 한 많은 정보를 미리 확보하자.

2단계: ‘9의 개수’ 대신 구체적 시간 단위로 유도

파커가 ‘파이브 나인’을 언급했다는 것은 가용성을 매우 높게 유지하고 싶다는 뜻입니다. 파이브 나인이 99.999%라는 점은 알겠지만, 그게 연간 가동 중지 시간으로 얼마인지는 잘 모를 가능성이 큽니다.

가용성 수준별 연간 가동 중지 시간

가용성(%)	연간 가동 중지 시간(괄호 안은 일일 환산)
90.0% (원 나인)	36일 12시간 (일 2.4시간)
99.0% (투 나인)	87시간 46분 (일 14분)
99.9% (스리 나인)	8시간 46분 (일 86초)
99.99% (포 나인)	52분 33초 (일 7초)
99.999% (파이브 나인)	5분 35초 (일 1초)
99.9999% (식스 나인)	31.5초 (일 86ms)

핵심은 협상의 논점을 ‘~나인’이라는 추상적 용어에서 현실적인 시간 단위 로 끌어내리는 것입니다. 파이브 나인이라고 하면 “당연히 그 정도는 필요하지”가 되지만, “하루 평균 1초의 다운타임만 허용된다”라고 하면 그 비용이 얼마나 비현실적인지 즉시 와닿습니다.

아키텍트가 적절하다고 판단한 스리 나인(99.9%)은 하루 평균 86초의 다운타임에 해당합니다. 글로벌 트레이딩에서 트레이딩이 일어나지 않는 시간이 두 시간씩 있다는 사실을 함께 제시하면, 파커도 86초가 충분하다고 인정할 가능성이 높아집니다.

3단계: 비용과 시간은 마지막 카드

Tip

다른 모든 방법이 실패했다면, 구체적인 비용과 시간 을 제시하자.

협상 시작부터 “그건 돈이 너무 많이 든다”거나 “우리에게 그럴 시간이 없다”고 말하면 대개 상황이 꼬입니다. 비용·시간을 먼저 꺼내면 상대는 “결국 돈 얘기냐”로 받아들이기 쉽습니다.

협상 초반에는 더 근본적이고 상대방에게 의미 있는 명분과 근거를 먼저 제시하는 것이 좋습니다. 1단계의 유행어 분석, 2단계의 구체적 시간 환산이 이에 해당합니다. 비용과 시간은 의견 일치에 도달하지 못했을 때의 마지막 수단으로 미뤄 둡니다.

4단계: 분할 정복 (divide-and-conquer)

Tip

요구사항을 분류하거나 범위를 좁힐 필요가 있을 때는 ‘분할 정복’ 전략을 사용하자.

손자병법의 “적의 군세가 하나로 뭉쳐 있으면 분산시키라”는 조언은 협상에도 적용됩니다.

파커는 새 트레이딩 시스템 전체 에 99.999% 가용성을 요구합니다. 하지만 정말 시스템 전체가 파이브 나인이어야 할까요? 시스템에서 파이브 나인이 꼭 필요한 특정 영역들로 요구를 한정하면 어떻게 될까요? 그렇게 하면 과도하거나 비싼 요구사항의 범위를 줄일 수 있을 뿐 아니라 협상의 논점도 좁힐 수 있습니다.

다른 아키텍트와의 협상

시나리오 2 — REST vs 비동기 메시징

시니어 아키텍트 로건(Logan)은 여러 서비스 사이의 통신에 비동기 메시징을 쓰는 것이 성능과 확장성을 모두 높일 수 있는 올바른 접근법이라고 믿습니다. 다른 아키텍트 애디슨(Addison)은 강력하게 반대하며, REST가 메시징보다 항상 더 빠르고 확장성도 뛰어나다고 주장합니다. 애디슨은 구글 검색 결과와 유명 생성형 AI 도구의 응답을 자기 근거로 제시합니다.

시니어인 로건이 직책을 내세워 무시할 수도 있지만, 그러면 감정만 격해지고 두 아키텍트가 협업하지 않는 분위기가 개발 팀 전체에 부정적 영향을 미칩니다.

Tip

논쟁하는 것보다 보여주는 것이 낫다는 점을 항상 기억하자. 백문이 불여일견(demonstration defeats discussion) 이다.

REST와 메시징 중 어느 것을 선택할지 논쟁하는 대신 왜 메시징이 이 환경에서 더 나은 선택인지를 직접 보여주는 것이 효과적입니다. 환경마다 조건이 다르므로 인터넷 검색만으로는 답이 나오지 않습니다. 실제 프로덕션과 유사한 상황에서 두 방식을 비교하고 그 결과를 보여주면 불필요한 논쟁 없이 결론에 도달합니다.

백엔드 관점

이 패턴은 그대로 PoC와 벤치마크 문화로 이어집니다. “GPT가 그렇게 답했다”는 근거에 다른 근거로 맞서는 것은 시간 낭비입니다. 동일 부하·동일 메시지 크기·동일 인프라에서 JMeter / k6 / Gatling 결과 를 들이미는 편이 빠릅니다. 지나치게 논쟁적이거나 감정적으로 흐르는 말투를 차분히 거두고, 명확하고 간결한 논거로 대체하는 것이 핵심입니다.

대화가 너무 개인적이거나 감정적이 되면 협상을 잠시 중단하고 양쪽이 진정된 후 다시 임해야 합니다. 침착함과 리더십을 보여주면 상대방이 한발 물러서는 일이 많습니다.

개발자와의 협상

유능한 아키텍트는 개발 팀의 존중을 얻습니다. 그래야 어떤 요청을 해도 불만이 쌓이지 않습니다. 거리감을 느끼는 팀은 자신들이 의사결정에서 배제된다고 생각하기 쉬우며, 이것이 상아탑 안티패턴의 대표적인 모습입니다.

명령조 대신 명분을 먼저

Tip

아키텍처 결정이나 특정 작업을 개발자에게 요청할 때는 그냥 “윗사람 말이니까 따르세요”라고 하지 말고 반드시 명분을 제시해야 합니다.

❌ 아키텍트: "그 호출은 반드시 비즈니스 계층을 거쳐야 해요."
   개발자:   "동의하지 않습니다. 그냥 데이터베이스에 직접 접근하는 게 훨씬 빠르죠."

이 대화의 문제는 두 가지입니다. 첫째, “반드시 ~해야 한다”라는 명령조가 개발자를 얕보는 표현입니다. 둘째, 명분 없이 결과만 던졌습니다.

✅ 아키텍트: "닫힌 계층 아키텍처를 만든 것은 변경 관리(change control)가 제일 중요하기
   때문입니다. 그러려면 데이터베이스 접근을 비즈니스 계층에서만 요청해야 해요."
   개발자:   "알겠습니다. 그런데 단순 쿼리 성능 문제는 어떻게 대응하죠?"

명분을 먼저 제시하니 개발자는 더 이상 닫힌 계층 자체에 반대하지 않고, 같은 제약 안에서 성능 개선 방법을 함께 찾자는 협력적 대화로 바뀌었습니다. 또한 “반드시 ~해야 한다” 대신 “이는 ~라는 의미다”라고 사실의 진술처럼 전달한 점도 중요합니다.

개발자가 스스로 답을 찾게 하기

아키텍트가 프레임워크 X와 Y 중 하나를 선택해야 한다고 합시다. 검토 결과 프레임워크 Y는 시스템 보안 기준을 충족하지 못해 X를 선택했습니다. 그런데 한 개발자가 Y가 더 낫다고 강하게 주장합니다.

직접 반박하는 대신 이렇게 제안합니다.

“만일 프레임워크 Y의 보안 우려를 해소할 수 있다면 Y를 선택하겠습니다.”

가능한 결과는 두 가지입니다.

결과	진행	효과
Y의 보안을 입증하지 못함	개발자가 스스로 Y를 못 쓰는 이유를 깨달음	X 선택에 자동으로 동의
Y의 보안을 해결할 방법을 발견	아키텍트가 놓친 항목을 찾음	더 나은 해법 + 개발자 효능감

백엔드 관점

코드 리뷰에서도 같은 패턴이 통합니다. “이 쿼리는 N+1이라 안 됩니다”라고 닫지 말고 “지금 구조에서 N+1을 방지하면서 의도를 유지할 수 있는지 한 번 검토해볼래요?”라고 던지면, 개발자가 직접 fetch join이나 batch size 옵션에 도달하면서 학습이 일어납니다. 결정 권한을 놓지 않으면서 학습 기회를 주는 셈입니다.

아키텍처의 4C — 우발적 복잡성과 싸우기

변화는 단순해지는 방향이 아니라 복잡해지는 방향일 때가 많습니다. 복잡성은 두 종류로 나뉩니다.

종류	정의	예시
본질적 복잡성 (essential)	문제 자체가 본질적으로 어려운 경우	99.9999% 가용성 보장 (연간 31.5초 다운타임)
우발적 복잡성 (accidental)	아키텍트가 스스로 문제를 어렵게 만든 경우	자기 존재감 과시·일자리 보전을 위해 도입한 쓸데없는 구조

개발자는 마치 나방이 불빛에 끌리듯 복잡성에 끌린다. 그리고 그 결과 역시 나방의 운명과 비슷할 때가 많다.

본질적이지 않고 필연적이지도 않은 복잡성을 굳이 도입하는 것은 아키텍트가 리더십과 신뢰를 잃는 가장 빠른 길입니다. 우발적 복잡성을 피하려면 아키텍처의 4C 를 활용해야 합니다.

flowchart TB
    Comm[의사소통<br/>Communication] <--> Coll[협업<br/>Collaboration]
    Clear[명확함<br/>Clear] <--> Conc[간결함<br/>Concise]
    Comm <--> Clear
    Comm <--> Conc
    Coll <--> Clear
    Coll <--> Conc

4C	의미
Communication	명확하고 간결하게 의사소통하는 능력
Collaboration	개발자·이해관계자·다른 아키텍트와 협업하는 능력
Clear	명확함 — 모호함 없이 의도를 전달
Concise	간결함 — 군더더기 없는 표현

C4 다이어그램 모델의 4C와 혼동하면 안 됩니다. 이 4C는 사람을 움직이는 4C입니다.

현실적이면서도 비전을 가져라

flowchart LR
    실용성[실용성] <--> 비전[비전]

비전가(visionary) 는 상상력과 지혜로 미래를 내다보고 계획합니다. 비전을 가진다는 것은 문제에 전략적으로 접근한다는 뜻이며, 아키텍트가 해야 할 일이기도 합니다. 다만 너무 이론적으로 흐르면 실현하기 어렵고 이해하기도 어려운 복잡한 해법이 나옵니다.

현실적 이라는 것은 이론보다 실용에 근거해 합리적이면서 실질적으로 해결책을 찾는 태도입니다. 다음 항목들이 현실성을 담보합니다.

예산 제약과 비용 관련 요인
일정 제약과 시간 관련 요인
개발 팀의 역량과 숙련도
각 아키텍처 결정의 트레이드오프와 영향
제안하는 설계나 해법의 기술적 한계

동시 접속자 급증 시나리오

원인을 알 수 없는 상황에서 두 유형의 아키텍트는 다음과 같이 행동합니다.

유형	첫 행동
비전 편향	데이터베이스를 분리하고 복잡한 데이터 메시(data mesh) 를 구축해 탄력성 확보
현실 편향	시스템 탄력성을 제한하는 요인이 무엇인지부터 파악. 데이터베이스가 병목이라면 일부 데이터를 캐싱해 DB 요청 감소

데이터 메시는 분석용 데이터를 트랜잭션 데이터에서 분리하기 위한 도메인별 분산 데이터베이스 집합입니다. 이론상 가능하더라도 회사가 이전에 도입한 적이 있는지, 트레이드오프가 무엇인지, 정말로 이 문제를 해결하는지부터 따져야 합니다.

비즈니스 이해관계자는 미래지향적 해법을 높이 평가하지만 개발자는 실제 구현 가능한 현실적 해법을 선호합니다. 양쪽의 신뢰를 모두 얻으려면 균형이 필수입니다.

솔선수범으로 팀 이끌기

나쁜 아키텍트는 직책으로 사람을 움직이려 하고, 유능한 아키텍트는 솔선수범으로 움직입니다. 제럴드 와인버그(Gerald Weinberg)가 남긴 말이 핵심을 잘 담고 있습니다.

문제가 무엇이든, 그것은 사람의 문제이다.

기술적 지식은 문제 해법의 한 부분일 뿐, 대부분은 대인 관계 스킬에서 결판이 납니다.

협업 없는 의사소통은 문을 닫는다

❌ 개발자:   "이 성능 문제를 어떻게 해결해야 할까요?"
   아키텍트: "반드시 캐시를 사용해야 해요. 그러면 문제가 해결될 겁니다."
   개발자:   "나한테 이래라저래라 하지 마세요."

“반드시 ~해야 해요”라는 표현이 협업의 문을 닫아버립니다.

✅ 개발자:   "이 성능 문제를 어떻게 해결해야 할까요?"
   아키텍트: "캐시 사용을 고려해 봤나요? 그러면 문제가 해결될 것 같습니다."
   개발자:   "흠, 아니, 그건 생각하지 않았는데요. 아키텍트님 생각은 어떤가요?"

명령을 의견 요청으로 바꾸자 대화의 통제권이 개발자에게 넘어가면서 협력적 대화가 가능해집니다.

요청(request)을 부탁(favor)으로

사람들은 지시받는 것을 싫어하지만, 다른 사람을 돕는 것은 좋아합니다. 바쁜 반복(iteration) 중에 리팩터링을 부탁하는 두 시나리오를 비교해 봅시다.

❌ 아키텍트: "결제 서비스를 5개의 다른 서비스로 분리해야 하는데요. 각 서비스는…"
   개발자:   "미안하지만 이번 반복에서는 너무 바빠서 못 합니다."

이 대화에서 아키텍트는 개발자의 이름을 부르지도 않았고 자기 요구만 던졌습니다.

✅ 아키텍트: "스라다르 님 안녕하세요. 제가 지금 상황이 아주 곤란한데요. 내결함성과
   확장성을 높이려면 결제 서비스를 결제 유형별로 분리해야 하는데 너무 늦은 거 아닌가
   싶네요. 어떻게 이번 이터레이션에서 이 일 좀 처리해 줄 수 있을까요? 그러면 제게 정말
   큰 도움이 될 겁니다."
   개발자(잠시 멈추며): "이번 이터레이션에 정말 바쁘긴 한데요. 한 번 살펴볼게요."
   아키텍트: "고마워요 스라다르 님. 정말 도움이 됩니다. 신세 졌네요."

차이는 세 가지입니다.

이름을 부른다. 비인격적 업무 요구가 개인적이고 친숙한 대화로 바뀝니다.
자신의 곤란함을 인정한다. “아주 곤란한 상황”임을 드러내며 도움을 요청합니다.
요청을 부탁으로 바꾼다. “분리해야 한다”가 아니라 “처리해 줄 수 있을까요”입니다.

악수와 시선

처음 만나는 사람이나 가끔 만나는 사람을 맞을 때 악수와 눈맞춤은 효과적인 리더십 기법입니다. 악수가 통용되는 문화권에서 시선을 피하는 것은 무례함의 표시일 가능성이 큽니다.

악수의 원칙은 단순합니다.

손에 적당히 힘을 주되, 상대를 제압할 정도는 아닐 것
상대의 눈을 볼 것
2~3초면 충분, 너무 오래 하지 말 것
매일 아침 모두와 악수하는 식으로 남발하지 말 것
문화권에 따라 다르게 인사할 것 (예: 일본에서는 허리 숙여 절)

리더는 모든 직급의 사람들 사이에 존재하는 개인 경계선(personal boundary) 을 존중해야 합니다. 악수가 좋다면 포옹은 더 좋지 않을까 생각하는 사람이 있지만, 전문적 업무 관계에서 포옹은 사람을 불편하게 할 수 있고 직장 내 괴롭힘의 한 형태가 될 수도 있습니다. 포옹은 생략하고 악수만 합니다.

의지가 되는 사람(go-to person)

좋은 리더는 개발자가 질문이나 문제가 생겼을 때 가장 먼저 떠올리고 찾아가는 사람입니다. 직책이나 역할에 상관없이 기회를 포착하고 주도적으로 팀을 이끕니다. 비기술적 상황에서도 마찬가지로, 팀원이 우울해 보이면 “이봐, 안토니오, 나 커피 마시러 가는데. 같이 가지 않겠나?”처럼 대화를 유도하는 작은 행동이 멘토링과 코칭의 기회를 엽니다.

다만 대화를 강제해서는 안 됩니다. 상대의 언어적·비언어적 신호를 살펴 물러날 때를 알아채야 합니다.

또 다른 자리매김 방법은 디자인 패턴이나 최신 프로그래밍 언어 릴리스의 새로운 기능 같은 특정 기법에 대해 주기적으로 ‘점심시간 스터디’ 세션을 주최하는 것입니다. 멘토링과 대중 의사소통 기술을 연습할 기회이자, 자신을 리더와 멘토로 각인시키는 계기가 됩니다.

개발 팀에 녹아들기 — 회의 통제

아키텍트의 일정은 회의가 꼬리를 물기 마련입니다. 팀에 녹아들고 멘토링하며 질문에 응답할 시간을 확보하려면 회의를 잘 통제해야 합니다.

flowchart LR
    Others[다른 사람들] -->|초대된 회의| Architect1[아키텍트]
    Architect2[아키텍트] -->|소집한 회의| Team[다른 사람들]

회의 유형	정의	통제 가능성
초대된 회의	누군가가 불러서 참석하는 회의	통제 어려움
소집한 회의	내가 다른 사람을 불러 진행하는 회의	통제 가능

초대된 회의 줄이기

초대받으면 주최자에게 왜 자신이 필요한지 물어봅니다.

단순 정보 공유가 목적이면 회의록 같은 문서로 대체 가능
회의 안건을 살펴보고 일부만 관련 있다면 그 부분에만 참여
자신과 기술 리더가 모두 초대받았다면 한쪽만 참여하고 결과를 공유

Tip

사전에 회의 안건을 요청하자. 그러면 회의에 정말 참석해야 하는지 판단하는 데 도움이 된다.

소집한 회의는 최소화

내가 소집한 회의는 통제 가능하므로 최소한으로 유지합니다.

안건을 정하고 그대로 따른다
정보 전달만 목적이면 이메일로 대체
개발자의 핵심 업무 시간을 피해 아침 일찍·점심 직후·일과 종료 무렵에 잡는다

같은 사무실에서 옆에 앉기

팀과 떨어진 칸막이 안에 앉으면 “나는 특별하니 방해하지 마시오”라는 메시지를 보냅니다. 반대로 팀과 나란히 앉으면 “나는 팀의 일원이며 언제든 응할 준비가 되어 있다”는 메시지가 됩니다. 다른 층에 있거나 자기 사무실에 틀어박혀 있는 아키텍트는 팀을 이끌 수 없습니다.

원격 근무 환경이라면 협업이 더 어려워집니다. 이 경우 재퀴 리드(Jacqui Read)의 『Communication Patterns』(O’Reilly, 2023)의 원격 팀 운영 패턴을 참고할 수 있습니다.

개발자의 몰입 상태 (flow)

몰입은 개발자가 어떤 문제에 뇌를 100% 집중해서 창의력을 최대로 발휘하는 정신 상태입니다. 개발자들은 어려운 알고리즘 작업을 몇 시간씩 했음에도 몇 분처럼 느끼곤 합니다.

아키텍트는 팀의 생산성 몰입(productivity flow) 에 세심한 주의를 기울이고 그것을 방해하지 말아야 합니다. 회의 시간 선택, 옆에 앉는 위치, 말 거는 타이밍 모두 이 몰입을 깨지 않는 방향으로 정렬되어야 합니다.

비교 / 트레이드오프

협상 상대별 핵심 전략

상대	1차 전략	마지막 카드	절대 금지
비즈니스 이해관계자	유행어 듣기 → 구체적 시간 단위로 환산 → 분할 정복	비용·시간 제시	처음부터 비용 얘기
다른 아키텍트	백문이 불여일견(PoC·벤치마크)	협상 일시 중단	직책으로 누르기
개발자	명분을 먼저 제시, 명령조 → 사실 진술	스스로 답을 찾게 유도	”윗사람 말이니까”

의사소통의 좋은 화법 vs 나쁜 화법

나쁜 화법	좋은 화법
”반드시 ~해야 한다"	"이는 ~라는 의미다"
"캐시를 사용해야 해요"	"캐시 사용을 고려해 봤나요?"
"분리해야 합니다"	"처리해 줄 수 있을까요?”
(이름 없이 요구만)	(이름 부르고 곤란함 인정 후 부탁)

4C 정렬 방향

항목	비전 편향	현실 편향	균형
의사소통	추상적 비전	구체적 제약	비전을 구체적 언어로
협업	자기 의견 강조	팀 의견 수용만	양방향
명확함	추상 용어 남발	단편적 디테일	의도+근거
간결함	장황한 설계서	부족한 설명	핵심만

내 생각

’~나인’의 함정은 SLA 문서에서 가장 많이 본다

SLO/SLA를 협상할 때 비즈니스 측이 무심코 “99.99%면 충분하지 않을까요?”라고 던지는 경우가 많습니다. 이때 그대로 받아 적으면 인프라 비용이 폭증합니다. 연간 다운타임 분 단위와 비용 추정치 를 함께 적은 표를 들고 들어가야 합니다. 가용성 1단계 차이가 인프라 비용을 몇 배 단위로 늘린다는 사실을 환산표로 제시하는 것 자체가 강력한 협상 카드입니다.

”백문이 불여일견”은 ADR과 PoC를 묶는 명분이다

다른 아키텍트와의 기술 선택 분쟁에서 가장 빠른 종결자는 동일 조건의 PoC입니다. 사내에 ADR(Architecture Decision Record) 작성 시 “Considered Alternatives” 섹션에 PoC 결과 또는 부하 테스트 결과 링크를 첨부하는 룰을 만들면, 감정적 논쟁이 데이터로 대체됩니다.

명령조 → 사실 진술은 코드 리뷰 코멘트에 그대로 적용된다

“~해야 한다”는 코멘트는 차단(blocking)으로, “~라는 의미다 / ~를 고려해 봤나요?”는 제안(suggestion)으로 받아들여집니다. PR 코멘트 컨벤션(Conventional Comments의 suggestion: nitpick: praise:)을 도입하면 이 화법이 자연스럽게 강제됩니다.

회의 통제는 캘린더 정책으로 자동화 가능

“안건 없는 회의는 자동 거절”, “오전 9~11시는 No-Meeting Block” 같은 정책을 캘린더 도구에 미리 박아두면 개인 의지에 의존하지 않고도 몰입 시간을 확보할 수 있습니다. Google Calendar의 Focus Time, Slack의 huddle 시간 차단 같은 기능이 이 책의 권고를 도구로 옮겨놓은 형태입니다.

더 알아볼 것

Tanya Reilly, 『The Staff Engineer’s Path』 — 시니어 개인 기여자의 정치·협상
Roger Fisher 외, 『Getting to Yes』 — 협상의 고전, 입장이 아닌 이해관계 협상법
Mihaly Csikszentmihalyi, 『Flow』 — 개발자 몰입 상태의 심리학
Jacqui Read, 『Communication Patterns』 — 원격 팀 의사소통 패턴
Gerald Weinberg, 『The Psychology of Computer Programming』, 『The Secrets of Consulting』
사내 ADR 템플릿에 “Considered Alternatives + PoC 결과 링크” 섹션 의무화
SLA 협상용 가용성↔다운타임↔인프라 비용 환산표 만들기
캘린더에 No-Meeting Block / Focus Time 정책 적용
PR 리뷰에 Conventional Comments 도입 검토

출처

소프트웨어 아키텍처 The Basics, Ch25 협상과 리더십 스킬

Dev Wiki

탐색기

Ch25 협상과 리더십 스킬

한 줄 정의

쉽게 말하면

왜 중요한가?

핵심 내용

비즈니스 이해관계자와의 협상

1단계: 유행어와 단서 듣기

2단계: ‘9의 개수’ 대신 구체적 시간 단위로 유도

가용성 수준별 연간 가동 중지 시간

3단계: 비용과 시간은 마지막 카드

4단계: 분할 정복 (divide-and-conquer)

다른 아키텍트와의 협상

백엔드 관점

개발자와의 협상

명령조 대신 명분을 먼저

개발자가 스스로 답을 찾게 하기

백엔드 관점

아키텍처의 4C — 우발적 복잡성과 싸우기

현실적이면서도 비전을 가져라

동시 접속자 급증 시나리오

솔선수범으로 팀 이끌기

협업 없는 의사소통은 문을 닫는다

요청(request)을 부탁(favor)으로

악수와 시선

의지가 되는 사람(go-to person)

개발 팀에 녹아들기 — 회의 통제

초대된 회의 줄이기

소집한 회의는 최소화

같은 사무실에서 옆에 앉기

비교 / 트레이드오프

협상 상대별 핵심 전략

의사소통의 좋은 화법 vs 나쁜 화법

4C 정렬 방향

내 생각

’~나인’의 함정은 SLA 문서에서 가장 많이 본다

”백문이 불여일견”은 ADR과 PoC를 묶는 명분이다

명령조 → 사실 진술은 코드 리뷰 코멘트에 그대로 적용된다

회의 통제는 캘린더 정책으로 자동화 가능

더 알아볼 것

관련 개념

출처

그래프 뷰

목차

백링크