안녕하세요. 그린입니다 🍏이번 포스팅에서는 WWDC 2025에서 소개된 Build a UIKit app with the new design 세션을 정리해보겠습니다 🙋🏻 Build a UIKit app with the new designLiquid Glass를 앱에 가져와서 적용하는 방법에 대해 알아보는 세션입니다. Liquid Glass는 반투명하고 역동적이죠.UIKit의 기본적인 컴포넌트들은 새로운 SDK 업데이트를 통해 사용한다면 바로 이런 적용으로 보일 수 있어요. Tab views and split views탭 뷰와 스플릿 뷰에 새 디자인을 적용하고 컨텐츠 위에 띄우는 방법을 보겠습니다.이미 새 버전에서 탭 바와 스플릿 컨트롤러는 Liquid Glass 디자인으로 업데이트 되었어요. 탭 ..

Build a UIKit app with the new design (feat. WWDC 2025)

WWDC 2025에서 가장 핫한건 Liquid Glass죠?
iOS 개발자들에게도 개발에 있어 또 새로운 재미가 생겼을거라 생각합니다.

이번에는 WWDC 2025의 Build a UIKit app with the new design 세션을 보면서 어떻게 기본 컴포넌트에서 적용되었는지, 그리고 더 나아가 우리가 구현하는 커스텀한 뷰들에서는 어떻게 Liquid Glassf를 적용하여 구현해볼 수 있는지 한번 살펴보았습니다 😃

WWDC 2025에서 가장 핫한건 Liquid Glass죠?iOS 개발자들에게도 개발에 있어 또 새로운 재미가 생겼을거라 생각합니다. 이번에는 WWDC 2025의 Build a UIKit app with the new design 세션을 보면서 어떻게 기본 컴포넌트에서 적용되었는지, 그리고 더 나아가 우리가 구현하는 커스텀한 뷰들에서는 어떻게 Liquid Glassf를 적용하여 구현해볼 수 있는지 한번 살펴보았습니다 😃

iOYES

Build a UIKit app with the new design

『Clean Architecture』의 “FUNCTIONAL PROGRAMMING” 마지막에는
개발 패러다임(패턴)을 어떤 관점으로 학습해야 할지 생각하게 만드는 문장이 있습니다.

“What we have learned over the last half-century is what not to do.”

책에서 설명하는 개발 패러다임은,
협업과 비즈니스 성장을 저해하는 문제 상황을 제거하기 위해
지난 반세기 동안 축적된 엔지니어들의 실전적 노하우라고 볼 수 있습니다.

그렇기에 개발 패러다임을 공부할 때는
“어떻게 코드를 작성해야 하는가”보다
“어떤 코드가 어떤 문제를 유발할 수 있는가”를 아는 것이 더욱 중요하다고 생각합니다.

『Clean Architecture』의 “FUNCTIONAL PROGRAMMING” 마지막에는개발 패러다임(패턴)을 어떤 관점으로 학습해야 할지 생각하게 만드는 문장이 있습니다. “What we have learned over the last half-century is what not to do.” 책에서 설명하는 개발 패러다임은,협업과 비즈니스 성장을 저해하는 문제 상황을 제거하기 위해지난 반세기 동안 축적된 엔지니어들의 실전적 노하우라고 볼 수 있습니다. 그렇기에 개발 패러다임을 공부할 때는“어떻게 코드를 작성해야 하는가”보다“어떤 코드가 어떤 문제를 유발할 수 있는가”를 아는 것이 더욱 중요하다고 생각합니다.

개발 패러다임, "무엇을 하자"보다 "무엇을 하지말자"에 주목할 것

시니어 개발자의 실전 경험에서 우러난 취업과 협업에 대한 현실 조언을 담았습니다! 

개발자로 성장하는 데 필요한 건 어떤 태도일까? | 우아한 형제들 출신 멘토님

이번에 제가 멘토로 활동하는 커뮤니티에서 주니어 개발자들의 궁금증에 대한 제 생각을 공유하는 인터뷰를 진행했습니다.

"이력서는 항상 붙는데 면접에서 계속 떨어진다면 어떤 노력을 더 하면 좋을까요?"
"새로운 기술 스택을 배운 후, 바로 현업에서 적용하는 경우도 있나요?"
"멘토님께서 취업을 준비하실 때, 얼마나 많은 시간을 투자하셨을지 궁금합니다."
"비개발자와 잘 소통할 수 있는 팁이 있을까요?"
"하루 중 가장 좋아하는 순간이 언제인가요?"

이런 고민을 해보셨다면, 이 인터뷰 글이 도움이 될 거 같은데요.
이번 인터뷰를 통해 저의 경험을 바탕으로, 몇 가지 현실적인 조언을 드렸습니다.

면접: 기술 설명은 '왜'와 '어떻게'를 담아 1시간 강의할 수 있을 정도로 준비해야 합니다. 그리고 면접관을 '사랑과 존경의 시선'으로 바라보는 태도가 중요합니다.

기술 학습: 기술은 '배워서 쓰는 것'이 아니라, '쓰기 위해 배우는 것'입니다. 이제는 과감히 실전에서 부딪히며 배우는 태도가 진짜 실력입니다.

취업 준비: 구직 기간이 생각보다 길어지는 것은 지극히 정상입니다. 중요한 것은 시간이 아니라, 그 시간을 '어떻게' 활용했는가입니다.

소통: 비개발자와의 협업에서는 '중학생에게 설명하듯' 쉽고 명확하게 소통하는 능력이 무엇보다 중요합니다.

단순히 코딩 실력뿐만 아니라, 함께 일하고 싶은 동료로 성장하기 위한 저의 생각을 담았습니다. 개발자로서 다음 스텝을 고민하고 계신 분, 더 나은 개발 문화와 동료와의 협업을 고민하는 분들께 이 글이 작은 영감이 되기를 바랍니다.
자세한 내용은 아래 블로그에서 확인해주세요! 여러분의 생각도 댓글로 남겨주시면 감사하겠습니다 :)

https://f-lab.kr/blog/250610-devclub

이번에 제가 멘토로 활동하는 커뮤니티에서 주니어 개발자들의 궁금증에 대한 제 생각을 공유하는 인터뷰를 진행했습니다. "이력서는 항상 붙는데 면접에서 계속 떨어진다면 어떤 노력을 더 하면 좋을까요?" "새로운 기술 스택을 배운 후, 바로 현업에서 적용하는 경우도 있나요?" "멘토님께서 취업을 준비하실 때, 얼마나 많은 시간을 투자하셨을지 궁금합니다." "비개발자와 잘 소통할 수 있는 팁이 있을까요?" "하루 중 가장 좋아하는 순간이 언제인가요?" 이런 고민을 해보셨다면, 이 인터뷰 글이 도움이 될 거 같은데요. 이번 인터뷰를 통해 저의 경험을 바탕으로, 몇 가지 현실적인 조언을 드렸습니다. 면접: 기술 설명은 '왜'와 '어떻게'를 담아 1시간 강의할 수 있을 정도로 준비해야 합니다. 그리고 면접관을 '사랑과 존경의 시선'으로 바라보는 태도가 중요합니다. 기술 학습: 기술은 '배워서 쓰는 것'이 아니라, '쓰기 위해 배우는 것'입니다. 이제는 과감히 실전에서 부딪히며 배우는 태도가 진짜 실력입니다. 취업 준비: 구직 기간이 생각보다 길어지는 것은 지극히 정상입니다. 중요한 것은 시간이 아니라, 그 시간을 '어떻게' 활용했는가입니다. 소통: 비개발자와의 협업에서는 '중학생에게 설명하듯' 쉽고 명확하게 소통하는 능력이 무엇보다 중요합니다. 단순히 코딩 실력뿐만 아니라, 함께 일하고 싶은 동료로 성장하기 위한 저의 생각을 담았습니다. 개발자로서 다음 스텝을 고민하고 계신 분, 더 나은 개발 문화와 동료와의 협업을 고민하는 분들께 이 글이 작은 영감이 되기를 바랍니다. 자세한 내용은 아래 블로그에서 확인해주세요! 여러분의 생각도 댓글로 남겨주시면 감사하겠습니다 :) https://f-lab.kr/blog/250610-devclub

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

이력서는 붙는데 면접에서 계속 떨어진다면?

안녕하세요. 그린입니다 🍏오늘 포스팅에서는 async 및 throws 컨텍스트에서 defer를 사용하는 방법에 대해 한번 작성해볼까 합니다 🙋🏻 최근 Swift by Sundell 사이트에서 해당 관련한 포스트를 접하게 되었고 꽤 흥미로운 내용이라 한번 보고 정리해보려고 해요! 해당 원본 아티클을 보시려는분은 요걸 보시면 됩니다 😃 Using Swift’s defer keyword within async and throwing contexts | Swift by SundellHow Swift’s defer keyword can be incredibly useful when working with code scopes that have multiple exit points, such as throw..

defer (async throwing contexts)

defer
는 스코프 종료 시 반드시 실행되는 코드를 작성할 수 있게 해주는 Swift의 강력한 기능이죠 😃

특히
async/await
나
throws
문맥에서의 자원 정리 및 상태 복원에 매우 유용하게 쓰일 수 있습니다.
한번 잘 활용해보면 좋지 않을까요?

<code >defer</code>는 스코프 종료 시 반드시 실행되는 코드를 작성할 수 있게 해주는 Swift의 강력한 기능이죠 😃 특히 <code >async/await</code>나 <code >throws</code> 문맥에서의 자원 정리 및 상태 복원에 매우 유용하게 쓰일 수 있습니다.한번 잘 활용해보면 좋지 않을까요?

defer, 에러 핸들링과 비동기에서 어떻게 활용할까?

플레이모어와 함께할 동료를 찾습니다 | Notion

🎉 벤처기업 인증 완료! 🎉

근데 명칭이 정확하게는 “인증”같은 거창한게 아니라 “확인”이더군요. 😇

