승이의 기술블로그
article thumbnail

이번 3차 릴리즈를 하게 되면서, 우리 팀은 어느 정도 '조직'의 형태를 갖추어 가게 됐다. 기존에는 나를 제외하면 백엔드 2명, 프론트엔드 2명인 팀에서 기획 1명, 디자인 1명, 백엔드 2명, 프론트엔드 3명으로 팀 구성이 바뀌게 되었다. 기존에는 개발자들끼리의 조직이었기에 그야말로 '우리끼리'의 단어로 이야기를 해도 소통을 원활하게 할 수 있었고 특별히 신경써야 하는 부분들이 없었다. 그러나 새로운 파트의 유입으로 인해 많은 걱정이 앞서게 됐던게 사실이다. 전문적인 지식이나 공부해본 경험이 없는 기획 파트나 디자인 파트의 태스크 역시도 고려해야 했고 새로운 팀원들의 융화에도 신경을 써야 했다. 또한, 이전보다 커진 집단을 체계적으로 관리하는 방법에 대해서도 궁리가 필요했다. 내가 한 노력에는 다음과 같은 것들이 있다.

1. 이벤트 스토밍 진행

다른 백엔드 파트 멤버가 이벤트 스토밍을 진행할 것을 제안했다. 그 이유는, 기존 회의에서 하나의 상황에 대해 다양한 도메인 용어를 사용하기도 했고, (ex. 타임라인을 이르는 말에 레코드, 중계, 기록 등을 사용) 새로운 구성원들이 유입되었기에 도메인 지식을 자연스럽게 습득하게 하기 위함도 있었다.

 

그 결과, 새로운 구성원들 역시도 바로 다음 회의부터 업무에 대한 논의가 가능할 정도로 도메인에 대한 깊은 이해가 가능해졌다.

2. 구글폼 만들어두기

이전까지는 개발자들끼리만 프로젝트를 진행해왔었기 때문에 회의 시간 내에 개발 용어들을 사용하는 것에 무리가 없었다. 그러나, 이벤트 스토밍 진행 과정에서 이가 다른 파트에게는 우리 집단에 녹아드는 데에 분명히 큰 장애물로 작용할 것이라는 것을 깨닫게 되었다. 따라서 위와 같이 구글폼을 제작해 두어, 비개발 파트들이 가졌던 의문이나 궁금증들에 대해서  해결할 수 있도록 했다. 구글폼은 매번 회의 시작 전에 확인하여, 매주 회의 시간 내에 해당 부분에 대한 대답을 하고 난 뒤에 회의를 진행했다.

3. 출석체크 봇 제안

아무래도 새로운 팀원과 일하게 되면 서로 합을 맞춰가는 데에 갈등이 생길 수밖에 없는 것 같다. 한 팀원이 함께 일하는 다른 팀원의 메신저 확인 빈도에 대해 불만을 제기했다. 나에게 이러한 문제에 대해 털어놓았고, 나는 이 문제에 대해 깊게 생각해보기 시작했다. 최대한 객관적으로 감정을 제하여 문제를 해결하기 위해서 노력했던 것 같다.

정말 개인만의 문제일까?

우선, 우리는 메신저로 슬랙을 사용하고 있었다. 슬랙을 사용하면서 나 역시도 메시지 확인을 놓칠 때가 있었는데, 알림이 종종 누락되기 때문이었다. 이에 대한 문제는 문제가 발생하기 이전 회의에서도 언급한 적이 있었다. 즉, 모두가 슬랙 알림에 대해 불만과 불편함이 있었다는 것이었고 나 역시도 이를 인지하고 있었다. 따로 직접 신경을 써서 슬랙에 들어가야겠다는 생각을 하지 않는 이상 다른 멤버들 역시도 알림을 놓칠 가능성이 충분하다는 생각이 들었다.

또한 슬랙을 자주 확인하지 못한 멤버는 새로 영입된 인원이었기에 아직 슬랙을 확인해야 하는 것에 대해 인식이 없을 뿐더러, 알림이 제대로 오지 않는다면 자주 들여다볼 생각이 들지 않는 것이 어찌 보면 당연할 수도 있다는 생각도 들었다.

