협업 병목을 줄이기 위한 자동화 실험 기록

들어가며

재직 중인 회사에서 새로운 서비스를 맡게 된지도 어느덧 1년 반이 지났다. 처음에는 새로 합을 맞추게 된 동료들과 익숙하지 않은 도메인에 적응하며 주어진 요구사항을 최선의 방법으로 구현해내는걸 주요 과제로 삼았다. 그렇게 시간이 흐르며 동료들과 도메인에 익숙해질 무렵, 자연스럽게 새로운 갈증과 고민이 생겼다.

단순히 주어진 요구사항을 구현하는 것을 넘어 +α를 만들어내는 사람이 되고싶었다. +α를 만들어내는 사람은 어떤 사람일까? 내가 만들 수 있는 +α는 무엇일까? 혼자서만 고민하다보니 점점 더 거창하게 느껴지고 답이 잘 내려지지 않아 외부에 적극적으로 도움을 구했다. 저분은 +α를 만들어 내시는 것 같다란 느낌이 드는 분들께 링크드인과 소속된 커뮤니티를 활용해 커피챗을 요청했고, 감사하게도 모든 분들이 기꺼이 수락해주셔서 이야기를 나눌 수 있었다.

다양한 관점에서 이루어진 대화 끝에 내린 결론은 마냥 거창하게 생각하지 말고, 회사에서 업무를 하며 느꼈던 문제나 불편함을 사소한 것부터 직접 개선해보기였다.

그 이후 업무를 할 때 자연스레 촉수를 곤두세우게 됐고, 협업 과정의 반복적인 수작업, 불필요한 커뮤니케이션 비용 같은 것들이 눈에 들어오기 시작했다. 이런 불편함을 기술적으로 해소할 수 있다면 조직에 기능을 만들어내는 것과는 결이 다른 임팩트를 줄 수 있고, 결과적으로 내가 고민하던 +α를 만들어낼 수 있지 않을까?란 생각에 작은 실험들을 시작했다. 아래에는 그렇게 진행했던 두가지 실험에 대해 적어보려 한다.

Slack 워크플로로 누구도 복붙하지 않는 채널 만들기

관찰, 그리고 문제 정의하기

우연히 비즈니스팀과 디자인팀이 소속된 홈페이지 작업 관련 Slack 채널을 보게 되었는데 작업 관련 내용이 특정 양식을 복사/붙여넣기 하는 형태로 공유되고 있었다.

매번 특정 양식을 찾아 복사해야 하고, 수동으로 작성하는 과정에서 오타나 포맷 오류가 자주 발생하고 있었다. 또 다양한 유형의 작업이 유사한 포맷으로 공유되다보니 현황을 한눈에 파악하기 어려워보였다.

채널 활동 빈도가 높은 동료들에게 파악한 문제점에 대해 이야기 해보았고, 비슷한 불편함을 느끼고 있다는 걸 확인했다. 관찰을 통해 문제점을 찾아냈으니 한 번 개선해보자는 마음이 들었다.

패턴 파악하기

문제를 해결하기 위해 우선 채널을 관찰하며 업무 흐름과 패턴을 파악해봤다.

채널에 공유되는 현황은 크게 작업 현황 알림과 배포 알림으로 나뉘어졌고, 각 현황마다의 업무 흐름은 위와 같이 이루어지고 있었다. 패턴을 파악하니 문제가 더 명확해졌다.

• 공유되어야 하는 정보는 각각 작업 시작, 배포 예정 메세지에 모두 작성되었으나 작업 완료/배포 완료 시점에도 공유하기위해 이전 단계에 작성했던 메세지를 복사해 수정해야했다.
• 배포 예정 알림 후 관련 실무진의 컨펌을 emoji를 통해 확인하는 과정이 번거로워 보였다.

자동화 도구 만들기

처음엔 단순하게 홈페이지 작업 플랫폼을 Slack과 연동해 로그인/로그아웃, 배포될 때 자동으로 알림이 오도록 하게 할까 생각했지만 결과적으로 Slack 워크플로로 결정했다.

공유되는 정보 중엔 배포 가능 여부 등 홈페이지 작업 플랫폼에서 알 수 없는 정보가 포함되어있었고, 배포 예정 알림은 홈페이지 작업 플랫폼과 별개의 프로세스이기에 단순히 알림을 주는 것만으로는 현재의 업무 흐름을 온전히 대체할 수 없다는 생각이 들었다. 또 워크플로는 노코드 툴이니 비개발직군인 디자인팀, 마케팅팀이 추후 필요에 따라 유지보수할 수 있다는 장점도 있었다.

