NAVER D2

﻿
순간적으로 트래픽이 급증하는 서비스를 운영하다 보면 단순히 서버를 늘리는 것만으로 해결이 안되는 경우가 있습니다. 또한 동시성 해결을 위해서 다양한 락(Lock)을 적용하여 처리한다고 해도 서비스를 온전히 사용하는 사용자가 있는 반면, 비즈니스 로직이나 상황에 따라서는 일부 사용자들은 정상적으로 사용이 어려운 경우가 생기기 마련인데요. 인기 있는 음식점을 가면 한정된 공간 안에 손님들을 모시기 위해 대부분 마련한 번호표 시스템처럼 서비스에도 "대기열 시스템" 을 적용해 보는 것도 검토의 대상이라 생각을 해봅니다.

네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다.

특히, 일반적인 폴링 형태로 사용자가 대기열을 통과 가능한지 체크하는 방식이 아닌 사용자와 대기열 사이에 중계 서버를 둬서 순번에 맞는 사용자만 통과시키는 방식이라든지 대기표 관리를 범위로써 관리하여 데이터베이스 관점에서 좀 더 유연한 구조를 가져간 점이 특징이라 볼 수 있는 것 같습니다.

https://d2.naver.com/helloworld/6480558

﻿순간적으로&nbsp;트래픽이&nbsp;급증하는&nbsp;서비스를&nbsp;운영하다 보면&nbsp;단순히&nbsp;서버를&nbsp;늘리는&nbsp;것만으로&nbsp;해결이&nbsp;안되는&nbsp;경우가&nbsp;있습니다.&nbsp;또한&nbsp;동시성&nbsp;해결을&nbsp;위해서&nbsp;다양한&nbsp;락(Lock)을&nbsp;적용하여&nbsp;처리한다고&nbsp;해도&nbsp;서비스를&nbsp;온전히&nbsp;사용하는&nbsp;사용자가&nbsp;있는&nbsp;반면,&nbsp;비즈니스&nbsp;로직이나&nbsp;상황에&nbsp;따라서는&nbsp;일부&nbsp;사용자들은&nbsp;정상적으로&nbsp;사용이&nbsp;어려운&nbsp;경우가&nbsp;생기기&nbsp;마련인데요.&nbsp;인기 있는&nbsp;음식점을&nbsp;가면&nbsp;한정된&nbsp;공간 안에&nbsp;손님들을&nbsp;모시기&nbsp;위해&nbsp;대부분&nbsp;마련한&nbsp;번호표&nbsp;시스템처럼&nbsp;서비스에도&nbsp;"대기열&nbsp;시스템"&nbsp;을&nbsp;적용해 보는&nbsp;것도&nbsp;검토의&nbsp;대상이라&nbsp;생각을&nbsp;해봅니다. 네이버페이 주문에 적용된 확장 대기열 개발기라는 주제로 확장성에 초점을 두고 시스템 설계 측면에서 설명하는 글이 있어 공유합니다. 특히,&nbsp;일반적인&nbsp;폴링 형태로&nbsp;사용자가&nbsp;대기열을&nbsp;통과&nbsp;가능한지&nbsp;체크하는&nbsp;방식이&nbsp;아닌&nbsp;사용자와&nbsp;대기열&nbsp;사이에&nbsp;중계&nbsp;서버를&nbsp;둬서&nbsp;순번에&nbsp;맞는&nbsp;사용자만&nbsp;통과시키는&nbsp;방식이라든지&nbsp;대기표&nbsp;관리를&nbsp;범위로써&nbsp;관리하여&nbsp;데이터베이스&nbsp;관점에서&nbsp;좀 더&nbsp;유연한&nbsp;구조를&nbsp;가져간&nbsp;점이&nbsp;특징이라&nbsp;볼 수&nbsp;있는 것&nbsp;같습니다. https://d2.naver.com/helloworld/6480558

d2.naver.com

네이버페이 주문에 적용된 확장 가능한 대기열 개발기

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다.

웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다.

React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다.

이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다.

모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다.

웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.
 * Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.
 * Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.
 * HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.
이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다.

이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다.

📝 포스팅: https://www.daleseo.com/web-components/

