REST (Representational State Transfer): REST is a widely adopted architectural style for designing networked applications. It is based on a set of principles and constraints, such as using standard...

Most popular API architecture styles in our Digital World

REST (Representational State Transfer)
REST는 애플리케이션을 설계하기 위해 널리 채택된 API 아키텍처 스타일입니다. 리소스 조작, 상태-비저장 및 균일한 인터페이스를 위해 표준 HTTP 메서드(GET, POST, PUT, DELETE)를 기반으로 합니다. REST API는 리소스를 식별하기 위해 URI(Uniform Resource Identifier)를 사용하며 JSON 또는 XML과 같은 다양한 형식으로 데이터를 교환합니다.
 
SOAP (Simple Object Access Protocol)
SOAP는 네트워크를 통해 구조화된 정보를 교환하기 위한 XML 기반 프로토콜입니다. 엄격한 규칙을 따르며 메시지의 구조를 정의하기 위해 XML 스키마를 사용합니다. SOAP API는 일반적으로 HTTP 프로토콜을 사용하지만 SMTP나 TCP와 같은 프로토콜도 사용할 수 있습니다. SOAP API는 높은 수준의 프로토콜 추상화를 제공하고, 암호화 및 트랜잭션 관리와 같은 고급 기능을 지원합니다. 은행 및 금융 산업에서는 보안을 이유로 일반적으로 SOAP를 사용합니다.
 
SOAP는 서로 다른 시스템 간의 복잡한 연결이 필요한 환경에서 사용됩니다. 암호화, 디지털 서명 및 신뢰할 수 있는 메시징과 같은 고급 기능을 지원하는 엄격하고 표준화된 메시징 프로토콜을 제공합니다. 따라서 보안, 신뢰성 및 트랜잭션이 중요한 시나리오에 적합합니다. 
 
GraphQL
GraphQL은 API 쿼리 언어로 클라이언트가 서버에 특정한 데이터를 요청할 수 있습니다. 클라이언트가 필요한 데이터만 요청하여 데이터 패치에 대해 유연하고 효율적인 접근 방식을 제공합니다. 각 엔드포인트가 고정된 데이터 세트를 반환하는 REST와 달리 GraphQL API는 단일 엔드포인트가 있으며 클라이언트는 요구 사항에 따라 응답을 형성할 수 있습니다.
 
facebook, GitHub, Shopify, Twitter등의 회사가 사용합니다.
 
gRPC (Google Remote Procedure Call)
gRPC는 구글이 원격 프로시저 호출 API 구축을 위해 개발한 고성능 오픈 소스 프레임워크입니다. protobuf를 사용하며 여러 프로그래밍 언어를 지원합니다. gRPC API는 양방향 스트리밍 및 인증과 같은 기능을 제공하며 전송을 위해 이진 직렬화 및 HTTP/2를 사용하여 서비스 간의 효율적인 통신을 가능케 합니다. 
 
gRPC는 효율적이고 확장 가능한 분산 시스템을 구축하게 합니다. 구글, 넷플릭스, 스퀘어 등의 회사가 사용합니다.
 
WebSocket
WebSocket은 단일 TCP 연결을 통해 이중 통신 채널을 제공하는 통신 프로토콜입니다. 요청-응답 기반의 전통적인 HTTP와 달리 WebSocket은 클라이언트와 서버 간의 실시간 양방향 통신을 허용합니다. 이것은 클라이언트와 서버가 반복적인 요청 없이 서로에게 메시지를 보낼 수 있게 합니다. WebSocket은 채팅 애플리케이션, 협업 도구, 스트리밍 서비스와 같은 실시간 업데이트가 필요한 애플리케이션에서 사용됩니다.
 
WebSocket을 사용하는 메시징 어플리케이션은 Slack, Discord, Trello, Robinhood 등이 있습니다. 
 
Webhook
Webhook는 HTTP POST 요청을 다른 시스템의 미리 정의된 URL로 전송하여 한 시스템에서 이벤트를 자동으로 알리거나 트리거하는 메커니즘입니다. 두 시스템이 거의 실시간으로 데이터를 전송하여 통신할 수 있도록 합니다. 특정 이벤트나 조건이 발생하면 Webhook를 트리거하고, Webhook는 대상 시스템의 엔드포인트로 관련 데이터 페이로드를 전송합니다. 일반적으로 서로 다른 서비스와 시스템을 통합하는 데 사용되며 실시간 데이터 동기화, 이벤트 기반 워크플로우 및 자동 알림을 가능하게 합니다.
 
번역: [https://ducktopia.tistory.com/121]
원본:

REST (Representational State Transfer)REST는 애플리케이션을 설계하기 위해 널리 채택된 API 아키텍처 스타일입니다. 리소스 조작, 상태-비저장 및 균일한 인터페이스를 위해 표준 HTTP 메서드(GET, POST, PUT, DELETE)를 기반으로 합니다. REST API는 리소스를 식별하기 위해 URI(Uniform Resource Identifier)를 사용하며 JSON 또는 XML과 같은 다양한 형식으로 데이터를 교환합니다.&nbsp;SOAP (Simple Object Access Protocol)SOAP는 네트워크를 통해 구조화된 정보를 교환하기 위한 XML 기반 프로토콜입니다. 엄격한 규칙을 따르며 메시지의 구조를 정의하기 위해 XML 스키마를 사용합니다. SOAP API는 일반적으로 HTTP 프로토콜을 사용하지만 SMTP나 TCP와 같은 프로토콜도 사용할 수 있습니다. SOAP API는 높은 수준의 프로토콜 추상화를 제공하고, 암호화 및 트랜잭션 관리와 같은 고급 기능을 지원합니다. 은행 및 금융 산업에서는 보안을 이유로 일반적으로 SOAP를 사용합니다.&nbsp;SOAP는 서로 다른 시스템 간의 복잡한 연결이 필요한 환경에서 사용됩니다. 암호화, 디지털 서명 및 신뢰할 수 있는 메시징과 같은 고급 기능을 지원하는 엄격하고 표준화된 메시징 프로토콜을 제공합니다. 따라서 보안, 신뢰성 및 트랜잭션이 중요한 시나리오에 적합합니다.&nbsp;&nbsp;GraphQLGraphQL은 API 쿼리 언어로 클라이언트가 서버에 특정한 데이터를 요청할 수 있습니다. 클라이언트가 필요한 데이터만 요청하여 데이터 패치에 대해 유연하고 효율적인 접근 방식을 제공합니다. 각 엔드포인트가 고정된 데이터 세트를 반환하는 REST와 달리 GraphQL API는 단일 엔드포인트가 있으며 클라이언트는 요구 사항에 따라 응답을 형성할 수 있습니다.&nbsp;facebook, GitHub, Shopify, Twitter등의 회사가 사용합니다.&nbsp;gRPC (Google Remote Procedure Call)gRPC는 구글이 원격 프로시저 호출 API 구축을 위해 개발한 고성능 오픈 소스 프레임워크입니다. protobuf를 사용하며 여러 프로그래밍 언어를 지원합니다. gRPC API는 양방향 스트리밍 및 인증과 같은 기능을 제공하며 전송을 위해 이진 직렬화 및 HTTP/2를 사용하여 서비스 간의 효율적인 통신을 가능케 합니다.&nbsp;&nbsp;gRPC는 효율적이고 확장 가능한 분산 시스템을 구축하게 합니다. 구글, 넷플릭스, 스퀘어 등의 회사가 사용합니다.&nbsp;WebSocketWebSocket은 단일 TCP 연결을 통해 이중 통신 채널을 제공하는 통신 프로토콜입니다. 요청-응답 기반의 전통적인 HTTP와 달리 WebSocket은 클라이언트와 서버 간의 실시간 양방향 통신을 허용합니다. 이것은 클라이언트와 서버가 반복적인 요청 없이 서로에게 메시지를 보낼 수 있게 합니다. WebSocket은 채팅 애플리케이션, 협업 도구, 스트리밍 서비스와 같은 실시간 업데이트가 필요한 애플리케이션에서 사용됩니다.&nbsp;WebSocket을 사용하는 메시징 어플리케이션은 Slack, Discord, Trello, Robinhood 등이 있습니다.&nbsp;&nbsp;WebhookWebhook는 HTTP POST 요청을 다른 시스템의 미리 정의된 URL로 전송하여 한 시스템에서 이벤트를 자동으로 알리거나 트리거하는 메커니즘입니다. 두 시스템이 거의 실시간으로 데이터를 전송하여 통신할 수 있도록 합니다. 특정 이벤트나 조건이 발생하면 Webhook를 트리거하고, Webhook는 대상 시스템의 엔드포인트로 관련 데이터 페이로드를 전송합니다. 일반적으로 서로 다른 서비스와 시스템을 통합하는 데 사용되며 실시간 데이터 동기화, 이벤트 기반 워크플로우 및 자동 알림을 가능하게 합니다.&nbsp;번역: [https://ducktopia.tistory.com/121]원본:

Medium

🕊️ 개발 세계에서 인기 있는 API 아키텍처 스타일

프로덕트 매니저 (PM) 는 성공적인 제품과 서비스를 만들어내기 위해 다양한 역량을 갖추어야 합니다. 성공적인 (최소한 덜 실패하는) 프로덕트 매니저가 되기 위해 갖추어야 할 8가지 역량을 제 경험에 비추어 정리해보았습니다.

프로덕트 매니저의 필수 역량 8가지: 혁신을 이끄는 성장의 레시피

1. 지속적으로 줌-인, 줌-아웃을 합니다 : 프로젝트를 성공적으로 이끌려면, 전체적인 방향성과 목표를 놓치지 않으면서도, 이용자 관점에서 디테일한 부분까지 꼼꼼히 살펴야 합니다. 따라서 쏟아지는 일에 휩쓸리지 않고, 수시로 줌-인, 줌-아웃하며 일을 할 수 있어야 해요.

2. 화려한 한 방보다는 지속적인 최적화에 더 큰 관심을 기울입니다 : 경험이 없는 사람들은 화려하게 준비해서 잘 런칭하면 큰 관심을 받을 것이라고 착각하지만, 그건 현실을 잘 모르는 얘기입니다. 아무리 잘 준비해도, 막상 프로젝트를 내놓으면 수정하고 최적화할 것들이 넘쳐납니다. 다시 말해, 프로젝트에선 탄생보다 진화가 훨씬 더 중요합니다.

3. 고객과 데이터를 중심으로 사고하세요 : 비즈니스 프로젝트는 크게 2가지로 나눌 수 있습니다. 1) 고객이 어려움을 겪는 문제를 해결하거나(Problem-solving), 2) 고객에게 새로운 습관을 만들어 주거나 (Habit-forming). 그리고 이 2가지의 접근 방식은 달라야 합니다. 고객의 문제를 해결하는 프로젝트는 고객의 명확한 니즈나 pain point를 파악하고, 이를 효과적으로 해결하는 데 초점을 맞춰야 하고, 새로운 습관을 만드는 프로젝트는 (재미 등) 고객의 잠재된 니즈를 발굴하여, 이를 새로운 습관으로 형성할 수 있도록 유도하는 것이 중요합니다. 그리고 이를 위해선 기본적으로, 고객 입장에서 생각하고, 고객 피드백과 데이터를 토대로 의사결정하는 사고방식을 가져야 합니다. 습관을 만들든, 고객의 문제를 해결하든, 모두 데이터를 보면서 사고해야 한다는 말입니다.

