메시지 펌핑: 일의 흐름을 공유하는 법

• "프로젝트의 속도는 아이디어가 사람들의 마음 사이를 이동하는 속도다." - Alistair Cockburn

에피소드: 정리해서 올릴게요

월요일 오전 10시, 아키텍처 회의.

"결정했습니다. 다음주부터 API 스펙을 RESTful 방식으로 전면 변경합니다. user_id는 userId로 카멜케이스 통일하고..."

1년차 개발자 준호의 머리가 복잡해졌다. 자기가 짜고 있는 로그인 기능이 통째로 바뀌어야 한다는 뜻이다. 회의 내용을 노트북에 끄적인다.

"준호씨, 이거 회의록 정리해서 공유 부탁합니다." "네, 정리해서 팀 채널에 올릴게요."

오후 2시, 급한 버그 티켓이 떨어진다. "결제 모듈 에러 긴급 수정 요청". 준호는 회의록을 까맣게 잊는다.

오후 4시, 배포 이슈. 5시, 기획자와 갑작스런 미팅. 6시, 정신을 차리고 보니 회의 내용이 가물가물하다. '아, 회의록... 내일 아침에 정리해야지.'

화요일 오전

"준호씨, API 스펙 어떻게 된 거예요?"

같은 팀 선배 지훈이가 묻는다. 지훈이는 어제부터 user_id를 쓰는 새 기능을 개발하고 있었다. 준호의 머릿속에만 있던 정보가 흐르지 않았다.

결국 세 명의 개발자가 옛날 스펙으로 코드를 짰고, 다음주에 다시 고쳐야 했다.

한 달 뒤

준호는 다르게 일하기 시작했다.

회의가 시작되자마자 Slack 개발팀 채널에 쓰레드를 연다.

[아키텍처 회의] 2026.01.27

회의 중에 실시간으로 타이핑한다. 정리된 문장이 아니다. 듣는 대로 적는다.

- API 스펙 변경: user_id → userId (카멜케이스 통일)
- 시작: 다음주 월요일
- 마이그레이션 가이드: 김과장님이 내일까지 공유 예정
- 주의: 기존 20개 엔드포인트 영향받음

회의가 끝나기도 전에 댓글이 달린다.

• 💬 백엔드 이팀장: "그럼 DB 스키마도 맞춰야겠네요. user_id 컬럼명 변경 스크립트 준비하겠습니다"
• 💬 프론트 박대리: "오 감사합니다. 저도 바로 반영할게요"
• 💬 QA 정과장: "테스트 케이스 업데이트 일정 잡았습니다"

준호는 완벽하게 정리된 문서를 만들지 않았다. 날것 그대로의 정보였다.

하지만 흘렀다. 공기처럼.

개념 1: Osmotic Communication - 공기처럼 스며드는 정보

"삼투압 커뮤니케이션"이라고 번역하면 어색하니, 그냥 "공기 같은 정보 흐름"이라고 생각하자.

애자일 방법론의 선구자 AlistairCockburn이 이름 붙인 개념이다. 팀원들이 한 공간에 있을 때, 누군가의 대화를 우연히 듣고 관련 정보를 얻게 되는 현상을 말한다.

예를 들어:

상황 1: 회의실 옆 자리에서 두 사람이 대화한다. "이 API 호출하면 타임아웃 나네요." "그래? 어떤 API?" "/users 엔드포인트요. 300ms 넘어가면 튕겨요."

옆에서 코딩하던 당신, 귀가 쫑긋한다. '어? 나도 그 API 쓰는데?' 당신은 바로 자기 코드를 확인한다. 아니나 다를까, 타임아웃 예외 처리가 없었다. 버그를 미리 막았다.

누구도 당신에게 직접 말하지 않았다. 공지도 없었다. 하지만 정보는 공기처럼 스며들었다.

Cockburn은 이렇게 말했다:

• "프로젝트의 속도는 아이디어가 사람들의 마음 사이를 이동하는 속도다."

리모트에서는 어떻게?

재택근무, 하이브리드 근무가 일상화된 지금, 물리적으로 같은 공간에 있기 힘들다.

그럼 osmotic communication은 불가능한가? 아니다.

핵심은 "공개 채널"이다.

• DM으로 물어보면 → 두 사람만 안다
• 채널에서 물어보면 → 모두가 듣는다

Slack, Teams, Discord. 도구는 중요하지 않다. 중요한 건 대화가 흐르는 공간이 있느냐다.

"준호야, 그거 어떻게 됐어?" (DM) → ❌ "@준호 그거 어떻게 됐어요?" (개발팀 채널) → ✅

