OpenAI가 o1을 정식으로 발표하면서, 이미지까지 인식할 수 있는 멀티모달 기능을 더했네요. 더불어 기존의 $20 짜리 유료 구독에 더해 $200 짜리 유료 구독을 추가했습니다. 모든 고급 모델과 음성 모드를 무제한으로 쓸 수 있는 요금제입니다.

추가로 pro 요금제는 o1에 대해서 pro 모드를 사용할 수 있는 요금제인데요. 더 길게 생각(더 많은 컴퓨팅 자원을 사용)하는 모드로, 더 복잡하고 어려운 문제에 답변 할 수 있는 모드입니다.

과연 얼마나 어려운 문제를, 그리고 얼마나 답변의 품질 수준이 높아졌을지 궁금하긴 한데..너무 비싸서 좀 고민이 되네요. 🥹 우선은 다른 분들의 후기를 기대해봐야겠습니다.

OpenAI가 o1을 정식으로 발표하면서, 이미지까지 인식할 수 있는 멀티모달 기능을 더했네요. 더불어 기존의 $20 짜리 유료 구독에 더해 $200 짜리 유료 구독을 추가했습니다. 모든 고급 모델과 음성 모드를 무제한으로 쓸 수 있는 요금제입니다. 추가로 pro 요금제는 o1에 대해서 pro 모드를 사용할 수 있는 요금제인데요. 더 길게 생각(더 많은 컴퓨팅 자원을 사용)하는 모드로, 더 복잡하고 어려운 문제에 답변 할 수 있는 모드입니다. 과연 얼마나 어려운 문제를, 그리고 얼마나 답변의 품질 수준이 높아졌을지 궁금하긴 한데..너무 비싸서 좀 고민이 되네요. 🥹 우선은 다른 분들의 후기를 기대해봐야겠습니다.

Two people in the same company can have completely different experiences, often depending on one crucial factor — their manager.

Am I working with the right manager?

회사에서 느끼는 경험은 리더와 함께 크게 달라지곤 합니다. 좋은 리더를 만난 사람은 자신의 커리어에서 큰 이점을 누리지만, 그 반대의 경우도 존재합니다. 중요한 것은 '좋은' 리더가 아니라, 나에게 '맞는' 리더와 함께 하는 것일텐데요. 이 글에서는 리더의 스타일을 분석하고, 나와 맞는 리더를 발견할 수 있는 방법을 알려줍니다.

 1. 🛠️ 프로세스 중심 리더
 * 강점:
   * 효율적인 워크플로우와 프로세스를 구축.
   * 일정과 마감일 점검으로 프로젝트 유지.
   * 회고를 통해 지속적인 개선.
   * 상세한 문서를 작성하여 팀을 위한 지침 제공.
 * 도전 과제:
   * 새로운 방법이나 기술에 적응하는 데 어려움.
   * 프로세스 중시로 창의성 억제 가능성.
   * 개인별 강점과 필요를 간과할 가능성.
   * 지나친 프로세스 의존으로 의사 결정 지연.

 2. 🤝 사람 중심 리더
 * 강점:
   * 팀원의 복지와 커리어 목표 우선.
   * 성과와 기여를 인정하며 사기를 북돋음.
   * 열린 대화와 건강한 논쟁 장려.
   * 팀과 작업물을 보호하며 신뢰 구축.
 * 도전 과제:
   * 갈등 회피로 어려운 대화를 피하는 경향.
   * 과도한 합의 추구로 의사 결정 지연.
   * 관계 중심 접근으로 정서적 소진 위험.
   * 지나치게 돌보는 방식으로 권위 약화 가능성.

 3. ✏️ 실무형 리더
 * 강점:
   * 브레인스토밍과 디자인 검토에 적극 참여.
   * 실질적이고 구체적인 피드백 제공.
   * 프로젝트 상황을 면밀히 파악하여 지원.
   * 자신의 경험과 통찰을 공유해 팀의 성장 유도.
 * 도전 과제:
   * 지나친 관여로 팀의 자율성 침해 가능성.
   * 과도한 책임 부여로 위임의 어려움.
   * 과잉 가이드로 팀원의 성장 제한.
   * 매니저의 참여가 병목현상으로 작용 가능.

 4. 🎯 전략적 리더
 * 강점:
   * 명확한 비전을 제시하며 팀의 방향성을 설정.
   * 부서 간 협업을 촉진하여 공통 목표 달성.
   * 산업 트렌드를 공유하며 창의적 사고 촉진.
   * 큰 그림을 강조하며 팀원이 넓은 관점을 갖도록 함.
 * 도전 과제:
   * 장기적 비전과 단기적 요구의 균형 어려움.
   * 팀원의 세부 작업에 대한 맥락 부족.
   * 비전을 실행 가능한 단계로 세분화하는 데 어려움.
   * 추상적인 피드백으로 실행 어려움 발생.

나와 맞는 리더인지 질문 던져보기
 * 성공적인 디자인 팀은 어떤 모습이라고 생각하시나요?
 * 피드백과 성과 평가를 어떻게 접근하시나요?
 * 팀 내 갈등이나 도전을 어떻게 해결하시나요?
 * 팀원들은 당신과 일하는 것을 어떻게 묘사할까요?
 * 마지막으로 승진시킨 사람은 누구였고, 그 이유는 무엇인가요?

여러분들의 지금 리더는 어떤 리더인가요? 그리고 지금 여러분의 성장과 잘 맞는 리더인가요?

https://uxplanet.org/am-i-working-with-the-right-manager-d15bb1b43809

회사에서 느끼는 경험은 리더와 함께 크게 달라지곤 합니다. 좋은 리더를 만난 사람은 자신의 커리어에서 큰 이점을 누리지만, 그 반대의 경우도 존재합니다. 중요한 것은 '좋은' 리더가 아니라, 나에게 '맞는' 리더와 함께 하는 것일텐데요. 이 글에서는 리더의 스타일을 분석하고, 나와 맞는 리더를 발견할 수 있는 방법을 알려줍니다. <ol ><li>🛠️ 프로세스 중심 리더</li></ol><ul ><li>강점:<ul ><li>효율적인 워크플로우와 프로세스를 구축.</li><li>일정과 마감일 점검으로 프로젝트 유지.</li><li>회고를 통해 지속적인 개선.</li><li>상세한 문서를 작성하여 팀을 위한 지침 제공.</li></ul></li><li>도전 과제:<ul ><li>새로운 방법이나 기술에 적응하는 데 어려움.</li><li>프로세스 중시로 창의성 억제 가능성.</li><li>개인별 강점과 필요를 간과할 가능성.</li><li>지나친 프로세스 의존으로 의사 결정 지연.</li></ul></li></ul> <ol start="2"><li>🤝 사람 중심 리더</li></ol><ul ><li>강점:<ul ><li>팀원의 복지와 커리어 목표 우선.</li><li>성과와 기여를 인정하며 사기를 북돋음.</li><li>열린 대화와 건강한 논쟁 장려.</li><li>팀과 작업물을 보호하며 신뢰 구축.</li></ul></li><li>도전 과제:<ul ><li>갈등 회피로 어려운 대화를 피하는 경향.</li><li>과도한 합의 추구로 의사 결정 지연.</li><li>관계 중심 접근으로 정서적 소진 위험.</li><li>지나치게 돌보는 방식으로 권위 약화 가능성.</li></ul></li></ul> <ol start="3"><li>✏️ 실무형 리더</li></ol><ul ><li>강점:<ul ><li>브레인스토밍과 디자인 검토에 적극 참여.</li><li>실질적이고 구체적인 피드백 제공.</li><li>프로젝트 상황을 면밀히 파악하여 지원.</li><li>자신의 경험과 통찰을 공유해 팀의 성장 유도.</li></ul></li><li>도전 과제:<ul ><li>지나친 관여로 팀의 자율성 침해 가능성.</li><li>과도한 책임 부여로 위임의 어려움.</li><li>과잉 가이드로 팀원의 성장 제한.</li><li>매니저의 참여가 병목현상으로 작용 가능.</li></ul></li></ul> <ol start="4"><li>🎯 전략적 리더</li></ol><ul ><li>강점:<ul ><li>명확한 비전을 제시하며 팀의 방향성을 설정.</li><li>부서 간 협업을 촉진하여 공통 목표 달성.</li><li>산업 트렌드를 공유하며 창의적 사고 촉진.</li><li>큰 그림을 강조하며 팀원이 넓은 관점을 갖도록 함.</li></ul></li><li>도전 과제:<ul ><li>장기적 비전과 단기적 요구의 균형 어려움.</li><li>팀원의 세부 작업에 대한 맥락 부족.</li><li>비전을 실행 가능한 단계로 세분화하는 데 어려움.</li><li>추상적인 피드백으로 실행 어려움 발생.</li></ul></li></ul> 나와 맞는 리더인지 질문 던져보기<ul ><li>성공적인 디자인 팀은 어떤 모습이라고 생각하시나요?</li><li>피드백과 성과 평가를 어떻게 접근하시나요?</li><li>팀 내 갈등이나 도전을 어떻게 해결하시나요?</li><li>팀원들은 당신과 일하는 것을 어떻게 묘사할까요?</li><li>마지막으로 승진시킨 사람은 누구였고, 그 이유는 무엇인가요?</li></ul> 여러분들의 지금 리더는 어떤 리더인가요? 그리고 지금 여러분의 성장과 잘 맞는 리더인가요? https://uxplanet.org/am-i-working-with-the-right-manager-d15bb1b43809

