개인에게 종속된 작업일수록 skill과 상성이 좋다

제목의 「개인에게 종속된 작업일수록 skill과 상성이 좋다」라는 말은 며칠 전 어디선가 본 문구입니다.

정리된 글은 아니었던 것 같아서 아마 X(구 Twitter)의 짧은 포스트였을 것이고, 어쩌면 뉘앙스도 조금 달랐을지도 모릅니다.

다만 그 말이 왠지 모르게 머릿속에 남아 있었고, 최근 며칠간 「과연 그렇다」라고 생각되는 부분도 있었기에 글로 정리해 둡니다.

개인에게 종속된 작업(属人化した作業)이란 특정 사람만이 할 수 있는 작업을 말합니다.

• 작업 절차가 명문화되어 있지 않아, 그 사람만이 작업 노하우를 가지고 있다
• 작업 중의 판단에 경험치적인 요소가 필요하다

이것이 종속화(属人化)가 발생하는 요인입니다.

「그런 건 문서화하면 되잖아」라고 생각할 수도 있겠지만, 「작업 내용」은 영구적인 문서로 만들 수 있을지 몰라도 「작업 절차」는 (시대의 흐름에 따라) 매번 바뀌기도 하므로, 문서화를 하더라도 금방 진부해지는 경우가 있어 어려운 점이 있습니다.

반대로 말하면 작업 절차를 명문화할 수 있는 작업은 종속화되지 않습니다.

예를 들어 저는 「프로그래밍 시험/연수에서 사용하는 각종 프로그래밍 언어용 docker image (Java, Ruby, NodeJS, Python, PHP, etc.etc...)를 일 년에 한 번 버전 업그레이드한다」라는 태스크를 맡고 있는데, 이 작업은 실질적으로 확인 작업이 9할입니다.

버전 업그레이드 작업 자체는 절차화가 가능하고, 확인 작업도 어느 정도 자동 테스트 (Automated Test)를 만들 수 있지만, 「Java 21을 Java 25로 올리면 어떤 문제가 발생할 수 있는가?」와 같은 것은 직접 해보지 않으면 알 수 없는 법입니다.

실제로 docker image 생성과 자동 테스트를 통과하는 것까지는 2일 만에 끝났지만, 오히려 그부터가 본론이라 확인 작업은 2주가 경과한 현재까지도 아직 끝나지 않았습니다. (이 작업만 하고 있었던 것은 아닙니다만)

매년 확인해야 할 포인트를 나열하기도 하지만, 그것만 클리어한다고 해서 OK가 되는 것은 아니기에 문서화 접근법을 통한 종속화 해소는 거의 불가능하다고 생각합니다.

본론과는 약간 벗어나지만, 종속화가 반드시 악은 아니라는 점에 대해서도 일단 써 두겠습니다.

왜냐하면 조직의 규모나 성장 과정에서의 포지션에 따라 달라지기 때문에 일률적으로 말할 수 없기 때문입니다.

예를 들어 스타트업 기업에서는 종속화가 오히려 정의입니다.

적은 인원으로 어떻게든 성과를 내야 하므로, 잘하는 사람이 잘하는 것을 맡아 오로지 업무 사이클을 올리는 것은 이치에 맞습니다.

하지만 어느 정도 조직이 성장하면 「그 사람밖에 할 수 없는」 업무의 존재는 반대로 리스크가 됩니다. (SPOF 혹은 Bus factor라고 불리는 것입니다.)

어떤 조직이든 초기에는 종속화된 작업투성이겠지만, 성장에 따라 점진적으로 해소해 나가야 한다는 뜻입니다.

자, 앞서 언급한 docker image 검증 작업은 당연하게도 Claude Code에게 시키고 있습니다.

(진짜 편리해졌다. 스스로 끊임없이 검증용 일회성 스크립트를 작성하던 시대로는 이제 돌아갈 수 없다. 고마워, AI.)

원래는 1년에 한 번밖에 발생하지 않는 작업이었기에 skill로 만들 필요성은 낮다고 생각하여 계속 대화 형식으로 진행해 왔는데, 하는 도중에 깨달았습니다.

skill.md는 자세히 생각해보면 작업 내용의 명문화와 작업 절차의 지시 그 자체입니다.

즉, skill을 만드는 것(정확히는 AI 스스로 만들게 하는 것)은, 위에서 어렵다고 쓴 종속화 작업의 문서화 그 자체인 것입니다.

