자유로움은 거저 주어지는 것이 아니다. 자유롭게 해보고 싶은 것들을 시도할 기회가 있지만 그런 시도들이 유의미한 결과로 이어 질 수 있도록 주인 의식과 책임감을 갖추려는 분위기가 형성되어 있다. 일련의 활동에 대해 구성원 상호 간에 조직과 법인을 넘어서 익명으로 평가하는 시스템을 통해 반기에 한번씩 상호 리뷰를 하는 것도 그런 움직임의 일환이다.
QA : 프로젝트의 시작부터 끝까지를 계속 함께 확인하고 검증하는 과정
필드테스트 : 이런 기획과 개발 과정을 거치고 나면 게임의 주 타깃 서비스 국가로 출장을 가서 개발한 리소스 다운로드가 제대로 동작하는지 테스트를 해야. 예를들어 네트워크 테스트는 실제 거리를 다니거나 지하철 등을 이용하는 이동 과정에서 게임이 잘 동작하는지를 확인하는 방식으로 진행하며, 이 과정을 필드 테스트라고 부른다. 종일 지하철을 갈아타면서 테스트를 했다.
사내 공모를 통해 경력을 전환하거나 새로운 업무에 도전해 볼 기회를 제공
아마존의 복지 프로그램 : 홈 파인딩 크립과 포장이사부터 배우자 취업까지 초기 정착 지원에 비용과 혜택을 아끼지 않음
기존에 근무시간 위주로, 이메일 중심으로 이뤄졌던 비동기 켜뮤니케이션에서, 수시로 울리는 메신저를 보며 즉각 답하는 실시간 커뮤니케이션으로 전환해야 했는데, 적응하기가 만만치 앖음, 매우 빠르게 이뤄지는 정보 교환과 의사결정이 장점이라면, 업무 집중도가 낮아지고 몰입을 방해한다는 단점이 있음.
인상적인 부분은, 조직 내 시니어 개발자들의 비율이 높고 각자의 전문성 또한 매우 뛰어나다는 것, 서비스에 문제가 발생할 때마다 모든 개발자들이 뛰어들어 이슈를 해결하는 모습과 적극성 또한 인상적, 예를 들어 아파치 톰캣의 스레드가 과도하게 사용되고 있다는 알람이 울렸다고 하자. 보통 2분 이내에 누군가가 알람이 울렸다는 사실을 메신저에 보고한다. 그러면 해당 사실과 연관되는 여러 메트릭에 대한 정보, 스택트레이스 등이 공유된다. 관련된 변경에서 원인을 찾기도 하고 늘어난 트래픽에서 문제를 유추하기도 한다. 토론 끝에 원인에 대한 결론이 나면 필요한 액션 항목을 정리하고 분석을 마친다. 이런 과정을 접하며, 개발자의 성장과 역량 개발의 한 축은 장애와 트러블에 대응하며 문제해결 능력을 키워나가는 데 있지 않나 하는 생각을 하게 되었다.
비트겐슈타인 - 공학적 감수성의 철학
개발에서는 기여contribution에 대한 인정credit이 분명하다.
누구나 직급이나 형식을 따지지 않고 자유롭게 대화하면서도 엄밀하게 옳고 그름을 따지고, 서로 부딪치기도 하면서, 최선의 해결책을 찾아나간다.
당장 밀려드는 문제를 처리하는 데만 급급해하지 않고, 원칙을 되새기며 문서를 유지 보수하는 일은 결코 쉽지 않다.
사소하고 별것 아닌 것처럼 보이는 문제에도 서로 부담 없이 코멘트를 달 수 있다는 사실은 중요하다. '트집 잡지 않는다'는 코드 리뷰가 정착되지 않으면 사소해 보이는 문제들은 쌓이고 쌓여 기술 부채가 될 테고, 팀 전체의 실력을 유지하기는 커녕 눈앞의 문제를 처리하는데 급급한 상황을 마주하게 될 것이다.
많은 위기와 시스템 장애를 겪었지만 지금껏 어떤 한 사람을 콕 집어서 책임을 물었던 적은 없는것 같다. 코드 리뷰를 통해 함께 만들어가는 시스템이기에 문제가 발생하면 우리 모두의 문제였다고 말하는 것이다. 서로를 탓하는 데에 시간을 낭비하지 않고, 다 함께 문제를 빠르게 해결하기 위해 집중한다. 그리고 장애를 해결하고 나면 팀원 전체가 함께하는 커피 타임을 갖거나 저녁 번개 회식을 하면서 더 나은 내일을 준비한다.
특허 출원을 위해 아이디어를 A4 한두 장 정도로 정리해서 사내 특허팀에 전달했다. 특허팀에서는 내가 복잡한 행정적인 절차에 대해 신경쓰지 않고 본업인 개발 업무에만 집중 할 수 있도록 모든 과정을 알아서 착착 진행해 주었고… 커피 타임에서 평소와 크게 다를 바 없이 툭 던진 아이디어가 특허로 출원…
기술적 도전을 느끼는 순간이 많은데, 이런 경우 문제를 해결해야 하다 보니 평소에도 기술 블로그나 뉴스를 꾸준히 읽으며 노력하는 편이다. 내가 더 공부해야 할 것이 있거나 기술적인 고민이 있을 때 언제든지 부담 없이 질문하고 논의할 수 있는 환경이 있다는 것도 성장에 많은 도움이 되는거 같다.
최근에는 많은 회사가 기술 블로그를 운영하고 있다. 큰 기업뿐만 아니라 많은 스타트업도 기술 블로그를 운영하고 있으니 관심있는 서비스를 운영하는 회사의 기술 블로그를 찾아보면 도움이 된다. 최근에는 awesome-devblog처럼 여러 기술 블로그 글을 일괄적으로 모아서 피드로 제공하거나 이메일로 발송해주는 형태의 서비스도 여럿 있다. 기술적 깊이뿐만 아니라 시야도 넓힐 수 있는 방법이다.
개발자의 이론적 배경을 탄탄하게 만드는 데에는 책이 좋은것 같다. 해당 이론 또는 기술에 대한 윤곽을 쉽게 잡을 수 있기 때문이다. 새로운 기술을 접할 때 책을 먼저 한번 보고, 기술 문서를 보거나 코드에 접근하면 내가 지금 파보고 있는 코드가 어느 영역에 해당하는 것인지, 그리고 고민해야 하는 영역이 어떤 것인지 쉽게 알 수 있다.
신규자는 온보딩 문서에 따라 진행하면서 정상 동작하지 않는 부분이 있거나, 새 버전이 나오면서 바뀐 부분이 있다면 수정을 부탁한다. 그렇게 차곡차곡 쌍인 문서가 이제 팀 위키에 어느 정도 갖춰져 있다.
또한, 빠르게 변하는 개발 환경에 좀 쉽게 적응하도록 매주 뉴스레터를 보내고 있다. 사실 거창하게 생각하고 시작한 일은 아닌데, 예전에 개인적으로 몇 번 지인들에게 한 주간 읽었던 기술 관련 글 중 괜찮았던 글 링크와 간단한 한 줄 요약을 보내자 반응이 괜찮았다. 그래서 한 주간 구독 중인 글 중 다른 사람들도 읽어 볼 만 하다고 생각하는 링크를 모아 주간 뉴스레터를 보내고 있다.
7천명 이상의 인원 근무 하지만 정말 고객이 원하는 것이 무엇인지를 최우선시 하고, 데이터를 기반으로 고객의 반응을 확인하며, 빠르게 도전하고 실패하더라도 바로 일어나서 다시 시작할 기회를 충분히 주는 것이 장점
버그 바운티 : 소프트웨어의 보안 취약점을 발견해 벤더에게 리포트를 하면 그에 대한 상금을 받는 것
회사 전반 문서화가 잘 되었을 때의 장점 : 회사 내 정보 중 휘발 되는 것이 없기 때문에 회사 내 활동 경험이 집단적으로 축적 될 수 있다. 충실한 문서화의 두 번째 장점은 써보는 문화와 함께 찾아보는 문화 또한 발달하게 된다는 점이다.
Evangelist의 사전적인 의미는 '전도사'이다. 그래서 테크 에반젤리스트를 '기술 전도사'로 옮기기도 한다.
변화하는 소프트웨어 업계에서 계속 배우고 자신을 성장시킬 유용한 방법 중 하나가 기술 공유 활동이다. 기술 블로그를 운영하면서 알게 된 점은, 내가 잘 알고 있다고 생각했던 것들도 글로 남기기 위해 더 많은 공부를 하게 된다는 것이다. 단편적으로 알고 있던 내용을 글로 적다 보면 하나의 맥락으로 연결시키게 되면서 더 잘 기억에 남게 된다.
크고 작은 기술 행사를 열거나 기술 블로그 운영을 통해 회사의 기술과 개발 문화를 알리고, 개발자 커뮤니티 후원 활동도 지원한다. 내부적으로는 사내 개발자 교육 프로그램을 통해 개발자들의 스킬 계발을 돕거나 개발자들이 함께 즐길 수 있는 개발 문화를 만들고 있다. 또한 일하는 방법 개선, 다양한 도구(이슈 추적도구, 빌드 도구, 테스트 도구 등) 간리, 인프라 지원 및 컨설팅 등 개발 프로세스의 낭비를 줄이고 자동화하여 개발자들이 안정적으로 개발에 집중하게끔 하는 DevOps 기능도 활발하게 진행하고 있다.
[참고도서] 나는 LINE 개발자입니다.