나사 조직문화에서 배우는 실패와 혁신, AI팀에 적용하는 법
1986년 1월 28일, 미국 플로리다 케네디 우주센터. 우주 왕복선 챌린저호가 전 세계 언론의 생중계 속에서 힘차게 날아올랐다가, 불과 73초 만에 공중에서 산산조각이 났습니다.
이 장면을 다룬 책이 바로 『나사는 어떻게 일하는가』1입니다.
단순히 "나사( NASA)의 멋진 우주 이야기"가 아니라, "세계 최고 기술 조직도 어떻게 실패하고, 그 실패를 통해 어떻게 일하는 방식을 바꿔갔는가"를 다루는 내용이죠.
AI 개발자로서 이 책을 보고 느낀 건, 이게 그냥 우주 이야기가 아니라 우리 팀, 우리 회사, 그리고 내가 하는 프로젝트에 그대로 적용 가능한 "조직 운영 매뉴얼"에 가깝다는 거였습니다.
아래에서 나사의 조직문화, 협업 방식, 문제 해결 철학을 하나씩 풀어보겠습니다. 읽다 보면, 자연스럽게 "우리 팀은 어떻게 일해야 하지?"라는 질문으로 이어지실 거예요.
나사의 진짜 경쟁력은 '로켓'이 아니라 '조직문화'
나사는 겉으로 보면 하이테크 집합체처럼 보이지만, 속을 들여다보면 기술만큼이나 "조직이 어떻게 의사결정을 하고, 어떻게 말하고, 어떻게 실패를 다루는지"가 핵심입니다.
챌린저호 참사는 기술적인 문제(추운 날씨에서 O-링 고무 패킹이 굳어 제 역할을 못 한 것)로 발생했지만, 조사 결과가 밝힌 진짜 원인은 "조직문화와 의사결정 실패"에 더 가까웠습니다.
현장에서 "오늘 같은 기온에서 발사하면 위험하다"는 엔지니어들의 경고가 있었음에도, 여러 단계의 보고, 일정 압박, 정치적·대외적 부담 속에서 경영진은 발사를 강행했죠.
이 지점이 AI 개발자 입장에서 굉장히 익숙하게 느껴졌습니다. "이번 스프린트에 맞춰야 하니까", "고객 데모가 있어서", "이미 위에 보고 올라갔으니까" 같은 이유로 리스크를 알면서도 일단 진행해 본 경험, 한 번쯤 있으실 겁니다.
나사가 이후에 했던 일은 단순히 기술을 보강하는 것이 아니었습니다. 의사소통 구조, 리포팅 체계, 이견을 말할 수 있는 분위기, 리스크 관리 프로세스 등 "우리가 일하는 방식(work culture)" 전체를 다시 짜는 거였습니다.
결국 나사의 경쟁력은 로켓 기술이 아니라, 그 기술을 끝까지 검증하고, 반대 의견을 끌어올리고, 실패를 분석해서 다시 시스템으로 녹여내는 "조직의 운영 방식"에서 나온다는 메시지였죠.
실패를 숨기지 않고 해부하는 조직, 나사의 사고 대응 방식
챌린저호 폭발 이후 나사는 치열할 정도로 실패를 해부했습니다. 단순히 "누구 잘못이냐"를 찾는 게 아니라, "어떤 구조적 요인이 이 잘못된 결정을 만들었는가"를 끝까지 파고들었습니다.
여기서 인상 깊었던 포인트는 두 가지였습니다.
첫째, 실패를 "개인 실수"가 아니라 "시스템의 결함"으로 본다는 것. 어느 한 사람을 희생양으로 세우는 순간, 다른 사람들은 입을 닫습니다. 하지만 시스템의 문제로 접근하면, 구성원들이 훨씬 솔직하게 말할 수 있고, 실패가 "처벌의 대상"이 아니라 "학습의 원료"가 됩니다.
둘째, 기록과 공유를 집요할 정도로 중시한다는 것. 사건의 타임라인, 각 단계의 판단 근거, 사용한 데이터, 누가 어떤 우려를 냈는지까지 낱낱이 기록하고, 그걸 다시 전사적인 학습 자료로 돌립니다.
AI 프로젝트로 옮겨 보면, 예를 들어 서비스 론칭 후 심각한 버그나 데이터 이슈가 터졌을 때, "누가 이걸 OK 했냐"에서 끝나느냐, 아니면 "어떤 리뷰 프로세스가 비어 있었나, 어떤 신호를 우리가 놓쳤나"까지 가느냐에 따라 조직의 다음 1년이 완전히 달라집니다.
나사는 후자를 선택했고, 그래서 계속 날 수 있는 조직이 됐습니다. 실패를 덮지 않고, 아주 자세하게 문서화하고, 그걸 다음 프로젝트의 설계와 체크리스트에 반영하는 조직. 이게 나사의 진짜 면역체계입니다.
'계급보다 데이터' – 나사의 협업과 의사결정 원칙
나사의 협업 문화를 한 줄로 요약하면 "계급보다 데이터"였습니다.
엔지니어, 과학자, 관리자, 외부 파트너가 섞인 거대한 프로젝트에서 누가 직급이 높으냐보다 "누가 더 잘 측정하고, 더 잘 분석했느냐"가 중요했습니다.
물론 현실의 나사도 완벽하진 않았고, 챌린저호 같은 사건이 그 균열을 보여줬죠. 그래서 이후 나사는 의사결정에서 다음과 같은 원칙들을 강화합니다.
"우려사항을 말하는 사람"을 보호하고, 장려한다.
데이터와 실험 결과를 중심으로 토론한다.
일정, 정치적 압박, 대외 이미지보다 "안전"을 우선한다.
소수 의견이라도 공식 기록에 남긴다.
AI 개발팀에서도 이 구조를 그대로 가져올 수 있습니다. 예를 들어 모델 배포를 앞둔 상황에서
한 데이터 엔지니어가 "샘플 편향이 너무 심하다"고 말했을 때,
주니어 리서처가 "이 성능 수치가 과적합 같다"고 말했을 때,
그 목소리를 얼마나 진지하게 받아들이느냐가 조직의 수준을 그대로 드러냅니다.
저도 팀에서 리뷰를 할 때, "일단 시니어가 말했으니까 따라가자"가 아니라 "근거가 뭐지? 실험 로그 보여줄 수 있어?"로 대화를 돌렸을 때 훨씬 건강한 방향으로 가는 경험을 자주 했습니다.
나사의 메시지는 명확합니다. 권위가 아니라 근거로, 사람의 감이 아니라 데이터와 검증으로 의사결정을 하라는 것.
혁신을 유지하는 조직: 나사의 장기 프로젝트 운영법
나사의 미션은 대부분 "1-2 년짜리"가 아니라 "십 년짜리"입니다. 화성 탐사, 우주망원경, 달 기지 프로젝트 같은 것들을 보면 "프로젝트가 아니라 시대를 넘는 작업"에 가깝죠.
이런 초장기 프로젝트에서 나사가 선택한 방식은 "한 번에 혁신을 다 하려 하지 말고, 단계별로 작게, 지속적으로 진화하는 구조"였습니다.
새로운 미션을 수행할 때, 완전히 새로운 조직을 만드는 게 아니라 기존의 경험, 실패 기록, 검증된 모듈, 표준화된 체크리스트를 조합하면서 새 것을 올려 쌓는 방식입니다.
이건 AI 시스템 개발에도 똑같이 들어맞습니다.
하나의 모델로 모든 걸 해결하려 하기보다 용도별로 안정된 컴포넌트를 쌓고,
MLOps, 데이터 파이프라인, 모니터링 시스템을 조금씩 개선하며,
각 프로젝트에서 나온 삽질과 배움을 다음 프로젝트에 재사용하는 구조로 가는 것.
나사의 진짜 강점은 "한 번의 천재적인 아이디어"가 아니라 "오랜 기간 동안, 지치지 않고 개선을 누적하는 시스템"에 가깝습니다.
저는 이걸 보고 나서, 새로운 프로젝트를 할 때 "이번엔 완전히 새로 짜야지" 대신 "지난 번에 쌓아둔 걸 얼마나 잘 재활용할 수 있을까?"를 먼저 보게 됐습니다. 이게 장기적으로 훨씬 '나사스러운' 접근이더라고요.
나사의 경영철학이 오늘날 기업 전략과 만나는 지점
『나사는 어떻게 일하는가』가 흥미로운 이유는 이게 단순한 조직문화 에세이가 아니라, 오늘날 기업 전략에도 그대로 적용된다는 점입니다.
오늘날 기업이 직면한 환경을 나사 언어로 번역해 보면 이렇습니다.
불확실성: 우주 대신 시장과 기술 트렌드가 수시로 바뀝니다.
리스크: 모델 배포, 데이터 유출, 규제 리스크 등은 일종의 "발사 리스크"입니다.
이해관계자: 투자자, 고객, 내부 조직, 파트너는 나사의 정치·대외 관계와 비슷합니다.
이 상황에서 필요한 건 "한 번에 완벽하게 맞추는 전략"이 아니라 나사가 보여준 것처럼
리스크를 투명하게 드러내고,
다양한 관점을 모으고,
실패를 기록하며,
반복해서 학습하고,
데이터 기반으로 의사결정하는 방식입니다.
특히 마음에 들었던 부분은, 나사가 스스로를 "기술 조직"이 아니라 "학습하는 조직"으로 정의하고 있다는 느낌이었습니다.
우리도 팀을 이야기할 때 "우리는 AI 모델 잘 만드는 팀"이 아니라 "학습 속도가 빠른 팀"이라고 정의하면 일하는 방식이 조금씩 달라지더라고요.
시사점: 우리 팀이 '나사처럼' 일하기 위해 체크해볼 것들
책을 보면서 제일 크게 남은 건 "나사는 특별해서가 아니라, 특별해지기 위한 시스템을 만든 조직"이라는 점이었습니다.
개인적인 관점에서, 우리가 당장 해볼 수 있는 것들을 정리하면 이 정도로 정리됩니다.
첫째, 실패를 기록하는 습관. 서비스 장애, 모델 성능 이슈, 데이터 문제 등 큰 사건이 터질 때마다 "사건 리포트"를 남기고, 그걸 팀 온보딩 자료와 체크리스트로 재활용하는 구조를 만드는 것.
둘째, 계급보다 데이터. 리뷰 자리에서 "누가 말했느냐"보다 "어떤 근거와 실험이 있느냐"를 먼저 보는 문화를 팀 합의로 만드는 것. 특히 주니어가 낸 우려를 가볍게 넘기지 않는 태도는 생각보다 강력한 신호가 됩니다.
셋째, 일정보다 안전. 나사에게 '안전'이 생명이라면, 우리에게는 '서비스 신뢰도', '법적·윤리적 문제', '데이터 보안'이 그 역할을 합니다. "데드라인을 못 맞출 수도 있지만, 이 리스크는 그냥 갈 수 없다"는 말을 누군가는 조직 안에서 해줘야 합니다.
넷째, 혁신을 너무 드라마틱하게 만들지 않기. 완전히 새롭고 거대한 걸 하겠다고 덤벼들기보다, 기존 시스템 위에 작은 개선을 계속 올려 쌓는 방식을 선택하는 것. 나사의 장기 프로젝트 운영 방식에서 배울 수 있는 태도입니다.
마지막으로, 이 책을 읽으면서 "우리는 얼마나 솔직하게 걱정을 말할 수 있는 팀인가?"라는 질문을 계속 하게 되더군요.
챌린저호의 비극은 기술이 모자라서가 아니라, 이미 알고 있던 리스크를 끝까지 끌어올리지 못해서 벌어진 사건이었습니다.
우리의 다음 프로젝트가 "작은 챌린저호"가 되지 않으려면, 나사가 실패를 해부하며 만들어낸 그 일하는 방식을 우리 조직의 언어로 번역해서 가져오는 작업이 필요합니다.
AI를 만드는 우리는, 어쩌면 매일 작은 우주선을 쏘고 있는지도 모릅니다. 그렇다면, 나사가 어떻게 일하는지 공부하는 건 단순한 호기심이 아니라 꽤 실용적인 생존 전략에 가깝습니다.
참고
✨ Editor's Pick
이 노트는 요약·비평·학습 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.