Medium

나에게 맞는 리더와 함께 일하고 있는 걸까?

 [유머] 왜 소프트웨어 개발은 예상보다 2~3배 더 오래 걸리는가? · Soojin Ro 

예전에 읽었던 글인데 오랜만에 다시 봤어요 ㅋㅋㅋㅋ

“이거 3일 걸릴 것 같은데요?”
그리고 현실은 3주. 🙃

추정이란 기본적으로 틀리기 마련인데요, 여러분들은 어떻게 하고 계신가요!?

https://soojin.ro/blog/sw-estimation

예전에 읽었던 글인데 오랜만에 다시 봤어요 ㅋㅋㅋㅋ “이거 3일 걸릴 것 같은데요?” 그리고 현실은 3주. 🙃 추정이란 기본적으로 틀리기 마련인데요, 여러분들은 어떻게 하고 계신가요!? https://soojin.ro/blog/sw-estimation

soojin.ro

왜 스프트웨어 개발은 예상보다 2~3배 더 오래 걸리는가?

From 14:54 UTC on the 12th September until 01:33 UTC on the 13th September, Lichess experienced the longest downtime in its history.

Post-Mortem of our Longest Downtime

한 번이라도 서버가 다운되어 당황했던 적이 있으신가요? 특히 예상치 못한 문제가 발생했을 때 어떻게 대처할지 명확하지 않다면 더 혼란스러울 수밖에 없습니다. 오픈 소스와 커뮤니티의 도움으로 운영되는 Lichess는 최근 10시간 동안의 서버 중단이라는 역대 최장의 장애를 경험했습니다. 포스트 모템 글을 통해서 장애의 원인, 대응 과정, 그리고 재발 방지를 위한 계획을 투명하게 설명하며, 개발자와 관리자들에게 유용한 교훈을 다루고 있습니다.

1. 발생 배경
 * 문제 발생 시각: 2024년 9월 12일 14:54 UTC, 핵심 서버인 'Manta'에서 네트워크 연결이 갑작스레 끊김.
 * 원인: OVH 데이터 센터의 물리적 네트워크 하드웨어 문제로 확인.
   * 초기 점검 시에는 네트워크 문제가 간헐적으로 해결되는 것처럼 보였으나, 이후 네트워크 커넥터가 완전히 손상됨.
   * OVH 기술자들이 데이터 센터를 방문해 직접 하드웨어를 교체하는 작업이 필요했음.
 * 복잡성 추가: 네트워크 문제 해결 후에도 시스템이 정상 작동하지 않아, 여러 번의 추가 복구 시도가 이루어짐.

2. 대응 과정
 * 즉각적 복구 시도: Lichess의 창립자 Thibault와 핵심 관리자 Lucas가 즉각적인 원격 복구 작업을 시도.
   * Manta 서버가 다운되자, 중계 및 게임 데이터를 다른 서버로 옮겨 서비스 유지를 시도.
 * 백업 서비스 가동: 장애 상황에서도 체스 올림피아드 경기 중계는 백업 시스템에서 지속적으로 진행.
   * 그러나 일반 사용자의 게임 및 일부 기능은 제한될 수밖에 없었음.
 * 커뮤니티와 소통: Lichess는 실시간으로 장애 상황을 투명하게 공유하며, 커뮤니티의 신뢰를 유지하려 노력.
   * SNS 및 공지를 통해 상황 업데이트 제공.
 * 최종 해결: OVH 데이터 센터 기술자가 손상된 하드웨어를 교체하고 네트워크 문제를 복구한 뒤 정상 운영이 가능해짐.

3. 장애 후 계획
 * 상세 원인 조사: OVH와 협력해 네트워크 하드웨어 결함의 원인을 분석 중.
 * 재발 방지 대책:
   * 다중 페일세이프(fail-safe) 옵션 추가 검토.
   * 네트워크 문제 발생 시 자동으로 다른 서버로 트래픽을 전환하는 기능 강화.
 * 운영 구조 개선: 대부분의 팀원이 자원봉사로 일하고 있으므로, 자원 관리와 추가 인프라에 대한 효율적인 계획 수립 필요.

 4. 추가 FAQ와 커뮤니티 반응
 * 레이트 점수 복구 문제:
   * 서버 장애로 인해 종료된 게임의 레이팅 점수 복구는 불가능.
   * 하지만 대부분의 경우 사용자는 몇 차례의 게임을 통해 자신의 적정 레이팅으로 자연 복구 가능.
 * 흑/백 색상 불균형 문제:
   * 최근 업데이트된 기능으로 인해 흑백 배정이 균형적이지 않은 문제가 발생.
   * 이는 서버 다운과는 별개이며, 개선 중.

커뮤니티의 반응
 * 많은 사용자가 Lichess의 투명하고 신속한 대응에 감사의 뜻을 전함.
 * 장애 동안 발생한 불편에도 불구하고 Lichess의 기술적 도전과 커뮤니티 중심의 운영 방식을 높이 평가.
   
   

https://lichess.org/@/Lichess/blog/post-mortem-of-our-longest-downtime/XAgG7jbd

한 번이라도 서버가 다운되어 당황했던 적이 있으신가요? 특히 예상치 못한 문제가 발생했을 때 어떻게 대처할지 명확하지 않다면 더 혼란스러울 수밖에 없습니다. 오픈 소스와 커뮤니티의 도움으로 운영되는 Lichess는 최근 10시간 동안의 서버 중단이라는 역대 최장의 장애를 경험했습니다. 포스트 모템 글을 통해서 장애의 원인, 대응 과정, 그리고 재발 방지를 위한 계획을 투명하게 설명하며, 개발자와 관리자들에게 유용한 교훈을 다루고 있습니다. 1. 발생 배경<ul ><li>문제 발생 시각: 2024년 9월 12일 14:54 UTC, 핵심 서버인 'Manta'에서 네트워크 연결이 갑작스레 끊김.</li><li>원인: OVH 데이터 센터의 물리적 네트워크 하드웨어 문제로 확인.<ul ><li>초기 점검 시에는 네트워크 문제가 간헐적으로 해결되는 것처럼 보였으나, 이후 네트워크 커넥터가 완전히 손상됨.</li><li>OVH 기술자들이 데이터 센터를 방문해 직접 하드웨어를 교체하는 작업이 필요했음.</li></ul></li><li>복잡성 추가: 네트워크 문제 해결 후에도 시스템이 정상 작동하지 않아, 여러 번의 추가 복구 시도가 이루어짐.</li></ul> 2. 대응 과정<ul ><li>즉각적 복구 시도: Lichess의 창립자 Thibault와 핵심 관리자 Lucas가 즉각적인 원격 복구 작업을 시도.<ul ><li>Manta 서버가 다운되자, 중계 및 게임 데이터를 다른 서버로 옮겨 서비스 유지를 시도.</li></ul></li><li>백업 서비스 가동: 장애 상황에서도 체스 올림피아드 경기 중계는 백업 시스템에서 지속적으로 진행.<ul ><li>그러나 일반 사용자의 게임 및 일부 기능은 제한될 수밖에 없었음.</li></ul></li><li>커뮤니티와 소통: Lichess는 실시간으로 장애 상황을 투명하게 공유하며, 커뮤니티의 신뢰를 유지하려 노력.<ul ><li>SNS 및 공지를 통해 상황 업데이트 제공.</li></ul></li><li>최종 해결: OVH 데이터 센터 기술자가 손상된 하드웨어를 교체하고 네트워크 문제를 복구한 뒤 정상 운영이 가능해짐.</li></ul> 3. 장애 후 계획<ul ><li>상세 원인 조사: OVH와 협력해 네트워크 하드웨어 결함의 원인을 분석 중.</li><li>재발 방지 대책:<ul ><li>다중 페일세이프(fail-safe) 옵션 추가 검토.</li><li>네트워크 문제 발생 시 자동으로 다른 서버로 트래픽을 전환하는 기능 강화.</li></ul></li><li>운영 구조 개선: 대부분의 팀원이 자원봉사로 일하고 있으므로, 자원 관리와 추가 인프라에 대한 효율적인 계획 수립 필요.</li></ul> <ol start="4"><li>추가 FAQ와 커뮤니티 반응</li></ol><ul ><li>레이트 점수 복구 문제:<ul ><li>서버 장애로 인해 종료된 게임의 레이팅 점수 복구는 불가능.</li><li>하지만 대부분의 경우 사용자는 몇 차례의 게임을 통해 자신의 적정 레이팅으로 자연 복구 가능.</li></ul></li><li>흑/백 색상 불균형 문제:<ul ><li>최근 업데이트된 기능으로 인해 흑백 배정이 균형적이지 않은 문제가 발생.</li><li>이는 서버 다운과는 별개이며, 개선 중.</li></ul></li></ul> 커뮤니티의 반응<ul ><li>많은 사용자가 Lichess의 투명하고 신속한 대응에 감사의 뜻을 전함.</li><li>장애 동안 발생한 불편에도 불구하고 Lichess의 기술적 도전과 커뮤니티 중심의 운영 방식을 높이 평가. </li></ul> https://lichess.org/@/Lichess/blog/post-mortem-of-our-longest-downtime/XAgG7jbd