해보니 딱히 대단한게 아니었어서.. 이걸 왜 그렇게 자랑하나 싶기도 하지만.. 😅

그래도 자랑한다고 손해 볼 건 없으니 자랑해봅니다. 😆

정부가 인증한 혁신적 벤처기업🤭 플레이모어에서 초기 멤버를 모집하고 있습니다. 많은 관심 부탁드립니다. 🙇🏻🙇🏻‍♀️

https://go.playmore.ai/careers

🎉 벤처기업 인증 완료! 🎉 근데 명칭이 정확하게는 “인증”같은 거창한게 아니라 “확인”이더군요. 😇 해보니 딱히 대단한게 아니었어서.. 이걸 왜 그렇게 자랑하나 싶기도 하지만.. 😅 그래도 자랑한다고 손해 볼 건 없으니 자랑해봅니다. 😆 정부가 인증한 혁신적 벤처기업🤭 플레이모어에서 초기 멤버를 모집하고 있습니다. 많은 관심 부탁드립니다. 🙇🏻🙇🏻‍♀️ https://go.playmore.ai/careers

playmoreai on Notion

안녕하세요. 그린입니다 🍏이번 포스팅에서는 Logger 캐싱과 성능에 대해 한번 정리해볼까 합니다 🙋🏻Logger Caching & PerformanceiOS 개발에서 os.Logger를 포함한 로깅 시스템은 앱 진단 및 디버깅에 있어서 핵심적인 역할을 해줍니다. 하지만, 혹시 Logger 인스턴스를 매번 새로 생성하고 있지는 않으신가요? 이번 포스팅에서는 그것을 중심으로 Logger 인스턴스 캐싱이 왜 필요하고 실제로 어떤 성능 차이가 있는지에 대해 한번 분석해보면서 정리해봅니다 😃 Logger를 매번 새로 만든다면?Apple은 iOS 14부터 os.Logger API를 도입하면서 기존의 os_log 기반 로깅을 더 정돈된 방식으로 관리할 수 있게 발전했습니다.이 Logger는 단순한 구조체지만..

Logger Caching & Performance

os.Logger를 매번 새로 만들면 내부적으로 생각보다 많은 비용이 발생합니다.
Logger 인스턴스를 캐싱했을때와 아닐때의 성능을 한번 비교해봐도 좋은 포인트입니다.
이를 위해 구현 패턴과 수치 기반의 분석을 아주 간단히 정리해봤습니다 🙋🏻

os.Logger를 매번 새로 만들면 내부적으로 생각보다 많은 비용이 발생합니다.Logger 인스턴스를 캐싱했을때와 아닐때의 성능을 한번 비교해봐도 좋은 포인트입니다.이를 위해 구현 패턴과 수치 기반의 분석을 아주 간단히 정리해봤습니다 🙋🏻

Logger 인스턴스 매번 생성하시나요?

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

 - YouTube

AI 가 네이티브인 Dia 브라우저와 함께
공식문서를 공부하는 방법에 대해 소개해드려요.
직접 써보고 좋은 프로덕트여서 후기 남겨요. 🤗

다양한 공식문서를 직접 깊이 공부해야 할때
활용하시면 도움이 되실것 같아서요.
그럼 각자의 자리에서 함께 공부하시는 모든 분들 화이팅입니다. :)

https://youtu.be/x8CibOavzEE

AI 가 네이티브인 Dia 브라우저와 함께 공식문서를 공부하는 방법에 대해 소개해드려요. 직접 써보고 좋은 프로덕트여서 후기 남겨요. 🤗 다양한 공식문서를 직접 깊이 공부해야 할때 활용하시면 도움이 되실것 같아서요. 그럼 각자의 자리에서 함께 공부하시는 모든 분들 화이팅입니다. :) https://youtu.be/x8CibOavzEE

youtu.be

새로운 AI 브라우저와 함께 공식문서를 깊이 있게 + 효율적으로 공부하기

루비온레일즈에서는 CoC라는 게 있습니다. Convention over Configuration. 그러니까 설정보다 컨벤션을 더 중시하게 본다는 겁니다. 설정 파일에다가 이것저것 적는 것이 아니라 그저 관행대로 하면 알아서 동작하는 거.

레일즈 철학과 카카오 문화

루비온레일즈에서는 CoC라는 게 있습니다.
Convention over Configuration.
그러니까 설정보다 컨벤션을 더 중시하게 본다는 겁니다.
설정 파일에다가 이것저것 적는 것이 아니라 그저 관행대로 하면 알아서 동작하는 거.

예를 들어서 라우트에 articles란 이름의 경로를 만들면, 이 경로는 articles_controller.rb 와 자동으로 매핑이 됩니다.
그리고 articles_controller의 index 액션은 views/articles/index.html.erb 을 자동으로 찾아서 렌더링 합니다.
이를 위한 어떤 설정도 필요 없습니다. 그저 관행일 뿐입니다.
DB 의 테이블 이름과 모델 클래스의 이름이 항상 동일하다는 것도 CoC의 한 예입니다.

처음엔 이런 관행이 짜증 나기도 했습니다.
왜 모든 테이블 이름이 복수형이어야만 하지?
Person 모델이 있으면 당연히 테이블 이름도 person이어야 직관적이지 않나? 왜 people이라는 복수형을 강제하는 거지?
이런 생각으로 반항하며 대들 때마다 레일즈는 고통을 돌려주었습니다.

초반에는 Rails와 많이 다투면서 이런 고집스러운 녀석과는 같이 못 살겠다 생각을 했었습니다만…
그 장점을 받아들이고 나서 드디어 친하게 지낼 수 있게 되었습니다.
오히려 제약하고 강제하면서 코딩이 만사 편해질 수 있구나 하는 걸 배웠습니다.

그런데 이게 꼭 코딩 시에만 적용되는 것은 아니었습니다.
사내 문화에 이런 걸 적용한 회사도 있었습니다.

카카오에 처음 들어갔을 때 영어 닉네임을 정해야만 했습니다.
그 영어 닉네임은 사람들에게 불리는 내 호칭이기도 했지만, 내 이메일 주소가 되기도 했습니다. 사내 github 주소가 되었고 사내 게시판의 닉네임이 되었습니다.
동료의 메일 주소를 물어볼 필요가 없었습니다. 부르는 이름이 메일 주소니까.
저는 Windows 컴퓨터를 사용해왔지만 얄짤없었습니다. 모든 사람들에게 맥북이 지급되었습니다.
사람들의 자유를 너무 제약하고 강제하는 것 아닌가?

돌아보니 이런 문화들이 마치 레일즈의 CoC처럼 느껴집니다.
회사 문화를 처음 만든 사람들이 레일즈를 워낙 좋아해서 영향을 받은 거 아닌가 하는 의심마저 들었습니다.(웃음)
엄격하게 강제하지만 구성원들이 잘 따르기만 하면 모두가 편해지는 관례.

이런 것이 좋을 때도 있다는 사실을 이제는 받아들입니다.

https://jeho.page/essay/2025/06/13/rails-kakao-coc.html

루비온레일즈에서는 CoC라는 게 있습니다. Convention over Configuration. 그러니까 설정보다 컨벤션을 더 중시하게 본다는 겁니다. 설정 파일에다가 이것저것 적는 것이 아니라 그저 관행대로 하면 알아서 동작하는 거. 예를 들어서 라우트에 articles란 이름의 경로를 만들면, 이 경로는 articles_controller.rb 와 자동으로 매핑이 됩니다. 그리고 articles_controller의 index 액션은 views/articles/index.html.erb 을 자동으로 찾아서 렌더링 합니다. 이를 위한 어떤 설정도 필요 없습니다. 그저 관행일 뿐입니다. DB 의 테이블 이름과 모델 클래스의 이름이 항상 동일하다는 것도 CoC의 한 예입니다. 처음엔 이런 관행이 짜증 나기도 했습니다. 왜 모든 테이블 이름이 복수형이어야만 하지? Person 모델이 있으면 당연히 테이블 이름도 person이어야 직관적이지 않나? 왜 people이라는 복수형을 강제하는 거지? 이런 생각으로 반항하며 대들 때마다 레일즈는 고통을 돌려주었습니다. 초반에는 Rails와 많이 다투면서 이런 고집스러운 녀석과는 같이 못 살겠다 생각을 했었습니다만… 그 장점을 받아들이고 나서 드디어 친하게 지낼 수 있게 되었습니다. 오히려 제약하고 강제하면서 코딩이 만사 편해질 수 있구나 하는 걸 배웠습니다. 그런데 이게 꼭 코딩 시에만 적용되는 것은 아니었습니다. 사내 문화에 이런 걸 적용한 회사도 있었습니다. 카카오에 처음 들어갔을 때 영어 닉네임을 정해야만 했습니다. 그 영어 닉네임은 사람들에게 불리는 내 호칭이기도 했지만, 내 이메일 주소가 되기도 했습니다. 사내 github 주소가 되었고 사내 게시판의 닉네임이 되었습니다. 동료의 메일 주소를 물어볼 필요가 없었습니다. 부르는 이름이 메일 주소니까. 저는 Windows 컴퓨터를 사용해왔지만 얄짤없었습니다. 모든 사람들에게 맥북이 지급되었습니다. 사람들의 자유를 너무 제약하고 강제하는 것 아닌가? 돌아보니 이런 문화들이 마치 레일즈의 CoC처럼 느껴집니다. 회사 문화를 처음 만든 사람들이 레일즈를 워낙 좋아해서 영향을 받은 거 아닌가 하는 의심마저 들었습니다.(웃음) 엄격하게 강제하지만 구성원들이 잘 따르기만 하면 모두가 편해지는 관례. 이런 것이 좋을 때도 있다는 사실을 이제는 받아들입니다. https://jeho.page/essay/2025/06/13/rails-kakao-coc.html

K리그 프로그래머