컴포넌트 기반 UI 개발의 패러다임을 주도한 React가 등장한지도 어느 덧 10년이 넘었네요. 이제 Vue.js, Svelte, Angular 등 어떤 프론트엔드 프레임워크를 사용하든 현대 웹 개발에서 컴포넌트 기반으로 UI 개발하는 것은 거의 당연한 얘기가 되었죠. 그리고 마침내 웹 컴포넌트(Web Components)를 통해서 별다른 프론트엔드 프레임워크가 없어도 UI 컴포넌트를 만들 수 있는 길이 활짝 열렸습니다. 웹 컴포넌트는 웹사이트나 애플리케이션에서 UI를 모듈화하고 재사용할 수도록 해주는 웹 표준 기술입니다. React와 같은 프론트엔드 프레임워크에서 오랫동안 경험해왔던 UI 컴포넌트를 떠올리시면 이해가 쉬우실 것 같습니다. React 컴포넌트는 React에서만 쓸 수 있고, Vue.js 컴포넌트는 Vue.js에서만 쓸 수 있는 근본적인 한계가 있습니다. 하지만 웹 컴포넌트는 이와 같은 구애를 받지 않고 어떤 프론트엔드 프레임워크와도 함께 쓸 수 있습니다. 왜냐하면 웹 컴포넌트는 브라우저에서 네이티브(native)하게 작동하기 때문입니다. 이러한 웹 컴포넌트의 띄어난 호환성과 이식성, 재사용성 및 생산성 덕분에 최근에는 디자인 시스템(Design System)을 구현하는 최고의 기술로 주목받고 있습니다. 모든 기술이 그러하든 웹 컴포넌트가 장점만 있는 것은 아닙니다. 대표적인 단점으로 API가 직관적이지 않다고 평가받고 있고, 배우기 쉬운 기존 프런트엔드 프레임워크 대비 진입 장벽이 높은 편입니다. 그래서 실제 프로젝트에서는 이러한 단점을 보완한기 위해서 웹 컴포넌트를 직접 작성하기 보다는 Lit나 Stencil과 같은 라이브러리를 많이 사용합니다. 웹 컴포넌트은 크게 다음 세 가지 핵심 기술로 이루어집니다.<ul ><li>Custom Elements: 사용자 정의 HTML 요소(element) 또는 태그(tag)를 정의할 수 있습니다.</li><li>Shadow DOM: DOM 트리의 일부를 캡슐화하여 스타일과 마크업이 외부와 충돌하지 않도록 해줍니다.</li><li>HTML Templates: 화면에 나타나지 않는 HTML 조각(fragment)을 정의해놓고 재사용할 수 있습니다.</li></ul>이 웹 표준 기술들은 현재 주요 브라우저에서 모두 지원되고 있습니다. 이번 포스팅에서는 각각의 기반 기술을 하나씩 살펴보면 웹 컴포넌트의 기본 개념을 잡아보도록 하겠습니다. 📝 포스팅: https://www.daleseo.com/web-components/

웹 컴포넌트 (Web Components)

알림과 실시간 채팅 같은 서비스를 구현할 때, 우리는 자연스럽게 두 가지 기술 사이에서 고민에 빠지게 됩니다. SSE와 WebSocket은 각기 다른 매력을 지닌 두 명의 주인공과 같습니다. 이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다. 실시간 통신의 필요성여러분의 앱이 최신 주식 가격을 보여주거나 "우리 동네에 눈이 내립니다!" 같은 알림을 띄워야 한다면, 실시간 통신은 선택이 아니라 필수입니다. 그런데 문제는 단방향이냐, 양방향이냐! 양방향 통신을 택하면 더 복잡하지만 매력적이고, 단방향 통신은 더 기능이 적지만 그만큼 단순합니다. 둘 중 어느 쪽을 고를지 결정하기 위해선 기술들의 성격을 ..

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되었을까?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.
 
SSE (Server-Sent Events)
SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.
 * 학생: 선생님, 질문이 있습니다
 * SSE: 미안, 넌 질문할 수 없어!
 
 
SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.
 
서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i <= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}

const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};

장점:
 * SSE는 자동 재연결을 지원합니다.
 * 설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.
단점:
 * 오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)
 * 데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.
 
WebSocket
WebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.
 * A: "지금 뭐 해?"
 * B: "지금 네 메시지 받았어. 다시 보낼게!"

이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.
@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}

const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () => {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) => {
 console.log('받은 메시지:', event.data);
};

장점:
 * 양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.
 * 텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)
