부산 개발자 네트워킹하고 옴.
회고
2023.12.09(토) PM 02:00 ~ PM 05:30
GDG(Google for Developers Group)에서 주최한 "부산 개발자들의 송년회와 새로운 한 해의 준비 행사"에 다녀왔다. 학부에서 프론트를 지망하는 사람은 거의 없었기에 커리어 준비도 거의 혼자 했는데 부산의 여러 개발자들과 만나 소통할 수 있는 기회가 생겨 반가웠다. MBTI가 ISTJ라 이런 외부 행사를 즐기는 편은 아니지만(해커톤은 좋아함), 친구의 권유로 같이 가게 되었다. 그런데 친구가 발을 빼는 바람에 혼자 갔다..
세션이 끝난 후에는 혼자 쓸쓸하게 있었는데 주변 분들이 먼저 말을 걸어주셔서 많은 이야기를 할 수 있었다. GDG에 가입하는 것도 재밌을 것 같고.
개발자도 혼자 일하지 않는다.
행사는 2개의 세션과 네트워킹 시간으로 구성되었다. 네트워킹 시간에 여러 개발자분들과 이야기하는 시간도 즐거웠지만, 2개의 세션에서 얻어가는 것이 많았다. 첫 번째 세션은 쏘카의 하재민 PM님의 "이젠 개발자도 혼자 일하지 않는다."를 주제로 개발자들이 지녀야 할 소프트스킬을 정형화하는 방법에 대해서 알려주셨다.
개발자는 절대 혼자서 일하지 않는다. 그러면 어떻게 잘 커뮤니케이션을 해야 할까? 이런 커뮤니케이션 방법은 누군가 가르쳐주지 않고 또 정형화되어 있지 않기 때문에 개발자들마다 커뮤니케이션하는 방식이 상이한 편이다. 그러나 이는 개발자와 소통하는 PM도 마찬가지이다. 하재민님은 PM의 입장에서 개발자들과 소통하면서 커뮤니케이션을 잘하는 분은 어떤 분인지, 커뮤니케이션에서 중요한 것은 무엇인지, 어떻게 해야하는지에 대해서 사례를 통해 자세히 설명해주셨다.
커뮤니케이션의 핵심 요소는 다음과 같다. PM이 개발자에게 요구사항을 잘 전달하고 개발자가 PM과 소통하기 위해서는 "개요", "목적", "목표", "산출물"이 필수적으로 들어가야 한다. PM은 프로젝트의 마감 기한을 지키고 완성시켜야 할 필요가 있다. 그리고 개발자는 프로젝트가 구현 가능한 지, 산출물의 구현에 책임질 필요가 있다. 서로 다른 입장의 개발자와 PM은 서로에게 필요한 것을 명확하게 전달할 필요가 있다. PM은 개발자에게 "검색 아이템을 태그별로 필터링해서 유저에게 보여주는 기능을 구현해주세요"라고 할 것이 아니라, 개요와 목적, 목표, 산출물을 명시해서 전달할 필요가 있다. 개발자는 PM에게 받은 요구사항으로 기능이 어떤 이유로 언제까지 어떻게 가능할지를 명확하게 답변해줄 필요가 있다.
아직 나는 학부생 개발자일 뿐이지만, PM님이 말하고자 하는 바를 이해할 수 있었다. 팀프로젝트를 진행하면서 그런 어려움을 겪어본 적은 없지만 프로젝트 기획 시 요구 사항을 정확하게 명시하고 팀원들과 소통할 때 서로 다른 이야기를 하는 것 같으면 요구 사항을 다시 확인하고 수정하면서 합의한 경험은 있기 때문이다. 팀프로젝트 경험이 많지 않아 나의 커뮤니케이션 스킬도 부족할지 모르지만, 이번 졸업 과제 프로젝트를 진행할 때는 이런 커뮤니케이션의 중요성을 항상 염두하며 팀원들과 이야기해봐야겠다.
1. 개요(Summary)
2. 목적(Why)
3. 목표(What)
4. 산출물(How to)
5. 성과(선택)
회고를 회고하는 시간
2번째 세션은 Microsoft MVP이면서 Ubuntu 커뮤니티 운영진이신 한상곤 교수님께서 "Meta Retrospective - 회고를 회고하는 시간"을 주제로 개발자들의 올바른 회고에 대해서 알려주셨다. 사실 이번 행사를 참여한 주된 이유는 작년에 한상곤 교수님의 프로그래밍 언어론 수업에서 좋은 말씀을 많이 듣고 교수님이 세션을 맡으신다는 소식을 듣고 참여한 것이 크다.
"회고"란 "뒤를 돌아봄", "지난 일을 돌이켜 생각해봄"이란 뜻을 가진다. 개발자들에게 "회고"란 "구성원이 지난 일을 되돌아보고 느낀 바와 배운 점을 기반으로 성장하기 위해 앞으로 개선할 점을 찾아가는 활동"을 의미한다.
한상곤 교수님께서는 우리나라에서 많은 개발자들이 잘못된 회고를 하고있다고 꼬집었다. 초등학교 시절부터 일기를 강제로 쓰던 한국인들에게 회고란, 일기를 쓰는 것처럼 "잘못한 것을 돌아보아야 하는 싫은 일", "마치 일기처럼 주구절절하게 적는 것", "객관적으로 문제를 분석하기 보다는 문제에 대해 본인을 탓하는 것"과 같이 자아비판이 되는 경향이 있다고 한다. 특히나 팀 내에서 회고를 한다면 서로의 문제점을 지적하며 싸움이 될 수도 있다고 한다. 회고를 통해 자신과 싸우는 것을 멈추고 우리를 성장시키도록 회고해야 한다고 말씀하셨다.
회고의 장점은 다음과 같다.
- 데이터의 누적
- 개발 실력의 향상
- 자신과의 싸움을 멈추고 자신을 긍정
회고를 작성하는 방식은 여러가지가 있는데, 그 중에서 일기, 블로그, 커밋에 대해 이야가했다. (1) 일기는 단기 회고를 진행하는 것으로 일기를 쓰고 있으면 따로 회고를 할 필요가 없다. 대신 "자신을 들여다보는 일"이기 때문에 괴롭다. (2) 블로그는 비주기적인 글쓰기 또는 회고로, 자신의 생각 혹은 어떤 문제를 소개하거나 해결책을 개시한다. 보통 블로그는 '이런 문제를 어떻게 해결했다.'와 같이 해결책에 집중하는 경향이 있다. 또한 비주기적으로 작성되기 때문에 포스트 간에 컨텍스트(맥락)이 이어지지 않는다. (3) 커밋은 Git 프로젝트의 변경사항을 기록하는 행위이다. Git 커밋 메세지를 잘 적을수록 좋은 개발자로 여겨진다. 그러나 블로그와 마찬가지로 많은 개발자들이 커밋 메세지를 "문제를 해결한 결과"에 대해서만 기록한다. 이는 컨텍스트(맥락)가 부재한 상태로, 1년 뒤에 메세지를 돌아볼 때 "그 때 이 기능을 왜 구현했지?"와 같이 선택의 원인을 알 수 없게 된다.
한상곤 교수님은 선택에 대해 기록하라고 하셨다. 선택한 것과 선택을 한 이유, 선택에 영향을 준 외부 상황 등을 상세히 기록함으로써 기록 간의 컨텍스트가 이어지고, 이는 이후에 올바른 회고로써 기능할 것이다. 나중에 선택을 후회하게 된다 하더라도, 모든 사람은 일관성을 가지기 때문에 본인의 선택 또한 일관성을 유지할 것이고, 따라서 그 선택에 대해 후회하기보다는 받아들이면 된다고 한다.
회고를 주기적으로 작성하는 것은 어려운 일이기 때문에, 의식적으로 노력하는 수 밖에 없다고 하셨다. 결론은 다음과 같다.
- 짧은 회고나 주기적인 회고는 개발자를 향상시킴.
- 맥락이 누락되지 않는 방법은 문서화나 대화를 통해서 계속해서 맥락을 보충해줘야 함.
- 짧은 커밋 메시지에 신경을 쓰자.
- 잘하는 것은 실력이 아니라 어쩌면 "신뢰"일 확률이 높음.
- 잘하려면 피드백을 잘 받아야 한다.
- 선택에 대한 이유를 중요시하자.
- 반복과 실수를 통해 교정할 수 있어야 한다.
느낀 점
원래는 내가 여태까지 회고라고 작성했던 것들이 조금 부끄러웠다. 거의 뭐 일기처럼 작성해서 남들에게 보여줄 것이 못 되었다. 그러나 세션을 듣고난 뒤 부터는 생각이 바뀌었다. 크래프톤 정글 당시, 회고를 일기처럼 작성하면서 하루의 상황과 내가 배운 것, 느낀 점, 생각했던 바를 가감없이 기록했었다. 모든 것을 적나라하게 적은 덕분에 지금 다시 읽어 보더라도 그때의 상황(컨텍스트)가 생생하게 기억난다. 단어 선택이나 문장이 조금 저렴하긴 하지만, 회고의 틀을 유지했었던 것이다.
정글 수료 이후로는 거의 작성하지 않게 되었지만.. 다시 열심히 써볼 생각이다. 2023 연말 회고를 시작으로 졸업과제 정기 회고, 프로젝트 회고 등 잘 작성해봐야겠다.
그리고 개발자 지인이라고는 크래프톤 정글과 학교 친구들 밖에 없었는데 이번 네트워킹 행사를 통해 여러 사람들과 만날 수 있었다. 초청된 오프라인 모각코 행사도 참여하면서 네트워킹을 지속적으로 이어나갈 생각이다.
아래부터는 devfest에서 작성한 필기이다.
231209 정리
## 개발자도 혼자 일하지 않는다
하재민 - 쏘카
스타트업 구조
TL(Tech Leader)
BO(Business Owner), PM(Product Manager)
### 커뮤니케이션의 핵심 요소
1. 개요(Summary)
2. 목적(Why)
3. 목표(What)
4. 산출물(How to)
5. 성과(선택)
## 회고를 회고하는 시간
한상곤(Microsoft MVP)
회고
- 뒤를 돌아봄, 지난 일을 돌이켜 생각해봄
- 구성원이 지난 일을 되돌아보고 느낀 바와 재운 점을 기반으로 성장하기 위해 앞으로 개선할 점을 찾아가는 활동
- (주로) 개선점을 알거나 혹은 개선사항을 찾는 과정
- 개발에서 회고 == 애자일 방법론
애자일 방법론이 유행했기 때문. 특히 MSA
대한민국에서 회고란, 자아비판이 되는 경향이 있다. 팀에서 회고하면, 곧 싸움이 될 수 있다.
그래도 회고는 우리를 반드시 성장시킨다. 또한, 개발 실력도 향상 시킨다. 마지막으로 자신과의 싸움을 멈추어야 한다.
A. 데이터 누적
- 일기: 단기회고를 진행하는 것, 일기를 쓰고 있으면 따로 회고할 필요가 없음.
=> 자신을 들여다보는 일이기 때문에 괴롭다.
- 블로그: 비주기적인 글쓰기 혹은 회고, 자신의 생각이나 정서/혹은 어떤 문제를 소개하거나 해결책을 제시
=> 그러나 뒤돌아보지 않는다. 대신 해결한 문제에 대해서만 적는다. 과거보다는 현재에 집중한다.
=> 또한 비주기적으로 작성하기 때문에 컨텍스트(맥락)이 이어지지 않는다.
- 커밋
OKR은 거르라.
대부분의 회고는 해결에 대해 집중하지, 문제를 적지 않는다. 대신 짧은 회고를 추천한다.
- 내가 "선택"한 것을 기록. 선택을 한 이유를 기록. => XGP와 PS Plus 중 XGP를 선택
- 선택의 결과를 작성
- 모든 사람은 선택에 대해 일관성을 가진다. 그러니 선택에 대해 후회할 필요가 없고 받아들이면 된다.
대학생들은 직군을 정하지 않는다. '삼성을 가고 싶다' 삼성이란 회사는 없다. 직군은 어디야? 경향을 파악하고 관심사를 집중시켜야 한다.
### 회고는 개발 실력도 향상시킨다.
전문성을 올리는 방법
- 잘 정의된 작업
- 적절한 난이도
- 정보가 풍부하고 때맞는 피드백
- 반복과 실수를 교정의 기회
커밋을 잘 써라. 커밋을 쓸 때도 왜 그 선택을 했는지, 그 선택에 영향을 준 것은 무엇인지, 외부 상황 같은 것을 모조리 쓰라. 어차피 아무도 안 본다. "맥락"은 외부에 존재한다. 코드가 이상한 이유는 "맥락"이 누락되었기 때문인다.
## 결론
따라서 의식적으로 노력해야 한다.
- 짧은 회고나 주기적인 회고는 개발자를 향상시킴.
- 맥락이 누락되지 않는 방법은 문서화나 대화를 통해서 계속해서 맥락을 보충해줘야 함.
- 짧은 커밋 메시지에 신경을 쓰자.
- 잘하는 것은 실력이 아니라 어쩌면 "신뢰"일 확률이 높음.
- 잘하려면 피드백을 잘 받아야 한다.
- 선택에 대한 이유를 중요시하자.
- 반복과 실수를 통해 교정할 수 있어야 한다.