lichess.org

기술적 문제는 누구도 피할 수 없습니다

사내 메신저에 피드백을 요청하는 설문이 올라왔어요. 한 달 전에 입사한 동료가 직접 만든 설문이었죠.

정식 피드백을 받기 전에 직접 피드백을 수집해 미리 개선하려는 거라고 했어요.

결과는 어땠을까요? 그 동료는 나날이 성장했고 멋지게 수습을 통과했어요.

그때 배웠어요. 빠른 검증을 통한 개선이 제품에만 적용되는 게 아니라는 걸.

사내 메신저에 피드백을 요청하는 설문이 올라왔어요. 한 달 전에 입사한 동료가 직접 만든 설문이었죠. 정식 피드백을 받기 전에 직접 피드백을 수집해 미리 개선하려는 거라고 했어요. 결과는 어땠을까요? 그 동료는 나날이 성장했고 멋지게 수습을 통과했어요. 그때 배웠어요. 빠른 검증을 통한 개선이 제품에만 적용되는 게 아니라는 걸.

피드백 주실 수 있을까요?

만약 데이터에 파이썬 자료 구조(예: 딕셔너리, 리스트 등)이 문자열 형태로 저장되어 있다면,
ast
패키지를 사용해보세요.

따로 처리할 필요없이
ast.literal_eval
함수만 사용하면, 알아서 파이썬 문법을 인식하고 자료 구조 형태로 변경해줍니다.

만약 데이터에 파이썬 자료 구조(예: 딕셔너리, 리스트 등)이 문자열 형태로 저장되어 있다면, <code >ast</code>패키지를 사용해보세요. 따로 처리할 필요없이 <code >ast.literal_eval</code> 함수만 사용하면, 알아서 파이썬 문법을 인식하고 자료 구조 형태로 변경해줍니다.

🐍 파이썬 꿀팁

12월 우아한테크세미나 가 개최되네요. 이번 주제는 올해의 기술 콘퍼런스, 핵심만 담아봤습니다 - LLM 인데요. 카카오 개발자 컨퍼런스인 ‘if(kakao)2024’ 와 팀네이버 통합 컨퍼런스 ‘DAN24’의 연사분들을 초청해서 LLM 기반 서비스활용 사례를 되짚어 본다고 합니다.

세미나 일정
 * 2024. 12. 17.(화) 저녁 6시, 약 90분간
 * 우아한테크 YouTube 채널 실시간 스트리밍

신청 기간
 * 2024. 12. 17.(화) 당일까지
   * 신청하신 분께는 세미나가 끝난 뒤 발표 자료(.pdf)를 제공 한다고 합니다.

LLM에 관심이 많으신 분이라면 좋은 기회가 될 것 같습니다.

https://techblog.woowahan.com/20702/

12월 우아한테크세미나 가 개최되네요. 이번 주제는 올해의 기술 콘퍼런스, 핵심만 담아봤습니다 - LLM 인데요. 카카오 개발자 컨퍼런스인 ‘if(kakao)2024’ 와 팀네이버 통합 컨퍼런스 ‘DAN24’의 연사분들을 초청해서 LLM 기반 서비스활용 사례를 되짚어 본다고 합니다. 세미나 일정<ul ><li>2024. 12. 17.(화) 저녁 6시, 약 90분간</li><li>우아한테크 YouTube 채널 실시간 스트리밍</li></ul> 신청 기간<ul ><li>2024. 12. 17.(화) 당일까지 * 신청하신 분께는 세미나가 끝난 뒤 발표 자료(.pdf)를 제공 한다고 합니다.</li></ul> LLM에 관심이 많으신 분이라면 좋은 기회가 될 것 같습니다. https://techblog.woowahan.com/20702/

12월 우아한테크 세미나: LLM트렌드

Have you ever started something but never finished it, like learning a new language, a regimented...

Consistency is King, and here's why.

여러분은 새로운 기술을 배우거나 목표를 세웠지만, 중도에 포기했던 경험이 있나요? 이 글은 그러한 실패를 극복하고 목표를 달성하는 데 있어 "꾸준함"이 얼마나 중요한지를 보여줍니다. 하루하루의 작은 노력이 쌓여 어떤 성과를 만들어낼 수 있는지, 그리고 그 과정을 어떻게 유지할 수 있을까요?

1. 작은 단위로 목표를 쪼개는 중요성
 * 큰 목표는 압도적으로 느껴질 수 있지만, 이를 작은 단위로 나누면 실행 가능성이 높아짐.
 * 하루 10분이라도 지속적으로 시간을 투자하는 습관이 성과로 이어짐.
   * 예시: 웹 애플리케이션 개발 시 전체 기능을 생각하기보다 버튼 한 개를 만드는 작업부터 시작.
2. 꾸준함이 가져오는 점진적 성장
 * 처음에는 작고 간단한 일부터 시작해 조금씩 확장.
   * 예시:
     * 첫째 주에는 매일 5분 그림 그리기.
     * 그다음 주에는 10분, 이후 20분으로 늘리며 기술과 자신감을 동시에 성장시킴.
 * 이 과정에서 점점 더 복잡한 목표에도 도전 가능.
3. 실패를 성장의 기회로 받아들이기
 * 실패는 자연스러운 과정이며, 이를 통해 문제 해결 능력을 키울 수 있음.
 * 일관성을 유지하며 작은 실패를 학습의 기회로 삼을 때, 장기적인 성공 가능성이 높아짐.
   * 예시: 코드 작성 중 에러를 만났을 때, 원인을 분석하고 해결하며 지식을 쌓음.
4. 실생활 성공 사례
 * 저자는 "포켓몬 캐릭터 그리기"에서 시작해 현재는 복잡한 인물화를 그릴 수 있게 됨.
 * 매일 작은 그림 연습을 통해 그림의 스타일과 기술을 발전시킴.
 * 반복과 일관된 노력이 "어제보다 나은 나"를 만들어감.
5. 구체적인 목표 설정과 실행
 * 성공적인 일관성을 유지하기 위해 목표를 구체적이고 현실적으로 설정해야 함.
   * 좋은 목표의 예:
     * "하루에 블로그 글 한 문단 쓰기."
     * "매일 알고리즘 문제 한 개 풀기."
   * 이를 통해 성취감과 동기 부여를 지속적으로 얻을 수 있음.
 * 특히 개발자라면 프로젝트를 작은 기능별로 나누어 매일 실행 가능한 단계로 관리.
   * 예: "오늘은 로그인 버튼 디자인", "내일은 데이터베이스 연동"과 같은 세부 목표.
추가적인 팁
 * 일관성을 높이기 위한 도구 활용: To-do 리스트 앱, 캘린더 리마인더 등을 사용하여 꾸준함을 기록하고 관리.
 * 스스로 보상 제공: 목표를 달성했을 때, 좋아하는 음료를 마신다거나 휴식을 즐기며 자신을 격려.
 * 커뮤니티와의 공유: 목표를 다른 사람들과 공유하고, 피드백과 응원을 받을 때 동기 부여가 강화됨.

https://dev.to/choir241/consistency-is-king-and-heres-why-5ean

여러분은 새로운 기술을 배우거나 목표를 세웠지만, 중도에 포기했던 경험이 있나요? 이 글은 그러한 실패를 극복하고 목표를 달성하는 데 있어 "꾸준함"이 얼마나 중요한지를 보여줍니다. 하루하루의 작은 노력이 쌓여 어떤 성과를 만들어낼 수 있는지, 그리고 그 과정을 어떻게 유지할 수 있을까요? 1. 작은 단위로 목표를 쪼개는 중요성<ul ><li>큰 목표는 압도적으로 느껴질 수 있지만, 이를 작은 단위로 나누면 실행 가능성이 높아짐.</li><li>하루 10분이라도 지속적으로 시간을 투자하는 습관이 성과로 이어짐.<ul ><li>예시: 웹 애플리케이션 개발 시 전체 기능을 생각하기보다 버튼 한 개를 만드는 작업부터 시작.</li></ul></li></ul>2. 꾸준함이 가져오는 점진적 성장<ul ><li>처음에는 작고 간단한 일부터 시작해 조금씩 확장.<ul ><li>예시:<ul ><li>첫째 주에는 매일 5분 그림 그리기.</li><li>그다음 주에는 10분, 이후 20분으로 늘리며 기술과 자신감을 동시에 성장시킴.</li></ul></li></ul></li><li>이 과정에서 점점 더 복잡한 목표에도 도전 가능.</li></ul>3. 실패를 성장의 기회로 받아들이기<ul ><li>실패는 자연스러운 과정이며, 이를 통해 문제 해결 능력을 키울 수 있음.</li><li>일관성을 유지하며 작은 실패를 학습의 기회로 삼을 때, 장기적인 성공 가능성이 높아짐.<ul ><li>예시: 코드 작성 중 에러를 만났을 때, 원인을 분석하고 해결하며 지식을 쌓음.</li></ul></li></ul>4. 실생활 성공 사례<ul ><li>저자는 "포켓몬 캐릭터 그리기"에서 시작해 현재는 복잡한 인물화를 그릴 수 있게 됨.</li><li>매일 작은 그림 연습을 통해 그림의 스타일과 기술을 발전시킴.</li><li>반복과 일관된 노력이 "어제보다 나은 나"를 만들어감.</li></ul>5. 구체적인 목표 설정과 실행<ul ><li>성공적인 일관성을 유지하기 위해 목표를 구체적이고 현실적으로 설정해야 함.<ul ><li>좋은 목표의 예:<ul ><li>"하루에 블로그 글 한 문단 쓰기."</li><li>"매일 알고리즘 문제 한 개 풀기."</li></ul></li><li>이를 통해 성취감과 동기 부여를 지속적으로 얻을 수 있음.</li></ul></li><li>특히 개발자라면 프로젝트를 작은 기능별로 나누어 매일 실행 가능한 단계로 관리.<ul ><li>예: "오늘은 로그인 버튼 디자인", "내일은 데이터베이스 연동"과 같은 세부 목표.</li></ul></li></ul>추가적인 팁<ul ><li>일관성을 높이기 위한 도구 활용: To-do 리스트 앱, 캘린더 리마인더 등을 사용하여 꾸준함을 기록하고 관리.</li><li>스스로 보상 제공: 목표를 달성했을 때, 좋아하는 음료를 마신다거나 휴식을 즐기며 자신을 격려.</li><li>커뮤니티와의 공유: 목표를 다른 사람들과 공유하고, 피드백과 응원을 받을 때 동기 부여가 강화됨.</li></ul> https://dev.to/choir241/consistency-is-king-and-heres-why-5ean

