My thoughts on license choices for balancing business interests and Open Source software and why the FSL is a better choice than the AGPL.

FSL: A Better Business/Open Source Balance Than AGPL

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다.

Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다.

이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다.

이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다.

AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다.

라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다.

https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Flask를 만들고 오랫동안 오픈소스 활동을 한 Armin Ronacher가 FSL이 AGPL보다 더 좋은 선택이라고 설명하는 글입니다. Elasticsearch가 몇년전 클라우드 사업의 충돌 문제로 오픈소스 라이센스를 빼고 오픈소스가 아니게 되었다가 최근 이제 문제가 해결되었다면서 다시 AGPL을 추가하면서 오픈소스 프로젝트가 되었습니다. 이 예시를 언급하면서 특정회사가 오픈소스 프로젝트 대부분을 책임지는 상황을 단일 벤더 모델이라고 얘기하면서 이러한 경우 FSL을 사용하면 이 공급업체가 상당한 권한을 가질수 있고 FSL은 2년이 지나면 오픈소스 라이센스로 자동변환이 되기 때문에 시간이 지남에 따라 권한이 약화된다고 얘기합니다. 그래서 Sentry가 지금 사업하는데는 문제가 없으면서 혹 Sentry 사업이 잘 안되어서 회사가 망하더라도 오픈소스 라이센스로 변경된 코드를 가지고 다른 누군가가 이어서 프로젝트를 할 수 있다고 설명합니다. 이렇게 어느 회사든 없어질 수 있는데 이런 경우 FSL이 훨씬 효과적이고 과거에도 회사가 괜찮은 프로젝트의 라이센스를 제대로 풀지 않고 회사가 없어지면서 문제가 된 경우도 많다고 얘기합니다. AGPL을 쓰더라도 CLA(Contributor License Agreement)가 있냐 없냐에 따라 달라지는에 CLA가 있는 AGPL의 경우는 2년이 지난 뒤에는 FSL보다 저작권자가 더 강력한 권한을 가지게 된다고 합니다. 라이센스 문제는 꽤 복잡하긴 한데 FSL에 대해서 이 글에서 저는 설득력 있게 느껴졌습니다. https://lucumr.pocoo.org/2024/9/23/fsl-agpl-open-source-businesses/

Armin Ronacher's Thoughts and Writings

The 2024 Tidelift state of the open source maintainer report

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다.

1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.
2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.
3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.
4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.
5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.
6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.
7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.
8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.
9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.
10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.
11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.
12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다.

전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다.

https://explore.tidelift.com/2024-survey

오픈소스 메인테이너를 지우너하는 플랫폼인 Tidelift에서 오픈소스 메인테이너 400여 명에게 설문조사를 진행한 결과입니다. 1. 메인테이너 중 60%는 여전히 작업 보수를 받지 못합니다.2. 메인테이너가 더 많은 보수를 받을수록 프로젝트에는 더 많은 개선이 이루어집니다.3. 32%는 다른 조직이나 개인으로부터 보수를 받고 고용주로부터 보수를 받는 메인테이너는 24%로 소폭 감소했습니다.4. 메인테이너는 몇년전보다 보안에 3배 더 많은 시간을 쓰고 있습니다.5. 메인테이너가 보수를 받는 경우 OpenSSF 스코어카드에 부합할 가능성이 훨씬 더 높습니다.6. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 중요한 보안 관행을 구현할 가능성이 더 높습니다.7. 보수를 받는 메인테이너는 보수를 받지 않는 메인테이너에 비해 더 많은 유지 보수 작업과 문서화 작업을 합니다.8. 거의 절반의 메인테이너가 자신의 작업이 과소 평가되고 무의미하다고 느낍니다.9. xy utils 해킹 사건 이후 메인테이너의 2/3는 컨트리뷰터를 덜 신뢰합니다.10. AI 기반 코딩 도구는 번창하고 있지만 메인테이너들은 코드 품질과 스팸 PR 등으로 이한 우려를 하고 있습니다.11. 더 젊은 오픈소스 메인테이너는 AI 기반 코딩 도구를 사용할 가능성이 훨씬 더 큽니다.12. 오픈소스 메인테이너 커뮤니티가 점점 나이가 들어가고 있습니다. 전혀 몰랐던 내용이 있는건 아니지만 좀더 확실하게 메인테이너에게 작업 보수를 주는 것이 중요하다는 것을 알게 되었고 메인테이너들이 더 자신들의 작업에 집중하고 더 많은 오픈소스 메인테이너가 참여할 수 있는 환경이 조성되어야 한다는 생각이 더 많이 들었습니다. https://explore.tidelift.com/2024-survey

Tidelift

GitHub 에서 자주보던 브랜드인데 구체적으로 뭘하는지믄 몰랐어요. 소개해주셔서 감사합니다.

요즘 인프라 쪽에서 주목을 많이 받는 분야 중 하나가 

내가 생각하는 플랫폼 엔지니어링 :: Outsider's Dev Story

https://blog.outsider.ne.kr/1736

운좋게 3여년정도 플랫폼 엔지니어링 비스무리한 일을 하고 있게 되어서 최근 인프라쪽에서 관심 받고 있는 플랫폼 엔지니어링에 대한 고민을 좀 빠르게 할 수 있었습니다. 제가 있는 환경내에서의 경험뿐이지만 그동안 고민하면서 시행착오도 겪었을 일을 바탕으로 제가 생각하는 플랫폼 엔지니어링은 어떠해야 하는지를 정리해 봤습니다.

https://blog.outsider.ne.kr/1736 운좋게 3여년정도 플랫폼 엔지니어링 비스무리한 일을 하고 있게 되어서 최근 인프라쪽에서 관심 받고 있는 플랫폼 엔지니어링에 대한 고민을 좀 빠르게 할 수 있었습니다. 제가 있는 환경내에서의 경험뿐이지만 그동안 고민하면서 시행착오도 겪었을 일을 바탕으로 제가 생각하는 플랫폼 엔지니어링은 어떠해야 하는지를 정리해 봤습니다.