유쾌하게 풀어볼까?

메신저 확인에 대해 신경을 곤두세워야 하고 게다가 알림까지 제대로 오지 않아서 직접 들어가서 확인해야 한다면 장기적으로 우리 팀에게 스트레스가 될 것이라고 생각했다. 따라서 자발적으로 메신저를 확인하도록 하되, 스트레스가 가지 않는 방향으로 슬랙을 멤버들의 인식 속에 자리잡을 수 있도록 조금은 유쾌하게 풀어보고 싶다는 생각을 하게 됐다.

처음에는 직접 슬랙봇을 만들까 하는 생각이 들었다. ChatGPT 를 이용해 슬랙 내부의 채널에 매일 멤버들의 생일을 토대로 '오늘의 운세'를 보내주고, 이모지를 남기면 출석체크가 되는 방식으로 구상을 했었다. 그러나, 오히려 부가적인 컨텐츠를 넣는 것이 피로도를 올릴 수 있겠다는 다른 팀원의 피드백을 받았다.

그래서 이번에는 단순히 출석체크봇을 만들면 어떨까 싶었다. 이에 대해 팀원들에게 이야기해보았고, 다들 좋은 아이디어라는 의견이 대부분이었다. 또한 기존 우리 슬랙 채널에 존재하던 슬랙봇을 간단히 손보면 출석체크 봇으로 만들 수 있을 것 같다며 자신이 만들어보겠다고 해주어 출석체크봇을 도입하게 됐다.

 

결과는 대성공이었다! 

매일 아침 9시에 팀원들이 출석체크를 하게 되니, 최대 24시간으로 메신저 확인 공백 기간을 축소시킬 수 있었다. 또한, 출석체크 하지 않은 팀원에 대해 이모지로 장난스럽게 눈치도 주며 스트레스를 받지 않고 슬랙을 확인해야 한다는 인식을 형성하는 데에 성공했다.

4. 팀의 성장 방향에 대해 고민하기

앞선 메신저 확인 문제에 이어서, 프로젝트가 길어지다 보니 단순히 출석체크로만은 해결할 수 없는 '늘어짐'이 점차 눈에 보이기 시작했다.이 역시도 기간이 늘어지게 되면 얼마든지 생길 수 있는 문제라는 것을 알고 있다. 그러나 이번 릴리즈 시점이 우리 팀에 치명적이라고 생각을 하고 있었기에 이 문제에 대해 예민하게 받아들일 수밖에 없었다.

앞선 릴리즈에서 매니저 서버의 API 가 모두 완성되었음에도, 프론트와의 스케줄 조정 실패로 인해서 매니저 서버의 릴리즈를 할 수 없었다. 이가 특정 팀원들의 사기를 저하할 것을 알고 있었고, 같은 학생의 입장으로서 완성된 API 가 쓰이지 않는다는 것은 얼마나 큰 상실감을 줄지 완전히 이해하고 있었기 때문이다. 그렇기에 이번 릴리즈만큼은 완벽하게 해내고 싶다는 생각이 들었다.

그 '늘어짐'이 보이는 순간부터 이것저것 찾아보기 시작했다. 팀장은 처음이었고, 게다가 한순간에 커져버린 팀을 이끌어가는 노하우가 나에게는 없었기 때문이다. 당시 눈에 띄었던 문제점들은 다음과 같았다.

 

1. 팀원들이 미리 고지하지 않았던 개인 일정을 이유로 회의에 불참하기 시작

2. 마찬가지로 미리 고지하지 않았던 개인 일정을 이유로 태스크의 완료에 딜레이가 생기기 시작

 

결론적으로 내가 내린 문제점은, 프로젝트의 초입과는 다르게 기간이 길어지게 되면 각자의 영역에서 갖는 책임감이 줄어드는 것이었다. 따라서 이에 대해 팀원들에게 다시 한번 언급할 필요가 있는 시점이라는 생각을 하게 됐다.

 

https://github.com/leehosung/awesome-devteam?tab=readme-ov-file

 