DEV Community

꾸준함이 최고의 열쇠가 되는 이유

촬영하고 있는 TDD 강의 수업 영상 하나를 TDD나 테스트 자동화에 익숙하지 않은 지인에게 보여줬는데 두 가지를 느꼈다.

처음으로 시스템, 클라이언트, 인터페이스의 개념이 명확하지 않고 범위가 제한적이다. 기억에는 없지만 어쩌면 나도 테스트를 배우며 이런 개념이 더 선명해졌을 수도 있겠다는 생각도 든다.

두번째는, Mockist 테스팅 편향이 강하다. '모킹은 어떻게 해야하나?'라는 질문을 반복했다. 테스트 대역이 필요한 상황이 분명 있긴하지만 필요 이상으로 테스트 대역에 대한 집착이 강하다.

이젠 Mockist 테스팅이 안티 패턴이라는 것이 더 이상 논쟁거리가 아니게 되었지만 그건 숙련자들 사이에서의 일이고 다수 프로그래머들은 여전히 스스로 인지하지도 못한채 Mockist 사상에 오염되어 있다고 느껴왔다. 그게 TDD 강의를 준비하게 된 가장 큰 이유이기도 한데, 지인 반응을 통해서 더 확신하게 됐다.

그런데 나 역시 과거엔 Mockist였고 2014년에 Kent Beck이 '나는 테스트 대역을 거의 사용하지 않는다'라고 말해 충격을 받고 Classicist로 전향했다.

기대보다 촬영 진도가 느려서 조금 스트레스이긴 한데 더 집중해야겠다.

촬영하고 있는 TDD 강의 수업 영상 하나를 TDD나 테스트 자동화에 익숙하지 않은 지인에게 보여줬는데 두 가지를 느꼈다. 처음으로 시스템, 클라이언트, 인터페이스의 개념이 명확하지 않고 범위가 제한적이다. 기억에는 없지만 어쩌면 나도 테스트를 배우며 이런 개념이 더 선명해졌을 수도 있겠다는 생각도 든다. 두번째는, Mockist 테스팅 편향이 강하다. '모킹은 어떻게 해야하나?'라는 질문을 반복했다. 테스트 대역이 필요한 상황이 분명 있긴하지만 필요 이상으로 테스트 대역에 대한 집착이 강하다. 이젠 Mockist 테스팅이 안티 패턴이라는 것이 더 이상 논쟁거리가 아니게 되었지만 그건 숙련자들 사이에서의 일이고 다수 프로그래머들은 여전히 스스로 인지하지도 못한채 Mockist 사상에 오염되어 있다고 느껴왔다. 그게 TDD 강의를 준비하게 된 가장 큰 이유이기도 한데, 지인 반응을 통해서 더 확신하게 됐다. 그런데 나 역시 과거엔 Mockist였고 2014년에 Kent Beck이 '나는 테스트 대역을 거의 사용하지 않는다'라고 말해 충격을 받고 Classicist로 전향했다. 기대보다 촬영 진도가 느려서 조금 스트레스이긴 한데 더 집중해야겠다.

The library for web and native user interfaces

React v19 – React

React 19가 npm에 배포됐습니다.
요즘엔 프론트엔드보다 AI관련 업무를 주로 하면서 프론트엔드를 살짝 병행하는 중인데요, 왠지 이 속도를 따라가기가 점점 더 힘들어지는 것 같습니다. 그나마 Cursor와 같은 도구가 등장해서 다행이지만, 모델의 학습데이터가 업데이트 되기 전까지는 최신 내용을 활용하긴 어렵겠죠. RAG를 활용해서 별도의 봇을 구성해야할지 고민이 되는 순간입니다

https://react.dev/blog/2024/12/05/react-19

React 19가 npm에 배포됐습니다. 요즘엔 프론트엔드보다 AI관련 업무를 주로 하면서 프론트엔드를 살짝 병행하는 중인데요, 왠지 이 속도를 따라가기가 점점 더 힘들어지는 것 같습니다. 그나마 Cursor와 같은 도구가 등장해서 다행이지만, 모델의 학습데이터가 업데이트 되기 전까지는 최신 내용을 활용하긴 어렵겠죠. RAG를 활용해서 별도의 봇을 구성해야할지 고민이 되는 순간입니다 https://react.dev/blog/2024/12/05/react-19

react.dev

React 19 릴리스!

useEffect의 불필요한 사용은 리렌더링을 초래하고 이는 곧 웹의 성능 저하로 연결됩니다. 이 글에서는 코드 예시를 통해 useEffect를 올바르게 사용하는 방법을 제시합니다.

[번역] useEffect를 남용하지 마세요!

오늘은 네이버의 안샛별님이 번역해주신 글입니다.

리액트 개발자에게 리렌더링은 어떤 숙명과도 같은 존재일 것입니다. 단 한 줄의 코드만으로 리렌더링을 여러 번 유발할 수도, 한 번으로 감소시킬 수도 있습니다. 이 글은 useEffect의 잘못된 사용으로 인해 성능이 악화되는 사례를 정리하고 개선된 코드를 소개합니다. 어렵지 않은 글이라 리액트를 많이 해보지 않았더라도 가볍게 읽기 좋은 글이라고 생각합니다.

글 링크: https://velog.io/@typo/leave-useeffect-alone

오늘은 네이버의 안샛별님이 번역해주신 글입니다. 리액트 개발자에게 리렌더링은 어떤 숙명과도 같은 존재일 것입니다. 단 한 줄의 코드만으로 리렌더링을 여러 번 유발할 수도, 한 번으로 감소시킬 수도 있습니다. 이 글은 useEffect의 잘못된 사용으로 인해 성능이 악화되는 사례를 정리하고 개선된 코드를 소개합니다. 어렵지 않은 글이라 리액트를 많이 해보지 않았더라도 가볍게 읽기 좋은 글이라고 생각합니다. 글 링크: https://velog.io/@typo/leave-useeffect-alone

velog.io

useEffect를 남용하지 마세요!

수십년동안 영어를 잘 하고 싶어서 영어를 배우지는 않고 영어를 배우는 법만을 공부한 사람으로써..(…다.. 다들 그렇죠? 🥲)

영어를 확실히 그리고 빠르게 배우는 데에는 두 가지 방법이 있다. (영어 뿐 아니라 어떤 언어든)

1. 공부한다 -> 실전에 사람을 만나 시도한다

2. 실전에 사람을 만나 버벅인다 -> 버벅였던 내용을 어떻게 말할지 공부한다

즉 중요한 건 실전을 겪는 것이고, 1, 2번 중에서도 2번이 더 빠르고 확실한 방법이라고 한다. 그래서 많은 사람들이 미쿡인 (이성)친구를 만드는게 가장 빠른 방법이라고 하는 것이 다 경험적으로 그렇기 때문.

하지만 친구를 만든다는 것이 어렵기 때문에 다들 유학을 가거나 짧게라도 어학연수를 가는 것이고, 말이 많긴해도 이것이 확실한 방법 중 하나라는 것은 증명 된 방법.

문제는 실전을 접할 수 있는 기회가 없다는 것인데, 그래서 최근에 시중이 많이 그러한 앱들이 나오고 있지만 사실상 실전용이 아니다.(스픽도 마찬가지) 하지만 실전을 만들 수 있는 방법이 하나 있는데..(to be continued..)

수십년동안 영어를 잘 하고 싶어서 영어를 배우지는 않고 영어를 배우는 법만을 공부한 사람으로써..(…다.. 다들 그렇죠? 🥲) 영어를 확실히 그리고 빠르게 배우는 데에는 두 가지 방법이 있다. (영어 뿐 아니라 어떤 언어든) 1. 공부한다 -&gt; 실전에 사람을 만나 시도한다 2. 실전에 사람을 만나 버벅인다 -&gt; 버벅였던 내용을 어떻게 말할지 공부한다 즉 중요한 건 실전을 겪는 것이고, 1, 2번 중에서도 2번이 더 빠르고 확실한 방법이라고 한다. 그래서 많은 사람들이 미쿡인 (이성)친구를 만드는게 가장 빠른 방법이라고 하는 것이 다 경험적으로 그렇기 때문. 하지만 친구를 만든다는 것이 어렵기 때문에 다들 유학을 가거나 짧게라도 어학연수를 가는 것이고, 말이 많긴해도 이것이 확실한 방법 중 하나라는 것은 증명 된 방법. 문제는 실전을 접할 수 있는 기회가 없다는 것인데, 그래서 최근에 시중이 많이 그러한 앱들이 나오고 있지만 사실상 실전용이 아니다.(스픽도 마찬가지) 하지만 실전을 만들 수 있는 방법이 하나 있는데..(to be continued..)