4. 비즈니스 모델을 생각하지 않은 프로젝트는 사상누각에 불과합니다 : 처음에 떠오른 아이디어를 제품이나 서비스로 기획하는 일은 재미있고 신나는 활동입니다. 하지만 지속적으로 고객을 만족시키고, 프로젝트를 발전시키기 위해선 비즈니스 모델이 반드시 있어야 합니다. 고객의 문제를 진정으로 해결하고, 고객에게 만족감을 주려면 많은 돈과 시간과 인력이 들어가니까요. 따라서 비즈니스 모델에 대한 탐구나 고려가 없는 프로젝트는 바람 앞에 등불과도 같은 겁니다.

5. 우선순위가 없다는 건 뭐가 중요한지 모른다는 뜻입니다 : 어떤 프로젝트든 시간과 자원은 한정되어 있습니다. 따라서 중요하고 좋은 효과를 낼 수 있는 곳에 자원을 우선적으로 집중해야 합니다. 즉, 프로젝트가 성공하기 위해선 항상 우선순위를 명확히 하고, 가장 중요한 일에 자원을 집중해야 합니다.

6. 커뮤니케이션과 협업 없이는 위대한 일을 해낼 수 없습니다 : 자신의 제한된 시간과 역량을 최대한 효과적으로 활용하기 위해서는 다른 사람과 명확하게 커뮤니케이션을 하고, 협업을 잘 하는 것이 무엇보다 중요합니다. 반대로, 커뮤니케이션이나 협업 능력이 떨어지면, 쉬운 일마저 어려워지죠. 따라서 일을 잘하고 싶다면, 커뮤니케이션과 협업하는 역량부터 키워야 합니다. 특히 내가 잘 되기 위해선 다른 사람을 잘 도울 수 있어야 합니다. 따라서 다른 사람을 진정으로 도울 수 있는 플러싱(Plussing) 기술을 익히는 건 필수적인 일입니다.

7. 기회는 환경 변화 속에서 만들어집니다. 따라서 변화에 기민하게 대응해야 합니다 : 인터넷의 등장, 스마트폰의 등장, 생성형 AI의 등장 등 새로운 변화가 일어나면 새로운 기회가 만들어집니다. 따라서 기회를 잡고 싶다면, 변화에 대한 감각을 예민하게 길러야 합니다. 하던 대로 하는 게 아니라.

8. 호기심을 가지고 지속적으로 탐구하고 학습해야 지적 성장이 일어납니다 : 세상에 완전히 새로운 건 없습니다. 뭐가 좋은지를 찾고, 좋은 건 잘 학습하고, 그걸 자신의 스타일대로 풀어내는 연습을 해야 창의적인 결과물을 만들어낼 수 있습니다. 사람들은 창의성을 재능이나 능력이라고 착각하지만, 창의성은 태도에 더 가깝습니다.

++ 존경하는 정윤호 대표님 글을 참고해서 작성해봤습니담 ;)

https://slashpage.com/yunojung/pm-8skills

1. 지속적으로 줌-인, 줌-아웃을 합니다 : 프로젝트를 성공적으로 이끌려면, 전체적인 방향성과 목표를 놓치지 않으면서도, 이용자 관점에서 디테일한 부분까지 꼼꼼히 살펴야 합니다. 따라서 쏟아지는 일에 휩쓸리지 않고, 수시로 줌-인, 줌-아웃하며 일을 할 수 있어야 해요. 2. 화려한 한 방보다는 지속적인 최적화에 더 큰 관심을 기울입니다 : 경험이 없는 사람들은 화려하게 준비해서 잘 런칭하면 큰 관심을 받을 것이라고 착각하지만, 그건 현실을 잘 모르는 얘기입니다. 아무리 잘 준비해도, 막상 프로젝트를 내놓으면 수정하고 최적화할 것들이 넘쳐납니다. 다시 말해, 프로젝트에선 탄생보다 진화가 훨씬 더 중요합니다. 3. 고객과 데이터를 중심으로 사고하세요 : 비즈니스 프로젝트는 크게 2가지로 나눌 수 있습니다. 1) 고객이 어려움을 겪는 문제를 해결하거나(Problem-solving), 2) 고객에게 새로운 습관을 만들어 주거나 (Habit-forming). 그리고 이 2가지의 접근 방식은 달라야 합니다. 고객의 문제를 해결하는 프로젝트는 고객의 명확한 니즈나 pain point를 파악하고, 이를 효과적으로 해결하는 데 초점을 맞춰야 하고, 새로운 습관을 만드는 프로젝트는 (재미 등) 고객의 잠재된 니즈를 발굴하여, 이를 새로운 습관으로 형성할 수 있도록 유도하는 것이 중요합니다. 그리고 이를 위해선 기본적으로, 고객 입장에서 생각하고, 고객 피드백과 데이터를 토대로 의사결정하는 사고방식을 가져야 합니다. 습관을 만들든, 고객의 문제를 해결하든, 모두 데이터를 보면서 사고해야 한다는 말입니다. 4. 비즈니스 모델을 생각하지 않은 프로젝트는 사상누각에 불과합니다 : 처음에 떠오른 아이디어를 제품이나 서비스로 기획하는 일은 재미있고 신나는 활동입니다. 하지만 지속적으로 고객을 만족시키고, 프로젝트를 발전시키기 위해선 비즈니스 모델이 반드시 있어야 합니다. 고객의 문제를 진정으로 해결하고, 고객에게 만족감을 주려면 많은 돈과 시간과 인력이 들어가니까요. 따라서 비즈니스 모델에 대한 탐구나 고려가 없는 프로젝트는 바람 앞에 등불과도 같은 겁니다. 5. 우선순위가 없다는 건 뭐가 중요한지 모른다는 뜻입니다 : 어떤 프로젝트든 시간과 자원은 한정되어 있습니다. 따라서 중요하고 좋은 효과를 낼 수 있는 곳에 자원을 우선적으로 집중해야 합니다. 즉, 프로젝트가 성공하기 위해선 항상 우선순위를 명확히 하고, 가장 중요한 일에 자원을 집중해야 합니다. 6. 커뮤니케이션과 협업 없이는 위대한 일을 해낼 수 없습니다 : 자신의 제한된 시간과 역량을 최대한 효과적으로 활용하기 위해서는 다른 사람과 명확하게 커뮤니케이션을 하고, 협업을 잘 하는 것이 무엇보다 중요합니다. 반대로, 커뮤니케이션이나 협업 능력이 떨어지면, 쉬운 일마저 어려워지죠. 따라서 일을 잘하고 싶다면, 커뮤니케이션과 협업하는 역량부터 키워야 합니다. 특히 내가 잘 되기 위해선 다른 사람을 잘 도울 수 있어야 합니다. 따라서 다른 사람을 진정으로 도울 수 있는 플러싱(Plussing) 기술을 익히는 건 필수적인 일입니다. 7. 기회는 환경 변화 속에서 만들어집니다. 따라서 변화에 기민하게 대응해야 합니다 : 인터넷의 등장, 스마트폰의 등장, 생성형 AI의 등장 등 새로운 변화가 일어나면 새로운 기회가 만들어집니다. 따라서 기회를 잡고 싶다면, 변화에 대한 감각을 예민하게 길러야 합니다. 하던 대로 하는 게 아니라. 8. 호기심을 가지고 지속적으로 탐구하고 학습해야 지적 성장이 일어납니다 : 세상에 완전히 새로운 건 없습니다. 뭐가 좋은지를 찾고, 좋은 건 잘 학습하고, 그걸 자신의 스타일대로 풀어내는 연습을 해야 창의적인 결과물을 만들어낼 수 있습니다. 사람들은 창의성을 재능이나 능력이라고 착각하지만, 창의성은 태도에 더 가깝습니다. ++ 존경하는 정윤호 대표님 글을 참고해서 작성해봤습니담 ;) https://slashpage.com/yunojung/pm-8skills

SlashPage

프로젝트를 성공적으로 마무리하려면 어떻게 해야 하나?

01 . 혹시 예전에는 별생각 없이 자주 썼던 말인데 어느 순간부터는 덜 사용하게 되는 말이 있으신가요? 뭐 유행이 한풀 꺾여서 더 이상 안 쓰게 될 수도 있지만 그건 나뿐만 아니라 많은 사람에게 해당되는 말이기도 하고, 말하는 습관이나 환경이 달라짐에 따라 왠지 거리를 좀 두게 되는 말들도 존재하지만 그 또한 내 의지로 인해 사용성이 감소하는 단어는 아닐 겁니다.

02 . 살면서 특정한 단어의 쓰임을 고민한다는 건 그 단어가 가진 고유한 뜻보다 누군가에게 어떻게 들릴지를 깊이 있게 생각해 보는데서 출발합니다. 이런 예시가 적절한지 모르겠지만, 마치 칼이나 가위처럼 날카로운 도구를 나 혼자 다룰 때는 비교적 적당한 주의만으로도 충분히 사용할 수 있지만 누군가에게 건넬 때는 한 번 더 조심성이 더해지는 것처럼 말이죠. 서로 주고받는 타이밍이 약간이라도 어긋나거나 상대가 아직 그 사용성에 익숙하지 않다면 사고로 이어질 수도 있으니까요.

03 . 일을 해오는 동안 생긴 습관 중에 하나는 누구에게라도 흘려 내뱉는 말처럼 'OO 님이 이해 좀 해주세요'라는 표현을 쉽게 쓰지 않게 되었다는 겁니다. 심지어 그전까지는 많은 사람들이 그토록 쉽고 편하게 '이해하라'는 말을 한다는 사실조차도 모르고 있었죠.
물론 살면서 누군가에게 이해를 구하는 일도 생기고 나 역시 상대를 이해해야 하는 순간들이 부지기수로 많습니다. 하지만 내가 직접 이해를 바라거나 반대로 내가 직접 이해를 하는 것과는 다르게, 상대에게 또 다른 특정 대상을 가리켜 이해하라고 요구하는 것은 본질적인 차이가 있다고 생각합니다. 더불어 꽤 일방적이고 때로는 무례한 요구이기까지 하죠.