Outsider's Dev Story

내가 생각하는 플랫폼 엔지니어링

“네가 원하는 걸 만들지 말고 다른 사람들이 원하는 걸 만들어.”

스타트업 세계에서 자주 듣는 말입니다.
내가 만들고 싶은 걸 만들다가 써주는 사람이 없어서 망했다는 이야기.
바보 같고 우스워 보이지 않나요?

하지만… 남들 모두가 원하는 거 만들면 정말 잘 될 수 있을까?
그렇게 쉽지는 않을 겁니다.
거기엔 이미 경쟁자들이 우글우글 할텐데.
정말 그 경쟁자들을 이길 수 있는가? (마음만 앞서는 건 아니고?)

남들이 뭘 좋아하는지 보다 제가 좋아하는 것 중심으로 생각하고 싶습니다.
어차피 이렇게 하나 저렇게 하나 돈 벌기는 어려운 일.
그렇다면 내가 만들고 싶은 걸 만들어야 후회 없지 않을까?
내가 원했던 서비스라면 누군가는 분명 나 같은 사람이 있을 거라는 믿음으로.
커피한잔이 바로 제가 (결혼 전) 꼭 있었으면 했던 서비스였습니다.

물론 나만 원하고 아무도 원하지 않는 걸 만들어서는 안 됩니다.
서비스를 출시해보고 망해보고 하면서 이런 감각이 길러집니다.

자기가 만들고 싶은 걸 만들 때는 장점이 있습니다.
오랫동안 기복 없이 할 수 있다는 것.
쉽게 포기하지 않는다는 것.
내 앱의 최고 사용자가 바로 나라는 것.

서비스 한 번 시작하면 몇 년은 훌쩍 지나갑니다.
내 인생도 소중하다고.
기왕이면 제가 관심 있고 좋아하는 일에서 시작하고 싶습니다.

https://jeho.page/essay/2024/10/14/build-what-i-want-to-build/html

“네가 원하는 걸 만들지 말고 다른 사람들이 원하는 걸 만들어.” 스타트업 세계에서 자주 듣는 말입니다. 내가 만들고 싶은 걸 만들다가 써주는 사람이 없어서 망했다는 이야기. 바보 같고 우스워 보이지 않나요? 하지만… 남들 모두가 원하는 거 만들면 정말 잘 될 수 있을까? 그렇게 쉽지는 않을 겁니다. 거기엔 이미 경쟁자들이 우글우글 할텐데. 정말 그 경쟁자들을 이길 수 있는가? (마음만 앞서는 건 아니고?) 남들이 뭘 좋아하는지 보다 제가 좋아하는 것 중심으로 생각하고 싶습니다. 어차피 이렇게 하나 저렇게 하나 돈 벌기는 어려운 일. 그렇다면 내가 만들고 싶은 걸 만들어야 후회 없지 않을까? 내가 원했던 서비스라면 누군가는 분명 나 같은 사람이 있을 거라는 믿음으로. 커피한잔이 바로 제가 (결혼 전) 꼭 있었으면 했던 서비스였습니다. 물론 나만 원하고 아무도 원하지 않는 걸 만들어서는 안 됩니다. 서비스를 출시해보고 망해보고 하면서 이런 감각이 길러집니다. 자기가 만들고 싶은 걸 만들 때는 장점이 있습니다. 오랫동안 기복 없이 할 수 있다는 것. 쉽게 포기하지 않는다는 것. 내 앱의 최고 사용자가 바로 나라는 것. 서비스 한 번 시작하면 몇 년은 훌쩍 지나갑니다. 내 인생도 소중하다고. 기왕이면 제가 관심 있고 좋아하는 일에서 시작하고 싶습니다. https://jeho.page/essay/2024/10/14/build-what-i-want-to-build/html

K리그 프로그래머

아니, 난 그냥 내가 만들고 싶은 걸 만들래

Facebook

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

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

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

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

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

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

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

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

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

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

www.facebook.com

결국 시장이 제일 중요하다

제가 지금까지 만든 학습 패키지는 총 8개입니다.

- 데이터 이력서 템플릿
- 생산성 도구 리스트
- 위클리 뉴스레터
- 코호트 데이터 분석 노트
- AARRR 데이터 분석 노트
- 데이터 커리어 스타터팩 BASIC
- 취업 준비 트래커
- ARAR 타임 트래커

학습 패키지를 하나하나씩 만들면서, 실제로 배우는 사람들에게 어떤 도움이 되는지, 그리고 학습자의 미래에 진심으로 도움이 되는지를 매번 다시 한번 생각해보곤 합니다.

물론 제 기준으로 만들기 때문에, 모든 학습자들에게 도움이 된다고 100% 확신할 수 없습니다.

하지만, DATA/AI를 조금 더 재미있게, 조금 더 가치있게 배울 수 있는 교육을 만들고 싶습니다.
그리고 그로 인해 더 많은 사람들이 더 나은 세상을 만들어가는 학습을 꿈꾸고 있습니다.

DATA/AI를 재미있고 가치있게 배울 수 있도록 앞으로도 더 많은 학습들을 만들어가겠습니다.

감사합니다.

#데이터리차드 #학습패키지 #DATA #AI

제가 지금까지 만든 학습 패키지는 총 8개입니다. - 데이터 이력서 템플릿 - 생산성 도구 리스트 - 위클리 뉴스레터 - 코호트 데이터 분석 노트 - AARRR 데이터 분석 노트 - 데이터 커리어 스타터팩 BASIC - 취업 준비 트래커 - ARAR 타임 트래커 학습 패키지를 하나하나씩 만들면서, 실제로 배우는 사람들에게 어떤 도움이 되는지, 그리고 학습자의 미래에 진심으로 도움이 되는지를 매번 다시 한번 생각해보곤 합니다. 물론 제 기준으로 만들기 때문에, 모든 학습자들에게 도움이 된다고 100% 확신할 수 없습니다. 하지만, DATA/AI를 조금 더 재미있게, 조금 더 가치있게 배울 수 있는 교육을 만들고 싶습니다.그리고 그로 인해 더 많은 사람들이 더 나은 세상을 만들어가는 학습을 꿈꾸고 있습니다. DATA/AI를 재미있고 가치있게 배울 수 있도록 앞으로도 더 많은 학습들을 만들어가겠습니다. 감사합니다. #데이터리차드 #학습패키지 #DATA #AI

