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

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

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

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

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

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

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

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

화요일 오전

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

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

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

한 달 뒤

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

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

[아키텍처 회의] 2026.01.27

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

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

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

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

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

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

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

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

예를 들어:

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

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

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

Cockburn은 이렇게 말했다:

리모트에서는 어떻게?

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

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

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

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

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

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

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

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

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

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

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

Working Out Loud는 다르다:

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

왜 이게 좋을까?

예시 상황:

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

Case 1: 조용히 일하기

Case 2: Working Out Loud

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 메신저가 아니라 "여유"를 뜻한다)에서 이렇게 말했다:

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

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

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

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

균형이 필요하다:

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

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

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

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

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

❌ 이렇게 하지 마라:

✅ 이렇게 하라:

왜? 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 모델:

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

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

흐르는 조직:

막히는 조직:

Accountability = 자연스러운 신뢰

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

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

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

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

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

핵심 원칙:

1. 공유 first, Online first

2. 완벽보다 흐름

3. 채널 > DM

4. 과정을 보여줘라

당장 실천할 수 있는 것:

오늘 오후부터:

이번 주부터:

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

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

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

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

LetWorkFlowByExample (last edited 2026-01-29 04:10:37 by 정수)