단점:
 * 설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.
 * 재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.
 
마무리 및 결론
 * SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.
 * 반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.
 
저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.
 
이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?

이 포스팅에서는 SSE와 WebSocket의 특징과 사용법을 비교해 보면서, ‘내 프로젝트에서는 어떤 녀석이 주인공일까?’에 대한 답을 찾아보도록 하겠습니다.&nbsp;SSE (Server-Sent Events)SSE는 마치 선생님이 수업 시간 내내 일방적으로 학생들에게 말하는 것과 같습니다. 학생(클라이언트)은 계속해서 듣고 받아 적어야 하죠.<ul ><li>학생: 선생님, 질문이 있습니다</li><li>SSE: 미안, 넌 질문할 수 없어! </li></ul>SSE는 서버가 클라이언트에게 일방적으로 데이터를 푸시할 때 쓰입니다. HTTP 기반이라서 프록시나 방화벽이 거부하지 않습니다.&nbsp;서버에서 매초마다 데이터를 보낸다고 상상해 볼까요?<pre ><code class="language-javascript">import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

import java.io.IOException;
import java.io.PrintWriter;
import javax.servlet.http.HttpServletResponse;

@RestController
public class SSEController {

 @GetMapping("/sse")
 public void streamEvents(HttpServletResponse response) throws IOException {
 response.setContentType("text/event-stream");
 response.setCharacterEncoding("UTF-8");

 PrintWriter writer = response.getWriter();
 for (int i = 1; i &lt;= 5; i++) {
 writer.write("data: SSE 이벤트 #" + i + "\n\n");
 writer.flush();
 try {
 Thread.sleep(1000); // 1초마다 이벤트 전송
 } catch (InterruptedException e) {
 Thread.currentThread().interrupt();
 }
 }
 writer.close();
 }
}</code></pre><pre ><code class="language-javascript">const eventSource = new EventSource('/sse');

eventSource.onmessage = function(event) {
 console.log("새 이벤트 수신:", event.data);
};

eventSource.onerror = function() {
 console.error("SSE 연결 오류 발생");
};</code></pre>장점:<ul ><li>SSE는 자동 재연결을 지원합니다.</li><li>설정이 간단해서 빨리 구현하고 싶은 개발자에겐 최적입니다.</li></ul>단점:<ul ><li>오직 단방향입니다. 클라이언트는 서버에 말을 걸 수 없어요. (서운하지만 어쩔 수 없습니다.)</li><li>데이터를 텍스트로만 보내는 게 편합니다. 이미지나 비디오 전송은 꿈도 꾸지 마세요.</li></ul>&nbsp;WebSocketWebSocket은 연애 초기의 커플 같아요. 둘이 채팅하느라 시간 가는 줄 모르죠. 양방향 통신이 가능하기 때문에 서버와 클라이언트가 자유롭게 대화를 주고받습니다.<ul ><li>A: "지금 뭐 해?"</li><li>B: "지금 네 메시지 받았어. 다시 보낼게!"</li></ul> 이제 서버와 클라이언트가 한바탕 신나게 대화하는 예제를 보겠습니다.<pre ><code class="language-java">@Configuration
@EnableWebSocket
public class WebSocketConfig implements WebSocketConfigurer {
 @Override
 public void registerWebSocketHandlers(WebSocketHandlerRegistry registry) {
 registry.addHandler(new TextWebSocketHandler() {
 @Override
 protected void handleTextMessage(WebSocketSession session, TextMessage message) 
 throws Exception {
 session.sendMessage(new TextMessage("에코: " + message.getPayload()));
 }
 }, "/ws");
 }
}</code></pre><pre ><code class="language-java">const socket = new WebSocket('ws://localhost:8080/ws');

socket.onopen = () =&gt; {
 console.log('WebSocket 연결 성공!');
 socket.send('안녕, 서버!');
};