하지만 단순한 문서화와는 결정적으로 다른 점이 몇 가지 있습니다.

• 문서는 문서일 뿐이지만, skill은 그것에 따라 실제로 작업을 수행해 준다
• 절차가 진부해져도 AI는 자신보다 똑똑하기 때문에, 그것을 스스로 알아차려 준다
• 작성한 것을 읽어주는 사람이 있다 (사람은 아니지만)

등등.

이 외에도 장점은 여러 가지가 있겠지만, 사실 여기서 강조하고 싶은 것은 마지막 하나입니다.

위에서 종속화 해소를 위한 대책으로서 문서화는 유효하지 않다는 이야기를 길게 늘어놓았지만, 솔직히 말하자면 그저 귀찮다는 것, 딱 그뿐입니다.

왜 이 작업을 이토록 귀찮게 느끼느냐 하면,

• 눈앞에 있는 자신의 태스크 해결에는 기여하지 않는다
• 작성해 봤자 (필요에 부딪히기 전까지는) 아무도 읽지 않을 것이라 생각한다
• 읽히는 단계에서는 진부해져 있을 가능성이 높다

라고 생각하기 때문입니다.

말을 바꿔 표현하자면 이 작업은 비용 대비 성과가 압도적으로 맞지 않는다고 느껴지는 것입니다.

조직 입장에서 SPOF (Single Point of Failure, 단일 장애점)를 해소하는 것은 사활이 걸린 문제이기에, 자주 문서화해 달라는 요청을 받으며 그 필요성도 이해하고 있습니다. 하지만 동기 부여도, 우선순위도 올라가지 않아 계속해서 미뤄왔습니다.

하지만 이것을 skill로 만든다면 이야기는 달라집니다.

문서를 쓰는 것은 고통스러울지라도, AI와의 협업을 통해 skill을 만들어가는 것은 눈앞의 태스크 (Task)를 수행하는 작업이기도 하기에 그리 괴롭지 않습니다.

skill화는 위에서 언급한 문제점들을 모두 완벽하게 해결해 줍니다.

훌륭합니다.

십중팔구 내년에도 이 작업을 하고 있는 것은 자신일 것이라고 생각하지만, 그때도 도움이 될 것이며, 설령 자신이 없어져서 경험이 적은 멤버가 인수인계를 받게 된다 하더라도 skill은 단순한 문서보다 압도적으로 도움이 될 것입니다.

엔지니어는 예외 없이 모두가 문서 작성을 싫어한다고 생각하지만, skill을 만드는 것은 프로그래밍과 통하는 즐거움이 있기 때문에, 이 방침이라면 지금까지 전혀 진척되지 않았던 개인 종속적 태스크 (Task)의 문서화가 진행될지도 모릅니다.

skill에 대해 해설한 기사는 산더미처럼 많지만, 그중에서 skill을 작성하는 동기로 꼽히는 것은

• 매번 같은 작업을 하는 것이 귀찮다
• 시간 단축

이라는 내용이 많다고 생각합니다.

이것들은 어느 쪽인가 하면 개인 업무의 효율화에 초점을 맞춘 이야기입니다.

프로젝트에서 skill을 공유하는 경우도 있지만, 그것들도 범위를 조금 넓혔을 뿐 개인 작업 효율화의 연장선상에 불과합니다. (그렇게 생각했지만, 다시 생각해보면 시니어 (Senior)가 skill을 작성하고 주니어 (Junior)가 그것을 사용하여 구현하는 패턴은 개인 종속성 해소의 아종이네요. 다만 그 경우에도 '개인 종속성'이라는 키워드는 의식되지 않을 것이라고 생각합니다.)

하지만 '개인 종속성'이라는 관점을 가지고 skill을 사용하기 시작한다면, 이것은 '개인'뿐만 아니라 '조직'의 업무 전체를 크게 개선해 나갈 가능성이 있다고 생각합니다.

여기서 다룬 것은 상당히 극단적인 예였지만, 회사라는 조직 안에서는 누구나 약간의 자신만의 개인 종속적 태스크를 가지고 있을 것이므로, 그것을 skill화하는 것은 개인에게도 조직에게도 큰 가치가 있는 일이라는 점이 더 의식되어도 좋다고 느낍니다.

또한 AI를 대화형으로는 사용하고 있지만 skill 같은 것은 잘 모르겠다고 생각하는 비엔지니어 분들에게도, skill을 멀리하지 않고 사용하기 시작하는 계기가 되어주면 좋겠습니다.