What impact does @property have on the performance of your CSS?

Benchmarking the performance of CSS @property  |  Articles  |  web.dev

몇년전 각 브라우저 벤더들이 모여서 표준의 호환성을 잘 유지하기 위해 공동으로 테스트를 만들어서 브라우저간 차이를 줄이려고 노력하면서 Baseline을 만들었습니다. Baseline은 새로운 기능이 Chrome, Edge, Firefox, Safari에서 모두 지원되고 이후 30개월이 지나서 대부분의 사이트에서 사용해도 된다고 판단되면 Baseline에 추가됩니다.

CSS에서 커스텀 프로퍼티를 만들 수 있는 @property도 Baseline에 추가되었습니다. 이 @property의 성능을 벤치마킹한 글입니다.

CSS 프로퍼티는 상속이 될 수도 있고 아닐 수도 있는데 상속되지 않는 프로퍼티가 상속되는 프로퍼티보다 훨씬 빠른 성능을 보여주고 등록되지 않은 커스텀 프로퍼티는 정규 프로퍼티보다 느린 속도를 보여주었습니다. 그래서 커스텀 프로퍼티를 등록할 때도 시간이 걸리지만 등록할 가치가 있고 상속이 필요하지 않다면 inherits: false로 지정하면 성능에서 큰 혜택을 볼 수 있습니다.

@property의 성능 비교도 재밌지만 Chromium의 PerfTestRunner를 이용해서 이 테스트를 위한 CSS Selector Benchmark를 구성한 것도 재밌었습니다. 잘 기억해두면 나중에 직접 테스트를 해보고 싶을 때 활용해 볼 수 있을 것 같습니다.

https://web.dev/blog/at-property-performance?hl=en

몇년전 각 브라우저 벤더들이 모여서 표준의 호환성을 잘 유지하기 위해 공동으로 테스트를 만들어서 브라우저간 차이를 줄이려고 노력하면서 Baseline을 만들었습니다. Baseline은 새로운 기능이 Chrome, Edge, Firefox, Safari에서 모두 지원되고 이후 30개월이 지나서 대부분의 사이트에서 사용해도 된다고 판단되면 Baseline에 추가됩니다. CSS에서 커스텀 프로퍼티를 만들 수 있는 @property도 Baseline에 추가되었습니다. 이 @property의 성능을 벤치마킹한 글입니다. CSS 프로퍼티는 상속이 될 수도 있고 아닐 수도 있는데 상속되지 않는 프로퍼티가 상속되는 프로퍼티보다 훨씬 빠른 성능을 보여주고 등록되지 않은 커스텀 프로퍼티는 정규 프로퍼티보다 느린 속도를 보여주었습니다. 그래서 커스텀 프로퍼티를 등록할 때도 시간이 걸리지만 등록할 가치가 있고 상속이 필요하지 않다면 inherits: false로 지정하면 성능에서 큰 혜택을 볼 수 있습니다. @property의 성능 비교도 재밌지만 Chromium의 PerfTestRunner를 이용해서 이 테스트를 위한 CSS Selector Benchmark를 구성한 것도 재밌었습니다. 잘 기억해두면 나중에 직접 테스트를 해보고 싶을 때 활용해 볼 수 있을 것 같습니다. https://web.dev/blog/at-property-performance?hl=en

web.dev

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기.

사용자의 목소리

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다.
예전에 누군가에게 들었던 이야기.

인상적이었습니다. 진짜 그럴까?

커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다.
말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다.

가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다.
하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다.
난 사용자들 목소리가 듣고 싶은 건데.

커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다.
발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻.
사용자들 목소리 듣기가 얼마나 어려운데…

이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다.

https://jeho.page/essay/2024/10/17/user-voice.html

앱 시작 화면에 개발자 핸드폰 전화번호를 적어놔봐라. 그래도 전화 안 온다. 예전에 누군가에게 들었던 이야기. 인상적이었습니다. 진짜 그럴까? 커피한잔도 앱 시작 화면 정도는 아니지만 홈페이지 하단에 고객센터 전화번호를 노출해두고 있습니다. 말이 고객 센터지, 제가 가진 두 개의 핸드폰 번호 중 하나입니다. 가끔 전화가 오면 긴장 반 설렘 반으로 전화를 받습니다. 하지만 불행히도(?) 사용자분들에게 전화가 오기보단 스팸 전화가 대부분입니다. 난 사용자들 목소리가 듣고 싶은 건데. 커피한잔에서 사용자들에게 보내는 메일은 발신 전용 메일이 없습니다. 발신 전용으로 보낸다는 건 답장을 보내지 말라는 뜻. 사용자들 목소리 듣기가 얼마나 어려운데… 이야기를 더 많이 들어보기 위해 정말 스플래시 화면에 전화번호를 한 번 노출해 봐야겠습니다. https://jeho.page/essay/2024/10/17/user-voice.html

K리그 프로그래머

앱 스토어 리뷰에 사용자의 목소리가 주로 표현되더라고요. 

초거대 언어 모델(LLM: Large Language Model)을 사용하는 애플리케이션의 개발 및 배포 과정에서 발생하는 문제들은 ML 모델의 개발과 배포 과정에서 생기는 문제들과 마찬가지로 매우 다양하다. 처음 한 번은 LLM 기반 서비스를 만들하고 배포할 수 있지만, 그 후 LLM이 업그레이드되거나 새로운 LLM을 써보려고 한다면 어떤 최적화 및 검증 프로세스를 갖고 있느냐가 굉장히 중요해진다. 여기서 차별화된 경쟁력이 나오며, 이를 LLMOps 엔지니어가 담당하게 된다.

LLMOps는 LLM을 활용하는 다양한 서비스 개발과 운영에 필요한데 보통 RAG(Retrieval Augmented Genenration)라는 모양을 갖는 것이 현재로는 일반적이며 도메인과 관련된 지식을 벡터DB로 별도로 저장하고 이를 최종 프롬프트 생성에 사용하게 된다. 몇 가지 예를 들어보면 다음과 같다.

 1. 대화형 AI 서비스: 챗봇 및 가상 비서 등등
 2. 콘텐츠 생성 및 편집: 작문, 자동 번역, 뉴스 기사 생성 등등
 3. 교육 및 학습: 개인화된 학습 보조 도구, 자동 채점 및 피드백 시스템, 언어학습 등등
 4. 비즈니스 인텔리전스: 데이터 분석 및 보고서 생성, 시장 트렌드 분석 등등
 5. 의료 및 헬스케어: 의료 기록 분석 및 요약, 보험사 청구서 자동 작성, 질병 진단 보조 등등
 6. 법률 및 규제: 법률 문서 분석 및 요약, 계약서 검토 자동화 등등
 7. 소프트웨어 개발: 코드 자동 생성 및 최적화, 버그 검출 및 수정 제안, 개발 문서 자동화
 8. 창작 및 엔터테인먼트: 음악 작곡, 게임 시나리오 및 캐릭터 생성 등등
 9. ...

LLMOps는 위와 같은 서비스를 만듬에 있어 LLM 관련 최적화와 운영, 관리를 책임지는 직군이다. 이 직무는 머신러닝 모델의 생애주기를 관리하는 MLOps와 아주 유사하지만, 머신 러닝 모델을 직접 만들고 그것의 생애를 관리하는 것이 아니라 누군가 만든 LLM(ChatGPT, Claude, Gemini 등등)을 가져다 쓰면서 프롬프트 관리와 RAG와 같은 서비스라면 벡터 DB 등 다른 시스템이 존재하게 되는데 이를 전체적으로 최적화하고 평가하고 배포 후에 비용 등을 관리하면서 운영한다는 점이 다르다.

아직은 LLMOps팀이 전체 프로세스에 걸쳐 사용할 수 있는 하나의 플랫폼은 존재하지 않다고 보여지고 (그런 방향성을 갖고 있는 툴들은 존재) 다양한 툴을 섞어 사용해야 한다.

 * RAG 빌딩 툴: LangChain과 Llama Index가 가장 대표적인데 이 둘의 성격이 많이 다르긴 하지만 LangChain은 너무 복잡한 느낌이 있어서 개인적으로는 Llama Index를 선호한다. 써본 적은 없지만 PromptFlow도 괜찮다는 이야기를 많이 들었다.
 * 벡터 DB: Pinecone, ElasticSearch, Weaviate, VESPA, FAISS, GCP Vertex 등등 아주 많다. 개인적으로는 벡터 임베딩을 통한 검색 뿐만 아니라 키워드 기반 검색도 같이 사용하는 것이 더 효율적이라 생각하기에 이 두 가지를 잘 지원해주는 VESPA가 개인적으로는 가장 마음에 든다
 * 프롬프트 실험 및 관리: 많이 사용해본 툴이 없긴 하지만 Vellum, Baserun이 가장 많이 쓰이는 것으로 보인다. LangChain은 이 부분을 어느 정도 커버하긴 한다.
 * 성능 평가 툴: LLM 기반의 앱의 성능을 평가할 수 있는 테스트셋이 필요하고 이를 버저닝하고 관리할 수 있는 툴이 필요하다. RAG라면 사용되는 벡터DB로부터 사용자 질의와 관련된 정보를 검색해야 하는데 결과 품질을 평가할 수 있는 테스트셋도 필요하다. Ragas, Haystack, Truelens 등이 있고 LangChain도 이 기능을 일부 지원한다

업무에 대해 더 이야기해보자면 보통 LLMOps팀은 개발자와 도메인 전문가 두 직군의 사람이 협업을 하는 형태로 일을 하게 된다.

 * 도메인 전문가 (프롬프트 엔지니어): 프롬프트를 바꿔가며 최적화를 수행하는 역할하는데 결국은 테스트 데이터를 만들어 벡터 DB 등의 검색 품질을 평가하고 최종적으로 RAG 시스템의 품질을 평가해야 한다. 이 과정에서 개발자와 밀접한 협업을 하게 된다.
 * 개발자 (RAG 시스템 개발자): 벡터 DB을 주기적으로 빌딩하고 검색을 수행하며 LLM을 API로 통해 관리(실패시 재시도하거나 다른 LLM 시도, 비용 관리 등등 운영적인 부분이 중요)하며 전체적인 아키덱처를 잡되 프롬프트와 관련된 부분이나 검색 최적화와 관계된 부분에 있어서 앞서 도메인 전문가와 긴밀하게 일을 하게 된다.