앞으로 만들고 싶은 학습 프로덕트 리스트

1. 불확실성을 견디는 사람
불확실한 상황에도 묵묵히 1인분 이상을 해내는 사람

2. 불확실성을 즐기는 사람
불확실한 상황에서 만난 문제를 해결하길 즐기는 사람

3. 불확실성을 기회로 여기는 사람
불확실한 상황이 오히려 성장과 인정의 기회라고 믿는 사람

1. 불확실성을 견디는 사람불확실한 상황에도 묵묵히 1인분 이상을 해내는 사람 2. 불확실성을 즐기는 사람불확실한 상황에서 만난 문제를 해결하길 즐기는 사람 3. 불확실성을 기회로 여기는 사람불확실한 상황이 오히려 성장과 인정의 기회라고 믿는 사람

스타트업에서 모셔가는 개발자

그러니까 불확실한 사람을 모셔간다 이거죠!?

사이드 프로젝트 30개 만들어 본 개발자가 느낀
팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지

1️⃣ 팀원은 최소한의 인원으로

- 많은 인원일 수록 더 많은 일들을 할 수 있을 것 같지만, 실제로는 그렇게 되지 못하는 경우가 많습니다

- 의사 결정이 느려지거나 시간을 맞추기 어렵거나 등등 빠르게 서비스를 출시해야 하는 상황일 수록 득보다는 실이 많은 경우가 생기게 됩니다.

- 그리고 서비스 개발 속도는 팀원 수에 꼭 비례하지 않습니다

- 팀원은 최소한으로 (ex. 2~3명)

- 팀 내에 그 일을 할 수 있는 사람이 없을 때 팀원을 1명씩 영입해야 합니다

2️⃣ 모두가 똑같은 속도로 가는 것은 어렵다

- 팀원 모두가 다 같은 속도로 서비스 개발에 참여하여 빠르게 프로덕트를 출시하면 가장 이상적일 것 입니다

- 하지만 현실적으로 팀원 모두가 같은 시간과 노력을 쏟는 것은 불가능 합니다.

- 본업 이외의 시간에 '사이드'로 프로젝트를 진행하기 때문에 임하는 시간이 상대적일 수 밖에 없다는 것을 인지 해야합니다

- 전체적으로는 느슨하게, 하지만 풀어지게 하지 않도록 해야합니다

- 주 1회 이상 정기 회의를 가져 팀 전체의 진행 상황을 공유하고, 타임 라인을 꼭 설정하여 마감 기한을 설정하시기 바랍니다

- 중요한 건 팀내의 동기부여를 얼마나 꾸준하게 지속적으로 가져갈 수 있는 지 입니다

3️⃣ 솔직한 소통이 중요하다

- 혼자하는 것과 팀원이 함께하는 것의 가장 큰 차이점은 커뮤니케이션이 많은 부분을 차지한다는 것 입니다

- 사람 대 사람의 관계가 있기 때문에 의견을 나누는데 있어 솔직하지 못하는 경우가 생깁니다

- '다 좋다고 하는데.. 내가 괜히 반대 의견을 내는 건 아닐까?', '이렇게 말하면 상대방이 무시한다고 생각하지는 않을까..?', '내 의견은 말하기 부끄러운데..' 등등

- 하지만 솔직하게 의견과 생각을 나누지 않는다면 아이디어 선정 단계에서 부터 막히는 모습을 볼 수 있게 됩니다

- 뿐만 아니라 생각했던 방향과 전혀 다른 방향으로 흘러가는 경우도 생기게 됩니다

- 팀원 들이 적극적으로 의견을 낼 수 있어야 합니다. 그러기 위해선 서로 경청할 수 있는 분위기와 문화, 규칙을 만들어 주어야 합니다

사이드 프로젝트 30개 만들어 본 개발자가 느낀팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지 1️⃣ 팀원은 최소한의 인원으로 - 많은 인원일 수록 더 많은 일들을 할 수 있을 것 같지만, 실제로는 그렇게 되지 못하는 경우가 많습니다 - 의사 결정이 느려지거나 시간을 맞추기 어렵거나 등등 빠르게 서비스를 출시해야 하는 상황일 수록 득보다는 실이 많은 경우가 생기게 됩니다. - 그리고 서비스 개발 속도는 팀원 수에 꼭 비례하지 않습니다 - 팀원은 최소한으로 (ex. 2~3명) - 팀 내에 그 일을 할 수 있는 사람이 없을 때 팀원을 1명씩 영입해야 합니다 2️⃣ 모두가 똑같은 속도로 가는 것은 어렵다 - 팀원 모두가 다 같은 속도로 서비스 개발에 참여하여 빠르게 프로덕트를 출시하면 가장 이상적일 것 입니다 - 하지만 현실적으로 팀원 모두가 같은 시간과 노력을 쏟는 것은 불가능 합니다. - 본업 이외의 시간에 '사이드'로 프로젝트를 진행하기 때문에 임하는 시간이 상대적일 수 밖에 없다는 것을 인지 해야합니다 - 전체적으로는 느슨하게, 하지만 풀어지게 하지 않도록 해야합니다 - 주 1회 이상 정기 회의를 가져 팀 전체의 진행 상황을 공유하고, 타임 라인을 꼭 설정하여 마감 기한을 설정하시기 바랍니다 - 중요한 건 팀내의 동기부여를 얼마나 꾸준하게 지속적으로 가져갈 수 있는 지 입니다 3️⃣ 솔직한 소통이 중요하다 - 혼자하는 것과 팀원이 함께하는 것의 가장 큰 차이점은 커뮤니케이션이 많은 부분을 차지한다는 것 입니다 - 사람 대 사람의 관계가 있기 때문에 의견을 나누는데 있어 솔직하지 못하는 경우가 생깁니다 - '다 좋다고 하는데.. 내가 괜히 반대 의견을 내는 건 아닐까?', '이렇게 말하면 상대방이 무시한다고 생각하지는 않을까..?', '내 의견은 말하기 부끄러운데..' 등등 - 하지만 솔직하게 의견과 생각을 나누지 않는다면 아이디어 선정 단계에서 부터 막히는 모습을 볼 수 있게 됩니다 - 뿐만 아니라 생각했던 방향과 전혀 다른 방향으로 흘러가는 경우도 생기게 됩니다 - 팀원 들이 적극적으로 의견을 낼 수 있어야 합니다. 그러기 위해선 서로 경청할 수 있는 분위기와 문화, 규칙을 만들어 주어야 합니다

