좋은 시도를 사내에 소개해도, "좋은 이야기였네요"로 끝나버린다.

나는 과거에 5년 이상, 이 벽에 몇 번이고 부딪혀 왔습니다.

하지만 전달 방식을 바꾼 결과, 지금 회사에 입사한 지 1년 만에 다음과 같은 상태가 되었습니다.

• 개별적으로 상담해 준 사람: 20명 이상
• 내가 소개한 지견(知見)을 활용해 준 팀: 10팀 이상

이 기사에서는 권한이 없는 한 명의 엔지니어가, 좋은 시도를 "듣고 끝"내지 않고 다른 팀에서도 시도해 보게 만들기 위해 했던 일을 적습니다.

다만, 처음부터 잘 되었던 것은 아닙니다.

이전의 나는 내 팀에서 잘 된 방식을 다른 팀에서도 더 많이 시도해 주길 바랐습니다.

예를 들어, 새로운 툴을 도입하여 작업을 효율화하거나, AI를 사용하여 번거로운 조사나 정형 작업을 자동화하거나, 태스크(Task) 진행 방식을 가시화하거나, 그러한 작은 고안으로 생산성이 올라가기도 합니다.

내 팀에서 그러한 효과가 나타나면 정말 기쁩니다.

그리고 엔지니어라면 그 지견을 다른 팀에도 도움이 되길 바라는 마음이 들지 않을까요?

"이 방식은 꽤 좋다"

"분명 다른 팀에도 도움이 될 것이다"

"Slack으로 소개하거나 사내 발표를 하면 모두가 시도해 줄 것이다"

나는 그렇게 생각했습니다.

하지만 실제로는 그렇게 쉽게 퍼지지 않았습니다.

발표 후에 "좋은 이야기였네요"라는 말을 듣는다. Slack에 리액션도 달린다. 그 자리에서는 호의적으로 받아들여 준다.

하지만 다음 날부터 다른 팀의 업무 방식이 바뀌는 것은 아니다.

이것은 한두 번의 이야기가 아닙니다.

당시의 나는 조금 불만을 느끼고 있었습니다.

"왜 시도해 주지 않는 걸까"

"똑같이 하면 좋아질 텐데"

하지만 지금 되돌아보면, 시도해 주지 않았던 이유는 상대에게 있었던 것이 아니라 나의 전달 방식에 있었습니다.

나는 좋은 시도를 "소개"하고 있다고 생각했습니다.

하지만 상대의 고민거리나 우선순위를 모르는 채, 내 팀에서 잘 된 방식을 그대로 건네주고 있었을 뿐이었습니다.

어느 팀에게나 그때 안고 있는 과제나 우선순위가 있습니다. 좋아 보이는 방식을 들어도 지금 당장 곤란해하는 문제와 연결되지 않으면 시도할 이유가 되기 어렵습니다.

게다가 새로운 방식을 시도하려면 적게나워 에너지가 필요합니다. 지금의 진행 방식을 바꿔도 되는지, 누구에게 상담해야 하는지, 어디서부터 시작해야 하는지, 시도한 결과 잘 되지 않으면 어떻게 할 것인지. 그러한 작은 불안이나 번거로움이 있으면 "좋아 보이지만 지금 우리에게 어떻게 사용해야 할지 모르겠다"에서 멈춰버리는 경우가 있습니다.

그로부터 나는 수년에 걸쳐 조금씩 방식을 바꾸었습니다.

몇 번이고 "좋은 이야기였네요"로 끝났습니다. 내 팀에서 잘 된 방식을 소개하고 있다고 생각해도 상대에게는 닿지 않는 일이 있었습니다. 나의 지견을 강요하려다 잘 되지 않은 적도 있습니다.

그렇기에 좋은 시도를 퍼뜨리고 싶다면 내용 그 자체뿐만 아니라 전달 방식을 바꿀 필요가 있었습니다.

몇 년간 시행착오를 겪는 가운데 조금씩 알게 된 것이 있었습니다.

• 자기 팀에서 계속 시도하며 현장의 지견을 늘린다
• 발신을 통해 인지도를 만든다
• 개별 대화를 거듭한다
• 상대의 고민거리에 맞춰 지견을 건넨다

그 결과, 서두에 쓴 것처럼 지금 회사에서는 조금씩 좋은 시도를 다른 팀에서도 시도해 주게 되었습니다.

예를 들어, 자기 팀에서 시도한 태스크 진행 방식이나 회고(Retrospective)의 고안이 다른 팀에서도 사용되게 되었습니다. AI 에이전트를 사용한 업무 자동화 지견이 엔지니어뿐만 아니라 PdM, PjM, 고객용 콘텐츠 작성, 문의 지원 등 엔지니어가 아닌 다양한 직종의 업무 개선으로 이어지기도 했습니다.