앞서 정리한 두가지 작업 패턴에 따라 홈페이지 작업 알리미와 홈페이지 배포 알리미 워크플로를 만들었다.

홈페이지 작업 알리미

먼저 홈페이지 작업 알리미 워크플로에 대해 알아보자면, 실무진 분들께 확인해보니 공유되는 정보 중 가장 중요한 정보가 ‘전체 퍼블리시 가능 여부’였고, 여기에서 영감을 받아 신호등 컨셉으로 만들었다 🚥

1. 작업 시작 공유 : 워크플로를 호출해 form에 필수로 공유되어야 하는 사항을 작성한다. 작성이 끝나면 정해진 양식에 맞게 포맷팅된 ‘작업 시작’ 메세지가 전송된다.
2. 작업 완료 공유 : 작업 시작 메세지의 작업 완료했어요 버튼을 클릭해 참고사항을 입력한다. 간혹 작업을 하다보면 추가로 공유할 사항이 생길 수 있다는 실무진 분들의 의견을 참고해 이 단계를 추가했다.참고사항을 입력하면 기존의 작업 시작 메세지 정보와 참고사항을 포함한 작업 완료 메세지가 전송된다.

홈페이지 배포 알리미

다음으로 홈페이지 배포 알리미에 대해 알아보자.

1. 배포 예정 사항 공유 : 워크플로를 호출해 form에 필수로 공유되어야 하는 사항을 작성한다. 작성이 끝나면 정해진 양식에 맞게 포맷팅된 ‘배포 예정’ 메세지가 전송된다. (여기까진 작업 알리미와 거의 동일)
2. 관련 실무진 컨펌 : 관련 실무진은 배포 예정사항 확인 후 배포 예정 메세지의 확인했어요 버튼을 클릭한다. 버튼 클릭시 배포 예정 메세지의 스레드에 버튼을 클릭한 유저명과 함께 확인했다는 댓글이 달린다.
3. 컨펌 후 배포 완료 : 스레드 댓글에 달린 배포 완료했어요 버튼을 클릭한다. (워크플로를 최초 호출한 배포 예정 작업자가 클릭했을 때만 동작) 배포 예정 메세지의 정보를 기반으로 한 배포 완료 메세지가 자동 전송된다.

배포 예정 메세지를 작성한 뒤 버튼을 트리거로 1) 스레드에 확인 완료 댓글을 달고 2) 배포 완료 메세지도 전송해야 했다. 워크플로의 다음 단계로 이동시키는 버튼은 한 단계당 한개씩만 지원해서 최대한 어색하지 않은 흐름으로 단계를 구성하려 노력했다.

두 워크플로에서 가장 신경쓴 점은 기존의 업무 흐름을 동일하게 구현하되 그 내부의 불필요한 반복을 줄이는 것. 또 러닝커브를 최대한 낮추기 위해 직관적으로 다음 동작을 보여주는 버튼 트리거를 애용했다.

결과

워크플로 배포 및 안내 후, 감사하게도 동료분들이 열화와 같은 성원과 함께 적극적으로 사용해주셔서 홈페이지 작업 채널은 워크플로만으로 원활히 돌아가는 채널이 되었다! 이전과 같은 반복적인 복사-붙여넣기 메세지는 아예 사라졌다.

주기적으로 채널 모니터링도 하며 자잘한 수정을 하고있다. 나만의 토이프로젝트를 운영하는 느낌이랄까,,

실무진분들께 워크플로 도입 전후에 대해서도 자주 의견을 여쭤보는데, 특정 양식을 찾아다니고 복붙하는 과정이 사라지다보니 업무 피로도가 줄고, 메세지 오타나 누락이 줄어 명시적으로 업무 흐름을 파악할 수 있다는 피드백을 받았다. 또 동료분들의 열화와 같은 성원에 자기효능감을 느낄 수 있었다.🧚‍♀️

워크플로는 노코드 기반이기에 기술적인 난이도는 높지 않았지만, 관찰 → 분석 → 자동화 → 개선이라는 구조적인 문제 해결 과정을 거쳤다는 점에서 개인적으로 의미가 컸다.

React인지 JSP인지 셀프 확인하는 크롬 익스텐션 만들기

관찰, 그리고 문제 정의하기

현재 담당하고 있는 서비스는 대부분이 JSP로 구성되어 있고 점진적으로 React로 마이그레이션 해나가고 있다. 모든 서비스를 한번에 옮기기엔 서비스 규모가 너무 크기 때문에 달리는 열차의 바퀴를 교체하듯이.. strangler fig 패턴을 기반으로 기능 고도화를 곁들이며 모달, 특정 섹션 단위로 옮겨나가고 있다.