팀으로 사이드 프로젝트 진행할 때 알면 좋은 것 3가지

초거대 언어 모델(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 엔지니어

Tesla has revealed its fully autonomous taxi, which is said to feature inductive charging and is planned to start production in 2026.

Tesla Robotaxi Is a Driverless Car That Will Cost Under $30,000

아직도 갈길이 멀게 보이는 테슬라의 자율주행 로보택시와 옵티머스 로봇이 어째튼 공개되었습니다. 관련 행사시 오픈된 내용들을 리뷰해봅니다~

 1. 행사 개요
 * 일시: 10월10일(미국시간). 원래 일정은 8월이었으나 2달 연기
 * 장소: 미국 캘리포니아주 워너브라더스 디스커버리 영화 스튜디오
 * 주요 아젠다: 2인승 로보택시 ‘사이버캡’과 20인승 ‘로보밴’ 등 선보임

 2. 세부 내용
1) 로보택시 '사이버캡'
 * 자율주행 택시
 * 가격: ~ 3만 달러 미만
 * 생산: 2026년에 시작 예정(단, 일론타임(?)으로 지연 생산 예상)
 * 특징: 쿠페형 모델로 2인승 / 2도어 해치백/ No 운전대, 페달, 스티어링 휠 / 앞뒤 라이트 바가 사이버트럭과 같은 스타일링/ Tesla Model 3 및 Model Y와 유사한 대시보드 / 유도성(무선) 충전 기능 탑재로 충전 포트 없음 / '테슬라 네트워크'(테슬라 소유자가 자신의 차량을 자율주행 차량에 추가할 수 있는 차량 호출 서비스) 예상 / 비디오 카메라와 테슬라가 "AI 5"라고 부르는 최신 하드웨어 버전 사용
   
   
2) 로보밴
 * 20인승 대형 자율주행 운송수단(로보버스?)
 * 특징: 최대 20인명 승차 가능 / 물건 운반 / 지붕 양쪽에 유리창과 슬라이딩 사이드 도어

3) 로보반과 옵티머스 로봇
 * 2세대 옵티머스 로봇: 휴머노이드 로봇
 * 가격: 2만 8,000달러 ~ 3만 달러
 * 특징: 사람과 상호작용하는 로봇 / 댄싱 로봇 / 더 가볍고 빨라지고 개선된 2세대 옵티머스 로봇 / 가사도우미 또는 교육 지원 역할 수행 기대 / 개인용 또는 상업용으로 개조 가능
 * 2021년 처음 AI데이 행사에서 휴머노이드 로봇 작업 계획을 공개 > 2022년 시제품 > 2024년 댄싱 및 바텐더 서비스등 인터랙티브 기능 지원 로봇 선보임

 3. 이슈
 * 생산시기
   * 일론머스크는 2027년 이전 생산 시작이라고 했지만, 그동안 일론타임(?)을 보아온 많은 사람들은 과연 2027년 생산가능할까하는 의문?
 * 자율주행 택시에 대한 텍사스와 캘리포니아 주정부 규제 당국의 승인 여부
   * 완전 자율 주행(감독형) 소프트웨어를 비감독형 단계로 승인
   * 샌프란시스코에서 제너럴 모터스의 자회사인 ‘크루즈’가 운행하던 무인 자동차가
 * 경쟁사 대비 차별성?
   * 웨이모: 5세대 센서 시스템은 360도 라이다, 3개의 레이더, 3개의 카메라 등 최소 13개의 센서로 구성/ 크라이슬러 퍼시피카 미니밴을 주력으로자율주행 서비스를 운영해오다가 현재는 단종된 재규어 I-Pace를 사용 / 8월 지커 CM1e 기반 6세대 자율주행 택시 공개
   * 우버: 지난 8월 무인 자동차 개발사 크루즈와 제휴한다는 계획 발표 / 10월 초 현대의 ‘아이오닉 5’를 가지고 자사의 기술로 도로 테스트를 거친 후 로보택시 차량단에 활용 계획
   * 바이두: 현재 여러 도시에서 로보택시를 운행하고 있는 로보택시 사업부 ‘아폴로 고’를 중국 이외의 지역으로도 확장 예상
 * 인간이 원격 조종한 로봇?
   * 테슬라의 공식 답변은 아직 없으나, 로봇의 동작이 원격 작동(인간의 개입)에 의존한 것으로 보인다는 의견도 있음
 * 카메라 기반 접근 방식으로는 레벨 2 이상의 자율주행을 구현하는 데 한계?
   참고로, 현재 테슬라의 오토파일럿과 FSD는 여전히 레벨 2 단계로 분류
 * 2도어 택시?

 * source
   * https://www.theverge.com/2024/10/10/24265122/tesla-robotaxi-event-how-to-watch-what-to-expect-optimus
   * https://www.caranddriver.com/news/a62567491/tesla-robotaxi-reveal/
   * https://www.bbc.com/korean/articles/cgj4x7xy43jo
   * https://www.tesla.com/ko_kr/we-robot
   * https://www.youtube.com/watch?v=6v6dbxPlsXs&ab_channel=Tesla