나중에 "가르쳐 주신 방법으로 잘 되었습니다", "그 방식, 우리 팀에서도 사용할 수 있었습니다"라는 말을 듣기도 했습니다.

이것은 상상 이상으로 기쁩니다.

내가 직접 손을 움직여 한 일이 아니더라도, 나의 경험이나 실패에서 얻은 지견이 누군가의 일을 조금 편하게 하거나 다른 팀의 전진으로 이어지는 것. 그렇게 느껴지는 순간이 있습니다.

나아가 발신과 대화를 계속하다 보면 "이 테마라면 상담할 수 있겠다"라는 생각을 얻게 됩니다. 상담을 받게 되면 다른 팀의 고민거리를 알 수 있습니다. 내가 몰랐던 고안을 배울 수도 있습니다. 그렇게 내가 가진 지견을 건네줄 뿐만 아니라, 조직 안에 있는 지견이 내 쪽으로도 모여들게 됩니다.

물론, 갑자기 조직 전체가 바뀐 것은 아닙니다. 그럼에도 불구하고, 자 팀에서 계속 시도하고, 발신하며, 대화하고, 상대방의 어려움에 맞춰 지견을 전달하다 보면, 권한이 없어도 다른 팀의 다음 한 걸음에 관여할 수 있게 됩니다. 그 상태는 일하면서 매우 즐겁습니다.

여기서는 실제로 했던 것을 최대한 재현하기 쉬운 형태로 작성하겠습니다.

길기 때문에, 핵심 내용만 알고 싶은 분들은 각 장 마지막에 있는 추천 액션만 읽으셔도 괜찮습니다.

제목의 '흑역사 이야기'에 흥미를 느낀 분들은 '3.4 흑역사 이야기: 실패담은 거리를 좁힌다'를 봐주시면 좋겠습니다.

좋은 활동을 다른 팀에 전파하고 싶다면, 먼저 자신 자신이 살아있는 현장의 지견을 가지고 있어야 합니다.

여기서 말하는 지견은 깔끔하게 정리된 일반론이 아닙니다.

'이 방법이 좋아 보이니 한번 시도해 보자'라고 생각해서 시도해 봤더니, 실제로는 어디에서 막혔는지. 어떤 조건에서는 잘 되었고, 어떤 조건에서는 맞지 않았는지를. 그런, 현장에서 시도했기 때문에 알 수 있는 이야기입니다.

AI의 진화로 인해 일반적인 노하우는 누구나 얻기 쉬워지고 있습니다. 그렇기에 가치 있는 것은 자신의 팀에서 실제로 시도하고, 고민하고, 조정하며, 조금 전진한 경험입니다.

저는 1년 전(2025년 6월)에 Yayoi Corporation에 입사하여 한 스크럼 팀에 배치되었습니다. 팀에는 이미 스크럼 마스터도, PdM도, 디자이너도, 엔지니어도 있었습니다. 팀으로서 필요한 역할은 갖추어져 있었습니다.

직함은 엔지니어링 매니저였지만, 팀이나 조직에 대한 권한은 아무것도 가지고 있지 않았습니다. 일부러 한 명의 엔지니어로 팀에 들어가 개발 업무를 하면서, 바텀업으로 개선 제안을 해나갔습니다.

제가 이 1년 동안 해 온 것도 특별한 권한을 사용한 것은 아닙니다. 개발 업무를 하면서 아침 회의 방식을 조금 고치거나, 태스크 착수 시 집중 검토를 철저히 하는 등, 작은 개선을 조금씩 시도해 왔습니다.

하나하나가 작은 시행입니다. 하지만 그러한 시행을 거듭하다 보면, 자신 안에 '현장에서 시도한 지견'이 늘어납니다.

단순히 '이 프랙티스가 좋은 것 같다'라고 말하는 것이 아니라, '우리 팀에서는 이런 어려움이 있어서 이렇게 시도했더니, 여기는 효과가 있었다. 하지만, 여기는 맞지 않았다'라고 이야기할 수 있게 됩니다.

상대방 팀에 지견을 전달할 때, 일반론만으로는 '과연, 좋아 보이네요'에서 끝나기 쉽습니다. 하지만 자신의 현장에서 일어난 것까지 포함해서 말할 수 있다면, 상대방도 자신의 팀에 대입하여 생각하기 쉬워집니다.

추천 액션: 좋은 활동을 전파하고 싶다면, 먼저 자신 자신이 살아있는 현장의 지견을 많이 갖는다. 그를 위해 자 팀에서 작게 시도해 볼 개선을 제안해 본다.

자 팀을 계속 시도하는 팀으로 만들기 위해서는, 개선을 너무 무거운 의사결정으로 만들지 않는 것이 중요합니다.