레일즈와 카카오 문화

Kotlin의 Scope 함수 정리

Kotlin의 Scope 함수는 객체의 컨텍스트 내에서 코드 블록을 실행할 수 있게 해주는 강력한 기능입니다.

Scope 함수에는
let()
,
run()
,
also()
,
apply()
,
with()
이렇게 5개가 있는데요. 얘네들이 비슷한 것 같으면서도 미묘하게 달려서 잘 정리해두지 않으면 언제 어떤 녀석을 써야 하는지 은근히 헷갈릴 수 있습니다.

이번 포스팅에서는 Kotlin의 Scope 함수 5종의 사용법을 정리해드리도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/kotlin-scope-functions/

Kotlin의 Scope 함수는 객체의 컨텍스트 내에서 코드 블록을 실행할 수 있게 해주는 강력한 기능입니다. Scope 함수에는 <code >let()</code>, <code >run()</code>, <code >also()</code>, <code >apply()</code>, <code >with()</code> 이렇게 5개가 있는데요. 얘네들이 비슷한 것 같으면서도 미묘하게 달려서 잘 정리해두지 않으면 언제 어떤 녀석을 써야 하는지 은근히 헷갈릴 수 있습니다. 이번 포스팅에서는 Kotlin의 Scope 함수 5종의 사용법을 정리해드리도록 하겠습니다. 📝 포스팅: https://www.daleseo.com/kotlin-scope-functions/

www.daleseo.com

좋은 동료 훌륭한 동료는 나를 몇단계 성장할 수 있는 계기가 되기도 한다. 어떤 동료와 함께 일할 때 성장 확률이 높을까?

내가 속한 환경에서는 어떻게 일해야 성장할 수 있을까?

누구나 '좋은 개발자'가 되고 싶어 합니다.
하지만 대부분은 기술서적을 더 읽고, 새로운 언어를 배우며 스스로를 "업그레이드"하려 하죠. 물론 그 노력은 값집니다.

하지만 과연 그것만으로 충분할까요?

개발자의 성장은 단지 지식의 양으로만 설명되지 않습니다. 
어떤 환경에 속해 있는가, 어떤 질문을 던지고 있는가, 그리고 누구와 함께 성장하고 있는가가 훨씬 중요할 수 있습니다.
마치 같은 씨앗이라도 어디에 심기느냐에 따라 전혀 다른 나무로 자라듯이요.

최근에 읽은 한 글에서는 그런 성장에 대한 통찰을 볼 수 있었습니다.
단순히 기술을 가르치고 업무를 분배하는 조직이 아닌, 개발자가 스스로 고민하고 질문할 수 있게 만들어주는 환경의 가치가 중요합니다.

예를 들어, 어떤 문제가 생겼을 때 "답"을 주기보다, 스스로 해답에 도달하도록 가이드만 제시하는 구조, 이건 단순한 교육이 아니라 ‘성장을 설계하는 방식’에 가깝습니다.
또한 '실수'를 부끄러워하기보다 기회로 전환할 수 있는 문화, 그리고 그 과정에서 '어떻게 성장했는가'를 함께 나누는 분위기가 중요합니다.

실제로 개발자가 마주하는 대부분의 문제는 기술 자체보다 '어떻게 접근할 것인가'에 달려 있기 때문에, 이런 환경은 곧 실력의 방향성을 결정짓는 나침반이 됩니다.
성장을 고민하고 있는 개발자, 혹은 정체되어 있다고 느끼고 있다면 한번 읽어보면 좋을것 같아요.

누구나 '좋은 개발자'가 되고 싶어 합니다. 하지만 대부분은 기술서적을 더 읽고, 새로운 언어를 배우며 스스로를 "업그레이드"하려 하죠. 물론 그 노력은 값집니다. 하지만 과연 그것만으로 충분할까요? 개발자의 성장은 단지 지식의 양으로만 설명되지 않습니다.&nbsp;어떤 환경에 속해 있는가,&nbsp;어떤 질문을 던지고 있는가, 그리고&nbsp;누구와 함께 성장하고 있는가가 훨씬 중요할 수 있습니다. 마치 같은 씨앗이라도 어디에 심기느냐에 따라 전혀 다른 나무로 자라듯이요. 최근에 읽은 한 글에서는 그런 성장에 대한 통찰을 볼 수 있었습니다. 단순히 기술을 가르치고 업무를 분배하는 조직이 아닌,&nbsp;개발자가 스스로 고민하고 질문할 수 있게 만들어주는 환경의 가치가 중요합니다. 예를 들어, 어떤 문제가 생겼을 때 "답"을 주기보다, 스스로 해답에 도달하도록&nbsp;가이드만 제시하는 구조,&nbsp;이건 단순한 교육이 아니라 ‘성장을 설계하는 방식’에 가깝습니다.또한 '실수'를 부끄러워하기보다&nbsp;기회로 전환할 수 있는 문화, 그리고 그 과정에서 '어떻게 성장했는가'를 함께 나누는 분위기가 중요합니다. 실제로 개발자가 마주하는 대부분의 문제는 기술 자체보다 '어떻게 접근할 것인가'에 달려 있기 때문에, 이런 환경은 곧&nbsp;실력의 방향성을 결정짓는 나침반이 됩니다.성장을 고민하고 있는 개발자, 혹은 정체되어 있다고 느끼고 있다면 한번 읽어보면 좋을것 같아요.

좋은 개발자는 환경이 만든다

2025년 2분기 AI 세미나: '바이브 코딩 시대의 기업, 이렇게 바뀝니다'넘쳐나는 코딩 에이전트 시대, 스타트업부터 대기업까지 팀 구조는 어떻게 바뀔까요?2025년 상반기 AI 산업과 하반기에 AI를 통해 오게될 변화를 비즈니스 관점과 엔지니어 관점 모두에서 점검하는 시간입니다.<내용>1. 비즈니스 관점MCP부터 A2A까지 올 상반기 등장한 새로운 제품들을 직접 리뷰하고, 아래의 내용을 통해 빅테크 회사들의 AI 전략 변화를 다각도로 분석합니다. - 메리미커 리포트- 애플의 WWDC - 구글의 IO- NVIDIA의 GTC...

2025년 2분기 AI 세미나

