본문 바로가기

분류 전체보기

 (48)
엔지니어링뿐만아니라 리더십도 Full Stack이다. - Full-stack Engineer! Full-stack Leader, too. 리더십은 비전과 목표를 제시하고 구성원들을 이끌어 가는 힘입니다. 유능한 리더는 자신의 영향력을 활용해 구성원들에게 비전을 제시하고 좋은 성과를 만들어냅니다. 리더십에 대한 블로그나 서적들을 읽어보면 '리더십은 서번트, 민주형, 권위주의형등등 여러가지가 있고 각각의 장단점이 있으니 당신에게 맞는거 선택해서 성공하세요.'라는 내용이 대부분입니다. 최근 몇년동안 두 회사에서 여러 조직을 매니징하면서 크게 깨달은 점이 있습니다. 그것은 바로 '리더십도 Full Stack으로 갖춰야 겠다.'라는 것입니다. 말이 쉽지... 리더십을 여러가지로 구사할줄 알아야 한다는 것은 정말로 힘든 일입니다. 카멜레온처럼 엄청난 상황 대처 능력이 필요한 것이죠. 조직, 업무와 특수한 상황이 발생됐을때 해야하는 리더십 스타일을 다..
JPA Entity를 Http Response Dto로 절대 사용하지 말아야 하는 이유 몇몇 개인 블로그에서 JPA Entity를 Http Response로 리턴하는 사례를 보고 이런 Anti-Pattern은 꼭 알려야 겠다는 생각이 들었습니다. 그 잘못된 정보의 포스팅을 보고 개발 업무에 적용하는 사례가 생기면 안되니 꼭 제대로 정정했으면 하는 바램입니다. 왜 Http Response Dto로 Entity를 사용하면 안되는 이유를 알아보시죠. Entity 객체를 Json으로 Serialize할때 Query의 실행으로 시스템 부하가 올라갑니다. Entity Entity 간 양방향으로 Relationship이 걸린경우 무한루프가 발생하면서 시스템이 Down 상태가 됩니다. Entity를 Serialize하기 위해서 추가하는 코드가 아키텍처링 혼선을 만듭니다. Client에 전달해서는 안되는 ..
실시간 데이터 집계 시스템 아키텍처 우리가 사용하는 많은 서비스를 통해 실시간으로 데이터가 집계되는 기능을 매일매일 접하고 있다. 유투브의 라이브 방송에서 시청자 수를 확인한다거나, 게시판 글의 개수처럼 Count를 본다거나 해야할 때다. 그런데 현업에서 오래 일하다 보니 PO/PM Side에서는 '실시간 데이터 집계'라는 기능 자체를 굉장히 쉽게 생각하는 경우가 많아서 구현 난이도에서 발생한 Gap으로 인해 갈등이 일어나거나 PO, PM과 개발자 모두 '실시간 데이터 집계'라는 요구사항에 매몰되서 Over Engineering하는 경우가 많았다. '실시간'이라는 요구사항이 가지는 무게는 생각보다 무겁고, 난이도는 어렵다. 무엇이 중요하고 무엇이 중요하지 않은지 판별할 수 있는 것이 Expert의 역할이고 역량이라고 생각한다. 왜냐하면 실..
Ruthless Prioritization 불경중 반야심경에 '색증시공 공즉시색(色卽是空 空卽是色)'라는 구절이 있습니다. “공이 색과 다르지 않으며, 색이 곧 공이고 공이 곧 색이다.” 경력 10년이 훌쩍 넘은 유명 포털 출신의 PM으로부터 분기별 프로젝트 목록을 공유 받았을때 Highest Priority가 (공동 1등이) 너무 많아서 위의 이야기를 하면서 우선순위를 임팩트 기준으로 공동 순위가 없이 재조정을 해달라고 피드백을 주었습니다. 개발인력이 동시에 진행할 수 있는 업무 개수는 정해져 있는데 모두 중요하면 무엇부터 시작해야하는지 알 수 없기 때문이었습니다. 최근에 많은 스타트업 분들과 티타임을 가지면서 이야기하는 공통적인 이슈는 밀려드는 업무를 처리하느라 인력이 부족하고, 잦은 야근으로 구성원의 피로도가 높다는 이야기를 듣습니다. 그래..
상위 리더가 하위 리더에게 절대 해서는 안되는 말 Top 3 - a.k.a '퇴사를 부르는 한마디' 제가 생각하는 '상위 리더가 하위 리더에게 절대 해서는 안되는 말 Top 3'를 뽑아 봤습니다. 이외에도 많지만 구성원이 뒤도 돌아보지않고 퇴사를 결심하고 실천하게 만드는 정도의 임팩트로 생각하는 말입니다. 1. 나는 당신을 믿지 않습니다. : 이건 한마디로 'You're fired' 와 같은 말입니다. 누구나 이 말을 들은 사람은 이직 준비를 시작합니다. 상호간 신뢰를 기반으로 으쌰으쌰 움직여도 될까말까한 판에 신뢰하지 않는다는 말은 해고 통보와 같은 말입니다. 2. 내가 가이드한대로만 하세요. : 간혹 드라마에서 악덕 상사가 '당신은 생각이란거 하지말고 내가 하라는 거나 똑바로 하세요.'라고 말하는 장면이 있을겁니다. 네, 맞습니다. 같은 말입니다. 이건 구성원이나 동료로서 존중하지 않는 것입니다. ..
데이터는 쌓는 것보다 분석 대상을 먼저 정해야 한다. 전문가들은 데이터는 분석 대상과 목적을 먼저 정하고 데이터를 쌓아야 한다고 합니다. 그런데 현업에서 일하다보면 많은 분들이 데이터를 일단 쌓고 분석 대상을 나중에 생각하는 모습을 자주 목격할 수 있었습니다. 그래서 오늘은 '왜 데이터는 쌓는 것보다 분석 대상을 먼저 정해야 하는지'를 이야기하고자 합니다. 1. 데이터는 많이 쌓는 것보다 필요한 것만 쌓아야 한다. 과거에 PM(Product Manager) 팀 리더가 데이터 적재에 대한 업무를 요청했었습니다. 내용인즉, 모든 화면에 있는 요소(버튼, 텍스트, 페이지)에 대해서 모든 이벤트(클릭, 성공/실패, 이동, 마우스 오버 등)를 로그로 쌓아달라는 것이었습니다. 그래서 우선순위는 차치하더라도 업무의 목적과 효과에 대한 질의응답하는 과정에서 '모든 요소에..
평균(Average)의 함정 - 편차 우리는 아주 어렸을 적부터 '평균'이라는 데이터 산출법으로 대화하고 성적에 대한 기준으로 사용합니다. 하지만 성인이되고 직장생활을 하면서 여러 지표를 다룰때도 마찬가지로 평균을 사용합니다. 아마도 20세이상 모든 인류가 피타고라스 정리는 몰라도 평균은 알거라고 생각합니다. ㅎ 오늘 이야기하고 싶은 주제는 '평균으로 인해 빠지기 쉬운 함정'입니다. 학교 성적으로 평균을 사용하는 것은 아무 문제가 없었는데 지표로 평균을 사용할때는 주의해야 한다니... 어떤 이야기인지 알아보시죠. :) 평균이란, '모든 항목의 합을 항목의 개수로 나눈 값입니다.' 즉, 중간값을 구하는 것입니다. 바로 중간값이라는 특성때문에 함정이 빠지는 것이고 자기가 함정에 빠졌는지도 모르고 지나가는 것입니다. 평균이 왜 위험한 것일까요? ..
각 레벨의 엔지니어에 대한 기대치 매니저 생활을 오랫동안 하면서 팀원들이 주니어-미드-시니어가 되는 과정에 갈피를 잡지 못하는 상황을 심심치 않게 볼 수 있었습니다. 조금이나마 오늘도 성장하길 원하는 분들에게 도움이 되고자 실제로 제 팀원들에게 공유한 내용을 공개합니다. 주니어는 Specialist가 되야 합니다. 전체적인 아키텍처보다 특정 Tool, 라이브러리나 Language(Kotlin, Swift등)에 Expert하는 것을 추천드립니다. 물론 아키텍처가 중요하지만, 언어와 라이브러리의 본질을 깨닫고 능숙하게 사용했을때 전체적인 시야가 넓어지면서 아키텍처도 이해하고 볼 수 있습니다. 시스템의 전체적인 부분보다 1~2개의 도메인 영역에 Specialist가 되시길 추천드립니다. ‘이 서비스에서 저 영역은 저 사람을 찾아가라.’ 정도로..

티스토리툴바