socket.onmessage = (event) =&gt; {
 console.log('받은 메시지:', event.data);
};</code></pre>장점:<ul ><li>양방향이라 서버와 클라이언트가 마음껏 수다를 떨 수 있습니다.</li><li>텍스트뿐만 아니라 바이너리 데이터도 전송할 수 있어요. (그림도 보낼 수 있다는 얘기죠!)</li></ul>단점:<ul ><li>설정이 조금 귀찮습니다. 방화벽에 걸리기 쉽고, 초기 핸드셰이크까지 해야 하니까요.</li><li>재연결? 그런 거 없습니다. 알아서 다시 연결할 방법을 짜야 해요.</li></ul>&nbsp;마무리 및 결론<ul ><li>SSE는 "너 듣기만 해, 내가 다 말해줄게" 스타일에 적합합니다. 실시간 뉴스나 알림처럼 서버에서 클라이언트로만 정보가 흐를 때 좋습니다.</li><li>반면에, WebSocket은 "같이 떠들자!" 스타일입니다. 채팅, 게임처럼 상호작용이 필요한 경우 선택하세요.</li></ul>&nbsp;저는 개인적으로 어드민 UI에서 서버 로그를 실시간으로 출력할 때 SSE를 사용했습니다. 클라이언트가 서버에게 말할 필요가 없었기 때문에 SSE가 완벽한 선택이었습니다. 만약 반대로 채팅 앱을 만들었다면? WebSocket이 당연히 주인공이 되었겠죠.&nbsp;이제 여러분도 SSE와 WebSocket 중 누구를 주인공으로 선택할지 결정할 수 있겠죠?&nbsp;&nbsp;

덕토피아

SSE와 WebSocket, 그들은 왜 실시간 통신의 라이벌이 되

요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 

눈코 뜰 새 없이 매일을 살아가다, 턱 막히는 순간들이 옵니다. 지금까지는 외부 요인에 집중했는데 시장, 제품, 팀, 투자자 탓 말고 원인을 창업가 본인에 두면 해결의 실마리도보이는 것 같아요. 

1)… | 댓글 11

LinkedIn Hannah Choi 페이지: 요즘 연습 중인 생각의 회로: 다 대표 탓이라고 생각하면 돌파구가 나옵니다. 눈코 뜰 새 없이 매일을 살아가다, 턱 막히는… | 댓글 11

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다.

시장 "요즘 비시즌이라 섭외 볼륨이 없어요"
 * 계절성에 대해 대응을 하지 못한 탓
 * 시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?

프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."
 * 사업 상황에 맞지 않는 우선순위를 선정한 내 탓
 * 더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?
 * 채용 계획을 다시 점검해볼까 ?
 * 프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?

투자 "이번 라운드는 어려울 것 같습니다"
 * 해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓
 * 현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?
 * 우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?

사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

스타트업을 운영 중이신 한 대표님께서 말씀하시길, 난관에 봉착했을 때 이전에는 외부 요인에 집중했었지만, 이제는 시장, 제품, 팀, 투자자를 탓하지 않고 원인을 창업가 본인에게서 찾아 해결의 실마리를 발견해 나간다고 합니다. 시장 "요즘 비시즌이라 섭외 볼륨이 없어요"<ul ><li>계절성에 대해 대응을 하지 못한 탓</li><li>시즌이 국가 한정이라면, 린하게 확장할 수 있을까? 반드시 상업 촬용 중개 수수료에만 BM을 한정해야 할까?</li></ul> 프로덕트 "고객님 거기까지는 아직 프로덕트 대응이 안돼서..."<ul ><li>사업 상황에 맞지 않는 우선순위를 선정한 내 탓 </li><li>더욱 타이트하게 제품-사업 팀의 소통을 열 수 없었을까?</li><li>채용 계획을 다시 점검해볼까 ?</li><li>프로덕트 없이 손으로 당장 고객에게 벨류를 가져다 줄 방법은 없을까?</li></ul> 투자 "이번 라운드는 어려울 것 같습니다"<ul ><li>해당 투자사가 원하는 제품, 시장, 벨류와 맞지 않는 피칭을 전달한 내 탓</li><li>현재 우리 상황을 더 선호하는 투자사들을 만날 수 있게 아웃바운드 볼륨을 높여볼까?</li><li>우리 팀의 미래에 대해 설득력을 높일 수 있는 방법은 없을까?</li></ul> 사업은 마음만큼 따라와 주지 않는 일이 90%지만, 이런 저런 핑계말고 내 손으로 더 할 수 있는 일을 찾아보고 있습니다. 시장이 당장 바뀌기 어려워도, 제품이 하루 아침에 업데이트 되기는 힘들어도, 돌아선 투자사의 마음을 바꾸기는 어려워도 적어도 창업자 자신은 지금 당장 무엇인가 시도해볼 수 있기 때문입니다.

