토스 코어의 프론트엔드 챕터는 80명이 넘는 많은 분들이 함께 일하고 있는데요. 조직 운영을 유기적으로 하고 모든 구성원들이 긴밀하게 협업할 수 있도록 챕터 리드가 많은 역할을 하고 있답니다. 🙋‍♂️이 아티클에서는 프론트엔드 챕터 리드에 대해 궁금해하실만한 질문 10개에 대해서, 실...

토스 프론트엔드 챕터 리드는 어떤 역할인가요?

토스의 챕터 리드는 동일한 도메인을 가진 여러 사일로 개발자들(대여섯 명)이 모여 기술을 교류하는 역할을 담당합니다. 이들은 프론트엔드 개발 조직을 설계하고, 채용 및 1:1 미팅을 통해 구성원의 니즈를 파악하여 최적의 위치에 배치하는데요. 또한, 협력적이고 생산적인 작업 환경을 조성한다고 합니다.

챕터 리드로서의 기여 사례
 * 1:1 미팅: 개발 과정을 회고하고 잘한 점과 아쉬운 점을 논의합니다. 액션 아이템을 설정한 후 체크리스트를 구성원들이 직접 만들도록 제안합니다.
 * 신규 기능 개발: 체크리스트를 함께 돌아보며 점검합니다.

구성원 성장을 위한 노력
 * 코드 리뷰 문화: 꼼꼼한 코드 리뷰 문화를 조성합니다.
 * 심적 안정: 구성원들이 심리적으로 안정감을 느낄 수 있도록 지원합니다.
 * 주기적 1:1 미팅: 성장 방향을 파악하고 적절한 팀 배치를 합니다.

챕터 간 교류
온/오프라인을 통해 자주 소통하고 스터디를 진행합니다. 한 달에 최소 두 번은 미팅과 식사
자리를 마련하여 친밀감을 쌓고 조직 운영 현황을 리뷰합니다.

리드로서의 보람
스스로 문제를 해결할 수 있도록 돕는 것이 가장 중요합니다. 이를 통해 회사에 대한 기여의 폭이 훨씬 넓어집니다.
업무와 리딩 시간 관리 방법
 * 업무 집중 시간: 점심시간 전에는 혼자 하는 일들을 처리합니다. 커뮤니케이션은 주로 오후에 진행합니다.
 * 예측 가능성: 점심 시간 이후에는 마무리한 일들이 많아 조급함이 덜합니다.
 * 업무 시각화: 우선순위를 정렬하고 업무 처리 정도를 예측합니다.

리드의 역할은 단순히 뛰어난 개발 능력을 넘어서는 복합적인 리더십을 요구합니다. 프로젝트의 성공적인 수행, 팀원 개개인의 성장 촉진, 그리고 건강한 팀 문화 조성을 포괄하는데요. 이러한 리더십 요소들은 현재 리드 포지션에 있지 않다고 하더라도 중요한 지향점이 되는것 같습니다.

좀 더 자세한 토스의 프론트엔드 리드의 역할에 대해 더 알고 싶으신 분은 원문 게시글을 확인해 보시길 권장드립니다.

https://toss.im/career/article/28734

토스의 챕터 리드는 동일한 도메인을 가진 여러 사일로 개발자들(대여섯 명)이 모여 기술을 교류하는 역할을 담당합니다. 이들은 프론트엔드 개발 조직을 설계하고, 채용 및 1:1 미팅을 통해 구성원의 니즈를 파악하여 최적의 위치에 배치하는데요. 또한, 협력적이고 생산적인 작업 환경을 조성한다고 합니다. 챕터 리드로서의 기여 사례<ul ><li>1:1 미팅: 개발 과정을 회고하고 잘한 점과 아쉬운 점을 논의합니다. 액션 아이템을 설정한 후 체크리스트를 구성원들이 직접 만들도록 제안합니다.</li><li>신규 기능 개발: 체크리스트를 함께 돌아보며 점검합니다.</li></ul> 구성원 성장을 위한 노력<ul ><li>코드 리뷰 문화: 꼼꼼한 코드 리뷰 문화를 조성합니다.</li><li>심적 안정: 구성원들이 심리적으로 안정감을 느낄 수 있도록 지원합니다.</li><li>주기적 1:1 미팅: 성장 방향을 파악하고 적절한 팀 배치를 합니다.</li></ul> 챕터 간 교류온/오프라인을 통해 자주 소통하고 스터디를 진행합니다. 한 달에 최소 두 번은 미팅과 식사 자리를 마련하여 친밀감을 쌓고 조직 운영 현황을 리뷰합니다. 리드로서의 보람스스로 문제를 해결할 수 있도록 돕는 것이 가장 중요합니다. 이를 통해 회사에 대한 기여의 폭이 훨씬 넓어집니다.업무와 리딩 시간 관리 방법<ul ><li>업무 집중 시간: 점심시간 전에는 혼자 하는 일들을 처리합니다. 커뮤니케이션은 주로 오후에 진행합니다.</li><li>예측 가능성: 점심 시간 이후에는 마무리한 일들이 많아 조급함이 덜합니다.</li><li>업무 시각화: 우선순위를 정렬하고 업무 처리 정도를 예측합니다.</li></ul> 리드의 역할은 단순히 뛰어난 개발 능력을 넘어서는 복합적인 리더십을 요구합니다. 프로젝트의 성공적인 수행, 팀원 개개인의 성장 촉진, 그리고 건강한 팀 문화 조성을 포괄하는데요. 이러한 리더십 요소들은 현재 리드 포지션에 있지 않다고 하더라도 중요한 지향점이 되는것 같습니다. 좀 더 자세한 토스의 프론트엔드 리드의 역할에 대해 더 알고 싶으신 분은 원문 게시글을 확인해 보시길 권장드립니다. https://toss.im/career/article/28734

Toss

토스 챕터 리드의 역할과 책임: 프론트엔드 개발팀 리딩

카일스쿨 | Google Analytics 4, Firebase 데이터의 형태의 앱 로그 분석을 진행합니다. 배열, 윈도우 함수, 퍼널, 리텐션, Google Sheets 등 실무에서 사용할 때 유용한 내용들을 담았습니다., Google Analytics 4, Fireba

BigQuery(SQL) 활용편(퍼널 분석, 리텐션 분석) 강의 | 카일스쿨 - 인프런

안녕하세요.

초보자를 위한 BigQuery 강의를 출시한지 4개월이 지났네요. 강의 질문에도 자주 있었는데, 많은 분들이 기다려주신 활용편이 드디어 나왔어요.

활용편은 앱 로그 데이터를 기반으로 퍼널 분석, 리텐션 분석을 진행해요. 이 과정에서 BigQuery의 심화라고 할 수 있는 배열, 윈도우 함수를 집중적으로 학습합니다. 더불어 BigQuery에서 유용한 기능이였던 스케줄 쿼리, 절차적 언어, JSON 함수, UDF 등도 알려드려요!

https://inf.run/QVgPf

안녕하세요. 초보자를 위한 BigQuery 강의를 출시한지 4개월이 지났네요. 강의 질문에도 자주 있었는데, 많은 분들이 기다려주신 활용편이 드디어 나왔어요. 활용편은 앱 로그 데이터를 기반으로 퍼널 분석, 리텐션 분석을 진행해요. 이 과정에서 BigQuery의 심화라고 할 수 있는 배열, 윈도우 함수를 집중적으로 학습합니다. 더불어 BigQuery에서 유용한 기능이였던 스케줄 쿼리, 절차적 언어, JSON 함수, UDF 등도 알려드려요! https://inf.run/QVgPf

인프런

BigQuery 활용편(배열, 퍼널 분석, 리텐션 분석) 강의 런칭

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다.

죽을 만큼 힘든 날은 없었다

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일.
이제 20년이 지났습니다.

돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다.

매일 조금씩 힘들고 피곤하긴 했지만..
죽을 만큼 힘들다고 생각해 본 날은 없습니다.

마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까?

저에게는 그런 날은 하루도 없었던 것입니다.
이 정도면 뭐 할만한 것 아닌가?

죽을 만큼 힘들게 훈련하진 않더라도,
(그렇게 해야 세계 챔피언이 될 수 있나 봅니다)
적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다.
왜냐면 그것조차 할 수 있는 사람이 별로 없으니까.

이걸 알고 나서 마음이 참 편해졌습니다.
난 분명히 잘될 거야.
더 즐기면서 일할 수 있게 되었습니다.

https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

컴퓨터 공부를 처음 시작한 날이 2004년 8월 25일. 이제 20년이 지났습니다. 돌아보면 그렇게 쉽진 않았지만 또 그렇게 어렵지도 않았던 것 같습니다. 매일 조금씩 힘들고 피곤하긴 했지만.. 죽을 만큼 힘들다고 생각해 본 날은 없습니다. 마라톤 금메달리스트 황영조 선수가 훈련 중에 자동차가 지나가면 그 바퀴 밑으로 뛰어들어 죽고 싶었다고 말했던 걸 기억합니다. 도대체 어느 정도 힘들어야 죽어버리는 게 낫겠다는 생각을 할 수 있을까? 저에게는 그런 날은 하루도 없었던 것입니다. 이 정도면 뭐 할만한 것 아닌가? 죽을 만큼 힘들게 훈련하진 않더라도, (그렇게 해야 세계 챔피언이 될 수 있나 봅니다) 적당한 훈련을 매일 오랫동안 해나가면 인생을 편안하게 살 만큼의 성취 정도는 이룰 수 있다는 걸 나중에야 알게 됐습니다. 왜냐면 그것조차 할 수 있는 사람이 별로 없으니까. 이걸 알고 나서 마음이 참 편해졌습니다. 난 분명히 잘될 거야. 더 즐기면서 일할 수 있게 되었습니다. https://jeho.page/essay/2024/07/17/not-easy-but-not-hard-either.html

K리그 프로그래머

깊은 생각을 하게 하는 글입니다. 저도 본받고 싶습니다.

이력서는 중요합니다.
면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다.

이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.
resumemaker.online 인데요.

기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.
컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다.

한가지 단점은 한글 폰트를 지원하지 않습니다.
그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는
것도 좋을 것 같습니다.

제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서는 중요합니다.면접관에게는 지원자를 파악하기 위한 첫번째 장소이기 때문입니다. 이런 이력서 작성을 편리하게 도와주는 사이트가 있어서 소개드립니다.resumemaker.online 인데요. 기존에 작성한 이력서가 있다면 업로드해서 AI가 초안을 작성해주기도 합니다.컬러나 템플릿등을 설정할 수 도 있고, 꽤 정돈된 형태로 이력서가 나오게 됩니다. 한가지 단점은 한글 폰트를 지원하지 않습니다.그래도 이력서 작성을 별로 해보시지 않았다면 툴의 도움을 받아서 채워보시는것도 좋을 것 같습니다. 제가 기존에 써둔 이력서를 업로드 해서 만들어봤는데 퀄리티가 나쁘지 않네요.

이력서를 편하게 만듭시다 - resumemaker

코드를 읽다 보면 이 속성(prop)이 어디서 온 건지 궁금할 때가 있습니다. 그럴 땐 속성을 선택하고 아래 단축키를 누르면 속성 이름을 기반으로 빠르게 검색해 줍니다. 특히 TypeScript를 사용하고 있으면 IDE가 똑똑하게 타입 기반으로 속성이 선언된 곳을 찾아주기 때문에 좀 더 정확도가 높습니다.

Webstorm
 * 맥: Command + B
 * 윈도우: Ctrl + B
VSCode
 * 맥: F12
 * 윈도우: F12