GitHub - leehosung/awesome-devteam: 좋은 개발팀을 만드는데 도움이 되는 자료

좋은 개발팀을 만드는데 도움이 되는 자료 . Contribute to leehosung/awesome-devteam development by creating an account on GitHub.

github.com

 

나는 위의 레포지토리를 참고하여 '조직' 과 관련된 글을 읽기 시작했다. 그 중에서도, 가장 우리의 상황에 적합하다고 생각했던 것은 다음의 자료이다.

 

https://www.slideshare.net/HeejongAhn/ss-73274788

 

더 나은 팀을 위하여

더 나은 팀을 위하여 - Download as a PDF or view online for free

www.slideshare.net

 

캡처본 게시에 대한 원작자분의 허가를 받았습니다.

해당 자료는 기업에 대한 내용이기에 나의 상황과는 일정 부분 차이가 있지만, 나에게 와닿은 부분들은 다음과 같았다.

 

  • 그럴 수밖에 없는 사정이 있었을 수 있다.
  • 같은 말을 표현만 고쳐서 함으로서 듣는 사람이 감정이 덜 상할 수 있다면, 안 그럴 이유가 없다.
  • 비판의 목적은 개선이지, 일침이 아니다.
  • 행동 지령보다 의도를 공유 해 나갈 때 더 나은 결과를 이뤄낼 수 있다.

현재 상황에 대해 자세히 언급하며 특정 누군가를 손가락질 하거나, 민망하게 만들기 보다는 지금 내가 팀장으로서 느끼고 있는 문제점들에 대해 공감을 얻고 나의 말에 대한 의도를 전달하는 것이 우선시되어야 한다는 생각을 했다. 그래서 결과적으로 다음과 같은 메시지를 보내게 됐다.

이를 통해 팀원들이 이전보다 프로젝트 상황에 대해 집중하는 모습을 볼 수 있게 됐고, 성공적으로 릴리즈를 마칠 수 있게 됐다.

피드백

프로젝트의 릴리즈가 한 차례 끝나고, 팀원들에게 각자 구글폼을 이용해 피드백을 받을 것을 제안했다.

https://github.com/asbubam/resume

 

GitHub - asbubam/resume: Resume of Seungwoo Lee

Resume of Seungwoo Lee. Contribute to asbubam/resume development by creating an account on GitHub.

github.com

깃허브에서 위와 같이 이력서에 동료들의 평가가 들어가는 것이 매력적이라고 생각했기 때문이다. 또한, 처음으로 맡은 팀장으로서의 역량에 대해 피드백을 받고 싶기도 했다.

 

1. 팀장으로서의 나의 점수, 플러스 요인과 마이너스 요인

플러스 요인

1) 서비스나 팀의 분위기를 잘 이해하고, 읽고, 이끌어나가려고 한 점 ex. 지체되는 루즈한 기간, 메신저의 역할 개선, 각자의 역할의 부담감 파악 등

2) 각 멤버와 업무에 대한 세심한 이해와 관리 ex. 기획, 디자인에서 놓치고 있는 업무 파악과 전달 / 콘텐츠나 홍보적 개선점 고려

3) 커뮤니케이션 스킬 


이벤트 스토밍때부터 봤던 거 같은데 하는 행동들이 대부분 팀에게 도움 되는 방향이었다고 생각함. 예를 들어 전체적인 일정을 관리하는 부분이나 출석 체크같이 어떠한 목표를 위해 여러 기능을 도입하는 부분 등


 

부드럽지만 강한 리더십을 가진 사람으로서 지금까지 만났던 팀장/리더 중 가장 따뜻하고 어른이라고 느꼈음


 

- 항상 회의를 주도하며 다양한 의견을 내는 점

- 백엔드 업무도 잘 해주었고 기획파트를 도와 기획 및 외부에 신경써야 할 부분도 신경써주어서 팀원들이 내부 일에 집중할 수 있었음

- 팀장으로서 팀원들 끌고가기 많이 답답했을텐데 싫은 소리 안하고 팀장 역할을 제대로 해주었다고 생각합니다.


 