04 . 직접 경험한 것도 있고 간접 경험한 것도 있지만 사건의(?) 케이스들은 대부분 이랬습니다. A,B,C라는 세 사람이 있다면 보통 A가 B에게 문제를 제기하거나 개선을 요구하는 데서 출발합니다. 그 이야기를 들은 A는 C에게 사정 혹은 문제가 있다는 것을 알지만 본인이 이 사실을 이슈로 만들고 싶은 생각은 없습니다. 그렇다고 뾰족한 대책을 마련해 줄 수도 없다 보니 문제를 다시 B에게로 돌려보내는 겁니다. 바로 '네가 좀 이해해라. C에게도 그만한 사정이 있을 거다'라는 말과 함께 말이죠.

05 . 특히 이 과정에서 A가 B보다 높은 지위에 있는 경우라면 문제는 더 심각해질 수 있습니다. 문제를 덮고 돌려보내는 것 자체도 좋지 않은 상황을 야기하지만 그보다 더 나쁜 건 B로 하여금 '내가 이해를 하면 되는 문제인 거구나'라는 인식을 심어주기 때문이죠. 그때부터는 누군가를 '이해하라'는 말이 매우 강압적인 표현이 될 수도 있음이 분명합니다.

06 . 그래서 어느 순간부터는 섣불리 '이해하라'는 말을 꺼내기에 앞서 상대가 스스로 어떻게 문제를 받아들이고 있고 어떤 노력을 하고 있는지를 객관적으로 볼 수 있게 대화를 이어가려 합니다. 즉, 'OO 님이 생각하시기엔 지금 상황에서 제일 큰 문제가 무엇이라고 생각하세요?'라든가 '혹시 저에게 말씀하시기 전까지 어떤 부분들이 제일 고민이 되었나요?' 같은 질문을 하려고 하거든요. 그럼 많은 경우 스스로가 생각한 문제나 스스로가 해온 노력들을 직접 말로 표현하면서 생각을 더 체계적으로 정리하는 케이스가 많았습니다.

07 . 이렇다 보니 이제는 누군가가 고민을 얘기하거나 의견을 개진하려고 할 때 일단 무턱대고 '이해'부터 내세우고 요구하는 사례가 더 눈에 잘 띕니다.
"아니에요. 그렇게 생각하지 마시고 OO 님도 좋게 좋게 받아들이세요. 아예 모르는 사이도 아니고 우리가 그 정도는 충분히 이해할 수 있잖아요."
아마 지금 이 글을 읽고 계신 분들 중에도 이런 표현의 말들을 들어본 분이 적지 않을 거라고 생각됩니다. 그만큼 우리 모두 크게 의식하지 않고 일상 속에 퍼뜨리는 말 중에 하나니까요.

08 . 하지만 '이해하라'는 말은 상대에게 정확한 범위도, 역할도, 방법도, 효과도 규정하지 않은 채로 문제 자체를 무효화하는 결과로 이어집니다. 물론 타인과 관계를 맺어가야 하는 입장에서 누군가를 더 깊고 넓게 이해하는 데서 오는 긍정적인 점들이 많다는 건 당연히 잘 알고 있지만, 매사 타인에게 '이해하고 보라'는 식의 주문은 그리 적절해 보이지 않다는 게 제 생각입니다.

09 . 그럼에도 불구하고 '괜히 속 좁은 사람처럼 보일 수 있지 않을까...'라고 생각된다면 '이해하라'는 말을 이렇게 한번 사용해 보는 것도 좋습니다.
일을 같이하는 입장이라면 '우리가 C에게 어떤 도움을 줄 수 있을까요?'라며 문제의식 자체를 공통의 어젠다로 등록하는 방법도 있고, 일반적인 사이에서는 '혹시 우리가 잘못 이해하고 있는 부분이 있으려나?'처럼 '충분히 헤아려봤음에도 쉽게 납득되지 않는 부분이 존재하는지'를 셀프 체크하는 방법도 있거든요. 저는 이게 '이해'라는 단어를 제대로 사용하는 현명한 가이드라고도 생각합니다.

10 . 파나소닉의 창업자이자 국내의 많은 독자들에게도 경영의 귀재로 알려져 있는 마쓰시타 고노스케 옹은 이런 말을 남겼습니다.
"만사가 잘 진행되게 하려면 누구에게 어떤 말을 해주는가가 기본이다. 적절한 말이 올바르게 쓰일 때 일도 사람도 성장한다."
그런 의미에서 저는 '이해'라는 단어도 그렇게 쓰였으면 합니다. '적절하고 올바르게'.

01 . 혹시 예전에는 별생각 없이 자주 썼던 말인데 어느 순간부터는 덜 사용하게 되는 말이 있으신가요? 뭐 유행이 한풀 꺾여서 더 이상 안 쓰게 될 수도 있지만 그건 나뿐만 아니라 많은 사람에게 해당되는 말이기도 하고, 말하는 습관이나 환경이 달라짐에 따라 왠지 거리를 좀 두게 되는 말들도 존재하지만 그 또한 내 의지로 인해 사용성이 감소하는 단어는 아닐 겁니다. 02 . 살면서 특정한 단어의 쓰임을 고민한다는 건 그 단어가 가진 고유한 뜻보다 누군가에게 어떻게 들릴지를 깊이 있게 생각해 보는데서 출발합니다. 이런 예시가 적절한지 모르겠지만, 마치 칼이나 가위처럼 날카로운 도구를 나 혼자 다룰 때는 비교적 적당한 주의만으로도 충분히 사용할 수 있지만 누군가에게 건넬 때는 한 번 더 조심성이 더해지는 것처럼 말이죠. 서로 주고받는 타이밍이 약간이라도 어긋나거나 상대가 아직 그 사용성에 익숙하지 않다면 사고로 이어질 수도 있으니까요. 03 . 일을 해오는 동안 생긴 습관 중에 하나는 누구에게라도 흘려 내뱉는 말처럼 'OO 님이 이해 좀 해주세요'라는 표현을 쉽게 쓰지 않게 되었다는 겁니다. 심지어 그전까지는 많은 사람들이 그토록 쉽고 편하게 '이해하라'는 말을 한다는 사실조차도 모르고 있었죠. 물론 살면서 누군가에게 이해를 구하는 일도 생기고 나 역시 상대를 이해해야 하는 순간들이 부지기수로 많습니다. 하지만 내가 직접 이해를 바라거나 반대로 내가 직접 이해를 하는 것과는 다르게, 상대에게 또 다른 특정 대상을 가리켜 이해하라고 요구하는 것은 본질적인 차이가 있다고 생각합니다. 더불어 꽤 일방적이고 때로는 무례한 요구이기까지 하죠. 04 . 직접 경험한 것도 있고 간접 경험한 것도 있지만 사건의(?) 케이스들은 대부분 이랬습니다. A,B,C라는 세 사람이 있다면 보통 A가 B에게 문제를 제기하거나 개선을 요구하는 데서 출발합니다. 그 이야기를 들은 A는 C에게 사정 혹은 문제가 있다는 것을 알지만 본인이 이 사실을 이슈로 만들고 싶은 생각은 없습니다. 그렇다고 뾰족한 대책을 마련해 줄 수도 없다 보니 문제를 다시 B에게로 돌려보내는 겁니다. 바로 '네가 좀 이해해라. C에게도 그만한 사정이 있을 거다'라는 말과 함께 말이죠. 05 . 특히 이 과정에서 A가 B보다 높은 지위에 있는 경우라면 문제는 더 심각해질 수 있습니다. 문제를 덮고 돌려보내는 것 자체도 좋지 않은 상황을 야기하지만 그보다 더 나쁜 건 B로 하여금 '내가 이해를 하면 되는 문제인 거구나'라는 인식을 심어주기 때문이죠. 그때부터는 누군가를 '이해하라'는 말이 매우 강압적인 표현이 될 수도 있음이 분명합니다. 06 . 그래서 어느 순간부터는 섣불리 '이해하라'는 말을 꺼내기에 앞서 상대가 스스로 어떻게 문제를 받아들이고 있고 어떤 노력을 하고 있는지를 객관적으로 볼 수 있게 대화를 이어가려 합니다. 즉, 'OO 님이 생각하시기엔 지금 상황에서 제일 큰 문제가 무엇이라고 생각하세요?'라든가 '혹시 저에게 말씀하시기 전까지 어떤 부분들이 제일 고민이 되었나요?' 같은 질문을 하려고 하거든요. 그럼 많은 경우 스스로가 생각한 문제나 스스로가 해온 노력들을 직접 말로 표현하면서 생각을 더 체계적으로 정리하는 케이스가 많았습니다. 07 . 이렇다 보니 이제는 누군가가 고민을 얘기하거나 의견을 개진하려고 할 때 일단 무턱대고 '이해'부터 내세우고 요구하는 사례가 더 눈에 잘 띕니다. "아니에요. 그렇게 생각하지 마시고 OO 님도 좋게 좋게 받아들이세요. 아예 모르는 사이도 아니고 우리가 그 정도는 충분히 이해할 수 있잖아요."아마 지금 이 글을 읽고 계신 분들 중에도 이런 표현의 말들을 들어본 분이 적지 않을 거라고 생각됩니다. 그만큼 우리 모두 크게 의식하지 않고 일상 속에 퍼뜨리는 말 중에 하나니까요. 08 . 하지만 '이해하라'는 말은 상대에게 정확한 범위도, 역할도, 방법도, 효과도 규정하지 않은 채로 문제 자체를 무효화하는 결과로 이어집니다. 물론 타인과 관계를 맺어가야 하는 입장에서 누군가를 더 깊고 넓게 이해하는 데서 오는 긍정적인 점들이 많다는 건 당연히 잘 알고 있지만, 매사 타인에게 '이해하고 보라'는 식의 주문은 그리 적절해 보이지 않다는 게 제 생각입니다. 09 . 그럼에도 불구하고 '괜히 속 좁은 사람처럼 보일 수 있지 않을까...'라고 생각된다면 '이해하라'는 말을 이렇게 한번 사용해 보는 것도 좋습니다. 일을 같이하는 입장이라면 '우리가 C에게 어떤 도움을 줄 수 있을까요?'라며 문제의식 자체를 공통의 어젠다로 등록하는 방법도 있고, 일반적인 사이에서는 '혹시 우리가 잘못 이해하고 있는 부분이 있으려나?'처럼 '충분히 헤아려봤음에도 쉽게 납득되지 않는 부분이 존재하는지'를 셀프 체크하는 방법도 있거든요. 저는 이게 '이해'라는 단어를 제대로 사용하는 현명한 가이드라고도 생각합니다. 10 . 파나소닉의 창업자이자 국내의 많은 독자들에게도 경영의 귀재로 알려져 있는 마쓰시타 고노스케 옹은 이런 말을 남겼습니다. "만사가 잘 진행되게 하려면 누구에게 어떤 말을 해주는가가 기본이다. 적절한 말이 올바르게 쓰일 때 일도 사람도 성장한다."그런 의미에서 저는 '이해'라는 단어도 그렇게 쓰였으면 합니다. '적절하고 올바르게'.