실제 작업할 때 예시를 알려드리면, 컴포넌트 상단에 정의된 Props 인터페이스에서 필드명을 더블클릭하고 Command + B를 누릅니다. 그럼 이 속성을 전달하는 부모 컴포넌트를 보여주는데, 해당 항목을 클릭하고 다시 Command + B를 눌러서 그 속성을 전달하는 부모 컴포넌트를 다시 찾아갑니다. 이 과정을 반복해서 속성이 어디서 왔는지 빠르게 찾을 수 있습니다.
interface ButtonProps {
 onClick: () => void;
 // 1. 요기에 커서 올려놓고 단축키 입력
}

interface ButtonContainerProps {
 onClick: () => void;
 // 3. 요기에 커서 올려놓고 단축키 입력
}

const ButtonContainer = ({ onClick }: ButtonContainerProps) => {
 // Blah Blah

 return (
 <Button onClick={onClick} />
 // 2. 요기에 커서 올려놓고 단축키 입력
 )
}

이 방법은 컴포넌트 깊이가 어느정도 있는 구조에서 특히 유용한 것 같습니다.

코드를 읽다 보면 이 속성(prop)이 어디서 온 건지 궁금할 때가 있습니다. 그럴 땐 속성을 선택하고 아래 단축키를 누르면 속성 이름을 기반으로 빠르게 검색해 줍니다. 특히 TypeScript를 사용하고 있으면 IDE가 똑똑하게 타입 기반으로 속성이 선언된 곳을 찾아주기 때문에 좀 더 정확도가 높습니다. Webstorm<ul ><li>맥: Command + B</li><li>윈도우: Ctrl + B</li></ul>VSCode<ul ><li>맥: F12</li><li>윈도우: F12</li></ul> 실제 작업할 때 예시를 알려드리면, 컴포넌트 상단에 정의된 Props 인터페이스에서 필드명을 더블클릭하고 Command + B를 누릅니다. 그럼 이 속성을 전달하는 부모 컴포넌트를 보여주는데, 해당 항목을 클릭하고 다시 Command + B를 눌러서 그 속성을 전달하는 부모 컴포넌트를 다시 찾아갑니다. 이 과정을 반복해서 속성이 어디서 왔는지 빠르게 찾을 수 있습니다.<pre ><code class="language-tsx">interface ButtonProps {
 onClick: () =&gt; void;
 // 1. 요기에 커서 올려놓고 단축키 입력
}</code></pre><pre ><code class="language-tsx">interface ButtonContainerProps {
 onClick: () =&gt; void;
 // 3. 요기에 커서 올려놓고 단축키 입력
}

const ButtonContainer = ({ onClick }: ButtonContainerProps) =&gt; {
 // Blah Blah

 return (
 &lt;Button onClick={onClick} /&gt;
 // 2. 요기에 커서 올려놓고 단축키 입력
 )
}</code></pre>이 방법은 컴포넌트 깊이가 어느정도 있는 구조에서 특히 유용한 것 같습니다.

React 컴포넌트 prop이 어디서 왔는지 쉽게 찾는 꿀팁

처음 써보는데 많이 유용하네요.
나중에는 점진적 이외에도 한번에 찾을 수 있는 방법이 나오면 좋겠네요.

실리콘밸리 관련해서 종종 듣는 질문들 중에 다음과 같은 것들이 있다.

 * 실리콘밸리 개발자들은 얼마나 뛰어난가요?
 * 제가 가면 경쟁할 수 있나요?
   
   
과연 사람이 다른 걸까? 환경이 다른 걸까? 물론 실리콘밸리에는 세계각국에서 좋은 인재들이 몰려든다. 하지만 이 인재라는 정의에는 포함되는 중요한 포인트 하나는 "도전"하는 사람들이 온다는 점이다. 일단 그 부분을 인지하는 것이 중요하다. 지금 내가 사는 나라에서 부족함을 못 느끼거나 도전에 관심이 없는 사람이라면 굳이 모험을 하지 않는다.

한국에서 학사, 석사 마치고 5년 일하고 미국에서 24년째 일하고 있다. 지난 2년 동안 한국 회사("그렙")에서 일을 해보고 굉장히 많은 한국 개발자 및 IT 인력과 접점이 생기면서 어떤 부분이 다른지 좀더 이해하게 되었다. 한국에 계신 분들께 조금 아쉬운 부분들은 아래와 같은 포인트들인데 이건 개인이 가진 문제라기 보다는 사회 전반적인 아쉬움이라 생각된다. 결국은 나이에 관한 부담과 수능으로 제2의 천성이 되어버린 선행학습이 문제가 아닌가 싶다.

조금더 구체적으로 내가 느낀 아쉬움을 적어보면 아래와 같다. 이는 실리콘밸리에는 전혀 존재하지 않는 것들이라고 하면 거짓말이고 상대적으로 한국에서 더 많이 보인다는 거다.

 1. 기술 지향적 (전문성 트랩)
 2. 부캐에 관한 조바심
 3. 대기업에 관한 너무 큰 기대

하나씩 이야기해보자

기술 지향적 (전문성 트랩)

나에게 맞는 환경을 찾아 현재에 집중하기 보다는 전문성이라는 트랩에 빠져 본인이 맡은 일을 어떻게 잘 할까 고민하고 거기에 필요한 일을 학습하기 보다는 유행의 선두에 서서 새로 생기는 기술을 맹목적으로 알고 싶어한다. 이는 끝이 없기에 이 트랩에 빠지면 삶이 아주 고단해지고 항상 뒤쳐진다는 두려움과 조바심을 갖게 된다. 더 큰 문제는 뜨는 기술을 안다는 것이 내 커리어를 더 안전하게 만들고 행복하게 만들지 않는다는 점이다. 다른 사람들과 소통할 줄 알고 결과를 내고 좋은 평판을 만들고 영향력을 갖는 것이 내 커리어를 안전하게 만들고 행복하게 만드는 지름길 아닌 지름길이다.

부캐에 관한 조바심

SNS의 폐해가 아닌가 싶은데 나 빼고 모든 사람들이 뭔가 부캐를 하고 있고 본캐만 믿고 살면 미래가 너무 불안하다는 생각을 많이 한다. 커리어 초반에는 사실 부캐를 하고 싶어도 부캐를 할 경험치가 있기 힘들다. 정말 해보고 싶은 부캐가 있다면 그걸 본캐로 열심히 해보는 것이 맞지 않나 싶다. "질투", "시기", "부러움"은 가장 나쁜 감정이며 이는 비교로부터 시작한다. 이런 감정을 떨구기 쉽지 않고 이런 감정은 사실 실리콘밸리에 살면 더 심하게 드는 감정이기도 하지만 적어도 실리콘밸리에 부캐에 대한 열풍이 있다고 생각하지는 않는다.

대기업에 관한 너무 큰 기대

대기업을 가지 말라는 이야기가 아니다. 능력이 되면 가서 나에게 맞는지 판단하면 된다. 문제가 되는 부분은 마치 대기업을 가면 내 커리어가 완성될 꺼라 너무 큰 기대를 하는 거다. 기대가 크면 실망도 크다. 인생의 행복은 기대 관리다. 이는 사람에 대한 기대일 수도 있고 내가 하는 일에 대한 기대일 수도 있다. 긴 커리어에서 대기업이건 아주 작은 스타트업이건 내가 앞으로 다닐 10-20개 회사들 중의 하나일 뿐 그 이상도 그 이하도 아니다. 내 커리어를 완성시킬 수 있는 것은 나 자신이며 평정심과 꾸준함이 중요한 이유다.

요약하자면 개인이 갖고 있는 능력이 실리콘밸리에서 일하는 사람들이 더 뛰어나다고 생각하지 않는다. 다만 도전하는 사람들이 모이는 곳이며 실패를 인정하고 다양성을 존중하는 환경이다 보니 나이를 덜 생각하고 공부로 승부보기 보다는 행동으로 승부를 보려는 사람들이 많다는 점이 다를 뿐이다. 즉 환경이 다른 것이다.

혹시라도 내가 나이가 많다고 느껴지거나, 뭔가 문제가 생기면 공부를 통해 해결하겠다라는 생각이 먼저 든다면 그 부분을 이제부터 의식적으로 고쳐볼 필요가 있으며 이는 환경을 바꾸면 쉽게 변할 수 있는 부분이다.

관련 유튜브 영상을 만들었는데 댓글 참고

실리콘밸리 관련해서 종종 듣는 질문들 중에 다음과 같은 것들이 있다. <ul ><li>실리콘밸리 개발자들은 얼마나 뛰어난가요?</li><li>제가 가면 경쟁할 수 있나요? </li></ul>과연 사람이 다른 걸까? 환경이 다른 걸까? 물론 실리콘밸리에는 세계각국에서 좋은 인재들이 몰려든다. 하지만 이 인재라는 정의에는 포함되는 중요한 포인트 하나는 "도전"하는 사람들이 온다는 점이다. 일단 그 부분을 인지하는 것이 중요하다. 지금 내가 사는 나라에서 부족함을 못 느끼거나 도전에 관심이 없는 사람이라면 굳이 모험을 하지 않는다. 한국에서 학사, 석사 마치고 5년 일하고 미국에서 24년째 일하고 있다. 지난 2년 동안 한국 회사("그렙")에서 일을 해보고 굉장히 많은 한국 개발자 및 IT 인력과 접점이 생기면서 어떤 부분이 다른지 좀더 이해하게 되었다. 한국에 계신 분들께 조금 아쉬운 부분들은 아래와 같은 포인트들인데 이건 개인이 가진 문제라기 보다는 사회 전반적인 아쉬움이라 생각된다. 결국은 나이에 관한 부담과 수능으로 제2의 천성이 되어버린 선행학습이 문제가 아닌가 싶다. 조금더 구체적으로 내가 느낀 아쉬움을 적어보면 아래와 같다. 이는 실리콘밸리에는 전혀 존재하지 않는 것들이라고 하면 거짓말이고 상대적으로 한국에서 더 많이 보인다는 거다. <ol ><li>기술 지향적 (전문성 트랩)</li><li>부캐에 관한 조바심</li><li>대기업에 관한 너무 큰 기대</li></ol> 하나씩 이야기해보자 기술 지향적 (전문성 트랩) 나에게 맞는 환경을 찾아 현재에 집중하기 보다는 전문성이라는 트랩에 빠져 본인이 맡은 일을 어떻게 잘 할까 고민하고 거기에 필요한 일을 학습하기 보다는 유행의 선두에 서서 새로 생기는 기술을 맹목적으로 알고 싶어한다. 이는 끝이 없기에 이 트랩에 빠지면 삶이 아주 고단해지고 항상 뒤쳐진다는 두려움과 조바심을 갖게 된다. 더 큰 문제는 뜨는 기술을 안다는 것이 내 커리어를 더 안전하게 만들고 행복하게 만들지 않는다는 점이다. 다른 사람들과 소통할 줄 알고 결과를 내고 좋은 평판을 만들고 영향력을 갖는 것이 내 커리어를 안전하게 만들고 행복하게 만드는 지름길 아닌 지름길이다. 부캐에 관한 조바심 SNS의 폐해가 아닌가 싶은데 나 빼고 모든 사람들이 뭔가 부캐를 하고 있고 본캐만 믿고 살면 미래가 너무 불안하다는 생각을 많이 한다. 커리어 초반에는 사실 부캐를 하고 싶어도 부캐를 할 경험치가 있기 힘들다. 정말 해보고 싶은 부캐가 있다면 그걸 본캐로 열심히 해보는 것이 맞지 않나 싶다. "질투", "시기", "부러움"은 가장 나쁜 감정이며 이는 비교로부터 시작한다. 이런 감정을 떨구기 쉽지 않고 이런 감정은 사실 실리콘밸리에 살면 더 심하게 드는 감정이기도 하지만 적어도 실리콘밸리에 부캐에 대한 열풍이 있다고 생각하지는 않는다. 대기업에 관한 너무 큰 기대 대기업을 가지 말라는 이야기가 아니다. 능력이 되면 가서 나에게 맞는지 판단하면 된다. 문제가 되는 부분은 마치 대기업을 가면 내 커리어가 완성될 꺼라 너무 큰 기대를 하는 거다. 기대가 크면 실망도 크다. 인생의 행복은 기대 관리다. 이는 사람에 대한 기대일 수도 있고 내가 하는 일에 대한 기대일 수도 있다. 긴 커리어에서 대기업이건 아주 작은 스타트업이건 내가 앞으로 다닐 10-20개 회사들 중의 하나일 뿐 그 이상도 그 이하도 아니다. 내 커리어를 완성시킬 수 있는 것은 나 자신이며 평정심과 꾸준함이 중요한 이유다. 요약하자면 개인이 갖고 있는 능력이 실리콘밸리에서 일하는 사람들이 더 뛰어나다고 생각하지 않는다. 다만 도전하는 사람들이 모이는 곳이며 실패를 인정하고 다양성을 존중하는 환경이다 보니 나이를 덜 생각하고 공부로 승부보기 보다는 행동으로 승부를 보려는 사람들이 많다는 점이 다를 뿐이다. 즉 환경이 다른 것이다. 혹시라도 내가 나이가 많다고 느껴지거나, 뭔가 문제가 생기면 공부를 통해 해결하겠다라는 생각이 먼저 든다면 그 부분을 이제부터 의식적으로 고쳐볼 필요가 있으며 이는 환경을 바꾸면 쉽게 변할 수 있는 부분이다. 관련 유튜브 영상을 만들었는데 댓글 참고