수십년동안 영어를 잘 하고 싶어서 영어를 배우지는 않고 영어를 배

지난 8월에 시작한 스터디 2기가 성공적으로 마무리되었습니다. 스터디에 참여해주신 분들께서 생생한 후기를 많이 남겨주셨습니다. 아, 그리고 정말 기쁘게도 1기 참여자 중에서 원하는 기업에 합격하신 분이 또 배출되었어요! 🎊 저도 함께 매주 알고리즘 문제를 풀다보니 얼떨결에 최근에 이직을 하게 되었네요 😅

이제 스터디가 꽤 알려졌는지 아직 3기 모집을 시작하지도 않았는데 벌써 50분 가까이 대기자로 등록을 해주셨어요. 그래서 모집 공고를 올리지 않으려다가 다음 차수를 기다리시던 분들이 분명 계실 것 같아서 정원을 100명으로 두 배 늘리기로 결정하였습니다.

스터디 규모가 커지면서 전 세계에 흩어져있는 모든 멤버가 참석할 수 있는 모임 일정을 잡는 것이 너무 어려워지고, 깃허브에서 멘션이 가능한 최대 인원을 초과하고 디스코드에서 음성 채팅의 최대 인원을 초과하는 등 여러가지 제약 사항에 부딪히게 되었습니다. 그래서 3기 부터는 부득이하게 정기 모임을 중단하고 100% 온라인 비대면으로 진행하오니 양해 부탁드립니다.

스터디는 12월 8일부터 시작하고 신청은 12월 2일에 마감하도록 하겠습니다.

👉 달레 스터디 3기 신청: https://github.com/DaleStudy/leetcode-study/discussions/620
👉 달레 스터디 웹사이트: https://www.dalestudy.com/

지난 8월에 시작한 스터디 2기가 성공적으로 마무리되었습니다. 스터디에 참여해주신 분들께서 생생한 후기를 많이 남겨주셨습니다. 아, 그리고 정말 기쁘게도 1기 참여자 중에서 원하는 기업에 합격하신 분이 또 배출되었어요! 🎊 저도 함께 매주 알고리즘 문제를 풀다보니 얼떨결에 최근에 이직을 하게 되었네요 😅 이제 스터디가 꽤 알려졌는지 아직 3기 모집을 시작하지도 않았는데 벌써 50분 가까이 대기자로 등록을 해주셨어요. 그래서 모집 공고를 올리지 않으려다가 다음 차수를 기다리시던 분들이 분명 계실 것 같아서 정원을 100명으로 두 배 늘리기로 결정하였습니다. 스터디 규모가 커지면서 전 세계에 흩어져있는 모든 멤버가 참석할 수 있는 모임 일정을 잡는 것이 너무 어려워지고, 깃허브에서 멘션이 가능한 최대 인원을 초과하고 디스코드에서 음성 채팅의 최대 인원을 초과하는 등 여러가지 제약 사항에 부딪히게 되었습니다. 그래서 3기 부터는 부득이하게 정기 모임을 중단하고 100% 온라인 비대면으로 진행하오니 양해 부탁드립니다. 스터디는 12월 8일부터 시작하고 신청은 12월 2일에 마감하도록 하겠습니다. 👉 달레 스터디 3기 신청: https://github.com/DaleStudy/leetcode-study/discussions/620👉 달레 스터디 웹사이트: https://www.dalestudy.com/

📣 달레 스터디 3기를 모집합니다

YouTube에서 마음에 드는 동영상과 음악을 감상하고, 직접 만든 콘텐츠를 업로드하여 친구, 가족뿐 아니라 전 세계 사람들과 콘텐츠를 공유할 수 있습니다.

 - YouTube

최근 프론트엔드 진영 에서는 웹뷰, React 개발이 주류로 자리잡고 있습니다. 이런 흐름 에서
React Native
의 웹뷰 개발을 개선한
webview-bridge
라이브러리를 FECONF 세미나 영상을 통해 접하게 되었는데요. 영상을 매우 흥미롭게 시청하여서 내용을 정리해보았습니다.

 1. Event To Promise 방식의 양방향 통신
    기존 단방향 통신 방식에서는 처리 결과를 확인하기가 어려웠습니다. 이런 한계를 프론트엔드와 백엔드 간 통신 패턴에서 영감을 받아 Promise 기반의 응답 처리 시스템을 구현했습니다. 이를 통해 안정적이고 예측 가능한 통신이 가능해졌습니다.
    
    
 2. 강력한 타입 안정성과 추론
    네이티브 에서 정의한 브릿지 함수들의 반환값(Input)을 기반으로 웹 측의 타입이 자동으로 추론됩니다. 이는 개발자가 수동으로 타입을 정의할 때 발생할 수 있는 실수를 원천적으로 방지하면서도, 함수가 반환하는 데이터 구조를 기반으로 전체 타입 시스템이 자동으로 신뢰성 있게 구성됩니다.
    
 3. 실시간 상태 동기화
    useSyncExternalStore
    API 를 활용하여 네이티브 앱과 웹뷰 간의 상태를 실시간으로 동기화합니다. 이를 통해 특히 인증 토큰이나 사용자 정보와 같은 중요 데이터의 일관성을 유지합니다.
    
 4. 개발편의성과 하위 호환성
    사용자 중심의 설계로 개발 편의성을 향상시켰습니다. Proxy를 활용한 메소드 호출 처리로 존재하지 않은 메소드 호출시 타입에러를 반환하고, 사용 가능한 메소드를 체크해서 하위호환성을 체크합니다. 이를 통해 네이티브에 해당 메서드가 없다면 대체코드(fallback)이 실행되어 런타임 에러 방지와 앱 버전별 기능 차이에 대응이 가능합니다.

webview-bridge
는 하이브리드 앱 개발의 복잡성을 우아하게 해결하였다는 생각이 들었습니다. 세심한 API 설계, 자동화된 타입 시스템, 그리고 견고한 예외처리는 라이브러리의 완성도를 잘 보여주는데요. 국내 개발자가 실제 현장에서 마주한 문제를 깊이있게 분석하고, 자신만의 철학으로 해결책을 제시했다는 점이 특히 인상깊었습니다. 또 한국 개발자들의 기술력이 성장하고 있고, 글로벌 오픈소스 생태계에 대한 의미있는 기여를 보여주는 사례라고 생각되는데요. 이런 흐름이 계속되어 한국 개발자들이 세계에 더 많은 영향력을 발휘할 수 있기를 기대해봅니다.

https://www.youtube.com/watch?v=GyU9-pE0dAg

최근 프론트엔드 진영 에서는 웹뷰, React 개발이 주류로 자리잡고 있습니다. 이런 흐름 에서 <code >React Native</code>의 웹뷰 개발을 개선한 <code >webview-bridge</code> 라이브러리를 FECONF 세미나 영상을 통해 접하게 되었는데요. 영상을 매우 흥미롭게 시청하여서 내용을 정리해보았습니다. <ol ><li>Event To Promise 방식의 양방향 통신기존 단방향 통신 방식에서는 처리 결과를 확인하기가 어려웠습니다. 이런 한계를 프론트엔드와 백엔드 간 통신 패턴에서 영감을 받아 Promise 기반의 응답 처리 시스템을 구현했습니다. 이를 통해 안정적이고 예측 가능한 통신이 가능해졌습니다. </li><li>강력한 타입 안정성과 추론네이티브 에서 정의한 브릿지 함수들의 반환값(Input)을 기반으로 웹 측의 타입이 자동으로 추론됩니다. 이는 개발자가 수동으로 타입을 정의할 때 발생할 수 있는 실수를 원천적으로 방지하면서도, 함수가 반환하는 데이터 구조를 기반으로 전체 타입 시스템이 자동으로 신뢰성 있게 구성됩니다. </li><li>실시간 상태 동기화<code >useSyncExternalStore</code> API 를 활용하여 네이티브 앱과 웹뷰 간의 상태를 실시간으로 동기화합니다. 이를 통해 특히 인증 토큰이나 사용자 정보와 같은 중요 데이터의 일관성을 유지합니다. </li><li>개발편의성과 하위 호환성사용자 중심의 설계로 개발 편의성을 향상시켰습니다. Proxy를 활용한 메소드 호출 처리로 존재하지 않은 메소드 호출시 타입에러를 반환하고, 사용 가능한 메소드를 체크해서 하위호환성을 체크합니다. 이를 통해 네이티브에 해당 메서드가 없다면 대체코드(fallback)이 실행되어 런타임 에러 방지와 앱 버전별 기능 차이에 대응이 가능합니다.</li></ol> <code >webview-bridge</code>는 하이브리드 앱 개발의 복잡성을 우아하게 해결하였다는 생각이 들었습니다. 세심한 API 설계, 자동화된 타입 시스템, 그리고 견고한 예외처리는 라이브러리의 완성도를 잘 보여주는데요. 국내 개발자가 실제 현장에서 마주한 문제를 깊이있게 분석하고, 자신만의 철학으로 해결책을 제시했다는 점이 특히 인상깊었습니다. 또 한국 개발자들의 기술력이 성장하고 있고, 글로벌 오픈소스 생태계에 대한 의미있는 기여를 보여주는 사례라고 생각되는데요. 이런 흐름이 계속되어 한국 개발자들이 세계에 더 많은 영향력을 발휘할 수 있기를 기대해봅니다. https://www.youtube.com/watch?v=GyU9-pE0dAg