아직도 갈길이 멀게 보이는 테슬라의 자율주행 로보택시와 옵티머스 로봇이 어째튼 공개되었습니다. 관련 행사시 오픈된 내용들을 리뷰해봅니다~ <ol ><li>행사 개요</li></ol><ul ><li>일시: 10월10일(미국시간). 원래 일정은 8월이었으나 2달 연기</li><li>장소: 미국 캘리포니아주 워너브라더스 디스커버리 영화 스튜디오</li><li>주요 아젠다: 2인승 로보택시 ‘사이버캡’과 20인승 ‘로보밴’ 등 선보임</li></ul> <ol start="2"><li>세부 내용</li></ol>1) 로보택시 '사이버캡'<ul ><li>자율주행 택시</li><li>가격: ~ 3만 달러 미만</li><li>생산: 2026년에 시작 예정(단, 일론타임(?)으로 지연 생산 예상)</li><li>특징: 쿠페형 모델로 2인승 / 2도어 해치백/ No 운전대, 페달, 스티어링 휠 / 앞뒤 라이트 바가 사이버트럭과 같은 스타일링/ Tesla Model 3 및 Model Y와 유사한 대시보드 / 유도성(무선) 충전 기능 탑재로 충전 포트 없음 / '테슬라 네트워크'(테슬라 소유자가 자신의 차량을 자율주행 차량에 추가할 수 있는 차량 호출 서비스) 예상 / 비디오 카메라와 테슬라가 "AI 5"라고 부르는 최신 하드웨어 버전 사용 </li></ul>2) 로보밴<ul ><li>20인승 대형 자율주행 운송수단(로보버스?)</li><li>특징: 최대 20인명 승차 가능 / 물건 운반 / 지붕 양쪽에 유리창과 슬라이딩 사이드 도어</li></ul> 3) 로보반과 옵티머스 로봇<ul ><li>2세대 옵티머스 로봇: 휴머노이드 로봇</li><li>가격: 2만 8,000달러 ~ 3만 달러</li><li>특징: 사람과 상호작용하는 로봇 / 댄싱 로봇 / 더 가볍고 빨라지고 개선된 2세대 옵티머스 로봇 / 가사도우미 또는 교육 지원 역할 수행 기대 / 개인용 또는 상업용으로 개조 가능</li><li>2021년 처음 AI데이 행사에서 휴머노이드 로봇 작업 계획을 공개 &gt; 2022년 시제품 &gt; 2024년 댄싱 및 바텐더 서비스등 인터랙티브 기능 지원 로봇 선보임</li></ul> <ol start="3"><li>이슈</li></ol><ul ><li>생산시기<ul ><li>일론머스크는 2027년 이전 생산 시작이라고 했지만, 그동안 일론타임(?)을 보아온 많은 사람들은 과연 2027년 생산가능할까하는 의문?</li></ul></li><li>자율주행 택시에 대한 텍사스와 캘리포니아 주정부 규제 당국의 승인 여부<ul ><li>완전 자율 주행(감독형) 소프트웨어를 비감독형 단계로 승인</li><li>샌프란시스코에서 제너럴 모터스의 자회사인 ‘크루즈’가 운행하던 무인 자동차가</li></ul></li><li>경쟁사 대비 차별성?<ul ><li>웨이모: 5세대 센서 시스템은 360도 라이다, 3개의 레이더, 3개의 카메라 등 최소 13개의 센서로 구성/ 크라이슬러 퍼시피카 미니밴을 주력으로자율주행 서비스를 운영해오다가 현재는 단종된 재규어 I-Pace를 사용 / 8월 지커 CM1e 기반 6세대 자율주행 택시 공개</li><li>우버: 지난 8월 무인 자동차 개발사 크루즈와 제휴한다는 계획 발표 / 10월 초 현대의 ‘아이오닉 5’를 가지고 자사의 기술로 도로 테스트를 거친 후 로보택시 차량단에 활용 계획</li><li>바이두: 현재 여러 도시에서 로보택시를 운행하고 있는 로보택시 사업부 ‘아폴로 고’를 중국 이외의 지역으로도 확장 예상</li></ul></li><li>인간이 원격 조종한 로봇?<ul ><li>테슬라의 공식 답변은 아직 없으나, 로봇의 동작이 원격 작동(인간의 개입)에 의존한 것으로 보인다는 의견도 있음</li></ul></li><li>카메라 기반 접근 방식으로는 레벨 2 이상의 자율주행을 구현하는 데 한계?참고로, 현재 테슬라의 오토파일럿과 FSD는 여전히 레벨 2 단계로 분류</li><li>2도어 택시?</li></ul> <ul ><li>source<ul ><li>https://www.theverge.com/2024/10/10/24265122/tesla-robotaxi-event-how-to-watch-what-to-expect-optimus</li><li>https://www.caranddriver.com/news/a62567491/tesla-robotaxi-reveal/</li><li>https://www.bbc.com/korean/articles/cgj4x7xy43jo</li><li>https://www.tesla.com/ko_kr/we-robot</li><li>https://www.youtube.com/watch?v=6v6dbxPlsXs&amp;ab_channel=Tesla</li></ul></li></ul>

Car and Driver

테슬라의 We, Robot 행사 리뷰

🙅‍♂️ 내가 하지 않는 생각
- 이걸로 무조건 성공해서 돈 벌어야지
- 많은 기능 넣으면 사용자들이 좋아하겠지?
- 이왕 만드는 거 완벽하게 만들어야지

🙆‍♀️ 내가 하는 생각
- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자
- 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자
- 필요한 기능 1개만 추려서 빠르게 만들어 보자
- 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