서비스 규모가 크고 마이그레이션 범위가 모호하다 보니 기획자, 디자이너, QA엔지니어가 해당 영역의 기술 스택을 파악하는 데 어려움을 겪었다. React와 JSP를 구분할 수 있는 공식적인 문서나 가이드는 존재하지 않았고 실제 기획자는 매번 프론트엔드 개발자에게 질문을 해야 했다.

“이 페이지는 JSP인 것 같은데, 모달은 React인가요?”

“이 섹션은 React처럼 보이는데 맞나요?”

작은 질문이지만 반복되면서 나도, 기획자도 피로도가 쌓이고 있었다.

패턴 파악하기

각 페이지별로 생길 수 있는 경우의 수를 나눠 카테고리를 나눠봤다. 크게 4가지의 유형으로 정리할 수 있었다.

• JSP Page : JSP로만 개발된 페이지
• React Page : React로만 개발된 페이지
• React Modal : JSP Page에 React Modal을 띄운 형태
• React Section: JSP Page의 일부분이 React로 구성된 형태

여기서 JSP Page와 React Page는 URL을 통해 구분할 수 있었다.

JSP와 React가 공존할 경우의 세부 유형은 JSP Page 내부의 iframe src를 분석해 확인할 수 있었다.

React로 개발된 Modal은 사내 디자인 시스템 요소를 활용하는데, 이때 특정 class가 포함되기에 iframe의 src에 React Page의 URL이 포함되어 있다면 classList.contains()를 통해 Modal인지 Section인지 확인할 수 있었다.

자동화 도구 만들기

비개발직군이 기술스택을 파악하려면 어떤 방법이 가장 편할까? 고민해보니 직관적인 시각화가 필요하다고 느꼈다. 그래서 다음과 같은 방식의 크롬 익스텐션을 직접 제작했다.

• 페이지 로딩 시 JSP Page, React Page, React Modal, React Section을 다른 색상으로 하이라이팅
• 각 요소 위에 해당 기술 스택 정보를 보여주는 라벨 표시

MVP 형태로 제작하여 테스트했고, 실제로 스쿼드 기획자분께 선보였더니 반응은 기대 이상이었다. 좀더 다듬어 전사에도 공유했다.

결과

이 결과를 가장 실감하는 사람 중 한명은 바로 나일텐데, 익스텐션을 배포한 이후 스쿼드 기획자님께 이 부분은 React인가요? 라는 질문을 받은 적이 없다. 이제 더 이상 질문하지 않아도 혼자서 익스텐션을 통해 페이지별 기술 스택을 정확히 파악할 수 있게 되었기 때문. 작은 확장 프로그램이었지만, 실사용자인 내 업무 스트레스를 줄여준😇 사례였다.

느낀 점 – 도구보다 중요한 것은 문제 해결 능력

사실 이 글의 초안은 예전에 작성해두었지만, 포스팅을 하기까지 꽤 오랜 시간 망설였다. 기술적으로 난이도가 높지 않은 내용이다보니 기록하는게 의미가 있을까?라는 생각이 들었기 때문. (각종 회고글은 잘만 포스팅하면서..?😶‍🌫️)

이 고민은 글의 초점을 ‘기술’보다 ‘문제 해결’에 두니 자연스레 해결됐다. 두 실험을 통해 도구 자체보다 문제를 인식하고 해결해내는 과정이 중요하다는 걸 깨달았다. 워크플로든, 크롬 익스텐션이든, 핵심은 사용된 기술의 종류보단 문제를 해결하는 방식에 있었다.

그리고 그 문제는 대부분 관찰에서 시작됐다. 불편해 보이는 점을 그냥 넘기지 않고 “왜 이렇게 하고 있을까?”, “더 나은 방법은 없을까?” 고민하며 문제를 정의하고, 패턴을 파악하다보면 그 안에서 개선점을 찾아낼 수 있었다.

요즘 개발 환경은 빠르게 변화하고 있다. 코드를 쓰는 일조차 AI가 어느 정도 대체 가능한, 이른바 ‘딸깍의 시대’가 오고 있다. 그럴 수록 중요해지는 것은 ‘무엇을’ 구현할지, ‘왜’ 구현해야 하는지를 판단하는 능력이라고 생각한다.

들어가며에서 언급한 +α를 만들어내는 사람은 주어진 과제 외에도 문제를 주체적으로 정의하고, 이를 기술적으로 개선하고 해결해나가는 사람이 아닐까? 여기서 중요한 단어는 주체적인 것 같다.

이 실험 기록을 시작으로 앞으로도 기술로 더 나은 협업 환경을 만드는 사람으로 성장해나가고 싶다.