www.youtube.com

리액트 네이티브와 웹뷰의 만남: webview-bridge

커피챗을 100번 넘게 하면서 가장 어려워하는 지점 중 하나가 '성과를 데이터로 증명하기'입니다. 사실 회사의 비공개 프로젝트, 클라이언트가 있는 프로젝트 또는 현재 진행형이라면 이 성과를 수치로 보여준다는 것이 쉽지 않습니다. 데이터 기반의 성장을 추구하는 조직이라도 모든 기능 적용에 대해 코호트 분석을 하긴 어렵기 때문에 데이터 중심 조직에서 커리어를 쌓더라도 이 문제에서 자유롭지 않습니다. 포트폴리오에 '성과', '임팩트'를

포트폴리오에 사이드, 스텔스 프로젝트에서 성과 표현하기

커피챗을 하면서 가장 어려워하는 지점 중 하나가 '성과를 데이터로 증명하기'입니다. 사실 회사의 비공개 프로젝트, 클라이언트가 있는 프로젝트 또는 현재 진행형이라면 이 성과를 수치로 보여준다는 것이 쉽지 않습니다. 데이터 기반의 성장을 추구하는 조직이라도 모든 기능 적용에 대해 코호트 분석을 하긴 어렵기 때문에 데이터 중심 조직에서 커리어를 쌓더라도 이 문제에서 자유롭지 않습니다. 포트폴리오에 '성과', '임팩트'를 강조하라고 하는데 어떻게 해야 할까요? 2가지를 기억하시면 좋겠습니다.

포트폴리오에 넣을 데이터가 없는게 고민이에요

1️⃣ 포트폴리오 본질에 충실하세요

먼저, 포트폴리오에서 중요한 건 프로젝트나 서비스에 대한 소개가 아니라 지원자 본인의 '문제 해결 능력'을 '논리적'으로 또 '설득력'있게 보여주는 것입니다. 인터뷰어로 UX팀 지원자의 포트폴리오를 검토할 때 가장 흔히 범하는 실수가 지원자(메신저)에 대한 이야기 없이 프로덕트에 대한 메시지에 대해서만 보여주는 경우였습니다. 서비스 소개서, IR 자료가 아니라 본인의 고민, 가설, 결정, 커뮤니케이션, 이 과정에서 고민했던 지점과 판단한 방식이 잘 드러나야 합니다. 주장을 뒷받침할 데이터가 있으면 좋지만 데이터가 없어도 괜찮습니다. 대부분의 지원자가 동일한 문제를 겪고 있어요. 데이터가 있으면 좋겠지만, 같은 문제과 어려움으로 데이터가 없는 경우도 많죠. 그러니 문제 정의와 논리적 전개에 충실하는 것이 우선이고 실제로 더 중요합니다.

2️⃣ 정량뿐만 아니라 정성까지 데이터인걸요

두 번째로 정성 데이터를 적극적으로 활용하는 겁니다. 정성 데이터로 활용할 수 있는 것은 동료의 리뷰, 고객의 VoC, SNS에 공개된 내용, App Store 리뷰도 포함됩니다. 후행적이지만 현시점에서 당시 서비스를 이용했던 고객을 리크루팅 해서 인터뷰를 진행해 (1) 당시 서비스를 알게 된 계기 (2) 사용했던 이유 (3) 중단한 or 계속 사용하는 이유 3가지만 확인하더라도 의미 있는 데이터가 됩니다.

정량 데이터가 없더라도 활용할 수 있는 정성 데이터 4가지

 1. App Store 또는 공개된 사용자의 리뷰
 2. 제품을 함께 만든 내부 관계자의 의견 (회고, Lessons Learned)
 3. 미디어 노출, SNS 검색 등 Desk Research로 확보할 수 있는 자료
 4. 유사한 기능을 가진 대체재, 경쟁사 제품에 대한 고객 반응 또는 시장 임팩트 (제한적 활용)

후행 인터뷰를 통해서 검증하면 좋은 3가지

 1. 고객이 처음 서비스를 알게 된 계기
 2. 처음 서비스에 회원가입을 해서 사용한 이유
 3. 현재 서비스 이용을 중단한 계기 또는 계속 이용하는 이유

프로덕트 디자이너나 UX 리서처를 채용할 때 가장 중요하게 생각하는 건 '문제를 정의하고 해결하는 능력'입니다. 보이는 것보다 실제 쓰이는 것, 현상보다는 근원적인 문제를 고민해서 솔루션을 탐색하고 검증하는 능력을 요구합니다. 데이터는 문제 해결을 위한 보조 자료이지 데이터 자체가 문제의 본질인 경우는 없습니다. 나의 생각의 흐름을 논리적으로 전달할 수 있는 가능한 방법에 집중하시면 좋겠습니다.

https://redbusbagman.com/myportfoliodata/

커피챗을 하면서 가장 어려워하는 지점 중 하나가 '성과를 데이터로 증명하기'입니다. 사실 회사의 비공개 프로젝트, 클라이언트가 있는 프로젝트 또는 현재 진행형이라면 이 성과를 수치로 보여준다는 것이 쉽지 않습니다. 데이터 기반의 성장을 추구하는 조직이라도 모든 기능 적용에 대해 코호트 분석을 하긴 어렵기 때문에 데이터 중심 조직에서 커리어를 쌓더라도 이 문제에서 자유롭지 않습니다. 포트폴리오에 '성과', '임팩트'를 강조하라고 하는데 어떻게 해야 할까요? 2가지를 기억하시면 좋겠습니다. 포트폴리오에 넣을 데이터가 없는게 고민이에요 1️⃣ 포트폴리오 본질에 충실하세요 먼저, 포트폴리오에서 중요한 건 프로젝트나 서비스에 대한 소개가 아니라 지원자 본인의 '문제 해결 능력'을 '논리적'으로 또 '설득력'있게 보여주는 것입니다. 인터뷰어로 UX팀 지원자의 포트폴리오를 검토할 때 가장 흔히 범하는 실수가 지원자(메신저)에 대한 이야기 없이 프로덕트에 대한 메시지에 대해서만 보여주는 경우였습니다. 서비스 소개서, IR 자료가 아니라 본인의 고민, 가설, 결정, 커뮤니케이션, 이 과정에서 고민했던 지점과 판단한 방식이 잘 드러나야 합니다. 주장을 뒷받침할 데이터가 있으면 좋지만 데이터가 없어도 괜찮습니다. 대부분의 지원자가 동일한 문제를 겪고 있어요. 데이터가 있으면 좋겠지만, 같은 문제과 어려움으로 데이터가 없는 경우도 많죠. 그러니 문제 정의와 논리적 전개에 충실하는 것이 우선이고 실제로 더 중요합니다. 2️⃣&nbsp;정량뿐만 아니라 정성까지 데이터인걸요 두 번째로 정성 데이터를 적극적으로 활용하는 겁니다. 정성 데이터로 활용할 수 있는 것은 동료의 리뷰, 고객의 VoC, SNS에 공개된 내용, App Store 리뷰도 포함됩니다. 후행적이지만 현시점에서 당시 서비스를 이용했던 고객을 리크루팅 해서 인터뷰를 진행해 (1) 당시 서비스를 알게 된 계기 (2) 사용했던 이유 (3) 중단한 or 계속 사용하는 이유 3가지만 확인하더라도 의미 있는 데이터가 됩니다. 정량 데이터가 없더라도 활용할 수 있는 정성 데이터 4가지 <ol ><li>App Store 또는 공개된 사용자의 리뷰</li><li>제품을 함께 만든 내부 관계자의 의견 (회고, Lessons Learned)</li><li>미디어 노출, SNS 검색 등 Desk Research로 확보할 수 있는 자료</li><li>유사한 기능을 가진 대체재, 경쟁사 제품에 대한 고객 반응 또는 시장 임팩트 (제한적 활용)</li></ol> 후행 인터뷰를 통해서 검증하면 좋은 3가지 <ol ><li>고객이 처음 서비스를 알게 된 계기</li><li>처음 서비스에 회원가입을 해서 사용한 이유</li><li>현재 서비스 이용을 중단한 계기 또는 계속 이용하는 이유</li></ol> 프로덕트 디자이너나 UX 리서처를 채용할 때 가장 중요하게 생각하는 건 '문제를 정의하고 해결하는 능력'입니다. 보이는 것보다 실제 쓰이는 것, 현상보다는 근원적인 문제를 고민해서 솔루션을 탐색하고 검증하는 능력을 요구합니다. 데이터는 문제 해결을 위한 보조 자료이지 데이터 자체가 문제의 본질인 경우는 없습니다. 나의 생각의 흐름을 논리적으로 전달할 수 있는 가능한 방법에 집중하시면 좋겠습니다. https://redbusbagman.com/myportfoliodata/