실리콘밸리 개발자 vs. 한국 개발자

Built with Notion, the all-in-one connected workspace with publishing capabilities.

무엇이 궁금한가요? | Notion

안녕하세요,
스타트업에서 PO로 일하고 있는 루트입니다.

제가 4년째 하고 있는 개인 프로젝트 중 하나가 '한 달에 한 편' 글쓰기입니다.
일하면서 했던 고민, 생각, 느낀 점들을 글로 정리하는 것입니다.

최근에 한 세미나에서 'Help others'라는 키워드를 듣고, 제 글을 되돌아보게 되었습니다.

'여태껏 내가 하고 싶은 말만 한 것은 아닌가?'

그래서 39회 글쓰기는 사람들에게 도움 되는, 정말 필요한 글을 써보기로 결심하고,
PM/PO Private Talk으로 진행해보려 합니다.

PM/PO Private Talk는 무엇인가요?
PM/PO와 관련된 질문을 남겨주시면, 제가 답변을 드리는 QnA 입니다.

질문 제목은 오픈되고, 내용은 공개되지 않습니다. 답변은 개인 이메일로 드립니다.

이렇게 하는 이유는, 고민이 있어도 공개적인 공간에 질문을 남기기 부담스러워할 분들의 마음을 덜어드리고 싶고, 저도 성심성의껏 답변을 드리기 위해서는 오픈된 곳에서 말하기 어려운 부분들도 있을 것 같다고 생각했습니다.
(이메일 정보는 프로젝트 외 다른 곳에 절대 이용하지 않습니다)

제 소개를 드리자면,
저는 6년차 PO이고, 제 강점은 '다양함'입니다.
 * 회사 : 스타트업 A~C 단계를 모두 거쳐 기업의 흥망성쇠를 겪었습니다.
 * 제품 : 제품 라이프사이클(0to1, 1to100)마다 필요한 제품 개발 전략 및 플랫폼, 커머스, SaaS, H/W 등 다양한 제품을 경험했습니다.
 * 역할 : 서비스기획자, 기획팀 팀장, PO(Squad Lead) 등의 직함으로 조직에 기여했습니다.
 * 산업 : 에너지, 화훼, 자동차 산업을 겪으며 시장 구조를 빠르게 파악하는 법을 익혔습니다.

스타트업의 제품, 역할, 조직구조, 문화와 관련된 질문은 답변을 잘 드릴 수 있을 것 같습니다.

대기업, 유니콘, 빅테크, 외국계 회사를 겪어보지 못해 그와 관련된 답변이 조금은 부족할 수 있는 점 양해 부탁드립니다. 그래도 제가 귀동냥으로 들은 것을 다 끌어모아 말씀 드리겠습니다.

꼭 PM/PO와 관련되지 않더라도 커리어, 직장 내 커뮤니케이션, 이직 등 궁금한 것이 있다면 편하게 작성하셔도 됩니다.

마지막으로..
질문 하나하나 깊이 고민하여 작성합니다만, 제 최선의 답변이 정답은 아닙니다. 질문자님의 고민을 해결할 수 있는 힌트가 되길 바라는 마음입니다. 기한은 6/19(수)까지 열어두겠습니다.

감사합니다

⬇️PM/PO Private Talk 참여하기⬇️
https://shorturl.at/grLpi

안녕하세요,스타트업에서 PO로 일하고 있는 루트입니다. 제가 4년째 하고 있는 개인 프로젝트 중 하나가 '한 달에 한 편' 글쓰기입니다. 일하면서 했던 고민, 생각, 느낀 점들을 글로 정리하는 것입니다. 최근에 한 세미나에서 'Help others'라는 키워드를 듣고, 제 글을 되돌아보게 되었습니다. '여태껏 내가 하고 싶은 말만 한 것은 아닌가?' 그래서 39회 글쓰기는 사람들에게 도움 되는, 정말 필요한 글을 써보기로 결심하고, PM/PO Private Talk으로 진행해보려 합니다. PM/PO Private Talk는 무엇인가요?PM/PO와 관련된 질문을 남겨주시면, 제가 답변을 드리는 QnA 입니다. 질문 제목은 오픈되고, 내용은 공개되지 않습니다. 답변은 개인 이메일로 드립니다. 이렇게 하는 이유는, 고민이 있어도 공개적인 공간에 질문을 남기기 부담스러워할 분들의 마음을 덜어드리고 싶고, 저도 성심성의껏 답변을 드리기 위해서는 오픈된 곳에서 말하기 어려운 부분들도 있을 것 같다고 생각했습니다. (이메일 정보는 프로젝트 외 다른 곳에 절대 이용하지 않습니다) 제 소개를 드리자면,저는 6년차 PO이고, 제 강점은 '다양함'입니다.<ul ><li>회사 : 스타트업 A~C 단계를 모두 거쳐 기업의 흥망성쇠를 겪었습니다.</li><li>제품 : 제품 라이프사이클(0to1, 1to100)마다 필요한 제품 개발 전략 및 플랫폼, 커머스, SaaS, H/W 등 다양한 제품을 경험했습니다.</li><li>역할 : 서비스기획자, 기획팀 팀장, PO(Squad Lead) 등의 직함으로 조직에 기여했습니다.</li><li>산업 : 에너지, 화훼, 자동차 산업을 겪으며 시장 구조를 빠르게 파악하는 법을 익혔습니다.</li></ul> 스타트업의 제품, 역할, 조직구조, 문화와 관련된 질문은 답변을 잘 드릴 수 있을 것 같습니다. 대기업, 유니콘, 빅테크, 외국계 회사를 겪어보지 못해 그와 관련된 답변이 조금은 부족할 수 있는 점 양해 부탁드립니다. 그래도 제가 귀동냥으로 들은 것을 다 끌어모아 말씀 드리겠습니다. 꼭 PM/PO와 관련되지 않더라도 커리어, 직장 내 커뮤니케이션, 이직 등 궁금한 것이 있다면 편하게 작성하셔도 됩니다. 마지막으로..질문 하나하나 깊이 고민하여 작성합니다만, 제 최선의 답변이 정답은 아닙니다. 질문자님의 고민을 해결할 수 있는 힌트가 되길 바라는 마음입니다. 기한은 6/19(수)까지 열어두겠습니다. 감사합니다 ⬇️PM/PO Private Talk 참여하기⬇️https://shorturl.at/grLpi

Route의 Notion on Notion

39. PM/PO Private Talk을 개최합니다 😀

오오 너무 흥미로운 talk 입니다…👀

제품팀은 팀플레이로 일한다.
팀플은, 항상 어렵다.

왜 어려운가?

가장 큰 이유는 '대화'를 통해 협업해야 하기 때문이다. 제품팀은 PM, 디자인, 개발 직군 담당자가 함께, 팀으로 일해야 한다.

제품팀이 팀으로 일한다는 것은 '대화'를 통해 기획안을 디벨롭하고, 출시하는 것을 뜻한다. 이때 대화의 질에 따라 결과가 달라진다. 대화를 잘 했을 때는 결과도 좋을 확률이 높다. 실패하더라도 다음 프로젝트의 자산으로 활용될 수 있다. 반대로, 대화를 잘 못했을 때는 좋은 결과를 낼 수 없다.

대화를 잘하기 위한 7가지 가이드라인을 제작했다.

1. 말을 해야 한다.
﻿말을 안 하면 대화가 안된다. 말이 대화의 시작이고, 좋은 팀으로 가는 첫걸음이다. 침묵은 링겔만 효과가 발생한다. 링겔만 효과는 시너지 효과의 반대말로, 집단에 참여하는 수가 늘어날수록 1인당 공헌도가 떨어지는 심리 현상을 말한다. 다시 말해, '나만 아니면 돼'의 마음이 퍼져 팀 전체의 퍼포먼스가 떨어진다는 뜻이다. 누군가는 1인분 이상을 하고 있을 것인데, 그 팀원의 사기가 떨어진다면? 팀 퍼포먼스는 급격히 나빠질 것이다.

2. 결론과 근거를 제시해야 한다.
말에 담긴 주장은 논증의 형태여야 한다. 논증이란, 여러 전제를 들어 결론을 제시하는 것이다. 전제 하나하나가 타당해야 하고, 전제들을 통해 결론을 도출해 내야 한다.

예를 들면, '우리는 찜 기능을 만들어야 합니다. 왜냐하면 유저가 봤던 물건 중 몇몇은 나중에 다시 찾아보기 위해 앱에 접속하는데, 저희 앱 내에는 상품이 수십만 개라 찾기가 어렵습니다. 찜 기능이 있다면 이 문제를 해결할 수 있습니다.' 정도가 되겠다. '찜 기능을 만들어야 한다'라는 결론을 제시하기 위해 여러 전제(유저들이 봤던 물건을 다시 찾아보기 위해 재접속한다, 앱 내에는 상품이 수십만 개라 찾기 어렵다)를 들어 뒷받침하고 있다.

3. 결론은 No가 아니라 better이어야 한다.
'~~해서 안된다'라고 하는 것은 좋은 대화법이 아니다. 'A 방안은 어떠한 문제가 있으니, B 방안이 어떻겠냐' 혹은 'A에 동의한다. 그러기 위해서는, C 문제를 먼저 해결해야 한다'라고 말하는 게 좋다. 대안을 말하거나, 솔루션을 달성하기 위해 해결해야 하는 문제를 짚어주는 게 좋다.

4. A에 대해 반론할 때는 A에 대해 답해야 한다.
예를 들어, '이 회원가입 퍼널은 너무 길어요'라고 문제 제기를 했다고 하자. 만약 답변을 '퍼널을 짧게 만들게 되면 one thing one page 법칙도 깨지고, 다른 페이지의 디자인 스타일과 안 맞아서 길게 해야 해요'라고 말하는 것은 좋은 대화법이 아니다. 제기한 문제는 '퍼널이 길다'라는 것이지 '짧게 했을 때의 문제점'이 아니기 때문이다.

