협업 시뮬레이션을 거부하는 엔지니어의 인지적 방어기제
새로운 프로젝트나 시스템 아키텍처를 구상할 때 머릿속으로 그리는 미래의 그림은 사람마다 완전히 다릅니다. 어떤 엔지니어는 요구사항을 확인하자마자 자신이 홀로 심야에 콘솔을 열고 복잡한 백엔드 파이프라인을 끝까지 완성해 내는 고독한 영웅의 장면을 떠올립니다. 반면 어떤 기획자나 개발자는 기획 단계부터 배포 후 장애 대응까지 동료들과 쉼 없이 슬랙 메시지를 주고받으며 끊임없이 확인 도장을 받는 장면을 먼저 머릿속에 채워 넣습니다.
우리는 이를 단순히 개인의 성향이나 일하는 스타일의 차이로 치부하곤 합니다. 혼자 묵묵히 코드를 밀어붙이는 사람은 독립적이고 책임감이 강한 전문가로, 동료의 의견을 계속 구하는 사람은 협업 지향적인 팀플레이어로 포장되기 쉽습니다. 그러나 우리가 프로젝트의 미래를 머릿속으로 시뮬레이션하는 방식 뒤편에는 훨씬 더 뿌리 깊은 심리학적 기전이 작동하고 있습니다.
미래를 상상할 때 타인의 존재를 자연스럽게 포함하는지, 아니면 완전히 지워버리는지는 우연한 상상이 아닙니다. 그것은 과거의 관계적 경험이 뇌의 시뮬레이션 엔진에 새겨놓은 정교한 방어 전략에 가깝습니다. 이 무의식적인 시뮬레이션 습관이 실제 소프트웨어 설계와 팀의 기술 부채로 어떻게 전이되는지 들여다볼 필요가 있습니다.
일화적 미래 사고가 프로젝트 설계를 지배하는 방식
인간은 아직 일어나지 않은 사건을 머릿속에서 구체적인 시나리오로 시뮬레이션하는 고유한 능력을 갖추고 있습니다. 심리학에서는 이를 일화적 미래 사고(Episodic Future Thinking)라고 부릅니다. 이 정신적 과정은 단순히 막연한 희망을 품는 것이 아니라, 특정 시간과 장소에서 자신이 무엇을 하고 어떤 감정을 느낄지 생생하게 예행연습하는 인지 기능입니다. 우리는 이 시뮬레이션을 통해 다가올 장애를 예측하고, 작업 일정을 가늠하며, 예상치 못한 위험에 대비합니다.
그런데 이 시뮬레이션 장면에 타인이 얼마나 개입하는지는 개인의 애착 유형에 따라 극명하게 갈립니다. PsyPost가 소개한 와세다대학교 양 판(Fan Yang) 교수와 오카야마대학교 장 저(Ze Zhang) 연구팀의 연구에 따르면, 성인 애착 유형 중 불안형 애착(Attachment Anxiety) 성향이 높은 사람들은 미래의 일화를 상상할 때 타인과의 사회적 상호작용과 지지를 과도하게 많이 포함하는 경향을 보였습니다. 반대로 회피형 애착(Attachment Avoidance) 성향이 강한 사람들은 미래를 시뮬레이션할 때 대인관계를 철저히 배제하고 혼자서 상황을 헤쳐 나가는 고립된 미래를 그렸습니다. 이 연구는 국제 학술지 '개인차 저널(Journal of Individual Differences)'에 게재되었습니다.
연구진은 타인을 배제한 미래를 그리는 사람들이 선천적인 외톨이라서가 아니라고 설명합니다. 오히려 타인과의 친밀함에서 오는 불편함과 거절의 불안을 피하기 위해 학습된 방어기제를 작동시키는 것입니다. 스스로에게만 의존하는 완벽한 미래를 머릿속으로 구축함으로써 타인에게 의존했다가 실망하게 될 위험을 원천 차단하려는 시도입니다.
문제는 이러한 개인의 인지적 방어기제가 복잡한 IT 시스템을 설계하고 운영하는 실무 현장에 그대로 투영된다는 점입니다. 소프트웨어 엔지니어링은 본질적으로 다수의 지식이 교차하는 협업 작업입니다. 그러나 일화적 미래 사고에서 동료를 지워버리는 엔지니어는 시스템을 구상하는 첫 단계부터 협업과 위임을 배제한 채 머릿속 설계를 완성해 버립니다.
타인을 배제한 고립된 설계가 맞닥뜨리는 비용
회피형 시뮬레이션을 작동시키는 엔지니어는 기술 명세서를 작성하거나 모듈을 분할할 때 무의식적으로 '나 혼자 통제할 수 있는 구조'를 지향합니다. 이들은 인터페이스를 명확히 정의하여 다른 팀원에게 작업을 분배하는 대신, 모든 비즈니스 로직을 자신이 직접 통제하는 단일 서비스나 복잡한 모듈 내부에 욱여넣는 경향을 보입니다. 다른 개발자가 자신의 코드에 개입하는 상황 자체를 미래 시뮬레이션에서 불편한 변수로 인식하기 때문입니다.
이러한 방어적 설계는 초기 개발 속도를 일견 빠르게 만드는 착시를 낳습니다. 커뮤니케이션 비용이 들지 않고, 복잡한 코드 리뷰나 아키텍처 싱크 회의를 거치지 않아도 되기 때문입니다. 하지만 시스템이 릴리스되고 운영 단계로 진입하는 순간 치명적인 병목이 발생합니다. 머릿속 시뮬레이션에서 동료를 배제했던 대가가 고스란히 현실의 부채로 돌아오는 것입니다.
가장 먼저 무너지는 것은 지식의 분산입니다. 회피적 시뮬레이션으로 구축된 컴포넌트는 오직 작성자 본인의 머릿속 모델에만 최적화되어 있습니다. 다른 팀원이 해당 코드를 수정하거나 기능을 확장하려 할 때 진입 장벽은 비정상적으로 높아집니다. 결국 해당 모듈의 버그 수정, 성능 최적화, 기능 추가 요청은 모조리 최초 작성자 한 사람에게 집중됩니다.
더 심각한 문제는 장애 대응 상황에서 드러납니다. 연구진이 지적했듯, 혼자서 모든 것을 해결하겠다는 인지적 방어는 상상했던 상황이 극심한 스트레스 환경으로 바뀌는 순간 맥없이 무너져 내립니다. 실제 프로덕션 환경에서 대규모 장애가 발생했을 때, 동료와 디버깅 로그를 공유하고 역할을 나누어 트래픽을 우회시키는 협업 프로토콜을 머릿속으로 연습해 본 적이 없는 엔지니어는 극심한 패닉에 빠집니다. 온콜(On-call) 부담을 홀로 짊어지다 번아웃에 직면하고, 시스템은 단일 장애점(SPOF)으로 전락합니다. 타인을 배제한 독립성은 전문성이 아니라 협업 실패를 예고하는 인지적 위험 신호였던 셈입니다.
승인에 매몰되어 결정을 마비시키는 불안형 시뮬레이션
반대로 미래를 상상할 때 타인의 개입과 반응을 과도하게 채워 넣는 불안형 시뮬레이션 역시 프로젝트를 다른 방식으로 마비시킵니다. 불안형 애착 성향이 높은 엔지니어는 코드를 한 줄 작성하거나 아키텍처 의사결정을 내릴 때마다 끊임없이 동료들의 평가와 잠재적 비판을 시뮬레이션합니다.
이들의 일화적 미래 사고는 기술적 검증보다 사회적 안전망 확보에 치우쳐 있습니다. '이 라이브러리를 선택했을 때 시니어 엔지니어가 나를 무능하게 보지 않을까?', '이 PR을 올렸을 때 리뷰어들이 내 설계를 비웃지 않을까?'와 같은 관계적 불안이 뇌의 작업 기억을 점유합니다. 결과적으로 이들은 스스로 결정을 내리지 못하고 사소한 구현 디테일까지 슬랙 채널에 공유하며 팀 전체의 합의를 요구합니다.
이러한 오버커뮤니케이션은 표면적으로는 민주적이고 꼼꼼한 협업처럼 보이지만, 실제로는 의사결정 지연과 책임 분산이라는 심각한 부작용을 낳습니다. 아키텍처 결정 레코드(ADR)를 작성하는 데 수 주일을 허비하고, 모든 팀원의 사소한 의견을 반영하려다 누더기 설계를 만듭니다. 기술적 트레이드오프를 데이터와 비즈니스 요구사항으로 판단하는 것이 아니라, 팀 내 역학 관계와 감정적 마찰을 피하는 방향으로 결정해 버리기 때문입니다.
결국 회피형의 고립된 독주와 불안형의 결정 마비는 동전의 양면입니다. 두 경우 모두 과거의 관계적 불안에서 비롯된 왜곡된 일화적 미래 사고가 프로젝트의 현실적인 리스크를 객관적으로 시뮬레이션하지 못하게 가로막고 있는 것입니다.
멘탈 시뮬레이션의 디폴트 설정을 재조정하는 실천
자신의 뇌가 미래를 시뮬레이션할 때 작동시키는 방어기제를 인지했다면, 이를 의도적으로 교정하는 작업이 가능해집니다. 이는 성격을 억지로 바꾸라는 의미가 아닙니다. 엔지니어링 프로세스와 인지적 장치를 통해 왜곡된 시뮬레이션을 현실적인 협업 모델로 동기화하는 훈련을 뜻합니다.
회피형 시뮬레이션으로 인해 혼자 코드를 떠안으려는 관성이 강하다면, 설계를 시작하는 첫날 '내가 이 시스템을 전혀 모르는 상태에서 인계받는다면?'이라는 역방향 시뮬레이션을 강제해야 합니다. 기술 문서를 작성할 때 내가 부재한 상황에서의 장애 조치 절차를 가장 첫 문단에 적어보는 것입니다. 또한 코드를 구현하기 전에 다른 동료와 인터페이스 명세를 먼저 합의하는 API 우선(API-first) 설계를 도입하거나, 핵심 모듈의 뼈대를 잡는 단계에서 페어 프로그래밍을 의무화하는 것도 효과적입니다. 동료가 내 설계에 개입하는 것이 시스템을 파괴하는 것이 아니라 견고하게 만든다는 경험적 데이터를 뇌에 지속적으로 주입해야 합니다.
불안형 시뮬레이션으로 인해 결정 장애를 겪고 있다면, 타인의 승인을 구하는 범위를 명확히 제한하는 가이드라인을 세워야 합니다. 모든 피드백을 수용하려 들지 말고, 명확한 거부권(Veto) 기준과 의사결정 시한을 캘린더에 못 박아두는 방식입니다. 아키텍처 결정 시 '완벽한 동의' 대신 '반대하되 헌신한다(Disagree and Commit)'는 원칙을 팀의 기본 규칙으로 삼고, 기술적 결정의 성패를 개인의 평판과 분리해 바라보는 인지적 거리두기가 필요합니다.
오늘 작성 중인 기술 명세서나 태스크 티켓을 가만히 들여다보시기 바랍니다. 머릿속으로 그리고 있는 그 시스템의 배포 당일 풍경에 동료의 자리는 마련되어 있습니까? 만약 혼자서 모니터를 응시하며 고군분투하는 장면만 선명하다면, 당신의 뇌는 지금 협업이 두려워 방어벽을 쌓고 있는 중일지도 모릅니다. 오늘 오후에는 혼자 해결하려 했던 설계의 고민 한 조각을 동료의 자리에 슬그머니 올려두는 것으로 시뮬레이션을 다시 시작해 보십시오.
이 글과 함께 읽으면 좋은 인사이트
댓글 0