www.linkedin.com

다 대표 탓이라고 하면 돌파구가 나옵니다.

단순히 취업이 아닌,
꾸준히 성장하는 핵심 인재가 되고 싶다면,

다각도에서 내 역량이 어떻게 성장하고 있는지
스스로 파악하는 메타 인지가 필요해요.

DATA/AI 분야 뿐만 아니라,
다양한 영역에서 내가
어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요.

- 하드 스킬
- 소프트 스킬
- 커리어 스킬

기업이 뽑고 싶어하는,
아니 기업이 뽑을수 밖에 없는 인재들은
이런 디테일을 가지고 있답니다.

하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요.

이렇게 스스로 분석하고 객관적으로 바라볼수 있다면,
결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

단순히 취업이 아닌, 꾸준히 성장하는 핵심 인재가 되고 싶다면, 다각도에서 내 역량이 어떻게 성장하고 있는지 스스로 파악하는 메타 인지가 필요해요. DATA/AI 분야 뿐만 아니라, 다양한 영역에서 내가 어떤 스킬을 얼마나 갖추고 있는지를 생각해보세요. - 하드 스킬 - 소프트 스킬 - 커리어 스킬 기업이 뽑고 싶어하는, 아니 기업이 뽑을수 밖에 없는 인재들은 이런 디테일을 가지고 있답니다. 하드 스킬, 소프트 스킬, 그리고 커리어 스킬을 각각 성장의 관점에서 바라보고 주기적으로 점검하는 습관을 들여보세요. 이렇게 스스로 분석하고 객관적으로 바라볼수 있다면, 결국 기업에서 찾는 '핵심 인재'로 자리매김하게 될 거예요.

꾸준히 성장하는 핵심 인재의 특징

Last week, I interviewed a friend who got to Staff (IC6) at Google by 28 in an unusual way.

What You Work On >> How Hard You Work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다.

1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기
 * 핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.
 * 작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.
 * 시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.
 * 매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.
2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬
 * 오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.
 * 균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.
 * 시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.
자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요?

https://www.developing.dev/p/what-you-work-on-how-hard-you-work

기술 경로에서 빠르게 성공한 개발자들의 전략이 무엇인지 궁금하지 않으신가요? 이번 이야기는 구글에서 20대 후반에 IC6(Staff) 단계까지 오른 한 개발자의 경험을 담고 있습니다. 그가 일주일에 평균 40시간도 일하지 않으면서도 어떻게 빠르게 승진할 수 있었는지, 핵심은 단순히 성실한 업무량이 아닌, 전략적인 선택과 소통 능력이었다고 합니다. 1) 결과 중심적 사고와 큰 임팩트를 만드는 일 선택하기<ul ><li>핵심 목표 이해: 그는 조직에서 가장 중요하게 여기는 결과와 그것을 달성하기 위해 필요한 핵심 작업을 우선 파악했습니다.</li><li>작은 일 거절하기: 영향력이 적은 일은 거절하고, 승진 가능성을 높일 수 있는 프로젝트에 집중했습니다.</li><li>시간은 제한적: 누구에게나 주어진 시간은 동일하기에, 중요한 일을 선별하고 집중하는 것이 높은 성과를 내는 유일한 방법이라고 합니다.</li><li>매니저와의 대화: 그가 일의 임팩트를 평가하는 능력을 키운 방법은 매니저나 기술 리더와의 대화를 통해서였습니다. 이는 다음 단계를 준비하는 데 중요한 과정이라고 합니다.</li></ul>2) 부드럽게 “아니요”라고 말할 수 있는 소프트 스킬<ul ><li>오버커뮤니케이션: 거절할 때는 반드시 설명이 필요하며, 이를 통해 오해나 문제를 방지할 수 있습니다. 예를 들어, 중요한 프로젝트에 집중해야 하므로 덜 중요한 일을 맡지 않겠다고 설명하는 식입니다.</li><li>균형 잡기: 승진에 도움이 되지 않는 일을 모두 거절하면 팀 플레이어로서의 이미지가 나빠질 수 있으므로, 상황에 따라 유연하게 접근하는 것이 중요합니다.</li><li>시간 보호하기: 시간이 곧 자산이므로, 무분별하게 모든 요청에 응답하지 않고 자신의 시간을 보호해야 합니다. 예를 들어, 다른 팀원들의 문의나 온콜(On-call) 근무를 모두 거절했던 한 Distinguished 엔지니어의 사례를 참고하며, 경우에 따라 시간 보호를 우선시할 필요도 있음을 강조했습니다.</li></ul>자신의 시간을 지키고 집중하는 것이 성공적인 커리어로 가는 지름길이 될 수 있습니다. 여러분은 어떤 방식으로 업무를 선택하고, 집중력을 유지하고 계신가요? https://www.developing.dev/p/what-you-work-on-how-hard-you-work