팀을 이끌어가기 위해서 많은 노력을 하였음. 인원 충당 같은 것부터 슬랙 출첵 도입까지 많은 고민이 보였다. 그리고 백엔드 개발하면서 기획적인 부분도 많이 하여서 팀장으로서 임무를 완수함


 

고민을 많이 했다는 점에서 큰 점수를 주고 싶습니다. 사람들이 슬랙을 잘 보지 않거나, 업무 효율이 점점 떨어지고 있을 때, 어떻게 하면 이 상황을 타개할 수 있을지 고민하는 과정을 지켜보면서 문제 해결 능력이나 문제 인식 능력을 엿볼 수 있었습니다.

 

마이너스 요인

어쩔 수 없지만 팀장의 한국 부재가 팀 결속력에 영향을 받아서.. 그것 빼곤 없어용


아쉬운 부분은 중간에 영국으로 떠나버리는 바람에 주도해서 모임을 갖는다던가 팀의 단합을 위한 일을 못했다는 점이에요. 매주 비대면으로 회의만 하다 보니 새로 들어온 팀원들이나 다른 파트 팀원들과의 결속력을 강화하는 데에 어려움이 있었지 않은가 싶습니당


이번 릴리즈 관련하여 팀 전체적 시간관리

 2. 소프트스킬적인 측면에서의 장점과 단점

장점

커뮤니케이션 스킬, 리더십, 책임감, 팀워크, 문제 해결 능력(상황 대처)


 

팀원에게 테스크 분배를 하거나 등등 여러 상황에서 기분 나쁘지 않게 말 전달하는게 장점인 거 같다.


 

유연성

- 변하는 상황에 따른 대처가 빠름 책임감

- 시차 안 맞을 텐데도 항상 프로젝트에 신경 쓰고 새벽까지도 트래킹함

 

협업능력

- 팀으로서 항상 북돋아주고 회의도 매끄럽게 진행함

 

꼼꼼함

- 팀원들이 어디 놓친 건 없는지 계속 확인하고 배려함


 

- 팀을 어떻게 관리해야 좋을지 고민하는 모습이 계속 보여서 리더십이 있는 것 같다.

- 백엔드 뿐 아니라 다른 방면의 일도 계속 신경 쓰면서 멀티 태스킹에 뛰어난다고 생각한다.

- 이해 안되는 부분을 계속 물고 늘어지는 모습에 끈기 있다고 느껴졌다.


 

책임 의식도 당연 좋고 본인의 의견을 정확하게 피력하는 것이 장점이라고 생각했음


 

앞서 이야기 한 점이긴 하지만, 책임감이나 문제 인식 능력이 큰 장점이라고 생각합니다. 단순히 팀원들이 슬랙을 잘 확인하지 않는다는 것에서 출발하여 현재 업무 방식의 문제점으로 이어지는 사고 과정, 그리고 그것을 어떻게 해결해야 하는지 결론내리는 과정이 굉장히 창의적이었다고 생각합니다. 그것을 실제로 해결했던, 그렇지 않던 문제를 인식하고 다양한 관점으로 분석한 뒤 결론을 내리는 그 능력에 대해 칭찬하고 싶어요.

단점

승희 단독적인 문제는 아니지만 백-프론트-기획-디자인 간 업무 체계성을 같이 더 잡아가야한다는 생각이 들었음!


상황을 좋게만 끌어가려 한다거나 최대한 참아보려 한다는 것 정도 있을 것 같아요. 사실 말만 들으면 하나도 부족할 곳 없고 오히려 장점일 수 있는 이야기들이지만, 팀장이라는 직책으로 인해 조금 다르게 들릴 수 있을 것 같아요.

팀장은 팀의 최대 효율을 뽑아내기 위해 가장 솔선수범해야 하는 자리라서 팀 전체의 업무 효율성을 해치거나 일정을 딜레이 시키는 거나 분위기를 해치는 등의 상황을 마주했을 때 잘 처리할 수 있는 능력이 필요한 것 같아요. 참 어려운 일이라는 것을 잘 알고 있고, 나름대로 신경쓰며 노력했다는 것을 아주아주 잘 알지만, 이 부분에 대해서 조금 더 연습을 한다면 더욱 믿음직스럽고 리더쉽 있는 팀장이 될 수 있을 것 같아요.