두 번째는 다른 팀원들도 본다. 맥락도 공유된다. 나중에 검색도 된다.

개념 2: Working Out Loud - 일하면서 소리내기

이건 John Stepper라는 사람이 정리한 개념이다. 한국어로 번역하면 "일하면서 큰 소리로 말하기" 정도?

핵심은 이거다: 일의 과정을 보여주면서 일한다.

보통 우리는 이렇게 일한다:

1. 일을 한다 (혼자서, 조용히)
2. 완성한다
3. 발표한다 "짜잔! 완성했어요!"

Working Out Loud는 다르다:

1. 일을 시작하면서 공유한다 "이거 시작합니다"
2. 진행하면서 공유한다 "여기서 막혔어요" "이 방법 써봤는데 좋네요"
3. 완성하면서도 공유한다 "거의 다 됐어요" "이런 점 개선하고 싶은데 의견 있나요?"

왜 이게 좋을까?

예시 상황:

당신이 새로운 로그 수집 시스템을 만들고 있다고 하자.

Case 1: 조용히 일하기

• 2주 동안 혼자 열심히 코딩
• 완성해서 PR 올림
• 리뷰어: "어? 우리 이미 Datadog 쓰기로 했는데요?"
• 당신: "...😱"

Case 2: Working Out Loud

• 1일차: 채널에 공유 "로그 수집 시스템 조사 중. ELK vs Datadog 비교표 만들고 있어요"
• 팀장: "아, Datadog 이미 계약했어요. 가이드 문서 공유할게요"
• 당신: "오 감사합니다! 그럼 Datadog 연동부터 시작하겠습니다"
• 2주 낭비 방지 ✅

5가지 요소 (어렵지 않다)

John Stepper가 정리한 Working Out Loud의 요소들:

1. 관계(Relationships): 결국 사람이다. 혼자보다 함께.

2. 너그러움(Generosity): "이거 제가 삽질한 건데, 여러분은 참고하세요"

3. 가시적 작업(Visible Work): 뭘 하는지 보여준다

   "오늘 OAuth 연동 시도 중. 
   구글 문서 이해가 잘 안 가네요. 
   혹시 예제 코드 있으신 분?"

4. 목적있는 발견(Purposeful Discovery): 그냥 떠드는 게 아니라, 목표가 있다

5. 지속적인 학습: 실험하고, 피드백받고, 개선한다

완벽하지 않아도 된다

이게 핵심이다.

"이 부분 어떻게 해야 할지 모르겠어요." ✅ "이 라이브러리 써봤는데 이런 점이 좋더라고요." ✅ "3시간 삽질했는데 알고보니 오타였습니다 ㅠㅠ" ✅

이런 게 다 Working Out Loud다. 창피한 게 아니다. 이게 쌓여서 팀 전체가 똑똑해진다.

개념 3: Message Pumping - 프로그램이 살아있으려면

개발자라면 한 번쯤 겪었을 것이다. 프로그램이 "응답 없음" 상태가 되는 순간.

특히 GUI 프로그래밍에서 흔하다. Windows 프로그램이 하얗게 변하며 "(응답 없음)"이라고 뜨는 거.

왜 그럴까? 메시지 루프가 멈췄기 때문이다.

# 간단히 표현하면 이런 느낌
while True:
    message = get_message()  # 클릭, 키보드, 타이머 등
    if message:
        process_message(message)
    # 계속 메시지를 처리해야 UI가 살아있다

버튼 클릭, 키보드 입력, 타이머 이벤트... 이런 메시지들이 계속 처리되어야 프로그램이 살아있다.

만약 어떤 함수가 메시지 루프를 막으면?

def heavy_task():
    for i in range(1000000):
        calculate_something()  # 10분 걸림
    # 이 동안 메시지 처리 안 됨 → 응답 없음!

사용자가 닫기 버튼을 눌러도, 아무 반응이 없다. 시스템은 "이 프로그램 강제 종료할까요?"라고 묻는다.

팀도 마찬가지다

팀에서 정보 공유가 없으면 = 메시지 루프가 멈춘 상태

당신이 2주 동안 조용히 일한다:

• 동료들은 당신이 뭘 하는지 모른다
• 막혀있는지, 잘 진행되는지 모른다
• 도움이 필요한지 모른다
• 우선순위가 바뀌었는지 모른다

팀 전체가 "(응답 없음)" 상태다.

주기적으로 공유하면 = Message Pumping