새로운 방식을 제안할 때, '앞으로 쭉 이 방식으로 갑시다'라고 들으면, 받는 쪽은 신중해집니다. 정말 효과가 있는 걸까? 운영이 늘어나지는 않을까? 지금의 방식을 망가뜨리진 않을까. 그렇게 생각하면, 시도하기 전부터 무거워집니다.

그래서 저는 최대한 작게 시도하려고 했습니다.

일단 2주만 시도해 본다. 좋아 보이면 계속한다. 안 맞으면 그만둔다.

이렇게 가볍게 하면, 새로운 방식을 시도하기 쉬워집니다.

참고로, 제가 과거에 제 팀에서 시도했던 프랙티스는 30건 이상 있으니, 참고해 주세요. 여기서 전하고 싶은 포인트는, 정책의 세부 절차가 아닙니다.

좋은 활동을 전파하는 데 필요한 것은, 완벽한 성공 사례를 갖는 것이 아니라고 생각합니다.

자 팀에서 계속 시도하며 잘 된 것도, 잘 안 된 것도, 다음 사람이 시도할 수 있는 형태로 말로 남겨두는 것이 중요합니다.

추천 액션: 개선을 제안할 때는 '일단 2주만 시도해 보고, 안 맞으면 그만둡시다'와 함께 전달해 본다. 그런 경험이 많아지면, 다른 팀에도 전할 수 있는 살아있는 지견이 늘어난다.

여기서는 자 팀에서 시도하여 얻은 지견을 아직 면식이 없는 팀들에게 알리는 이야기가 이어집니다.

저는 자 팀에서 시도했던 것과 얻은 지견을 사내 엔지니어 조직 전체(약 300명)가 보는 Slack 채널에 게시했습니다. 사내 LT에서도 발표했습니다. 외부에서 발표한 자료도 사내에 공유했습니다.

하지만, 다수에게 발신했다고 해서 바로 조직이 바뀌는 것은 아닙니다.

이것도 과거에 여러 번 느껴왔던 것입니다.

발신하면 반응은 있습니다. '좋네요', '참고가 되었습니다'라고 말해주는 경우도 있습니다. 하지만 그것만으로 다른 팀의 방식이 바뀌지는 않습니다.

그렇다면, 많은 사람에게 발신하는 것은 의미가 없는 것일까요? 그렇지 않습니다.

왜냐하면, 많은 사람에게 발신하는 역할은 그 자리에서 상대방이 도입을 결정하게 만드는 것이 아니기 때문입니다.

타 팀에는 타 팀만의 사정이 있습니다. 지금 당장 곤란해하고 있는 것, 우선순위를 두고 있는 것, 팀의 상태, 멤버 구성, 사용할 수 있는 시간이 다릅니다. 우리가 "좋은 시도입니다"라고 소개하더라도, 상대방의 구체적인 고민과 연결되지 않는다면 즉시 시도되지 않는 것은 자연스러운 일입니다.

그러므로, "좋은 이야기였네요"로 끝나는 것 자체가 실패는 아닙니다.

많은 사람에게 발신하며 우선 만들어야 하는 것은 도입이 아니라 인지(Recognition)입니다.

"이 사람은 이런 생각을 하고 있구나"

"이런 프랙티스(Practice)를 시도하고 있구나"

"곤란할 때 상담할 수 있겠구나"

그렇게 생각할 수 있는 입구를 늘리는 것이 발신의 역할입니다.

그 자리에서 누군가의 팀이 바뀌지 않더라도, 훗날 그 사람이 비슷한 과제에 직면했을 때, "그러고 보니 그 사람이 무언가 시도하고 있었지"라고 떠올려 줄지도 모릅니다. 발신은 그 미래의 상담을 위해 씨앗을 뿌리는 행위이기도 합니다.

추천 액션: 많은 사람에게 발신하는 것은 "즉시 도입하게 하기 위해서"가 아니라, "이 테마라면 상담할 수 있겠다"라고 생각하게 만들기 위해 수행한다.

인지를 만들기 위해서는 한 번 크게 발신하는 것보다, 작은 접점을 여러 번 만드는 것이 더 효과적이라고 생각합니다.

저는 자 팀(Self-team)에서 시도한 것을 Slack에 게시했습니다. 성공한 시책뿐만 아니라, 왜 시도했는지, 어떤 과제가 있었는지, 해보고 나서 무엇을 알게 되었는지도 쓰도록 했습니다.

실제로 개발 조직 전체의 Slack 채널에 게시한 내용도 처음부터 거창한 제안만 있었던 것은 아닙니다.

예를 들어, Notion으로 Jira와 같은 티켓 관리(Ticket management)를 시도하고 있었을 때는, "티켓 완료 시 완료일을 자동으로 설정하는 방법"을 자 팀에서 사용하던 설정 예시와 GIF를 곁들여 공유했습니다.