www.developing.dev

어떻게 일하느냐가 얼마나 열심히 하느냐보다 중요하다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다.

지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다.

이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다.

이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다.

가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 데이터 엔지니어링 강의를 가르친지 11주가 되어 간다. 80%의 학생은 인도에서 대학을 마치고 3-5년 일하면 번 돈으로 실리콘밸리에서 일하는 것을 꿈꾸며 넘어온 도전이란 관점에서 나무랄 때가 없는 사람들이다. 하지만 도전 정신 만큼 성적이 나오느냐는 다른 문제이다. 정규 분포를 분명히 따르며 적은 수의 다른 문화권 출신들과 비교해보면 평균 점수는 확연히 낮다. 나머지 20%의 학생들은 주로 대만계인데 중국 본토 출신들은 없다. 중국 본토 출신은 R&amp;D에 관심이 있다보니 석사 후 취업 보다는 박사까지 하는 걸 많이 고려하다보니 없는 걸로 보인다. 지지난 주 중간 고사를 보고 결과에 대해 궁금증이 있거나 납득이 안되는 학생들은 오피스 아워로 오라고 했는데 인도 학생들만 오고 그 이외의 인종은 아무도 오지 않았다 :) 실리콘 밸리에서 일해본 사람이라면 어느 정도 인정할 수 밖에 없는 것은 바로 인도 사람들의 자신감과 도전 정신이다. 다른 문화권에 비해 자기 검열을 하는 사람은 현저하게 적다. 또 하나 다른 점은 권위에 도전한다는 점이다. 매니저라고 해서 교수라고 해서 자기 의견을 죽이는 사람보다는 어떻게든 표현하는 사람들이 많다. 암튼 이런 저런 요청을 많이 하고 질문이 많다. 이런 문화적 특성 위에 영어를 어렸을 때부터 사용했다보니 언어적인 문제가 적다. 같이 일했던 인도 동료들을 보면 발음은 처음에 이해하기 힘들지 몰라도 단어 선택이나 표현 자체는 원어민들보다도 좋은 사람들이 많았다. 이 조합들(자기검열을 덜 하고 권위에 도전하며 영어 자체에 익숙한 점)이 결국 리더십으로 갈 수 있느냐 없느냐를 결정하는 것 같다. 또 하나 무시할 수 없는 점은 동아시아권들에 비해 모국의 환경이 그다지 좋지 않다보니 실리콘밸리에서 어떻게든 성공하겠다는 간절함이 더 있다고 보여진다. 가르치면서 이런 관찰을 또 할 줄은 몰랐지만 암튼 덜 자기검열하고 욕망을 잘 표현하고 의사소통을 잘 하는 것이 긴 커리어에서는 참 중요한 기술이다. 참 이번에 주관식 초벌 채점은 RAG로 해봤는데 물론 최종검수를 했고 RAG 만드느라 더 시간을 썼지만 아주 흥미로운 경험이었다. 나중에는 한번 이 이야기해도 공유 해봐야겠다.

산호세 주립대에서 가르치며 다시 한번 깨달은 인도계의 다른 점

이 글은 DuckDB 사용법을 작성한 글입니다 예상 독자 DuckDB가 궁금하신 분 데이터 분석가 : Pandas가 느리다고 생각해서 다른 대안을 찾고 있는 분 데이터 엔지니어 : 데이터 엔지니어링의 Transform 영역에서 활용할 수 있는 수단을 찾고 있는 분. 작은 규모의 회사에서 데이터 웨어하우스를 고민하고 있는 분 키워드 : Duckdb 사용법, Duckdb 설치,...

DuckDB 사용법(DuckDB Python + Jupyter Lab)

 * 요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다
 * 정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!

https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

