Simplify Simplify

불경중 반야심경에 '색증시공 공즉시색(色卽是空 空卽是色)'라는 구절이 있습니다. “공이 색과 다르지 않으며, 색이 곧 공이고 공이 곧 색이다.” 경력 10년이 훌쩍 넘은 유명 포털 출신의 PM으로부터 분기별 프로젝트 목록을 공유 받았을때 Highest Priority가 (공동 1등이) 너무 많아서 위의 이야기를 하면서 우선순위를 임팩트 기준으로 공동 순위가 없이 재조정을 해달라고 피드백을 주었습니다. 개발인력이 동시에 진행할 수 있는 업무 개수는 정해져 있는데 모두 중요하면 무엇부터 시작해야하는지 알 수 없기 때문이었습니다. 최근에 많은 스타트업 분들과 티타임을 가지면서 이야기하는 공통적인 이슈는 밀려드는 업무를 처리하느라 인력이 부족하고, 잦은 야근으로 구성원의 피로도가 높다는 이야기를 듣습니다. 그래..

제가 생각하는 '상위 리더가 하위 리더에게 절대 해서는 안되는 말 Top 3'를 뽑아 봤습니다. 이외에도 많지만 구성원이 뒤도 돌아보지않고 퇴사를 결심하고 실천하게 만드는 정도의 임팩트로 생각하는 말입니다. 1. 나는 당신을 믿지 않습니다. : 이건 한마디로 'You're fired' 와 같은 말입니다. 누구나 이 말을 들은 사람은 이직 준비를 시작합니다. 상호간 신뢰를 기반으로 으쌰으쌰 움직여도 될까말까한 판에 신뢰하지 않는다는 말은 해고 통보와 같은 말입니다. 2. 내가 가이드한대로만 하세요. : 간혹 드라마에서 악덕 상사가 '당신은 생각이란거 하지말고 내가 하라는 거나 똑바로 하세요.'라고 말하는 장면이 있을겁니다. 네, 맞습니다. 같은 말입니다. 이건 구성원이나 동료로서 존중하지 않는 것입니다. ..

전문가들은 데이터는 분석 대상과 목적을 먼저 정하고 데이터를 쌓아야 한다고 합니다. 그런데 현업에서 일하다보면 많은 분들이 데이터를 일단 쌓고 분석 대상을 나중에 생각하는 모습을 자주 목격할 수 있었습니다. 그래서 오늘은 '왜 데이터는 쌓는 것보다 분석 대상을 먼저 정해야 하는지'를 이야기하고자 합니다. 1. 데이터는 많이 쌓는 것보다 필요한 것만 쌓아야 한다. 과거에 PM(Product Manager) 팀 리더가 데이터 적재에 대한 업무를 요청했었습니다. 내용인즉, 모든 화면에 있는 요소(버튼, 텍스트, 페이지)에 대해서 모든 이벤트(클릭, 성공/실패, 이동, 마우스 오버 등)를 로그로 쌓아달라는 것이었습니다. 그래서 우선순위는 차치하더라도 업무의 목적과 효과에 대한 질의응답하는 과정에서 '모든 요소에..

우리는 아주 어렸을 적부터 '평균'이라는 데이터 산출법으로 대화하고 성적에 대한 기준으로 사용합니다. 하지만 성인이되고 직장생활을 하면서 여러 지표를 다룰때도 마찬가지로 평균을 사용합니다. 아마도 20세이상 모든 인류가 피타고라스 정리는 몰라도 평균은 알거라고 생각합니다. ㅎ 오늘 이야기하고 싶은 주제는 '평균으로 인해 빠지기 쉬운 함정'입니다. 학교 성적으로 평균을 사용하는 것은 아무 문제가 없었는데 지표로 평균을 사용할때는 주의해야 한다니... 어떤 이야기인지 알아보시죠. :) 평균이란, '모든 항목의 합을 항목의 개수로 나눈 값입니다.' 즉, 중간값을 구하는 것입니다. 바로 중간값이라는 특성때문에 함정이 빠지는 것이고 자기가 함정에 빠졌는지도 모르고 지나가는 것입니다. 평균이 왜 위험한 것일까요? ..