🙅‍♂️ 내가 하지 않는 생각- 이걸로 무조건 성공해서 돈 벌어야지 - 많은 기능 넣으면 사용자들이 좋아하겠지? - 이왕 만드는 거 완벽하게 만들어야지 🙆‍♀️ 내가 하는 생각- 사람들이 불편해 하는 점이 있는 것 같네. 한번 만들어 보자 - 실패해도 배운 점이 있도록 평소 사용하고 싶었던 기술이나 주제를 적용해보자 - 필요한 기능 1개만 추려서 빠르게 만들어 보자 - 완벽하기보단 우선 만들어보자. 반응 없으면 버리고, 반응이 있다면 그 때 개선하자

사이드 프로젝트 만들 때

Online JSON view, format, minify, validate and compare. It also provides graph view to preview JSON data, semantic comparing two JSON diffs, convert JSON to CSV or CSV to JSON and support jq online.

JSON For You | The best online JSON tool

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요!
구조 비교 & 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요!

https://json4u.com/editor

json 을 table로 변환하는 툴들은 많이 봤었는데, 이렇게 graph로 변환까지 해주는 툴은 처음보는 것 같아요! 구조 비교 &amp; 텍스트 비교로 2개의 JSON간 차이점 빠른 확인도 가능해서 더 좋아요! https://json4u.com/editor

JSON For You

파워풀한 json 시각화툴

알고리즘 입문자를 위한 달레의 친절한 안내서

알고리즘 | 알고달레

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java)
📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗)
📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유

개발자 달레님이 만드신 사이트인데요,
무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요!

https://www.algodale.com/algorithms/

📕 코딩 테스트에 단골로 등장하는 문제(LeetCode, 프로그래머스)에 대한 다양한 접근 방법과 답안 코드 (Python, JavaScript, Java) 📗 코딩 문제를 풀 때 반드시 필요한 알고리즘과 자료구조 설명 (최대한 입문자의 눈높이에서 친절하게 쉽게 🤗) 📘 코딩 시험/면접 준비 관련 가이드 + 17년 차 개발자 달레의 코딩 테스트 노하우 공유 개발자 달레님이 만드신 사이트인데요, 무료로 열려있어 공부하기도 좋고 깔끔해서 눈으로 보기도 좋아요! https://www.algodale.com/algorithms/

알고달레

코딩테스트 공부를 위한 추천 사이트

“아니, 도대체 왜 조회 쿼리 메서드에서 데드락이 생기는거야?”  

왜 조회 쿼리에서 데드락이 발생했을까?

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.
https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

"아니, 도대체 왜?"'findBy...' 에서 데드락이 발생하는 걸 보고 궁금해서 이모저모 실험해보았어요.https://hyeon9mak.github.io/why-occurs-deadlock-from-select-query/

현구막 기술 블로그

"아니, 도대체 왜?"
'findBy...' 에서 데드락이 발생하

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다.

📕 YES24: https://www.yes24.com/Product/Goods/134021042
📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265
📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550

사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다.

이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다.

"헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

마침내 제가 쓴 자바스크립트 책, "헬로 Bun"이 출간되어 온라인 서점에서 예약 판매가 시작되었습니다. Bun은 아직 국내에는 많이 알려지지 않았지만, 해외에서는 Node.js의 뒤를 잇는 차세대 자바스크립트 런타임으로 주목받고 있습니다. JavaScript Rising Stars 🌟 2023 집계에서 당당히 2위를 차지한 오픈 소스 프로젝트이며, State of JS 2023 설문 조사에서 개발자 응답에 가장 많이 오르고 내린 정말 HOT🔥한 기술입니다. 📕 YES24: https://www.yes24.com/Product/Goods/134021042 📗 교보문고: https://product.kyobobook.co.kr/detail/S000214450265 📘 알라딘: https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=348745550 사실 처음 Bun을 접했을 때는 제가 국내에 이 기술을 소개하는 책까지 쓰게 될 줄은 몰랐어요. 원래는 여타 기술처럼 제 블로그에서 한 번 다뤄보려고 했습니다. 그런데 이 귀여운 찐빵(?)이 겉보기와 다르게 기능과 성능이 후덜덜하더군요. 단순히 타입스크립트와 JSX를 바로 실행할 수 있는 자바스크립트 런타임인 줄 알았는데, 알고보니 모듈 시스템, 패키지 매니저, 테스트 러너, 번들러, 자체 DB, 웹소켓, CLI, 셸 스크립팅... "아니, Bun으로 내가 도대체 못하는 게 뭐지?"라는 생각이 들 정도였습니다. 자바스크립트 개발에 필요한 모든 기능을 자체적으로 제공하면서, 기존 런타임의 성능을 압도하는 이 차세대 기술을 블로그로 다루기에는 너무 방대하다는 것을 깨닫고 집필을 결심하게 되었습니다. 이 책이 단순히 Bun에 대한 기술서가 아니라, 많은 분들께 자바스크립트를 새롭게 만날 수 있는 계기가 되었으면 좋겠습니다. Bun의 등장으로 자바스크립트를 배우기 정말 좋은 시대가 열렸다고 생각합니다. 예전처럼 프로젝트 구성이나 라이브러리 설치하느라 오랫동안 씨름하지 않고 바로 재미있는 애플리케이션 개발을 Bun과 함께 시작하실 수 있습니다. 기존에 자바스크립트에 대해 좋지 못한 경험을 하셨던 현직 개발자분께도 추천드리고 싶습니다. Bun이 자바스크립트 개발자로서 고질적인 애로사항을 해결해 줄 뿐만 아니라, 자바스크립트에 대한 새로운 관점과 다양한 영감을 불어넣을 것입니다. "헬로 Bun"을 통해 여러분이 자바스크립트를 더 쉽게 배우고, 더 즐겁게 소프트웨어 개발을 할 수 있기를 바랍니다. 많은 관심 부탁드립니다! 🙇‍♂️🙏

👋 헬로 Bun 🥟 출간 소식 📚