좋은 대화는 '퍼널이 길다'에 대한 YES or NO가 되어야 한다. '긴 것은 맞다. 하지만, 전환율은 개선될 것이다' 혹은 '유저가 생각할 틈이 없이 이어지기 때문에 길다고 느끼지 않을 것이다. 그래서 긴 것이 아니다'라고 말해야 한다.

5. 대화는 Align의 과정이다. Defence가 아니다.
﻿결론을 정해두고 반박하는 경우가 있다. 처음에는 '안된다'라고 주장하며 합리적으로 보이는 1,2,3의 근거를 제시한다. 그러나, 누군가가 제시한 근거를 타파하거나 다른 방향을 제시하면 그 방향에 내포되어 있는 문제를 지적하면서 내 주장이 맞다는 식으로 논거를 제시한다.

논리학에서는 이를 '거짓 딜레마의 오류'라고 한다. 당신이 틀렸기 때문에 내가 맞다고 하는 것이다. 이런 식의 논리적 오류는 내 주장을 defence 하려고 할 때 자주 발생한다. 우리는 팀이고, 더 좋은 방향을 위해 피드백을 하는 것이다. Align 하려는 마음가짐은 우리를 더 열린 태도를 갖게 만들어준다.

6. 감정적으로 대응하지 마라.
감정적인 표현은 문제 해결에 아무런 도움이 안 된다. 감정만 상하는 게 아니라 시간도 허비하고, 더 이상 무엇이 문제였는지 알 수 없게 되어버린다. 팀을 위한 말이 아니라 개인의 헐뜯기를 위한 말이 될 때, 팀은 무너진다.

7. 경청해라.
경청하려고 해도 우리는 상대방의 말을 잘 못 알아듣는다. 그 와중에 멀티태스킹까지 하는 경우도 많다. 그러면서 다 알아듣는다고 생각한다면, 오만이다. 게다가 상대방도 말 쏙쏙 박히게 하는 사람이 아니다. '아, 잘 못 들었어요. 다시 얘기해 주세요'라고 말하는 것 역시 링겔만 효과를 불러일으킨다.

팀플은 어렵다.
그러나, 잘하는 팀플은 미친듯이 재밌다.

좋은 대화법을 익히자.

제품팀은 팀플레이로 일한다.팀플은, 항상 어렵다.​왜 어려운가?​가장 큰 이유는 '대화'를 통해 협업해야 하기 때문이다. 제품팀은 PM, 디자인, 개발 직군 담당자가 함께, 팀으로 일해야 한다.​제품팀이 팀으로 일한다는 것은 '대화'를 통해 기획안을 디벨롭하고, 출시하는 것을 뜻한다. 이때 대화의 질에 따라 결과가 달라진다. 대화를 잘 했을 때는 결과도 좋을 확률이 높다. 실패하더라도 다음 프로젝트의 자산으로 활용될 수 있다. 반대로, 대화를 잘 못했을 때는 좋은 결과를 낼 수 없다.​대화를 잘하기 위한 7가지 가이드라인을 제작했다.​1. 말을 해야 한다.﻿말을 안 하면 대화가 안된다. 말이 대화의 시작이고, 좋은 팀으로 가는 첫걸음이다. 침묵은 링겔만 효과가 발생한다. 링겔만 효과는 시너지 효과의 반대말로, 집단에 참여하는 수가 늘어날수록 1인당 공헌도가 떨어지는 심리 현상을 말한다. 다시 말해, '나만 아니면 돼'의 마음이 퍼져 팀 전체의 퍼포먼스가 떨어진다는 뜻이다. 누군가는 1인분 이상을 하고 있을 것인데, 그 팀원의 사기가 떨어진다면? 팀 퍼포먼스는 급격히 나빠질 것이다.​2. 결론과 근거를 제시해야 한다.말에 담긴 주장은 논증의 형태여야 한다. 논증이란, 여러 전제를 들어 결론을 제시하는 것이다. 전제 하나하나가 타당해야 하고, 전제들을 통해 결론을 도출해 내야 한다.​예를 들면, '우리는 찜 기능을 만들어야 합니다. 왜냐하면 유저가 봤던 물건 중 몇몇은 나중에 다시 찾아보기 위해 앱에 접속하는데, 저희 앱 내에는 상품이 수십만 개라 찾기가 어렵습니다. 찜 기능이 있다면 이 문제를 해결할 수 있습니다.' 정도가 되겠다. '찜 기능을 만들어야 한다'라는 결론을 제시하기 위해 여러 전제(유저들이 봤던 물건을 다시 찾아보기 위해 재접속한다, 앱 내에는 상품이 수십만 개라 찾기 어렵다)를 들어 뒷받침하고 있다.​3. 결론은 No가 아니라 better이어야 한다.'~~해서 안된다'라고 하는 것은 좋은 대화법이 아니다. 'A 방안은 어떠한 문제가 있으니, B 방안이 어떻겠냐' 혹은 'A에 동의한다. 그러기 위해서는, C 문제를 먼저 해결해야 한다'라고 말하는 게 좋다. 대안을 말하거나, 솔루션을 달성하기 위해 해결해야 하는 문제를 짚어주는 게 좋다.​4. A에 대해 반론할 때는 A에 대해 답해야 한다.예를 들어, '이 회원가입 퍼널은 너무 길어요'라고 문제 제기를 했다고 하자. 만약 답변을 '퍼널을 짧게 만들게 되면 one thing one page 법칙도 깨지고, 다른 페이지의 디자인 스타일과 안 맞아서 길게 해야 해요'라고 말하는 것은 좋은 대화법이 아니다. 제기한 문제는 '퍼널이 길다'라는 것이지 '짧게 했을 때의 문제점'이 아니기 때문이다.​좋은 대화는 '퍼널이 길다'에 대한 YES or NO가 되어야 한다. '긴 것은 맞다. 하지만, 전환율은 개선될 것이다' 혹은 '유저가 생각할 틈이 없이 이어지기 때문에 길다고 느끼지 않을 것이다. 그래서 긴 것이 아니다'라고 말해야 한다.​5. 대화는 Align의 과정이다. Defence가 아니다.﻿결론을 정해두고 반박하는 경우가 있다. 처음에는 '안된다'라고 주장하며 합리적으로 보이는 1,2,3의 근거를 제시한다. 그러나, 누군가가 제시한 근거를 타파하거나 다른 방향을 제시하면 그 방향에 내포되어 있는 문제를 지적하면서 내 주장이 맞다는 식으로 논거를 제시한다.​논리학에서는 이를 '거짓 딜레마의 오류'라고 한다. 당신이 틀렸기 때문에 내가 맞다고 하는 것이다. 이런 식의 논리적 오류는 내 주장을 defence 하려고 할 때 자주 발생한다. 우리는 팀이고, 더 좋은 방향을 위해 피드백을 하는 것이다. Align 하려는 마음가짐은 우리를 더 열린 태도를 갖게 만들어준다.​6. 감정적으로 대응하지 마라.감정적인 표현은 문제 해결에 아무런 도움이 안 된다. 감정만 상하는 게 아니라 시간도 허비하고, 더 이상 무엇이 문제였는지 알 수 없게 되어버린다. 팀을 위한 말이 아니라 개인의 헐뜯기를 위한 말이 될 때, 팀은 무너진다.​7. 경청해라.경청하려고 해도 우리는 상대방의 말을 잘 못 알아듣는다. 그 와중에 멀티태스킹까지 하는 경우도 많다. 그러면서 다 알아듣는다고 생각한다면, 오만이다. 게다가 상대방도 말 쏙쏙 박히게 하는 사람이 아니다. '아, 잘 못 들었어요. 다시 얘기해 주세요'라고 말하는 것 역시 링겔만 효과를 불러일으킨다.​팀플은 어렵다.그러나, 잘하는 팀플은 미친듯이 재밌다.​좋은 대화법을 익히자.

38. 제품팀의 팀워크 향상을 위한 7가지 대화 전략

지금까지 멘토링을 쭈욱 진행해오면서 한결같이 강조한 부분이 있는데요!
바로 포트폴리오의 중요성입니다.

개발자는 결국 개발 능력을 보여줄 수 있어야하고 회사와 협상할 때도 그 점을 잘 어필해야 합니다.
협상을 잘 해야 면접을 통과해서 취업에 성공할 수 있고 더 나아가 연봉협상도 자신에게 더 유리하게 할 수 있겠죠.

이 전체적인 취업 과정에서 첫 단추를 잘 끼워야 할 것 같은데요!
첫 단추는 어디일까요?

네! 바로 서류통과 부분이죠. 여기에서 탈락해버리면 할 수 있는게 아무것도 없습니다. 그냥 다른 회사를 알아볼 수 밖에요.

가끔은 개발실력이 뛰어난데도 서류통과에서 떨어지는 분들도 있습니다. 자신이 가진 개발실력을 제대로 어필하지 못해서그런거에요.
개발실력이 탄탄하다는 전제하에 서류통과의 합격 기준은 결국 포트폴리오 구성에 달려있다고 봐야합니다.

그럼 어떻게 눈에 띄는 포트폴리오를 만들 수 있을까요?

저의 경우 최근 이직(2023년 3~4월 기준)에서 구직 시작하자마자 2주만에 20개의 기업에서 면접 제안을 받았고, 그 중 총 4개의 기업에 제가 제시한 처우 조건 이상으로 합격했습니다.

감사하게도 회사를 선택해서 갈 수 있는 상황이 펼쳐진 것이죠.
단시간에 수 많은 회사에서 연락이 온 이유는 무엇일까요? 그건 제 프로젝트 경험을 잘 녹여낸 포트폴리오 때문이라고 확신합니다.

포트폴리오를 구성할 때 가장 중요한 부분은 바로 첫번째 장이에요.

첫번째 장에서 임팩트를 주지 못하면 절대 그 다음장을 주의깊게 보지 않습니다. 끝까지 다 읽지 않을 가능성도 커요.
그냥 스윽 훓어보고 넘겨버릴 수 있습니다.

면접을 담당하는 사람 입장에서 좀 생각해봐야하는데요. 본인 업무도 있는데 없는 시간을 쪼개서 함께 일 할 사람을 뽑는 상황이에요.

문서를 다 훓어볼 시간도 없고 아주 명확한 기준보다는 일단 눈이 가는 포트폴리오를 선택해서 좀 더 상세히보고 면접 여부를 결정합니다.
그리고 많은 경우 포트폴리오를 잘 구성한 사람이 프로젝트 경험도 뛰어나요.
첫 장에서 어떻게 임팩트를 줄 수 있을까요?

이 부분에 대해 얘기를 하자면 엄청 길어집니다...
가장 중요한 한 가지를 말씀드릴께요!

바로 호기심을 불러일으키는겁니다. 내가 어떤 사람인지 궁금하게끔, 그리고 실제로 눈을 마주치고 인사를 한다는 느낌을 주게끔 구성을 해야 합니다.
저는 정말 잘 나온(스튜디오 같은 곳에서 돈주고 촬영한) 프로필 사진을 대문짝만하게 첫장에 넣었습니다. 그리고 제 개발자로써의 컨셉을 넣었죠.

그리고 프로젝트 경험 중에서 가장 눈에띄는 부분을 요약해서 3문장으로 넣었습니다.
이런 독특한 구성이 면접관의 호기심을 자극한 것이죠. 다른 포트폴리오와 차별화가 된 것입니다.
물론 디자인적인 요소도 중요합니다. 우리가 어떤 웹사이트나 앱을 볼 때 디자인 중요하게 생각하잖아요?

디자인이 구리면 기능이 잘 동작해도 손이 잘 안갑니다. 그런 것과 같은 맥락이에요. 근데 생각보다 많은 개발자분들이 아주 밋밋하고 글자만 빽빽한 포트폴리오 구성을 사용하더군요.
포트폴리오 구성할 때 가장 중요한 첫장에 대한 꿀팁을 드렸습니다.