'네가 이해하라'는 말이 주는 부정적 영향에 대하여

어느 1인 기업가의 조직도 (feat. AI .. : 네이버블로그

여러 AI 제품들을 이용해서 실제 사업에 어떤 도움을 받고 있는지가 잘 정리된 글입니다. (히크로도스라는 1인기업 대표 최재완님의 글) 교육 콘텐츠 기획, IT/개발, 디자인, 세무회계 등 각 분야별로 SaaS 툴들을 잘 조합해서 꽤 높은 생산성을 낼 수 있다고 소개하신 내용이 구체적이고, 참고가 되네요. 노코드 툴을 이용한 서비스 개발이나, 제품 기획 과정에서 AI 제품을 활용하는 데 관심있는 분들이라면 한번쯤 읽어보시면 좋을 것 같아요.

여러 AI 제품들을 이용해서 실제 사업에 어떤 도움을 받고 있는지가 잘 정리된 글입니다. (히크로도스라는 1인기업 대표 최재완님의 글) 교육 콘텐츠 기획, IT/개발, 디자인, 세무회계 등 각 분야별로 SaaS 툴들을 잘 조합해서 꽤 높은 생산성을 낼 수 있다고 소개하신 내용이 구체적이고, 참고가 되네요. 노코드 툴을 이용한 서비스 개발이나, 제품 기획 과정에서 AI 제품을 활용하는 데 관심있는 분들이라면 한번쯤 읽어보시면 좋을 것 같아요.

Naver

[어느 1인 기업가의 조직도]

라이팅에 구체성을 더해 매끄러운 UX 만들기 | 구체성은 사용자에게 눈앞의 문제를 해결할 힘을 줍니다. 모호하게 느껴지는 모바일 인터페이스를 살펴보면 라이팅이 구체적이지 않은 경우가 많습니다. 서비스 규모가 커질수록 인터랙션 경우의 수는 방대해집니다. 이 경우 불어난 레이블이나 토스트, 팝업 등에 포괄적인 라이팅을 적용해 대응의 기동성을 선택하는 경우가 많습니다.

14화 모호한 UX 라이팅이 문제라고요?

명확하고 이해하기 쉬운 라이팅은 사용자 경험을 크게 개선할 수 있습니다. 이번 글에서는 UX 라이팅이 모호할 때 발생하는 문제와 이를 해결하기 위한 구체적인 방법을 다룹니다.

- 📖 명확한 커뮤니케이션: 사용자가 정보를 쉽게 이해하고, 신속하게 행동으로 옮길 수 있도록 돕습니다.
- 🚫 모호한 라이팅의 문제점: 혼란과 오해를 초래하며, 사용자 만족도를 저하시킬 수 있습니다.
- 💡 개선 방안: 실제 예시를 통해 어떻게 UX 라이팅을 개선할 수 있는지 제시합니다.

명확하고 이해하기 쉬운 라이팅은 사용자 경험을 크게 개선할 수 있습니다. 이번 글에서는 UX 라이팅이 모호할 때 발생하는 문제와 이를 해결하기 위한 구체적인 방법을 다룹니다. - 📖 명확한 커뮤니케이션: 사용자가 정보를 쉽게 이해하고, 신속하게 행동으로 옮길 수 있도록 돕습니다.- 🚫 모호한 라이팅의 문제점: 혼란과 오해를 초래하며, 사용자 만족도를 저하시킬 수 있습니다.- 💡 개선 방안: 실제 예시를 통해 어떻게 UX 라이팅을 개선할 수 있는지 제시합니다.

Brunch Story

🫨모호한 UX 라이팅이 문제라고요?

스타트업 서바이벌 가이드, 미매뉴얼

미매뉴얼

2024년 4월 13일 토요일 오후에 B 클럽 '오늘의 아이디어를 내일의 사업으로 만드는 방법'을 4시간 동안 진행했다. 여기서 나눈 이야기들 중 하나로 창업가의 꿈과 비전에 대한 이야기~ 😊

창업을 하고 사업을 하고 싶은 사람이라면 반드시 생각을 정리해야 할 것이 있다. 그것은 바로 비전과 드림(꿈)이다.

비전과 꿈의 차이가 없다면 사업이라기 보다는 사실 장사라든가 프리랜서에 더 가깝다. 직장인도 마찬가지다. 하지만 사업을 할거라면 비전이 필요하다. 비전은 내가 개인적으로 달성하고 싶은 부분(꿈)과 여기에 더하여 이 조직을 통해서 얻고자 하는 게 무엇인지를 같이 고민해야만 한다. 그런데 이것을 많이 헷갈려 한다. 본인의 꿈인데 이걸 자꾸 비전이라고 강조하시는 사람들이 많다.

그렇게 해서 조직을 운영하기 시작하시면 100% 문제 발생이 시작이 된다. 나 개인의 목적으로 했었던 부분을 무작정 남에게 정확하게는 임직원들과 사업 관련한 주위 이해관계자들에게 강요하는 일이 발생한다. 직장생활을 해본 사람들이라면 공감할 것이다. 내가 동의하지 않는 개인의 꿈을 회사의 비전이라고 했었을 경우에 조직 몰입도랑 만족도가 매우 떨어진다. 정말 어마어마하게 연봉과 월급에서 차이가 나지 않는 이상 10% 전후의 차이가 되면 (다른 조건들이 모두 동일할 때) 돈을 조금 손해 보더라도 내가 회사의 비전에 공감하거나 나와 조직 문화가 맞는 곳을 선택하지 괜히 돈 10%에서 20% 더 받겠다고 맞지 않는 곳에 가지 않고 가더라도 단기간내에 거의 100% 그만두게 된다. 이를 역으로 생각하면 창업가와 사업가는 꿈과 비전은 분리해서 생각하고 내 꿈을 조직을 통해 실현하고 조직원들의 공감대를 얻을 수 있는 비전을 만들어야 한다. 그리고 비전을 통해 나 자신 뿐만 아니라 임직원들까지 다 함께 사업이 어느 방향으로 가야 될 지에 대한 사업방향성을 제시하고 장기적으로 모두가 방황하지 않도록 해야만 한다.

https://www.memanual.co.kr

2024년 4월 13일 토요일 오후에 B 클럽 '오늘의 아이디어를 내일의 사업으로 만드는 방법'을 4시간 동안 진행했다. 여기서 나눈 이야기들 중 하나로 창업가의 꿈과 비전에 대한 이야기~ 😊 창업을 하고 사업을 하고 싶은 사람이라면 반드시 생각을 정리해야 할 것이 있다. 그것은 바로 비전과 드림(꿈)이다. 비전과 꿈의 차이가 없다면 사업이라기 보다는 사실 장사라든가 프리랜서에 더 가깝다. 직장인도 마찬가지다. 하지만 사업을 할거라면 비전이 필요하다. 비전은 내가 개인적으로 달성하고 싶은 부분(꿈)과 여기에 더하여 이 조직을 통해서 얻고자 하는 게 무엇인지를 같이 고민해야만 한다. 그런데 이것을 많이 헷갈려 한다. 본인의 꿈인데 이걸 자꾸 비전이라고 강조하시는 사람들이 많다. 그렇게 해서 조직을 운영하기 시작하시면 100% 문제 발생이 시작이 된다. 나 개인의 목적으로 했었던 부분을 무작정 남에게 정확하게는 임직원들과 사업 관련한 주위 이해관계자들에게 강요하는 일이 발생한다. 직장생활을 해본 사람들이라면 공감할 것이다. 내가 동의하지 않는 개인의 꿈을 회사의 비전이라고 했었을 경우에 조직 몰입도랑 만족도가 매우 떨어진다. 정말 어마어마하게 연봉과 월급에서 차이가 나지 않는 이상 10% 전후의 차이가 되면 (다른 조건들이 모두 동일할 때) 돈을 조금 손해 보더라도 내가 회사의 비전에 공감하거나 나와 조직 문화가 맞는 곳을 선택하지 괜히 돈 10%에서 20% 더 받겠다고 맞지 않는 곳에 가지 않고 가더라도 단기간내에 거의 100% 그만두게 된다. 이를 역으로 생각하면 창업가와 사업가는 꿈과 비전은 분리해서 생각하고 내 꿈을 조직을 통해 실현하고 조직원들의 공감대를 얻을 수 있는 비전을 만들어야 한다. 그리고 비전을 통해 나 자신 뿐만 아니라 임직원들까지 다 함께 사업이 어느 방향으로 가야 될 지에 대한 사업방향성을 제시하고 장기적으로 모두가 방황하지 않도록 해야만 한다. https://www.memanual.co.kr

Memanual

꿈과 비전은 다르다

최근 오픈소스가 활성화되면서 새로운 프로그래밍 언어가 다양하게 나오고 있는데요. 그중에도 2024, 2025년도에 두각을 드러낼 것 같다고 생각한 프로그래밍 언어도 소개합니다.

2024년, 배우면 좋을 프로그래밍 언어 ② | 원티드

2024년 새로운 프로그래밍 언어를 도전해보신다면 이 언어를 추천합니다!

안녕하세요. 이번에 원티드랑 두번째 글로 2024년 배우면 좋은 프로그래밍언어 Part 2와 2024/2025에 주목해야하는 프로그래밍 언어에 대한 글을 기고했습니다 :)

특히 2024/2025에 주목해봐야할 언어는 파이썬이 점령한 AI와 데이터처리에 도전하는 언어들도 다뤄보았습니다 :)

파트1은 아래에서 보실수 있습니다.

Part1. https://www.wanted.co.kr/events/article_240408a

2024년 새로운 프로그래밍 언어를 도전해보신다면 이 언어를 추천합니다! 안녕하세요. 이번에 원티드랑 두번째 글로 2024년 배우면 좋은 프로그래밍언어 Part 2와 2024/2025에 주목해야하는 프로그래밍 언어에 대한 글을 기고했습니다 :) 특히 2024/2025에 주목해봐야할 언어는 파이썬이 점령한 AI와 데이터처리에 도전하는 언어들도 다뤄보았습니다 :) 파트1은 아래에서 보실수 있습니다. Part1. https://www.wanted.co.kr/events/article_240408a

원티드

2024년도에 배우면 좋은 프로그래밍언어 Part 2

