중요한 것은 주제 자체보다 오늘의 판단과 실행 순서를 바꾸는지입니다.
파일명만 남은 20분
파일명 여덟 단어만 남은 문서를 앞에 두고 저는 20분째 그날 무슨 기술이 오갔는지 짐작만 하고 있었습니다. 지금 제 손에 있는 근거는 내부 원문 자료라는 제목뿐입니다. 날짜는 3월 20일인데 내용이 비어 있으니, 이 세션이 AI 자동화 이야기였는지 배포 장애 회고였는지, 협업 규칙 정리였는지 알 수 없습니다. 저는 이런 장면을 볼 때마다 한 가지를 더 세게 믿게 됩니다. 기술 공유는 발표 당일의 박수보다, 두 달 뒤 다시 꺼내 쓸 수 있게 남았는지가 더 중요합니다.
잘 설명하면 공유가 끝났다고 믿는 순간
많은 팀이 기술 공유를 “똑똑한 사람이 앞에 서서 잘 설명하는 시간”으로 끝냅니다. 저도 예전에는 그쪽에 가까웠습니다. 슬라이드가 깔끔하고 데모가 매끄러우면 충분한 줄 알았죠. 그런데 비개발자 직장인의 하루는 그렇게 굴러가지 않았습니다.
지난달 저는 40분짜리 도구 소개를 듣고 다음 날 같은 질문을 세 번 다시 보냈습니다. “그래서 이걸 누가 언제 쓰면 되죠?” “실패하면 어디부터 보면 되죠?” 발표는 분명 좋았는데, 제 업무에는 연결선이 없었습니다. 기술을 직접 만드는 팀에게는 자명한 말이, 현업 쪽 사람에게는 늘 반쯤 비어 있는 문장으로 남는 경우가 많습니다.
세션의 성패는 발표장이 아니라 2주 뒤에 드러난다
제 주장은 분명합니다. 기술 공유 세션의 성공 기준은 만족도나 참석 인원보다 재사용률이어야 합니다. 다시 말해, 2주 뒤 누군가 그 기록을 열었을 때 시간을 줄여주면 성공이고, 제목만 남기고 다시 물어보게 만들면 실패입니다.
이번 건에서 제가 확정할 수 있는 사실은 많지 않습니다. 2026년 3월 20일에 `박성수 개발실 기술 공유 세션`이라는 문서가 있었다는 것, 그리고 지금 공개된 맥락만으로는 실제 내용과 근거를 확인할 수 없다는 것. 저는 이 빈칸을 상상으로 메우고 싶지 않습니다. 오히려 이 빈칸 자체가 기술 공유의 약한 고리를 잘 보여준다고 봅니다. 세션이 끝난 뒤 남은 것이 파일명뿐이라면, 지식은 전달됐을지 몰라도 운영은 남지 않았습니다.
제가 이 문제를 예민하게 보는 이유도 실무에서 자주 데였기 때문입니다. 지난주 저는 번역 자동화 흐름을 다시 정리하다가, 두 달 전 들은 내부 설명 메모를 뒤졌습니다. 메모에 남은 문장은 “설정만 맞추면 바로 돌릴 수 있음” 한 줄이었고, 그 한 줄 때문에 저는 43분 동안 입력 형식 세 개를 번갈아 확인했습니다. 설명한 사람은 틀리지 않았습니다. 다만 듣는 사람에게 필요한 최소 단위가 빠져 있었습니다. 어떤 설정인지, 어디서 맞추는지, 실패하면 무엇이 먼저 깨지는지가 없었습니다.
AI 도구가 계속 바뀌는 지금은 이 문제가 더 커집니다. 새 모델 이름을 기억하는 것보다, 우리 팀에서 언제 어떻게 쓰는지 남기는 편이 더 오래 갑니다. 저는 기술 공유 메모를 볼 때 아래 네 칸이 비어 있으면 다시 물어볼 준비부터 합니다.
| 다시 쓰이는 공유 | 그날만 반짝한 공유 |
|---|---|
| 무엇이 바뀌었는지 한 문장으로 적혀 있다 | 배경 설명은 길지만 바뀐 행동이 안 보인다 |
| 누가 먼저 써야 하는지 적혀 있다 | “다들 써보면 좋다”로 끝난다 |
| 실패하면 확인할 지점이 2~3개 적혀 있다 | 데모는 성공했는데 예외 처리 메모가 없다 |
| 다음 실험이나 적용 날짜가 있다 | 좋은 아이디어로만 남고 주인이 없다 |
비개발자 직장인에게 기술 공유는 새 기계를 소개하는 시간이 아니라, 내일 아침 덜 헤매게 만드는 안내문이어야 합니다. 저는 발표를 잘하는 사람보다 “이걸 문서 한 장으로 남겨둔 사람” 덕분에 더 자주 시간을 아꼈습니다. 누군가는 이 기준이 너무 운영 중심이라고 싫어할 수 있습니다. 그래도 제 경험에서는, 멋진 설명보다 짧고 정확한 기록이 훨씬 오래 일했습니다.
> 기술 공유는 잘 말한 시간이 아니라, 다시 찾았을 때 시간을 줄여주느냐로 평가해야 합니다.
영감만 필요한 자리라면 제 기준이 과할 수 있다
물론 모든 세션을 작업 지시서처럼 만들 필요는 없습니다. 연구 탐색 자리나 초기 아이디어 공유라면, 거친 문제 제기만 있어도 충분한 경우가 있습니다. 이번 `박성수 개발실 기술 공유 세션`도 실제로는 그런 성격이었을 수 있습니다. 지금은 제목 외에 확인된 출처가 없으니, 제가 내용을 단정하는 쪽이 더 무책임합니다.
다만 영감 중심 세션이어도 최소 기록은 남겨야 한다는 생각은 바뀌지 않습니다. 왜냐하면 영감은 기억보다 빨리 증발하고, 사람들은 늘 세션보다 마감 쪽을 먼저 붙잡기 때문입니다. 저는 예전에 좋은 아이디어 메모를 “나중에 정리하지 뭐” 하고 넘겼다가, 3주 뒤에는 제 손글씨도 못 알아본 적이 있습니다. 그 뒤로는 기록의 품질보다 기록의 생존을 먼저 챙깁니다.
오늘 퇴근 전 세 줄만 남겨두면 된다
오늘 바로 할 일은 하나입니다. 최근 3개월 안에 들은 기술 공유 하나를 골라, 아래 세 줄만 다시 남겨두세요. 길게 쓰지 않아도 됩니다. 중요한 건 다시 찾을 때 바로 쓰이느냐입니다.
① 무엇이 바뀌었는가 ② 누가 먼저 써야 하는가 ③ 실패하면 어디부터 확인하는가
제가 복붙용으로 남기는 문장은 이겁니다.
“좋은 기술 공유는 이해를 넓히는 데서 끝나지 않고, 다음 행동을 줄여준다.”
오늘은 방금 떠오른 세션 하나를 골라 저 세 줄만 붙여두세요. 다음 편에서는 그 세 줄짜리 기록을 비개발자 팀도 바로 쓰는 운영 노트로 키우는 방법을, 제가 실제로 돌리고 있는 번역 자동화 사례와 함께 이어보겠습니다.
핵심 정리
- 파일명 여덟 단어만 남은 문서를 앞에 두고 저는 20분째 그날 무슨 기술이 오갔는지 짐작만 하고 있었습니다.
- 많은 팀이 기술 공유를 “똑똑한 사람이 앞에 서서 잘 설명하는 시간”으로 끝냅니다.
- 지난달 저는 40분짜리 도구 소개를 듣고 다음 날 같은 질문을 세 번 다시 보냈습니다.
→ 영어판 보기