이 점을 명심하시고 포트폴리오 구성에 참고한다면 서류통과 확률을 높이실 수 있을꺼에요!
앞으로도 도움이 되는 팁들 많이 풀도록 하겠습니다 :)

지금까지 멘토링을 쭈욱 진행해오면서 한결같이 강조한 부분이 있는데요!바로 포트폴리오의 중요성입니다. 개발자는 결국 개발 능력을 보여줄 수 있어야하고 회사와 협상할 때도 그 점을 잘 어필해야 합니다.협상을 잘 해야 면접을 통과해서 취업에 성공할 수 있고 더 나아가 연봉협상도 자신에게 더 유리하게 할 수 있겠죠. 이 전체적인 취업 과정에서 첫 단추를 잘 끼워야 할 것 같은데요!첫 단추는 어디일까요? 네! 바로 서류통과 부분이죠. 여기에서 탈락해버리면 할 수 있는게 아무것도 없습니다. 그냥 다른 회사를 알아볼 수 밖에요. 가끔은 개발실력이 뛰어난데도 서류통과에서 떨어지는 분들도 있습니다. 자신이 가진 개발실력을 제대로 어필하지 못해서그런거에요.개발실력이 탄탄하다는 전제하에 서류통과의 합격 기준은 결국 포트폴리오 구성에 달려있다고 봐야합니다. 그럼 어떻게 눈에 띄는 포트폴리오를 만들 수 있을까요? 저의 경우 최근 이직(2023년 3~4월 기준)에서 구직 시작하자마자 2주만에 20개의 기업에서 면접 제안을 받았고, 그 중 총 4개의 기업에 제가 제시한 처우 조건 이상으로 합격했습니다. 감사하게도 회사를 선택해서 갈 수 있는 상황이 펼쳐진 것이죠.단시간에 수 많은 회사에서 연락이 온 이유는 무엇일까요? 그건 제 프로젝트 경험을 잘 녹여낸 포트폴리오 때문이라고 확신합니다. 포트폴리오를 구성할 때 가장 중요한 부분은 바로 첫번째 장이에요. 첫번째 장에서 임팩트를 주지 못하면 절대 그 다음장을 주의깊게 보지 않습니다. 끝까지 다 읽지 않을 가능성도 커요.그냥 스윽 훓어보고 넘겨버릴 수 있습니다. 면접을 담당하는 사람 입장에서 좀 생각해봐야하는데요. 본인 업무도 있는데 없는 시간을 쪼개서 함께 일 할 사람을 뽑는 상황이에요. 문서를 다 훓어볼 시간도 없고 아주 명확한 기준보다는 일단 눈이 가는 포트폴리오를 선택해서 좀 더 상세히보고 면접 여부를 결정합니다.그리고 많은 경우 포트폴리오를 잘 구성한 사람이 프로젝트 경험도 뛰어나요.첫 장에서 어떻게 임팩트를 줄 수 있을까요? 이 부분에 대해 얘기를 하자면 엄청 길어집니다...가장 중요한 한 가지를 말씀드릴께요! 바로 호기심을 불러일으키는겁니다. 내가 어떤 사람인지 궁금하게끔, 그리고 실제로 눈을 마주치고 인사를 한다는 느낌을 주게끔 구성을 해야 합니다.저는 정말 잘 나온(스튜디오 같은 곳에서 돈주고 촬영한) 프로필 사진을 대문짝만하게 첫장에 넣었습니다. 그리고 제 개발자로써의 컨셉을 넣었죠. 그리고 프로젝트 경험 중에서 가장 눈에띄는 부분을 요약해서 3문장으로 넣었습니다.이런 독특한 구성이 면접관의 호기심을 자극한 것이죠. 다른 포트폴리오와 차별화가 된 것입니다.물론 디자인적인 요소도 중요합니다. 우리가 어떤 웹사이트나 앱을 볼 때 디자인 중요하게 생각하잖아요? 디자인이 구리면 기능이 잘 동작해도 손이 잘 안갑니다. 그런 것과 같은 맥락이에요. 근데 생각보다 많은 개발자분들이 아주 밋밋하고 글자만 빽빽한 포트폴리오 구성을 사용하더군요.포트폴리오 구성할 때 가장 중요한 첫장에 대한 꿀팁을 드렸습니다. 이 점을 명심하시고 포트폴리오 구성에 참고한다면 서류통과 확률을 높이실 수 있을꺼에요!앞으로도 도움이 되는 팁들 많이 풀도록 하겠습니다 :)

🌅 회사에서 모셔가는 포트폴리오 작성 꿀팁 #1

1. 스타트업에서 제품팀을 운영할 때 애자일 방법론과 스쿼드 체제에 대해 의견이 분분합니다. 스쿼드 체제로 운영하는 제품팀의 PO(Product Owner)로 일한 경험을 기반으로, 실무자와 관리자 각각의 관점에서 느낀 것들을 공유드리고자 합니다.

2. 현 회사에서 PO로 1년 8개월 동안 2개 스쿼드를 맡았고, 지금은 3번째 스쿼드를 맡고 있습니다. 팀원은 총 4명(PO, PD, FE, BE), 월 이슈 처리 개수는 60~70개, 작년 스쿼드 성과는 매출액 YoY 3X+, 현 스쿼드의 KPI 성장률은 최근 3개월 CMGR 47%입니다. 1주 단위 스프린트를 기본으로 일하되, 즉각 대응이 필요한 이슈는 우선적으로 처리합니다.

3. PO로서 느낀 스쿼드 체제의 가장 큰 장점은 ‘속도’입니다. 속도는 제품 개발 속도를 의미합니다. 이슈가 발생했을 때 팀원끼리 논의하고, 개선안을 만들고, 배포합니다. 상황에 따라 우선순위를 쉽게 바꿀 수 있기 때문에 임팩트 있는 일들부터 처리하게 되고, 결과적으로 제품이 빠르게 성장하게 됩니다.

일례로, 프로모션 시 빠른 대응으로 폭발적인 성과를 냈던 적이 있습니다. 해당 프로모션은 높은 할인율로 인기가 많았는데, 많은 고객들이 할부 결제를 원했음에도 어드민에 할부 결제 기능이 없었습니다. 다른 개발 건들이 진행되고 있었으나 할부 결제 기능 개발의 우선순위가 높다고 판단해 빠르게 개발했고, 해당 월에 매출 MoM 72%를 달성했습니다.

4. 이에 반해, 스쿼드 체제의 가장 큰 단점은 ‘백업의 부재’입니다. 팀원이 퇴사하면 스쿼드가 정상적으로 운영될 수 없습니다. 신규 팀원 충원이 늦어지는 경우도 많고, 타 팀원을 대체 인력으로 운용하여도 스쿼드가 이전만큼 퍼포먼스를 낼 수 없습니다. 스쿼드 조직의 구조상 한 명에게 큰 역할과 권한을 부여하기 때문에 필연적으로 인적 자원에 취약합니다.

제 스쿼드의 경우, 개발자 2명이 모두 병역특례를 이유로 3주 훈련을 통지 받았던 적이 있습니다. 기간은 겹치지 않았으나 서로가 담당하는 영역이 달라 대응에 어려움이 있었습니다. 다행히 1명은 대체 인력을 운용할 수 있어 훈련을 갔지만, 1명은 훈련 일정을 연기해야 했습니다. 이를 해결하기 위해 조직 차원에서 구조적 문제점을 개선하기로 했습니다.

5. 실무자 입장에서 스쿼드 체제로 운영되는 애자일 조직은 만족스러웠습니다. 다만, 조직 운영의 관점에서 '애자일 조직이 좋은가?'에 'YES'라고 답하긴 어려웠습니다. 이 운영 방식이 성공하기 위해서는, 즉 ‘속도’라는 장점을 살리기 위해서는 몇 가지 전제조건들이 필요했기 때문입니다.

6. 애자일 조직은 크게 조직적 지원과 높은 수준의 개인 역량을 필요로 합니다.

7. 조직적 지원은 경영진의 의지, 스쿼드-독립적인 제품 개선 전략 및 개발 우선순위 의사 결정 권한, 독립적인 인력 구성, CI/CD를 비롯한 DevOps지원 등을 뜻합니다. 체제는 스쿼드인데 업무는 기능팀처럼 하거나, 스쿼드에 의사 결정 권한을 주지 않거나, 모놀리식 아키텍처여서 상시 배포가 되지 않거나, 한 명이 여러 스쿼드에 배정되어 리소스가 분산되는 등 속도를 저해하는 요소들이 회사 곳곳에 있습니다. 조직적 차원에서 이를 해결하지 않으면 원하는만큼 빠른 속도를 내는 애자일 조직이 되기 어렵습니다.

8. 높은 수준의 개인 역량은 목표 중심적인 사고방식, 의사 결정 능력, 의사 결정 속도, 우선순위 조정 능력, 일정 관리, 강력한 업무 몰입도 등을 뜻합니다. 모든 권한을 부여 받았음에도 목표와 동떨어진 문제를 해결하거나, 우선순위 조정을 잘못해서 퍼포먼스가 나오지 않거나, 일정이 계속 밀리거나, 디자인 혹은 개발 속도 자체가 느리거나, 구성원으로부터 공감을 이끌어 내지 못하는 등 개인 역량이 뒷받침되지 않아도 원하는 속도를 만들어 낼 수 없습니다.

9. 결정적으로 위 전제조건들은 필요조건입니다. 없으면 실패하나, 있다고 성공하는 건 아닙니다. 또한, 다른 관점에서 질문할 필요도 있습니다. '우리에게 속도가 과연 중요한가?' 혹은 '지금 꼭 조직을 애자일하게 바꿔야 하는가?'와 같은 당위에 대해서도 진지하게 고민해 봐야 합니다. 제품 퀄리티가 가장 중요하다면 애자일 방법론은 최선이 아닐 겁니다.

10. 하지만, 적어도 스타트업은 ‘속도’를 필수적인 강점으로 가져야 한다고 생각합니다. 생존을 위해 '더 빠르게!'를 외치면서 애자일 조직의 시행착오를 겪고 있다면, 리더의 적극적인 개입과 모니터링이 필요합니다. 속도를 저해하는 요소가 무엇인지 팀원들과 소통하며 세밀하게 파악하고, 하나하나 깨부숴야 합니다. 많은 비용과 노력이 드는 것이 사실입니다. 결국 가장 중요한 건, 그 모든 것을 감당하겠다는 경영진의 강한 의지에 달려있지 않나 싶습니다.