바이브 코딩의 시대, 정말 새로운 세상이 열렸다

 * '입 코딩'을 실현시켜주는 클로드 코드와 구글 Jules가 5월 말 속속 오픈되면서 필자가 직접 테스트해봤음. 정말 충격적. (와이어드 기사 참고)
 * 1-2시간이면 서비스 하나 뚝딱. 개발팀원, 디자인 팀원이 1/5만 있어도 되고 속도는 5배 이상 빨라짐.
 * 일하는 워크플로우가 완전히 뒤바뀌는 중. 이제 아이디어만 있으면 누구나 개발자가 될 수 있는 시대가 정말 온 것 같음.
 * 다만 와이어드 기사처럼 개발자들 사이에서도 의견이 완전 갈림. 
   
   * 베테랑 개발자들은 "AI가 유치원생처럼 실수투성이라 계속 감시해야 한다"고 하고,
   * 젊은 개발자들은 "이거 안 쓰면 달리기 경주에서 걷는 거나 마찬가지"라며 적극 수용 중.
 * 결국 핵심은 AI를 잘 다루는 법이 아니라 개발팀을 이끄는 프로덕트 팀 자체가 바뀐다는 것. 업무 방식이 개인의 생산성, 팀의 생산성이 아니라 제품의 플로우 전환에 있음 .
 * 바이브 코딩으로 새로운 세상이 어떻게 열렸는지 오호츠크 온라인 세미나 세션(https://55check.imweb.me/32/?idx=7) 에서 직접 보여드릴게요.
   6월 26일(목) 저녁, 29일(일) 아침 이렇게 2개 세션을 준비했습니다.

나머지 이야기들도 다음의 글에서.

AI 업체들, 데이터 확보에 사활
 * 왜 메타는 ScaleAI 를 20조나 주고 인수 했을까?
   
   
엔비디아, 국가별 사업모델 구축에 나서
- 이제 국가별 맞춤형으로 장사하려는 듯. "빅테크가 독점하게 두지 말고 국가별 데이터센터 구축하자"고 요즘 주장하는데, 이건 빅테크 견제라기보다는 "국가별로 같은 걸 만들게 해서라도 더 많이 팔아먹고 싶다"는 젠슨 황의 진심.

퀄컴, AI 반도체 설계회사 알파웨이브 3.2조에 인수

마우스를 만든 빌 앳킨슨 별세
 * 빌 앳킨슨이 췌장암으로 2025년 6월 5일 별세. (포춘 코리아)
 * 50년 전 컴퓨터 혁명을 이끈 분.

바이브 코딩의 시대, 정말 새로운 세상이 열렸다 <ul ><li>'입 코딩'을 실현시켜주는 클로드 코드와 구글 Jules가 5월 말 속속 오픈되면서 필자가 직접 테스트해봤음. 정말 충격적. (와이어드 기사 참고)</li><li>1-2시간이면 서비스 하나 뚝딱. 개발팀원, 디자인 팀원이 1/5만 있어도 되고 속도는 5배 이상 빨라짐.</li><li>일하는 워크플로우가 완전히 뒤바뀌는 중. 이제 아이디어만 있으면 누구나 개발자가 될 수 있는 시대가 정말 온 것 같음.</li></ul><ul ><li>다만 와이어드 기사처럼 개발자들 사이에서도 의견이 완전 갈림.&nbsp; <ul ><li>베테랑 개발자들은 "AI가 유치원생처럼 실수투성이라 계속 감시해야 한다"고 하고,</li><li>젊은 개발자들은 "이거 안 쓰면 달리기 경주에서 걷는 거나 마찬가지"라며 적극 수용 중.</li></ul></li></ul><ul ><li>결국 핵심은 AI를 잘 다루는 법이 아니라 개발팀을 이끄는 프로덕트 팀 자체가 바뀐다는 것. 업무 방식이 개인의 생산성, 팀의 생산성이 아니라 제품의 플로우 전환에 있음 .</li><li>바이브 코딩으로 새로운 세상이 어떻게 열렸는지 오호츠크 온라인 세미나 세션(https://55check.imweb.me/32/?idx=7) 에서 직접 보여드릴게요. 6월 26일(목) 저녁, 29일(일) 아침 이렇게 2개 세션을 준비했습니다.</li></ul> 나머지 이야기들도 다음의 글에서. AI 업체들, 데이터 확보에 사활<ul ><li>왜 메타는 ScaleAI 를 20조나 주고 인수 했을까? </li></ul>엔비디아, 국가별 사업모델 구축에 나서 - 이제 국가별 맞춤형으로 장사하려는 듯.&nbsp;"빅테크가 독점하게 두지 말고 국가별 데이터센터 구축하자"고 요즘 주장하는데, 이건 빅테크 견제라기보다는 "국가별로 같은 걸 만들게 해서라도 더 많이 팔아먹고 싶다"는 젠슨 황의 진심. 퀄컴, AI 반도체 설계회사 알파웨이브 3.2조에 인수 마우스를 만든 빌 앳킨슨 별세<ul ><li>빌 앳킨슨이 췌장암으로 2025년 6월 5일 별세. (포춘 코리아)</li><li>50년 전 컴퓨터 혁명을 이끈 분.</li></ul>

55check.imweb.me

6월 초, 새로운 바이브 코딩과 SW 개발의 전환의 시대

첫번째 채용입니다. (두근💓) 채용 직무는 다음과 같습니다.

🔍 Product Manager
🎨 Product Designer
📱 Software Engineer, RN App (Full Stack)
🚀 Software Engineer, AI Agent (Backend)

회사 소개와 직무에 대한 자세한 내용은 아래 링크에서 확인해주세요.

https://go.playmore.ai/careers

소개를 이리저리 멋지게 작성하려고 해 보다가.. 담백하게 작성했습니다. ☺️ 꼭 메일이 아니어도 DM등으로 문의 해 주셔도 좋습니다.

그럼 많은 관심과 추천, 홍보 부탁드리겠습니다.

감사합니다. 🙇🏻‍♂️🙇🏻‍♀️

첫번째 채용입니다. (두근💓) 채용 직무는 다음과 같습니다. 🔍 Product Manager🎨 Product Designer📱&nbsp;Software Engineer, RN App (Full Stack)🚀 Software Engineer, AI Agent (Backend) 회사 소개와 직무에 대한 자세한 내용은 아래 링크에서 확인해주세요. https://go.playmore.ai/careers 소개를 이리저리 멋지게 작성하려고 해 보다가.. 담백하게 작성했습니다. ☺️ 꼭 메일이 아니어도 DM등으로 문의 해 주셔도 좋습니다. 그럼 많은 관심과 추천, 홍보 부탁드리겠습니다. 감사합니다. 🙇🏻‍♂️🙇🏻‍♀️

🪄 플레이모어와 함께할 동료를 찾습니다

1. PM/PO 커리어는 3개의 단계로 나눠 생각해 볼 수 있다. 그 세가지는 일을 할 때 거치는 3단계와도 같다. 일의 3단계는 무얼까.

2. Why -> What -> How. 모든 일은 이 3가지 단계를 거친다. 프로덕트도 마찬가지다.

3. 첫 번째는 Why다. 그 일이 존재하는 이유다. 프로덕트와 기능으로 하고 싶은 궁극적인 이유다. 무엇을 할 것인가? 왜 해야 하는가. 왜 하고 싶은가. 꼭 해야 하는지. 그 목적은 무언가. 또, 목표는 무언가. 성공 여부는 무엇으로 판단할 수 있나.

4. Why는 우리가 일할 때 잘 보이지 않는다. 그래서 정말 중요하다. 보이지 않기에 쉽게 잊는다. 위험하다. 특히 제품을 만들다 보면, 만드는 일 자체에 매몰된다. 왜 이걸 만들고 있는지 잊는다. 목적을 잊는다면 수단이 목적이 된다. 늘 경계해야 한다.

5. 두 번째는 What이다. What은 사용자에게 전달되는 프로덕트/기능 자체다. Why를 어떻게 달성할 수 있을까. 목적을 달성할 수 있는 수단은 항상 많다. 너무 많아서 문제다.

6. 확산과 수렴이 필요하다. 가능한 방법을 리스트 업한다. 마음껏 넓혀서 확장한다. 이후에는 좁혀간다. 지우고 합친다. 우선순위를 정해본다. 최종적으로 가장 적합한 What을 결정한다.

7. 이제 마지막으로 How다. 그 What을 어떻게 만들 것인가. 마찬가지로 만들 수 있는 방법은 다양하다. 이 기능을 어떻게 구현하면 좋을까.

8. 쓸 수 있는 시간과 자원을 고려해 본다. 기술을 효과적으로 쓸 수 있는 방법과 제약도 검토한다. 때로는 제품이 아닌 정책 변경 같은 방법이 가장 효율적일 때도 있다. 망치를 들고 있으면 못만 보이는 법이다. 필요 없는 일을 효율적으로 한다고 가치가 생기진 않는다. Why의 해결/달성이 궁극적인 목표인 걸 늘 기억해야 한다.

9. 프로덕트를 만드는 3단계를 살펴봤다. PM/PO의 커리어는 정확히 이 순서의 반대로 진행된다.

10. 먼저 주니어다. 주니어 때는 How에 집중하는 기간이다. 만들어야 할 제품과 기능은 대부분 이미 정해져있다. 해야 할 일은 누구와 함께 그것을 잘 만들어내는 일이다.

11. 디자이너, 엔지니어, QA 등 메이커들을 이끌어 What을 만든다. 출시까지 발생하는 이슈들을 해결한다. 이후에 지표와 고객의 반응을 확인하고 분석한다. 프로덕트 관리와 프로젝트 관리가 혼재되어 있다.

12. 중니어, 미들급은 What에 집중하는 기간이다. How는 충분히 익혔기에 목표를 달성할 수 있는 제품과 기능을 고민하게 된다.

13. 사업적인 요구사항은 Why다. 그 목적을 달성할 수 있는 가장 좋은 프로덕트/기능은 무엇일까. 이 질문에 답을 찾는다.

14. 먼저 사업적인 이해가 필요하다. 그리고 구체적인 제품의 모습을 그린다. 최종적으로 사용할 고객의 모습을 상상한다. How 단계의 구현까지도 염두에 둔다. 이 모든 걸 종합해서 만들 제품/기능을 정의한다.

15. 마지막으로 시니어/C레벨의 단계는 Why다. What/How는 도구다. 사용할 수 있는 무기와 같다. 이 무기를 기반으로 해야 할 일, 목적을 정의한다.

16. 프로덕트의 What/How의 경험을 기반으로 가치를 만들어낼 일, Why를 만든다. 이 가치를 수익과 바꿀 수 있는 시장과 고객을 찾는 게 결국 사업이다. 프로덕트/플랫폼 기반의 사업을 리딩하고 실행한다. Why를 What/How 레벨에 잘 전달하는 것도 중요한 역할이다.

17. 일은 Why -> What -> How 순서다. 우리가 거치는 커리어는 그 반대다. How -> What -> Why 순으로 성장해간다. 지금 어떤 일을 하건 이 3가지 단계로 생각해 보는 건 중요하다.

18. 주니어 시절에 늘 답답했다. Why가 보이지 않았기 때문이다. 내가 하고 있는 이 일은 무엇을 위해서일까. 왜 이 일을 해야 하는 걸까. 아무도 알려주지 않았고, 알 수 없었다. 그저 막연히 상상해 볼 수밖에.

19. 그런 답답함에서 오는 막막한 상상들이 성장에는 큰 도움이 됐다. 비록 정답을 생각할 수는 없었다. 하지만 그렇게 Why를 생각해보는 연습이 넓은 관점을 갖는데 도움이 됐다. 커리어에 어느 지점이건 늘 3가지 단계를 기억하자. 나는 지금 어느 단계에 있을까.

#PM학개론

1. PM/PO 커리어는 3개의 단계로 나눠 생각해 볼 수 있다. 그 세가지는 일을 할 때 거치는 3단계와도 같다. 일의 3단계는 무얼까. ​2. Why -&gt; What -&gt; How. 모든 일은 이 3가지 단계를 거친다. 프로덕트도 마찬가지다. 3. 첫 번째는 Why다. 그 일이 존재하는 이유다. 프로덕트와 기능으로 하고 싶은 궁극적인 이유다. 무엇을 할 것인가? 왜 해야 하는가. 왜 하고 싶은가. 꼭 해야 하는지. 그 목적은 무언가. 또, 목표는 무언가. 성공 여부는 무엇으로 판단할 수 있나. 4. Why는 우리가 일할 때 잘 보이지 않는다. 그래서 정말 중요하다. 보이지 않기에 쉽게 잊는다. 위험하다. 특히 제품을 만들다 보면, 만드는 일 자체에 매몰된다. 왜 이걸 만들고 있는지 잊는다. 목적을 잊는다면 수단이 목적이 된다. 늘 경계해야 한다. ​5. 두 번째는 What이다. What은 사용자에게 전달되는 프로덕트/기능 자체다. Why를 어떻게 달성할 수 있을까. 목적을 달성할 수 있는 수단은 항상 많다. 너무 많아서 문제다. ​6. 확산과 수렴이 필요하다. 가능한 방법을 리스트 업한다. 마음껏 넓혀서 확장한다. 이후에는 좁혀간다. 지우고 합친다. 우선순위를 정해본다. 최종적으로 가장 적합한 What을 결정한다. ​7. 이제 마지막으로 How다. 그 What을 어떻게 만들 것인가. 마찬가지로 만들 수 있는 방법은 다양하다. 이 기능을 어떻게 구현하면 좋을까. ​8. 쓸 수 있는 시간과 자원을 고려해 본다. 기술을 효과적으로 쓸 수 있는 방법과 제약도 검토한다. 때로는 제품이 아닌 정책 변경 같은 방법이 가장 효율적일 때도 있다. 망치를 들고 있으면 못만 보이는 법이다. 필요 없는 일을 효율적으로 한다고 가치가 생기진 않는다. Why의 해결/달성이 궁극적인 목표인 걸 늘 기억해야 한다. ​9. 프로덕트를 만드는 3단계를 살펴봤다. PM/PO의 커리어는 정확히 이 순서의 반대로 진행된다. ​10. 먼저 주니어다. 주니어 때는 How에 집중하는 기간이다. 만들어야 할 제품과 기능은 대부분 이미 정해져있다. 해야 할 일은 누구와 함께 그것을 잘 만들어내는 일이다. ​11. 디자이너, 엔지니어, QA 등 메이커들을 이끌어 What을 만든다. 출시까지 발생하는 이슈들을 해결한다. 이후에 지표와 고객의 반응을 확인하고 분석한다. 프로덕트 관리와 프로젝트 관리가 혼재되어 있다. ​12. 중니어, 미들급은 What에 집중하는 기간이다. How는 충분히 익혔기에 목표를 달성할 수 있는 제품과 기능을 고민하게 된다. ​13. 사업적인 요구사항은 Why다. 그 목적을 달성할 수 있는 가장 좋은 프로덕트/기능은 무엇일까. 이 질문에 답을 찾는다. ​14. 먼저 사업적인 이해가 필요하다. 그리고 구체적인 제품의 모습을 그린다. 최종적으로 사용할 고객의 모습을 상상한다. How 단계의 구현까지도 염두에 둔다. 이 모든 걸 종합해서 만들 제품/기능을 정의한다. 15. 마지막으로 시니어/C레벨의 단계는 Why다. What/How는 도구다. 사용할 수 있는 무기와 같다. 이 무기를 기반으로 해야 할 일, 목적을 정의한다. ​16. 프로덕트의 What/How의 경험을 기반으로 가치를 만들어낼 일, Why를 만든다. 이 가치를 수익과 바꿀 수 있는 시장과 고객을 찾는 게 결국 사업이다. 프로덕트/플랫폼 기반의 사업을 리딩하고 실행한다. Why를 What/How 레벨에 잘 전달하는 것도 중요한 역할이다. ​17. 일은 Why -&gt; What -&gt; How 순서다. 우리가 거치는 커리어는 그 반대다. How -&gt; What -&gt; Why 순으로 성장해간다. 지금 어떤 일을 하건 이 3가지 단계로 생각해 보는 건 중요하다. ​18. 주니어 시절에 늘 답답했다. Why가 보이지 않았기 때문이다. 내가 하고 있는 이 일은 무엇을 위해서일까. 왜 이 일을 해야 하는 걸까. 아무도 알려주지 않았고, 알 수 없었다. 그저 막연히 상상해 볼 수밖에. ​19. 그런 답답함에서 오는 막막한 상상들이 성장에는 큰 도움이 됐다. 비록 정답을 생각할 수는 없었다. 하지만 그렇게 Why를 생각해보는 연습이 넓은 관점을 갖는데 도움이 됐다. 커리어에 어느 지점이건 늘 3가지 단계를 기억하자. 나는 지금 어느 단계에 있을까. #PM학개론

< PM/PO 커리어 3단계: 당신은 How, What, Why

뉴시스 창사 23주년 '10년 후 한국' 포럼서 '기업 시대정신' 강연 "사람은 정서로 움직여…머리보다 가슴 지향하는 문화 만들어야"

박웅현 TBWA 조직문화연구소장 "모든 직원은 고객, '회사 팬' 만들어야" [뉴시스 포럼-10년후 한국]

“직원들에게 월급 외에 출근할 이유를 줘야 합니다. 팀장이 좋다던가, 이 일이 날 성장시킨다던가, 이 일이 좋다던가, 이게 다 여기에 해당합니다.“ 박웅현 TBWA 코리아 조직문화연구소 소장은 직원들을 조직에 남게하는 방법을 이렇게 제안했다.

공감의 조직문화를 이야기한 박 소장은 “이런 것들은 모두 우리의 심장 부분에 해당한다. 사람은 객관적인 팩트로 움직이지 않고, 정서로 움직이기 때문이다. 우리는 이제까지 너무 머리를 지향했다. 사람이 어떻게 움직이는지 잘 생각해봐야 하는데, 사람은 유기체이고 가슴으로 움직인다.”라고 말했다.

박 소장은 “공감은 함께 느낀다는 말”이라며 “리더들은 공감을 어떻게 할지, 어떻게 감정을 밀어 넣을지, 어떻게 그 사람 입장이 될지 고민해야 한다.”며 공감에 바탕을 둔 조직문화의 중요성을 강조했다.

광고회사인 TBWA가 경쟁PT에서 여러 차례 고배를 마셨던 사례도 이야기했다. 그는 “광고회사는 경쟁PT로 먹고산다. 한번은 10번을 연달아 PT에서 떨어진 적이 있는데, 회사 긴장도가 많이 높아졌다.”고 회상했다.

“15회쯤 실패가 반복되니까 서로를 탓하는 문화가 생겼는데, 결국엔 20연패가 됐다. 그쯤 되니 업계에 ‘거긴 이제 별로’라고 소문이 나는 게 무서웠다.”고 말했다.

그때 박 소장은 분위기를 반전시키기 위해, 일본 후쿠오카에 팀장들과 워크숍을 가는 안을 냈다. 평소처럼 서울 근교로 1박2일 워크샵을 떠나자고 하면 “자아비판을 하라는 거냐!”며 불만이 나올 수 있었기 때문이다.

그 다음엔 태스크포스를 만들어 어떻게 분위기를 반전시키고 이 사람들을 웃게 만들지 고민했다. 실제로 그는 워크숍 첫날 미술팀과 <TBWA 묘비>를 만들었다. 팀장들에겐 흰 국화를 들고 오게 해서 <TBWA 장례식>을 치렀다.

여기저기서 웃음이 터졌고, 이날 찍은 사진들이 몇몇 참가자들의 SNS에 올라갔다. TBWA가 이 위기를 심각하게 받아들이지 않는다는 메시지를 외부에 전달하기 위해서다.

박 소장은 ”그 다음엔 업무 얘기를 전혀 안 하고, 팀장들과 후쿠오카를 돌아다니면서 술을 마시고 잤다. 다음날 회의도 일부러 비교적 늦은 오전 10시에 시작했다“고 회상했다.

다음 날 회의실은 생일파티처럼 꾸몄다. 여기저기 풍선을 띄우고, 팀장들에겐 미리 나눠준 샴페인을 들고 오게 했다. TBWA가 다시 태어난 생일이라는 의미였다.

그제야 팀장들은 이구동성으로 ‘우리가 떨고 있다’고 말했다. 광고주들의 취향을 지나치게 맞추고 눈치 보느라 TBWA가 원하는 것을 하지 못하고 있다는 지적이었다.

박 소장은 “전략 대신 정서를 이야기했고, 무엇을 전달할지보다는 어떻게 전달할지 고민했다. 팩트보다는 분위기를 파악하고, 머리보다는 가슴을 지향했다.”고 설명했다.

마지막으로 박웅현 소장은 “회사는 직원을 우리 회사의 팬으로 만드는 문화를 갖춰야 한다.”고 강조했다. 우리 회사의 직원은 고객이지, 관리의 대상이 아니다. 회사의 철학을 이해하고, 공감하고, 이를 자발적으로 퍼뜨려야 하는 가장 중요한 고객이다.

“직원들에게 월급 외에 출근할 이유를 줘야 합니다. 팀장이 좋다던가, 이 일이 날 성장시킨다던가, 이 일이 좋다던가, 이게 다 여기에 해당합니다.“ 박웅현 TBWA 코리아 조직문화연구소 소장은 직원들을 조직에 남게하는 방법을 이렇게 제안했다. 공감의 조직문화를 이야기한 박 소장은 “이런 것들은 모두 우리의 심장 부분에 해당한다. 사람은 객관적인 팩트로 움직이지 않고, 정서로 움직이기 때문이다. 우리는 이제까지 너무 머리를 지향했다. 사람이 어떻게 움직이는지 잘 생각해봐야 하는데, 사람은 유기체이고 가슴으로 움직인다.”라고 말했다. 박 소장은 “공감은 함께 느낀다는 말”이라며 “리더들은 공감을 어떻게 할지, 어떻게 감정을 밀어 넣을지, 어떻게 그 사람 입장이 될지 고민해야 한다.”며 공감에 바탕을 둔 조직문화의 중요성을 강조했다. 광고회사인 TBWA가 경쟁PT에서 여러 차례 고배를 마셨던 사례도 이야기했다. 그는 “광고회사는 경쟁PT로 먹고산다. 한번은 10번을 연달아 PT에서 떨어진 적이 있는데, 회사 긴장도가 많이 높아졌다.”고 회상했다. “15회쯤 실패가 반복되니까 서로를 탓하는 문화가 생겼는데, 결국엔 20연패가 됐다. 그쯤 되니 업계에 ‘거긴 이제 별로’라고 소문이 나는 게 무서웠다.”고 말했다. 그때 박 소장은 분위기를 반전시키기 위해, 일본 후쿠오카에 팀장들과 워크숍을 가는 안을 냈다. 평소처럼 서울 근교로 1박2일 워크샵을 떠나자고 하면 “자아비판을 하라는 거냐!”며 불만이 나올 수 있었기 때문이다. 그 다음엔 태스크포스를 만들어 어떻게 분위기를 반전시키고 이 사람들을 웃게 만들지 고민했다. 실제로 그는 워크숍 첫날 미술팀과 &lt;TBWA 묘비&gt;를 만들었다. 팀장들에겐 흰 국화를 들고 오게 해서 &lt;TBWA 장례식&gt;을 치렀다. 여기저기서 웃음이 터졌고, 이날 찍은 사진들이 몇몇 참가자들의 SNS에 올라갔다. TBWA가 이 위기를 심각하게 받아들이지 않는다는 메시지를 외부에 전달하기 위해서다. 박 소장은 ”그 다음엔 업무 얘기를 전혀 안 하고, 팀장들과 후쿠오카를 돌아다니면서 술을 마시고 잤다. 다음날 회의도 일부러 비교적 늦은 오전 10시에 시작했다“고 회상했다. 다음 날 회의실은 생일파티처럼 꾸몄다. 여기저기 풍선을 띄우고, 팀장들에겐 미리 나눠준 샴페인을 들고 오게 했다. TBWA가 다시 태어난 생일이라는 의미였다. 그제야 팀장들은 이구동성으로 ‘우리가 떨고 있다’고 말했다. 광고주들의 취향을 지나치게 맞추고 눈치 보느라 TBWA가 원하는 것을 하지 못하고 있다는 지적이었다. 박 소장은 “전략 대신 정서를 이야기했고, 무엇을 전달할지보다는 어떻게 전달할지 고민했다. 팩트보다는 분위기를 파악하고, 머리보다는 가슴을 지향했다.”고 설명했다. 마지막으로 박웅현 소장은 “회사는 직원을 우리 회사의 팬으로 만드는 문화를 갖춰야 한다.”고 강조했다. 우리 회사의 직원은 고객이지, 관리의 대상이 아니다. 회사의 철학을 이해하고, 공감하고, 이를 자발적으로 퍼뜨려야 하는 가장 중요한 고객이다.

뉴시스

“직원들에게 월급 외에 출근할 이유를 줘야 합니다. 팀장이 좋다던

﻿
어제 뉴스에서 대통령이 주재한 국무회의 장면을 보았습니다. 회의 모두발언에서 대통령이 국무위원들에게 전한 말씀이 인상 깊었습니다. 핵심은 행정 제도를 만들거나 개선할 때, 제도의 수요자인 국민들이 어떻게 생각하고 받아들일지를 먼저 고려해야 한다는 것이었습니다.

행정을 담당하는 사람들이 일방적으로 제도를 설계해 발표하는 방식은 편리할 수 있지만, 국민들의 입장을 반영하지 않으면 실질적인 효과를 기대하기 어렵습니다. 제도의 수용성과 실효성을 높이려면, 실제로 그 제도를 적용받는 사람들의 목소리를 듣고 반영하는 과정이 반드시 필요합니다.

이러한 관점은 기업이 제품이나 서비스를 만들 때 사용자 중심으로 설계하는 접근과 닮아 있습니다. 대통령은 행정에서도 이처럼 국민 중심의 사고가 필요하다고 강조했습니다. 즉, 제도의 최종 사용자에게 의미 있고 필요한 방향으로 설계되어야 비로소 수용성이 높아진다는 것입니다.

우리가 업무를 수행할 때도 마찬가지입니다. 머릿속으로 상상한 결과물을 빠르게 만들어내는 것이 효율적으로 보일 수 있지만, 그 결과물이 실제 대상자에게 도움이 되지 않는다면 의미가 없습니다. 서로의 입장을 깊이 이해하지 않고 일방적으로 추진된 결과는 시행착오로 이어질 가능성이 큽니다.

저도 커리어 코칭을 하면서 이러한 교훈을 다시금 되새깁니다. 때때로 저는 코칭을 받는 사람의 입장을 깊이 이해하기보다, 제가 준비한 내용을 먼저 전달하려는 경향이 있습니다. 하지만 진정한 도움이 되려면, 상대의 고민과 필요를 먼저 듣고 그에 맞게 응답해야 합니다. 그게 진정한 코칭이고, 효과적인 소통입니다.

대통령은 과거 배고픈 시절에는 밥을 주는 것만으로도 감사함을 받았지만, 지금은 왜 밥을 주는지 그 이유와 목적을 설명해야 납득을 얻을 수 있다고 말했습니다. 이 말이 참 와닿았습니다. 요즘처럼 정보와 선택지가 넘쳐나는 시대에는 단순히 '주는 것'만으로는 감동을 주기 어렵습니다. 무엇을 주는지가 아니라, 왜 주는지가 중요한 시대입니다.

이력서도 마찬가지입니다. 아무리 화려한 경력을 적더라도, 입사 동기와 기업에 대한 관심이 담겨 있지 않으면 설득력을 잃습니다. 채용 담당자가 원하는 것은 단순한 정보가 아니라, 지원자가 왜 우리 회사에 오고 싶은지를 납득할 수 있는 설명입니다.

우리의 모든 행동은 누군가에게 영향을 줍니다. 아침에 눈을 떠 시작하는 하루가 나와 주변 사람들에게 어떤 영향을 줄지 생각해 보아야 합니다. 의미 없이 반복되는 행동은 소중한 시간을 낭비하게 만듭니다. 그러나 생각을 담고, 목적을 이해하며 실천하는 행동은 스스로와 타인에게 긍정적인 파장을 만들어냅니다.

대통령은 자신의 한 시간을 국민 5,200만 명을 위한 시간으로 여겨야 한다고 했습니다. 그만큼 모든 시간을 의미 있게 사용하라는 뜻입니다. 우리도 마찬가지입니다. 내 행동이 한 사람에게라도 영향을 줄 수 있다면, 그 한 사람을 위해서라도 진지하고 성실하게 임해야 합니다.
그런 의미 있는 행동과 생각을 할 줄 아는 우리가 되길, 진심으로 응원합니다.

﻿어제 뉴스에서 대통령이 주재한 국무회의 장면을 보았습니다. 회의 모두발언에서 대통령이 국무위원들에게 전한 말씀이 인상 깊었습니다. 핵심은 행정 제도를 만들거나 개선할 때, 제도의 수요자인 국민들이 어떻게 생각하고 받아들일지를 먼저 고려해야 한다는 것이었습니다. 행정을 담당하는 사람들이 일방적으로 제도를 설계해 발표하는 방식은 편리할 수 있지만, 국민들의 입장을 반영하지 않으면 실질적인 효과를 기대하기 어렵습니다. 제도의 수용성과 실효성을 높이려면, 실제로 그 제도를 적용받는 사람들의 목소리를 듣고 반영하는 과정이 반드시 필요합니다. 이러한 관점은 기업이 제품이나 서비스를 만들 때 사용자 중심으로 설계하는 접근과 닮아 있습니다. 대통령은 행정에서도 이처럼 국민 중심의 사고가 필요하다고 강조했습니다. 즉, 제도의 최종 사용자에게 의미 있고 필요한 방향으로 설계되어야 비로소 수용성이 높아진다는 것입니다. 우리가 업무를 수행할 때도 마찬가지입니다. 머릿속으로 상상한 결과물을 빠르게 만들어내는 것이 효율적으로 보일 수 있지만, 그 결과물이 실제 대상자에게 도움이 되지 않는다면 의미가 없습니다. 서로의 입장을 깊이 이해하지 않고 일방적으로 추진된 결과는 시행착오로 이어질 가능성이 큽니다. 저도 커리어 코칭을 하면서 이러한 교훈을 다시금 되새깁니다. 때때로 저는 코칭을 받는 사람의 입장을 깊이 이해하기보다, 제가 준비한 내용을 먼저 전달하려는 경향이 있습니다. 하지만 진정한 도움이 되려면, 상대의 고민과 필요를 먼저 듣고 그에 맞게 응답해야 합니다. 그게 진정한 코칭이고, 효과적인 소통입니다. 대통령은 과거 배고픈 시절에는 밥을 주는 것만으로도 감사함을 받았지만, 지금은 왜 밥을 주는지 그 이유와 목적을 설명해야 납득을 얻을 수 있다고 말했습니다. 이 말이 참 와닿았습니다. 요즘처럼 정보와 선택지가 넘쳐나는 시대에는 단순히 '주는 것'만으로는 감동을 주기 어렵습니다. 무엇을 주는지가 아니라, 왜 주는지가 중요한 시대입니다. 이력서도 마찬가지입니다. 아무리 화려한 경력을 적더라도, 입사 동기와 기업에 대한 관심이 담겨 있지 않으면 설득력을 잃습니다. 채용 담당자가 원하는 것은 단순한 정보가 아니라, 지원자가 왜 우리 회사에 오고 싶은지를 납득할 수 있는 설명입니다. 우리의 모든 행동은 누군가에게 영향을 줍니다. 아침에 눈을 떠 시작하는 하루가 나와 주변 사람들에게 어떤 영향을 줄지 생각해 보아야 합니다. 의미 없이 반복되는 행동은 소중한 시간을 낭비하게 만듭니다. 그러나 생각을 담고, 목적을 이해하며 실천하는 행동은 스스로와 타인에게 긍정적인 파장을 만들어냅니다. 대통령은 자신의 한 시간을 국민 5,200만 명을 위한 시간으로 여겨야 한다고 했습니다. 그만큼 모든 시간을 의미 있게 사용하라는 뜻입니다. 우리도 마찬가지입니다. 내 행동이 한 사람에게라도 영향을 줄 수 있다면, 그 한 사람을 위해서라도 진지하고 성실하게 임해야 합니다.그런 의미 있는 행동과 생각을 할 줄 아는 우리가 되길, 진심으로 응원합니다.﻿

결과보다 과정을

design by 슝슝 (w/ChatGPT) 아래 글은 2025년 06월 11일에 발행된 뉴스레터에 실린 글입니다.전체 뉴스레터를 보시려면 옆의 링크를 클릭하시면 됩니다. [뉴스레

네이버플러스 스토어가 쿠팡고객을 데려왔다는 건에 대하여

진짜 중요한 건 ‘유입 수’가 아닌 ‘단독 이용률’과 ‘사용 시간’입니다

[아티클 3문장 요약📑]

1️⃣ 최근 네이버플러스 스토어 앱이 급성장 중이라는 기사가 쏟아지고 있는데, 특히 이들이 모은 고객 중 상당수가 쿠팡에서 유입된 것으로 나타났는 점을 강조하며, 쿠팡을 위협한다거나 네이버가 쿠팡 고객을 움직이게 했다는 식의 이야기가 많이 들려오고 있죠.

2️⃣ 하지만 이는 제대로 해석이 필요한 지표로, 실제 네이버플러스 스토어 앱으로 유입된 신규 사용자의 83.1%는 이전 달에 쿠팡 앱을 이용했던 고객들은 맞지만, 이는 고객을 뺏어 왔다는 뜻이 아니라, 단지 이들이 쿠팡 이용 이력이 있다는 걸 말하고, 더욱이 쇼핑 카테고리 앱을 사용하는 사람 10명 중 8명은 어차피 쿠팡 고객이라는 점에서 사실 당연한 숫자라 봐야 합니다.

3️⃣ 따라서 이보다 더 중요한 건 '업종 내 단독 사용률'로 해당 앱만 쓰는 고객을 모아야 정말 쿠팡을 위협한다고 볼 수 있을 텐데, 문제는 쿠팡 앱의 단독 사용률은 무려 48.0%로 절반 가까이 되며 네이버플러스 스토어 앱은 6.5%에 불과하기에, 아마 네이버가 정말 쿠팡을 따라 잡으려면 아직 갈 길이 멀어 보이네요.

💡기묘한 관점➕
이제 커머스 플랫폼간 경쟁에서 가장 중요한 건 사용자 수가 아니라 사용 시간을 점유하는 겁니다. 사용 시간 점유율을 높여 가다 보면 언젠가는 사람ㄷ 데려올 수 있기 때문이죠. 특히 네이버플러스 스토어는 발견형 쇼핑을 주창하고 있기에, 이러한 체류 시간 지표가 더욱 중요할 수밖에 없는데요. 이러한 지표의 성장세가 최근 둔화되고 있어서, 확실히 다른 대안이 필요해 보입니다. 그래야 정말 쿠팡의 경쟁자라 불릴만한 자격을 갖출 수 있을 거고요.

🥤트렌드라이트 구독하기
https://m.site.naver.com/1Ew5V

진짜 중요한 건 ‘유입 수’가 아닌 ‘단독 이용률’과 ‘사용 시간’입니다 [아티클 3문장 요약📑] 1️⃣&nbsp;최근 네이버플러스 스토어 앱이 급성장 중이라는 기사가 쏟아지고 있는데, 특히 이들이 모은 고객 중 상당수가 쿠팡에서 유입된 것으로 나타났는 점을 강조하며, 쿠팡을 위협한다거나 네이버가 쿠팡 고객을 움직이게 했다는 식의 이야기가 많이 들려오고 있죠. 2️⃣&nbsp;하지만 이는 제대로 해석이 필요한 지표로, 실제 네이버플러스 스토어 앱으로 유입된 신규 사용자의 83.1%는 이전 달에 쿠팡 앱을 이용했던 고객들은 맞지만, 이는 고객을 뺏어 왔다는 뜻이 아니라, 단지 이들이 쿠팡 이용 이력이 있다는 걸 말하고, 더욱이 쇼핑 카테고리 앱을 사용하는 사람 10명 중 8명은 어차피 쿠팡 고객이라는 점에서 사실 당연한 숫자라 봐야 합니다. 3️⃣&nbsp;따라서 이보다 더 중요한 건 '업종 내 단독 사용률'로 해당 앱만 쓰는 고객을 모아야 정말 쿠팡을 위협한다고 볼 수 있을 텐데, 문제는 쿠팡 앱의 단독 사용률은 무려 48.0%로 절반 가까이 되며 네이버플러스 스토어 앱은 6.5%에 불과하기에, 아마 네이버가 정말 쿠팡을 따라 잡으려면 아직 갈 길이 멀어 보이네요. 💡기묘한 관점➕이제 커머스 플랫폼간 경쟁에서 가장 중요한 건 사용자 수가 아니라 사용 시간을 점유하는 겁니다. 사용 시간 점유율을 높여 가다 보면 언젠가는 사람ㄷ 데려올 수 있기 때문이죠. 특히 네이버플러스 스토어는 발견형 쇼핑을 주창하고 있기에, 이러한 체류 시간 지표가 더욱 중요할 수밖에 없는데요. 이러한 지표의 성장세가 최근 둔화되고 있어서, 확실히 다른 대안이 필요해 보입니다. 그래야 정말 쿠팡의 경쟁자라 불릴만한 자격을 갖출 수 있을 거고요. 🥤트렌드라이트 구독하기https://m.site.naver.com/1Ew5V

www.openads.co.kr

🔍네이버가 쿠팡 고객을 데려왔다고? 팩트 체크해 봤습니다

1. 젠슨 황은 항상 뛰어난 학생이었다. 하지만 다른 사람들과 사회적으로 상호작용하는 법을 배우기란 쉽지 않았다.

2. 젠슨 황은 말했다. “저는 굉장히 내성적인 성격이었어요. 말도 안 되게 수줍음을 탔죠. (그런데) 데니스 패밀리 레스토랑에서 웨이터로 일한 경험이 그 단단한 벽을 무너뜨리는 데 도움이 됐어요”

3. 젠슨 황이 15살일 때 그의 형은 포틀랜드에 있는 데니스 패밀리 레스토랑의 일자리를 소개해줬다. 젠슨 황은 고등학교, 대학생 시절, 몇 번의 여름 방학을 이 식당에서 일을 하며 보냈다. 젠슨 황은 항상 그랬듯, 설거지나 화장실 청소 같은 궂은일부터 시작했다.

4. 젠슨 황은 데니스에서 일한 경험 덕분에 여러 중요한 인생 기술을 배웠다고 말했다. 혼란한 상황에서도 계속 일에 집중하는 법, 시간 압박을 받으며 일하는 법, 고객과 소통하는 법, 실수를 해결하는 법 등을 익혔다.

5. 뿐만 아니라, 아무리 사소한 일이라도 자신의 업무를 잘 해내는 것에서 만족감을 느끼는 법과 가능한 최고의 기준에 맞춰 그 일을 해내는 법을 배웠다. 그는 당시 자신이 매순간 최선을 다했다고 회상한다.

6. (한편) 알로하 고등학교에 다니는 동안 그는 수학, 과학, 컴퓨터 동아리에서 친구들을 사귀었다. 모든 쉬는 시간을 쏟아 애플 2 컴퓨터에서 BASIC 프로그램을 하거나, 텔레타이프 터미널로 게임을 했다.

7. 그러다 비디오 게임과 사랑에 빠졌다. 특히 그는 <스타트렉>을 좋아했다. 또한 그는 아케이드 게임인 <아스테로이즈>, <갤럭시안>과 같은 게임에 많은 시간을 썼다.

8. (게임을 많이 했지만, 성적도 좋았던) 젠슨 황은 졸업한 후 미국에서 가장 큰 반도체 칩 제조회사들로부터 구애를 받았다. 처음에는 미국 전역에 있는 ‘텍사스 인스트루먼츠’에 가려고 했지만, 면접을 망쳐서 합격 통보를 받지 못했다.

9. 이후, 그는 캘리포니아에 기반을 둔 두 회사에 면접을 봤다. ‘AMD’와 ‘LSI 로직’이었다. 두 회사 모두에 합격했으나 자신이 보기에 사람들에게 더 잘 알려진 AMD를 선택했다. 그러고는 낮에는 AMD에서 일하고, 밤과 주말에는 스탠퍼드 대학교에서 진기공학 석사학위 과정을 밟았다.

10. 마침내 8년 만에 그는 석사학위 과정을 마쳤다. 젠슨 황은 말했다. “저는 대단히 장기적인 관점을 가지고 있어요. 물론 어떤 것들에 대해서는 참을성이 없지만, 그 외의 것들에 대해선 무한히 인내심을 가지는 스타일이죠. 포기하지 않고 꾸준히 하는 게 바로 접니다”

11. (그러는 사이) 젠슨 황의 야망은 커졌다. 분명 그는 AMB에서 마이크로칩 설계 업무를 잘 해내고 있었지만, 어느 순간부터 그 일이 지루하게 느껴졌다. 당시 마이크로칩 설계는 여전히 수작업으로 하나하나 이루어졌기 때문이다.

12. 그러던 중 동료 중 한 명이 LSI로 이직하면서 젠슨 황에게도 함께 갈 것을 권유했다. 젠슨 황은 LSI가 칩 설계 과정을 훨씬 더 빠르고 더 쉽게 바꿀 혁신적인 소프트웨어 도구를 개발한다는 소문을 듣고, 그 아이디어에 흥미를 느꼈다.

13. 리스크를 감수해야 하는 일이었지만, 그는 반도체 사업의 미래를 제대로 아는 것처럼 보이는 회사에서 일해야 한다고 생각했다.

14. 그는 결단을 내렸고, LSI에 합류해 고객사에서 고객과 함께 일하는 기술직 역할을 맡았다. 젠슨 황은 ‘썬마이크로시스템즈’라는 당시 스타트업 고객사에 배정되었는데, 그곳에서 두 명의 인물을 만났다. 바로, 엔지니어인 ‘커티스 프리엠’과 ‘크리스 말라초프스키’다.

15. (이후, 이 세 사람은 엔비디아를 만들었다)

- 태 킴, <엔비디아 레볼루션> 중

1. 젠슨 황은 항상 뛰어난 학생이었다. 하지만 다른 사람들과 사회적으로 상호작용하는 법을 배우기란 쉽지 않았다. 2. 젠슨 황은 말했다. “저는 굉장히 내성적인 성격이었어요. 말도 안 되게 수줍음을 탔죠. (그런데) 데니스 패밀리 레스토랑에서 웨이터로 일한 경험이 그 단단한 벽을 무너뜨리는 데 도움이 됐어요” 3. 젠슨 황이 15살일 때 그의 형은 포틀랜드에 있는 데니스 패밀리 레스토랑의 일자리를 소개해줬다. 젠슨 황은 고등학교, 대학생 시절, 몇 번의 여름 방학을 이 식당에서 일을 하며 보냈다. 젠슨 황은 항상 그랬듯, 설거지나 화장실 청소 같은 궂은일부터 시작했다. 4. 젠슨 황은 데니스에서 일한 경험 덕분에 여러 중요한 인생 기술을 배웠다고 말했다. 혼란한 상황에서도 계속 일에 집중하는 법, 시간 압박을 받으며 일하는 법, 고객과 소통하는 법, 실수를 해결하는 법 등을 익혔다. 5. 뿐만 아니라, 아무리 사소한 일이라도 자신의 업무를 잘 해내는 것에서 만족감을 느끼는 법과 가능한 최고의 기준에 맞춰 그 일을 해내는 법을 배웠다. 그는 당시 자신이 매순간 최선을 다했다고 회상한다. 6. (한편) 알로하 고등학교에 다니는 동안 그는 수학, 과학, 컴퓨터 동아리에서 친구들을 사귀었다. 모든 쉬는 시간을 쏟아 애플 2 컴퓨터에서 BASIC 프로그램을 하거나, 텔레타이프 터미널로 게임을 했다. 7. 그러다 비디오 게임과 사랑에 빠졌다. 특히 그는 &lt;스타트렉&gt;을 좋아했다. 또한 그는 아케이드 게임인 &lt;아스테로이즈&gt;, &lt;갤럭시안&gt;과 같은 게임에 많은 시간을 썼다. 8. (게임을 많이 했지만, 성적도 좋았던) 젠슨 황은 졸업한 후 미국에서 가장 큰 반도체 칩 제조회사들로부터 구애를 받았다. 처음에는 미국 전역에 있는 ‘텍사스 인스트루먼츠’에 가려고 했지만, 면접을 망쳐서 합격 통보를 받지 못했다. 9. 이후, 그는 캘리포니아에 기반을 둔 두 회사에 면접을 봤다. ‘AMD’와 ‘LSI 로직’이었다. 두 회사 모두에 합격했으나 자신이 보기에 사람들에게 더 잘 알려진 AMD를 선택했다. 그러고는 낮에는 AMD에서 일하고, 밤과 주말에는 스탠퍼드 대학교에서 진기공학 석사학위 과정을 밟았다. 10. 마침내 8년 만에 그는 석사학위 과정을 마쳤다. 젠슨 황은 말했다. “저는 대단히 장기적인 관점을 가지고 있어요. 물론 어떤 것들에 대해서는 참을성이 없지만, 그 외의 것들에 대해선 무한히 인내심을 가지는 스타일이죠. 포기하지 않고 꾸준히 하는 게 바로 접니다” 11. (그러는 사이) 젠슨 황의 야망은 커졌다. 분명 그는 AMB에서 마이크로칩 설계 업무를 잘 해내고 있었지만, 어느 순간부터 그 일이 지루하게 느껴졌다. 당시 마이크로칩 설계는 여전히 수작업으로 하나하나 이루어졌기 때문이다. 12. 그러던 중 동료 중 한 명이 LSI로 이직하면서 젠슨 황에게도 함께 갈 것을 권유했다. 젠슨 황은 LSI가 칩 설계 과정을 훨씬 더 빠르고 더 쉽게 바꿀 혁신적인 소프트웨어 도구를 개발한다는 소문을 듣고, 그 아이디어에 흥미를 느꼈다. 13. 리스크를 감수해야 하는 일이었지만, 그는 반도체 사업의 미래를 제대로 아는 것처럼 보이는 회사에서 일해야 한다고 생각했다. 14. 그는 결단을 내렸고, LSI에 합류해 고객사에서 고객과 함께 일하는 기술직 역할을 맡았다. 젠슨 황은 ‘썬마이크로시스템즈’라는 당시 스타트업 고객사에 배정되었는데, 그곳에서 두 명의 인물을 만났다. 바로, 엔지니어인 ‘커티스 프리엠’과 ‘크리스 말라초프스키’다. 15. (이후, 이 세 사람은 엔비디아를 만들었다) - 태 킴, &lt;엔비디아 레볼루션&gt; 중

젠슨 황은 어떻게 커리어를 쌓았나

태초에 모든 동물은 바다에서 살았다. 바다가 동물이 살기 좋은 환경이었던 것이다. 그런데, 동물 사이에 먹이 사슬이 형성되었고, 힘이 없는 동물들은 척박한 곳으로 밀려났다. 그곳이 바로 강이다. 처음에는 강에서 살기 힘들었지만, 성공적으로 적응하는 동물들이 생겨났고, 그래서 강에도 생태계가 형성되었다.

생태계가 형성되자 그곳에서도 강자와 약자가 구분되었다. 그리고 약자들은 또다시 척박한 곳으로 밀려났다. 그곳이 바로 육지다. 역시 오랜 시간을 거쳐 육지에 적응하는 동물들이 생겨났고, 육지에도 새로운 생태계가 형성되었다.

이런 진화 과정은 육지에서도 반복된다. 부족한 산소를 극복하는 과정에서 공룡과 포유류가 탄생했다. 생존을 위한 노력 속에서 어떤 동물은 하늘을 날게 되었고, 어떤 동물은 도구를 사용하게 되었다.

비단 진화 과정에서만 볼 수 있는 일은 아니다. 인류의 역사를 들여다봐도 어려운 환경을 극복하는 과정에서 강자가 된 사례가 넘쳐나고, 현대의 비즈니스에서도 종종 이런 사례가 목격된다. 그러니까 타고난 능력도 좋지만, 더 중요한 건 ‘고난을 극복하며 얻은 강인함’인 것이다. 고난을 통해 얻은 강인함이야말로, 치열한 경쟁 속에서 살아남고, 나아가 승자가 되도록 만들어 주는 원동력이 된다.

#고난 #커리어 #인생

태초에 모든 동물은 바다에서 살았다. 바다가 동물이 살기 좋은 환경이었던 것이다. 그런데, 동물 사이에 먹이 사슬이 형성되었고, 힘이 없는 동물들은 척박한 곳으로 밀려났다. 그곳이 바로 강이다. 처음에는 강에서 살기 힘들었지만, 성공적으로 적응하는 동물들이 생겨났고, 그래서 강에도 생태계가 형성되었다. 생태계가 형성되자 그곳에서도 강자와 약자가 구분되었다. 그리고 약자들은 또다시 척박한 곳으로 밀려났다. 그곳이 바로 육지다. 역시 오랜 시간을 거쳐 육지에 적응하는 동물들이 생겨났고, 육지에도 새로운 생태계가 형성되었다. 이런 진화 과정은 육지에서도 반복된다. 부족한 산소를 극복하는 과정에서 공룡과 포유류가 탄생했다. 생존을 위한 노력 속에서 어떤 동물은 하늘을 날게 되었고, 어떤 동물은 도구를 사용하게 되었다. 비단 진화 과정에서만 볼 수 있는 일은 아니다. 인류의 역사를 들여다봐도 어려운 환경을 극복하는 과정에서 강자가 된 사례가 넘쳐나고, 현대의 비즈니스에서도 종종 이런 사례가 목격된다. 그러니까 타고난 능력도 좋지만, 더 중요한 건 ‘고난을 극복하며 얻은 강인함’인 것이다. 고난을 통해 얻은 강인함이야말로, 치열한 경쟁 속에서 살아남고, 나아가 승자가 되도록 만들어 주는 원동력이 된다. #고난 #커리어 #인생

고난이 사람을 키운다

With the design overhaul that's coming this year, Apple plans to rename all of its operating systems, reports Bloomberg. Going forward, iOS,...

No iOS 19: Apple Going Straight to iOS 26

매년 iOS 버전은 하나씩 업데이트 되고 있습니다.
그러다보니 현재는 iOS 18이 최신인데, 올해부터는 연도를 나타내는 iOS 26으로 바뀔거라는 소식이 있어요 😃

사실 연도를 따라가면 헷갈리지 않아서 좋긴한데, 조금 더 나아가서 Xcode, iPhone OS 버전들도 같이 통일해주면 더 헷갈리지 않을것 같습니다.
개발할 때 매번 이 세가지의 버전이 늘 헷갈리더라구요.

그러면, Xcode 몇 버전에서는 최신 iOS 몇 버전까지 지원되고 그런것들에서 해방될 수 있지 않을까 생각해봅니다 ☺️

매년 iOS 버전은 하나씩 업데이트 되고 있습니다.그러다보니 현재는 iOS 18이 최신인데, 올해부터는 연도를 나타내는 iOS 26으로 바뀔거라는 소식이 있어요 😃 사실 연도를 따라가면 헷갈리지 않아서 좋긴한데, 조금 더 나아가서 Xcode, iPhone OS 버전들도 같이 통일해주면 더 헷갈리지 않을것 같습니다.개발할 때 매번 이 세가지의 버전이 늘 헷갈리더라구요. 그러면, Xcode 몇 버전에서는 최신 iOS 몇 버전까지 지원되고 그런것들에서 해방될 수 있지 않을까 생각해봅니다 ☺️

MacRumors

개발

민회

미리캔버스 프론트엔드 엔지니어

김재훈

문제해결에 도움되는 기술을 좋아합니다.
미리캔버스 웹&앱을 개발중이며, FSD에 관심있어서
사이드 프로젝트에 적용하고 블로그에 기록중입니다.

iOS 19가 아니라 이제 iOS 26?

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필