📰 인터넷은 그냥 한 때의 유행일 것

불과 24년전 신문의 헤드라인이다. 앞으로 무엇이 어떻게 될 지는 정말 아무도 모르는 일이다.
—
인터넷은 많은 사용자에게 그저 한때의 유행일 수도 있다는 보고서가 나왔다. 연구원들은 전 세계적으로 수백만의 사용자가 불편함과 비용이 많이 드는 연결 장비 때문에 인터넷 사용을 포기했다고 밝혔다. 전문가들은 인터넷 사용의 급감이 통신사들의 전략 실패를 나타낼 뿐만 아니라, 사용자들이 현실 세계로 돌아가길 원한다는 신호일 수 있다고 말한다.

📰 인터넷은 그냥 한 때의 유행일 것 불과 24년전 신문의 헤드라인이다. 앞으로 무엇이 어떻게 될 지는 정말 아무도 모르는 일이다.—인터넷은 많은 사용자에게 그저 한때의 유행일 수도 있다는 보고서가 나왔다. 연구원들은 전 세계적으로 수백만의 사용자가 불편함과 비용이 많이 드는 연결 장비 때문에 인터넷 사용을 포기했다고 밝혔다. 전문가들은 인터넷 사용의 급감이 통신사들의 전략 실패를 나타낼 뿐만 아니라, 사용자들이 현실 세계로 돌아가길 원한다는 신호일 수 있다고 말한다.

우선 한 번 경험하게 하는 것의 강력함 | 만약 우리 서비스가 초기라면 토스나 당근 같이 이미 크게 성장한 레퍼런스가 잘 맞지 않는 경우가 많습니다. 서비스 단계나 카테고리별 전략이 다르기 때문입니다. 그리고 급변하는 시장의 영향력은 시기에 따라 급변하는 변수입니다. 1년 전에 통했던 전략이 오늘은 통하지 않습니다. 좋은 레퍼런스를 보면 머릿속에서 이내 하나의 단단한 가설로 굳습니다.

13화 성공한 서비스의 시작점에는 가치 사다리가 있다?

무료에서 유료로, 단순 구매에서 장기적 관계로! 성공한 서비스의 시작점에는 가치 사다리가 있다?

👉제가 눈여겨 본 실제 사례를 통해 미끼 상품의 활용부터 장기적 고객 관계 구축의 가능성을 살펴 보았습니다.

본문 요약
 * 무료라도 경쟁력을 갖춰야 시간 가치를 이길 수 있다.
 * 본질이 약하면 다음 사다리로 연결되지 않는다.
 * 미끼 상품부터 문제 해결의 모습이나 바이럴 요소가 있어야 한다.
https://brunch.co.kr/@cliche-cliche/219

무료에서 유료로, 단순 구매에서 장기적 관계로! 성공한 서비스의 시작점에는 가치 사다리가 있다? 👉제가 눈여겨 본 실제 사례를 통해 미끼 상품의 활용부터 장기적 고객 관계 구축의 가능성을 살펴 보았습니다. 본문 요약<ul><li>무료라도 경쟁력을 갖춰야 시간 가치를 이길 수 있다.</li><li>본질이 약하면 다음 사다리로 연결되지 않는다.</li><li>미끼 상품부터 문제 해결의 모습이나 바이럴 요소가 있어야 한다.</li></ul>https://brunch.co.kr/@cliche-cliche/219

🪜성공한 서비스 뒤에는 가치 사다리가 있다?

1 책은 저자의 생각이다. 저자의 생각 덩어리다. 책을 쓴 사람의 전부가 담겨 있다. 2 그러므로 한 권의 책...

'한 권'의 책 읽기는 '한 사람'을 만나는 일이다

1
책은 저자의 생각이다. 저자의 생각 덩어리다. 책을 쓴 사람의 전부가 담겨 있다.

2
그러므로 한 권의 책을 읽는 건, 책을 쓴 사람을 만나는 일과도 같다. 가성비 최고의 간접 경험인 셈이다.

3
새로운 어떤 사람을 만났다고 하자. 처음부터 당연히 그 사람의 전부를 알 수 없다. 시간의 투자가 필요하다. 우리 스스로도 잘 모르는 부분이 많은데, 타인은 오죽할까.

4
그렇기에 일단 새로운 사람의 단면을 볼 수밖에 없다. 그렇게 그 조각조각을 알아가는 것이 당연하다.

5
조각은 모두 다르다. 어떤 사람은 나랑 잘 맞고, 그렇지 않은 인연도 있다. 잘 맞는 부분도 있지만, 다른 부분이 더 많다.

6
책을 읽을 때도 마찬가지다. 저자의 생각을 한 번에 이해할 수는 없다. 그리고 모든 생각에 동의할 수 없다. 동의할 필요도 없고.

7
때문에 한 권의 책을 시작했다고 끝까지 다 읽을 필요는 없다. 내가 필요한 부분만 읽어도 괜찮다. 아니, 반드시 그래야만 한다.

8
중요한 건 목적이다. 책을 펼친 목적만 명확하면 괜찮다. 내가 이 책에서 무엇을 얻을지, 왜 이 책을 읽는지 명확해야 한다. 왜냐하면 목적은 나에게 의미 있는 조각을 찾는 기준이 되기 때문이다.

9
만약 목적 없이 책을 읽으면 어떨까? 내게 익숙한 생각만 좇게 된다. 거부감 없는 편한 문장에 눈이 간다. 낯설고 새로운 생각은 외면하기 쉽다.

10
공부와 운동을 잘하려면 내가 틀린 문제, 부족한 부분을 채워가야 한다. 내가 잘 알고, 잘 하는 것만 해서는 크게 발전하기 어렵다.

11
책을 읽는 것도 마찬가지다. 목적이 있어야 책에서 배울 수 있다. 내가 가져가고 싶은 것, 얻고 싶은 게 있어야 새로운 것이 보인다. 책 한 권을 읽지 않더라도 말이다.

12
책을 읽을 때 목적은 그렇다고 해도, 사람을 만날 때도 꼭 목적이 필요할까? 너무 계산적인 사람처럼 보이진 않을까?

13
그냥 딱 한 가지 목적이면 된다. 주고 얻어 가기. 내가 이 사람에게 무엇을 줄 수 있을까. 그리고 나는 무엇을 배울 수 있을까. 내가 모두 할 수 있는 일이다.

14
아무리 맞지 않는 사람에게도 늘 배울 점은 있다. 최소한 저렇게 하지는 말아야겠다는 점은 배울 수 있으니까. 모든 사람에게는 무언가 배울 점이 항상 있다. 그리고 그 방법 중에는 언제나 독서가 최고다.

1 책은 저자의 생각이다. 저자의 생각 덩어리다. 책을 쓴 사람의 전부가 담겨 있다. ​ 2 그러므로 한 권의 책을 읽는 건, 책을 쓴 사람을 만나는 일과도 같다. 가성비 최고의 간접 경험인 셈이다. ​ 3 새로운 어떤 사람을 만났다고 하자. 처음부터 당연히 그 사람의 전부를 알 수 없다. 시간의 투자가 필요하다. 우리 스스로도 잘 모르는 부분이 많은데, 타인은 오죽할까. ​ 4 그렇기에 일단 새로운 사람의 단면을 볼 수밖에 없다. 그렇게 그 조각조각을 알아가는 것이 당연하다. ​ 5 조각은 모두 다르다. 어떤 사람은 나랑 잘 맞고, 그렇지 않은 인연도 있다. 잘 맞는 부분도 있지만, 다른 부분이 더 많다. ​ 6 책을 읽을 때도 마찬가지다. 저자의 생각을 한 번에 이해할 수는 없다. 그리고 모든 생각에 동의할 수 없다. 동의할 필요도 없고. ​ 7 때문에 한 권의 책을 시작했다고 끝까지 다 읽을 필요는 없다. 내가 필요한 부분만 읽어도 괜찮다. 아니, 반드시 그래야만 한다. ​ 8 중요한 건 목적이다. 책을 펼친 목적만 명확하면 괜찮다. 내가 이 책에서 무엇을 얻을지, 왜 이 책을 읽는지 명확해야 한다. 왜냐하면 목적은 나에게 의미 있는 조각을 찾는 기준이 되기 때문이다. ​ 9 만약 목적 없이 책을 읽으면 어떨까? 내게 익숙한 생각만 좇게 된다. 거부감 없는 편한 문장에 눈이 간다. 낯설고 새로운 생각은 외면하기 쉽다. ​ 10 공부와 운동을 잘하려면 내가 틀린 문제, 부족한 부분을 채워가야 한다. 내가 잘 알고, 잘 하는 것만 해서는 크게 발전하기 어렵다. ​ 11 책을 읽는 것도 마찬가지다. 목적이 있어야 책에서 배울 수 있다. 내가 가져가고 싶은 것, 얻고 싶은 게 있어야 새로운 것이 보인다. 책 한 권을 읽지 않더라도 말이다. ​ 12 책을 읽을 때 목적은 그렇다고 해도, 사람을 만날 때도 꼭 목적이 필요할까? 너무 계산적인 사람처럼 보이진 않을까? ​ 13 그냥 딱 한 가지 목적이면 된다. 주고 얻어 가기. 내가 이 사람에게 무엇을 줄 수 있을까. 그리고 나는 무엇을 배울 수 있을까. 내가 모두 할 수 있는 일이다. ​ 14 아무리 맞지 않는 사람에게도 늘 배울 점은 있다. 최소한 저렇게 하지는 말아야겠다는 점은 배울 수 있으니까. 모든 사람에게는 무언가 배울 점이 항상 있다. 그리고 그 방법 중에는 언제나 독서가 최고다.

< 한 권의 책 읽기는 한 사람을 만나는 일이다 >

Netflix는 Java, RxJava 및 Spring Boot를 활용해 마이크로서비스 아키텍처를 발전시켰으며, GraphQL Federation으로의 전환을 통해 더욱 발전했다. 이 글에서는 Netflix의 아키텍처 변화와 Java 사용 변천사를 설명한다.

Netflix의 Java 사용 변천사 (번역)

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰

현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃

팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만,
적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다
는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다.

Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다.

전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr

📌 목차
 1. Groovy 시대 with BFF(Backend For Frontend)
 2. RxJava와 리액티브 프로그래밍 사용
 3. GraphQL Federation으로 전환
 4. Netflix가 사용하는 Java 버전
 5. Netflix가 사용하는 Spring Boot