개발자 같은 경우 다양한 파이프라인을 만들어야 하는데 하나는 벡터 DB 등의 데이터베이스를 빌딩하는데 필요한 데이터 소스를 긁어오는 ETL 파이프라인과 이렇게 쌓인 데이터들로부터 최종 데이터를 만들고 이를 벡터 DB 등으로 로딩하는 ELT와 Reverse ETL 파이프라인등을 만들어야 하는데 여기서 바로 데이터 엔지니어링 스킬이 필요하다. 다른 파이프라인은 사용자 질의로부터 시작해서 최종적으로 사용자에게 응답을 리턴하는 런타임 파이프라인이며 여기에는 벡터 DB 질의와 LLM 질의 등이 포함되며 비용과 응답 시간 등등 관리해야할 항목이 많다.

LLMOps팀의 개발은 여러 사이클을 반복하는 형태로 이뤄지게 되는데 보통 아래와 같은 스텝을 필요로 한다.

 1. LLM 서비스 기획
 2. 개발
    1. 프롬프트 시스템 개발 (도메인 전문가)
    2. RAG 파이프라인 개발 (개발자). 여기에는 앞에 이야기한 데이터 파이프라인의 개발도 포함된다.
 3. 평가: 오프라인 테스트셋으로 검색과 최종 결과물 평가 두 종류를 가질 수 있다면 최적이다
 4. 스테이징 시스템 배포 후 다시 평가
    1. 이 때는 온라인 테스트도 수행
    2. 전체적인 응답속도 평가도 중요
 5. 만족할 만한 결과가 나올 때까지 2-4를 반복한다.
 6. 최종 배포 후 모니터링 (이때 비용 모니터링도 중요)

LLMOps팀이 궁극적으로 목표로 삼아야 하는 시스템은 도메인 전문가가 개발자와 아주 밀접한 의사소통 없이 셀프 서비스 형태로 원하는 LLM 기반 서비스를 만들 수 있는 No Code 혹은 Low Code 프레임웍을 만드는 것이다. 아직은 이 방향으로 뚜렷한 위너는 안 보이는데 곧 나오지 않을까 싶다. 혹시라도 알고 있는 서비스나 툴이 있다면 댓글 부탁!

다음 글에서는 데이터 웨어하우스에 관해서 프로덕션 데이터베이스와 비교해가며 더 설명해보고자 한다.

초거대 언어 모델(LLM: Large Language Model)을 사용하는 애플리케이션의 개발 및 배포 과정에서 발생하는 문제들은 ML 모델의 개발과 배포 과정에서 생기는 문제들과 마찬가지로 매우 다양하다. 처음 한 번은 LLM 기반 서비스를 만들하고 배포할 수 있지만, 그 후 LLM이 업그레이드되거나 새로운 LLM을 써보려고 한다면 어떤 최적화 및 검증 프로세스를 갖고 있느냐가 굉장히 중요해진다. 여기서 차별화된 경쟁력이 나오며, 이를 LLMOps 엔지니어가 담당하게 된다. LLMOps는 LLM을 활용하는 다양한 서비스 개발과 운영에 필요한데 보통 RAG(Retrieval Augmented Genenration)라는 모양을 갖는 것이 현재로는 일반적이며 도메인과 관련된 지식을 벡터DB로 별도로 저장하고 이를 최종 프롬프트 생성에 사용하게 된다. 몇 가지 예를 들어보면 다음과 같다. <ol ><li>대화형 AI 서비스: 챗봇 및 가상 비서 등등</li><li>콘텐츠 생성 및 편집: 작문, 자동 번역, 뉴스 기사 생성 등등</li><li>교육 및 학습: 개인화된 학습 보조 도구, 자동 채점 및 피드백 시스템, 언어학습 등등</li><li>비즈니스 인텔리전스: 데이터 분석 및 보고서 생성, 시장 트렌드 분석 등등</li><li>의료 및 헬스케어: 의료 기록 분석 및 요약, 보험사 청구서 자동 작성, 질병 진단 보조 등등</li><li>법률 및 규제: 법률 문서 분석 및 요약, 계약서 검토 자동화 등등</li><li>소프트웨어 개발: 코드 자동 생성 및 최적화, 버그 검출 및 수정 제안, 개발 문서 자동화</li><li>창작 및 엔터테인먼트: 음악 작곡, 게임 시나리오 및 캐릭터 생성 등등</li><li>...</li></ol> LLMOps는 위와 같은 서비스를 만듬에 있어 LLM 관련 최적화와 운영, 관리를 책임지는 직군이다. 이 직무는 머신러닝 모델의 생애주기를 관리하는 MLOps와 아주 유사하지만, 머신 러닝 모델을 직접 만들고 그것의 생애를 관리하는 것이 아니라 누군가 만든 LLM(ChatGPT, Claude, Gemini 등등)을 가져다 쓰면서 프롬프트 관리와 RAG와 같은 서비스라면 벡터 DB 등 다른 시스템이 존재하게 되는데 이를 전체적으로 최적화하고 평가하고 배포 후에 비용 등을 관리하면서 운영한다는 점이 다르다. 아직은 LLMOps팀이 전체 프로세스에 걸쳐 사용할 수 있는 하나의 플랫폼은 존재하지 않다고 보여지고 (그런 방향성을 갖고 있는 툴들은 존재) 다양한 툴을 섞어 사용해야 한다. <ul ><li>RAG 빌딩 툴: LangChain과 Llama Index가 가장 대표적인데 이 둘의 성격이 많이 다르긴 하지만 LangChain은 너무 복잡한 느낌이 있어서 개인적으로는 Llama Index를 선호한다. 써본 적은 없지만 PromptFlow도 괜찮다는 이야기를 많이 들었다.</li><li>벡터 DB: Pinecone, ElasticSearch, Weaviate, VESPA, FAISS, GCP Vertex 등등 아주 많다. 개인적으로는 벡터 임베딩을 통한 검색 뿐만 아니라 키워드 기반 검색도 같이 사용하는 것이 더 효율적이라 생각하기에 이 두 가지를 잘 지원해주는 VESPA가 개인적으로는 가장 마음에 든다</li><li>프롬프트 실험 및 관리: 많이 사용해본 툴이 없긴 하지만 Vellum, Baserun이 가장 많이 쓰이는 것으로 보인다. LangChain은 이 부분을 어느 정도 커버하긴 한다.</li><li>성능 평가 툴: LLM 기반의 앱의 성능을 평가할 수 있는 테스트셋이 필요하고 이를 버저닝하고 관리할 수 있는 툴이 필요하다. RAG라면 사용되는 벡터DB로부터 사용자 질의와 관련된 정보를 검색해야 하는데 결과 품질을 평가할 수 있는 테스트셋도 필요하다. Ragas, Haystack, Truelens 등이 있고 LangChain도 이 기능을 일부 지원한다</li></ul> 업무에 대해 더 이야기해보자면 보통 LLMOps팀은 개발자와 도메인 전문가 두 직군의 사람이 협업을 하는 형태로 일을 하게 된다. <ul ><li>도메인 전문가 (프롬프트 엔지니어): 프롬프트를 바꿔가며 최적화를 수행하는 역할하는데 결국은 테스트 데이터를 만들어 벡터 DB 등의 검색 품질을 평가하고 최종적으로 RAG 시스템의 품질을 평가해야 한다. 이 과정에서 개발자와 밀접한 협업을 하게 된다.</li><li>개발자 (RAG 시스템 개발자): 벡터 DB을 주기적으로 빌딩하고 검색을 수행하며 LLM을 API로 통해 관리(실패시 재시도하거나 다른 LLM 시도, 비용 관리 등등 운영적인 부분이 중요)하며 전체적인 아키덱처를 잡되 프롬프트와 관련된 부분이나 검색 최적화와 관계된 부분에 있어서 앞서 도메인 전문가와 긴밀하게 일을 하게 된다.</li></ul> 개발자 같은 경우 다양한 파이프라인을 만들어야 하는데 하나는 벡터 DB 등의 데이터베이스를 빌딩하는데 필요한 데이터 소스를 긁어오는 ETL 파이프라인과 이렇게 쌓인 데이터들로부터 최종 데이터를 만들고 이를 벡터 DB 등으로 로딩하는 ELT와 Reverse ETL 파이프라인등을 만들어야 하는데 여기서 바로 데이터 엔지니어링 스킬이 필요하다. 다른 파이프라인은 사용자 질의로부터 시작해서 최종적으로 사용자에게 응답을 리턴하는 런타임 파이프라인이며 여기에는 벡터 DB 질의와 LLM 질의 등이 포함되며 비용과 응답 시간 등등 관리해야할 항목이 많다. LLMOps팀의 개발은 여러 사이클을 반복하는 형태로 이뤄지게 되는데 보통 아래와 같은 스텝을 필요로 한다. <ol ><li>LLM 서비스 기획</li><li>개발<ol ><li>프롬프트 시스템 개발 (도메인 전문가)</li><li>RAG 파이프라인 개발 (개발자). 여기에는 앞에 이야기한 데이터 파이프라인의 개발도 포함된다.</li></ol></li><li>평가: 오프라인 테스트셋으로 검색과 최종 결과물 평가 두 종류를 가질 수 있다면 최적이다</li><li>스테이징 시스템 배포 후 다시 평가<ol ><li>이 때는 온라인 테스트도 수행</li><li>전체적인 응답속도 평가도 중요</li></ol></li><li>만족할 만한 결과가 나올 때까지 2-4를 반복한다.</li><li>최종 배포 후 모니터링 (이때 비용 모니터링도 중요)</li></ol> LLMOps팀이 궁극적으로 목표로 삼아야 하는 시스템은 도메인 전문가가 개발자와 아주 밀접한 의사소통 없이 셀프 서비스 형태로 원하는 LLM 기반 서비스를 만들 수 있는 No Code 혹은 Low Code 프레임웍을 만드는 것이다. 아직은 이 방향으로 뚜렷한 위너는 안 보이는데 곧 나오지 않을까 싶다. 혹시라도 알고 있는 서비스나 툴이 있다면 댓글 부탁! 다음 글에서는 데이터 웨어하우스에 관해서 프로덕션 데이터베이스와 비교해가며 더 설명해보고자 한다.

데이터 이야기 #9: LLMOps 엔지니어

계란후라이 1089

Q1) 상사가 화를 내면서 업무를 지시하는 상황에서 인턴으로 제가 할 수 있는 최선의 방법은 무엇일까요?
먼저 상사가 왜 화가 났는지 물어봐야 합니다. 그리고 정서적 공감 능력을 발휘하여 상사의 마음을 이해한다고 이야기할 수 있으면 좋습니다. 이는 아부가 아니요, 사람에 대한 존중의 표현입니다. 그다음 업무에 대한 이야기를 나누면 차분하게 이성적인 대화가 가능할 것입니다. 그런데 요즘도 감정적인 대화를 하려는 구성원이 있는 곳이라면 입사를 고민해 볼 필요가 있습니다. 요즘은 문화가 많이 바뀌어 상사가 일방적으로 팀원에게 업무 지시를 하는, 그것도 감정을 실어서 폭력적인 대화를 하는 분위기가 많이 사라졌다고 생각합니다.