<ul ><li>요즘 Pandas 대용, 데이터 웨어하우스 대용으로 많이 언급되는 DuckDB 사용법을 작성한 글입니다</li><li>정말 빠르니 데이터 직무에 계신 분들은 꼭 보시고 사용해보시면 좋겠네요..!!!</li></ul> https://zzsza.github.io/data-engineering/2024/10/25/duckdb/

zzsza.github.io

DuckDB 사용법

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다.

👉 총 35-40p 이내
👉 프로젝트 4-5개, 장당 7-8p
👉 구조: 배경 > 문제정의 > 가설 > 솔루션 > 결과해석 > 레슨런
👉 프로젝트 = 서비스 아님
👉 서비스 하나당 n개의 프로젝트가 나올 수 있음
👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

채용 담당자 시절 느낀 적당한 장수는 다음과 같았습니다. 👉 총 35-40p 이내👉 프로젝트 4-5개, 장당 7-8p👉 구조: 배경 &gt; 문제정의 &gt; 가설 &gt; 솔루션 &gt; 결과해석 &gt; 레슨런👉 프로젝트 = 서비스 아님👉 서비스 하나당 n개의 프로젝트가 나올 수 있음👉 문제 해결력을 잘 보여줄 수 있는 중요도 순서로 배치함 (최신순 아니어도 됨)

🎯 적당한 포트폴리오 장수는?

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

대체 불가능한 직원

월급이 적다는 이유로 회사를 그만둔 적은 없었지만…
그런 이유를 대봤으면 어땠을까 상상해 봤습니다.

“얼마나 올려주면 되는데?”
“50퍼센트요.”

한 번쯤 그렇게 말해볼 걸.
회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐.

하지만 저는 답을 알고 있기도 합니다.
“잘 가라.”

저는 대체 불가능한 사람이 아니었으므로.

만약 제가 대체 불가능했다면…
어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.
절대 거절할 수 없는 제안을.

그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다.
언제든 대체 가능한 사람이었다는 것이 분명하므로.

https://jeho.page/essay/2024/10/29/irreplaceable.html

월급이 적다는 이유로 회사를 그만둔 적은 없었지만… 그런 이유를 대봤으면 어땠을까 상상해 봤습니다. “얼마나 올려주면 되는데?” “50퍼센트요.” 한 번쯤 그렇게 말해볼 걸. 회사에서 인정하는 진짜 내 가치를 알 수 있을 테니깐. 하지만 저는 답을 알고 있기도 합니다.“잘 가라.” 저는 대체 불가능한 사람이 아니었으므로. 만약 제가 대체 불가능했다면… 어떤 이유를 대며 그만둔다고 말했든 간에 회사에서 먼저 제안 했을 겁니다.절대 거절할 수 없는 제안을. 그런 제안을 받아본 적이 없다는 것은 슬픈 일입니다. 언제든 대체 가능한 사람이었다는 것이 분명하므로. https://jeho.page/essay/2024/10/29/irreplaceable.html

K리그 프로그래머

The Complete List Of Unicorn Companies

CB인사이츠가 집계하는 전세계 유니콘 기업 숫자가 700곳을 넘었음. 최근 들어 정말 가파르게 증가중. 4~5년전인가 200곳일 때 거품이라고 유니콘이 터질 것이란 얘기를 많이 했었는데… 

혁신기업에 무진장 돈이 몰리고 있다는 얘기.

CB Insights Research

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

한주현

프리랜서 테크 비즈 라이터 

장혜림 (메이)

🤝bshr89@gmail.com 
☝️9년째 IT 주제 텍스트 콘텐츠 만들어요
😊해외 IT 소식을 큐레이션해요
🤟재밌는 거 좋아해요
🙏제임스 고슬링 자바 창시자, 귀도 판 로썸 파이썬 창시자, 오드리 탕 대만 디지털 장관을 인터뷰했어요
🇬🇧런던 거주중이에요

공동대표

기자

본부장

센터장

경영학과

경영대학원

임정욱

호기심 많은 관찰자입니다. 매일 아침 조간 신문 뉴스와 IT뉴스를 챙겨보고 흥미로운 내용을 SNS에 메모해 두는 습관을 10년 넘게 유지하고 있습니다. 독서보다 넷플릭스와 유튜브를 너무 많이 보는 것 같아서 걱정입니다. 막 벤처투자자로 커리어를 바꾸는 참입니다.

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필