엔지니어 협업에서 가장 이상적인 자세는 “내 문제를 내가 어느 정도 정리한 뒤, 다른 시각을 더하는 것”이다. 처음부터 아무 준비 없이 브레인스토밍부터 남의 힘을 빌리려 드는 건 협업이 아니라 민폐에 가깝다. 반대로 끝까지 자기 견해만 고집하는 것 역시 협업의 이점을 스스로 지워버리는 행동이다.
이 글에서는 엔지니어 협업에서 흔히 보이는 두 가지 극단을 짚고, 실마리를 먼저 잡아놓고 협업에 임하는 자세가 왜 더 날카로운 해결책을 만드는지를 이야기한다.
엔지니어 협업에서 흔히 보이는 2가지 극단
현장에서 일하다 보면 협업 방식이 극단적으로 나뉘는 사람들을 자주 만나게 된다.
첫 번째 유형은 끝까지 자기 주장만 고집하는 엔지니어다. 자신의 분석과 판단을 신뢰하는 것 자체는 좋다. 문제는 그 신뢰가 다른 시각을 차단하는 방어막이 될 때다. 이미 세운 가설에 반하는 데이터나 의견이 나와도 수용하지 않고, 협업을 “내 결론에 동의를 구하는 절차”로 취급한다. 이런 방식에서는 집단의 시각이 더해져도 아무것도 날카로워지지 않는다.
두 번째 유형은 협업을 면죄부로 쓰는 엔지니어다. 문제가 생기면 아무것도 정리하지 않은 채로 먼저 동료에게 달려간다. “같이 생각해보자”는 말은 좋은 의도처럼 들리지만, 실제로는 문제 정의부터 데이터 파악까지 상대방에게 떠넘기는 구조가 된다. 엔지니어 협업이 상부상조가 아닌 짐 떠넘기기로 전락하는 순간이다.
두 유형 모두 협업의 형태는 갖추고 있지만, 실질적인 시너지는 만들어내지 못한다.
엔지니어 협업이 진짜 빛나는 순간 — 실마리를 들고 가라
좋은 엔지니어 협업이 이루어지는 장면을 떠올려보면 공통점이 있다. 문제를 들고 온 사람이 이미 “어느 정도 정리된 상태”라는 점이다.
1차 데이터를 직접 봤고, 어디서 이상이 생겼는지 범위를 좁혀뒀고, 본인 나름의 가설도 세워져 있다. 완벽하지 않아도 괜찮다. 중요한 건 “방향을 잡을 수 있는 상태”다.
이 상태에서 동료의 경험에서 비롯된 새로운 시각이 더해지면 두 가지 일이 일어난다.
첫째, 문제가 더 날카롭게 다듬어진다. 내가 놓친 변수, 내가 당연하게 여겼던 전제가 외부 시선에 의해 드러난다. 혼자였다면 그냥 지나쳤을 지점이 핵심 원인으로 부각되기도 한다.
둘째, 더 창의적인 해결 방안이 나온다. 동일한 문제를 다른 현장, 다른 경험에서 바라보면 접근 방식 자체가 달라진다. 내가 “이 방법밖에 없다”고 생각했던 지점에서 전혀 다른 루트가 열리는 경우가 생긴다.
F1 레이스에서 이런 상황을 상상해보자. 레이스 엔지니어가 타이어 성능 저하 패턴을 혼자 분석하다가 해결책을 못 찾은 상황에서, 레이스 전략가에게 “3랩째부터 그립이 급격히 떨어지는데, 코너 진입 속도와의 상관은 확인했고, 타이어 온도 데이터는 이렇다”라고 정리해서 공유한다. 전략가는 서킷 특성과 날씨 데이터를 조합해 전혀 다른 피트 스탑 타이밍을 제안한다. 이게 진짜 협업이다.
아무 준비 없이 “타이어가 이상한 것 같은데 같이 봐줘”라고 한다면? 전략가는 레이스 엔지니어가 해야 할 1차 분석을 대신 떠안게 된다.
문제를 잘 정리한다는 것의 의미
“1차 분석을 해야 한다”는 말이 완벽한 해결책을 혼자 찾아야 한다는 뜻은 아니다. 엔지니어 협업에서 말하는 정리의 수준은 다음 3가지면 충분하다.
| 항목 | 의미 | 예시 |
|---|---|---|
| 현상 범위 파악 | 언제부터, 어느 조건에서 발생하는가 | “3월 2주차 이후, B라인에서만 발생” |
| 1차 데이터 확인 | 눈에 보이는 수치·로그·패턴을 직접 읽은 상태 | “파라미터 로그에서 특정 구간 변곡점 확인” |
| 초기 가설 보유 | 완벽하지 않아도 방향을 가리키는 가설 | “설비 A의 노후화 가능성 또는 레시피 변경 영향” |
이 세 가지를 갖추고 협업에 임하면, 동료는 처음부터 문제를 이해하는 데 에너지를 쏟지 않아도 된다. 바로 “네가 못 본 곳”을 들여다볼 수 있게 된다.
도메인 지식과 데이터 분석의 관계를 이전 포스팅에서 다뤘는데, 문제를 정리하는 능력 역시 도메인 지식에서 나온다. 데이터를 읽을 줄 알고, 현장의 맥락을 알기 때문에 “어디서 이상이 생겼는지”를 스스로 좁혀갈 수 있다.
새로운 시각에 열린 자세를 갖는 3가지 방법
실마리를 들고 가는 것만큼 중요한 게 있다. 내가 가져간 가설이 틀렸을 때 그것을 받아들이는 자세다.
1. 가설을 결론이 아닌 질문으로 제시한다
“원인은 A다”가 아니라 “A가 원인일 가능성이 있는데, 어떻게 생각하나?”로 프레임을 바꾼다. 가설을 결론처럼 제시하면 상대방은 반박보다 동의를 먼저 고민하게 된다. 질문으로 던지면 상대방의 경험이 자연스럽게 개입된다.
2. 반박을 데이터로 받는다
“그건 아닌 것 같은데”라는 말보다 “그 가설이 맞으면 이 데이터가 설명이 안 되지 않나?”라는 형태의 피드백이 더 유용하다. 내가 반박을 들었을 때도 마찬가지다. 감정적으로 받지 않고 “어떤 데이터를 근거로 하는가”를 먼저 묻는 습관이 필요하다.
3. 협업 이후 내 분석을 업데이트한다
대화가 끝난 뒤 새로운 시각을 그냥 흘려보내지 않는다. 내가 처음 세운 가설과 무엇이 달라졌는지, 어느 부분이 보완되었는지를 짧게라도 정리한다. 이 과정이 반복되면 다음 문제를 정리할 때의 질이 올라간다. 메타 프롬프팅과 유사한 구조다 — 생각의 구조를 외부에 검증받고, 다시 내부로 흡수하는 사이클.
마무리 — 기본은 내가, 방향은 함께
엔지니어 협업의 이상적인 모습은 결국 하나의 문장으로 요약된다.
나의 문제는 내가 기본적인 방법으로 해결할 수 있다는 자세에서 시작하되, 문제를 잘 정리하고 공유하며 새로운 견해에 열린 마음을 갖는 것.
고집도 의존도 아닌, 준비된 개방성. 그게 엔지니어 협업에서 가장 날카로운 자세다.
이 글에서 다룬 “문제를 정리하는 능력”은 결국 도메인 지식에서 출발한다.
새로운 시각에 열린 자세를 AI와의 협업에도 적용하고 싶다면 이어서 읽어볼 만하다.
영화 아이언맨을 감상하며 Refresh도 하고 Inspiration도 얻어보자