Q2) 팀원들의 의견이 좁혀지지 않는 상황, 직급이 같은 직원들끼리의 의견 조율을 하는 최선의 방법은 무엇일까요?
의견은 얼마든지 다를 수 있습니다. 서로 다른 의견을 건강한 방법으로 조율하는 것이 필요합니다. 먼저 서로의 의견을 경청합니다. ‘나’와 생각이 다르다고 상대방의 의견을 듣지 않고, 내 의견만 주장하는 것으로 의견 조율이 어렵습니다. 토론의 기본은 경청입니다.
자신의 주장은 근거를 가지고 의견을 제시합니다. 근거 없는 자기주장은 설득력이 부족합니다. 과거 본인 경험에 의거하여 그것이 정답인 것처럼 주장하는 것은 옳지 않습니다. 객관적인 근거를 바탕으로 의견을 제시하는 논리적인 토론 문화가 필요합니다.
의사 결정 방식을 처음부터 정하고 토론을 시작합니다. 다수결로 정할지, 의사 결정권자가 최종 결론을 내릴지 토론 시작 전에 정의하면 구성원 간 의견이 갈려도 우왕좌왕하지 않을 수 있습니다. 구성원은 의견을 제시하고 의사결정이 합리적으로 내려질 수 있다는 신뢰를 갖습니다. 신뢰를 바탕으로 서로 격렬하게 토론할 수 있습니다. 직급에 관계없이 자유롭게 토론할 때 훌륭한 대안이 도출될 수 있다고 믿습니다.

Q3) 미리 정해진 일정과 갑자기 생긴 야근의 경우, 우선순위가 미리 정해진 일이 매우 중요할 때 최대한 상사에게 야근을 참여할 수 없다고 이야기하는 방법은 무엇일까요?
업무 시간과 일정 관리는 온전히 구성원이 해야 할 역할입니다. 상사가 정해주는 것은 업무를 주도적으로 못하고 있다는 반증입니다. 수동적인 업무 진행은 과정이 재미없고, 성과가 좋지 않습니다.
필요에 따라 야근도 할 수 있습니다. 다만, 오늘 일을 얼마나 할 것인지 결정은 본인이 합니다. 하루마다 자신이 가용할 수 있는 시간을 계산하여 처리해야 할 일감을 완수하는데 필요한 시간으로 하루, 일주일 단위로 업무를 배분합니다. 그럼 일과 시간 이후까지 일을 해야 하는지, 개인 사정에 따라 일을 더 할 수 있는 날짜가 언제인지 계획할 수 있습니다. 그렇다면 질문처럼 상사가 요구하는 야근은 잘 일어나지 않을 것입니다.
물론 갑자기 발생하는 비상사태는 예외입니다. 그럴 땐 개인 약속을 조정하는 것이 바람직합니다. ‘나’는 절대 양보할 수 없고, 회사가 무조건 이해해야 한다는 사고방식은 잘못되었습니다. 서로의 상태를 공감하여 합리적인 방향으로 배려하고 맞추려는 노력이 필요합니다.

계란후라이 1089 Q1) 상사가 화를 내면서 업무를 지시하는 상황에서 인턴으로 제가 할 수 있는 최선의 방법은 무엇일까요?먼저 상사가 왜 화가 났는지 물어봐야 합니다. 그리고 정서적 공감 능력을 발휘하여 상사의 마음을 이해한다고 이야기할 수 있으면 좋습니다. 이는 아부가 아니요, 사람에 대한 존중의 표현입니다. 그다음 업무에 대한 이야기를 나누면 차분하게 이성적인 대화가 가능할 것입니다. 그런데 요즘도 감정적인 대화를 하려는 구성원이 있는 곳이라면 입사를 고민해 볼 필요가 있습니다. 요즘은 문화가 많이 바뀌어 상사가 일방적으로 팀원에게 업무 지시를 하는, 그것도 감정을 실어서 폭력적인 대화를 하는 분위기가 많이 사라졌다고 생각합니다.​Q2) 팀원들의 의견이 좁혀지지 않는 상황, 직급이 같은 직원들끼리의 의견 조율을 하는 최선의 방법은 무엇일까요?의견은 얼마든지 다를 수 있습니다. 서로 다른 의견을 건강한 방법으로 조율하는 것이 필요합니다. 먼저 서로의 의견을 경청합니다. ‘나’와 생각이 다르다고 상대방의 의견을 듣지 않고, 내 의견만 주장하는 것으로 의견 조율이 어렵습니다. 토론의 기본은 경청입니다.자신의 주장은 근거를 가지고 의견을 제시합니다. 근거 없는 자기주장은 설득력이 부족합니다. 과거 본인 경험에 의거하여 그것이 정답인 것처럼 주장하는 것은 옳지 않습니다. 객관적인 근거를 바탕으로 의견을 제시하는 논리적인 토론 문화가 필요합니다.의사 결정 방식을 처음부터 정하고 토론을 시작합니다. 다수결로 정할지, 의사 결정권자가 최종 결론을 내릴지 토론 시작 전에 정의하면 구성원 간 의견이 갈려도 우왕좌왕하지 않을 수 있습니다. 구성원은 의견을 제시하고 의사결정이 합리적으로 내려질 수 있다는 신뢰를 갖습니다. 신뢰를 바탕으로 서로 격렬하게 토론할 수 있습니다. 직급에 관계없이 자유롭게 토론할 때 훌륭한 대안이 도출될 수 있다고 믿습니다.​Q3) 미리 정해진 일정과 갑자기 생긴 야근의 경우, 우선순위가 미리 정해진 일이 매우 중요할 때 최대한 상사에게 야근을 참여할 수 없다고 이야기하는 방법은 무엇일까요?업무 시간과 일정 관리는 온전히 구성원이 해야 할 역할입니다. 상사가 정해주는 것은 업무를 주도적으로 못하고 있다는 반증입니다. 수동적인 업무 진행은 과정이 재미없고, 성과가 좋지 않습니다.필요에 따라 야근도 할 수 있습니다. 다만, 오늘 일을 얼마나 할 것인지 결정은 본인이 합니다. 하루마다 자신이 가용할 수 있는 시간을 계산하여 처리해야 할 일감을 완수하는데 필요한 시간으로 하루, 일주일 단위로 업무를 배분합니다. 그럼 일과 시간 이후까지 일을 해야 하는지, 개인 사정에 따라 일을 더 할 수 있는 날짜가 언제인지 계획할 수 있습니다. 그렇다면 질문처럼 상사가 요구하는 야근은 잘 일어나지 않을 것입니다.물론 갑자기 발생하는 비상사태는 예외입니다. 그럴 땐 개인 약속을 조정하는 것이 바람직합니다. ‘나’는 절대 양보할 수 없고, 회사가 무조건 이해해야 한다는 사고방식은 잘못되었습니다. 서로의 상태를 공감하여 합리적인 방향으로 배려하고 맞추려는 노력이 필요합니다.

꿈을 찾는 사람에게 보내는 277 번째 편지

htmx gives you access to AJAX, CSS Transitions, WebSockets and Server Sent Events directly in HTML, using attributes, so you can build modern user interfaces with the simplicity and power of hypertext

    htmx is small (~14k min.gz’d), dependency-free, extendable, IE11 compatible & has reduced code base sizes by 67% when compared with react

</> htmx ~ Why Gumroad Didn't Choose htmx

프론트엔드는 React가 대세로 자리 잡았지만 또 그 복잡성때문에 다른 방법을 추구하는 사람도 적지 않습니다. 그런 대안으로 떠오른 것 중 하나가 htmx인데 온라인 커머스 서비스를 운영하고 있는 Gumroad에서 htmx를 고려하다가 선택하지 않은 이유를 설명합니다.

Gumroad CEO는 React가 자신들에게는 과하다고 생각했기에 htmx를 처음 선택했을 때는 만족했다고 합니다.

하지만 복잡한 form을 다루는 경우에는 Next.js보다 htmx가 더 복잡해졌고 불가능한 것은 아니지만 억지로 htmx에서 처리하는 것이 부자연스럽게 느껴졌다고 합니다. 그리고 htmx를 사용하면 Rais에서 CRUD 방식이 강제되면서 더 좋은 UX를 제공하기도 쉽지 않아졌습니다.

htmx르 Gumroad를 만드는 것이 불가능 한 것은 아니었지만 htmx의 장점에서 벗어나고 있다고 느껴져서 결국 React와 Next.js를 선택했다고 합니다.

https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

프론트엔드는 React가 대세로 자리 잡았지만 또 그 복잡성때문에 다른 방법을 추구하는 사람도 적지 않습니다. 그런 대안으로 떠오른 것 중 하나가 htmx인데 온라인 커머스 서비스를 운영하고 있는 Gumroad에서 htmx를 고려하다가 선택하지 않은 이유를 설명합니다. Gumroad CEO는 React가 자신들에게는 과하다고 생각했기에 htmx를 처음 선택했을 때는 만족했다고 합니다. 하지만 복잡한 form을 다루는 경우에는 Next.js보다 htmx가 더 복잡해졌고 불가능한 것은 아니지만 억지로 htmx에서 처리하는 것이 부자연스럽게 느껴졌다고 합니다. 그리고 htmx를 사용하면 Rais에서 CRUD 방식이 강제되면서 더 좋은 UX를 제공하기도 쉽지 않아졌습니다. htmx르 Gumroad를 만드는 것이 불가능 한 것은 아니었지만 htmx의 장점에서 벗어나고 있다고 느껴져서 결국 React와 Next.js를 선택했다고 합니다. https://htmx.org/essays/why-gumroad-didnt-choose-htmx/

htmx.org

Generate interactive flashcards from your notes using models from OpenAI (ChatGPT), Google (Gemini), Ollama (local LLMs), and more. Or manually create your own to use with the quiz UI. - ECuiDev/ob...

GitHub - ECuiDev/obsidian-quiz-generator: Generate interactive flashcards from your notes using models from OpenAI (ChatGPT), Google (Gemini), Ollama (local LLMs), and more. Or manually create your own to use with the quiz UI.