이 정도의 작은 팁(Tips)이라도 비슷한 운영을 하고 있는 팀에게는 그대로 시도해 볼 수 있는 재료가 됩니다. 포인트는 자신이 한 일을 다른 사람이 재현할 수 있는 정보를 덧붙이는 것입니다. 예를 들어, 수행한 절차를 적어두면 다음 사람이 시도하기 쉬워집니다.

외부에 게시한 기사도 사내 Slack으로 소개했습니다. 외부 발표용 슬라이드도 단순히 URL만 붙이는 것이 아니라, "이 자료에서는 무엇을 이야기했는지", "사내 팀 빌딩(Team building)과 관련될 만한 포인트는 어디인지"를 덧붙여 공유했습니다.

사내 LT(Lightning Talk) 대회에서도 발표했습니다. 70명 정도가 모이는 부회(Department meeting)에서도 발표했습니다. 전 사원 대상 이벤트에서 발표 시간을 얻어 이야기한 적도 있습니다.

또한, Findy Team+의 추진 역할로도 자원했습니다. 공식 서포트 담당자로부터 배운 내용이나, 우리 팀에서 시도하며 알게 된 점을 Slack이나 부회에서 공유했습니다.

외부 이벤트에서의 발표 예정 사항도 Slack에 게시했습니다. Scrum Fest에서 발표하게 된 것, Nikkei Newspaper 주최 이벤트에 스피커로 초대받은 것, Qiita FM에 게스트로 출연하게 된 것 등도 공유했습니다.

예를 들어, Scrum Fest에서 발표하게 되었을 때는 발표 예정 사항뿐만 아니라, 왜 도전했는지, 어떤 테마로 이야기할 것인지도 덧붙여 게시했습니다.

이것은 "나는 밖에서도 발표하고 있다"라고 과시하고 싶어서가 아닙니다.

외부에서 발표할 기회가 있다는 것은, 그 테마에 대해 자신이 일정 수준의 경험이나 지견을 가지고 있다는 것을 사내 사람들에게 알릴 수 있는 기회이기도 합니다. 그렇게 되면 같은 테마로 고민하는 사람이 있을 때, "이 사람에게 물어보면 어떤 힌트가 있을지도 모른다"라고 생각하기 쉬워집니다.

이렇게 쓰면 사내 발신을 아주 많이 한 것처럼 보일지도 모르겠습니다.

하지만 중요한 것은 "눈에 띄는 곳에서 발신하는 것"이 아닙니다.

중요한 것은 자신이 무엇을 시도하고 있는지, 무엇 때문에 곤란해하는지, 무엇을 배웠는지를 주변 사람들이 여러 번 보게 되는 상태를 만드는 것입니다.

첫걸음은 강연이나 큰 이벤트일 필요가 없습니다. 자 팀에서 시도한 작은 노하우를 재현 가능한 형태로 Slack에 두는 것만으로도 충분합니다.

Slack의 짧은 게시물이어도 좋습니다. 사내 LT여도 좋습니다. 부회의 5분 발표 시간이어도 좋습니다. 외부 기사나 발표 자료를 사내에 공유하는 것만으로도 충분합니다.

그러한 접점이 늘어날수록 "이 사람은 팀 개선에 대해 지속적으로 시도하는 사람이다"라는 인지가 조금씩 쌓입니다.

그리고 그러한 인지가 있으면, 후술할 개별 대화의 자리에서도 "이 사람은 실제로 여러 가지를 시도하고 있는 사람이다"라고 생각하기 쉬워지며, 이야기에 귀를 기울여 주기가 더 수월해집니다.

추천 액션: 인지(Recognition)는 한 번의 큰 발신이 아니라, 작은 발신의 축적으로 만들어진다. 그러므로 Slack 게시, 사내 LT(Lightning Talk), 부회 발표 등을 통해 지속적으로 공유하라.

사외 이벤트나 기사를 통해 강하게 배운 점이 있다면, 사내에서 발표할 기회를 만들 수 없을지 고민하기 시작했습니다.

컨퍼런스(Conference)에 참가하면 많은 배움이 있습니다.

참가 리포트를 작성하여 Slack으로 공유하는 방법도 있습니다. 물론 그것만으로도 의미는 있습니다.

다만, 기사나 리포트는 읽는 사람의 편의에 따라 읽을 수 있다는 장점이 있는 반면, 아무래도 "이런 세션을 들었습니다"라는 공유로 끝나기 쉽습니다. 읽은 사람이 자신의 업무와 어떻게 관련되는지까지 상상하기에는 약간의 거리감이 있습니다.

반면, 발표 형식을 취하면 배운 내용뿐만 아니라, 자신이 왜 그것을 중요하다고 생각했는지까지 전달하기 쉬워집니다.

