신입A : "OOO기술을 도입해 성능 개선을 하고 싶습니다."
선임B : "지금 할 일이 태산인데 시간이 있겠어요?
도입하더라도 어떤 개선이 있을지 모르겠네요.
제가 보기엔 큰 차이 없을 것 같은데. 나중에 보죠."
신입A : "OOO 기술을 도입해 OOO 프로젝트의 단점을 보완하면
향후 투입 리소스가 20%정도 감소되고,
잠재된 기술 부채도 축소시킬 수 있을 것으로 예상합니다."
선임B : "와~ 좋은 기술에 대해 분석을 해오셨네요.
지금 당장은 진행중인 프로젝트 때문에 개발자 여력이 부족한데,
OO 프로젝트가 마무리되는 2개월 후에 TF를 구성해서 제대로 같이 보시죠.”
둘 다 흔한 신입과 선임 간의 대화입니다. 그런데 같은 상황, 많이 다른 느낌이죠?
동료들간 대화 방식은 그 회사의 기업문화, 개발 문화를 투영한다고 생각하는데요.
두번째 대화는 어쩐지 평소에 ‘테크톡’ 좀 해본 느낌 아닌가요? 😉
여러분은 ‘테크톡’ 하면 어떤 생각이 나세요?
아마 대부분 DEVIEW, 토스 테크, NHN FORWARD 와 같은 큰 규모의 세미나를 떠올리실 것 같습니다.
그런데 이런 생각도 한번쯤 해보지 않으셨나요?
‘매일 만나는 동료들과 일상적으로 테크톡을 하면 어떨까?’
그래서 준비해 봤습니다. 쪼그려 앉아서 해도 괜찮고, 하고 싶은 사람만 참여해도 괜찮은,
위메프 개발 문화 2편. 테크톡 이야기입니다.
"어떻게 할까", "무엇부터 해야 하나?"… 일단 시작~!
테크톡. 말 그대로 기술 주제를 정해 토론하고 이견을 조율하면 되는 건데, 머릿속으론 간단하지만 실행에 옮기려고 하니 어렵더군요. 그래서 팀원들에게 제 생각을 허심탄회하게 풀어놓았습니다. 우리에게 오랜 미해결 과제이면서 동시에 토론을 통해 개선해볼 수 있는 주제를 함께 찾아보자고요.
“자동화 크롤링 플랫폼을 만들어 보려고 합니다. UI 기반의 검증 필터를 생각하고 있는데요. 물론 에러를 자동으로 처리, 반영해주면 더욱 좋겠네요. 어떠한 시스템에 적용하더라도 동작을 해야 하고 누구나 운영할 수 있는 편의성도 있었으면 합니다. 이걸 테크톡 주제로 논의해 볼까요?”
그렇게 주제를 정하고도 그 다음으로 해야 할 일은 무엇인지, 우선순위를 조율하는 일이 또 막막하더라고요. 그래서 주니어부터 시니어 개발자 모두 공통의 주제에 대해 각자 끄적여 놓은 메모장을 서로 공유하면서 함께 답을 찾자고 제안했습니다.
“지금 이 주제를 듣고 머릿속에 있는 생각을 글로 써주세요. 어떤 내용이든 좋습니다.”
사실 개발자들은 누군가에게 요청을 받아서 그것을 개발하는 프로세스로 일하는 것에 익숙합니다. 그래서 협업툴에 내가 작업해야 할 내용(요청)이 구체적으로 명시돼 있지 않으면, 소위 멘붕상태(!)가 되기도 합니다. ‘글을 쓴다’는 것도 일상적인 업무가 아니다 보니 약간의 멘붕을 유발하긴 하죠.
하지만 목적에 맞는 글을 쓴다는 것은 개발자들의 성장에 큰 도움을 준다고 생각합니다. 글을 통해 생각과 기술을 공유하면 우리가 하나의 커뮤니티에 속해 있다는 유대감이 형성되니까요.
그래서 테크톡은 개발자들이 주제를 스스로 선정해 생각을 글로 정리해보고, 자율적이고 적극적인 학습을 통해 다른 개발자들과 상호 교류를 하는 소중한 기회가 됩니다.
막상 판이 깔리니 열띤 토론장!
테크톡을 시작할 때 정한 룰입니다. 토론에서 규칙은 꼭 필요하거든요.
1. 동료가 이야기를 할 때는 경청한다.
2. 이견이 있더라도 중간에 말을 끊지 않는다.
3. 주제에 맞고, 대안이 있는 이견을 제시한다.
상대의 의견을 충분히 듣지 않고 말을 끊거나 반대를 위한 이견만 제시하면 자칫 불필요한 갈등으로 번질 수 있기 때문이죠.
테크톡에 참여하는 개발자는 경력 1년차에서 20년차까지 스펙트럼이 넓은데요. 각자의 의견을 존중하면서 서로의 기술적 고민을 충분히 듣고 이야기하다 보니, 자연스레 다양한 관점에서 함께 문제를 해결하는 방식으로 운영이 됩니다.
‘스탠딩 브리핑’이지만 쪼그려 앉아도 괜찮아요
토론을 통해 해야 할 일을 도출하고, 해결점과 보완점을 모색하다 보면 너무 몰두한 나머지 놓치는 포인트가 생길 수 있습니다. 주제 선정을 포함한 모든 것이 무에서 유가 됐으니, 분명 그렇겠죠?😉
토론 진행 중간에 지금까지 정리된 내용을 보드에 적으며 우리가 도출한 내용이 맞는지 함께 점검해 봅니다. 앞서 말했듯이 글로 쓰는 것이 생각을 정리하는데 큰 도움이 됩니다.
‘스탠딩 브리핑’이라고 부르는 이 시간만큼은 이견이 있거나 다른 아이디어가 있을 경우 언제든 끼어들어서 말할 수 있습니다. 토론 규칙과는 상반되죠. 이렇게 하는 이유는 다른 의견을 기록해 두고 이 이슈가 해소될때까지 또 다른 토론을 통해 새로운 의견을 분석, 반영할 수 있기 때문입니다.
혹시 이러다 계획을 전면 수정해야 하는 상황은 오지 않냐고요? 앞서 수많은 토론과 논의를 통해서 주제를 선정하고 분석했기 때문에 아직까지 그런 경우는 없었습니다. 그렇지만 만약 계획을 전면 수정하자고 의견이 모아지면 그렇게 하면 되는 거 아닐까요? 그러니 더욱 마음껏 토론하면 됩니다.
함께 프로젝트 하실 분 모셔요!📢
이제 거의 다 왔습니다.
계획 보고서를 협업 문서에 공유하고 그룹메신저를 통해 새로운 프로젝트를 함께할 분을 공개 모집해봅시다!
📄 계획 보고서
· 소개 새로운 프로젝트를 소개하고 주요 기능과 이점에 대해 소개합니다.
· 도입 취지 이슈를 발견하고 문제점을 상세하게 명시해 손실 부분을 알려주는게 도움이 됩니다.
· 계획 및 로드맵 로드맵의 경우 작업 리소스 대비 효과를 측정하기 위한 근거 자료로 계획과 다를 수 있겠지만
실제 작업에 투입된 기록을 명시합니다.
· 개선 사항 이전과 다르게 개선된 사안을 명시하고 기대 효과도 기입해 두는게 좋습니다.
· 향후 계획 향후 고도화 계획 및 운영 방안 그리고 추가 작업을 명시합니다.
개발자라면 새로운 기술을 사용해 보고 싶은 욕심은 꼭 있을 거라고 생각합니다. 하지만 현업이 바빠서 참여를 꺼리거나 주저하시는 분들이 많죠.
결국 참여를 가능하게 하는 환경이 가장 중요합니다. 업무가 많으면 양해를 구하고 본인 의지만큼만 참여하도록 하고, 다른 사람 눈치를 보거나 주저할 필요가 없는 분위기를 만드는 거죠. 한마디로, 좋은 개발 문화.😊
실제 위메프의 플랫폼과 서비스에 발전적인 영향을 줄 수 있기 때문에 프로젝트 참여시 업무 성과로 인정하며, 동료나 다른 프로젝트에 피해가 가지 않도록 일정을 조율해가며 진행하고 있습니다. 이렇게 개인의 커리어에도 도움되는 일석이조 프로젝트다 보니 개발자들의 자발적 참여율도 꽤 좋습니다.
구현 그리고 완성을 위해 다시 테크톡
자, 프로젝트 구성원들은 다 모였습니다. 이제 공수 산정을 해야죠!
프로젝트는 사실상 정해진 마감 일정이 없기 때문에 최대한 여러 사항을 고려하면서 작업 일정을 산출해야 합니다. 시간이 다소 걸리더라도 충분히 고민을 많이 하면서 개발하고 테스트 시간을 부족하지 않게 갖는다면 좋은 산출물이 나올 거라 기대하면서요.
"짜잔~!!!!" 어느덧 산출물이 나왔는데요. 여러분이라면 제일 먼저 무엇을 하고 싶으신가요? 옆에 있는 동료에게 자랑하고 싶으시죠? 저희는 다시 작은 테크톡을 하기로 했습니다.
프로덕트나 아키텍처를 어떻게 만들었는지는 물론 왜 만들었는지, 또 어떤 가치를 갖고, 어떤 영향을 미치는지를 공유해야 하니까요. 또 실무에 적용하기 전, 각 분야의 동료와 실무진들 의견을 수렴해서 고도화를 계획하고 수정 보완의 인사이트를 얻는 자리가 필요하고요.
테크톡 자리에서 동료들이 결과물에 사용된 기술에 대한 궁금증을 쏟아내면 기분이 좋습니다. 다음 테크톡 참여를 독려할 수 있으니까요! 이러한 끊김 없는 기술 공유와 소통은 개발 조직 내에서 너무 기본적이면서도 정말 중요한 부분인데요.
위메프는 개발자분들이 더 만족스러운 환경에서 일할 수 있도록 일하는 방식과 프로세스에 대해서 항상 고민합니다. 테크톡과 같은 시도를 통해 개발 문화를 만들고요.
이런 개발 문화를 계속해 잘 지켜 나가려면 ‘좋은 동료’가 필요한데요.
어떠세요, 함께 일해보지 않으시겠어요?
원하신다면 현재 채용 중인 개발 포지션 채용공고를 참고해 주세요!
플랫폼 백앤드개발 채용공고 바로가기
에릭
쿠폰·디자인시스템과 같은 플랫폼개발업무와
파트너센터, 마케팅센터 서비스를 맡고 있습니다.
아! 가장 중요한 팀원들의 휴가결재도요!