리소스 낭비는 커뮤니케이션 부족에서 일어나게 되고, 직설적으로 요구사항을 전달하는 게 옳다고 느껴진다. 조금 더 날카로운 사람이 됐으면 한다.

피드백에 대한 나의 생각

주로 나의 장점으로 꼽히는 부분들은 책임감, 적극성, 책임감 등이 있을 것 같다. 특히 출석체크의 경우, 상황을 다양한 시각에서 파악하고 접근하고자 노력했는데 그런 점을 알아봐준 것 같아서 뿌듯함이 있었다.

그러나 더 중요한 것은 단점이라고 생각한다. 내가 지적받은 문제점은 크게 세개이다.

 

1. 일정 관리의 실패

2. 해외 체류로 인한 결속력의 부족

3. 해야 할 말을 잘 전달하는 것

1. 일정관리의 실패

이에 대해서는 정말 나의 책임이 크다고 볼 수 있을 것 같다. 물론, 나의 귀책이 100% 가 아님을 나도 잘 알고 있다. 팀원들의 취업, 앞서 '팀의 성장 방향에 대해서 고민하기'에 대해서도 언급했듯 전체적으로 딜레이되는 상황들이 있었다. 그럼에도 팀장으로서의 입지에서 전체적인 흐름을 확인하고 데드라인이 제대로 지켜지지 않았을 때 집어내야 하는 것은 분명히 나의 몫이다.

초반에는 마냥 시간이 많이 남아있다는 생각이 컸고, 팀원들에게 부담을 주고 싶지 않다는 생각도 있었던 것 같다. 무엇보다 나 역시도 타임라인이 명확히 잡히지 않았다. 프론트가 작업이 들어가려면, API 가 나와야 하고, API 가 나오려면 기획이 확정이 되어야 하는데, 그렇다고 기획만으로 백엔드가 API 를 짜기에는 화면이 안나와 있어 무리인 것 같은데 어떡해야 하지? 하는 복잡한 생각들 속에서 각자 파트에게 각 스프린트마다의 태스크 할당을 자율로 맡겨버렸던 것 같다.

2. 해외 체류로 인한 결속력의 부족

이 역시도 내가 팀원들에게 마음의 부채를 갖고 있는 요소 중 하나이다. 이번 릴리즈의 초입에 나는 예정되어 있던 어학연수를 오게 됐다. 프로젝트를 시작하는 시점에는 어학연수가 이미 확정되어 있었고, 6개월이 넘게 남아있었기에 이가 어학연수에 가서도 지속되고 있을 줄은 꿈에도 몰랐다. 그래서 오프라인이 아닌 전면 비대면으로 회의가 진행되어서 새로운 구성원들이 팀에 녹아드는 데에 분명 어려움이 있었을 것이다. 

3. 해야 할 말을 잘 전달하는 것

이는 내가 평소에도 인지하고 있는 내 스스로에 대한 딜레마이다. 나는 남들에게 상처나 피해를 주지 않고 살아가고자 한다. 그것이 나의 가치관이자 지향점이다. 그렇기에 한번 이야기를 하기 전에 많은 고민을 하게 된다. 앞서 언급한 출석체크 봇의 도입이나 팀 문화와 관련된 자료를 찾아보며 슬랙에 메시지를 보내게 된 사고의 과정도 이에 기반한다. 그러나 이번 릴리즈에서 나 스스로도 많은 감정과 시간의 투자를 요하고, 다른 팀원들에게도 일부 답답한 마음이 들 수 있다는 것을 알게 됐다. 

그래서 어떻게 해결해야 할까?

1. 일정관리의 실패

이와 관련해서는 정말 많은 자료가 있는 것으로 알게 됐다. 실제로 현업에서도 이가 가장 중요하면서도 어려운 난제라는 것을 실감할 수 있었다. 그 중에서도 가장 도움이 될 것 같다고 느껴졌던 글은 위의 게시글이다.

https://brunch.co.kr/@greenful/31

 

IT 15년 썰 - 9