원문 : How to make your web page faster before it even loads How to make your web page faster before it even loads…

(번역) 웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다.

웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다.

만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :)

글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

오늘 소개해드릴 글은 42dot의 유경상님이 번역해주신 글입니다. 웹 페이지 성능 최적화라고 하면 대부분 페이지 로딩 후의 성능에 집중하는 경향이 있습니다. 하지만 이 글에서는 그 관점을 뒤집어 새로운 인사이트를 제공합니다. 저자는 첫 바이트가 도달하기 전 단계의 최적화에 주목하며, 브라우저의 Performance API와 Navigation Timing API를 활용해 캐시, DNS 조회, 연결 설정, TLS 협상 등 각 단계별 최적화 방법을 상세히 설명합니다. 만약 웹 성능 최적화에 대해 관심이 있으시다면, 이 글을 통해 최적화의 새로운 기회를 발견할 수 있을 것이라고 생각합니다. 이 글을 통해 웹 페이지 성능 최적화에 대한 시야를 넓히는 좋은 기회가 되시길 바랍니다 :) 글 링크 : https://ykss.netlify.app/translation/how_to_make_your_web_page_faster_before_it_even_loads/

ykss.netlify.app

웹 페이지가 로드되기 전에 더 빠르게 만드는 방법

Arthur's place

저자는 try-catch 블록 없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.
const [error, response] = try await fetch("https://arthur.place")

위 코드는 기존 try-catch 코드 블록을 간소화하고
error
를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다.
let response;
try {
  response = await fetch("https://arthur.place");
} catch (error) {
  // blah blah
}

아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.
참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과
try
표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다.

https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

저자는 try-catch 블록&nbsp;없이 에러를 처리할 수 있는 try 표현식을 제안합니다. 예를 들면 다음과 같습니다.<pre ><code class="language-js">const [error, response] = try await fetch("https://arthur.place")</code></pre>위 코드는 기존 try-catch 코드 블록을 간소화하고 <code >error</code>를 반환값 앞에 먼저 배치하여 에러 핸들링에 대한 우선순위를 높이는 효과가 있습니다. <pre ><code class="language-js">let response;
try {
 response = await fetch("https://arthur.place");
} catch (error) {
 // blah blah
}</code></pre>아직 초기 단계의 제안이긴 하지만, 흥미로운 제안인 것 같습니다.참고: 저자의 제안은 원래 안전 할당(`?=`)을 통해 에러 처리를 간소화하려는 제안이였으나, 의논 결과 <code >try</code> 표현식이 좀 더 관용적인 접근 방법이라고 생각되어 try 제안으로 변경한다고 합니다. 관련 Pull Request가 올라와있어, 이 글도 해당 PR의 내용을 기반으로 소개드린 점 참고 부탁드립니다. https://github.com/arthurfiorette/proposal-safe-assignment-operator/pull/42

ECMAScript try-expressions 제안

You are being redirected...

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다.

# 소프트웨어 침식의 원인과 문제
 * 지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.
 * 불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.
 * 중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.

# 소프트웨어 침식을 방지하는 방법
 * 지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.
 * 품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.
 * 설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.

소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요?

https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

소프트웨어는 시간이 흐르면서 기능이 추가되고 유지보수 작업이 누적되면서 자연스럽게 "침식" 현상을 겪습니다. 이는 코드 품질 저하, 기술 부채 증가, 그리고 성능 저하를 야기하여 유지보수 비용을 크게 증가시킵니다. 이 글에서는 소프트웨어 침식의 원인과 그로 인한 문제, 그리고 이를 방지하기 위한 방법을 소개합니다. # 소프트웨어 침식의 원인과 문제<ul ><li>지나치게 복잡해진 코드베이스: 시간이 지나며 요구사항 변화와 기능 추가로 인해 코드가 점점 복잡해짐.</li><li>불필요한 의존성: 빠른 문제 해결을 위해 임시방편으로 추가된 의존성들이 코드베이스를 무겁게 함.</li><li>중복 코드와 설계의 일관성 부족: 팀원 간 커뮤니케이션 부족 및 시간 제약으로 인해 코드 중복과 일관성 결여 발생.</li></ul> # 소프트웨어 침식을 방지하는 방법<ul ><li>지속적인 코드 리팩토링: 정기적인 코드 리뷰와 리팩토링을 통해 코드베이스의 품질을 유지.</li><li>품질 관리 프로세스 개선: 코드 품질을 유지하기 위한 단위 테스트, 통합 테스트 등의 자동화된 테스트 도입.</li><li>설계와 아키텍처 점검: 기존 아키텍처를 주기적으로 점검하고, 필요시 개선 작업을 진행.</li></ul> 소프트웨어 침식은 방치할 경우, 나중에 해결하는 데 많은 비용과 시간이 소요되므로 초기부터 주의 깊은 관리가 필요합니다. 여러분은 현재 프로젝트에서 소프트웨어 침식을 방지하기 위해 어떤 노력을 기울이고 계신가요? https://www.softwaretestingnews.co.uk/software-is-eroding-before-our-eyes/

www.softwaretestingnews.co.uk

내 눈 앞에서 소프트웨어가 침식되고 있다

음.. 어떻게 얘길 시작해야 하나 

끗과 시작, 그 사이 어딘가

'최고가 되어 떠나라'
회사에 붙어있는 메시지 중 하나인데요.
퇴사부검을 보고나니 다들 멋지네요
앞으로 더 좋은 소식 기대하고 있을께요

https://www.brainbackdoor.com/retrospective/2019-2024

'최고가 되어 떠나라'회사에 붙어있는 메시지 중 하나인데요.퇴사부검을 보고나니 다들 멋지네요앞으로 더 좋은 소식 기대하고 있을께요 https://www.brainbackdoor.com/retrospective/2019-2024

동규님의 우아한형제들 퇴사부검

어제 심오한 고민을 하다가 헤라의 글로우 래스팅 파운데이션을 구매했다. 솔직히 양에 비해 가격이 저렴하...