발표에는 같은 시간과 장소를 공유하는 장점이 있습니다. 청자가 그 시간 동안만 테마에 집중해주기 때문에, 기사를 훑어볼 때보다 이야기의 배경이나 문제의식까지 받아들이기가 더 수월합니다.

또한, 발표에서는 왜 그 이야기를 중요하다고 생각했는지, 어디에서 충격을 받았는지, 자신의 현장에서 무엇을 바꾸고 싶다고 생각했는지를 목소리의 온도나 완급 조절(Pause)을 포함하여 전달할 수 있습니다. 지식뿐만 아니라 "이 테마를 정말 중요하게 생각하고 있다"라는 열량(Energy)도 전달하기 쉽습니다.

사람은 올바른 정보만을 보았을 때는 좀처럼 움직이지 않습니다. 하지만 발표를 들으면 그 사람이 무엇에 문제의식을 가지고 있는지, 어떤 경험을 해왔는지, 어떤 가치관으로 팀을 개선하려고 하는지가 전달됩니다. 단순히 지식을 알게 하는 것을 넘어, "이 사람은 이런 점을 중요하게 여기는 사람이구나"라고 인물상 자체를 알릴 수 있습니다.

그 위에서 중요한 것은, 사외에서 얻은 배움을 우리들의 현장에서 시도할 수 있는 언어로 치환하는 것입니다.

"이 세션이 좋았습니다"라고만 하는 것이 아니라, "우리 회사의 팀 빌딩에 대입하면 이 부분이 활용 가능해 보입니다", "지금 우리들의 현장이라면 우선 여기서부터 시도해 볼 수 있을 것 같습니다"라고 자신의 언어로 정리하여 말합니다.

그렇게 하면 듣는 사람은 컨퍼런스의 내용을 자신의 업무와 연결 지어 생각하기 쉬워집니다. 단순한 이벤트 참가 리포트가 아니라, 자신의 팀에서 시도해 볼 수 있는 힌트로 받아들이기 쉬워집니다.

저의 경우에는 Agile Japan이라는 컨퍼런스에 일반 참가한 후, 엔지니어 조직 전체를 대상으로 자율 참여 방식의 45분 발표로서 회의 안내를 보내 실시했습니다.

발표에서는 인상 깊었던 프랙티스(Practice)를 그대로 소개하는 것에 그치지 않고, 우리 조직이라면 어디에 활용할 수 있을지, 우선 무엇부터 시도할 수 있을지도 덧붙여 이야기했습니다.

Slack으로 발표 안내를 할 때도 단순히 "참가 리포트를 발표합니다"라고 쓰지 않았습니다. 왜 이 테마를 공유하고 싶은지, 어떤 사람에게 들려주고 싶은지, 들으면 무엇을 얻어갈 수 있는지(Takeaway)를 먼저 적었습니다.

발표 내용을 자세히 설명하기 전에, "이것은 우리 조직과도 관련이 있을 것 같다"라고 느낄 수 있는 입구를 만들기 위해서입니다. 바쁜 와중에 자율 참여 발표에 참석하게 하려면, 내용의 정확성뿐만 아니라 자신의 업무와의 연관성이 보이는 것이 중요하다고 생각합니다.

결과적으로 약 100명이 참가해 주었고, 발표 후에는 "이 프랙티스를 우리 팀에서도 시도해 보고 싶다"라는 목소리도 많았습니다. 단순히 이벤트 내용을 알리는 것을 넘어, 우리들의 현장에서 내딛을 다음 단계로서 받아들여 주었다고 생각합니다.

이러한 발표를 통해 배운 내용뿐만 아니라, 자신이 어떤 과제 의식을 가지고 있는지도 전달됩니다. 그렇게 되면 "이 테마로 고민이 생기면 이 사람에게 물어보자"라고 생각할 가능성도 높아집니다.

그러므로 강하게 배운 점이 있다면 참가 리포트만으로 끝내지 말고, 발표 형식으로 전달하는 것을 추천합니다. 그 배움을 자신의 현장에 맞는 언어로 다시 전달하고, 자신이 무엇에 과제를 느끼며 무엇을 개선하고 싶어 하는지까지 전달하는 것은, 수평적 영향력(Lateral Influence)을 만들기 위한 유효한 한 걸음이 됩니다.

추천 액션: 사외 이벤트나 기사에서 강하게 배운 점이 있다면, 참가 리포트만으로 끝내지 말고 사내에서 발표할 기회를 만들어라. 무엇을 배웠는지뿐만 아니라, 왜 중요하다고 생각했는지, 우리들의 현장이라면 무엇부터 시도할 수 있을지까지 전달하라.

사외에서 얻은 배움을 사내에서 사용할 수 있는 형태로 치환하여 돌려주는 것과 마찬가지로, 자신의 경험에서 얻은 배움도 읽는 사람에게 전달되는 형태로 바꿀 수 있습니다.