REDBUSBAGMAN | 빨간색 광역버스에 백팩을 메고 탑니다

⟪포트폴리오에 사이드, 스텔스 프로젝트에서 성과 표현하기⟫

1 일 잘하는 사람이 연차가 쌓인다. 그럼 보통 리더가 된다. 하지만, 분명 실무는 잘했는데, 좋은 리더는 ...

일 잘하는 사람이 좋은 리더가 되기 어려운 이유 - '실무는 잘했는데, 리더는 왜 어렵나?'

1
일 잘하는 사람이 연차가 쌓인다. 그럼 보통 리더가 된다. 하지만, 분명 실무는 잘했는데, 좋은 리더는 못 되는 사람들이 있다. 왜일까?

2
답은 간단하다. 실무자와 리더의 일은 다르기 때문이다. 실무자는 내가 맡은 일만 잘 하면 된다. 하지만 리더는 팀의 일이 되도록 만들어야 한다.

3
팀의 일이 되도록 만든다는 건 뭘까. 팀과 개인을 생각해 보자.

4
팀은 개인의 합이다. 그래서 팀은 개인보다 언제나 위대하다. 한 명의 개인보다 훨씬 큰일을 할 수 있으니까. 팀은 단순한 1+1=2가 아니다. 그 합은 3, 4도 되고 10도 될 수 있다. 팀은 창발적 가치를 만들어낸다.

5
팀의 일은 개인의 일의 합이다. 혼자 해서 끝나는 일도 있다. 하지만, 대부분의 일은 연결된다. 모든 개인의 일이 맞물려서 가치를 낸다. 마무리가 되어야 성과를 기대할 수 있다. 이걸 반복해야 성장한다.

6
이 과정을 챙기는 게 리더의 역할이다. 막힌 곳을 뚫는다. 느린 곳을 점검한다. 마무리를 짓는다. 결과를 확인하고 성과를 본다. 직접 하는 게 아니라 사람을 움직여야 한다.

7
하지만, 일 잘하던 리더는 답답하다. 저걸 왜 못할까, 이렇게 밖에 못할까, 내가 하면 금방인데. 시간은 없고, 마음이 급하다.

8
그래서 실무에 직접 손을 댄다. 깊숙이 관여한다. 한정된 리더의 시간을 실무에 쏟으면, 전체를 볼 시간이 줄어든다. 숲을 보지 못하고 나무만 볼 확률이 높아진다.

9
사람을 움직이는 노력보다 개별적인 일에 집중해서는 팀이 잘될 수 없다. 이게 반복되면 결국 리더는 지친다. 일 잘하던 사람이 리더 역할은 왜 못하나. 스스로도 좌절한다.

10
넓은 시야로 보려고 노력하기. 사람을 움직이는 법을 배우기. 이게 리더가 해야 할 일이다.

11
사실 리더의 일은 티가 안 난다. 그래서 리더의 역할은 쉬워 보인다. 내가 겪었던 수많은 리더들도 그랬다. 딱히 하루 종일 하는 일이 없어 보인다. 자리에도 잘 없다. 도대체 어디서 무엇을 하고 있을까. 궁금했다. 부당하다고 느낀 적도 있었다.

12
리더가 된 후에 깨달았다. 그럴 수밖에 없었다. 리더의 일은 눈에 보이지 않으니까. 그래서 또 어렵다. 무슨 일을 해야 하는지 알 수가 없으니까.

13
결국은 사람이다. 세상에 수많은 훌륭한 경영자와 사상가들이 하나같이 하는 말. 인사가 만사다. 결국, 리더가 잘 해야 하는 단 한 가지의 일은 사람 공부다.

1 일 잘하는 사람이 연차가 쌓인다. 그럼 보통 리더가 된다. 하지만, 분명 실무는 잘했는데, 좋은 리더는 못 되는 사람들이 있다. 왜일까? ​ ​​2 답은 간단하다. 실무자와 리더의 일은 다르기 때문이다. 실무자는 내가 맡은 일만 잘 하면 된다. 하지만 리더는 팀의 일이 되도록 만들어야 한다. ​ ​3 팀의 일이 되도록 만든다는 건 뭘까. 팀과 개인을 생각해 보자. ​ ​4 팀은 개인의 합이다. 그래서 팀은 개인보다 언제나 위대하다. 한 명의 개인보다 훨씬 큰일을 할 수 있으니까. 팀은 단순한 1+1=2가 아니다. 그 합은 3, 4도 되고 10도 될 수 있다. 팀은 창발적 가치를 만들어낸다. ​ ​5 팀의 일은 개인의 일의 합이다. 혼자 해서 끝나는 일도 있다. 하지만, 대부분의 일은 연결된다. 모든 개인의 일이 맞물려서 가치를 낸다. 마무리가 되어야 성과를 기대할 수 있다. 이걸 반복해야 성장한다. ​ ​6 이 과정을 챙기는 게 리더의 역할이다. 막힌 곳을 뚫는다. 느린 곳을 점검한다. 마무리를 짓는다. 결과를 확인하고 성과를 본다. 직접 하는 게 아니라 사람을 움직여야 한다. ​ ​7 하지만, 일 잘하던 리더는 답답하다. 저걸 왜 못할까, 이렇게 밖에 못할까, 내가 하면 금방인데. 시간은 없고, 마음이 급하다. ​ ​8 그래서 실무에 직접 손을 댄다. 깊숙이 관여한다. 한정된 리더의 시간을 실무에 쏟으면, 전체를 볼 시간이 줄어든다. 숲을 보지 못하고 나무만 볼 확률이 높아진다. ​ ​9 사람을 움직이는 노력보다 개별적인 일에 집중해서는 팀이 잘될 수 없다. 이게 반복되면 결국 리더는 지친다. 일 잘하던 사람이 리더 역할은 왜 못하나. 스스로도 좌절한다. ​ ​10 넓은 시야로 보려고 노력하기. 사람을 움직이는 법을 배우기. 이게 리더가 해야 할 일이다. ​ ​11 사실 리더의 일은 티가 안 난다. 그래서 리더의 역할은 쉬워 보인다. 내가 겪었던 수많은 리더들도 그랬다. 딱히 하루 종일 하는 일이 없어 보인다. 자리에도 잘 없다. 도대체 어디서 무엇을 하고 있을까. 궁금했다. 부당하다고 느낀 적도 있었다. ​ ​12 리더가 된 후에 깨달았다. 그럴 수밖에 없었다. 리더의 일은 눈에 보이지 않으니까. 그래서 또 어렵다. 무슨 일을 해야 하는지 알 수가 없으니까. ​ ​13 결국은 사람이다. 세상에 수많은 훌륭한 경영자와 사상가들이 하나같이 하는 말. 인사가 만사다. 결국, 리더가 잘 해야 하는 단 한 가지의 일은 사람 공부다.

blog.naver.com

< 일 잘하는 사람이 좋은 리더가 되기 어려운 이유 >

리더가 모든 지시나 업무가 다 중요하다는 식의 메시지를 전달하고 있다거나, 간단한 수준(또는 그렇게 여기는)의 업무지시는 별 문제가 되지 않는다 여겨 빠른 결과물을 요구한다면? 구성원들 입장에서는 업무 우선순위에 혼선이 발생할 수 밖에 없고, 조금만 지나도 업무를 숙제처럼 쳐내는 상황에 내몰리게 됩니다. 만일 이 상황이 지속되어 구성원들이 이를 체념하는 수준에 이른다면, 중장기적으로는 조직의 위기를 초래하는 시그널로 받아들여야 한다고 봅니다. 더구나 그 업무들이 목표와 어떻게 align 되는지 잘 이해되지 못한 채 지속적으로 강요될 경우, 그 hidden cost들이 구성원들의 내적동기를 깎아 내리고 결국 조직의 성과와 성장을 저해할 수 밖에 없습니다.

비즈니스에 있어서 빠른 의사결정과 실행은 매우 중요합니다. 그러나 이에 앞서 구성원들이 그 의사결정이 왜, 어떤 맥락에서 빠른 실행이 필요한지에 대해 분명하게 이해하고 공감하는 것이야말로 더 빠른 실행의 원동력이 되는 것 아닐까요. 그럼에도 많은 리더들이 이를 놓치는 것 같습니다. 그저 빠르기만 한 것과 모두가 한 방향으로 빠르게 움직이는 것, 둘 중에 어떤 방법이 시너지와 성과를 낼지는 너무나 자명합니다.

이러한 구성원들 간의 목표 공유와 공감은 리더의 관념과 말로만 이루어지는 것이 아니기에, 구체적으로 어떤 장치와 프로세스를 통해 형성해 갈지에 대해 고민해야만 합니다. 그리고 일회성 전달이 아니라, 의사결정 기준과 일하는 방식에 있어서 일관성 있게 적용해가는 지속적인 노력이 필요하고요. 그리고 이것이 다함께 힘을 합쳐 의미있는 성과와 성취를 이루어내는 조직문화로 정착되어야 합니다.

이런 조직 문화는 people 조직이 선언하고 가이드 한다고 해서 달성할 수 있는 것이 아닙니다. 각 상황에 맞게 구체적인 방법을 고민하고 시행착오를 거쳐가며 개선해나가야 하는 리더들의 중요한 역할이자 의무 아닐까요.