노트에 열심히 적어놓고 나중에 보면 무슨 내용인지 기억이 안 날 때가 많습니다. 복습 용도로 AI가 퀴즈를 내주면 좋겠다고 생각했었는데, 구글링하다가 찾은 Quiz Generator 플러그인이 제가 딱 생각한 역할을 하는 플러그인이여서 소개드립니다.

이 플러그인은 여러분이 작성한 노트나 폴더를 넣으면 알아서 맞춤형 퀴즈를 만들어줍니다. 거의 모든 주요 AI 제공업체의 모델을 지원하는데요, OpenAI, Google, Anthropic, Perplexity, Mistral, Cohere, Ollama 등이 포함돼 있습니다. 다국어도 지원하는데 그 중 한국어도 사용 가능합니다.

설치는 옵시디언 커뮤니티 플러그인에서 Quiz Generator를 검색해서 설치하시고, 설정에 들어가 Provider와 API Key를 입력하고 저장하면 됩니다. 경험상 Provider는 OpenAI로 설정해서 사용하는 걸 추천드립니다. Claude 3.5도 써봤는데 일부 기능이 잘 안 되더라구요.
설정이 끝나면 왼쪽 사이드바에 뇌 모양 아이콘이 생기는데, 이걸 클릭해서 원하는 노트나 폴더를 선택하고 하단의 퀴즈 생성 버튼을 누르면 잠시 후에 퀴즈를 만들어줍니다.

최근에 HTTP 관련 노트로 퀴즈를 만들어봤는데요, 당시엔 완벽하게 공부했다고 생각했지만 퀴즈를 풀어보니 절반 이상을 틀리더라구요. 복습의 중요성을 다시 한 번 깨달았습니다ㅎ 그 때부터 이 플러그인으로 옛날 노트들의 퀴즈를 만들어서 풀어보고 있는데 확실히 도움이 많이 되는 것 같아요.

플러그인 깃허브 링크는 아래에 있습니다. 링크에 데모 동영상도 있으니 써보기 전에 한 번 느낌을 보시고 설치해 보시는 것도 좋습니다.

https://github.com/ECuiDev/obsidian-quiz-generator

노트에 열심히 적어놓고 나중에 보면 무슨 내용인지 기억이 안 날 때가 많습니다. 복습 용도로 AI가 퀴즈를 내주면 좋겠다고 생각했었는데, 구글링하다가 찾은 Quiz Generator 플러그인이 제가 딱 생각한 역할을 하는 플러그인이여서 소개드립니다. 이 플러그인은 여러분이 작성한 노트나 폴더를 넣으면 알아서 맞춤형 퀴즈를 만들어줍니다. 거의 모든 주요 AI 제공업체의 모델을 지원하는데요, OpenAI, Google, Anthropic, Perplexity, Mistral, Cohere, Ollama 등이 포함돼 있습니다. 다국어도 지원하는데 그 중 한국어도 사용 가능합니다. 설치는 옵시디언 커뮤니티 플러그인에서 Quiz Generator를 검색해서 설치하시고, 설정에 들어가 Provider와 API Key를 입력하고 저장하면 됩니다. 경험상 Provider는 OpenAI로 설정해서 사용하는 걸 추천드립니다. Claude 3.5도 써봤는데 일부 기능이 잘 안 되더라구요.설정이 끝나면 왼쪽 사이드바에 뇌 모양 아이콘이 생기는데, 이걸 클릭해서 원하는 노트나 폴더를 선택하고 하단의 퀴즈 생성 버튼을 누르면 잠시 후에 퀴즈를 만들어줍니다. 최근에 HTTP 관련 노트로 퀴즈를 만들어봤는데요, 당시엔 완벽하게 공부했다고 생각했지만 퀴즈를 풀어보니 절반 이상을 틀리더라구요. 복습의 중요성을 다시 한 번 깨달았습니다ㅎ 그 때부터 이 플러그인으로 옛날 노트들의 퀴즈를 만들어서 풀어보고 있는데 확실히 도움이 많이 되는 것 같아요. 플러그인 깃허브 링크는 아래에 있습니다. 링크에 데모 동영상도 있으니 써보기 전에 한 번 느낌을 보시고 설치해 보시는 것도&nbsp;좋습니다. https://github.com/ECuiDev/obsidian-quiz-generator

GitHub

AI로 맞춤형 퀴즈를 만들어주는 옵시디언 플러그인

GitHub Actions를 사용하여 리포지토리에서 바로 소프트웨어 개발 워크플로를 자동화, 사용자 지정 및 실행합니다. CI/CD를 포함하여 원하는 작업을 수행하기 위한 작업을 검색, 생성 및 공유하고 완전히 사용자 정의된 워크플로에서 작업을 결합할 수 있습니다.

GitHub Actions 설명서 - GitHub Docs

최근 지속적 통합(CI)과 지속적 배포(CD)의 중요성이 날로 커지고 있습니다. 이러한 흐름에 맞추어
GitHub Actions
가 점점 많이 사용되고 있는데요. 과거에는
Jenkins
를 주로 사용했지만 최근에는 비교적 접근성이 좋은
Github Action
을 더 많이 사용하고 있어
GitHub Actions
의 개념을 한번 정리해보았습니다.

GitHub Actions
는
GitHub
에서 제공하는 CI/CD 서비스입니다. 개발자들은
GitHub
코드 저장소와 직접 연계된 자동화된 워크플로우를 비교적 손쉽게 구축할 수 있습니다.

1. 활용 사례
 * 자동화된 배포: 새로운 기능이나 버전을 서버에 자동으로 배포
 * 주기적 작업 실행: 데이터 수집, 처리 등의 정기적인 작업 자동화
 * 테스트 자동화: 코드 변경 시 자동으로 테스트 실행

2. 개념
Workflow:
 * 자동화된 전체 프로세스를 정의
 * YAML 형식으로 작성되며, 프로젝트의 최상위 개념
Event:
 * Workflow를 트리거하는 특정 활동이나 조건
 * 예: 특정 브랜치로의 푸시, Pull Request 생성 등
Job:
 * 독립된 실행 환경
 * 가상 머신 또는 컨테이너 Ex:
   Lunux(ubuntu-latest), Window
   에서 수행되는 작업 단위
Steps:
 * Job
   내부에서 순차적으로 실행되는 개별 작업들
 * 셸 명령어 실행이나
   Action
   사용 등을 포함
Action:
 * GitHub Actions의 꽃
 * 재사용 가능한 작업 단위로, GitHub Marketplace에서 다양한 Action 활용 가능
 * Ex:
   actions/checkout@v4
   (레포지토리를 워크플로우 실행 환경으로 가져옴. 복제)
Runner:
 * Workflow
   를 실행하는 서버 인스턴스
 * GitHub
   에서 제공하는 호스팅
   Runner
   또는 사용자가 직접 관리하는
   Self-hosted Runner
   선택 가능

3. 고려사항
 * 보안: 민감한 정보는
   GitHub Secrets
   를 활용하여 안전하게 관리
 * 모듈화: 재사용 가능한
   Action
   개발을 통한 생산성 향상

이런 자동화 프로세스를 이용하여 팀의 생산성을 높여 보세요. 반복적인 작업에서 벗어나 더 가치 있는 업무에 집중할 수 있습니다.

https://docs.github.com/ko/actions

최근 지속적 통합(CI)과 지속적 배포(CD)의 중요성이 날로 커지고 있습니다. 이러한 흐름에 맞추어 <code >GitHub Actions</code>가 점점 많이 사용되고 있는데요. 과거에는 <code >Jenkins</code>를 주로 사용했지만 최근에는 비교적 접근성이 좋은 <code >Github Action</code>을 더 많이 사용하고 있어 <code >GitHub Actions</code>의 개념을 한번 정리해보았습니다. <code >GitHub Actions</code>는 <code >GitHub</code>에서 제공하는 CI/CD 서비스입니다. 개발자들은 <code >GitHub</code>코드 저장소와 직접 연계된 자동화된 워크플로우를 비교적 손쉽게 구축할 수 있습니다. 1. 활용 사례<ul ><li>자동화된 배포: 새로운 기능이나 버전을 서버에 자동으로 배포</li><li>주기적 작업 실행: 데이터 수집, 처리 등의 정기적인 작업 자동화</li><li>테스트 자동화: 코드 변경 시 자동으로 테스트 실행</li></ul> 2. 개념Workflow:<ul ><li>자동화된 전체 프로세스를 정의</li><li>YAML 형식으로 작성되며, 프로젝트의 최상위 개념</li></ul>Event:<ul ><li>Workflow를 트리거하는 특정 활동이나 조건</li><li>예: 특정 브랜치로의 푸시, Pull Request 생성 등</li></ul>Job:<ul ><li>독립된 실행 환경</li><li>가상 머신 또는 컨테이너 Ex: <code >Lunux(ubuntu-latest), Window</code>에서 수행되는 작업 단위</li></ul>Steps:<ul ><li><code >Job</code> 내부에서 순차적으로 실행되는 개별 작업들</li><li>셸 명령어 실행이나 <code >Action</code> 사용 등을 포함</li></ul>Action:<ul ><li>GitHub Actions의 꽃</li><li>재사용 가능한 작업 단위로, GitHub Marketplace에서 다양한 Action 활용 가능</li><li>Ex: <code >actions/checkout@v4</code>(레포지토리를 워크플로우 실행 환경으로 가져옴. 복제)</li></ul>Runner:<ul ><li><code >Workflow</code>를 실행하는 서버 인스턴스</li><li><code >GitHub</code>에서 제공하는 호스팅 <code >Runner</code> 또는 사용자가 직접 관리하는 <code >Self-hosted Runner</code> 선택 가능</li></ul> 3. 고려사항<ul ><li>보안: 민감한 정보는 <code >GitHub Secrets</code>를 활용하여 안전하게 관리</li><li>모듈화: 재사용 가능한 <code >Action</code> 개발을 통한 생산성 향상</li></ul> 이런 자동화 프로세스를 이용하여 팀의 생산성을 높여 보세요. 반복적인 작업에서 벗어나 더 가치 있는 업무에 집중할 수 있습니다. https://docs.github.com/ko/actions

GitHub Docs

개발 생산성 향상을 위한 GitHub Actions: CI/CD 자동화

“그날 나는 결심했다. 내가 매니저가 된다면 팀원들에게 성장에 필요한 조언을 주리라.”

소프트웨어 엔지니어 가이드북

지난 2월, 이 책을 발견하고 단숨에 읽었다. 책이 주는 깊이 있는 통찰과 실용적인 조언에 감명받았고, 번역이 시작된다는 소식에 무척 기뻤다. 8개월의 기다림 끝에, 드디어 번역되어 출간되었다!