1. 스타트업에서 제품팀을 운영할 때 애자일 방법론과 스쿼드 체제에 대해 의견이 분분합니다. 스쿼드 체제로 운영하는 제품팀의 PO(Product Owner)로 일한 경험을 기반으로, 실무자와 관리자 각각의 관점에서 느낀 것들을 공유드리고자 합니다.​2. 현 회사에서 PO로 1년 8개월 동안 2개 스쿼드를 맡았고, 지금은 3번째 스쿼드를 맡고 있습니다. 팀원은 총 4명(PO, PD, FE, BE), 월 이슈 처리 개수는 60~70개, 작년 스쿼드 성과는 매출액 YoY 3X+, 현 스쿼드의 KPI 성장률은 최근 3개월 CMGR 47%입니다. 1주 단위 스프린트를 기본으로 일하되, 즉각 대응이 필요한 이슈는 우선적으로 처리합니다.​3. PO로서 느낀 스쿼드 체제의 가장 큰 장점은 ‘속도’입니다. 속도는 제품 개발 속도를 의미합니다. 이슈가 발생했을 때 팀원끼리 논의하고, 개선안을 만들고, 배포합니다. 상황에 따라 우선순위를 쉽게 바꿀 수 있기 때문에 임팩트 있는 일들부터 처리하게 되고, 결과적으로 제품이 빠르게 성장하게 됩니다.​일례로, 프로모션 시 빠른 대응으로 폭발적인 성과를 냈던 적이 있습니다. 해당 프로모션은 높은 할인율로 인기가 많았는데, 많은 고객들이 할부 결제를 원했음에도 어드민에 할부 결제 기능이 없었습니다. 다른 개발 건들이 진행되고 있었으나 할부 결제 기능 개발의 우선순위가 높다고 판단해 빠르게 개발했고, 해당 월에 매출 MoM 72%를 달성했습니다.​4. 이에 반해, 스쿼드 체제의 가장 큰 단점은 ‘백업의 부재’입니다. 팀원이 퇴사하면 스쿼드가 정상적으로 운영될 수 없습니다. 신규 팀원 충원이 늦어지는 경우도 많고, 타 팀원을 대체 인력으로 운용하여도 스쿼드가 이전만큼 퍼포먼스를 낼 수 없습니다. 스쿼드 조직의 구조상 한 명에게 큰 역할과 권한을 부여하기 때문에 필연적으로 인적 자원에 취약합니다.​제 스쿼드의 경우, 개발자 2명이 모두 병역특례를 이유로 3주 훈련을 통지 받았던 적이 있습니다. 기간은 겹치지 않았으나 서로가 담당하는 영역이 달라 대응에 어려움이 있었습니다. 다행히 1명은 대체 인력을 운용할 수 있어 훈련을 갔지만, 1명은 훈련 일정을 연기해야 했습니다. 이를 해결하기 위해 조직 차원에서 구조적 문제점을 개선하기로 했습니다.​5. 실무자 입장에서 스쿼드 체제로 운영되는 애자일 조직은 만족스러웠습니다. 다만, 조직 운영의 관점에서 '애자일 조직이 좋은가?'에 'YES'라고 답하긴 어려웠습니다. 이 운영 방식이 성공하기 위해서는, 즉 ‘속도’라는 장점을 살리기 위해서는 몇 가지 전제조건들이 필요했기 때문입니다.​6. 애자일 조직은 크게 조직적 지원과 높은 수준의 개인 역량을 필요로 합니다.​7. 조직적 지원은 경영진의 의지, 스쿼드-독립적인 제품 개선 전략 및 개발 우선순위 의사 결정 권한, 독립적인 인력 구성, CI/CD를 비롯한 DevOps지원 등을 뜻합니다. 체제는 스쿼드인데 업무는 기능팀처럼 하거나, 스쿼드에 의사 결정 권한을 주지 않거나, 모놀리식 아키텍처여서 상시 배포가 되지 않거나, 한 명이 여러 스쿼드에 배정되어 리소스가 분산되는 등 속도를 저해하는 요소들이 회사 곳곳에 있습니다. 조직적 차원에서 이를 해결하지 않으면 원하는만큼 빠른 속도를 내는 애자일 조직이 되기 어렵습니다.​8. 높은 수준의 개인 역량은 목표 중심적인 사고방식, 의사 결정 능력, 의사 결정 속도, 우선순위 조정 능력, 일정 관리, 강력한 업무 몰입도 등을 뜻합니다. 모든 권한을 부여 받았음에도 목표와 동떨어진 문제를 해결하거나, 우선순위 조정을 잘못해서 퍼포먼스가 나오지 않거나, 일정이 계속 밀리거나, 디자인 혹은 개발 속도 자체가 느리거나, 구성원으로부터 공감을 이끌어 내지 못하는 등 개인 역량이 뒷받침되지 않아도 원하는 속도를 만들어 낼 수 없습니다.​9. 결정적으로 위 전제조건들은 필요조건입니다. 없으면 실패하나, 있다고 성공하는 건 아닙니다. 또한, 다른 관점에서 질문할 필요도 있습니다. '우리에게 속도가 과연 중요한가?' 혹은 '지금 꼭 조직을 애자일하게 바꿔야 하는가?'와 같은 당위에 대해서도 진지하게 고민해 봐야 합니다. 제품 퀄리티가 가장 중요하다면 애자일 방법론은 최선이 아닐 겁니다.​10. 하지만, 적어도 스타트업은 ‘속도’를 필수적인 강점으로 가져야 한다고 생각합니다. 생존을 위해 '더 빠르게!'를 외치면서 애자일 조직의 시행착오를 겪고 있다면, 리더의 적극적인 개입과 모니터링이 필요합니다. 속도를 저해하는 요소가 무엇인지 팀원들과 소통하며 세밀하게 파악하고, 하나하나 깨부숴야 합니다. 많은 비용과 노력이 드는 것이 사실입니다. 결국 가장 중요한 건, 그 모든 것을 감당하겠다는 경영진의 강한 의지에 달려있지 않나 싶습니다.

37. PO가 느낀 애자일 조직의 장단점과 성공의 필요조건

인프런이 만드는 IT인의 축제, 인프콘에 초대합니다

인프콘 2024 - INFCON 2024

1. INFCON
- https://www.inflearn.com/conf/infcon-2024/
- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등
- 2024년 8월 2일(금)
- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정

2. UbuCon Korea 2024
- https://2024.ubuntu-kr.org/ko/
- Ubuntu 코리아 컨퍼런스
- 2024년 8월 10일(토)
- 유료

3. FEConf24
- https://2024.feconf.kr/
- 국내 최대 프론트엔드 컨퍼런스
- 2024년 8월 24일(토)
- 유료

4. Kubernetes Korea Community Day 2024
- https://kcd-korea.net/
- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스
- 2024년 9월 24일(화)
- 유료

5. OpenInfra Summit Asia 2024
- https://2024.openinfraasia.org/
- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스
- 2024년 9월 3일(화) ~ 9월 4일(수)
- 유료

6. KWDC 2024
- https://kwdc.dev/2024/
- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스
- 2024년 10월 24일(목)
- 유료

7. PyCon KR 2024
- https://2024.pycon.kr/
- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스
- 2024년 10월 25일(금) ~ 10월 27일(일)
- 유료

8. DebConf24
- https://debconf24.debconf.org/
- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나
- 2024년 7월 28일(일) ~ 8월 4일(일)
- 유·무료(일반 무료, 전문가/기업 유료)

9. GopherCon Korea 2024
- https://festa.io/events/5098
- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스
- 2024년 10월 12일(토) ~ 10월 13일(일)
- 유료

해외 컨퍼런스
1. GitHub Universe 2024
- https://githubuniverse.com/
- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코
- 유료 / 온라인 라이브 스트리밍 무료

2. KubeCon + CloudNativeCon North America
- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/
- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티
- 유료 / 키노트 라이브 스트리밍 무료

3. AWS re:Invent 2024
- https://reinvent.awsevents.com/
- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스
- 유료 / 온라인 라이브 스트리밍 무료

1. INFCON- https://www.inflearn.com/conf/infcon-2024/- ‘인프런’에서 주최하는 IT 컨퍼런스. 개발자, PM/PO, 디자이너 분야 등- 2024년 8월 2일(금)- 유료 / 참가 신청 마감. 추후 인프콘 다시보기 서비스 제공 예정 2. UbuCon Korea 2024- https://2024.ubuntu-kr.org/ko/- Ubuntu 코리아 컨퍼런스- 2024년 8월 10일(토)- 유료 3. FEConf24- https://2024.feconf.kr/- 국내 최대 프론트엔드 컨퍼런스- 2024년 8월 24일(토)- 유료 4. Kubernetes Korea Community Day 2024- https://kcd-korea.net/- 쿠버네티스에서 주최하는 국내 클라우드 네이티브 기술 컨퍼런스- 2024년 9월 24일(화)- 유료 5. OpenInfra Summit Asia 2024- https://2024.openinfraasia.org/- 클라우드 네이티브 오픈소스 기술 재단 ‘오픈인프라’ 컨퍼런스- 2024년 9월 3일(화) ~ 9월 4일(수)- 유료 6. KWDC 2024- https://kwdc.dev/2024/- 국내 애플 개발자 커뮤니티 3곳이 주최하는 한국 Apple 생태계 컨퍼런스- 2024년 10월 24일(목)- 유료 7. PyCon KR 2024- https://2024.pycon.kr/- 세계 각국의 파이썬 프로그래밍 언어 커뮤니티에서 주관하는 컨퍼런스- 2024년 10월 25일(금) ~ 10월 27일(일)- 유료 8. DebConf24- https://debconf24.debconf.org/- 데비안 운영체제, 소프트웨어 개발과 관련한 세미나- 2024년 7월 28일(일) ~ 8월 4일(일)- 유·무료(일반 무료, 전문가/기업 유료) 9. GopherCon Korea 2024- https://festa.io/events/5098- 한국의 Go 언어 사용자 모임 커뮤니티에서 주최하는 컨퍼런스- 2024년 10월 12일(토) ~ 10월 13일(일)- 유료 해외 컨퍼런스1. GitHub Universe 2024- https://githubuniverse.com/- 2024년 10월 29일(화) ~ 10월 30일(수) / 미국 샌프란시스코- 유료 / 온라인 라이브 스트리밍 무료 2. KubeCon + CloudNativeCon North America- https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/- 2024년 11월 12일(화) ~ 11월 15일(금) / 미국 유타주 솔트레이크시티- 유료 / 키노트 라이브 스트리밍 무료 3. AWS re:Invent 2024- https://reinvent.awsevents.com/- 2024년 12월 2일(월) ~ 12월 6일(금) / 미국 라스베가스- 유료 / 온라인 라이브 스트리밍 무료

2024 하반기 IT 컨퍼런스

I finally have the feeling that I&rsquo;m a decent programmer, so I thought it would be fun to write some advice with the idea of &ldquo;what would have gotten me to this point faster?&rdquo; I&rsquo;m not claiming this is great advice for everyone, just 

Marcus' Blog


한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다.
몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다.

🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다.
팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다.
이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다.

🪠 품질과 속도 사이의 균형을 맞춰야한다.
구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요.

🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.
도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다.

🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.
버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요.

🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.
이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요.

🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.
끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다.
또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.
'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요.

🏋️ 디버깅 하기 쉽게 만들어야 한다.
디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요.

💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.
경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다.

👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요
프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