[극대노주의] 올리브영 일반배송 은근슬쩍 오늘드림 변환 수법

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 <리서치 하는데요> 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다)

요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠.

사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠.

문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다.

[ 큐레이터의 문장 🎒 ]

1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다"

2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다."

3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며"

https://m.blog.naver.com/boksle1127/223420780140

제목부터 범상치 않습니다. [극대노주의]를 대괄호로 표시했죠. 결론부터 말씀드리면 뷰티 시장의 큰손, 올리브영 서비스를 앱으로 이용하면서 일반 배송으로 선택했지만 자동으로 선택된 항목으로 인해 '오늘 드림'으로 배송이 되어 증정품을 받지 못하는 상황을 경험한 사용자의 후기입니다. (트레바리 북클럽 &lt;리서치 하는데요&gt; 멤버인 초은 님이 클럽 커뮤니티에 공유해 주신 글이 인상적이라 제가 자세히 살펴보고 정리했습니다) 요약하면 사용자의 의도, 기대했던 것과 다른 경험을 제공하는 기만적 패턴이 문제였습니다. 구매할 때 일반 배송으로 받아야만 증정품을 받을 수 있기 때문에 의도적으로 '오늘 드림'이 아닌 '일반 배송'으로 선택하고 넘어간 것인데 다음 화면에서는 '무료 배송으로 내일 자정까지 받아보시겠어요?'라는 문구가 자동으로 선택되어 있는 겁니다. 문제는 이 문구가 '오늘 드림'을 의미하는 것인지도 모호하고 따져보면 내일 자정이니 '내일드림'이면 그럴듯해도, '오늘 드림'은 아니겠거니 생각하면서 진행을 했던 것인데 받아보니 증정품이 없었던 것이죠. 사용자가 고객센터에 문의한 결과 '무료배송으로 내일 자정까지 받아보시겠어요?'라는 문구를 선택하면 '오늘 드림' 배송으로 동의한 것이라 일반배송이 아닌 게 되므로 증정품을 받을 수 없다는 답변을 받았다고 합니다. 주목할 점은 (1) 문구를 자동으로 선택하도록 만든 것 (2) 이전에 선택한 옵션의 내용을 교모하게 바꿔두고 받을 수 있는 상품구성이 달라진 부분에 대해 사용자가 직접 제품을 받은 뒤 고객센터에 문의해야만 알 수 있다는 점이죠. 문구는 모호하고 화장품 구매에서 증정품이 미치는 영향을 고려할 때 올리브영의 이런 패턴(자동으로 문구 선택, 모호한 설명, 기대한 상품을 받지 못하는 경험)은 기만적이라고 할 수 있습니다. 사용자 블로그글에는 경험을 손상시킨 3가지 문제에 대한 언급이 있습니다. [ 큐레이터의 문장 🎒 ] 1️⃣ "불만 접수방식도 불만 게시판이 명확하게 설립되어 있는 농심과 비교되어 더더욱 기분이 나빴고 (중략) 게다가 설문조사는 그렇게 꼬치꼬치 엄청난 수의 문항으로 물어보면서 이런 고객 불만사항 게시판은 또 마땅히 활성화되어 있지 않는다는 점이 대조되어 더 괘씸하다" 2️⃣ "아무리 생각해도 전에는 오해의 여지가 없도록 명백하게 '오늘드림'이라는 단어를 활용해 안내했었는데 이제 와서 오해의 여지가 다분한 유도성 문구로 변경해 둔 것이 의도가 없이 그런 것이라 생각되질 않기에 사은품 여부를 떠나서 더 기분이 나빴다." 3️⃣ "나는 앞으로 꼭 사은품을 안전하게 받을 수 있는 아모레퍼시픽 공식몰을 이용할 것이라 다짐하며" https://m.blog.naver.com/boksle1127/223420780140

네이버 블로그 | 계절의 기록

《올리브영 다크 패턴에 돌아선 사용자》

대다수의 직장인들이 자신이 다니고 있는 회사가 마치 자기인 양 착각하는 이들이 많은 것 같아.자신이 올린 성과가 혼자 맨땅에 헤딩해서 이루어낸 것처럼 느끼는 거지. 물론 자기가 열심히 했기 때문이기도 하지만, 그 뒤에 조직의 뒷받침이 있어서 가능했던 것인데 말이야. 사회에서 사람들...

📢 99% 직장인이 퇴사 후 알게 되는 충격적인 진실. 이것 모르고 퇴사하면 큰일나요

📢99% 직장인이 퇴사 후 알게 되는 충격적인 진실

자기 객관화를 하라!

#직장인 #퇴사 #퇴사전알아야할것
#헤드헌터 #자기객관화 #커리어
📘#여자는남자가이럴때반한다
#테헤란로소진언니 #삼성동#커리어코치
_________________
✨세상을 반하게 하는 사람들
🎁진짜 나를 찾는 첫 번째 선물 상자

@jennyhr_2008______

📢99% 직장인이 퇴사 후 알게 되는 충격적인 진실 자기 객관화를 하라! #직장인 #퇴사 #퇴사전알아야할것 #헤드헌터 #자기객관화 #커리어 📘#여자는남자가이럴때반한다 #테헤란로소진언니 #삼성동#커리어코치 _________________ ✨세상을 반하게 하는 사람들 🎁진짜 나를 찾는 첫 번째 선물 상자 @jennyhr_2008______

www.youtube.com

제니휴먼리소스 대표(헤드헌터/ 커리어코치) 

김소진

🚩 '연봉' 올려주는 '테헤란로 소진언니'
📕 '넥스트 커리어'로 새로운 인생을 돕는 21년 경력 헤드헌터
♦ 전문직ㅣCEO를 위한 프로필 리마스터
♦ 직장인 넥스트 커리어를 위한 커리어 코칭
 📌link.inpock.co.kr/jennyhr

📢99% 직장인이 퇴사 후 알게 되는 충격적인 진실

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필