소프트웨어 엔지니어의 커리어를 다룬 책은 많지만, 이처럼 경력 전반을 포괄적이고 체계적으로 정리한 책은 드물다고 생각한다. 저자는 초급 엔지니어부터 테크 리드, 스태프 엔지니어에 이르기까지, 각 단계에서 필요한 지식과 스킬을 명확히 제시한다. 많은 커리어 서적이 특정 측면에만 집중하지만, 이 책은 개인과 조직, 나아가 기업 차원에서 영향력을 발휘할 수 있는 전략을 폭넓게 다루며 엔지니어의 성장 과정을 포괄적으로 안내한다.

특히 이 책은 커뮤니케이션과 리더십 같은 소프트 스킬뿐만 아니라, 소프트웨어 엔지니어링의 핵심 역량과 그 중요성을 다룬다. 구체적인 기술적 세부 사항에 치우치지 않고, 다양한 경력 단계에서 해당 역량이 왜 필요한지, 어떻게 준비해야 하는지를 말해준다. 이러한 접근은 독자가 실무와 리더십 사이에서 자신만의 길을 찾도록 도울 수 있을 것으로 기대된다.

마치 OTT 서비스의 날것의 프로그램처럼, 이 책은 기존에 정형화된 커리어 서적과는 다른 신선함과 통쾌함을 줬다. 많은 엔지니어가 이 책을 통해 단순한 지식 이상의 것을 얻어, 진정한 의미의 성장을 위한 영감을 받을 수 있을 것이다.

https://www.hanbit.co.kr/store/books/look.php?p_code=B2570473158

지난 2월, 이 책을 발견하고 단숨에 읽었다. 책이 주는 깊이 있는 통찰과 실용적인 조언에 감명받았고, 번역이 시작된다는 소식에 무척 기뻤다. 8개월의 기다림 끝에, 드디어 번역되어 출간되었다! 소프트웨어 엔지니어의 커리어를 다룬 책은 많지만, 이처럼 경력 전반을 포괄적이고 체계적으로 정리한 책은 드물다고 생각한다. 저자는 초급 엔지니어부터 테크 리드, 스태프 엔지니어에 이르기까지, 각 단계에서 필요한 지식과 스킬을 명확히 제시한다. 많은 커리어 서적이 특정 측면에만 집중하지만, 이 책은 개인과 조직, 나아가 기업 차원에서 영향력을 발휘할 수 있는 전략을 폭넓게 다루며 엔지니어의 성장 과정을 포괄적으로 안내한다. 특히 이 책은 커뮤니케이션과 리더십 같은 소프트 스킬뿐만 아니라, 소프트웨어 엔지니어링의 핵심 역량과 그 중요성을 다룬다. 구체적인 기술적 세부 사항에 치우치지 않고, 다양한 경력 단계에서 해당 역량이 왜 필요한지, 어떻게 준비해야 하는지를 말해준다. 이러한 접근은 독자가 실무와 리더십 사이에서 자신만의 길을 찾도록 도울 수 있을 것으로 기대된다. 마치 OTT 서비스의 날것의 프로그램처럼, 이 책은 기존에 정형화된 커리어 서적과는 다른 신선함과 통쾌함을 줬다. 많은 엔지니어가 이 책을 통해 단순한 지식 이상의 것을 얻어, 진정한 의미의 성장을 위한 영감을 받을 수 있을 것이다. https://www.hanbit.co.kr/store/books/look.php?p_code=B2570473158

www.hanbit.co.kr

소프트웨어 엔지니어라면 꼭 알아야 할 커리어 관리 비법

React 렌더링 전략이 어떻게 진화해왔는지를 분석하고, 각 방식의 특징, 장단점 그리고 전망에 대해 살펴보는 글입니다.

React 렌더링의 진화 : CSR,SSR 그리고 RSC까지

React Server Components(RSC)의 도입으로 
React
렌더링 전략의 새로운 시대를 목격하고 있습니다. 따라서 이런
RSC
를 더욱 잘 이해하기 위해
CSR
부터
SSR
그리고
RSC
에 관련된 블로그 글을 작성했습니다.

React
개발자는 이제 단순 기능 개발 구현과 더불어 프로젝트 요구사항을 토대로 최적의 렌더링 전략을 선택하고 구현하는 것이 중요한 능력인 시대에 접어들었습니다.

CSR
,
SSR
Hydration
개념. 또
SSR
을 이용한
RSC
의 활용법과 기술적 특성, 장점 오해 등을 기술했습니다.

State of React 2023 보고서 에서는 2028년경에는
RSC
를 포함한 '풀스택' 버전과,
SPA
두 가지 패러다임이 공존할 것으로 예상된다고 합니다.

따라서 각 렌더링 방식의 장단점을 이해하고 최적의 솔루션을 선택해야 개발자 경험 및 최상의 사용자 경험을 제공할 수 있습니다. 관련해서 더 자세한 내용은 블로그 글을 참조 해보시는것을 추천드립니다.

https://f-lab.kr/blog/evolution-of-react-rendering

React Server Components(RSC)의 도입으로 <code >React</code> 렌더링 전략의 새로운 시대를 목격하고 있습니다. 따라서 이런 <code >RSC</code>를 더욱 잘 이해하기 위해 <code >CSR</code> 부터 <code >SSR</code>그리고 <code >RSC</code>에 관련된 블로그 글을 작성했습니다. <code >React</code>개발자는 이제 단순 기능 개발 구현과 더불어 프로젝트 요구사항을 토대로 최적의 렌더링 전략을 선택하고 구현하는 것이 중요한 능력인 시대에 접어들었습니다. <code >CSR</code>, <code >SSR</code> <code >Hydration</code> 개념. 또 <code >SSR</code>을 이용한 <code >RSC</code>의 활용법과 기술적 특성, 장점 오해 등을 기술했습니다. State of React 2023 보고서 에서는 2028년경에는 <code >RSC</code>를 포함한 '풀스택' 버전과, <code >SPA</code> 두 가지 패러다임이 공존할 것으로 예상된다고 합니다. 따라서 각 렌더링 방식의 장단점을 이해하고 최적의 솔루션을 선택해야 개발자 경험 및 최상의 사용자 경험을 제공할 수 있습니다. 관련해서 더 자세한 내용은 블로그 글을 참조 해보시는것을 추천드립니다. https://f-lab.kr/blog/evolution-of-react-rendering

F-Lab : 상위 1% 개발자들의 멘토링

React의 진화: CSR에서 RSC까지 - 렌더링 전략 가이드

계란후라이 1086

과거 product manager 역할을 경험했습니다. 제가 원해서 했던 건 아니었고, 사업 개발 역할을 하다 보니 온라인 서비스 환경을 구축하고 개선해야 했습니다. 당시 막 시대에 회자되고 있는 product manager, product owner 역할이었습니다. 회사에서 그럼 우리도 사업 개발이라고 하지 말고 pm 직무를 만들자고 하여 pm 역할을 맡게 되었습니다.
지금에서 과거를 회고하면, 저는 좋은 pm 역할을 하지 못했습니다. 기능적으로도, 성과적으로도 뚜렷한 족적을 남기지 못했습니다. 모르는 것도 많았고, 그래서 할 줄 아는 것도 적었습니다. 그래서 주도적으로 이슈를 만들고 프로젝트를 이끌지 못하고, 수동적으로 시키는 일만 열심히 했습니다.
스포츠로 치면 짧게 선수 생활을 하면서 눈에 띄지 않았던 무명 선수입니다. 그러다가 코치가 되어 선수로 뛰고자 하는 사람들을 만나 코칭을 하고 있습니다. 성과를 만들어 본 것도 아니고, 일을 잘 해본 것도 아니면서 주제넘게 코칭을 하고 있습니다. 이론적으로 알고 있는 일 잘 하는 pm 역할 이야기를 전파하고 있습니다.
개미 코딱지 같은 경험과 역량을 가진 사람이지만, pm 직무로 취업을 원하는 데 도움이 필요하다면 제 이야기를 들어주세요. 특히 저처럼 다른 직무 하다가 pm 역할로 전환하고 싶은 분들에게 조금이나마 도움이 될 수 있겠습니다. 제가 pm 역할을 하며 잘 못했던 부분들을 잘 하면 인정받는 pm 직무 수행이 됩니다.
문제 정의를 잘 해야 합니다. 무엇이 문제인가? 고객이 그것을 진짜 문제라고 이야기하고 있는가? 그 문제는 꼭 개발로 풀어야 하는가? 문제의 본질과 주인, 해결 방법에 있어서 고민이 필요합니다. 문제니까 그냥 푼다가 아니라 진짜 문제가 맞는지 들여다봐야 합니다. 반드시 지금 풀어야 하는지 우선순위에 대한 고민도 필요합니다. 얼마나 깊게 해결할 것인지 투입할 자원을 고려한 문제 정의가 필요합니다.
사용자 경험을 고려하여 기획해야 합니다. 서비스 이용 고객에게 편의와 가치를 주는 기획, 서비스를 디자인하고 개발하는 협업 동료가 이해와 공감할 수 있는 기획이 되어야 합니다. 내 생각, 내 마음은 중요하지 않습니다. 실제 이용자 입장에서 생각하고, 그들이 좋아할 것을 만들어야 합니다.
만든 결과가 사용자에게 어떻게 사용되고 있는지 추적해야 합니다. 사용자 반응을 살펴야 합니다. 정성적으로 인터뷰를 통해 사용자의 서비스 이용 경험을 듣고, 정량적으로 사용자 활동 데이터를 분석해 의도한 것처럼 서비스를 잘 이용하고 있는지 검증해야 합니다.
회고를 통해 개선점을 도출하고, 다음 이슈를 제시해야 합니다. 잘한 점과 부족했던 점을 있는 그대로 피드백하여 동료가 성장할 수 있도록 도와야 합니다. 반대로 동료에게 피드백 받아 자신도 성장해야 합니다.
이렇게 일했어야 하는데 저는 위와 같이 일한 pm 경험자가 아닙니다. 부디 pm 직무로 취업을 희망하거나 앞으로 일을 더 잘 하고 싶은 pm 역할을 맡고 계신 분이 있다면 참고해 주세요. 일하는 방식뿐만 아니라 필요한 직무 기술도 위에 이야기를 곰곰이 생각해 보면 유추해 낼 수 있을 것입니다. 여러분의 도전을 진심으로 응원합니다.