안녕하세요 :) 저는 최근에 다시 Java와 Spring Boot를 사용하는 미국 회사로 이직하면서, 지난 2년간 스타트업에서 Ruby on Rails를 사용하며 잊고 지내던 Java와 Spring 생태계에 다시 발을 내딛었습니다. 🥰 현재 회사에서는 수많은 모놀리틱 서비스와 마이크로서비스가 함께 사용되는 상황이라 꽤 복잡한 아키텍처로 구성되어 있습니다. 그리고 새로운 Java/Spring 기반 서비스들이 빠르게 추가되고 있어서 각 서비스들 간의 통신이나 아키텍처 구성을 어떻게 개선해가면 좋을지 고민되는 상황이었는데요. 🙃 팀에 빅테크(FAANG) 출신 시니어 개발자들도 있어서 제가 이 개선을 주도하지는 않겠지만, <code >적어도 아키텍처 개선 방향에 대한 내 의견을 가지고 있어야겠다</code>는 생각으로 힌트를 얻고자 Java 기반 서비스들의 큰 형님격인 Netflix의 문을 두드렸습니다. Netflix는 Java 기반 서비스들의 아키텍처를 어떻게 발전시켜나갔는지 궁금해서 찾아보다가 이 글을 발견했고, 오랜만에 Java 생태계로 돌아온 저에게 유익했던 글이라 DeepL의 도움을 받아 번역해보았습니다. 전체 내용 보기 👉 https://www.integer.blog/evolution-of-java-usage-at-netflix/?ref=careerly.co.kr 📌 목차<ol ><li>Groovy 시대 with BFF(Backend For Frontend)</li><li>RxJava와 리액티브 프로그래밍 사용</li><li>GraphQL Federation으로 전환</li><li>Netflix가 사용하는 Java 버전</li><li>Netflix가 사용하는 Spring Boot</li></ol>

1nteger 🏄🏻‍♂️

Mobile development is a dynamic field that evolves rapidly, demanding developers to be proactive in keeping up with the latest trends, tools, and technologies. As the app landscape continuously...

How to Stay Up-to-Date as a Mobile Developer

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다.

 1.  개발자 블로그 및 뉴스레터 구독하기
     iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다.
     
     
 2.  소셜 미디어 및 온라인 커뮤니티에 참여하기
     트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...)
     
     
 3.  컨퍼런스 및 모임 참석
     온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요!
     
     
 4.  온라인 강좌를 통한 지속적 학습
     코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다!
     
     
 5.  출퇴근 시간에 팟캐스트 듣기
     통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠.
     
     
 6.  GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기
     GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다.
     
     
 7.  베타 릴리즈 사용해 보기
     얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠.
     
     
 8.  업계 보고서 읽기
     보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다.
     
     
 9.  개인적인 개발 계획 수립
     커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다.
     
     
 10. 지속적인 네트워킹
     네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다.
     
     본문에 대한 원글은 아래 링크에서 볼 수 있습니다.
     https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc

개발자가 간단하게 실천할 수 있는 최신 정보 습득 방법에 대해 가져와 봤습니다! 이미 실천하고 계신 분들도 많으실 것 같네요ㅎㅎ 빠르게 변하는 산업인 만큼 지속적으로 새로운 정보를 받아들이는 것은 중요할 것 같습니다. <ol ><li>개발자 블로그 및 뉴스레터 구독하기iOS, aOS 공식 블로그뿐만 아니라 업계 전문가가 운영하는 블로그나 뉴스레터를 정기적으로 받아보는 것은 꾸준히 정보의 흐름을 읽을 수 있는 가장 좋은 방법입니다. </li><li>소셜 미디어 및 온라인 커뮤니티에 참여하기트위터, 레딧, 스택오브플로우와 같은 개발자 커뮤니티에 가입하는 것은 개발자들과 함께 소통하면서 성장할 수 있는 좋은 방법입니다. (커리어리도 마찬가지입니다!) 관련 해시태그를 팔로우하고, 스레드에 참여해서 좋은 정보를 실시간으로 얻어보세요! (개인적으로 일론머스크의 트윗이 재밌더군요...) </li><li>컨퍼런스 및 모임 참석온라인 및 오프라인 컨퍼런스에 주기적으로 참여하면 동료 개발자들과 네트워크를 형성하고, 최신 업계 동향을 접할 수 있습니다. wwdc, google i/o뿐만 아니라 국내 기업에서 주최하는 세션이나 컨퍼런스에 참여해 보세요! </li><li>온라인 강좌를 통한 지속적 학습코세라와 같은 유명 플랫폼에서 제공하는 온라인 강좌를 통해 지속적으로 지식을 심화해 나가는 것도 좋은 방법입니다. 최신 도구나 프레임워크를 학습하는 것은 나에게 큰 도움이 될 것입니다! </li><li>출퇴근 시간에 팟캐스트 듣기통근 시간을 이용해 팟캐스트의 힘을 활용해 보세요! Fragmented, Swift by Sundell 및 Android Developers Backstage와 같은 팟캐스트에서는 최신 모바일 개발 사례나 인터뷰 및 토론을 제공합니다! 영어 공부도 덤이고요! 이 외에 주요 CEO들이 출연하여 기술에 대해 이야기하는 ACQUIRED를 추천드립니다! 최근에는 앤비디아의 젠슨 황이 출연하기도 했죠. </li><li>GitHub 리포지토리 및 오픈 소스 프로젝트를 팔로우하기GitHub만큼이나 개발자가 코드를 파보기가 좋은 데가 없죠. 도메인와 관련된 프레임워크 라이브러리 오픈소스 프로젝트의 저장소를 꾸준히 기여하고, 참여하면 코딩 기술을 업그레이드할 뿐만 아니라 새로운 코딩 표준 및 공동 개발 방식을 접할 수 있습니다. </li><li>베타 릴리즈 사용해 보기 얼리어답터가 되어 운영체제, SDK 및 개발도구의 베타 릴리즈를 실험하면 누구보다 빠른 기술을 습득할 수 있습니다. 이러한 경험을 통해 앱을 조정하고, 개발 커뮤니티에 좋은 의견들을 나눠볼 수 있죠. </li><li>업계 보고서 읽기보고서를 통해 업계 최신 동향을 광범위하게 얻을 수 있습니다. 또한 시장 행동과 타깃 유저 행동에 대한 통팔력을 통해 더 큰 그림을 이해하고, 프로젝트 방향에 대한 정보를 입각한 결정을 내릴 수 있습니다. 해외 쪽 뿐만 아니라 국내 주요 기업도 리포트를 발간하고 있으니, 참고하면 좋을 것 같습니다. </li><li>개인적인 개발 계획 수립커리어적인 성장을 위해 체계적인 계획을 개발하는 것이 중요합니다. 학습을 위한 시간을 확보하고, 강좌 및 컨퍼런스와 같은 앞선 내용들에 리소스를 할당하고 정기적으로 스스로 평가하는 시간을 가져보는 것이 좋습니다. </li><li>지속적인 네트워킹네트워킹은 최신 정보를 유지하는 데에 필수적인 요소입니다 동료 개발자와 소통하고, 적극적으로 협업 기회를 찾아보는 것입니다. 멘토링 및 협업 프로젝트에 참여하는 것도 좋습니다. 본문에 대한 원글은 아래 링크에서 볼 수 있습니다.https://medium.com/gitconnected/how-to-stay-up-to-date-as-a-mobile-developer-0d6c5ef47acc</li></ol>

개발자가 실생활에서 실천할 수 있는 스터디 방법 소개 🔑

 1. 기본기 확실히 하기
 2. 학습 능력 키우기
 3. 의사 소통 잘하기
 4. 문제 정의 잘하기
 5. 태스크 완료 시간 추정 잘하기
 6. 운영을 고려한 코드 작성하기
 7. 서비스 사고 대처 능력 키우기
 8. 결과를 내는데 집중하기
 9. 영향력 갖기 (코딩 멍키)

대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다.

내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다.

그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다.

다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다.

결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

<ol ><li>기본기 확실히 하기</li><li>학습 능력 키우기</li><li>의사 소통 잘하기</li><li>문제 정의 잘하기</li><li>태스크 완료 시간 추정 잘하기</li><li>운영을 고려한 코드 작성하기</li><li>서비스 사고 대처 능력 키우기</li><li>결과를 내는데 집중하기</li><li>영향력 갖기 <s>(코딩 멍키)</s></li></ol> 대부분의 개발자들은 굉장히 트렌디하다. 특히 한국 개발자들이 더 그렇다. 회사 일이 아무리 바쁘고 재미있어도 일에서 사용하는 기술이 최신이 아닌 레거시라고 생각하면 뒤쳐진다고 느끼고 조바심과 불안감을 많이 느낀다. 안 그래도 시간도 없고 힘도 부치는데 회사 일이 끝나면 새로운 기술을 조바심/불안감 기반으로 공부하는 경우가 아주 흔한다. 흔히 이야기하는 주경야독인데 약간 건강하지 않은 형태의 주경야독이다. 낮에는 회사 일을 하느라 바쁜 와중에 밤에는 선행학습을 하느라 바쁘다는 거다. 예를 들면 회사에서 레거시 시스템을 사용하는데 이게 커리어에 도움이 안된다고 보니 밤에 지금 마켓에서 핫한 시스템 공부를 하는 거다. 이 공부의 모티브가 중요한데 불안감이나 조바심이 주된 모티브라면 건강하지 않다. 내가 생각하는 건강한 학습은 평소 맡은 업무에 몰두하고 성취하는 경험을 통해 자신감을 쌓고 인정받고 (이에 대해서 뒤 "3. 의사 소통 잘하기"와 "4. 문제 정의 잘하기"에서 더 이야기해볼 예정이다) 이를 바탕으로 필요 중심 그리고 호기심 중심으로 학습하는 것이다. 즉 "현재"(필요성)에 집중하고 "나"(호기심)에 집중하는 거다. 여기에 약간의 조바심이나 불안감이 조미료처럼 첨가된다면 금상첨화다. 그런데 이게 가능하라면 내가 있는 환경이 중요해진다. 내가 잘 맞지 않는 환경이라면 현재에 집중하기가 쉽지 않을 것이다. 잘 맞는 환경인지 아닌지 판단하는 첫 번째는 같이 일하는 사람들이 어떤 사람들인지 특히 내 매니저가 어떤 사람인지 보는 건데 힘들어도 배울 점이 많고 성장한다는 느낌이 든다면 좋은 환경이다. 다음으로 나만의 학습방법을 만들어보는 것이 필요하다. 수능공부를 하는 것이 아니니 뭔가 두꺼운 책을 하나 사서 처음부터 끝까지 읽어야만 학습이 아니란 점, 필요한만큼 이해하고 넘어가도 된다는 점, 학습을 하다보면 항상 어느 시점에는 벽에 부딪칠 것이기에 꾸준함이 중요하다는 것 등등을 인지해야 한다. 개인적으로는 잘 모르는 주제가 생기면 유투브 등으로 짧은 영상 몇개 보고 더 깊게 들어갈 필요가 있다면 잘 아는 지인들에게 (적절히 보상을 해주고) 물어본다던지 아니면 더 긴 영상 강의(유데미, 인프런, 유투브 등등)등을 찾아서 밀도있게 학습하는 형태로 가려고 한다. 뭔가 정말 제대로 배우고 싶을텐데 다른 사람을 가르쳐보거나 톡을 하는 기회를 만들어서 강제로 학습하려고 한다. 결국 내가 인정받는 것은 내가 만든 결과물이지 어떤 기술을 알고 있느냐는 아니라는 점을 인식하고 호기심과 필요성 중심으로 학습으로 하는 습관을 갖도록 하자.

