GDSC Devtalk #9회
지난 4월 6일 목요일 GDSC 9회차 DevTalk이 진행됐었다. 배운 점이 많은 데브톡이였어서, 듣고 느낀 점을 적고자 한다.
각 강연 링크는 아래에 담아놨다.
[GDSC Hongik] 실무에서 협업에 대한 이야기 [Keynote] - 김종필
[GDSC Hongik] 개발자로 성장하기 - 한규진
[GDSC Hongik] Oauth & Open ID Connect - 이찬진
실무에서 협업에 대한 이야기 - 김종필
GDSC는 언제나 섭외 능력에 놀란다. 실제 회사였으면 CTO나 사장님으로 만났을 분의 강연을 무료로 들을 수 있는 자리를 마련해주다니...
김종필 알비언 테크본부장 님의 말씀을 들으면서, 어떤 부분에서는 팩트로 후드려(?) 맞기도 하였고, 어떤 부분은 큰 조언을 얻기도 하였다. 협업을 어떻게 해야 할 지에 대한 이야기인데, 협업을 하는 입장에서 어떤 자세를 취해야 하고, 어떻게 대화를 해야 하며, 어떻게 피드백을 주고 받으면 좋은지에 대해서 이야기를 해주셨다.
먼저 프로젝트, 혹은 일을 진행하는데 있어서 협업은 필수 불가결하다. 군대를 제외한, 거의 모든 곳에서 협업은 필수 불가결하다. 최근 SW 개발병을 지원하려고 군대를 알아보고 있는데, 군대의 경우는 그 특수성 때문에 개인이서 혼자 일을 하는 비중이 훨씬 크다고 하긴 하다. 면접에서도 그런 걸 물어보기도 하고. 그러나 심지어 그런 곳에서조차 어느 정도의 협업은 동반된다고 한다. 하물며 폐쇄적인 군대도 그정도인데, 21세기, 한 프로젝트를 하더라도 각각의 역할이 세분화되고 전문화되는 시대에서, 아무리 작은 규모의 사이드 프로젝트를 한다 하더라도 협업의 가치와 유용성은 무시할 수 없다.
제대로 된 프로젝트를 하기 위해서는 협업이 그래서 필수적이다. 그러나 나는 어떻게 협업의 중요성은 알면서도 어떻게 협업을 해야 하는지는 잘 알지 못 했다. 단순히 내가 나의 역할을 잘 한다면, 그게 장땡이라고 생각했다. 이전까지는 오직 '실력으로 살아남는 개발자가 되자', '1인분은 확실히 하는 개발자가 되자'라는 단순한 생각만 가지고 협업에 임했던 것 같다.
한 가지 놀라운 점은, 김종필 연사님이 말해주시길, 실무에서는 코딩하는 시간보다 미팅을 하고, 회의를 하는 시간이 더 많다고 한다. 사실 어떻게 보면 당연한 것이고, 어떻게 보면 또 놀라운 것이기도 하다. 회의와 미팅, 서로에 대한 피드백은 중요하다. 그것은 이전부터 알고 있었다. 그러나 이를 어떻게 해야 할 지, 그리고 어느 정도로 투자를 해야 할 지는 잘 모르고 있었다. 그런데 심지어 코딩하는 시간보다도 더 오래 투자를 한다니.
프로젝트가 성장하기 위해서는, 코드를 잘 짜는 것 뿐만 아니라, 이 프로젝트가 실질적으로 성공하기 위해서 어떻게 해야 하는지를 개발자들 스스로가 고민하는 시간이 많다고 했다. 단순히 수동적인 입장에서 기획 부서에서 시키는 대로 하는 것이 아니라, 스스로 어떻게 해야 성공할 수 있을지를 직접 고민하는 자세를 개발팀 모두가 갖고 있다는 생각이 들었다.
이러한 회의를 오래 지속함에도, 팀원들이 참여를 하기 위해서는, 프로젝트에 대한 주인의식이 있어야 한다. 이 주인의식은 회사의 경우 월급이라는 금전적 보상을 확실히 주어줌으로써 보장을 하긴 하지만, 그것만으로는 부족하다. 회사에서도 소위 '월급 루팡'은 존재할 수 밖에 없기 때문이다. 그렇기 때문에 개발자들 스스로가 프로젝트가 성공하기 위해서 고민을 하고, 주인의식을 갖고 프로젝트가 더 발전할 수 있게 회의를 할 수 있다는 것은, 회사 자체의 분위기가 개발자로 하여금 스스로 참여 동기와 주인 의식을 갖게 할 수 있는 분위기를 형성하고 있다고 느꼈다. 그리고 이런 생산적이고 참여적인 분위기를 형성하는 것이, 잘 되는 프로젝트를 경험하기 위해 반드시 조성해야 할 문화라고 생각했다.
피드백의 활성화도 그렇다. 실무에서는 매일매일 자기 코드에 대한 피드백을 겪는다고 한다. 사실 정말 두렵다... 현업자 분들한테 내 코드를 보여준다고 하니. 그러나 한편으로는 또 부럽기도 하다. 내가 코드를 짜면서 고민했던 부분들, 이 부분은 어떻게 짜야 더 좋은 코드, 생산성 있는 코드, 깔끔하고 가독성이 좋은 코드가 나올까를 현업 현장에서는 직접 피드백을 받으면서 개선할 수 있다니. 이걸 들으면서 내가 한 단계 더 발전하기 위해서는 인턴쉽 등 실제 현업자 분들과 가까이 일할 수 있는 곳에서 경험을 쌓아야 한다고 느꼈다. 무엇이 됐든, 이러한 피드백을 모든 사람들이 적극적으로 주고 받기 위해서는 이 피드백을 활성화할 수 있는 분위기가 형성되어야 한다.
결국 프로젝트가 성공하기 위해서는 이 시스템이 중요하다고 느꼈고, 이 시스템을 유지하기 위해서는 개개인이 시스템에 참여할 수 있도록 격려하고 장려해야 하며, 리더 역시 이 시스템을 구축하기 위해서 스스로 모범이 되어야 한다고 느꼈다.
또한 연사 님은 실무에서는 매일매일 피드백이 오가고, 서로의 성과를 확인한다고 했다. Slack, Jira, Notion, Excel 등과 같은 협업 툴을 사용해서 이를 정량, 정성적으로 측정할 수단을 마련한다고 했다. 어찌보면 당연한 건데, 회사에서는 이게 바로 월급과 직결되는 문제기 때문인 것 같기도 하다. 이렇게 자주 피드백이 오가다보니 프로젝트의 진행 속도를 이끄는데 기여를 하고, 긴 주기로 피드백이 오가지 않음으로써 각 인원 혹은 부서에서의 역할이 고립되거나 이상한 방향으로 흘러가는 것을 막을 수 있는 것 같다.
보통 대학생 프로젝트의 경우 피드백의 기간이 매우 길다. 일주일에 한 번 모임을 가지는 게 보통이고, 사실 이게 정기적으로 이루어지기만 해도 대단하다. 대다수의 프로젝트 참여인원들은 이 피드백 시간을 갖지 않으려고 하고, 이 시간에도 그냥 조용히 시간이 빨리 지나가길 기다리며 가만히 앉아있을 뿐이다. 그러나 프로젝트가 제대로 진행되기 위해서는, 이를 개선해야 한다. 미팅 시간이 단순히 시간아 흘러가라 하는 지루한 시간으로 낭비하지 않고, 실제 가치를 창출해내는 시간으로 남아야 한다. 이러한 분위기를 조성해야 하고, 이러한 분위기에 참여할 수 있는 팀원들을 프로젝트에 합류시켜야 한다.
연사를 들으면서 내가 경험한 프로젝트를 생각해보았다.
내 경험들에 대한 반성
쓰다보니 길어지기도 하였고, 민감한 내용들도 많았기에 이 글에서는 삭제했다.
두 프로젝트에 대한 반성
nx006.tistory.com
결론적으로 연사님한테 팩폭으로 뚜드려맞았다.. 협업을 하는 목적이 나를 위한 것인지 팀을 위한 것인지를 생각해보게 됐고, 지난 번의 실수를 뉘우치며 다음에 어떻게 개선해야 할 지를 고민하게 됐다. 제대로된 협업, 팀이 같이 성장할 수 있는 협업, 모두가 뿌듯해할 수 있는 협업이란 무엇인지를 고민하는 시간을 가졌다.
지난 두 프로젝트에서 수 많은 반성할 점들을 남겼다. 다음 번에는 더 잘 해낼 수 있겠지.
피드백을 주고 받는 형태 - sync냐 async냐
피드백을 어떻게 주고 받을 것인지에 대해서 질문을 물어봤다.
먼저 피드백을 주고 받는 것 자체는 매우 중요하다. 그러나 이를 어떻게 효율적으로 주고 받는 것일지 고민하는 것도 중요하다.
sync화된 미팅
기본적으로는 sync화된 의견 교환을 생각할 수 있다. 온라인이든 오프라인이든, 관련된 이들이 모두 동시에 참여하는 회의가 대표적이다.
H 동아리에서 운영진을 지낼 때에는 거의 매주 이와 같은 운영진 회의가 있었다. 이 방식에는 장단점이 있는데, 장점의 경우 의견 교환이 빠르고 즉각적이다. 바로바로 소통이 되고, 생각과 의견을 말로 논리적으로 풀어 설명할 수 있고, 피드백 역시 실시간으로 이루어지면서 의사 결정 과정을 빠르게 가져갈 수 있다.
이러한 방식의 문제는 실시간이므로, 시간을 맞추기가 어렵다는데 있다. 회의에 관련된 사람들이 모두 동일한 시간대에 모여야 하고, 이를 위해서 시간을 비워두어야 한다. 보통 온라인이든 오프라인이든, 각자의 일을 하다가 회의를 하기 위해서는 회의에 앞서서 준비 시간이 필요하다. 또한 회의가 끝나더라도 원래 하고 있던 일에 바로 복귀할 수 없고, 일을 전환하는 컨텍스트 스위칭 타임이 소모된다. 보통 회의가 시작되기 10분 전에는 일이 손에 안 잡힌다. 회의가 끝나고는 커피를 마시면서 정신을 돌린다. 이로 인해 만약 회의 시간이 30분이라 할 지라도, 30분이라는 시간만 소요되는 게 아니라, 그 앞뒤에 패딩 영역이 존재하는 것이다. 만약 회의가 오프라인 회의라면? 이동하는 시간이 고스란히 패딩 시간으로 작용한다.
또한 각 스레드(인원들)이 회의라는 task에 모이길 기다려야 하므로, 이 시간 역시 딜레이된다. 누군가 회의에 늦으면, 그 시간이 그대로 딜레이된다.
문제는 더 있는데, 회의에 참여하지 못한 사람의 경우 회의에서 어떠한 이야기가 오고 갔는지를 알 수가 없다는 것이다. 그래서 회의록을 작성하는게 매우 중요하다. 회의 시간에 말한 모든 내용을 문서화함으로써, 빠짐없이 모든 내용이 회의에 참여를 했든 안 했든 간에, 회의에 참여하지 않은 이들은 이 문서화된 내용을 보면서 스스로 업데이트된 상황을 fetch/merge하여서, 동기화가 이루어지게끔 해야 한다.
또 회의에 참여하는 인원이 많을 경우, 예를 들어 10명이 참여할 경우 한 사람이 3분만 말해도 30분이다. 나머지 27분 동안 의견을 내지 못 한다. 그래서 보통은 회의는 참여 인원이 많아질 수록, 그리고 회의가 길어서 지칠 수록 소수의 사람들만 주도권을 잡고서 의견을 피력하고, 나머지는 빨리 끝나길 바라는 마음으로 침묵을 유지한다.
async한 미팅
이를 개선하기 위한 방법으로는 async화된 미팅이 존재한다. async는 모든 스레드가 어느 태스크에 한 번에 참여하는 방식을 취하지 않고, 코루틴(Coroutine)의 방식을 취한다.
오른쪽 그림의 코루틴처럼, 회의는 모든 사람들이 동시에 진행되지 않는다. Async화된 회의는 문서화가 핵심이다. 먼저 주제와 안건을 담은 회외록 주제를 문서화시켜서 공개를 한다. 회의 뿐만이 아니라 해결이 필요한, 그러나 시급하지는 않은 이슈들, 장기적인 토론 등도 포함된다. 문서화를 시킨다음에, 의견이나 피드백을 전달할 게 있으면, 이 문서에 댓글을 달거나 관련된 피드백을 채팅으로 전달하는 식으로 회의에 참여한다. 이 방식의 경우 철저하게 async하다. 모든 참여자들은 각자의 main task에 방해받지 않고, 적당히 main task가 끝났을 때, 확인이 필요한 회의에 참여하며 댓글을 달거나 채팅을 남겨서 의견을 만들고, 적당한 시점에 yield를 일으켜 다시 main task로 복귀한다. 이 경우 main thread는 변경되지 않았고, 스위치 컨텍스트에 따른 시간도 소요되지 않는다(최적의 시간에 코루틴을 일으켰으므로).
회의에 참여하는 사람들이 많아도, 시간의 낭비없이 효율적으로 의견을 표시할 수 있다. 그냥 가서 댓글이나 채팅, 혹은 기타 수단으로 의견을 남기면 되기 때문에.
마치 병렬 처리로 바라본다면, 장단점을 명확하게 구분할 수 있어 더 와닿는다.
async화된 방식의 회의는 언뜻 보면 엄청 효율적이고 애자일스러워 보이는 방식이지만, 실제로는 이 역시 당연히 단점이 존재한다.
- Time Critical한 이슈에 대응하기 힘들다. 촉박한 시간, 빠르게 결정해야 하는 경우는 긴급 회의를 소집해서 빠르게 결정을 내려야 한다. 문서화를 먼저 해서 여유롭게 의견을 나눌 시간이 없다.
- 개개인에게 회의에 참여할 동기를 부여해야 한다.
- 동기가 부여되지 않으면, 모든 인원이 회의를 참여하고 있음을 보장할 수 없다.
async하게 의견을 나눈다는 것은, 반대로 말해 누군가가 의견 교환에 참여를 안 하더라도 티가 나지 않는다는 점이다. 이 사람이 실제로 자기 업무가 바빠서 의견을 내지 못 하는 건지, 아니면 불성실한 태도로 참여를 안 하는 건지를 구분하기 힘들다. 그래서 결국 모두가 의견을 나누는데 참여할 수 있도록 강력한 동기와 보상을 부여해야 한다.
그래서 3번의 문제가 발생한다. 모든 인원이 제대로 회의에 참여하고 있음을 알 수 없다.
때문에 각각의 상황에 맞추어서 제대로 선택을 하는 게 무엇보다 중요해보인다. 내가 물어본 질문은, async 방식을 소개한 뒤, sync화된 방식과 async 중 현업에서는 무엇을 고르는 지 묻는 질문이었다. 현업에선 당연한 소리겠지만 둘다 사용하는데, 다만 어느 것에 비중을 두는 가는 팀장의 판단과 성향이라고 한다. 팀장이 실시간으로 의견이 교환되는 것을 좋아한다면, 당연히 실시간으로 모여서 지켜볼 수 있는 sync화된 방식을 선호할 것이고, 반대로 time critical하지 않고 충분히 길게 의견을 나눌 경우 async한 방식을 선호하기도 할 것이다.
위와 같이 두 방식을 병행하되, 저렇게 기준을 세워서 미팅과 회의를 잡는 것도 유용해보인다.
예를 들어 정기보고같은 경우 모든 인원이 서로 무엇을 했는지 알아야하고, 또한 각자 성과를 이야기해야 하기 때문에, 이 경우는 동기화된 미팅을 진행해야 한다. B612의 먼슬리 리뷰가 그 예일 것이다. 프로젝트라면, 주기적으로 진행되는 보고가 그 예시이다.
반대로 굳이 실시간으로 정보의 공유가 필요하지 않은 것들의 경우, 비동기화된 회의가 유용할 수 있다. 예를 들어 굳이 말로 설명하지 않아도 되는 코드 리뷰라든지. 혹은 애초에 팀원들간의 시간이 맞지 않는 경우. 어쩌면 자주 있지만 작은 규모의 정기 보고같은 경우를 async로 진행할 수가 있겠다. 그런 의미에서 B612의 위클리 리뷰 역시 async로 진행하고 있다.
다음에 프로젝트해볼 때 제대로 한 번 적용해봐야지.
사실 실제로 막상 적용해보려고 해도, 위와 같은 조건을 충족시키지 못한 상황에서는 제대로 활용되지 못할 수가 있다. 나 역시 B612의 회의에서 몇 차례 Async 프로세스를 도입하려고 했으나, 성공하지 못 했다. 성공하지 못한 이유로는, 일단 제대로 효율을 내도록 프로세스를 적용하지 않았다. B612 회의 이전에 미리 문서화를 통해서 안건을 상정해놓고, 댓글을 달게 한 뒤에 온라인 실시간 회의를 가졌다. 미리 댓글을 달아서 결정할 수 있는 부분들은 미리 결정하고 고민을 미리 하게끔 해서, 회의 시간을 단축시키고자 하는 거였는데, 실제로는 회의 시간은 더 늘어났고, 제대로된 프로세스를 적용할 수 없었다. 이를 제대로 적용하게끔 하려면, 더 많은 고민과 시행착오, 그리고 제대로 된 방법의 적용이 필요해보인다.
실무에서는 생산성 툴을 많이 사용한다.
실무에서는 생산성 툴을 많이 사용한다는 것을 알았다. 사실 생산성 툴의 존재는 이전부터 존재했었다. B612 소개 자료를 만들 때에도, 기술 스택에 Notion과 Jetbrain사의 Space는 꼭 넣었다. Space는 실제로 사용하지는 않았지만, 내가 다음 프로젝트를 진행할 시 메인으로 사용하고 싶은 툴이여서 넣었다. 좋아보인다. 그래서 많은 사람들이 알았으면 해서(Slack과 Jira를 섞어놓은 듯한 툴이다.)
그러나 막상 실제로 프로젝트를 경험하면서, 이 툴들을 그렇게까지 유용하게 써보지 못 한 게 아쉽다. Space는 써보지도 못 했고. 특히 노션. 생산성 관리와 조직 관리를 위해서는 어떻게 쓰는지를 몰랐다.
강연에서, 이를 활용하는 유용한 방법 하나를 소개받았는데, 바로 회사에서는 매일매일 팀원이 무엇을 했는지를 체크한다는 것이었다. 이건 엑셀로도 가능하다고 한다. 행에 팀원들의 이름을 넣고, 열에 날짜를 넣어서, 매일 매일 지날 때마다 팀원들이 각자 무엇을 했는지 기록하는 것이다. 이건 회사는 자동화가 됐을테니 신경쓸 필요는 없고, 내가 하는 프로젝트같은 경우는 노션을 통해서 관리를 하면 되겠단 생각을 했다. 학생 입장에서 매일은 너무 심하고, 이틀에 한 번씩 칸을 추가해서 기록을 하게끔 하는 식으로 말이다. 이러면 확실히 부담스러워서라도 생산성은 급증할 것 같다.
프로젝트를 하면서 생산성 툴을 어떻게 효율적으로 활용할 것인지는 꼭 경험해보고 시작하는게 좋아 보인다. 그 외에는 실제로 사용해보면서, 아 이 부분은 불편하니깐 다르게 대체하고, 이 부분은 이렇게 쓰는게 더 좋다는 걸 경험해보면서 개선해나가면 될 것 같다.
개발자로 성장하기 - 한규진
'두둥'의 프론트엔드 개발자 한규진 님의 강연인데, 보면서 두둥 멋있어.. 라는 생각 밖에 안 들었다. 단순히 실제 프로덕트 레벨에서의 프로젝트를 완성하고 배포까지 했다는 점이 아니라, 군대가기 전에 만난 이들이 훗날을 기약하고 군대에서 돌아와서 다시 같이 모여서, 자신들이 겪었던 불편함을 해소하기 위해서 아이디어를 내놓고 이를 실현했다는 점이, 그리고 이 두둥 서비스를 만들기까지 두 번의 앞선 프로젝트를 겪으면서 두둥을 준비하게 됐다는 것이 정말 깔끔한 서사를 완성하면서, 프로젝트의 완성도를 더욱더 높이고 빛을 나게 한 것 같다. 대단하다.
지난 DevTalk #8에서 백엔드 개발자 이찬진 님의 두둥 개발에 대한 이야기를 듣고 나서 바로 프론트엔드의 이야기를 들으니깐 연속적으로 이어져서 더 몰입되기도 했다.
그리고 확실히 넥스터즈, CEOS가 정말 체계적이고, 도움이 많이 되는 동아리라고 생각들었다. 실제 현업 개발자분들의 피드백을 실시간으로 들을 수 있다니... 정말 부러웠다. 나도 CEOS 들어가고 싶다. 다음에 열리면 꼭 넣어볼 것이다.
또 개발 일지를 남기는 것의 중요성을 정말 실감하고 있다. 두둥의 개발일지를 보니깐 정말 체계적으로 잘 쓰였다.
나는 그동안 왜 안 남겼을까... 이제부턴 무조건 남길 거다. 저렇게 개발 일지를 남기니깐 서비스를 개발하기까지 어떤 고민과 과정을 거쳤는지 알 수 있어서, 도움이 많이 될 것 같다. 특히 오류를 어떻게 처리했는지는, 다른 팀원들 역시 같은 오류를 겪을 때 헤메지 말란 의미에서 문서화하는 것은 매우매우매우 중요해보인다. 오류 핸들링만이라도, 혹은 어떤 복잡하고 중요한 기능을 구현했을 때 이를 어떻게 구현했는지 등은 프로젝트 전체를 위해서도 중요한 과정임을 느꼈다.
사실 매번 저렇게 개발 일지를 남기기가 쉽지 않은데, 정말 프로젝트가 체계적으로 진행됐구나라는 것을 알 수 있었다. 이게 경력자들의 힘일까.
사실 지난 데브톡 듣고서 바로 득달같이 두둥 깃허브에 들어갔는데, 여기서는 이렇게 깃허브 관리를 활용했구나라는 것을 배울 수 있었다. 이슈를 제대로 활용한 것이 눈에 뛰었다. 이슈를 생성하고, 이슈를 생성했으니 무엇을 개발할 지에 대한 명세서를 얻는다. 이에 맞추어 Pull Request를 발생시킨다. 너무 깔끔한 프로세스에 굉장히 놀랐고, 보고 배울 점이 많은 히스토리였다.
정말 깔끔하다.
특히 PR 기록과 리뷰 프로세싱도 깔끔해보였다. 보고 배워야지.
Oauth & Open ID Connect - 이찬진
Firebase Auth를 써야겠다고 생각했다.
농담이고, 사실 이 부분은 나에게 있어 다소 어려운 부분이었다. 그럼에도 불구하고 매우 중요한 내용이라는 건 느낌적으로 감이 온다. 특히 단순히 Firebase Auth만 사용한다고 해서 끝날 게 아니고, 그 후에도 발생할 수 있는 보안 문제에 대해서 끊임없이 신경써주어야 한다는 것을 알았다.
회원 가입 기능 하나를 구현하기 위해서 그 뒤에서는 수많은 고민과 고려해야 할 것들이 존재한다는 것을 실감했다.
또 인증과 인가를 구분해서 사용하자는 말이 제일 깔끔한 설명같았다.
2023년 8월 7일 추가.
짧기도 하고, 길기도 한 시간이 지나고 나서 다시 이 발표를 찾아 듣게 되었는데, 지금 배워가는 점이 더 많은 것 같다. 역시 아는 만큼 보인다는 말이 맞는 것 같다.
그동안 JWT 및 OAuth에 대해서 더 배울 기회가 있었다. 이때 이 발표에서 인증과 인가를 구분해서 사용하라는 말이 기억나면서, 까다로운 Auth를 더 정확히 이해하는 데 있어서 큰 도움이 됐다.
결론 및 후기
데브톡 듣기만 해도 커피를 받는다. 잔뜩 좋았다.
나도 언젠가 저런 대단한 고인물 개발자가 되고 싶다. 화이팅.