"오늘 X 기능 50% 완료했습니다" "Y 부분에서 막혔는데, 내일 Z 방법 시도해볼게요" "테스트 통과했습니다. 리뷰 부탁드려요"

이런 작은 메시지들이 계속 흐르면:

• 팀이 살아 숨쉰다
• 우선순위가 실시간으로 조정된다
• 도움이 필요한 곳에 사람이 모인다
• 막혔을 때 빨리 발견된다

Efficiency vs Effectiveness

Tom DeMarco는 『Slack』(여기서 Slack은 Slack 메신저가 아니라 "여유"를 뜻한다)에서 이렇게 말했다:

• 효율성(efficiency)과 효과성(effectiveness)은 반비례 관계다.

혼자 몰두하면: 개인 효율은 높아진다. 방해받지 않고 집중. 생산성 UP.

하지만 팀 전체로 보면: 효과성이 떨어진다.

"지금 집중 중이니까 내일 얘기해주세요."

이 말이 나오는 순간, 정보는 막힌다. 동료는 하루를 기다린다. 그 동안 잘못된 방향으로 갈 수도 있다.

균형이 필요하다:

• 집중 시간도 필요하다 (Deep Work)
• 하지만 주기적인 공유도 필요하다 (Message Pumping)

9시-12시: 집중 모드 12시-12시 10분: 진행 상황 공유 12시 10분-: 점심

이런 식으로. 하루에 한 번, 혹은 주요 마일스톤마다.

그래서 어떻게 해야 하나? (실천 방법)

이론은 충분히 들었다. 이제 실천이다.

1. 회의록은 실시간으로 적는다

❌ 이렇게 하지 마라:

• 회의 중에 노트북에만 메모
• "정리해서 올리겠습니다"
• 집에 가서 기억 더듬으며 정리
• 다음날 아침에 업로드

✅ 이렇게 하라:

• 회의 시작 → 바로 공유 채널에 쓰레드 생성
• 회의 중 → 듣는 대로 타이핑 (날것 그대로)
• 완벽한 문장 아니어도 OK
• 회의 끝 → 이미 공유 완료

왜? 1. 핵심 정보는 지금 당장 필요할 수 있다 2. 기억은 시간이 지날수록 왜곡된다 3. 정리는 나중에도 할 수 있다 (실시간 공유가 먼저)

2. 작업 로그를 습관화한다

매일 퇴근 전 5분, 혹은 주요 진행 시점마다 짧게 적는다:

[2026.01.27 오후]
- 로그인 API 연동 완료 ✅
- OAuth 토큰 갱신 로직 50% 진행 중 🚧
- CORS 문제로 막힘. 백엔드팀 문의 예정 ❓

이게 보고가 아니다. 나를 위한 기록이다.

3개월 뒤, 성과 평가 시즌이 왔다. "제가 뭘 했더라?" 당황할 필요 없다. 로그를 쭉 보면 된다.

그리고 부수 효과: 다른 사람들이 공기처럼 흡수한다.

3. DM 말고 채널을 쓴다

시나리오 1: DM 사용

[준호 → 지훈 DM]
준호: 지훈씨, /users API 타임아웃 나는데 어떻게 해결하셨어요?
지훈: 아, 나는 retry 로직 넣었어요

→ 두 사람만 안다. 다른 팀원은 같은 문제로 또 삽질한다.

시나리오 2: 채널 사용