계란후라이 1086 과거 product manager 역할을 경험했습니다. 제가 원해서 했던 건 아니었고, 사업 개발 역할을 하다 보니 온라인 서비스 환경을 구축하고 개선해야 했습니다. 당시 막 시대에 회자되고 있는 product manager, product owner 역할이었습니다. 회사에서 그럼 우리도 사업 개발이라고 하지 말고 pm 직무를 만들자고 하여 pm 역할을 맡게 되었습니다.지금에서 과거를 회고하면, 저는 좋은 pm 역할을 하지 못했습니다. 기능적으로도, 성과적으로도 뚜렷한 족적을 남기지 못했습니다. 모르는 것도 많았고, 그래서 할 줄 아는 것도 적었습니다. 그래서 주도적으로 이슈를 만들고 프로젝트를 이끌지 못하고, 수동적으로 시키는 일만 열심히 했습니다.스포츠로 치면 짧게 선수 생활을 하면서 눈에 띄지 않았던 무명 선수입니다. 그러다가 코치가 되어 선수로 뛰고자 하는 사람들을 만나 코칭을 하고 있습니다. 성과를 만들어 본 것도 아니고, 일을 잘 해본 것도 아니면서 주제넘게 코칭을 하고 있습니다. 이론적으로 알고 있는 일 잘 하는 pm 역할 이야기를 전파하고 있습니다.개미 코딱지 같은 경험과 역량을 가진 사람이지만, pm 직무로 취업을 원하는 데 도움이 필요하다면 제 이야기를 들어주세요. 특히 저처럼 다른 직무 하다가 pm 역할로 전환하고 싶은 분들에게 조금이나마 도움이 될 수 있겠습니다. 제가 pm 역할을 하며 잘 못했던 부분들을 잘 하면 인정받는 pm 직무 수행이 됩니다.문제 정의를 잘 해야 합니다. 무엇이 문제인가? 고객이 그것을 진짜 문제라고 이야기하고 있는가? 그 문제는 꼭 개발로 풀어야 하는가? 문제의 본질과 주인, 해결 방법에 있어서 고민이 필요합니다. 문제니까 그냥 푼다가 아니라 진짜 문제가 맞는지 들여다봐야 합니다. 반드시 지금 풀어야 하는지 우선순위에 대한 고민도 필요합니다. 얼마나 깊게 해결할 것인지 투입할 자원을 고려한 문제 정의가 필요합니다.사용자 경험을 고려하여 기획해야 합니다. 서비스 이용 고객에게 편의와 가치를 주는 기획, 서비스를 디자인하고 개발하는 협업 동료가 이해와 공감할 수 있는 기획이 되어야 합니다. 내 생각, 내 마음은 중요하지 않습니다. 실제 이용자 입장에서 생각하고, 그들이 좋아할 것을 만들어야 합니다.만든 결과가 사용자에게 어떻게 사용되고 있는지 추적해야 합니다. 사용자 반응을 살펴야 합니다. 정성적으로 인터뷰를 통해 사용자의 서비스 이용 경험을 듣고, 정량적으로 사용자 활동 데이터를 분석해 의도한 것처럼 서비스를 잘 이용하고 있는지 검증해야 합니다.회고를 통해 개선점을 도출하고, 다음 이슈를 제시해야 합니다. 잘한 점과 부족했던 점을 있는 그대로 피드백하여 동료가 성장할 수 있도록 도와야 합니다. 반대로 동료에게 피드백 받아 자신도 성장해야 합니다.이렇게 일했어야 하는데 저는 위와 같이 일한 pm 경험자가 아닙니다. 부디 pm 직무로 취업을 희망하거나 앞으로 일을 더 잘 하고 싶은 pm 역할을 맡고 계신 분이 있다면 참고해 주세요. 일하는 방식뿐만 아니라 필요한 직무 기술도 위에 이야기를 곰곰이 생각해 보면 유추해 낼 수 있을 것입니다. 여러분의 도전을 진심으로 응원합니다.

꿈을 찾는 사람에게 보내는 274 번째 편지

재직자 대상 커리어 성장 코스, INNER CIRCLE

패스트캠퍼스 : INNER CIRCLE | 패스트캠퍼스

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다.

“앞으로 5년 후에도 개발자로 살아남을 수 있을까?”
“사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?”
“풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.”
“회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.”

저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만
이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다.

이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다.

바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다.

📌 실무 중심의 팀프로젝트 커리큘럼
단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다.

📌 실시간 온라인 진행 가능
100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.
또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다.

📌 동료들과 함께 성장
이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.
프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다.

📌 업계 상위 1% 리더와 검증된 동료
IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.
개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다.

📌 비용
450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.
또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다.

📌 창업 및 프로젝트 지원
팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다.

성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲

10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.
(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.)

🔗 신청 바로 가기: https://bit.ly/3U5CQu3 

추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면
대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요.