이미지 출처: Trustworthy Online Controlled Experiments, Ron Kohavi / Diane Tang / Ya Xu

리더가 모든 지시나 업무가 다 중요하다는 식의 메시지를 전달하고 있다거나, 간단한 수준(또는 그렇게 여기는)의 업무지시는 별 문제가 되지 않는다 여겨 빠른 결과물을 요구한다면? 구성원들 입장에서는 업무 우선순위에 혼선이 발생할 수 밖에 없고, 조금만 지나도 업무를 숙제처럼 쳐내는 상황에 내몰리게 됩니다. 만일 이 상황이 지속되어 구성원들이 이를 체념하는 수준에 이른다면, 중장기적으로는 조직의 위기를 초래하는 시그널로 받아들여야 한다고 봅니다. 더구나 그 업무들이 목표와 어떻게 align 되는지 잘 이해되지 못한 채 지속적으로 강요될 경우, 그 hidden cost들이 구성원들의 내적동기를 깎아 내리고 결국 조직의 성과와 성장을 저해할 수 밖에 없습니다. 비즈니스에 있어서 빠른 의사결정과 실행은 매우 중요합니다. 그러나 이에 앞서 구성원들이 그 의사결정이 왜, 어떤 맥락에서 빠른 실행이 필요한지에 대해 분명하게 이해하고 공감하는 것이야말로 더 빠른 실행의 원동력이 되는 것 아닐까요. 그럼에도 많은 리더들이 이를 놓치는 것 같습니다. 그저 빠르기만 한 것과 모두가 한 방향으로 빠르게 움직이는 것, 둘 중에 어떤 방법이 시너지와 성과를 낼지는 너무나 자명합니다. 이러한 구성원들 간의 목표 공유와 공감은 리더의 관념과 말로만 이루어지는 것이 아니기에, 구체적으로 어떤 장치와 프로세스를 통해 형성해 갈지에 대해 고민해야만 합니다. 그리고 일회성 전달이 아니라, 의사결정 기준과 일하는 방식에 있어서 일관성 있게 적용해가는 지속적인 노력이 필요하고요. 그리고 이것이 다함께 힘을 합쳐 의미있는 성과와 성취를 이루어내는 조직문화로 정착되어야 합니다. 이런 조직 문화는 people 조직이 선언하고 가이드 한다고 해서 달성할 수 있는 것이 아닙니다. 각 상황에 맞게 구체적인 방법을 고민하고 시행착오를 거쳐가며 개선해나가야 하는 리더들의 중요한 역할이자 의무 아닐까요. 이미지 출처: Trustworthy Online Controlled Experiments, Ron Kohavi / Diane Tang / Ya Xu

리더가 모든 지시나 업무가 다 중요하다는 식의 메시지를 전달하고 

V0와 Cursor AI로 프롬프트 기반으로 PM Prompts라는 웹앱을 만들었습니다. 프로덕트 매니저에게 유용한 프롬프트를 큐레이션한 서비스입니다:)  아래는 그 중에서 PRD를 생성하는 프롬프트 링크입니다:) https://pm-prompt.vercel.app/prompt/1  참고하실 수 있도록 프롬프트를 사용하는 예시를 아래와 같이 보여드리겠습니다

ChatGPT로 PRD 작성하기

V0와 Cursor AI로 코딩 없이 프롬프트 기반으로 PM Prompts라는 웹앱을 만들었습니다. 프로덕트 매니저가 실제 업무에 활용할 수 있는 프롬프트를 큐레이션하는 서비스입니다:)

그 중에서 PRD를 생성하는 프롬프트 활용법을 아래 브런치에 작성했습니다.

https://brunch.co.kr/@yongjinjinipln/197

아래 url도 즐겨찾기 해주시면 실제 업무에 유용한 프롬프트를 계속 업데이트해나가겠습니다.
https://pm-prompt.vercel.app

V0와 Cursor AI로 코딩 없이 프롬프트 기반으로 PM Prompts라는 웹앱을 만들었습니다. 프로덕트 매니저가 실제 업무에 활용할 수 있는 프롬프트를 큐레이션하는 서비스입니다:) 그 중에서 PRD를 생성하는 프롬프트 활용법을 아래 브런치에 작성했습니다. https://brunch.co.kr/@yongjinjinipln/197 아래 url도 즐겨찾기 해주시면 실제 업무에 유용한 프롬프트를 계속 업데이트해나가겠습니다.https://pm-prompt.vercel.app

Brunch Story

There’s a common character that can be often spotted in many online communities. It’s the “toxic influencer” (sometimes referred as “intellectual bully”). A toxic influencer is a person…

The Impact of Toxic Influencers on Communities

오랫동안 온라인 커뮤니티를 겪으면서 독성 인플러언서의 문제에 대해서 작은 글입니다.

이러한 독성 인프루언서는 특정 주제에 관한 지식이 꽤 있기 때문에 해당 커뮤니티에 필요한 서비스를 제공하기 때문에 실질적으로 도움이 되는 부분이 있기 때문에 우호 세력도 생기게 됩니다. 하지만 공격적인 태도를 취하기 때문에 커뮤니티 사람들의 신경을 건드리고 전체 커뮤니티에 긴장된 분위기를 조정하기 때문에 커뮤니티 전체적으로는 안좋아지는데 또 커뮤니티 규칙을 어기는 일이 없도록 신중한 태도를 취하기 때문에 운영진에서 조치를 취하기 어렵다고 합니다.

어떻게 하는게 맞는지는 모르겠지만 생각나는 일들도 많고 많이 본 케이스라는 생각이 들었습니다. 결국 큰 문제가 벌어지거나 하기 전까지는 실제로 조치를 취하기 어렵기도 하고 실질적으로 주는 나쁜 영향이 어느정도인지 측정하기 어렵기 때문에(또한 긍정적 혜택과의 차이도) 더욱 어려운 부분이라고 생각합니다.

https://intenseminimalism.com/2020/the-impact-of-toxic-influencers-on-communities/

오랫동안 온라인 커뮤니티를 겪으면서 독성 인플러언서의 문제에 대해서 작은 글입니다. 이러한 독성 인프루언서는 특정 주제에 관한 지식이 꽤 있기 때문에 해당 커뮤니티에 필요한 서비스를 제공하기 때문에 실질적으로 도움이 되는 부분이 있기 때문에 우호 세력도 생기게 됩니다. 하지만 공격적인 태도를 취하기 때문에 커뮤니티 사람들의 신경을 건드리고 전체 커뮤니티에 긴장된 분위기를 조정하기 때문에 커뮤니티 전체적으로는 안좋아지는데 또 커뮤니티 규칙을 어기는 일이 없도록 신중한 태도를 취하기 때문에 운영진에서 조치를 취하기 어렵다고 합니다. 어떻게 하는게 맞는지는 모르겠지만 생각나는 일들도 많고 많이 본 케이스라는 생각이 들었습니다. 결국 큰 문제가 벌어지거나 하기 전까지는 실제로 조치를 취하기 어렵기도 하고 실질적으로 주는 나쁜 영향이 어느정도인지 측정하기 어렵기 때문에(또한 긍정적 혜택과의 차이도) 더욱 어려운 부분이라고 생각합니다. https://intenseminimalism.com/2020/the-impact-of-toxic-influencers-on-communities/

Intense Minimalism

오랫동안 온라인 커뮤니티를 겪으면서 독성 인플러언서의 문제에 대해

ChatGPT와 같이 자연어 명령어로 답을 주는 서비스들이 점점 더 늘어나고 있습니다. 이번에는 SQL Query문입니다! 

DB table 정보를 등록하고 원하는 결과물을 자연어로 이야기하면 적절한 쿼리문을 짜줍니다. 물론 등록 안해도 어느정도는 되지만, 정확한 Table 정보와, CRUD 목적을 제대로 정해주면 더더욱 정확하게 잘 나온다고 합니다. 테스트해보니 한글로도 적절히 잘 나오네요. 

https://www.aiquery.co/ 

AI 생산성 툴의 끝은 도대체 어디일까요?!

@김형우 producthunt.com 을 자주 둘러봅니다 ㅎㅎ 재밌는 서비스들이 참 많아요!

개발자

서지연

만드는게 좋은 개발자! 즐겁게 함께 일해요!

지연님은 이러한 서비스를 어떻게 보시나요??? 

디지털 네이티브스 Product Owner

김형우

AI연구원

pung

MLOps에 관심이 많은 딥러닝 엔지니어입니다.
직접 서비스까지 구현하는 것을 좋아하고, 현실 문제에 관심이 많습니다. 
사용자들이 새로운 경험을 할 수 있는 제품을 만들고 싶습니다. 
#독서 #개발자 #끊임없는자기계발 #도전적인

라인플러스 소프트웨어 엔지니어

이원형

👨‍🎓무선 통신 분야 석사를 마치고 💾반도체 펌웨어를 개발하다가
지금은 💻메신저를 개발하고 있습니다.

❗ 본 계정에서 작성되는 모든 의견은 특정 회사와는 무관합니다.

Software Engineer

하조은

• 개발자의 성장을 위한 컨텐츠를 만들어요
• 인프런 '손에 익는 Next.js' 강의 지식공유자
• 유튜브 '하조은조하' 운영자

AI Query

댓글 2

비슷한 게시물

주간 인기 TOP 10

추천 프로필