[#backend 채널]
준호: @지훈 /users API 타임아웃 나는데 어떻게 해결하셨어요?
지훈: 아, 나는 retry 로직 넣었어요. 코드 공유할게요
[코드 스니펫]
민수: 오 저도 같은 문제 겪었는데 감사합니다!
팀장: 이거 공통 모듈로 빼면 좋겠네요

→ 모두가 배운다. 문제가 해결책으로 발전한다.

원칙: 개인적인 내용 아니면 채널에서.

4. 완벽을 기다리지 않는다

완벽주의의 함정:

• "정리가 안 됐으니까 나중에..."
• "이건 부끄럽네..."
• "좀 더 다듬고..."

결과: 정보가 머릿속에 갇힌다.

Better done than perfect:

불완전해도 공유:

[공유] 회의 녹음 파일입니다. 
회의록은 내일 정리해서 올릴게요. 
급하신 분들은 녹음 파일 참고하세요.

실패도 공유:

[삽질 로그] 
Redis Cluster로 바꾸려고 3일 시도했는데 
우리 트래픽엔 오버엔지니어링이었습니다.
단일 Redis로 충분해요. 
괜히 복잡하게 하지 마세요. (저처럼...)

→ 이게 지식이다. 다른 사람이 같은 실수를 안 한다.

5. 실전 예시: 일일 스탠드업을 비동기로

매일 오전, 각자 채널에 올린다:

[준호 - 2026.01.27]
어제: 로그인 API 완료
오늘: OAuth 토큰 갱신 작업
막힌 점: CORS 설정 관련 문서 찾는 중. 혹시 예제 있으신 분?

[지훈 - 2026.01.27]
어제: 결제 모듈 리팩토링
오늘: 테스트 코드 추가
막힌 점: 없음. 순조롭게 진행 중

[민수 - 2026.01.27]
어제: 외부 회의로 개발 못 함 ㅠㅠ
오늘: 회의록 정리 + 어제 못 한 작업 이어서
@준호 CORS 설정 제가 문서 있어요. 공유할게요!

30분짜리 회의 → 5분으로 단축. 그리고 시간대 상관없이 확인 가능.

6. 도구는 중요하지 않다

Slack이든, Teams든, Discord든, Notion이든.

중요한 건 도구가 아니라 습관이다.

이 습관:

• 일하면서 공유한다
• 완벽하지 않아도 공유한다
• 채널에서 공개적으로 소통한다
• 작은 업데이트를 자주 한다

이것이 쌓이면: 조직의 피가 된다

2000년대 초반, 집단지성(collective intelligence)과 수렴(convergence)이 화두였다.

일본 학자 노나카 이쿠지로(Ikujiro Nonaka)는 조직의 지식창조를 연구했다. 그의 SECI 모델:

• Socialization: 암묵지를 공유 → 이게 바로 osmotic communication

• Externalization: 명시지로 전환 → Working Out Loud

• Combination: 명시지를 결합 → 문서화, 위키

• Internalization: 내재화 → 학습

첫 단계부터 막히면 아무것도 시작되지 않는다.

지식이 흐르는 조직 vs 막히는 조직

흐르는 조직:

• 누가 무엇을 아는지 안다
• 같은 실수를 반복하지 않는다
• 신입이 빠르게 배운다
• 퇴사해도 지식은 남는다 (채널에 기록됨)

막히는 조직:

• "그건 김과장이 알아" (김과장 휴가가면 끝)
• 같은 질문을 매년 새로 한다
• 신입이 6개월 동안 헤맨다
• 퇴사하면 지식도 증발한다

Accountability = 자연스러운 신뢰

Working Out Loud를 하면 책임성(accountability)이 자동으로 생긴다.

억지로 보고하는 게 아니다. 일의 흔적이 자연스럽게 쌓인다.

• "내가 뭘 했는지" 굳이 증명 안 해도 됨 → 이미 다 봤으니까
• 문제가 생겨도 "왜 안 말했어?" 안 나옴 → 실시간으로 공유했으니까
• 투명하게 일하는 사람 = 신뢰받는 사람

성과 평가 시즌에 "제가 올해 뭘 했더라?" 고민 안 해도 된다. 채널 검색하면 1년치 기록이 나온다.

마무리: 오늘부터 시작하자

프로그램에서 message pumping이 없으면 "(응답 없음)"이 뜬다. 조직에서 정보 공유가 없으면 팀 전체가 멈춘다.

핵심 원칙:

1. 공유 first, Online first

• 정리해서 올리겠다 (❌) → 일단 올리고 정리하겠다 (✅)

2. 완벽보다 흐름

• 100% 정리된 문서 하나 < 70% 정보를 5번 공유

3. 채널 > DM

• 두 사람만 아는 것 < 모두가 듣는 것

4. 과정을 보여줘라

• 결과만 공유 < 진행 과정을 공유

당장 실천할 수 있는 것:

오늘 오후부터:

• [ ] 회의 있으면 실시간으로 채널에 적기
• [ ] 퇴근 전 5분, 오늘 한 일 한 줄 적기
• [ ] 질문하려고 DM 열었으면, 채널에 쓰기

이번 주부터:

• [ ] 작업 시작할 때 "이거 시작합니다" 공유하기
• [ ] 막히면 "여기서 막혔어요" 솔직히 말하기
• [ ] 해결하면 "이렇게 해결했어요" 공유하기

정보가 흐르면 조직이 산다. 정보가 막히면 조직이 죽는다.

작은 메시지들이 모여 큰 흐름을 만든다. 그 흐름이 조직의 피가 되고, 지식이 되고, 신뢰가 된다.

지금 당장, 채널을 열어라. 그리고 타이핑을 시작하라.

"이거 지금 시작합니다."