매니저 생활을 오랫동안 하면서 팀원들이 주니어-미드-시니어가 되는 과정에 갈피를 잡지 못하는 상황을 심심치 않게 볼 수 있었습니다. 조금이나마 오늘도 성장하길 원하는 분들에게 도움이 되고자 실제로 제 팀원들에게 공유한 내용을 공개합니다. 주니어는 Specialist가 되야 합니다. 전체적인 아키텍처보다 특정 Tool, 라이브러리나 Language(Kotlin, Swift등)에 Expert하는 것을 추천드립니다. 물론 아키텍처가 중요하지만, 언어와 라이브러리의 본질을 깨닫고 능숙하게 사용했을때 전체적인 시야가 넓어지면서 아키텍처도 이해하고 볼 수 있습니다. 시스템의 전체적인 부분보다 1~2개의 도메인 영역에 Specialist가 되시길 추천드립니다. ‘이 서비스에서 저 영역은 저 사람을 찾아가라.’ 정도로..

우리는 부지런함을 지상 최고의 덕목으로 삼으라는 교육을 받아왔습니다. 그런데 저는 개발자는 최대한 게을러질 수 있도록 최선을 다해야 한다고 생각합니다. 이것은 일을 하지 말라는 것이 아닙니다. 개발자가 게을러질 수 있는 것은 누구보다 빠르게 하는 방법을 찾고, 단순하고 반복적인 일은 자동으로 할 수 있게 만들 수 있는 직업이기 때문입니다. 게으름뱅이 개발자의 덕목 #1. 궂은 일은 최대한 기계한테 일을 맡기기 매니저로서 팀원들을 평가하다 보면 자기 평가에 CS 운영업무를 많이 처리했다고 자랑스럽게 작성하는 경우를 볼 수 있습니다. 과연 이게 좋은 것일까요? 요즘 가뜩이나 개발자 연봉이 천정부지로 오르고 있는 마당에 ROI가 낮은 업무하느라 중요한 업무를 못했다는 이야기로 해석될 수도 있습니다. 여러분이라..

start.spring.io에서 WebFlux를 다운로드 받아서 기본적인 세팅을 하고 실행하는데 아래 에러가 나온다. 그래서 검색해보니 web과 webflux 모듈이 충돌이 나는듯 하다. 그래서 해결책은 web 제거! 끝. 에러: com.fasterxml.jackson.databind.exc.InvalidDefinitionException: Cannot construct instance of `reactor.core.publisher.Mono` (no Creators, like default constructor, exist): abstract types either need to be mapped to concrete types, have custom deserializer, or contain add..

시스템을 오랫동안 운영하다보면 자연스럽게 모노리스가 됩니다. 얼마 안됐는데 코드가 이렇게 많아졌어? 라고 생각하신다면 비즈니스가 잘 성장하고 있다는 의미입니다. (자축하셔도 좋습니다.) 하지만 기쁜 마음도 잠시, 간단한 수정을 하더라도 어디에 Side Impact가 있을지 몰라 주저하는 마음이 든다면 이미 시스템에는 신호등에 빨간불이 들어왔다고 보셔야 합니다. 유지보수의 효율성이 떨어지고 있다는 이야기니까요. 자. 그럼 어떻게 해야 할까요? 특정 부분을 MSA로 분리할때가 온겁니다. 그럼 Monolith를 MSA로 전환을 계획할때 필요한 세가지를 알아보시죠. 1. 조직장으로 부터 꼭! 리소스 지원을 받아야 합니다. MSA 전환이나 서비스 분리는 리소스와 시간을 많이 요구하는 작업입니다. 디펜던시가 크던 ..