좋은 개발자가 알아야하는 9가지 포인트들 - 2. 학습 능력 키우

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음.

사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async.

자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

스레드를 5개월만에 런칭하기 위해 모놀리틱 아키텍처를 사용했고, 5일 만에 1억명의 사용자가 몰려드는 것을 수용할 수 있었음. 사용된 기술은 커스텀 버전의 Django와 PHP, 데이터 저장소로는 TAO/UDB/MySQL와 ZippyDB 그리고 피크 타임을 위한 서버리스 펑션 Async. 자, 말 할 거 많죠? ㅋㅋㅋ 한마디하고 싶은 분들 다 여기여기 붙으세요. 🤣🤣🤣

📝 메타의 스레드, 모놀리틱 아키텍처 사용

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌

자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂

📝 블로그: https://bun.sh/blog/bun-v1.1
📺 영상: https://youtu.be/yXTFOeGly9o

많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯

Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다.

📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

차세대 자바스크립트 런타임으로 주목받고 있는 Bun이 v1.1을 출시하였습니다. 하필 거짓말처럼 만우절에 출시를 하여 윈도우즈 사용자들의 애간장을 태웠는데요. 그동안 Bun을 윈도우에서 사용하려면 WSL(Windows Subsystem for Linux)가 필요했었는데, 이제는 네이티브로도 사용할 수 있게 되었습니다 🙌 자세한 내용은 아래 공식 블로그와 유튜브 영상을 참고 바랍니다. 실제 Bun을 개발하고 있는 엔지니어들이 직접 나와서 소개하고 있는데 같은 개발자로서 약간 웃프네용 😂 📝 블로그: https://bun.sh/blog/bun-v1.1📺 영상: https://youtu.be/yXTFOeGly9o 많은 분들이 Bun을 단순히 Node.js 보다 무지 빠른 자바스크립트 런타임이라고 알고 계시는데, 사실 Bun은 개발자 경험이 놀랍도록 띄어난 올인원 툴키트(all-in-one toolkit)입니다. Bun만 있으면 복잡한 과정없이 자바스크립트 뿐만 아니라 타입스크립트나 JSX로 작성된 코드를 바로 실행할 수 있으며, 패키지 매니저와 테스트 러너, 심지어 번들러까지 탑재하고 있습니다. 즉, 이 모든 귀찮은 일들이 다른 라이브러리 설치하지 않아도 Bun 하나만 있으면 해결됩니다 🤯 Bun에 대해서 더 알고 싶으시다면 아래 게시물을 추천드리겠습니다. 📕 Bun: 귀엽지만 강력한 새로운 자바스크립트 런타임: https://careerly.co.kr/comments/92202

🥟 Bun v1.1 출시 소식

디자인 시스템, 코드를 넘어서

https://so-so.dev/react/design-system-beyond-code/

같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

https://so-so.dev/react/design-system-beyond-code/ 같은 걸 3번 만드는 경험은 흔치 않죠. 그래서 글에 깊은 맛이 있답니다!!

So-so

디자인시스템 3번만든 이야기

HashMap is Hash table based implementation of the Map interface. This implementation provides all of the optional map operations, and permits null values and the null key. (The HashMap class is...

Barclays Java Spring-Boot Micro-service Interview Question with answer 2024

Finally 블록에서 예외가 발생하면 어떻게 되나요?
자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다. 
 
[Try-Catch 블록의 예외]
 * 정상적인 플로우가 중지됩니다.
 * 예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.
 * catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.
[Finally 블록의 예외]
 * 원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.
 * finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.
[키 포인트]
 * finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.
 * finally 블록의 예외는 원래의 예외를 억제합니다.
 * finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.
[Finally 블록의 쓰임새]
 * 리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.
 * 예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.
 
자바의 다이아몬드 문제란 무엇인가요?
"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다.

 1. 자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다. 
 2. 자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.
interface InterfaceA {
    default void display() {
        System.out.println("Inside InterfaceA");
    }
}

interface InterfaceB {
    default void display() {
        System.out.println("Inside InterfaceB");
    }
}

class MyClass implements InterfaceA, InterfaceB {
    // Here, we must provide our own implementation of display to resolve the ambiguity.
    @Override
    public void display() {
        InterfaceA.super.display(); // calling InterfaceA's default implementation
        InterfaceB.super.display(); // calling InterfaceB's default implementation
    }
}

어떻게 해결할 수 있을까요?

1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        System.out.println("Hello world");
    }
}

2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다. 
class MyClass implements InterfaceA, InterfaceB {
    @Override
    public void display() {
        InterfaceA.super.display(); // or InterfaceB.super.display()
        // Additional logic if needed
    }
}

 
Multilevel 상속이란 무엇인가요?
Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.
 
자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.
 
String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?
(번역/원문 참고)
 
메서드 오버라이딩과 오버로딩은 무엇인가요?
[메서드 오버로딩]
 * 단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.
 * 메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.
class Calculator {
  public int add(int a, int b) {
    return a + b;
  }

  public double add(double a, double b) {
    return a + b;
  }
}

[메서드 오버라이딩]
 * 상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.
 * 메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.
class Animal {
  public void makeSound() {
    System.out.println("Generic animal sound");
  }
}

class Dog extends Animal {
  @Override
  public void makeSound() {
    System.out.println("Woof!");
  }
}

 
예외 클래스의 계층구조는 무엇인가요?
Arraylist와 Linkedlist의 차이는 무엇인가요?
Set과 Arraylist의 차이는 무엇인가요?
(번역/원문 참고)
 
번역: [https://ducktopia.tistory.com/119]
원문:

Finally 블록에서 예외가 발생하면 어떻게 되나요?자바에서, try-catch에서 finally 블록 내에서 예외가 발생할 때의 동작은, try-catch 블록의 예외 처리와 약간 다릅니다.&nbsp;&nbsp;[Try-Catch 블록의 예외]<ul ><li>정상적인 플로우가 중지됩니다.</li><li>예외 유형과 일치하는 catch 블록이 있다면, 해당 블록 내의 코드가 실행됩니다. 이를 통해 예외를 처리할 수 있습니다.</li><li>catch 블록이 완료되거나 어떤 catch 블록과도 일치하지 않으면 finally 블록의 코드가 실행됩니다.</li></ul>[Finally 블록의 예외]<ul ><li>원래의 예외가 중지됩니다. 이는 원래의 예외가 메서드 호출자에게 전달되지 않는 것을 의미합니다.</li><li>finally 블록에서 던진 예외가 호출자에게 전파되는 새로운 예외가 됩니다.</li></ul>[키 포인트]<ul ><li>finally 블록은 try-catch 블록에서 예외가 발생하는지 여부에 관계없이 항상 실행됩니다.</li><li>finally 블록의 예외는 원래의 예외를 억제합니다.</li><li>finally 블록에서 던진 예외는 호출자가 처리해야 하는 새로운 예외가 됩니다.</li></ul>[Finally 블록의 쓰임새]<ul ><li>리소스(데이터베이스 연결, 파일 클로징)를 해제합니다.</li><li>예외에 관계없이 항상 수행해야 하는 정리 작업을 처리합니다.</li></ul>&nbsp;자바의 다이아몬드 문제란 무엇인가요?"다이아몬드 문제"란 여러 상속 시나리오에서 발생하는 특정한 문제를 의미합니다. 클래스 상속 다이어그램을 그릴 때 발생하는 다이아몬드 모양에서 이름을 따왔습니다. <ol ><li>자바의 접근방식: 자바는 클래스의 다중상속을 지원하지 않습니다. 그러나 자바는 인터페이스의 다중상속은 허용합니다.&nbsp;</li><li>자바 인터페이스의 다이아몬드 문제: 클래스가 두 개의 인터페이스를 구현하고 두 인터페이스가 모두 동일한 메소드명을 가진다면, 구현 클래스는 모호성을 해결하기 위해 메서드를 자체적으로 구현해야 합니다.</li></ol><pre ><code class="language-java">interface InterfaceA {
 default void display() {
 System.out.println("Inside InterfaceA");
 }
}

interface InterfaceB {
 default void display() {
 System.out.println("Inside InterfaceB");
 }
}

class MyClass implements InterfaceA, InterfaceB {
 // Here, we must provide our own implementation of display to resolve the ambiguity.
 @Override
 public void display() {
 InterfaceA.super.display(); // calling InterfaceA's default implementation
 InterfaceB.super.display(); // calling InterfaceB's default implementation
 }
}</code></pre>어떻게 해결할 수 있을까요? 1. 메서드 오버라이딩: 구현 클래스에서 자신만의 구현을 제공하여 모호함을 해결합니다. 이 방식은 기본 구현 중 하나를 선택하거나 완전히 새로운 구현을 제공하고자 할 때 적합합니다.<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 System.out.println("Hello world");
 }
}</code></pre>2. 특정 인터페이스의 메서드 호출: 특정한 인터페이스의 메서드를 호출합니다.&nbsp;<pre ><code class="language-java">class MyClass implements InterfaceA, InterfaceB {
 @Override
 public void display() {
 InterfaceA.super.display(); // or InterfaceB.super.display()
 // Additional logic if needed
 }
}</code></pre>&nbsp;Multilevel 상속이란 무엇인가요?Multilevel 상속에서 A 클래스는 B 클래스를 상속하며, B 클래스 역시 C 클래스를 상속합니다.&nbsp;자식 클래스는 부모 클래스를 통해 조부모 클래스에서 간접적으로 상속됩니다. 자식 클래스는 부모 및 조부모 클래스의 모든 public/protected 멤버에 접근할 수 있습니다.&nbsp;String, Stringbuffer, Stringbuilder의 차이는 무엇인가요?(번역/원문 참고)&nbsp;메서드 오버라이딩과 오버로딩은 무엇인가요?[메서드 오버로딩]<ul ><li>단일 클래스 내에서 발생합니다. 이름은 같지만 매개 변수가 다른 동일한 클래스의 여러 메서드를 말합니다.</li><li>메서드 오버로딩을 사용하면 유사한 작업을 수행하지만 입력/출력이 다른 메서드를 만들 수 있습니다.</li></ul><pre ><code class="language-java">class Calculator {
 public int add(int a, int b) {
 return a + b;
 }

 public double add(double a, double b) {
 return a + b;
 }
}</code></pre>[메서드 오버라이딩]<ul ><li>상속에서 클래스 간에 메서드 오버라이딩이 발생합니다. 하위 클래스가 상위 클래스에서 상속된 메서드를 재정의하는 것을 말합니다. 메서드는 상위 클래스 메서드와 동일한 이름, 반환 유형 및 매개 변수를 갖습니다.</li><li>메서드 오버라이딩을 사용하면 하위 클래스가 상위 클래스에서 상속된 메서드를 자체적으로 구현하여 하위 클래스에 대한 동작을 전문화할 수 있습니다.</li></ul><pre ><code class="language-java">class Animal {
 public void makeSound() {
 System.out.println("Generic animal sound");
 }
}