프로젝트 진행 방법론 2부 - 리더를 위한 4원칙 | 지난 글에, 프로젝트 진행 방법론 1부 - '팀'을 위한 4원칙을 정리했고,1. 먼저 보이고, 그 후에 고치자2. 테스트 환경을 구축해서, 평화를 찾자3. 매

brunch.co.kr

 

가장 핵심적인 내용만 간략하게 설명하자면, 어떤 일을 해야 하는지 핵심을 바라보고 모두가 진행상황을 확인할 수 있도록 우선순위대로 진행할 수 있게 하는 것이다.

이에 대해 아예 추진하지 않은 것은 아니었다. 태스크보드를 도입했다가 팀원들이 적극적으로 사용하지 않아서 중간에 그만 둔 적이 있었다. 다음 릴리즈 때는 이에 대해 궁리하여 도입할 수 있도록 시도해봐야겠다는 생각을 했다.

2. 해외 체류로 인한 결속력의 부족

이에 대해서는 내가 일부분 안일했다는 생각이 회고를 하며 들었다. 어쩔 수 없다는 생각이 들었는데, 주기적인 오프라인 모각코와 같은 자리를 마련했다면 충분히 극복할 문제였다고 생각한다.

앞으로는 다음과 같은 자리들을 마련해보고자 한다.

  • 모각코
  • 회식
  • 간헐적으로 오프라인 회의

등.. 다양한 방식을 앞으로도 고민해봐야할 것 같다. 💪🏻

3. 해야 할 말을 잘 전달하는 것

나에게 가장 어려운 부분처럼 느껴진다.

https://post.naver.com/viewer/postView.nhn?volumeNo=30948095&memberNo=799097

 

9회. 기분 나쁘지 않게 피드백하는 법

[BY 카시오페아] 며칠 전, 직원에게 이메일로 피드백을 보낸 적이 있습니다. 그런데 다음 날 직원이 ...

m.post.naver.com

 

가장 와닿은 말은 '서운하다'는 말이 듣기 싫어서, 상대의 마음을 불편하게 하고 싶지 않아서 꼭 필요한 피드백을 삼키고 넘어갈 수는 없다는 것이다. 그 감정까지 피드백을 해주는 입장에서 책임질 수는 없다는 것이다. 어쩌면 이제까지의 나는, 내 스스로의 가치관이 더 중요하다고 생각하며 팀장으로서의 직위보다는 나의 마음이 편하기 위해서 싫은 소리를 피해온 것이라는 생각도 들었다. 다양한 책을 읽고, 건강한 가치관을 확립하여 할 말을 할 수 있는 사람이 되고자 한다.

맺음말

피드백을 받으며 막상 나의 단점들을 마주하게 되니, 장점들은 보이지 않고 단점들만이 머리에 맴돌았다. 그래서 더 빨리 회고를 작성하여 이 감정을 기억했다가 더 개선하며 나아가는 나를 만들어야겠다는 생각을 하게 됐다.

누군가는 그저 학생 단위의 팀 프로젝트에서 왜 이렇게까지 진지하게 생각하고 힘을 빼냐며 비웃을수도 있겠다. 물론, 우리 팀이 창업이나 경제적 이득 등을 목적으로 나아가는 팀은 아니기에 내일 당장 서버를 종료한다고 하더라도 이상할 것 하나 없다. 그러나 이 과정 속에서 나는 정말 많은 것들을 느끼고, 체화하며 배워나가고 있음을 느낀다. 팀 프로젝트 상황에서 드러나는 나의 문제점들 역시도 일정 부분 내가 평소에 인지하고 있던 요소들이었기에 이 기회를 발판 삼아 나아가고 싶다.

이번 릴리즈 기간 내에 나는 나의 최선을 다했지만, 그럼에도 부족한 부분들이 존재하기에 더 완벽하다! 내 부족한 점까지 알게 되어 더 알찼다는 생각이 든다. 앞으로 더 좋은 팀장이, 더 좋은 동료가 되기 위해 기술적으로뿐만 아니라 다양한 방면에서도 발전해내고 싶다.

검색 태그