한 개발자가 과거의 나에게 개발자로써 조언을 해준다면? 에 대해 작성해주신 글입니다. 몇 가지는 직접적으로 저에게 도움이 되는 부분도 있어, 일부 저에게 도움되는 부분만 요약해서 공유드립니다. 🤔 계속 발에 총을 쏘고 있다면, 총을 고쳐야한다. 팀에서 시스템에 대해 자주 실수 하는 부분이 있지만, 그 실수를 줄일 방법에 대해 생각하지 않는 경우가 많습니다. 이런 경우 시스템을 개선하여 실수를 줄이는 것이 중요합니다. 이러한 문제들은 해결할 자연스러운 시기가 없었기에 오래 지속되는 경우가 많으니, 생각보다 몇 분 동안만 고민하면 해결 할 수 있는게 많습니다. 이런 문제가 있을 때 자신과 팀의 삶을 더 쉽게 만들 수 있다는 것을 상기시키고 마음가짐을 갖는게 중요합니다. 🪠 품질과 속도 사이의 균형을 맞춰야한다.구현 속도와 정확성에 대한 자신감 사이에는 항상 트레이드오프가 존재합니다. 현재 상황에서 버그를 출시하는 것이 얼마나 괜찮은지 자문해보고, 이에 대한 답변이 작업 방식에 영향을 미치지 않는다면 지나치게 경직된 것으로 생각하세요. 🪭 톱을 갈고 있는 시간은 거의 항상 가치가 있는 시간이다.도구를 잘 다루는 것이 중요합니다. 코드를 빠르게 작성하고, 주요 단축키를 알고, 운영체제와 셀에 능숙해야 합니다. 새로운 엔지니어에게서 보이는 가장 큰 그린 플래그 중 하나는 도구 선택과 능숙한 사용에 대한 관심입니다. 🧘🏻‍♂️버그를 한 층 더 깊이 해결하려고 노력해야 한다.버그를 표면적으로 해결하는 대신, 근본적인 원인을 찾아 해결하는 것이 중요합니다. 최대한 어떤 컴포넌트도 이 버그를 다시 겪지 않도록 해결하려고 노력해보세요. 🏃🏻‍♀️ 버그 조사 시 히스토리를 활용해야 한다.이상한 버그를 조사할 때, git 히스토리를 활용하는 것이 중요합니다. 예를 들어 메모리 누수 문제를 조사할 때, 특정 커밋 이후에 문제가 발생한 경우가 많으니 참고하세요. 🎆 가끔은 나쁜 코드로 작성하는 쪽으로 오류를 범해봐라.끔찍한 코드를 작성하는 것도 쉽고, 모든 모범사례를 절대적으로 따르는 코드를 작성하는 것도 정말 쉽습니다. 하지만 이런 코드 작성은 스타트업에 돈이 바닥 날 가능성이 큽니다. 또한 빨리 코드를 작성하게 되면 추후 나쁜 기술 부채로 인해 곤란을 겪게 될 수도 있습니다.'나쁜' 코드의 의미를 명확하게 하고, 시간과 노력의 균형을 찾아 코드를 작성해보세요. 🏋️ 디버깅 하기 쉽게 만들어야 한다.디버깅을 쉽게 하기 위한 노력을 하지 않으면, 소프트웨어가 점점 더 복잡해짐에 따라 각 이슈를 디버깅 하는데 엄청난 시간을 소비하게 될 것 입니다. 그렇게 되면 결국 변경 하는 것이 두려워지게 됩니다. 디버깅 시간 중 설정, 재현, 사후 정리에 소요되는 시간을 추적하는 데 주의를 기울이세요. 💁‍♂️ 팀에서 일할 때는 보통 질문을 해야 한다.경력 초반자들은 '사소한 질문으로 동료를 귀찮게 하는 것' 보다 '모든 것을 스스로 알아내려고 노력하는 것'에 너무 치우쳐 있습니다. 한 시간 넘게 무언가를 알아내기 위해 시간을 허비하지말고 몇 분 만에 답을 찾을 수 있게 항상 질문하세요. 누군가에게 귀찮은 경우는 몇 분 안에 스스로 답을 찾을 수 있었다는 것이 분명할 때 뿐입니다. 👁️ 배포 주기는 매우 중요, 빠르고 자주 배포할 수 있는 방법 고민 필요프로젝트 배포 속도는 시간이 지남에 따라 복리로 증가해서, 상상할 수 있는 것보다 빠르게 기능을 배포할 수 있게 됩니다. 스타트업은 런웨이가 제한적이고, 프로젝트에는 마감일이 항상 있으니 빠르게 배포하기 위해 여러가지 시도를 해보세요.

mbuffett.com

15년 전 나에게 해주고 싶은 프로그래밍 조언

회계는 지난 수백 년 동안 크게 변하지 않았음그럼에도 불구하고, 금융 시스템을 위한 소프트웨어를 구축하는 올바른 방법에 대해 많은 혼란이 있음이 글에서는 대기업에서 금융 시스템을 구축한 경험을 바탕으로 한 교훈을 공유회계 시스템 구축에 초점을 맞추겠지만, 이 원칙들은 더 일반적인 금융 시스템에도 적용됨기본 금융 용어 정의일반 원장 (General Ledge

금융 시스템 구축을 위한 엔지니어링 원칙 | GeekNews

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다.

숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다.

news.hada.io/topic?id=15794

블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다!

 * Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf
   
 * 실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w

예전에 회계 시스템 만들때, "아 정말 나는 금융을 하나도 모르는 구나" 하면서 참 고생했던 기억이 있습니다. 숫자 계산을 좋아하는 개발자들이지만, 역사가 긴 금융, 회계 시스템, 환율, 정책, 원리에 대해서 이해하지 않으면 설계에서부터 시작해서, 멱등성 유지, 트랜잭션 등 자칫 고려하지 못하면 큰일 나는 구석들도 많은 아주 흥미로우면서 후덜덜한 영역일 것 같습니다. news.hada.io/topic?id=15794 블로그 글 뿐만 아니라 저도 설계에 도움 많이 받았던 글들 공유드려봅니다! <ul ><li>Martin Fowler - Accounting Patterns : https://martinfowler.com/apsupp/accounting.pdf </li><li>실제 서비스 API로 만들면 이런 모양이 될꺼다!로 제일 참고하기 좋았던 Twisp Doc (GraphQL) : https://t.co/m78EFpYX7w </li></ul>

GeekNews

금융 시스템 구축을 위한 엔지니어링 원칙

테스트 코드는 왜 써야 할까요? 테스트 코드가 가져오는 베네핏들에는 어떤 것이 있을까요?

모닥불 | EP.3 프론트엔드 개발에서 테스트 자동화, 꼭 해야 할까?

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.
그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.
그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:
 1. 신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.
 2. 리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.
 3. 문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.

그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:
 1. 전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.
 2. 통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.
 3. 생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.

결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다.

https://toss.tech/article/firesidechat_frontend_3

프론트엔드 개발 영역에서 테스트 코드의 필요성은 지속적인 논의의 대상입니다. 사용자 인터페이스와 직접적으로 연결되는 프론트엔드 코드의 특성상, 빈번하고 다양한 변화에 직면하게 되기 때문인데요. 이러한 환경에서 개발자들은 때때로 시간적 제약으로 인해 테스트 코드 작성을 생략하고 즉각적인 개발에 집중하게 되는데요. 이는 단기적으로 생산성 향상으로 느껴질 수 있습니다.그러나 이러한 접근은 '단기적 효율'과 '장기적 지속가능성' 사이의 균형에 대한 문제를 제기합니다. 테스트 코드 없이 진행되는 개발이 당장은 빠른 결과물 도출로 이어질 수 있지만, 장기적 관점에서는 오히려 생산성 저하와 품질 문제로 이어질 수 있기 때문인데요.그렇다면 테스트 코드가 어떻게 장기적인 생산성 향상에 기여하는 것일까요? 다음은 테스트 코드가 가져다주는 주요 이점들입니다:<ol ><li>신속한 피드백 루프: 테스트 코드는 개발자가 변경사항을 즉각적으로 검증할 수 있게 해줍니다. 이는 수동 테스트 과정을 최소화하고, 버그를 조기에 발견하여 수정 비용을 절감시킵니다.</li><li>리팩토링 자신감: 잘 작성된 테스트 코드는 개발자에게 코드 개선에 대한 자신감을 부여합니다. 기존 기능의 정상 작동을 보장하면서 새로운 기능을 추가하거나 라이브러리 업데이트를 할 수 있습니다.</li><li>문서화 효과: 테스트 코드는 실행 가능한 명세서 역할을 합니다. 특히 빠르게 변화하는 스타트업 환경에서, 테스트 코드는 최신 상태의 신뢰할 수 있는 문서가 됩니다.</li></ol> 그렇다면 테스트 코드는 어떻게 작성해야 할까요? 아마 많은 개발자 분들이 실질적으로 궁금해하는 내용일텐데요. 전통적인 테스트 피라미드 접근법은 유닛 테스트를 기반으로, 통합 테스트, 그리고 E2E(End-to-End) 테스트 순으로 구성됩니다. 그러나 실제 개발 에서는 이론과 실제 적용 사이의 간극이 존재하기 마련인데요. 토스의 테스트 전략은 아래와 같은 개념 으로 구성되어 있습니다:<ol ><li>전략적 선별: 복잡성이 높고 비즈니스에 중요한 기능에 테스트 역량을 집중합니다. 단순한 UI 요소보다는 핵심 비즈니스 로직과 주요 사용자 시나리오에 초점을 맞춤으로써, 테스트의 투자 대비 생산성을 극대화합니다.</li><li>통합 테스트 중심 접근: 페이지 단위의 통합 테스트로 실제 사용자 경험에 더 가까운 테스트 시나리오를 구성합니다. 이러한 방식은 개별 컴포넌트의 기능성뿐만 아니라, 상호작용하여 전체 시스템을 구성하는지 검증할 수 있게 해줍니다.</li><li>생산성과 효율성의 균형: 너무 단순한 테스트는 작성하지 않습니다. 예를 들어, 즉시 확인 가능한 단순 UI 변경사항에 대해서는 별도의 자동화된 테스트를 작성하지 않습니다.</li></ol> 결론적으로, 토스의 프론트엔드 테스트는 기존의 이론적 모델을 맹목적으로 따르기보다는 실질적인 가치를 제공하는 방향으로 접근하고 있습니다. 통합테스트 중심의 실용적 접근을 통해 개발 생산성과 품질 사이의 적절한 균형을 맞추는게 인상적이었습니다. https://toss.tech/article/firesidechat_frontend_3

변화하는 UI, 변하지 않는 품질: 토스의 프론트엔드 테스트 전략

원문 : https&#x3A;//dev.to/yoskutik/extremely-reducing-the-size-of-npm-package-3420

[번역] NPM 패키지 크기 대폭 축소하기

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다.

이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다.

글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다.

각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :)

> 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

오늘 소개해드릴 글은 라인플러스의 손수림님이 번역해주신 글입니다. 이 글에서는 테스트 커버리지, 문서 작성, 유효한 버전 관리, 변경 로그 관리 등 패키지 개발의 다양한 측면을 다루고 있으며 특히 패키지의 크기를 최소화하는 방법에 초점을 맞추고 있습니다. 글은 크게 두 가지 부분로 나뉘어지며 첫 번째 부분에서는 의존성 설정과 빌드 프로세스와 같은 일반적인 팁을, 두 번째 부분에서는 개발자 경험(DX)을 약간 희생하면서도 패키지 크기를 더 작게 만드는 구체적인 코드 작성 방법을 설명합니다. 각종 최적화 팁과 더불어 코드 예제와 설명이 포함되어 있어 패키지 배포에 관심이 있으신 분들은 가볍게 읽어보시는 것을 추천드립니다. :) &gt; 글 링크 : https://velog.io/@surim014/extremely-reducing-the-size-of-npm-packages

Velog

NPM 패키지 크기 대폭 축소하기

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설. 모든 내용 하나하나가 주옥같았다. 일등 하는 사람들은 항상 배울 것이 있다. 그것도 전 세계 1등이니까. 그 사람이 거기까지 가는 데 있어서 내면적으로 겪은 경험들은... 아주 값진 지혜들을 담고 있다. 모든 내용들이 다 좋았지만, 나는 캡처한 부분이 제일 좋았다.

로저 페더러 다트머스 졸업연설

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.

1) Effortless is a myth. (공짜는 없다)
우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.

로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.

나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."

각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.

2) It's only a point. (그저 1 포인트일 뿐이다)
테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.

"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."

월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.

"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it."

어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.

3) Life is bigger than a court.
16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.

내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.

https://www.youtube.com/watch?v=t8v0cHn_LRc