🎁 추천인 코드 입력 방법
 1. 신청 바로 가기(https://bit.ly/3U5CQu3)에서 신청하기 버튼 클릭
 2. 신청 폼 작성
 3. 마지막 인지 경로 항목 작성 시 Other 클릭
 4. 주관식 문항에 추천인 코드 [이양일] 작성

이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

주니어 개발자로서 몇 년을 일하다 보면 자연스럽게 아래와 같은 고민들을 하실 것 같습니다. “앞으로 5년 후에도 개발자로 살아남을 수 있을까?” “사수도 없고, 내가 혼자서 잘하고 있는 게 맞을까?” “풀스택 개발자로 취업은 했지만, 실무에선 무슨 일이 어떻게 돌아가는지 막막하다.” “회사에서 주어진 일만 할 게 아니라, 내가 정말 원하는 프로젝트를 해보고 싶다.” 저도 물론 경험했던 고민들이고, 특강 및 멘토링 때 매번 말씀드리는 내용이지만이런 고민들을 해결할 수 있는 여러 방법중에 좋은것 하나는 A-Z 까지 경험해볼 수 있는 프로젝트를 진행하는 겁니다. 이와 관련되서 도움을 받으실 수 있을만한 교육 과정이 있어 공유드립니다. 바로 이너서클(INNER CIRCLE) 이라는 교육인데요, 제가 느꼈던 이너서클 교육의 가장 큰 장점은 다음과 같습니다. 📌 실무 중심의 팀프로젝트 커리큘럼단순한 이론 수업이 아닌, 13주간 100% 팀 프로젝트 중심 커리큘럼으로 진행되어 회사에서는 경험할 수 없는 다양한 매력적인 프로젝트를 A 부터 Z 까지 진행함으로써 한단계 더 성장하는 기회가 될 수 있습니다. 📌 실시간 온라인 진행 가능100% 실시간 온라인으로 진행하는 재직자 대상 무료 교육으로 평일 저녁, 주말에 진행하기 때문에 직장과 병행하여 수강이 가능합니다.또한 이너서클 과정 전반에 걸쳐 패스트캠퍼스의 온라인 VOD 강의를 제공하여 커리큘럼 진행중에 얼마든지 이론적 보완과 성장이 가능합니다. 📌 동료들과 함께 성장이너서클은 혼자가 아닌 동료 개발자들과의 협력을 경험할 수 있게 도와줍니다.프로젝트를 진행하며 동료 개발자들간의 피드백과 상호 평가를 통해 성장하고, 수료 후에도 오프라인 네트워킹으로 지속적인 교류가 가능합니다. 📌 업계 상위 1% 리더와 검증된 동료IT 업계 최고의 리더(네카라쿠배 출신의 IT 테크 리더)들이 강사로 참여하고, 이러한 리더들의 꼼꼼한 선발절차를 거쳐 팀프로젝트를 같이할 동료들이 선발된다고 합니다.개발팀장, CTO 등을 하셨던 리더분들이기 때문에 높은 수준의 실무 노하우를 배울 수 있고 이런 검증된 동료들과의 실전 경험과 교류는 개발자의 커리어를 쌓아가는데 매우 중요하다고 생각합니다. 📌 비용450만 원 상당의 교육비가 전액 국비 지원으로 무료입니다.또한 이너서클 수료 후, 패스트캠퍼스 취준생 멘토링 프로그램에 참여할 수 있는 기회가 주어지게 되는데 만약 프로그램에 참여하게 된다면 이에 대한 수익을 얻을 수 있다고 합니다. 📌 창업 및 프로젝트 지원팀별 프로젝트 진행 시, 프로젝트 지원금이 제공되며, 수료 후 창업을 준비한다면 패스트캠퍼스 미디어 노출, 인터뷰 등 다양한 지원을 받을 수 있습니다. 성장에 목마르신 모든 분들이 참여하실 수 있다면 좋겠지만, 3년차 이상의 경력이 있으신 분들 중 최종적으로 선별된 50명만 교육에 참여가 가능하다고 합니다.🥲 10월 27일까지 사전 신청을 완료하면, 얼리버드 이벤트로 개발자 커리어와 취업 시장에 관한 인사이트, 이너서클에 대한 사전 설명을 제공하는 멤버십 가이드 초대권도 드린다고 하니 관심있으신 분들은 이점 참고해주시면 좋겠습니다.(설명회는 10월 31일 19시에 온라인 라이브로 진행 예정이라고 합니다.) 🔗 신청 바로 가기: https://bit.ly/3U5CQu3&nbsp; 추가로 이너서클 측에서 감사하게도 제 이름으로 추천인 코드를 입력 후 수강 등록을 완료하면대기업 이직을 위한 자기소개서 작성법 전자책을 무료로 받을 수 있게 해주신다고 하니 이 점도 참고해주세요. 🎁 추천인 코드 입력 방법<ol ><li>신청 바로 가기(https://bit.ly/3U5CQu3)에서&nbsp;신청하기&nbsp;버튼 클릭</li><li>신청 폼 작성</li><li>마지막&nbsp;인지 경로&nbsp;항목 작성 시&nbsp;Other&nbsp;클릭</li><li>주관식 문항에 추천인 코드 [이양일] 작성</li></ol> 이 글이 성장하고 싶으신 주니어 개발자 분들에게 조금이나마 도움이 되었으면 좋겠습니다. 🙏

엘리스트랙

📢 실무 프로젝트로 성장하고 싶은 주니어 개발자 분들에게

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

 - YouTube

일 잘하는 개발자는 어떤 개발자 일까요? 흔히 개발자를 평가할 때 코드의 품질이나 기술적 숙련도만을 중요시하는 경향이 있는데요. 토스에서는 '일 잘하는 개발자' 란 코드 작성 외에도 고객에게 실질적인 가치를 제공하는 것이 더 중요하게 생각한다고 합니다. 다음은 토스가 중요하게 여기는 개발자의 자질들입니다:

요구사항을 넘어서는 통찰력
일 잘하는 개발자는 단순히 요구사항을 그대로 구현하는 것에 그치지 않습니다. 대신, 요구사항 속에 숨겨진 진정한 목적을 파악하고, 때로는 구현 없이도 그 목적을 달성할 수 있는 창의적인 방법을 제안합니다. 이는 단순한 '구현'을 넘어선 '문제 해결'에 초점을 맞추는 것입니다.

효율성과 가치의 균형
항상 효율성을 고민합니다. 예를 들어, "이 기능은 이렇게 하면 개발 시간을 절반으로 줄일 수 있을 것 같습니다. 먼저 이 방식으로 시도해보고, 나중에 더 발전시켜 보는 건 어떨까요?"와 같은 제안을 통해 극적인 효율 개선으로 이어질 수 있습니다.

'메이커'로서의 개발자
토스에서는 개발자를 단순한 '엔지니어'가 아닌 '메이커'로 부릅니다. 이는 개발자가 서비스에 대한 깊은 이해를 바탕으로 용기 있게 의견을 내고, 이를 통해 자신과 동료의 시간을 절약하며 제품의 성공에 기여할 수 있습니다.

빠른 런칭과 사용자 피드백의 중요성
제품을 빨리 런칭하고 실제 사용자의 목소리를 듣는 것이 중요합니다. 내부에서 생각하는 사용자의 의견은 실제와 다를 수 있기 때문입니다. 기능을 짧고 빠르게 만들어 출시하는 것이 성공으로 가는 지름길일 수 있습니다.

그렇지만 위와같은 방식이 모든 조직과 제품에 보편적으로 적용되는 것은 아닙니다. 조직의 특성과 제품의 발전 단계에 따라 '일 잘하는 개발자' 정의와 역할은 달라질 수 있습니다. 기능 중심 조직이고, 이미 완성도 높은 단계의 제품이라면 개발 전략과 우선순위가 달라질 수 있습니다.
이 관점은 주로 '사일로' 라는 목적 조직과 제품 초기 단계의 상황에 초점을 맞추고 있습니다.

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

일 잘하는 개발자는 어떤 개발자 일까요? 흔히 개발자를 평가할 때 코드의 품질이나 기술적 숙련도만을 중요시하는 경향이 있는데요. 토스에서는 '일 잘하는 개발자' 란 코드 작성 외에도 고객에게 실질적인 가치를 제공하는 것이 더 중요하게 생각한다고 합니다. 다음은 토스가 중요하게 여기는 개발자의 자질들입니다: 요구사항을 넘어서는 통찰력일 잘하는 개발자는 단순히 요구사항을 그대로 구현하는 것에 그치지 않습니다. 대신, 요구사항 속에 숨겨진 진정한 목적을 파악하고, 때로는 구현 없이도 그 목적을 달성할 수 있는 창의적인 방법을 제안합니다. 이는 단순한 '구현'을 넘어선 '문제 해결'에 초점을 맞추는 것입니다. 효율성과 가치의 균형항상 효율성을 고민합니다. 예를 들어, "이 기능은 이렇게 하면 개발 시간을 절반으로 줄일 수 있을 것 같습니다. 먼저 이 방식으로 시도해보고, 나중에 더 발전시켜 보는 건 어떨까요?"와 같은 제안을 통해 극적인 효율 개선으로 이어질 수 있습니다. '메이커'로서의 개발자토스에서는 개발자를 단순한 '엔지니어'가 아닌 '메이커'로 부릅니다. 이는 개발자가 서비스에 대한 깊은 이해를 바탕으로 용기 있게 의견을 내고, 이를 통해 자신과 동료의 시간을 절약하며 제품의 성공에 기여할 수 있습니다. 빠른 런칭과 사용자 피드백의 중요성제품을 빨리 런칭하고 실제 사용자의 목소리를 듣는 것이 중요합니다. 내부에서 생각하는 사용자의 의견은 실제와 다를 수 있기 때문입니다. 기능을 짧고 빠르게 만들어 출시하는 것이 성공으로 가는 지름길일 수 있습니다. 그렇지만 위와같은 방식이 모든 조직과 제품에 보편적으로 적용되는 것은 아닙니다. 조직의 특성과 제품의 발전 단계에 따라 '일 잘하는 개발자' 정의와 역할은 달라질 수 있습니다. 기능 중심 조직이고, 이미 완성도 높은 단계의 제품이라면 개발 전략과 우선순위가 달라질 수 있습니다.이 관점은 주로 '사일로' 라는 목적 조직과 제품 초기 단계의 상황에 초점을 맞추고 있습니다. https://www.youtube.com/watch?v=ZCg8kvtgcUg

www.youtube.com

토스가 바라보는 '일 잘하는 개발자': 코드를 넘어선 가치 창출

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠.

개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요.

여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요.

매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

이모카세 1호는 매일 같이 우리 식탁에 오르는 음식으로 100명의 요리사 중 6위를 차지했어요. 일상적인 것으로 심사위원의 마음을 얻은 결과죠. 개발자인 우리도 일상적인 것으로 유저의 마음을 얻을 수 있어요. 화려하고 멋진, 최신의 기술이 아니라 일상적인 기술로도 유저의 마음을 얻을 수 있어요. 여러분이 일상에서 다루는 기술의 가능성은 작지 않아요. 새로운 기술은 필요한 순간에 적절하게 사용하면 그만이에요. 매일 반복되는 일상의 기술만 다룬다고 너무 조급해하지 않아도 괜찮아요. 여러분은 내공을 쌓고 계신 거니까요.

흑백요리사, 이모카세가 대단한 이유

Facebook

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다.

퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.
책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다.

그런데 회사에 들어가서 보니
구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.
이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다.
이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다.

이 의견에 대해서 설득하지 못했습니다.
데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다.
하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다.

그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다.
고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다.
먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다.

조금씩 고객 규모는 늘어났지만
너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 & 꾸준히 정진하는 사람 & 능동적으로 텍스트를 읽고 이해하려는 사람 & 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다.

물론 반대되는 생각도 있었습니다.
퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다.

일하면서 강하게 하게 된 생각은
'스타트업은 시장 크기가 거의 전부다' 라는 것입니다.
퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다.

퍼블리에서는 열심히 일했지만 한계가 있었습니다.
충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다.
사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

과거 퍼블리에서 근무하시던 민우님께서 퍼블리를 애도하며 써주신 글입니다. 결국 사업은 시장의 크기나 시장의 성장 가능성이 있는 곳에서 하는게 성공할 가능성이 높아진다 라는 의미가 담겨있습니다. 퍼블리의 첫 타겟 고객은 고급 컨텐츠, 지적 컨텐츠를 바라는 사람들이었습니다.책 읽기를 좋아하고, 뛰어난 사람들은 어떤 생각을 하는지 궁금해하고, 남들이 모르는 걸 알게 되면 자랑하고 싶어서 근질근질거리는 사람들을 위한 컨텐츠를 표방하며 사람들을 끌어들였습니다. 그런데 회사에 들어가서 보니구매 데이터를 분석하고, 구매자들을 만나서 심층 인터뷰를 하고, 광고를 집행해보면서 내린 결론 은 시장의 뚜렷한 한계가 있는걸로 보였습니다.이 시장은 한계가 있고, 타겟 대상으로 뭔가를 파는 시장은 벤처 스케일의 스타트업이 타겟할 만큼의 규모가 나오지 않는다고 생각했습니다. 이 소수의 고객들 마저 '신선한 시도'에 돈을 내고 있는거지, 지속적으로 구매를 해줄 가능성은 낮다고 생각했습니다. 이 의견에 대해서 설득하지 못했습니다.데이터를 분석하는, 고객을 만나는, 광고를 집행하는 사람도 저 혼자였기에 팀에 설득하기란 쉽지 않았습니다. 또한 고급 컨텐츠, 지적 컨텐츠에 커다란 애정을 가지고 있는 공동창업자를 설득하는 건 거의 불가능에 가까운 일이었습니다. 하지만 설득할 필요 없이 시장은 명확하게 피드백을 주고 있었습니다. 그러고 나서 조금씩 큰 시장을 찾아내려고 했었습니다. 고객이 제품에서 가치를 얻는 데에 걸리는 시간이 너무 길다고 판단했고, 짧은 호흡의 컨텐츠, 바로 써먹을 수 있는 컨텐츠를 제공해야 더 많은 고객이 이용할 것이라고 판단했습니다. 먹고사니즘이 걸려있는, 불안감을 해소하고 싶은 자들은 직업에 대한 불안이 큰 사람들일 거라 판단했고 그 결과로 사회 초년생들을 타겟하기 시작했습니다. 조금씩 고객 규모는 늘어났지만너무 조금씩 늘어났고, 어느 순간에는 한계에 부딪혔다고 생각했습니다. 퍼블리가 타겟하는 고객은 '일을 더 잘하고 싶은 사람 &amp; 꾸준히 정진하는 사람 &amp; 능동적으로 텍스트를 읽고 이해하려는 사람 &amp; 거기에 돈을 쓸 만큼 진심인 사람' 들의 교집합이기에 이 시장은 너무 작고, 아무리 광고비를 쏟아부어도 성장에 한계가 있을 것이라고 결론을 내렸습니다. 물론 반대되는 생각도 있었습니다.퍼블리는 충분히 매력적이고, 시장이 작은게 아닌 잘 못팔고 있는거고 잘 팔면 충분히 클것이다 라는 의견입니다. 일하면서 강하게 하게 된 생각은'스타트업은 시장 크기가 거의 전부다' 라는 것입니다. 퍼블리 이전에는 쏘카에서 일했는데 쏘카존을 늘리는 대로 성장했고 하루에 몇억씩 매출이 나는 게 너무 당연했습니다. 차를 구매할 만큼의 경제력은 없지만 차를 타고 운전하고 싶은 욕망을 가진 젊은이들이 너무 많았고 쏘카는 욕망에 맞게 차를 공급해주기만 하면 됐습니다. 퍼블리에서는 열심히 일했지만 한계가 있었습니다.충분히 뛰어난 역량을 가진 구성원들이였고, 좋은 방식으로 일하려 했습니다. 이 구성원들이 다른 시장을 타겟하는 사업을 했으면 분명히 좋은 성과가 나왔을 거라고 생각합니다. 사업이 성장하고 성공하려면 사람들의 욕망을 건드려야하고, 그게 벤처 스케일의 사업이 되려면 큰 욕망을 건드려야 했었습니다.

www.facebook.com

결국 시장이 제일 중요하다

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 생각합니다:)

그동안 만든 21개의 사이드 프로젝트가 다 실패하고 22번째로 만든 프로젝트가 코로나맵이였습니다.