AI의 진화로 인해 교과서적인 지식이나 일반론은 점점 더 얻기 쉬워지고 있습니다. 리뷰(Review) 방법도, 심리적 안전성(Psychological Safety)의 중요성도, 피드백(Feedback)의 요령도 AI에게 물어보면 깔끔하게 정리된 답이 돌아옵니다.

그렇기에 지견(知見)을 발신할 때 가치를 갖는 것은, 자신이나 자신의 팀이 실제로 시도해서 무엇이 일어났는지에 대한 생생한 이야기입니다.

정말로 효과가 있었는지. 어디에서 막혔는지. 어떤 오해가 생겼는지. 직접 해보면서 사고방식이 어떻게 변했는지.

그런 이야기는 오직 그 사람만이 이야기할 수 있습니다.

그중에서도 실패담은 강력한 소재가 됩니다.

실패담에는 성공담과는 다른 읽기 쉬운 매력이 있습니다.

성공한 이야기를 읽으면 "대단하다", "참고가 된다"라고 생각하는 한편, "그건 그 사람이니까 가능했던 것 아닌가", "우리 팀과는 상황이 다르다"라며 조금 멀게 느껴지기도 합니다.

반면, 실패담에는 거리감을 좁히는 힘이 있습니다.

"맞아, 나도 저럴 것 같아"

"나도 비슷한 일을 하고 있었을지도 몰라"

"이 실패는 피하고 싶다"

이렇게 생각하게 만든다면, 실패담은 단순한 부끄러운 이야기가 아니라 누군가가 같은 함정을 피하기 위한 지견(知見)이 됩니다.

저는 과거의 팀 매니지먼트(Team Management) 과정에서 여러 가지 실패를 해왔습니다.

리뷰(Review)에서 수십 건의 지적을 하여 상대방의 자신감을 상실하게 만든 적이 있습니다.

회의에서 발언하지 않는 사람에 대해, "발언하지 않는 쪽에 원인이 있다"라고 단정 지어 생각한 적이 있습니다.

페어 프로그래밍(Pair Programming)에서 제가 더 잘 알고 있다고 생각하여, 상대방의 의견을 솔직하게 받아들이지 못한 적이 있습니다.

매우 부끄러운 과거입니다.

하지만 이런 실패담이야말로 실패를 회피하기 위한 지견(知見)이 가득 담겨 있습니다.

그래서 저는 저의 과거 팀 매니지먼트 실패를 단순한 노하우(Know-how) 기사가 아니라, 더 흥미롭게 읽을 수 있는 이야기로서 전달하기로 했습니다.

그 시도가 바로 라이트 노벨 스타일의 사내 연재물인 「흑역사 이야기」입니다.

자신의 흑역사를 일부러 드러내고, 그 상태에서 어떻게 생각을 바꾸고 어떻게 개선해 나갔는지를 이야기로 만들었습니다.

의식한 점은 처음부터 정답을 설명하지 않는 것이었습니다.

먼저 과거의 내가 무엇을 생각하고 있었는지 쓴다. 왜 그런 행동을 해버렸는지 쓴다. 그 결과 상대방에게 어떤 일이 일어났는지 쓴다. 그리고 나중에 되돌아보며 어디가 틀렸었는지, 어떻게 사고방식을 바꾸었는지를 쓴다.

그렇게 하면 독자는 "정답을 배우는" 것이 아니라, "실패의 과정을 함께 체험하는" 형태가 됩니다.

나아가 제목이나 썸네일(Thumbnail)도 조금 더 읽고 싶어지도록 의식했습니다.

단순히 "리뷰의 실패에서 배운 점"이라고 쓰는 것보다, "자신감을 상실시키는 리뷰의 어둠"이라고 쓰는 편이 무엇이 일어났는지 궁금해집니다.

단순히 "모브 워크(Mob Work) 권장"이라고 쓰는 것보다, "직접 하는 게 더 빠르다는 저주를 푸는 모브 워크"라고 쓰는 편이 과거의 자신에게도 더 와닿는 느낌이 있습니다.

지금까지 공개한 5화의 제목은 다음과 같습니다.

• 제1화 「자신감을 상실시키는 리뷰의 어둠」
• 제2화 「직접 하는 게 더 빠르다는 저주를 푸는 모브 워크」
• 제3화 「회의에서 발언을 이끌어내지 못한 원인은 나였다」
• 제4화 「이런 것도 몰라?라며 거들먹거리던 나」
• 제5화 「가르치고 있다고 생각하며 기회를 빼앗고 있었다」

黒歴史物語1.png

↑ 이것은 제1화의 아이캐치(Eye-catch) 이미지(제 사진을 AI로 가공한 것)

