2026-03-22-TIL: 기술 의사결정은 사람보다 구조를 설계해야 한다

기술적인 의사결정 과정에서 자주 부딪히는 문제는 “무엇이 더 좋은가”보다 “왜 서로 설득이 되지 않는가”인 경우가 많다.

특히 팀 간 협업에서는 이런 상황이 반복된다.

• 같은 문제를 보고도 전혀 다른 결론에 도달한다.
• 기술적으로 충분히 설명했는데도 반대가 계속된다.
• 논쟁은 길어지지만 결론이 나지 않는다.
• 결국 감정 소모만 커진다.

오늘은 이 문제를 설득의 문제가 아니라 구조의 문제로 보는 관점이 왜 중요한지 정리해봤다.

왜 기술적인 설득은 실패하는가

설득이 실패하면 보통 설명이 부족했거나, 논리가 약했거나, 상대가 이해하지 못했다고 생각하기 쉽다. 그런데 실제 원인은 대체로 다른 데 있다.

평가 기준이 다르다

같은 설계를 봐도 어떤 팀은 성능과 확장성을 먼저 보고, 어떤 팀은 운영 안정성과 유지보수성을 먼저 본다. 기준이 다르면 결론도 달라진다.

즉 설득이 안 되는 이유는 누가 틀려서가 아니라, 보고 있는 축이 다르기 때문이다.

책임과 리스크의 위치가 다르다

표면적으로는 “이 구조는 복잡하다”, “유지보수가 어렵다”는 말이 오가지만, 실제 속뜻은 다른 경우가 많다.

• 운영은 누가 맡는가
• 장애가 나면 누가 대응하는가
• 복잡도는 어느 팀 코드에 쌓이는가

기술 논쟁처럼 보여도, 실제로는 책임 분배 문제인 경우가 많다.

참여하지 않은 사람이 반대한다

의사결정 과정에 참여하지 않은 사람은 결과에 동의하지 않는 경우가 많다. 정보 부족이라기보다 프로세스 참여 부족에 가깝다.

결론만 전달하고 판단 과정을 공유하지 않는다

“이 구조가 더 좋습니다”만으로는 부족하다. 상대는 보통 다음을 알고 싶어 한다.

• 왜 다른 옵션은 버렸는가
• 어떤 리스크가 있는가
• 무엇을 포기했는가

설득은 결론 전달보다 판단 과정 공유에 가깝다.

설득의 목표를 바꿔야 한다

잘못된 목표는 상대를 납득시키거나, 내가 맞다는 것을 증명하는 것이다.

실제로 더 효과적인 목표는 다음이다.

• 의사결정 구조를 명확히 한다.
• 책임과 비용을 드러낸다.
• 선택 가능한 상태를 만든다.

결국 핵심 전환은 사람을 설득하는 것에서, 결정을 구조화하는 것으로 옮겨가는 데 있다.

실무에서 효과적인 접근

논쟁을 기술에서 기준으로 이동시킨다

예를 들어 먼저 이런 질문을 던질 수 있다.

이 논쟁은 어떤 기준 차이에서 발생하고 있는가?

그 다음 성능 vs 유지보수성, 개발 속도 vs 운영 안정성, 단기 vs 장기처럼 기준을 명시한다. 그러면 감정적인 충돌이 구조적인 비교로 바뀐다.

옵션을 공정하게 구조화한다

선택지를 “내 안”과 “상대 안”으로 나누지 말고, 모두가 인정할 수 있는 옵션 A, 옵션 B 형태로 정리하는 편이 낫다. 이때 상대 의견도 공정하게 포함돼야 한다.

트레이드오프를 드러낸다

좋은 의사결정 문서는 정답을 선언하기보다, 무엇을 얻고 무엇을 포기하는지를 보여준다.

• A는 단순하지만 확장성이 제한된다.
• B는 유연하지만 운영 복잡도가 증가한다.

이 표현이 있어야 논쟁이 “틀렸다”에서 “다르다”로 옮겨간다.

책임 구조를 직접 묻는다

실무에서는 이 질문이 의외로 가장 강력하다.

• 이 선택의 운영 책임은 어느 팀이 가져가는가
• 장애가 발생하면 어느 팀이 대응하는가
• 복잡도는 어느 팀에 쌓이는가
• migration 비용은 누가 부담하는가

이 질문을 던지면 숨겨져 있던 갈등이 더 빨리 드러난다.

합의가 안 되면 decision owner를 분명히 한다

모든 논쟁을 끝까지 설득으로 밀어붙일 필요는 없다. 구조와 트레이드오프를 충분히 공유했는데도 합의가 안 되면, 누가 최종 결정을 내릴지 분명히 하는 편이 낫다.

극단적인 설계 충돌은 타협보다 격리가 낫다

예를 들어:

• Monolith vs MSA
• Sync vs Event-driven
• ORM vs Raw SQL

이런 문제는 억지로 중간을 섞으면 오히려 더 나빠지는 경우가 많다.

이때는 다음 같은 방식이 더 현실적이다.

• 인터페이스로 분리해 내부 구현을 독립 유지한다.
• 적용 영역을 나눠 core와 edge의 기준을 다르게 둔다.
• feature flag, strategy pattern, adapter처럼 선택 가능 구조를 둔다.

핵심은 하나로 통일하는 것보다, 공존 가능한 구조를 만드는 것이다.

문서화가 설득을 대신한다

실무에서 가장 강한 도구는 말보다 문서다. 좋은 문서에는 최소한 다음이 들어가야 한다.

• 옵션
• 트레이드오프
• 오너십
• 운영 책임
• 실패 시나리오

특히 누가 운영하고, 누가 장애에 대응하고, 누가 비용을 부담하는지를 명시해야 한다. 설득이 어려운 이유는 기술보다 책임이 숨겨져 있기 때문인 경우가 많다.

실무에서 바로 쓰기 좋은 질문

논쟁을 구조로 바꾸는 질문은 이런 것들이다.

• 이 결정의 오너는 누구인가
• 장애가 발생하면 어느 팀이 대응하는가
• 복잡도는 어느 팀에 쌓이는가
• 변경 비용은 누가 부담하는가
• rollback이 가능한 구조인가
• 이 결정이 틀렸을 때 어떻게 되돌릴 것인가

정리

기술 의사결정에서 중요한 것은 상대를 이기는 설득이 아니라, 모두가 같은 판단 구조를 보게 만드는 일이다.

결국 핵심은 이것이다.

• 기준을 맞추고
• 옵션을 드러내고
• 트레이드오프를 설명하고
• 책임 구조를 분명히 하는 것

기술 의사결정에서 끝까지 남는 질문은 “무엇이 더 좋은가”보다 “누가 무엇을 책임지는가”에 더 가깝다.