class Dog extends Animal {
 @Override
 public void makeSound() {
 System.out.println("Woof!");
 }
}</code></pre>&nbsp;예외 클래스의 계층구조는 무엇인가요?Arraylist와 Linkedlist의 차이는 무엇인가요?Set과 Arraylist의 차이는 무엇인가요?(번역/원문 참고)&nbsp;번역: [https://ducktopia.tistory.com/119]원문:

🕊️ 2024 버클리즈 Java SpringBoot 인터뷰 질문 

Learn to become an Data Analyst using this roadmap. Community driven, articles, resources, guides, interview questions, quizzes for modern backend development.

Data Analyst Roadmap

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?
최근 데이터분석가의 로드맵도 업데이트되어 공유합니다!

사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요!

https://roadmap.sh/data-analyst

개발자분들은 roadmap.sh에 대해 이미 아시겠죠?최근 데이터분석가의 로드맵도 업데이트되어 공유합니다! 사실 이렇게 보면.. 개발자 로드맵보다 조금 정립되어있지 않은 느낌도 드는데, 그래도 참고해보면 좋을 것 같아요! https://roadmap.sh/data-analyst

roadmap.sh

데이터분석가 로드맵 🤓

1. 감정은 전염되기 때문에 매우 중요하다.

2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다.

3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다.

4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다.

5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다.

6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다.

#권력을경영하는7가지원칙

1. 감정은 전염되기 때문에 매우 중요하다. 2. 사람들은 자신과 연관된 것들을 자랑스러워하고 자신과 동료들이 성공할 것이라고 믿고 싶어 한다. 3. 그래서 조직을 이끄는 리더에게 주어진 가장 중요한 임무 하나가 자신감을 보여 주는 것이다. 4. 사람들은 자신감 넘치는 사람을 따르고 지지하고 싶어 한다. 5. 그렇기 때문에 자신감 있어 보이는 사람들이 취직하고 승진할 가능성이 크다. 6. 이뿐만 아니라 리더가 자신감 있게 행동하면 그 자신감이 전염되어 그를 따르는 다른 사람들도 더 자신감 있게 행동한다. #권력을경영하는7가지원칙

< 리더의 자신감은 전염된다 >

Optimism, obsession, self-belief, raw horsepower and personal connections are how things get started. Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are...

What I Wish Someone Had Told Me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다.

2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다.

3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요.

4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다)

5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과)

6. 커뮤니케이션은 명확하고 깔끔하게 하세요.

7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요.

8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다)

9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요!

10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다.

11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요)

12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다)

13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다.

14. 스케일은 급부상하고 있는 신흥 자산입니다.

15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요.

16. 쓰러져도 다시 일어나 계속 나아가세요.

17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다.

- 샘 알트만

https://blog.samaltman.com/what-i-wish-someone-had-told-me

1. 일은 낙관, 집념, 신념, 거친 돌파력, 인간적 연결에서부터 시작됩니다. 2. 하지만 일을 마무리하는 것은 단합된 팀, 빠른 속도와 차분함의 조합, 무한한 헌신입니다. 3. (사람들이 착각하지만) 팀에게는 ‘중요한데 어려운 일을 하는 것’이 ‘중요하지 않지만 쉬운 일을 하는 것’보다 훨씬 더 쉽습니다. 담대한 목표는 사람들의 동기를 자극하니까요. 4. 인센티브는 슈퍼 파워지만, 신중하게 설정해야 합니다. (그게 고객이든, 직원이든, 한 번 도입한 인센티브를 되돌리긴 쉽지 않기 때문입니다) 5. (너무 많은 일을 동시에 벌이려고 하지 말고) 확신을 가지는 소수의 몇 가지에 자원을 집중하세요. 하지만 말이 쉽지, 이를 행동으로 옮기는 건 쉽진 않을 겁니다. 생각했던 것보다 훨씬 더 많은 것들을 (뼈를 깎는 고통을 감수하며) 제거해야 할 테니까요. (=존 우든 효과) 6. 커뮤니케이션은 명확하고 깔끔하게 하세요. 7. 조직의 구조가 구성원들이 생산적으로 일하는 것을 방해하게 않도록 하세요. 특히 관료주의와 헛소리에 대해선 발견할 때마다 싸우고, 구성원들 또한 이를 발견할 때마다 싸우도록 만드세요. 8. 비즈니스에서 중요한 건 결과입니다. 과정이 좋았다며, 나쁜 결과를 변명하도록 내버려두지 마세요. (결과가 안 좋았다면, 분명 프로세스에 문제가 있는 겁니다. 따라서 과정이 좋았다는 위로가 아니라, 문제를 파악하고 개선해야 더 나은 결과를 얻을 수 있습니다) 9. 채용에 더 많은 시간을 투자하고, 빠르게 성장할 가능성이 보이는 사람들을 영입하기 위해 위험을 무릎 써보세요! 10. 슈퍼스타는 보이는 것보다 훨씬 더 큰 가치를 가지지만, 그들에 대한 평가는 조직의 성과에 어떤 기여를 했는지를 두고 정확하게 내려야 합니다. 11. 빠른 반복은 많은 문제를 해결합니다. 특히 빠르게 반복할 수 있으면, 틀려도 상관없습니다. (빠르게 반복하는 과정에서 틀린 것들을 계속 수정할 테니까요) 12. 물리 법칙에 해당하는 비즈니스와는 싸우지 마세요. (비과학적인 믿음으로 사업을 하지 말라는 말입니다) 13. 영감은 쉽게 깨지고, 삶은 놀랍도록 빠릅니다. 그리고 아무것도 하지 않은 것이야말로 최악의 위험입니다. 14. 스케일은 급부상하고 있는 신흥 자산입니다. 15. 복리는 마법입니다. 그러니 규모와 복리가 만나는 비즈니스를 하세요. 16. 쓰러져도 다시 일어나 계속 나아가세요. 17. 위대한 사람들과 함께 일하는 것은 인생에서 가장 큰 축복 중 하나입니다. - 샘 알트만 https://blog.samaltman.com/what-i-wish-someone-had-told-me

Sam Altman

창업을 하고자 하는 사람들에게 해주고 싶은 말들

Every week I'll provide updates on the latest trends in cloud software companies. Follow along to stay up to date! Fed Update On Wednesday the fed hiked rates 75bps. This was expected. Prior to Wednesday, the consensus was a 75bps hike in November, 50bps 

Clouded Judgement 11.4.22

1. 현재 상장 중인 북미 SaaS 기업에서 Q3의 결산 발표를 한 곳이 약 30개사 정도 됩니다. 

2. 미국에서 경기 침체가 조금 나타나기 시작했다고 정리된 글이 있네요. Q3의 예상 컨센서스를 중앙값으로 2.5% 웃도는데요. 

3. 반면 Q4 가이던스를 발표한 기업 중 절반이 예상 컨센서스를 밑돌고 또 절반이 웃돌았다고 합니다. 

4. 지금까지는 다음 분기의 가이던스를 2~2.5% 올리는 기업이 많았는데, 현시점에서 중앙치가 불과 0.1% 수준이라고 하네요. 

5. 경기 침체의 영향이 미국 SaaS 업계 어디까지 영향을 미칠 것인지 향후 결산 발표에 주목해 봐도 좋을 것 같습니다.

Substack

책과 만화, 신문과 잡지, 영화와 드라마, 팟캐스트와 오디오북, 트위터와 페이스북을 가리지 않고 콘텐츠를 즐기면서도 동시에 까다로운 소비자입니다. 일 하는 사람들의 콘텐츠 플랫폼, 퍼블리를 만들고 있습니다. 대학에서 경영학을, 대학원에서 공공정책학을 공부했고 경영 컨설턴트로 일했습니다.

퍼블리 CEO & Founder

박소령

컨텐츠와 커뮤니티를 통해서, 커리어 시장에서 정보와 기회의 격차를 해결하고, 개인과 기업 간 미스매칭 문제를 풀고 있습니다. 커리어리와 퍼블리가 잘 되게 하는 일은 무엇이든 다 하고, 안되는 일은 되게 합니다. 

😩경기 침체인가? 미국 SaaS Q3 결산 상황

Writing articles about Japan design events and trend

Global Design Repoter

Samsung Global Design Membership.
Good Design Exhibition 2012 ( MEDICAL LINK SERVICE_Stage presentation)

Product Design Intern

신규 앱 기획 및 프로모션 디렉션

- 카메라 브랜드 | App Store(iOS) 사진/비디오 카테고리 무료 1위, 프로모션 플래닝
- 글로벌 스포츠 브랜드 | 소셜 마케팅 & 오프라인 크리에이티브 제작

BX Designer

Figma

프로덕트 디자인

UI 디자인

UX 디자인

문제 정의하기

서비스 기획

커뮤니케이션

프로젝트 매니징

- Self-Service 제품 전략 및 설계 담당
- 잠재 고객 획득을 위한 Freemium 모델 도입
- 구매 전환 향상을 위한 제품 개선 다수
- 새로운 데이터 모델 개발 및 대시보드 사용자 경험 통합
- App Ape 한국 사업 전략 총괄

Product Manager / Designer

디자인 공학 석사

김영빈

Portfolio

LinkedIn

📝 Brunch | Jayden

📰 Facebook | PM Post. 프로덕트 매니저 포스트

📷 Instagram

도쿄에 살고 있으며 B2B SaaS 스타트업의 PdM로서 모바일 앱 분석 서비스를 개발하고 있습니다. 일본 IT 대기업에서 BX 디자이너로 커리어를 시작하였고, 레드닷 디자인 어워드의 수상 경력을 가지고 있습니다. PdM의 관점으로 보고 느끼는 부분을 공유합니다.


😩경기 침체인가? 미국 SaaS Q3 결산 상황

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필