모든 제목이 과거 자신의 실패가 그대로 보이도록 했습니다.

그렇기에 무엇이 일어났는지 궁금해지기 쉬운 것이라고 생각합니다.

"나도 비슷한 일을 하고 있을지도 모른다"라고 생각하게 만드는 이야기는 단순한 노하우보다 독자의 마음에 더 쉽게 파고들 때가 있습니다.

감사하게도 사내에서도 많은 분이 읽어주셨습니다. 엔지니어뿐만 아니라 매니저, 서포트, 홍보 등 다양한 직군의 분들에게도 전달되었습니다.

실제로 감상평에서도 "속이 쓰렸다", "지적하는 입장에서 뼈아픈 이야기다", "나도 똑같은 경험이 있다고 생각했다"와 같은 목소리가 있었습니다. 이는 실패담이 단순한 읽을거리로 소비된 것이 아니라, 독자 자신의 경험이나 행동과 겹쳐졌기 때문이라고 생각합니다.

나아가 "무의식적인 편견이 없는지 생각하는 계기가 되었다", "나도 주의해야겠다고 생각했다", "나의 실패담을 발신하는 것에도 도전해보고 싶다"와 같은 반응도 있었습니다. 읽은 사람의 마음이 조금 움직여 다음 행동이나 성찰로 이어졌다는 점은, 흑역사 이야기로서 전달했기에 가능했던 효과였다고 느낍니다.

읽히게 만들기 위해서는 공개하는 것으로 끝내지 않는 것도 의식했습니다.

흑역사 이야기를 사내보에 공개했을 때는 전 사원(약 800명)이 참여하는 Slack 채널에도 게시했습니다. 단순히 URL만 붙이는 것이 아니라, "내가 더 우월하다고 착각하고 있었다", "그 착각 때문에 실망스러운 페어 프로그래밍을 하고 있었다"와 같이 자신의 실패가 보이는 도입부를 작성하여, 흥미를 갖기 쉬운 형태로 소개했습니다.

지견(知見)은 올바르게 설명하는 것만으로는 전달되지 않을 때가 있습니다.

읽고 싶게 만드는 형태로 변환함으로써 비로소 전달될 때가 있습니다.

만약 자신 안에 "예전의 나는 이렇게 실패했다", "지금이라면 다르게 협업했을 것이다"라고 생각할 수 있는 경험이 있다면, 그것을 사내에서 하나의 이야기(Story)로서 공개해 보시는 것을 추천합니다.

조금 부끄러운 실패담일수록, 똑같이 고민하고 있는 누군가에게 닿을 때가 있습니다.

그렇다고는 해도, 처음부터 이야기 형태로 쓰는 것은 어렵다고 생각합니다.

참고할 수 있는 것이 있는 편이 쓰기 쉬울 것이라 생각하기에, 필요하다면 저의 원고를 전달해 드리겠습니다.

참고로, "흑역사 이야기(黒歴史物語)"의 원고 자체는 여러 사정으로 인해 인터넷상에는 공개할 수 없습니다. 혹시 관심이 있다면 저의 X 계정으로 DM을 주세요. 사내 한정 공유나, 저의 원고를 베이스로 자신의 실패담으로 교체하여 사내용으로 공개하는 용도라면, 상담 후 전달해 드릴 수 있습니다.

추천 액션: 자신의 실패담을 하나 골라, "당시의 나는 무엇을 옳다고 생각했는가", "그 결과 상대나 팀에 어떤 일이 일어났는가", "지금이라면 어떻게 생각하는가"의 흐름으로 사내용 글을 써본다. 단순한 반성이 아니라, 같은 실패를 피하기 위한 지견(知見)으로서 전달한다.

지금까지 사내에서 발신하여 인지도를 만드는 이야기에 대해 써왔습니다.

다만, 발신만으로는 상대 팀의 상황까지 이해할 수는 없습니다. 실제로 지견(知見)을 받아들이게 하려면, 상대가 무엇 때문에 곤란해하고 있는지, 그 문제가 어떤 상황에서 일어나고 있는지를 알 필요가 있습니다.

나아가, 타 팀과 관계를 맺는 의미는 자신의 지견(知見)을 전달하는 것뿐만이 아닙니다.

타 팀에게도 그 팀의 현장에서 시도해 온 살아있는 지견(知見)이 있습니다. 자신의 팀에는 없는 고안(工夫)이 있습니다. 자신이 아직 보지 못했던 고민거리가 있습니다.

그래서 저는 발신을 통해 만들어진 작은 접점을 1대 1의 대화로 이어 나갔습니다.

그렇다고는 해도, 기다리기만 한다고 해서 누군가로부터 연락이 온다는 보장은 없습니다.

오히려 자신부터 1대 1로 이야기할 수 있는 기회를 만들어 나가는 것이 더 중요하다고 생각합니다.