테니스 황제라고 불리는 로저 페더러의 최근 다트머스 졸업 연설이 인상적이다. 그가 이제 대학을 졸업하고 사회로 나가는 졸업생들과 나눈 세 가지 메시지에 내 생각을 얹어본다.​1) Effortless is a myth. (공짜는 없다)우린 모두 타고난 각자의 재능이 있다. 기가 막힌 음색을 가지고 태어난 사람도 있고, 숫자에 능한 사람도 있고, 동물적으로 운동감각이 뛰어난 사람도 있다. 성공하려면 타고난 재능을 가지고 있어야 한다는 말도 맞을지 모르겠다. 그래서일까? 우리는 종종 성공한 사람들을 보며 타고난 재능이라고 치부해 버리기도 하고, 쉽게 해내는 (것처럼 보이는) 결과물을 보며 그 자리까지 가기 위해 흘린 피 땀 눈물을 외면해 버리기도 한다.​로저 페더러는 자신이 테니스 선수에게 필요한 재능을 타고났음을 인정하면서(타고난 재능을 커리어와 연결시키는 건 매우 중요하다), 타고난 재능만으로는 성공할 수 없음을 강조한다. "Believe in yourself has to be earned."라며 자신에 대한 믿음은 경기를 승리로 이끄는데 꼭 필요한 재능인데, 이는 타고난 재능이 아니라 각고의 노력으로 얻어내야 하는 재능이라고 말한다. 인내심과 끈기, 과정을 즐길 수 있는 여유, 자기 관리... 이 모든 게 치열한 자신과의 싸움으로 만들어낸 재능이라는 것이다. 나는 개인적으로 "to be earned"라는 말을 좋아한다. 우리의 성공이 타고난 재능으로 결정된다면 억울하고 재미없는 삶이 되겠지만, 내가 노력해서 얻어낸 재능으로 성공을 만들 수 있다면 살아볼 만한 인생이라는 에너지가 생긴다.​나는 최근 일적으로 폭풍 속을 걷는 것 같은 시기를 보내고 있는데, 자기 확신, 회복력, 긍정적 마인드 이 세 재능을 바닥내지 않고 든든하게 키우기 위해 노력 중이다. 새로운 프로젝트를 리딩하고 팀을 매니징하고 의사결정을 내리는데 자기 확신은 필수이다. 그렇지 않으면 매사 불안감이 커져서 잘못된 판단을 내리거나, 결정을 미루거나, 책임을 전가해 버리는 결과를 내기 쉽다. 새로운 일을 시도할 때는 (특히 제로투원을 만들어 낼 때는) 실수나 실패를 했을 때 빠르게 인정하고 회복할 수 있어야 한다. 한 번에 성공하는 게 목표가 아니라 빠르게 실패하고 그걸 발판으로 또다시 시도하거나 피벗을 하면서 방향을 잡아 가는게 중요하기 때문이다. 실수나 실패에 타격이 큰 사람은 오래 버틸 수가 없다. 자기 확신과 회복력은 긍정적 마인드를 베이스로 한다. 괜찮다는 마음, 할 수 있다는 마음, 까짓것 일단 한번 해보지 뭐, 아님 말고! 하는 초긍정 마인드가 성공에 꼭 필요한 재능이고, 이건 타고난 재능이 아니라 치열한 노력으로 만들어진다. "Belive in yourself has to be earned."​각자 가진 재능을 잘 살펴보고 어떤 재능을 더 키워야 하는지 적어보면 어떨까. 성실한 것도, 잘 웃는 것도, 친화력 있는 것도, 책임감이 있는 것도 모두 노력으로 얻어야 하는 재능들이다.​2) It's only a point. (그저 1 포인트일 뿐이다)테니스의 황제라고 불리는 로저 페더러의 한 세트 평균 승률은 54%. 세계 최고 탑 플레이어이지만 승률은 50% 정도라는 것이다. (야구도 3할이면 최강 타자라고 불린다). 한 포인트는 승부사에게 매우 중요한 순간이지만(그래서 한 포인트를 얻기 위해 최선을 다해야 하지만), 졌을 땐 그저 한 포인트로 진거 일뿐이라는 거다. 진 포인트에 연연하면 다음 포인트를 놓치게 된다. 인생을 살다 보면 1 포인트를 잃게 되는 경우가 흔히 생기는데, 1 포인트는 그저 1 포인트일 뿐. It's OK. It's only a point. 인생 최고의 샷을 만들었다면? 그 또한 1 포인트일 뿐이다.​"When you're playing a point, it has to be the most important thing in the world and it is. But when it's behind you it's behind you. This mindset is really crucial because it frees you to fully commit to the next point and the next point after, with intensity, clarify, and focus. The truth is whatever game you play in life, sometimes you're going to lose; a point, a match, a season, a job.. it's a roller coaster with many ups and downs, but negative energy is wasted energy. You want to become a master at overcoming hard moments. That is a sign of a champion."​월드 챔피언은 모든 경기를 이겨서가 아니라, 자신의 패배를 다루는 법을 잘 알고 훈련한 사람이라고 강조한다.​"The best in the world are not the best because they win every point. But it's because they know they lose again and again and have learned how to deal with it." 어느 날은 일을 잘 해낸 것 같아서 뿌듯하다가, 어느 날은 다 망친 것 같아서 자괴감에 빠질 때도 있다. 동료들에게 칭찬을 듣기도 하고 비난을 받기도 한다. 내가 만든 결과물이 졸작인 것 같아서 다 버리고 싶은 날들이 이어지기도 한다. 성공도 실패도 그저 내 커리어 인생에 1 포인트일 뿐이다. 1포인트로 게임에서 진 것보다, 더 위험한 게 '난 역시 안 되나 봐', '자존심 상해서 그만뒀어', '다시 도전한 엄두가 안 나' 이런 마음으로 이어지는 패배감이다. 그저 1 포인트라는 걸 상기하자. 세계 최강 선수도 승률이 50%이고, 최강 타자도 3할인데, 평범한 내가 매번 성공한다면 그게 더 이상한 거다. 일희일비하지 말자. 그저 1 포인트씩 쌓아가는 거다.​3) Life is bigger than a court.16살에 테니스 커리어를 시작해서 24년 동안 테니스 코트에서 살았고 테니스에서 인생을 배웠다고 생각했는데, 2022년에 은퇴를 하고 보니 자신이 몰랐던 큰 세상이 있더라는 깨달음.​내가 처한 상황이 절망적이라고 느껴질 때, 내가 손에 쥐고 있는 걸 놓으면 세상이 무너질 것 같은 두려움이 생길 때, 나만 뒤처지고 억울한 것 같다는 생각이 밀려올 때.. 내 눈에 가림막을 하고 무작정 달리고 있는 건 아닌지 멈춰서 살펴봐야 한다. 생각해 보면 내가 만나는 사람들의 숫자도 지극히 제한적이고, 내가 속한 커리어 분야도 매우 협소하고 (게다가 나는 내가 하는 일 외엔 모르는 게 너무 많다), 내가 경험한 세계도 고작 몇몇 나라와 도시들뿐이다. 여행을 하면 내가 모르는 세상과 만나게 되는 게 가장 큰 인생 배움이 된다. 세상은 넓고, 사람들은 다양하고, 삶은 다 각자 다른 모습으로 꽃을 피운다. 인생을 내 커리어 코트에 묶어 놓는다면 경기가 끝났을 때 멘붕이 올 것이다. 커리어는 커리어일 뿐, 인생 전부가 아니다. 꼭 명심하자.​https://www.youtube.com/watch?v=t8v0cHn_LRc

YouTube

로저 페더러에게 배우는 성공의 비결

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다.

“Talk is cheap, show me the code.”

AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다.

“Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명언이 있다. “Talk is cheap, show me the code.” AI가 대신 코딩해주는 시대에, 이제 이 말은 다음처럼 바뀌어야 하지 않을까 싶다. “Code is cheap, talk about value.”

리눅스의 창시자인 리누스 토발즈의 유명한 말 중에 다음과 같은 명

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다.

1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까?
- 예시: 플라스틱 빨대를 종이 빨대로 대체하기.

2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까?
- 예시: 스마트폰과 카메라 기능 결합.

3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까?
- 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용.

4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까?
- 예시: 기존 제품의 색상이나 크기 변경.

5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까?
- 예시: 와인병을 꽃병으로 사용.

6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까?
- 예시: 제품의 복잡한 기능을 제거하고 단순화.

7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까?
- 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

SCAMPER는 아이디어 발상을 도와주는 창의적 사고도구입니다. 각각의 알파벳은 아이디어를 발전시키기 위한 구체적인 질문을 나타냅니다. 1. Substitute (대체하기): 어떤 요소를 다른 것으로 바꿀 수 있을까? - 예시: 플라스틱 빨대를 종이 빨대로 대체하기. 2. Combine (결합하기): 두 가지 요소를 결합하면 새로운 것이 나올까? - 예시: 스마트폰과 카메라 기능 결합. 3. Adapt (적용하기): 다른 분야에서 성공한 아이디어를 적용할 수 있을까? - 예시: 자동차 좌석의 열선 기능을 사무실 의자에 적용. 4. Modify (변형하기): 기존 아이디어를 어떻게 변형할 수 있을까? - 예시: 기존 제품의 색상이나 크기 변경. 5. Put to another use (다른 용도로 사용하기): 다른 방식으로 활용할 수 있을까? - 예시: 와인병을 꽃병으로 사용. 6. Eliminate (제거하기): 불필요한 요소를 제거할 수 있을까? - 예시: 제품의 복잡한 기능을 제거하고 단순화. 7. Reverse (반대로 생각하기): 순서를 뒤집거나 반대로 해볼 수 있을까? - 예시: 패키지 배송을 고객이 직접 픽업하게 하기.

아이디어가 잘 안생길 때 쓸 수 있는 프레임워크 SCAMPER 💡

네이버·카카오 스톡옵션 대박... 직원들 수억씩 챙긴다

"직급에 관계없이 성과에 따라 보상하는 것은 오래전부터 미국 실리콘밸리 기업의 성장 동력으로 자리 잡았다. 과거처럼 '회사가 먼저'라는 생각보다 성과 공유로 직원에게 동기를 유발할 수 있어야 지속 성장이 가능해진 시대"

카카오 여민수, 조수용 대표는 각각 173억원, 154억원. 네이버 한성숙 대표는 43억원. 카카오와 네이버의 주가가 급등하면서 스톡옵션 대박을 터뜨린 경영자와 직원들이 나오기 시작. 네이버는 지난해부터 전직원에게 스톡옵션을 주고 있다고. 실리콘밸리처럼 국내에서도 성장의 과실을 회사의 구성원과 함께 나누는 회사들이 많이 나올듯. 그래야 유능한 인재들이 모여들테니까.

Naver

서동환

황경호

마케팅

이재윤

대표

브랜드 마케터

브랜드 컨설턴트

광고기획자

Business

TBWA KOREA에서 광고를 시작해서 현재 광고대행사 이노션의 기획자(AE)로 일하고 있다. '임팩트가 없으면 죽음을' 이라는 모토를 가지고 광고를 만든다. 무신사 '다 여기서 사',  구글 어시스턴트 'Google에게 시키세요', 우르오스 '남자공학적' 같은 히트 캠페인을 기획했다.  현재 페이스북과 브런치에서 브랜드에 대한 재미있는 인사이트를 전하고 있다. 올 9월, 팔리는 브랜드의 비결을 담은 '드디어 팔리기 시작했다'를 출간했다.

브랜드보이

Brunch

Facebook

Youtube

브랜드 컨설팅 회사 <브랜드보이> 대표이자 유튜버, 작가, 강연자. 브랜드보이는 브랜드에 미친 남자다. 브랜드와 놀고, 브랜드로 돈까지 번다. 광고회사 TBWA, 이노션의 기획자를 거쳐 토스의 브랜드 마케터로 일했다. <믹스> <드디어 팔리기 시작했다>를 출간했다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필