저는 꾸준한 실패의 힘을 믿습니다 😆

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 생각합니다:) 그동안 만든 21개의 사이드 프로젝트가 다 실패하고 22번째로 만든 프로젝트가 코로나맵이였습니다. 저는 꾸준한 실패의 힘을 믿습니다 😆

사이드 프로젝트는 꾸준히 만들고 많이 실패해 보는 게 중요하다고 

나 혼자 몰래 듣고 싶은 네이버 경력 이직 성공기

네이버 경력사원이 다 대답해 드립니다

📎 네이버코드 채용 관련 콘텐츠 3탄! '네이버 경력사원' 분들의 이직 성공기가 공개되었습니다 : )

오늘 공개된 네이버코드 '네이버 경력사원이 다 대답해 드립니다'편에는 다양한 경험과 역량을 보유한 네이버 경력사원분들의 진솔한 인터뷰가 실렸습니다.
콘텐츠에는 아래와 같은 내용이 담겨있으며, 상세 내용은 하단 링크를 통해 확인하실 수 있습니다 🙂

✔︎ 이직을 고민하게 된 동기와 네이버를 선택한 이유는?
✔︎ 채용공고 속 직무와 내 경험 사이의 간극이 있다면 어떻게 해야 할까?
✔︎ 경력 이직에 성공한 사람들은 어떤 식으로 자기 어필을 했을까?
✔︎ 포트폴리오나 경력 기술서에 나만의 '킥'을 보탠다면?
✔︎ 실제 입사해 보니 네이버는 이런 회사였습니다!

📎 네이버코드 채용 관련 콘텐츠 3탄! '네이버 경력사원' 분들의 이직 성공기가 공개되었습니다 : ) 오늘 공개된 네이버코드 '네이버 경력사원이 다 대답해 드립니다'편에는 다양한 경험과 역량을 보유한 네이버 경력사원분들의 진솔한 인터뷰가 실렸습니다. 콘텐츠에는 아래와 같은 내용이 담겨있으며, 상세 내용은 하단 링크를 통해 확인하실 수 있습니다 🙂 ✔︎ 이직을 고민하게 된 동기와 네이버를 선택한 이유는?✔︎ 채용공고 속 직무와 내 경험 사이의 간극이 있다면 어떻게 해야 할까?✔︎ 경력 이직에 성공한 사람들은 어떤 식으로 자기 어필을 했을까?✔︎ 포트폴리오나 경력 기술서에 나만의 '킥'을 보탠다면?✔︎ 실제 입사해 보니 네이버는 이런 회사였습니다!

code.naver.com

경력사원들이 직접 풀어놓는 '네이버 이직 성공기'

코틀린에서 웹소켓에 액터모델을 연결시켜  분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다.

 * more : https://wiki.webnori.com/x/dYGZBQ

코틀린에서 웹소켓에 액터모델을 연결시켜&nbsp; 분산 상태처리가 가능한 웹소켓 모델로 업그레이드 시도를 해보겠습니다. <ul ><li>more : https://wiki.webnori.com/x/dYGZBQ</li></ul>

코틀린에서 웹소켓을 우아하게 사용하기

UX/UI 디자인 전문가 우디입니다. UX/UI 디자이너들의 이력서, 포트폴리오 작성부터 면접 준비까지, 실무 중심의 입사 전략을 세우는 데 필요한 조언을 제공합니다. 채용 담당자 입장을 이해하고 구체적이고 명확하게 자신을 어필하는 법을 익히세요!

ChatGPT - 우디의 UX/UI : 포트폴리오/면접/디자인/라이팅 코칭

안녕하세요, 우디입니다.

디자인 취업 준비 관련해 자주 나오는 질문들에 대한 답변을 더 효과적으로 제공하고, 실질적인 인사이트를 드리고 싶어 GPTs를 만들었습니다.

📌 GPTs 링크: https://chatgpt.com/g/g-c1iWakBh2-udiyi-ux-ui-poteupolrio-myeonjeob-dijain-kocing

더 나은 포트폴리오와 커리어를 만들어 가는 데 도움이 되었으면 좋겠네요!

📚 GPTs에 포함된 주요 학습 내용

1. 세 권의 저서 원본 PDF
- 사실은 이것도 디자인입니다 (제품을 보는 눈)
- 사용자를 사로잡는 UX/UI 실전 가이드 (UX/UI 기초)
- GEN Z 인문학 (디자인 윤리)

2. 디자인 포트폴리오 코칭 경험&인사이트
- 실제 코칭에서 얻은 내용을 통해 실용적인 조언을 제공합니다.

3. 제가 운영하는 커뮤니티 아카이빙 및 자주 나오는 질문과 샘플 답변

4. 두 번의 웨비나 PDF 포함
- 채용 담당자를 고려한 포트폴리오 만들기
- 가독성을 고려한 포트폴리오 라이팅

📈 GPTs를 통해 얻을 수 있는 도움
- 취업 준비: 포트폴리오 작성 및 라이팅 팁, 면접 팁
- 디자인 기초: UX/UI 디자인의 기본 개념과 원리
- 논리적 사고 구축: 디자인 논리와 문제 해결 접근법
- 디자인 윤리: 다크 패턴과 윤리를 고려한 기능 구별

🔧 초기 단계 안내
- 아직 초기 단계인 만큼 부족한 부분이 있을 수 있습니다. 계속해서 수정과 보완을 진행할 예정이니, 양해 부탁드립니다.

디자인 여정에 작은 도움이라도 되길 바랍니다.

안녕하세요, 우디입니다. 디자인 취업 준비 관련해 자주 나오는 질문들에 대한 답변을 더 효과적으로 제공하고, 실질적인 인사이트를 드리고 싶어 GPTs를 만들었습니다. 📌 GPTs 링크: https://chatgpt.com/g/g-c1iWakBh2-udiyi-ux-ui-poteupolrio-myeonjeob-dijain-kocing 더 나은 포트폴리오와 커리어를 만들어 가는 데 도움이 되었으면 좋겠네요! 📚 GPTs에 포함된 주요 학습 내용 1. 세 권의 저서 원본 PDF- 사실은 이것도 디자인입니다 (제품을 보는 눈)- 사용자를 사로잡는 UX/UI 실전 가이드 (UX/UI 기초)- GEN Z 인문학 (디자인 윤리) 2. 디자인 포트폴리오 코칭 경험&amp;인사이트- 실제 코칭에서 얻은 내용을 통해 실용적인 조언을 제공합니다. 3. 제가 운영하는 커뮤니티 아카이빙 및 자주 나오는 질문과 샘플 답변 4. 두 번의 웨비나 PDF 포함- 채용 담당자를 고려한 포트폴리오 만들기- 가독성을 고려한 포트폴리오 라이팅 📈 GPTs를 통해 얻을 수 있는 도움- 취업 준비: 포트폴리오 작성 및 라이팅 팁, 면접 팁- 디자인 기초: UX/UI 디자인의 기본 개념과 원리- 논리적 사고 구축: 디자인 논리와 문제 해결 접근법- 디자인 윤리: 다크 패턴과 윤리를 고려한 기능 구별 🔧 초기 단계 안내- 아직 초기 단계인 만큼 부족한 부분이 있을 수 있습니다. 계속해서 수정과 보완을 진행할 예정이니, 양해 부탁드립니다. 디자인 여정에 작은 도움이라도 되길 바랍니다.

ChatGPT

🛠️ 우디의 디자인 GPTs 공유

개발자의 인문학 공부: 인문학 서적 100권 읽기

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추천 도서 목록

SNS 댓글로 받은 추천 도서 목록입니다. 현재 50권이 살짝 넘네요. 누구나 수정 할 수 있게 열어두었으니, 혹시 더 추천해주시고 싶은 책이 있다면 추가해주시면 감사합니다. ☺️

그보다.. 공돌이로써 제목만 봐도 현기증이.. 문돌이 분들이 물리, 수학, 인공지능 기술 도서명 보면 이런 느낌이려나 싶네요..😇🤭

https://docs.google.com/spreadsheets/d/1w4t4HMIXdbI233GXHcOob_MKCnp5hHVyoxax5Nepzt0/edit?usp=sharing

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추천 도서 목록 SNS 댓글로 받은 추천 도서 목록입니다. 현재 50권이 살짝 넘네요. 누구나 수정 할 수 있게 열어두었으니, 혹시 더 추천해주시고 싶은 책이 있다면 추가해주시면 감사합니다. ☺️ 그보다.. 공돌이로써 제목만 봐도 현기증이.. 문돌이 분들이 물리, 수학, 인공지능 기술 도서명 보면 이런 느낌이려나 싶네요..😇🤭 https://docs.google.com/spreadsheets/d/1w4t4HMIXdbI233GXHcOob_MKCnp5hHVyoxax5Nepzt0/edit?usp=sharing

Google Docs

“개발자의 인문학 공부: 인문학 서적 100권 읽기 프로젝트” 추

프로젝트 관리할 때 위험한 동물 4종 | GeekNews

PM/PO 가 프로젝트를 관리할 때 조심해야 하는 동료들의 모습을 HIPPO, WOLF, RIHNO, ZEBRA 라는 4가지 동물로 축약된 약어로 소개합니다.

그리고 그에 따른 해결책을 또 제시합니다. 독단적인 CEO, 항상 급해서 뛰어다니는 사람들, 팀에 기여하지 않는 사람들, 데이터 없이 직관에 의거해 주장만 하는 사람. 4가지에 대해 말합니다.

GeekNews

프로덕트 매니저/서비스 기획

임성은

티온네트워크 AOS 개발자

경창현

글로벌 웹툰 업계에서 일한지 5년차되는 UX/UI 디자이너입니다. 한국만화영상진흥원과 웹툰언론전문사 웹툰가이드에서 웹툰 서비스에 대한 컬럼을 기고했습니다. '모바일 웹툰의 정보추구행동 모형화'에 대한 논문을 학술지에 게재했습니다.

글로벌 웹툰 서비스 태피툰 UX/UI 디자이너

김민오

글로벌 웹툰 업계에서 일한 지 5년 차 되는 UX/UI 디자이너입니다. 한국만화영상진흥원과 웹툰 전문언론사에서 웹툰 서비스 개선에 대한 컬럼을 기고했습니다. '모바일 웹툰의 정보추구행동 모형화'에 대한 논문을 학술지에 게재했습니다.
#프로덕트디자인 #BX디자인

서비스 기획

글로벌 서비스 기획

지원준

유용하거나, 재미있는 것들에 관심이 많습니다. 거시적인 테크 트렌드와 먹고 마시는 라이프스타일까지 흥미를 두고 있습니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필