가장 정석적인 방법은, 사내 Slack 게시물이나 사내 발표를 보고 자신에게 흥미를 느끼고 있을 것 같다고 생각되는 사람에게, 용기를 내어 1on1(원온원)으로 이야기할 수 있을지 타진해 보는 것입니다.

예를 들어, 저는 다음과 같은 DM을 보내곤 했습니다.

"지난번 발표를 들어주셔서 감사합니다.

○○님의 팀에 대해 관심이 있습니다.

어떤 방식으로 개발하고 계신지 여쭤보고 싶습니다.

괜찮으시다면, 한 번 30분 정도의 시간으로 1on1을 부탁드려도 될까요?"

포인트는 갑자기 "상담해 드릴게요"라고 말하지 않는 것입니다. 우선은 상대의 팀에 관심이 있다는 것, 배우고 싶다는 것을 전달합니다. 그래야만 이쪽이 일방적으로 무언가를 가르치러 가는 사람이 아니라, 상대로부터 배우고 싶어 하는 사람으로서 관계를 시작하기 쉬워집니다.

전혀 접점이 없는 상태에서 갑자기 부탁하는 것보다, 상대가 나의 발신을 보고 있는 상태인 편이 이야기를 시작하기 쉽습니다.

출근 이벤트에서 모르는 사람에게 말을 걸 때도 마찬가지입니다. 사내에서 발신하고 있으면, "그 게시물 봤습니다", "지난번 발표 재미있었습니다"라는 말을 들을 때가 있습니다. 그런 작은 계기가 있으면 초면이라도 대화가 활발하게 이어지기 쉽습니다.

우선은 온라인으로 1on1을 한다. 혹은 출근했을 때 오프라인으로 이야기한다. 그렇게 자신이 어떤 사람인지, 무엇에 문제의식을 가지고 있는지, 어떤 것들을 시도해 왔는지를 조금씩 알려줍니다.

상대의 고민을 듣고, 자신의 생각도 알린다. 그렇게 관계가 형성되면, 다음에는 팀 회의에 참여하도록 요청하기가 쉬워집니다.

추천 액션: 자신의 발신에 반응해 준 사람에게 우선 1on1을 요청해 본다. 상대의 고민이나 팀의 상황을 듣고, 자신이 무엇을 시도해 왔는지도 조금 이야기해 본다.

여기서 중요한 것은 1대 1 관계로 끝내지 않고, 거기서부터 팀의 활동에 참여하는 것입니다.

1on1을 통해 상대의 고민이나 팀의 상황을 조금 이해했다면, "괜찮으시다면 공부하고 싶으니, 팀의 회고(Retrospective)에 참여해도 될까요?"라고 상담해 봅니다.

저는 타 팀의 아침 회의(Morning Meeting), 모브 프로그래밍(Mob Programming), 회고(Retrospective) 등 몇 가지 활동에 참여했습니다.

그중에서도 특히 배움이 컸던 것은 회고(Retrospective)였습니다.

회고(Retrospective)에 참여하면 그 팀이 최근 어떤 것에 임하고 있는지, 무엇 때문에 곤란해하는지, 어떤 개선을 시도하고 있는지가 보입니다. 자신의 팀에는 없는 좋은 시도를 알 수 있는 경우도 있고, 회고(Retrospective)를 진행하는 방식 자체에서 배울 수 있는 것도 있습니다.

먼저 중요한 것은 조언하는 것이 아닙니다.

그 팀의 좋은 점을 찾아내어, 언어화(Verbalization)하여 전달하는 것입니다. 다음은 예시입니다.

"○○님은 감사의 내용을 굉장히 구체적으로 전달해주셔서 정말 멋집니다."

"회고(Retrospective) 중에 분위기를 띄우는 찬성 스탬프를 모두가 많이 사용해주셔서 정말 좋습니다."

1시간의 회의라면, 10건 정도는 찾아내고 싶습니다.

좋은 점을 언어화하여 전달하면, 그 팀에게도 자신들의 노력이 가진 가치를 재인식하는 계기가 됩니다. 이 또한 일방적으로 가르치는 사람이 아니라, 상대방으로부터 배우는 사람으로서 관계를 맺을 수 있습니다. 나아가 상대의 좋은 점을 자신의 언어로 설명하려고 노력함으로써, 자기 자신의 배움도 깊어집니다.

그리고 거기서 얻은 지견(Insight)은 자신 안에만 가두어 두지 않아도 된다고 생각합니다.

어느 팀의 회고에서 발견한 좋은 아이디어가 다른 팀의 고민을 해결하는 데 도움이 될 수 있습니다. 어떤 팀에서는 당연하게 하고 있는 일이 다른 팀에게는 새로운 힌트가 되기도 합니다.