테오의 W-IT DAY 강연 및 네트워킹 행사 참여 회고록
부산의 네트워킹 행사인 W-IT DAY에 테오님께서 오신다는 소식을 들었습니다
헉, 테오님이? 그것도 부산에?
부산에는 개발자 네트워킹 행사가 정말 귀한데,
제가 취준생일 때부터 존경한 테오님이 오신다니 가지 않을 이유가 없었습니다
테오님의 강연을 들을 수 있는 기회니 철저히 준비하지 않으면 안되겠죠
오시기 며칠 전부터 혹시나, 블로그의 글을 언급 하실까봐
최근에 작성하신, 그리고 테오님 블로그에서 중요한 키워드들을 미리 스크랩도 하고 예습해 갔습니다
그리고 강연 중에 블로그에 쓰셨던 내용을 언급해 주셔서 들으면서 내심 너무 반가웠습니다
(나 미리 공부하길 잘했다! + 내적 환호)
강연의 큰 주제는 Don’t be a Programmer, be a Problem Solver 였습니다
아래에 강연을 시작하며 처음 보여주신 내용을 인용합니다
생각이 바뀌면 관점이 바뀌고
관점은 태도를 바꾸며
태도는 행동을 바뀌게 한다
행동은 바뀌면 습관이 바뀌고
습관이 바뀌면 인격이 바뀌고
인격이 바뀌면 운명이 달라진다
생각을 바꾸는 것을 시작으로 운명도 바꿀 수 있을까요?
어떤 이야기를 들려주실 지 다음 이야기가 너무 궁금해졌습니다
- 모든 강연 내용을 정리하지는 않았습니다.
- 테오님의 블로그에 강연 내용을 상세히 정리한 글이 있어 첨부합니다. (링크)
관점과 태도에 대한 이야기
- 왜 협업을 잘 해야 하는지?
- 어떠한 관점과 태도를 가져야 하는지?
- 그래서 어떻게 해야 하는지?
좋은 개발자가 되기 위한 세 가지 가치
- 코드의 품질
- 좋은 제품 (시장 가치)
- 개발 시간의 딜레마
좋은 개발자가 되기 위해서 가장 큰 고민인 세 가지 가치
저 역시도 이 세 가지 안에서 혼란스러워했던 적이 있는데
이 셋 다 만족시키는 것은 (현실적으로) 불가능하다고 합니다
코드의 품질에 집착하는 개발자라고 해도
개발의 결과물은 시장 가치로 평가받는 것이며
‘개발자들조차 공개 라이브러리를 쓸 때 코드 품질에는 관심이 없다’는 말에 고개를 끄덕일 수 밖에 없었습니다
그럼 개발자는 코드 품질따위는 버리고 시장 가치만을 좇아야 하는가?
강연에서는 그렇지 않다고 설명해 주셨습니다
낙후된 코드의 품질은 개발 의욕마저 떨어뜨린다
비즈니스가 성공하여 규모가 커지면 다시 코드의 품질이 중요해진다고 합니다
즉, 낙후된 코드 품질은 지속 가능한 가치를 떨어뜨리는데
코드 품질은 바삭한 김의 방부제와 같은 역할이라 볼 수 있다는 비유를 들어주셨습니다
개발자의 역할은 코드의 품질을 유지하면서도, 비즈니스의 가치를 높이는 균형의 수호자가 되어야 하는데
그래서 참 어렵다는 말에 동감했습니다
개발자의 삼각형 : 요구사항, 시간, 코드의 품질
이 세 가지 가치가 개발자의 삼각형을 만들고,
세 가지 가치의 충돌에 대해 지혜롭게 해결할 수 있는 방법에 대한 세션이 이어졌습니다
저는 위 세 가지의 가치가 꼭 100% 채워져야 좋은 개발자, 잘하는 개발자라고 생각했었는데
사실 셋 다 지키려면 정말 나를 갈아야 했습니다
문제의 해결이 될 때까지 주말도 불사지르고 저를 갈면서 만들어 내려고만 했었고,
그렇게 정신없이 달린 결과가 양질의 코드로 보답해주진 않았으며
강연 주제인 Problem Solver 에는 점점 멀어졌던 것 같습니다
코드도 중요하고, 비즈니스 가치도 중요하고, 시간도 중요하고…
다 챙기면 번아웃이 쨘 하고 나타납니다
강연에서는 이 세 가지를 조율하는 것이 개발자의 일이고,
꼭 하나를 포기할 필요도 없으며, 어떤 모양의 삼각형을 그려야 하는 지 아는 것이 실력이라고 설명해 주셨습니다
-
모두 다 내가 선택하는 것
- 요구사항, 시간, 코드 품질
- 번아웃, 자괴감 사이
- 코드, 비즈니스 가치의 균형 감각
- 그리고 이러한 균형의 수호자 역할까지도
-
이 모든 것들을 다 선택하는 게 개발자의 역할
- 코딩만이 개발이 아니다
- ‘주도적으로, 즐겁게, 내가 무언가 하고 있구나!’
그 이야기를 듣고 나서부터 삼각형 안에서 고민하는 수동적인 개발자가 아니라,
삼각형을 능동적으로 조율하는, 정말로 ‘해결사’가 된 기분이 들었습니다
코딩만이 개발이 아니었던 것입니다
동시에 개발자는 주도적으로 일할 수 있는, 참 멋진 직업이구나 하는 생각도 들었습니다
나는 어떻게 하면 매력적이고 독보적인 해결사가 될 수 있을지
새로운 인사이트를 얻고, 즐거운 고민을 할 수 있었던 것 같습니다
협업의 가치와 문제 해결사
해결사로 다시 태어난 개발자는 이제 어떻게 하면 좋을까요?
개발의 가치는 비즈니스 가치로 인해 만들어지는데,
개발자의 직무로만 비즈니스의 가치를 높이는 것은 쉽지 않다고 합니다
저점을 높일 수는 있으나, 고점을 높이기는 어렵다
그래서 고점을 높이기 위해, 협업의 가치가 중요하다고 합니다
우리는 하나의 팀이고, 어떻게든 함께 해결해야 한다!
회사에는 다양한 직군의 사람들이 모여 공동의 목표, 즉 회사의 비즈니스 가치를 높이기 위해 협업하고 있는데
사람들과 함께하는 모든 행위가 곧 개발이고 비즈니스 가치라고 설명해 주셨습니다
그리고 실제 문제 해결 사례로 서버 문제 해결에 대한 이야기를 들려 주셨는데,
이 서버 문제를 각각의 문제로 보는 것이 아니라
모든 팀이 함께 적극적으로 해결함으로서
캐싱, 낙관적 업데이트, 서버 성능 개선 같은 부수적인 효과까지 얻었다고 합니다
개발 관련 이야기라서 정말 흥미롭게 들었던 세션이었습니다
개발로만 모든 문제를 해결할 필요는 없다
예시로, 한 항공사에서 수하물이 너무 늦게 도착한다는 이용객들의 불만이 쌓였을 때
‘대기시간 증대’를 문제로 본 것이 아니라
‘공항 전체 이동 동선이 짧고, 서비스 경험이 미흡하다’는 것이 문제라는 것을 찾고
항공사의 대처로 수하물을 찾으러 가는 거리를 더 늘려버려서
마치 수하물이 빨리 나오는 것처럼 느끼게 만든 사례가 있습니다
이처럼 개발로만 모든 문제를 해결할 것이 아니라 기획을 바꾸는 방법도 또 하나의 해결법이 될 수 있습니다
문제 해결에 한 발짝 다가서는 방법
- 본질을 찾고 (핵심 문제 찾기)
- 모순을 해소하고 (대립되는 문제를 둘 다 해결하기)
- 함께 해결한다
(각자가 아닌 ‘우리’ 이며, 네가 해결하면 되잖아 X → 문제는 함께 풀어가는 것 O)
같이 일하기 편한 사람 되기
공격적인 말, 냉소적인 태도로 말할 때마다 멈칫하게 되는 사람은 심리적 안전감을 갖추지 못한 사람이라고 합니다
안된다고’만’ 말해버리면 이 심리적 안전감이 박살나는데, 그것은 곧 비즈니스 가치의 하락으로 이어집니다
심리적 안전감이 있는 사람은 잘 들어주는 사람이며,
잘 들어주는 사람이란 시키는 대로 하는 사람이 아니라 ‘함께 고민하는 사람’이라고 합니다
- 개발자라는 자리를 지키는 선에서 도울 수 있는 방법을 찾기
- NO 라고 외치는 것이 아니다
그러네요.. 제가 어떻게든 해 보겠습니다 (X)
상황은 알겠습니다. 그렇다면 우리 이렇게 한 번 해보는건 어떨까요 (O)
‘같이 일하기 편한 사람’은 모두가 지향하는 목표지만 지키기 어려운 것 같습니다
심리적 안전감이 있는 사람이 되기 위해, 무조건 ‘가능합니다!’를 외쳤던 저인데
그건 심리적 안전감을 주는 사람이 아닌, 나를 버리고 공감한 것에 지나지 않았던 것입니다
문제를 해결하기 위해 함께 고민하고 같이 일하기 편한 사람이 되기!
테오님 블로그에 있었던 내용인데, 강연에서 더 깊은 내용을 들을 수 있어서 좋았습니다
협업도 배워야 한다는 말이 어떤 말인지 실감나는 세션이었습니다
말랑한 분위기에서 스크럼 하기
테오의 스프린트에서 활용하고 있는 피그잼에 대해 늘 궁금했는데,
피그잼을 활용한 말랑한 분위기로 스크럼 하는 방법에 대해 좀 더 구체적인 방법과 내용들도 들을 수 있었습니다
피그잼 스크럼 시간에는 아래와 같은 내용을 매일 정해진 시간에 모여 땡 하면 3분간 가볍게 서술합니다
- 완료한 작업이 있나요?
- 오늘은 뭐 할 건가요?
- 다른 누군가와 협업을 해야할 일이 있나요?
- 안되고 있는 일이 있나요? (blocked)
심지어 낙서도 스티커도 마구 붙여줍니다!
그래서 쭈뼛쭈뼛 불편한 보고가 아닌 스크럼 때 편하고 재밌는 분위기로 보고를 할 수 있게 됩니다
주간 보고는 피그마 AI를 사용해서 AI 요약하기 기능을 사용합니다 (엄청 간편해진다는 장점이!)
이러면 팀장님이 회의에 빠져도 괜찮아지고, 팀원들끼리 돌아가면서 MC가 되어도 좋습니다
주간 보고 역시 짧게 진행하고, 길어도 30분 내에 종료합니다
처음엔 혼자라도 꾸준히 쓰다보면, 나중엔 재밌어서 다들 참여하게 되는 형태가 된다고 합니다
회사에서 이미 데일리 스크럼을 슬랙으로 진행하고 있었는데
테오님께서 제안해주신 방법이 정말 좋은 것 같아서 저희 회사에서도 진행해 보자고 강력히 주장했고
매일 즐겁게 참여하고 있습니다
( 첫 스크럼 사진 )
(누군가 쓴 낙서에 칼같이 달리는 갈고리 2개와 파이리)
스크럼 때 낙서도 하고, 말랑한 분위기가 되어서 팀원들의 반응이 좋습니다!
네트워킹 행사
네트워킹 행사는 처음이었는데, 다른 회사의 프론트엔드 개발자들은 어떻게 일하는지 개발 관련된 이야기를 나누면서 새로운 인사이트를 얻을 수 있어서 좋았습니다.
같은 지역, 같은 업계에서 일하는 사람들의 이야기는 듣는 것만으로도 좋은 에너지를 받아갈 수 있는 것 같습니다. (나는 혼자가 아니야)
그리고 명함을 주신 한 분 께서는 저희 앱 이름을 말씀 드렸을 때 이미 사용 중이라고,
애기 엄마들은 이미 다 잘 쓰고 있다는 분도 계셨습니다
(정말감사해요)
앱을 실제로 사용하고 있다는 이야기는 처음 들어보았는데
더 많은 분들이 ‘저 그 앱 알아요! 잘 쓰고 있어요!’ 라고 얘기할 수 있도록
좋은 비즈니스를 만들고 싶다는 생각이 들었고, 새로운 동기부여가 된 것 같아 정말 좋았습니다!
이번 강연을 통해 참 얻은 것이 많은 것 같습니다
이런 귀한 강연을 볼 수 있게 배려해 주셔서 너무 감사드려요 @팀장님 :)
그리고 앞으로도 ‘개발자 행사’가 있으면 적극적으로 참여해 보려고 합니다
해결사가 되기 위해, 협업을 잘하는 개발자가 되기 위해 더 배우고 정진해 나가겠습니다!
긴 글 읽어주셔서 감사합니다 :)
