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

 - YouTube

GDG, Build with AI 에서 발표한 "진격의 AI, 개발자는 자멸할까?" 발표 슬라이드를 NotebookLM에 넣고 해설해보라고 해봤습니다.

약간의 할루시네이션이 있고, 중간에 도표만 있는 부분에 대한 해설은 다 빠져있습니다만 대체로 제가 전달하고자하는 내용을 잘 해설하였네요. 🙂 재밌게 들어주세요.

🎙️해설 파드캐스트: https://youtu.be/cofSXEl5Gso

🎁 아미고(Ameego) 앱 다운로드: https://tosto.re/ameego

👨🏻‍🏫 발표 슬라이드: https://docs.google.com/presentation/d/1uJaejY1VIgYfcNYL0QYt_lltOYOvIVtg18RnhJu191M/edit?usp=sharing

GDG, Build with AI 에서 발표한 "진격의 AI, 개발자는 자멸할까?" 발표 슬라이드를 NotebookLM에 넣고 해설해보라고 해봤습니다. 약간의 할루시네이션이 있고, 중간에 도표만 있는 부분에 대한 해설은 다 빠져있습니다만 대체로 제가 전달하고자하는 내용을 잘 해설하였네요. 🙂 재밌게 들어주세요. 🎙️해설 파드캐스트: https://youtu.be/cofSXEl5Gso 🎁 아미고(Ameego) 앱 다운로드: https://tosto.re/ameego 👨🏻‍🏫 발표 슬라이드: https://docs.google.com/presentation/d/1uJaejY1VIgYfcNYL0QYt_lltOYOvIVtg18RnhJu191M/edit?usp=sharing

youtu.be

🎙️NotebookLM 해설 - 진격의 AI, 개발자는 자멸할까?

나는 가끔 조합형 한글의 아름다움에 대해 생각한다.

그 아름다움은 단순히 예쁜 글꼴이나 정갈한 종이 위의 자소 배열에서 끝나지 않는다. 진짜 매력은, 정밀한 정보 구조와 이산 수학적 규칙성 속에 숨어 있다.

초성 19자, 중성 21자, 종성 28자(받침없음 포함)의 조합으로 구성된 조합형 한글은 이론적으로 가능한 모든 조합을 체계적으로 담아낸, 말 그대로 한글 문자 컴파일러와도 같다.

유니코드에서 한글은 U+AC00(가)부터 U+D7A3(힣)까지, 무려 11,172개의 음절로 정의되어 있는데, 이 조합 방식은 다차원 배열의 인덱싱 구조와도 흡사하다. 예컨대 ‘한’이라는 글자는 초성 ‘ᄒ’, 중성 ‘ᅡ’, 종성 ‘ᆫ’으로 구성되며, 다음 공식을 통해 유니코드 포인트가 계산된다:

U+AC00 + (초성 인덱스 × 588) + (중성 인덱스 × 28) + 종성 인덱스

이는 단순한 문자 처리 방식이 아니다. 초·중·종성이라는 세 개의 축을 갖는 3차원 좌표 공간에서 유니코드 포인트로 압축하여 출력하는 고성능 한글 출력 엔진이라 할 만하다. 15세기에 고안된 문자 체계가 현대 알고리즘 수준의 체계를 이미 내포하고 있었다는 것이다.

물론 조합형이라는 표현은 현대 디지털 기술이 정의한 것이지만, 그 기저에는 분해와 조합이 가능한 체계적 자모 설계가 존재한다. 즉, 세종대왕은 문자라는 고급 개념을 기계적으로 구현 가능한 형태로 설계한 엔지니어였던 셈이다.

어찌 보면, 조합형 한글은 600년 전에 만들어진 한국어라는 언어의 바이트코드다. 문자 이전의 자모, 음소 이전의 정보 구조. 다르게 말하자면 세종대왕은 나랏말을 만든 게 아니라, 나랏말을 코드화한 것이라고 할 수 있다.

즉, 세종대왕은 킹 갓 프로그래머였던 것.

나는 가끔 조합형 한글의 아름다움에 대해 생각한다. 그 아름다움은 단순히 예쁜 글꼴이나 정갈한 종이 위의 자소 배열에서 끝나지 않는다. 진짜 매력은, 정밀한 정보 구조와 이산 수학적 규칙성 속에 숨어 있다. 초성 19자, 중성 21자, 종성 28자(받침없음 포함)의 조합으로 구성된 조합형 한글은 이론적으로 가능한 모든 조합을 체계적으로 담아낸, 말 그대로 한글 문자 컴파일러와도 같다. 유니코드에서 한글은 U+AC00(가)부터 U+D7A3(힣)까지, 무려 11,172개의 음절로 정의되어 있는데, 이 조합 방식은 다차원 배열의 인덱싱 구조와도 흡사하다. 예컨대 ‘한’이라는 글자는 초성 ‘ᄒ’, 중성 ‘ᅡ’, 종성 ‘ᆫ’으로 구성되며, 다음 공식을 통해 유니코드 포인트가 계산된다: U+AC00 + (초성 인덱스 × 588) + (중성 인덱스 × 28) + 종성 인덱스 이는 단순한 문자 처리 방식이 아니다. 초·중·종성이라는 세 개의 축을 갖는 3차원 좌표 공간에서 유니코드 포인트로 압축하여 출력하는 고성능 한글 출력 엔진이라 할 만하다. 15세기에 고안된 문자 체계가 현대 알고리즘 수준의 체계를 이미 내포하고 있었다는 것이다. 물론 조합형이라는 표현은 현대 디지털 기술이 정의한 것이지만, 그 기저에는 분해와 조합이 가능한 체계적 자모 설계가 존재한다. 즉, 세종대왕은 문자라는 고급 개념을 기계적으로 구현 가능한 형태로 설계한 엔지니어였던 셈이다. 어찌 보면, 조합형 한글은 600년 전에 만들어진 한국어라는 언어의 바이트코드다. 문자 이전의 자모, 음소 이전의 정보 구조. 다르게 말하자면 세종대왕은 나랏말을 만든 게 아니라, 나랏말을 코드화한 것이라고 할 수 있다. 즉, 세종대왕은 킹 갓 프로그래머였던 것.

여러분 PostgreSQL 프로시저는 Python, JavaScript은 물론 Perl, Java, Lua 등도 사용할 수 있답니다~* 대부분 구식🤭 MySQL만 쓰셔서 모르시겠지만.. (도망간다)

여러분 PostgreSQL 프로시저는 Python, JavaScript은 물론 Perl, Java, Lua 등도 사용할 수 있답니다~* 대부분 구식🤭 MySQL만 쓰셔서 모르시겠지만.. (도망간다)

Postgresql은 mysql이랑 다루는데 있어 차이가 많이 나나요? 취업하고자 하는 회사에서 Postgresql을 요구해서 배워야 하는 상황인데 도움을 좀 받고 싶습니다

DB 프로시저 싫어하시는 분들 많으시죠? Lambda/Serverless Function 이라고 생각해보십시오! 사실상 Serverless Function이랑 똑같은 것. Serverless Function도 싫어하시면 린정.

DB 프로시저 싫어하시는 분들 많으시죠? Lambda/Serverless Function 이라고 생각해보십시오! 사실상 Serverless Function이랑 똑같은 것. Serverless Function도 싫어하시면 린정.

현대 생활의 속도 속에서 향수를 불러일으키는 감정 - 황금빛 햇살이 전선과 빽빽한 간판의 미로를 뚫고 들어와, 분주한 군중 위로 쏟아져 내리는데, 마치 분주한 도시 한가운데서 시간이 시적인 순간을 위해 느려지는 듯합니다. https://amongusonline.io/


알뜰폰으로 변경하고 싶어도 통신사 서비스에 무언가 묶인게 있어서 바꾸지 못했는데,

생각해보니 기존 통신사는 최저 요금제로 변경하고, 알뜰폰으로 신규 가입을 한 뒤 eSIM으로 추가 등록해서 사용하도록하는 방법이 떠올라 그렇게 함!

원래 요금제: 45,000원

변경한 요금: 통신사 기본요금 12,100원 + 알뜰폰 11,000원 = 23,100원

회선 두 개를 써도 무려 거의 두 배 차이!

기존 번호로 전화나 문자를 받거나 보내는 것도 문제가 없고, 필요시 다른 전화번호를 사용할 수도 있으니 오히려 좋다!!

알뜰폰으로 변경하고 싶어도 통신사 서비스에 무언가 묶인게 있어서 바꾸지 못했는데, 생각해보니 기존 통신사는 최저 요금제로 변경하고, 알뜰폰으로 신규 가입을 한 뒤 eSIM으로 추가 등록해서 사용하도록하는 방법이 떠올라 그렇게 함! 원래 요금제: 45,000원 변경한 요금: 통신사 기본요금 12,100원 + 알뜰폰 11,000원 = 23,100원 회선 두 개를 써도 무려 거의 두 배 차이! 기존 번호로 전화나 문자를 받거나 보내는 것도 문제가 없고, 필요시 다른 전화번호를 사용할 수도 있으니 오히려 좋다!!

간만에 개발 떡밥이(신난다) 이번엔 제가 소수 입장에 있는 ORM이군요. 후후..

저는 몇몇 사건을 통해 ORM 반대주의자가 된 사람인데요.

주요 이유는 잘못쓰면 큰 문제가 나중에 발견된다는 것과 최적화가 어렵고 오버헤드가 크기 때문입니다. 즉, 항간의 이야기와 달리 ORM이 오히려 디버깅과 유지보수가 어렵다는게 문제라는 것이죠.

유지보수의 문제점으로 말하는 것들은 대부분 보통 ORM을 쓰나 SQL을 쓰나 똑같은 문제들입니다. 빠르게 개발한다는 측면에서는.. 간단한건 그럴 수 있겠죠. 요즘은 SQL을 써도 타입 힌팅이 되고, 조금 편하게 한다면 쿼리 빌더 정도를 쓰면 되겠고요.

그리고 가능하면 프로시저를 적극적으로 활용하는게 좋다고 생각하는데요.

프로시저로 만드는 건 API를 만든다고 생각하면 이른바 관심사의 분리가 확실히 이루어지는 것이라 성능 최적화나 디버깅, 유지보수 측면에서 더욱 좋습니다.

즉, 이것이야말로 열분들 좋아하는 진정한 MSA가 아니겠습니까?! (아님)

간만에 개발 떡밥이(신난다) 이번엔 제가 소수 입장에 있는 ORM이군요. 후후.. 저는 몇몇 사건을 통해 ORM 반대주의자가 된 사람인데요. 주요 이유는 잘못쓰면 큰 문제가 나중에 발견된다는 것과 최적화가 어렵고 오버헤드가 크기 때문입니다. 즉, 항간의 이야기와 달리 ORM이 오히려 디버깅과 유지보수가 어렵다는게 문제라는 것이죠. 유지보수의 문제점으로 말하는 것들은 대부분 보통 ORM을 쓰나 SQL을 쓰나 똑같은 문제들입니다. 빠르게 개발한다는 측면에서는.. 간단한건 그럴 수 있겠죠. 요즘은 SQL을 써도 타입 힌팅이 되고, 조금 편하게 한다면 쿼리 빌더 정도를 쓰면 되겠고요. 그리고 가능하면 프로시저를 적극적으로 활용하는게 좋다고 생각하는데요. 프로시저로 만드는 건 API를 만든다고 생각하면 이른바 관심사의 분리가 확실히 이루어지는 것이라 성능 최적화나 디버깅, 유지보수 측면에서 더욱 좋습니다. 즉, 이것이야말로 열분들 좋아하는 진정한 MSA가 아니겠습니까?! (아님)

이건 약간 다른 얘긴데 AI 시대가 되어서, 좀 raw하게 짜는게 유지보수에 도움이 되기도 하는 것 같음. 너무 추상화 된 코드보다는 raw한 코드를 AI가 더 잘 이해하고 처리 할 수 있으니.

고기 먹었는데 연탄만 찍었네. 퐈이어!! 🔥

고기 먹었는데 연탄만 찍었네. 퐈이어!! 🔥

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

Binary Tree Level Order Traversal | 알고달레

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 102번째 문제인 Binary Tree Level Order Traver를 재귀와 깊이 우선 탐색을 통해 풀어보겠습니다.

📺 동영상: https://youtu.be/eRQJzWHyQmM
📝 설명/코드: https://www.algodale.com/problems/binary-tree-level-order-traversal/

코딩 테스트를 준비하시는 분들을 위해서 일주일에 한 번씩 문제 풀이를 해드리고 있습니다. 이번 시간에는 LeetCode의 102번째 문제인 Binary Tree Level Order Traver를 재귀와 깊이 우선 탐색을 통해 풀어보겠습니다. 📺 동영상: https://youtu.be/eRQJzWHyQmM📝 설명/코드: https://www.algodale.com/problems/binary-tree-level-order-traversal/

알고달레

리트코드 102. Binary Tree Level Order Traver

달레와 함께 코딩 테스트를 준비해볼까요?

달레의 코딩 테스트

지난 2년간, 매주 한 문제씩 코딩 테스트 문제를 풀고 그 과정을 유튜브에 기록했습니다. 그렇게 쌓인 영상이 어느덧 100개가 된 거 있죠? 그동안의 노력이 고스란히 담긴 플레이리스트를 쭉 스크롤해보니 괜히 뿌듯해지네요. 🥹

🎞️ 플레이리스트: https://www.youtube.com/playlist?list=PLapoeRAdKitdzTMQ7hq2h5zw39BaAVgbM

많은 분들이 제가 코딩 테스트 문제를 좋아한다고 오해하시는데요. 사실 전 세상에서 코딩 테스트가 제일 두렵고 싫어요. 😭 이직할 때마다 진저리가 나도록 준비해야 했던 코딩 테스트는 늘 스트레스였습니다. 손을 놓고 있자니 감이 떨어질 것 같고, 그렇다고 혼자서 풀자니 재미가 드럽게 없고... 게다가 코딩 테스트에 면접관으로 들어가니 지원자보다 문제에 대해서 더 잘 알아야 하더라고요. 소프트웨어 개발자인 저에게 코딩 테스트는 꼭 해야 하지만 늘 부담스러운, 그런 "필요악" 같은 존재였습니다.

특히 저는 코딩 테스트에서 문제를 푸는 것보다, 그 과정을 효과적으로 표현하고 전달하는 게 쉽지 않아서 늘 고민이었어요. 게다가 제가 면접 때 극도로 긴장을 하는 편이라서 저만의 특별한 훈련이 필요하다고 느꼈지요. 그래서 떠올린 방법이 바로 유튜브에 문제 풀이 영상을 올리는 것이었습니다. 유튜브 초보에게 카메라 앞에서 문제를 푸는 건 실전 면접만큼이나 떨리는 경험이죠 ㅎㅎ 😂

이렇게 한 문제 한 문제 강렬하게 연습하다보니 자연스럽게 유튜브에 올린 문제는 왠만하면 잊어버리지 않게 되었습니다. 댓글로 남겨주신 피드백을 통해 문제를 다양한 시각으로 바라볼 수 있는 능력도 키울 수 있었고요. 혹시 저처럼 코딩 테스트를 어려워하시는 분이 계시다면, 꼭 유튜브가 아니더라도 일부로 불편한 상황을 설정해놓고 자신만의 방식으로 꾸준히 연습해보시길 추천드리고 싶습니다

요즘엔 리트코드 뿐만 아니라 프로그래머스 문제도 풀어달라는 요청이 많네요. 풀 문제가 많습니다 ㅋㅋ 이제 200문제를 향해 달려볼께용~ 🏃‍♂️

지난 2년간, 매주 한 문제씩 코딩 테스트 문제를 풀고 그 과정을 유튜브에 기록했습니다. 그렇게 쌓인 영상이 어느덧 100개가 된 거 있죠? 그동안의 노력이 고스란히 담긴 플레이리스트를 쭉 스크롤해보니 괜히 뿌듯해지네요. 🥹 🎞️ 플레이리스트: https://www.youtube.com/playlist?list=PLapoeRAdKitdzTMQ7hq2h5zw39BaAVgbM 많은 분들이 제가 코딩 테스트 문제를 좋아한다고 오해하시는데요. 사실 전 세상에서 코딩 테스트가 제일 두렵고 싫어요. 😭 이직할 때마다 진저리가 나도록 준비해야 했던 코딩 테스트는 늘 스트레스였습니다. 손을 놓고 있자니 감이 떨어질 것 같고, 그렇다고 혼자서 풀자니 재미가 드럽게 없고... 게다가 코딩 테스트에 면접관으로 들어가니 지원자보다 문제에 대해서 더 잘 알아야 하더라고요. 소프트웨어 개발자인 저에게 코딩 테스트는 꼭 해야 하지만 늘 부담스러운, 그런 "필요악" 같은 존재였습니다. 특히 저는 코딩 테스트에서 문제를 푸는 것보다, 그 과정을 효과적으로 표현하고 전달하는 게 쉽지 않아서 늘 고민이었어요. 게다가 제가 면접 때 극도로 긴장을 하는 편이라서 저만의 특별한 훈련이 필요하다고 느꼈지요. 그래서 떠올린 방법이 바로 유튜브에 문제 풀이 영상을 올리는 것이었습니다. 유튜브 초보에게 카메라 앞에서 문제를 푸는 건 실전 면접만큼이나 떨리는 경험이죠 ㅎㅎ 😂 이렇게 한 문제 한 문제 강렬하게 연습하다보니 자연스럽게 유튜브에 올린 문제는 왠만하면 잊어버리지 않게 되었습니다. 댓글로 남겨주신 피드백을 통해 문제를 다양한 시각으로 바라볼 수 있는 능력도 키울 수 있었고요. 혹시 저처럼 코딩 테스트를 어려워하시는 분이 계시다면, 꼭 유튜브가 아니더라도 일부로 불편한 상황을 설정해놓고 자신만의 방식으로 꾸준히 연습해보시길 추천드리고 싶습니다 요즘엔 리트코드 뿐만 아니라 프로그래머스 문제도 풀어달라는 요청이 많네요. 풀 문제가 많습니다 ㅋㅋ 이제 200문제를 향해 달려볼께용~ 🏃‍♂️

www.youtube.com

🎯 유튜브에 100번째 코딩 테스트 문제 풀이 영상을 올렸습니다!

이번에 우아한형제들 기술 블로그에 "타입 안전한 API 모킹으로 프론트엔드 생산성 높이기"라는 새 글을 발행하게 되었습니다.

주문웹프론트개발팀(배달의민족 장바구니부터 결제까지 담당)은 다양한 시나리오를 테스트하기 위해 10개가 넘는 시나리오 별 JSON 파일을 관리하고 있었습니다.

하지만 API 모킹을 위한 JSON 파일이 점점 늘어나면서, 변경된 API 스펙을 목 데이터에 실수로 반영하지 않아 개발 환경에서 '흰 화면' 이슈를 겪는 등의 문제가 발생했습니다.

이 글은 타입 안전한 API 모킹을 통해 흰 화면 이슈를 방지하고, 유지보수 비용을 줄이기 위한 여정을 담고 있습니다.

API 모킹 방식에 고민이 있거나 반복적인 모킹 작업에 피로를 느끼는 프론트엔드 개발자분들께 도움이 되었으면 합니다.

https://techblog.woowahan.com/22127/

이번에 우아한형제들 기술 블로그에 "타입 안전한 API 모킹으로 프론트엔드 생산성 높이기"라는 새 글을 발행하게 되었습니다. 주문웹프론트개발팀(배달의민족 장바구니부터 결제까지 담당)은 다양한 시나리오를 테스트하기 위해 10개가 넘는 시나리오 별 JSON 파일을 관리하고 있었습니다. 하지만 API 모킹을 위한 JSON 파일이 점점 늘어나면서, 변경된 API 스펙을 목 데이터에 실수로 반영하지 않아 개발 환경에서 '흰 화면' 이슈를 겪는 등의 문제가 발생했습니다. 이 글은 타입 안전한 API 모킹을 통해 흰 화면 이슈를 방지하고, 유지보수 비용을 줄이기 위한 여정을 담고 있습니다. API 모킹 방식에 고민이 있거나 반복적인 모킹 작업에 피로를 느끼는 프론트엔드 개발자분들께 도움이 되었으면 합니다. https://techblog.woowahan.com/22127/

타입 안전한 API 모킹으로 프론트엔드 생산성 높이기

구성원들과 일대일(1on1)이나 손님과 커피챗 등을 하다 보면, 종종 커리어에 대한 이야기를 나눈다. 때로는 구체적인 계획을 가지고 대화에 임하는 분들도 있지만, 많은 경우 막연함을 느끼거나 혹시나 뒤처지는 것은 아닐까 하는 조급함(FOMO) 속에서 섣부른 결정을 꺼내는 분들도 있다. 그럴 때 나는 조용히 여쭙곤 한다. "몇 년 뒤, 어떤 모습의 개발자가 되어 있기를 바라시나요?" 이 질문을 시작으로, 함께 커리어 방향을 구체화하는 데 필요한 요소들을 찾아보고, 무엇을 좋아하고 잘하는지 스스로를 깊이 들여다보는 시간을 가지며 실마리를 풀어가곤 한다.

나 역시 비슷한 과정을 거쳐왔다. 제조 기업의 전산실에서 처음 사회생활을 시작해, 시스템 통합(SI) 프로젝트의 역동성을 경험하고, 이후 플랫폼 기업에서 대규모 시스템의 복잡성을 배웠으며, 지금은 디지털 제품을 만드는 스타트업에서 도전을 이어가고 있다. 지난 십여 년간 다양한 산업 도메인에서 엔터프라이즈급 애플리케이션을 구축하고 운영하는 일을 해왔다. 돌아보면 운이 좋게도 그 과정 속에서 내가 진정으로 좋아하는 것과 잘 해낼 수 있는 영역을 발견했고, 이를 바탕으로 커리어를 원하는 방향으로 조금씩 만들어올 수 있었다.

나는 특히 소프트웨어의 아키텍처, 즉 애플리케이션의 전체적인 구조를 설계하고 만들어가는 과정에 깊은 흥미를 느끼며, 이 부분을 비교적 잘 다룬다. 여기서 '잘 다룬다'는 것은, 초기 단계에서 비즈니스의 요구사항과 기술적 제약을 고려하여 필요한 수준의 추상화를 통해 유연한 구조를 제안하는 것뿐만 아니라, 시간이 흐름에 따라 변화하는 상황에 맞춰 애플리케이션의 개선 지점을 찾아내고, 구조를 점진적으로 발전시켜나가는 활동까지 포함한다. 새로운 애플리케이션을 처음부터 설계하고 구축하는 경험도 소중했지만, 오랜 시간 동안 운영되어 온 레거시 시스템을 이해하고, 그 안에서 새로운 가치를 찾아내며 현대적인 기술로 진화시키는 과정 역시 나에게 큰 성장의 밑거름이 되었다. 이러한 경험들이 차곡차곡 쌓이면서, 개별 애플리케이션을 넘어 다수의 애플리케이션과 인프라스트럭처가 복잡하게 얽힌 시스템 전체의 청사진을 그리고, 이를 실제로 구현해내는 역량으로 발전할 수 있었다고 생각한다. 이를 통해 비즈니스의 장기적인 목표와 변화에 발맞춰 시스템 구조를 짧게는 수개월, 길게는 수년에 걸쳐 어떻게 가꾸어 나갈지에 대한 로드맵을 수립하고 실행하는 역할을 수행하고 있다.

그래서 나는 스스로를
시스템 빌더(System Builder)
라고 소개한다. 이는 공식적으로 통용되는 호칭은 아니지만, 내가 하는 일의 본질을 가장 잘 담아내는 표현이라고 생각하기 때문이다. 나에게 시스템 빌더란 단순히 코드를 작성하는 것을 넘어, 비즈니스의 목표를 깊이 이해하고, 이를 기술적인 해결책으로 구체화하여 안정적이고 확장 가능한 시스템이라는 결과물로 만들어내는 사람을 의미한다. 또한, 시스템이 살아있는 유기체처럼 지속적으로 변화하고 성장할 수 있도록 장기적인 관점에서 고민하고, 필요한 기술과 자원을 조율하며, 때로는 복잡한 문제들 사이에서 최적의 경로를 찾아내는 길잡이 역할까지 포함한다. 물론 나를 구성하는 다른 많은 역량과 경험들이 있겠지만, 내가 어떤 개발자인지를 설명하는 데 있어 이
시스템 빌더
라는 정체성이 가장 명확하고 핵심적인 설명이라고 생각하고 있다.

결국, 자신을 어떤 개발자로 정의하고 싶은지에 대한 고민은, 앞서 구성원들과 나눴던 "몇 년 뒤 어떤 개발자가 되고 싶으세요?"라는 질문에 대한 스스로의 답을 찾아가는 여정이다. 나에게 시스템 빌더라는 호칭은 오랜 시간 동안 내가 걸어온 길과 내가 추구하는 가치를 담아낸 나만의 답변인 셈이다. 이처럼 스스로의 강점과 열정을 발견하고 자신만의 정체성을 찾아가는 과정은, 때로는 어렵고 시간이 걸릴지라도 커리어를 주체적으로 만들어가는 데 있어 무엇보다 중요하다고 믿고 있다.

이 글을 읽는 여러분께서도 각자의 자리에서 빛나는 자신만의 '무엇'을 찾아내어 커리어를 만들어가기를 진심으로 응원하겠다.

구성원들과 일대일(1on1)이나 손님과 커피챗 등을 하다 보면, 종종 커리어에 대한 이야기를 나눈다. 때로는 구체적인 계획을 가지고 대화에 임하는 분들도 있지만, 많은 경우 막연함을 느끼거나 혹시나 뒤처지는 것은 아닐까 하는 조급함(FOMO) 속에서 섣부른 결정을 꺼내는 분들도 있다. 그럴 때 나는 조용히 여쭙곤 한다. "몇 년 뒤, 어떤 모습의 개발자가 되어 있기를 바라시나요?" 이 질문을 시작으로, 함께 커리어 방향을 구체화하는 데 필요한 요소들을 찾아보고, 무엇을 좋아하고 잘하는지 스스로를 깊이 들여다보는 시간을 가지며 실마리를 풀어가곤 한다. 나 역시 비슷한 과정을 거쳐왔다. 제조 기업의 전산실에서 처음 사회생활을 시작해, 시스템 통합(SI) 프로젝트의 역동성을 경험하고, 이후 플랫폼 기업에서 대규모 시스템의 복잡성을 배웠으며, 지금은 디지털 제품을 만드는 스타트업에서 도전을 이어가고 있다. 지난 십여 년간 다양한 산업 도메인에서 엔터프라이즈급 애플리케이션을 구축하고 운영하는 일을 해왔다. 돌아보면 운이 좋게도 그 과정 속에서 내가 진정으로 좋아하는 것과 잘 해낼 수 있는 영역을 발견했고, 이를 바탕으로 커리어를 원하는 방향으로 조금씩 만들어올 수 있었다. 나는 특히 소프트웨어의 아키텍처, 즉 애플리케이션의 전체적인 구조를 설계하고 만들어가는 과정에 깊은 흥미를 느끼며, 이 부분을 비교적 잘 다룬다. 여기서 '잘 다룬다'는 것은, 초기 단계에서 비즈니스의 요구사항과 기술적 제약을 고려하여 필요한 수준의 추상화를 통해 유연한 구조를 제안하는 것뿐만 아니라, 시간이 흐름에 따라 변화하는 상황에 맞춰 애플리케이션의 개선 지점을 찾아내고, 구조를 점진적으로 발전시켜나가는 활동까지 포함한다. 새로운 애플리케이션을 처음부터 설계하고 구축하는 경험도 소중했지만, 오랜 시간 동안 운영되어 온 레거시 시스템을 이해하고, 그 안에서 새로운 가치를 찾아내며 현대적인 기술로 진화시키는 과정 역시 나에게 큰 성장의 밑거름이 되었다. 이러한 경험들이 차곡차곡 쌓이면서, 개별 애플리케이션을 넘어 다수의 애플리케이션과 인프라스트럭처가 복잡하게 얽힌 시스템 전체의 청사진을 그리고, 이를 실제로 구현해내는 역량으로 발전할 수 있었다고 생각한다. 이를 통해 비즈니스의 장기적인 목표와 변화에 발맞춰 시스템 구조를 짧게는 수개월, 길게는 수년에 걸쳐 어떻게 가꾸어 나갈지에 대한 로드맵을 수립하고 실행하는 역할을 수행하고 있다. 그래서 나는 스스로를 <code >시스템 빌더(System Builder)</code>라고 소개한다. 이는 공식적으로 통용되는 호칭은 아니지만, 내가 하는 일의 본질을 가장 잘 담아내는 표현이라고 생각하기 때문이다. 나에게 시스템 빌더란 단순히 코드를 작성하는 것을 넘어, 비즈니스의 목표를 깊이 이해하고, 이를 기술적인 해결책으로 구체화하여 안정적이고 확장 가능한 시스템이라는 결과물로 만들어내는 사람을 의미한다. 또한, 시스템이 살아있는 유기체처럼 지속적으로 변화하고 성장할 수 있도록 장기적인 관점에서 고민하고, 필요한 기술과 자원을 조율하며, 때로는 복잡한 문제들 사이에서 최적의 경로를 찾아내는 길잡이 역할까지 포함한다. 물론 나를 구성하는 다른 많은 역량과 경험들이 있겠지만, 내가 어떤 개발자인지를 설명하는 데 있어 이 <code >시스템 빌더</code>라는 정체성이 가장 명확하고 핵심적인 설명이라고 생각하고 있다. 결국, 자신을 어떤 개발자로 정의하고 싶은지에 대한 고민은, 앞서 구성원들과 나눴던 "몇 년 뒤 어떤 개발자가 되고 싶으세요?"라는 질문에 대한 스스로의 답을 찾아가는 여정이다. 나에게 시스템 빌더라는 호칭은 오랜 시간 동안 내가 걸어온 길과 내가 추구하는 가치를 담아낸 나만의 답변인 셈이다. 이처럼 스스로의 강점과 열정을 발견하고 자신만의 정체성을 찾아가는 과정은, 때로는 어렵고 시간이 걸릴지라도 커리어를 주체적으로 만들어가는 데 있어 무엇보다 중요하다고 믿고 있다. 이 글을 읽는 여러분께서도 각자의 자리에서 빛나는 자신만의 '무엇'을 찾아내어 커리어를 만들어가기를 진심으로 응원하겠다.

나는 시스템 빌더이다

﻿
우리 부모님 세대는 첫 직장이 중요하다고 이야기하십니다. 맞는 말입니다. 커리어를 어디서 시작하는지 결정하는 일은 중요합니다. 그러나 첫 직장이 커리어 여정 전부를 확정 짓는 요소가 되지 않습니다. 부모님 세대는 한곳에서 쭉 근무하는 것이 당연한 일이었습니다. 이직이라는 개념이 문제가 있을 때 피치 못하게 발생하는 것으로 부정적인 인식이 강하였기 때문입니다. 그래서 한 직장에서 30년 이상 근무하고 명예롭게 정년퇴직하는 분들이 많았습니다.

시대가 변하여 평생직장의 개념이 사라졌습니다. 한곳에 오래 머물기보다 필요에 따라 이동하는 것이 일반화되었습니다. 더 이상 이직을 하는 것이 경력에 흉이 되지 않고, 오히려 다양한 장점이 있는 흥나는 일이 되었습니다. 다양한 산업 군을 경험하는 것이 비즈니스 견문을 넓히는 기회가 됩니다. 다양한 사람들을 만나 네트워크를 확장하는 것도 큰 자산이 됩니다. 다양한 업무를 진행하는 것도 기술적 역량을 성장시키는 데 도움이 됩니다.

낀 세대인 저는 여전히 이직을 보수적으로 보지만, 정작 본인은 이직을 적지 않게 실행에 옮겼습니다. 물론 자의도 있고, 타의로 직장을 옮겨야 하는 때도 있었습니다. 반면, 아내는 한 직장에 10년 이상 오래 근무하고 한 번 이직 후 또 오래 근무할 생각을 갖고 있습니다. 아내와 같이 한 직장에 오래 머무는 것이 좋다는 생각이 듭니다. 이리저리 옮겨봐야 거기서 거기라는 경험이 있기 때문입니다. 매년 연봉이 조금씩 오르더라도 한곳에 머물며 익숙한 사람들과 인프라 속에서 안정적으로 일을 하는 것이 좋다는 생각이 들었습니다.

한 직장에 오래 근무하는 것이 객관적으로 진짜 좋으냐 묻는다면, 그건 조금 더 따져봐야 합니다. 위와 같이 이야기한 내용은 전적으로 이직을 적지 않게 실행한 사람의 소해일 뿐입니다. 주변 사람들을 보면 주니어 시절엔 비교적 작은 회사에서 짧은 근속 기간을 갖고, 이후 커리어 점프업을 통해 큰 회사에 들어가서 오래 근무하는 특징이 있습니다. 이렇게 전략적으로 이직하는 것이 또 좋으냐 묻는다면, 개인 커리어는 기호 식품을 먹는 것과 같아서 각자 알아서 판단하면 되는 영역이라고 생각합니다.

회사를 옮기는 이직만큼 직무를 바꾸는 것도 어렵지 않습니다. 다양한 직무에서 요구하는 공통 역량이 존재하기 때문입니다. 문제 정의, 문제 해결 기획, 문서화, 추진력, 일정관리 등 하드 스킬과 소프트 스킬 측면에서 공통 역량을 어필하면 직무 전환을 해볼 수 있습니다. 물론 쉽진 않습니다. 회사를 옮기는 것보다 더 직무를 바꾸는 일을 보수적으로 바라보기 때문입니다. 이것도 한 직장에서 오래 근무하는 것을 미덕으로 바라보는 시선과 맥랑이 닿아 있습니다. 한 직무를 오래 경험하는 것이 스페셜리스트로 직무 전문성을 갖고 있다고 믿기 때문입니다. 그러나 저는 한 직무를 오래 해야 전문성이 생긴다고 믿지 않습니다. 정확히 이야기하면 전문성은 시간에 비례하여 저절로 생기는 것이 아니라 상대적으로 더 많이 고민하고 실행해 본 사람에게 축적되는 것이 전문성이라고 생각합니다.

한때 ‘압축 성장’이라는 말이 유행했습니다. 짧은 시간 동안 집약적으로 지식과 경험을 쌓아서 전문가가 된다는 의미입니다. 위에 이야기한 내용처럼 전문성은 시간에 비례하여 저절로 생기는 것이 아니라는 메시지를 다르게 표현한 개념입니다. 전문성을 측정할 수 있다면, 전문성을 갖기 위해 무조건 많은 시간이 필요한 것이 아니라 짧은 시간 동안에도 지식과 경험을 밀도 있게 채우면 전문성을 가질 수 있다는 것입니다. 학원 홍보처럼 3개월 또는 6개월 만에 어떤 기술을 완성할 수 있다는 건 조금 믿기 어렵지만, 반드시 10년 이상 한 우물을 파야 지하수를 발견할 수 있는 건 아니라고 생각합니다. 한 직무를 2-3년만 파도 그 기간 동안 고민하여 실행한 내용이 밀도 있다면 전문성을 갖게 된 것이라고 판단할 수 있습니다. 그래서 개인적으로 경력 연차가 직무 전문성을 파악하는 지표가 되기 어렵다고 생각합니다. 완전히 무시할 순 없지만, 경험과 역량을 객관적으로 파악하여 요구하는 수준에 도달해 있는지 판단할 수 있으면 충분하지 않을까요?

오늘 하려던 이야기가 이게 아니었는데, 주제에 대한 배경 설명을 빌드 업하려다 보니 딴소리가 길어졌습니다. 내일 오늘 생각했던 주니어 시절 직무 선택에 대해서 이야기를 해보겠습니다. 오늘도 직무 선택으로 고민하고 방황하는 모든 분들을 진심으로 응원합니다. 무엇이든 다 여러분에게 도움이 될 일들입니다. 자신 있게 선택하세요. 파이팅!

﻿우리 부모님 세대는 첫 직장이 중요하다고 이야기하십니다. 맞는 말입니다. 커리어를 어디서 시작하는지 결정하는 일은 중요합니다. 그러나 첫 직장이 커리어 여정 전부를 확정 짓는 요소가 되지 않습니다. 부모님 세대는 한곳에서 쭉 근무하는 것이 당연한 일이었습니다. 이직이라는 개념이 문제가 있을 때 피치 못하게 발생하는 것으로 부정적인 인식이 강하였기 때문입니다. 그래서 한 직장에서 30년 이상 근무하고 명예롭게 정년퇴직하는 분들이 많았습니다. 시대가 변하여 평생직장의 개념이 사라졌습니다. 한곳에 오래 머물기보다 필요에 따라 이동하는 것이 일반화되었습니다. 더 이상 이직을 하는 것이 경력에 흉이 되지 않고, 오히려 다양한 장점이 있는 흥나는 일이 되었습니다. 다양한 산업 군을 경험하는 것이 비즈니스 견문을 넓히는 기회가 됩니다. 다양한 사람들을 만나 네트워크를 확장하는 것도 큰 자산이 됩니다. 다양한 업무를 진행하는 것도 기술적 역량을 성장시키는 데 도움이 됩니다. 낀 세대인 저는 여전히 이직을 보수적으로 보지만, 정작 본인은 이직을 적지 않게 실행에 옮겼습니다. 물론 자의도 있고, 타의로 직장을 옮겨야 하는 때도 있었습니다. 반면, 아내는 한 직장에 10년 이상 오래 근무하고 한 번 이직 후 또 오래 근무할 생각을 갖고 있습니다. 아내와 같이 한 직장에 오래 머무는 것이 좋다는 생각이 듭니다. 이리저리 옮겨봐야 거기서 거기라는 경험이 있기 때문입니다. 매년 연봉이 조금씩 오르더라도 한곳에 머물며 익숙한 사람들과 인프라 속에서 안정적으로 일을 하는 것이 좋다는 생각이 들었습니다. 한 직장에 오래 근무하는 것이 객관적으로 진짜 좋으냐 묻는다면, 그건 조금 더 따져봐야 합니다. 위와 같이 이야기한 내용은 전적으로 이직을 적지 않게 실행한 사람의 소해일 뿐입니다. 주변 사람들을 보면 주니어 시절엔 비교적 작은 회사에서 짧은 근속 기간을 갖고, 이후 커리어 점프업을 통해 큰 회사에 들어가서 오래 근무하는 특징이 있습니다. 이렇게 전략적으로 이직하는 것이 또 좋으냐 묻는다면, 개인 커리어는 기호 식품을 먹는 것과 같아서 각자 알아서 판단하면 되는 영역이라고 생각합니다. 회사를 옮기는 이직만큼 직무를 바꾸는 것도 어렵지 않습니다. 다양한 직무에서 요구하는 공통 역량이 존재하기 때문입니다. 문제 정의, 문제 해결 기획, 문서화, 추진력, 일정관리 등 하드 스킬과 소프트 스킬 측면에서 공통 역량을 어필하면 직무 전환을 해볼 수 있습니다. 물론 쉽진 않습니다. 회사를 옮기는 것보다 더 직무를 바꾸는 일을 보수적으로 바라보기 때문입니다. 이것도 한 직장에서 오래 근무하는 것을 미덕으로 바라보는 시선과 맥랑이 닿아 있습니다. 한 직무를 오래 경험하는 것이 스페셜리스트로 직무 전문성을 갖고 있다고 믿기 때문입니다. 그러나 저는 한 직무를 오래 해야 전문성이 생긴다고 믿지 않습니다. 정확히 이야기하면 전문성은 시간에 비례하여 저절로 생기는 것이 아니라 상대적으로 더 많이 고민하고 실행해 본 사람에게 축적되는 것이 전문성이라고 생각합니다. 한때 ‘압축 성장’이라는 말이 유행했습니다. 짧은 시간 동안 집약적으로 지식과 경험을 쌓아서 전문가가 된다는 의미입니다. 위에 이야기한 내용처럼 전문성은 시간에 비례하여 저절로 생기는 것이 아니라는 메시지를 다르게 표현한 개념입니다. 전문성을 측정할 수 있다면, 전문성을 갖기 위해 무조건 많은 시간이 필요한 것이 아니라 짧은 시간 동안에도 지식과 경험을 밀도 있게 채우면 전문성을 가질 수 있다는 것입니다. 학원 홍보처럼 3개월 또는 6개월 만에 어떤 기술을 완성할 수 있다는 건 조금 믿기 어렵지만, 반드시 10년 이상 한 우물을 파야 지하수를 발견할 수 있는 건 아니라고 생각합니다. 한 직무를 2-3년만 파도 그 기간 동안 고민하여 실행한 내용이 밀도 있다면 전문성을 갖게 된 것이라고 판단할 수 있습니다. 그래서 개인적으로 경력 연차가 직무 전문성을 파악하는 지표가 되기 어렵다고 생각합니다. 완전히 무시할 순 없지만, 경험과 역량을 객관적으로 파악하여 요구하는 수준에 도달해 있는지 판단할 수 있으면 충분하지 않을까요? 오늘 하려던 이야기가 이게 아니었는데, 주제에 대한 배경 설명을 빌드 업하려다 보니 딴소리가 길어졌습니다. 내일 오늘 생각했던 주니어 시절 직무 선택에 대해서 이야기를 해보겠습니다. 오늘도 직무 선택으로 고민하고 방황하는 모든 분들을 진심으로 응원합니다. 무엇이든 다 여러분에게 도움이 될 일들입니다. 자신 있게 선택하세요. 파이팅!﻿

이직의 조건

어제 출시된 따끈따끈한 ChatGPT Codex를 실제 프로젝트 레포에 써 보았습니다.

테스트가 있으면 스스로 테스트도 실행하고, 만든거 스스로 실행해보면서 버그도 수정하고 하는게 기특하긴 합니다.

물론 아직은 바닥부터 레포를 따서 만들게는 못하고, 네트워크가 제한되어 있고, 아주 복합적인 프로젝트는 잘 처리하지 못하는등의 한계가 매우 많습니다.

그래서 아직은 아주 작은, 환경이 격리된 상태에서도 문제 없는 프로젝트 정도에만 유용할 것 같습니다. 그러니까 리서치 프리뷰겠죠.

하지만 이것들은 어렵지 않게(?) 해결이 가능한 것이고, 무엇보다 “야 너 이것 좀 함 해와봐”의 컨셉이 제대로라서 상당히 기대가 됩니다.

기존의 Agent는 기다리면 되는거긴 해도 페어 프로그래밍 정도였다면, 이건 진짜로 누구에게 시키는 느낌이 듭니다. 딥 리서치의 상위 호환같은 느낌이에요.

컨셉의 기본 자체는 상당히 완성도가 높아서 매우 빠르게 발전할 것 같습니다. 향후 1년 안에 진짜로 주니어 개발자 수준은 될 것 같네요.

어제 출시된 따끈따끈한 ChatGPT Codex를 실제 프로젝트 레포에 써 보았습니다. 테스트가 있으면 스스로 테스트도 실행하고, 만든거 스스로 실행해보면서 버그도 수정하고 하는게 기특하긴 합니다. 물론 아직은 바닥부터 레포를 따서 만들게는 못하고, 네트워크가 제한되어 있고, 아주 복합적인 프로젝트는 잘 처리하지 못하는등의 한계가 매우 많습니다. 그래서 아직은 아주 작은, 환경이 격리된 상태에서도 문제 없는 프로젝트 정도에만 유용할 것 같습니다. 그러니까 리서치 프리뷰겠죠. 하지만 이것들은 어렵지 않게(?) 해결이 가능한 것이고, 무엇보다 “야 너 이것 좀 함 해와봐”의 컨셉이 제대로라서 상당히 기대가 됩니다. 기존의 Agent는 기다리면 되는거긴 해도 페어 프로그래밍 정도였다면, 이건 진짜로 누구에게 시키는 느낌이 듭니다. 딥 리서치의 상위 호환같은 느낌이에요. 컨셉의 기본 자체는 상당히 완성도가 높아서 매우 빠르게 발전할 것 같습니다. 향후 1년 안에 진짜로 주니어 개발자 수준은 될 것 같네요.

어제 출시된 따끈따끈한 ChatGPT Codex를 실제 프로젝트 

부대끼는 실리콘밸리 사람들 사이에서 샘 알트만의 탈출구는 농장이다. 샘의 넓은 농장은 나파 밸리의 포도나무가 우거진 언덕을 관통하는 도로 끝에 있다. 나는 널찍한 베이 윈도우(사다리꼴 모양으로 튀어나온 창)가 있는 집의 오픈 키친에서 약간 헝클어진 머리를 한 40세의 샘 알트만을 봤고, 바로 들어간다. 그의 당혹스러운 표정을 보니 나는 예상치 못한 손님이다. 알고 보니 내가 거의 한 시간 일찍 도착했다. ChatGPT의 배후자인 이 남자는 회의를 마무리하고 정원에서 나와 합류할 것이다. 나는 집과 이어진 포도나무 그늘 퍼골라 아래에서 기다린다.‘런치 윗 FT’를 위해, 알트만은 사람들로 둘러싸일 가능성이 높은 식당에서의 만남 대신 자기 농장에서 간단한 채식 식사를 만들어주겠다고 제안했다. 그가 운영하는 오픈AI 가 2022년 생성형 AI를 출시한 뒤, 알트만은 순식간에 세계적인 ‘셀럽’이 되었다. 작년 그는 소프트웨어 엔지니어인 남자친구와 결혼했고 최근 대리모를 통해 아들을 낳았다(그는 어떤 아기 침대를 구매할지 ChatGPT에 문의했다). 그래서 그는 요즘 나파 밸리의 농장에서 더 많은 시간을 보낸다.단 몇 분 후에 알트만이 정원에 나왔다. 그는 오픈 AI를 인류 역사상 가장 빠르게 성장하는 회사 중 하나로 발전시켰다. 기업가치는 놀랍게도 2500억 달러 이상으로 평가된다. 또 AI 패권을 향한 경쟁도 계속 치열하게 펼쳐나가고 있다. 이 경쟁은 인공 일반 지능(artificial general intelligence)의

샘 알트만: "지금 당신이 o3보다 더 똑똑하다고 생각하세요?" : 오호츠크 리포트

샘 알트먼의 농장에 가서 약간 맛없고 건강한 걸 해주는 알트먼과 이야기하는 파이낸셜 타임즈 기자와의 이야기입니다. o3 과 향후 인공지능에 관한 이야기인데 너무 재미있네요.

그들이 먹은 음식은.

메뉴
샘 알트먼의 농장
나파 밸리, 캘리포니아

고추, 마늘, 호두, 파슬리, 페코리노 치즈가 들어간 파스타
구운 당근
당근과 무우 샐러드
에스프레소
차

샘 알트먼의 농장에 가서 약간 맛없고 건강한 걸 해주는 알트먼과 이야기하는 파이낸셜 타임즈 기자와의 이야기입니다. o3 과 향후 인공지능에 관한 이야기인데 너무 재미있네요. 그들이 먹은 음식은. 메뉴샘 알트먼의 농장나파 밸리, 캘리포니아 고추, 마늘, 호두, 파슬리, 페코리노 치즈가 들어간 파스타구운 당근당근과 무우 샐러드에스프레소차

55check.com

샘 알트만: "지금 당신이 o3보다 더 똑똑하다고 생각하세요?"

1. 네이버를 두 번 다녔다. 퇴사 후 다른 회사들을 거쳐 다시 입사했다. 지금은 모르겠으나 당시에는 비개발 직군 재입사는 처음 있는 일이었다. 대표와 창업자의 컨펌까지 필요했다. 다른 이유는 아니다. 사례가 없던 예외 케이스였기 때문이다.

2. 네이버 다녀요. 낯선 누군가를 만나서 나를 소개한다. 그 이상의 질문은 없었다. 회사의 브랜드와 이미지 때문이었을까. 네이버에서 무슨 일을 하는지 궁금해하는 사람은 없었다. 나는 직장인이었다. 누구나 알고 선망의 대상이 되는 회사를 다니는.

3. 쿠팡과 마이리얼트립. 전자는 전 국민이 아는 회사고, 후자도 여행씬에서는 선 굵은 회사가 됐다. 하지만 내가 합류했을 때는 전혀 아니었다. 그저 이제 막 시작하는 작은 스타트업이었을 뿐이다.

4. 쿠팡에 있을 때 로켓배송을 런칭했다. 오늘 주문하면 내일 받아요. 지금은 너무 당연하고 자연스럽다. 그 당시에는? 그 누구도 그게 가능하다고 믿지 않았다. 심지어 만드는 사람들조차도.

5. 쿠팡 다녀요. 그게 무슨 회사인데? 당시 네이버 동료를 만났다. 하는 일을 설명했다. 아, 배송하는구나? 구구절절 설명해도 이해시키지 못했다. 그게 맞아요. 대화의 매듭을 짓기 일쑤였다.

6. 마이리얼트립도 똑같았다. 당시 마이 리틀 텔레비전이란 프로그램이 인기였다. 줄여서 마리텔이라 불렀다. 마이리얼트립의 약자는 마리트. 둘의 단어를 모두 다 헷갈려 했다.

7. 그때의 여행 시장은 패키지 상품뿐이었다. 여행을 원하는 고객의 선택지는 많지 않았다. 자유여행의 수요를 받아내는 가이드 투어 시장의 크기는 가늠되기 전이었다. 역시나 하는 일의 설명은 쉽지 않았다. 그냥 여행사구나. 정확한 설명 보다 쉬운 마무리로 끝낼 때가 많았다.

8. 지금, 스페이스오디티도 낯설다. 우리는 팬 중심의 케이팝 생태계를 꿈꾼다. 소비자인 팬에게 쉽고 재밌는 덕질을, 아티스트에게는 새로운 팬이 생기게 돕는다. 이 일은 엔터 사람에게도 생소하다. 씬을 바꿔보려는 시도니까. 평범한 소비자는 이해하기 더 어렵다. 아직은.

9. 회사는 내가 아니다. 멋진 회사명, 그 테두리 안에 있을 때는 회사가 나인 거 같다. 파트너를 대하거나 주변 사람을 만날 때도 역시 동일시된다. 그게 바로 직장인이다. 회사의 미래가 나의 미래인가? 나의 미래는 회사인가? 당연히 둘 다 아니다. 착각하면 안 된다.

10. 직업인은 다르다. 어디에 적을 두고 있건, 가치는 내가 만든다. 나의 역량이 곧 나의 가치다. 주어진 문제를 풀고, 새로운 가치를 만든다. 대부분의 스타트업이 그렇다. 회사명도 내가 하는 일도 아무도 모른다. 그래서 더더욱 내가 중요하다. 오히려 내가 회사를 만들어가야 한다.

11. 평생직장의 시대는 갔다. 이제는 기술로 일자리도 사라진다. 직업인으로써의 내 정체성은 무엇일까. 그것을 어떻게 정의하고, 성장할지의 고민이 더 중요하다. 그래서 '직업'인으로 성장하는데 스타트업은 좋은 '직장'이다.

1. 네이버를 두 번 다녔다. 퇴사 후 다른 회사들을 거쳐 다시 입사했다. 지금은 모르겠으나 당시에는 비개발 직군 재입사는 처음 있는 일이었다. 대표와 창업자의 컨펌까지 필요했다. 다른 이유는 아니다. 사례가 없던 예외 케이스였기 때문이다. ​2. 네이버 다녀요. 낯선 누군가를 만나서 나를 소개한다. 그 이상의 질문은 없었다. 회사의 브랜드와 이미지 때문이었을까. 네이버에서 무슨 일을 하는지 궁금해하는 사람은 없었다. 나는 직장인이었다. 누구나 알고 선망의 대상이 되는 회사를 다니는. ​3. 쿠팡과 마이리얼트립. 전자는 전 국민이 아는 회사고, 후자도 여행씬에서는 선 굵은 회사가 됐다. 하지만 내가 합류했을 때는 전혀 아니었다. 그저 이제 막 시작하는 작은 스타트업이었을 뿐이다. ​4. 쿠팡에 있을 때 로켓배송을 런칭했다. 오늘 주문하면 내일 받아요. 지금은 너무 당연하고 자연스럽다. 그 당시에는? 그 누구도 그게 가능하다고 믿지 않았다. 심지어 만드는 사람들조차도. ​5. 쿠팡 다녀요. 그게 무슨 회사인데? 당시 네이버 동료를 만났다. 하는 일을 설명했다. 아, 배송하는구나? 구구절절 설명해도 이해시키지 못했다. 그게 맞아요. 대화의 매듭을 짓기 일쑤였다. ​6. 마이리얼트립도 똑같았다. 당시 마이 리틀 텔레비전이란 프로그램이 인기였다. 줄여서 마리텔이라 불렀다. 마이리얼트립의 약자는 마리트. 둘의 단어를 모두 다 헷갈려 했다. ​7. 그때의 여행 시장은 패키지 상품뿐이었다. 여행을 원하는 고객의 선택지는 많지 않았다. 자유여행의 수요를 받아내는 가이드 투어 시장의 크기는 가늠되기 전이었다. 역시나 하는 일의 설명은 쉽지 않았다. 그냥 여행사구나. 정확한 설명 보다 쉬운 마무리로 끝낼 때가 많았다. ​8. 지금, 스페이스오디티도 낯설다. 우리는 팬 중심의 케이팝 생태계를 꿈꾼다. 소비자인 팬에게 쉽고 재밌는 덕질을, 아티스트에게는 새로운 팬이 생기게 돕는다. 이 일은 엔터 사람에게도 생소하다. 씬을 바꿔보려는 시도니까. 평범한 소비자는 이해하기 더 어렵다. 아직은. ​9. 회사는 내가 아니다. 멋진 회사명, 그 테두리 안에 있을 때는 회사가 나인 거 같다. 파트너를 대하거나 주변 사람을 만날 때도 역시 동일시된다. 그게 바로 직장인이다. 회사의 미래가 나의 미래인가? 나의 미래는 회사인가? 당연히 둘 다 아니다. 착각하면 안 된다. ​10. 직업인은 다르다. 어디에 적을 두고 있건, 가치는 내가 만든다. 나의 역량이 곧 나의 가치다. 주어진 문제를 풀고, 새로운 가치를 만든다. 대부분의 스타트업이 그렇다. 회사명도 내가 하는 일도 아무도 모른다. 그래서 더더욱 내가 중요하다. 오히려 내가 회사를 만들어가야 한다. ​11. 평생직장의 시대는 갔다. 이제는 기술로 일자리도 사라진다. 직업인으로써의 내 정체성은 무엇일까. 그것을 어떻게 정의하고, 성장할지의 고민이 더 중요하다. 그래서 '직업'인으로 성장하는데 스타트업은 좋은 '직장'이다. ​

< '네이버 다녀요'라는 말에 아무도 무슨 일을 하는지는 묻지 않

1. 기술이 세상을 다 먹은 지 오래다. AI가 세상을 다 바꿔버리는 요즘에 테크란 단어는 참 새삼스럽다. 하지만 케이팝을 중심으로 하는 엔터 시장은 이제 시작이다.

2. 블록체인, 메타버스, AR/VR, NFT, web3만 테크가 아니다. 가치보다 기술을 앞세운 시도는 모두 망했다. 적어도 대중적인 성공은 아직 없으니까. 다른 산업에서도 자리를 못 잡은 기술로 엔터에서 성공할 수 있을까. 새로움은 아이디어 싸움이 아니다. 아이디어만으로는 세상을 절대 바꿀 수 없다.

3. 기본이 중요하다. 시작은 고객을 이해하는 일이다. 아티스트를 만드는 기획사는 고객인 팬을 잘 모른다. 고객을 만들고, 이해하는데 엔터에 테크가 결합해서 만들 수 있는 가치가 많다. 크게 세 가지 키워드다.

4. 첫 번째 디지털. 디지털은 복제 비용이 제로다. 비용이 줄면, 마진이 커져야 한다. 또한, 모든 유저는 흔적을 남긴다. 데이터다. 데이터로 고객이 누군지 알고, 써먹을 수 있어야 한다.

5. 엔터는 그러한가? 아니다. 디지털 음원으로 사용자는 편리하다. 유통사는 돈을 번다. 그럼 기획사는? 음원은 음반을 대체한다. 게다가 유저의 데이터를 갖고 있지도 못하다.

6. 아티스트가 자산이다. 사람을 파는 게 가장 확실한 수익모델이다. 오랜시간 달라지지 않았다. 음반을 사면 포카를 준다. 포카는 가챠다. 음반을 많이 사야 팬사인회를 간다. 공연과 광고도 마찬가지다. 모두 오프라인, 사람 중심이다. 복제할 수 없다. 물리적 한계가 명확하다. 이게 최선이 아니란 건 모두 다 알고 있다. 하지만 당장 대안은 없다.

7. 둘째 공급자 마인드. 만든다고 팔리지 않는다. 취향은 쪼개지고, 상품은 무한하다. 팬의 돈과 시간은 한정되어 있다. 하이브 의장은 라이트 팬이 적은게 케이팝의 위기라 말했다. 팔 사람이 더 필요하다는 얘기다. 공급자 중심의 시대는 이미 끝났다. 그때는 맞고 지금은 틀리다. 이제는 하던 대로 해도, 안 팔린다. 똑같은 짓을 하면서, 다른 결과를 기대할 순 없다.

8. 다른 시장과 산업은? 모두 과거 얘기다. 기술이 모두 바꿨다. 이제 돈 내는 소비자가 왕이다. 그 누구도 불편함을 감수하며 지갑을 열지 않는다. 마지막 남은 시장이 엔터다. OTT로 눈이 높아진 고객은 수준 낮은 영화가 걸린 극장에 안 간다.

9. 데이터는 없다. 고객도 모른다. 막막하다. 심지어 치킨 집과 카페도 쿠폰을 주는 시대다. 모두 고객을 특정하려한다. 다시 찾게 이끄려고 한다. 엔터는 이런 최소한의 CRM 조차 없다.

10. 초동 100만 장. 누가 사는지 모른다. 100만이 아니라, 몇 명이, 또 누가 샀는지가 중요하다. 공연 티켓이 팔린다. 역시 누가 샀는지 모른다. 예매 사이트만 알뿐. 음원도 마찬가지. 스트리밍 숫자는 있어도, 누가 들었는지 모른다. 데이터가 없다. 팬이 누군지 모르는거다. 이제 먼저 수요부터 들여다봐야 한다.

11. 세 번째 창작의 과정. 역사적으로 창작의 과정은 진화해왔다. 건축과 제조는 대량생산에 적합했다. 생산 비용이 크다. 투자 비용도 크다. 건물을 만들다가 설계를 바꿀 순 없다. 반도체 같은 제도업도 마찬가지다. 초기 투자 비용이 크다. 기획과 설계가 중요하다.

12. 디지털은 다르다. 린하게 만들 수 있다. 기획보다 실행이 중요하다. 고객에게 물어보기다. 일단 작게 던져보고 고객의 피드백을 얻는다. 데이터를 본다. 이를 통해 배우고 다시 시도한다. 반복한다. 리스크가 줄었고 성공 확률은 높아졌다. 시행착오와 기회비용이 작다. 오늘날 IT 기반 스타트업이 일하는 방식이다. 이미 다 만들고 팔 궁리를 하면? 늦다. 무조건 실패다. 만들면서 팔 방법을 같이 고민해야 한다.

13. 물론 이런 시도가 없는 건 아니다. 사람이 기술과 만나자 IP가 중요해졌다. 아티스트의 메시지를 유료로 구독하고, 데뷔 전 아티스트를 노출하고 반응을 보기도 한다. 사람 리스크가 없는 버추얼 아티스트도 흥한다.

14. 고객에게 기술을 어필해서 성공한 제품은 없다. 사용자가 배워야 하는 서비스가 성공한 적도 없다. 이미 존재하는 기술을 써먹으려는 시도도 모두 실패했다. 하지만 기술은 반드시 필요하다. 보이지 않는 곳에서 가장 큰 가치를 만든다. 엔터가 고객을 만들고 이해하는데도 필수다.

15. 고객이 누구인가, 단골은 어떤 사람들인가. 새로운 걸 쫓는 게 아니라, 기본을 먼저 다시 돌아봐야 한다. 사업의 기본은 고객이니까. 내 물건과 가치를 알아보고 사 주는 사람. 엔터에서는 그게 곧 팬이다. 모든 아티스트는 팬이 있기에 존재할 수 있으니까. 엔터에 테크가 결합해서 만들 수 있는 무궁무진한 가치다.

1. 기술이 세상을 다 먹은 지 오래다. AI가 세상을 다 바꿔버리는 요즘에 테크란 단어는 참 새삼스럽다. 하지만 케이팝을 중심으로 하는 엔터 시장은 이제 시작이다. ​2. 블록체인, 메타버스, AR/VR, NFT, web3만 테크가 아니다. 가치보다 기술을 앞세운 시도는 모두 망했다. 적어도 대중적인 성공은 아직 없으니까. 다른 산업에서도 자리를 못 잡은 기술로 엔터에서 성공할 수 있을까. 새로움은 아이디어 싸움이 아니다. 아이디어만으로는 세상을 절대 바꿀 수 없다. ​3. 기본이 중요하다. 시작은 고객을 이해하는 일이다. 아티스트를 만드는 기획사는 고객인 팬을 잘 모른다. 고객을 만들고, 이해하는데 엔터에 테크가 결합해서 만들 수 있는 가치가 많다. 크게 세 가지 키워드다. ​4. 첫 번째 디지털. 디지털은 복제 비용이 제로다. 비용이 줄면, 마진이 커져야 한다. 또한, 모든 유저는 흔적을 남긴다. 데이터다. 데이터로 고객이 누군지 알고, 써먹을 수 있어야 한다. ​5. 엔터는 그러한가? 아니다. 디지털 음원으로 사용자는 편리하다. 유통사는 돈을 번다. 그럼 기획사는? 음원은 음반을 대체한다. 게다가 유저의 데이터를 갖고 있지도 못하다. ​6. 아티스트가 자산이다. 사람을 파는 게 가장 확실한 수익모델이다. 오랜시간 달라지지 않았다. 음반을 사면 포카를 준다. 포카는 가챠다. 음반을 많이 사야 팬사인회를 간다. 공연과 광고도 마찬가지다. 모두 오프라인, 사람 중심이다. 복제할 수 없다. 물리적 한계가 명확하다. 이게 최선이 아니란 건 모두 다 알고 있다. 하지만 당장 대안은 없다. ​7. 둘째 공급자 마인드. 만든다고 팔리지 않는다. 취향은 쪼개지고, 상품은 무한하다. 팬의 돈과 시간은 한정되어 있다. 하이브 의장은 라이트 팬이 적은게 케이팝의 위기라 말했다. 팔 사람이 더 필요하다는 얘기다. 공급자 중심의 시대는 이미 끝났다. 그때는 맞고 지금은 틀리다. 이제는 하던 대로 해도, 안 팔린다. 똑같은 짓을 하면서, 다른 결과를 기대할 순 없다. ​8. 다른 시장과 산업은? 모두 과거 얘기다. 기술이 모두 바꿨다. 이제 돈 내는 소비자가 왕이다. 그 누구도 불편함을 감수하며 지갑을 열지 않는다. 마지막 남은 시장이 엔터다. OTT로 눈이 높아진 고객은 수준 낮은 영화가 걸린 극장에 안 간다. ​9. 데이터는 없다. 고객도 모른다. 막막하다. 심지어 치킨 집과 카페도 쿠폰을 주는 시대다. 모두 고객을 특정하려한다. 다시 찾게 이끄려고 한다. 엔터는 이런 최소한의 CRM 조차 없다. ​10. 초동 100만 장. 누가 사는지 모른다. 100만이 아니라, 몇 명이, 또 누가 샀는지가 중요하다. 공연 티켓이 팔린다. 역시 누가 샀는지 모른다. 예매 사이트만 알뿐. 음원도 마찬가지. 스트리밍 숫자는 있어도, 누가 들었는지 모른다. 데이터가 없다. 팬이 누군지 모르는거다. 이제 먼저 수요부터 들여다봐야 한다. ​11. 세 번째 창작의 과정. 역사적으로 창작의 과정은 진화해왔다. 건축과 제조는 대량생산에 적합했다. 생산 비용이 크다. 투자 비용도 크다. 건물을 만들다가 설계를 바꿀 순 없다. 반도체 같은 제도업도 마찬가지다. 초기 투자 비용이 크다. 기획과 설계가 중요하다. ​12. 디지털은 다르다. 린하게 만들 수 있다. 기획보다 실행이 중요하다. 고객에게 물어보기다. 일단 작게 던져보고 고객의 피드백을 얻는다. 데이터를 본다. 이를 통해 배우고 다시 시도한다. 반복한다. 리스크가 줄었고 성공 확률은 높아졌다. 시행착오와 기회비용이 작다. 오늘날 IT 기반 스타트업이 일하는 방식이다. 이미 다 만들고 팔 궁리를 하면? 늦다. 무조건 실패다. 만들면서 팔 방법을 같이 고민해야 한다. ​13. 물론 이런 시도가 없는 건 아니다. 사람이 기술과 만나자 IP가 중요해졌다. 아티스트의 메시지를 유료로 구독하고, 데뷔 전 아티스트를 노출하고 반응을 보기도 한다. 사람 리스크가 없는 버추얼 아티스트도 흥한다. ​14. 고객에게 기술을 어필해서 성공한 제품은 없다. 사용자가 배워야 하는 서비스가 성공한 적도 없다. 이미 존재하는 기술을 써먹으려는 시도도 모두 실패했다. 하지만 기술은 반드시 필요하다. 보이지 않는 곳에서 가장 큰 가치를 만든다. 엔터가 고객을 만들고 이해하는데도 필수다. ​15. 고객이 누구인가, 단골은 어떤 사람들인가. 새로운 걸 쫓는 게 아니라, 기본을 먼저 다시 돌아봐야 한다. 사업의 기본은 고객이니까. 내 물건과 가치를 알아보고 사 주는 사람. 엔터에서는 그게 곧 팬이다. 모든 아티스트는 팬이 있기에 존재할 수 있으니까. 엔터에 테크가 결합해서 만들 수 있는 무궁무진한 가치다.

< 초동 100만 장, 그런데 팬은 어디 있죠? - 엔터 테크와

ChatGPT 사용할 때 어떤 모델을 선택해야할지 망설여집니다. 모델명만 봐서는 어떤게 좋은지 모르겠더라고요.

그래서 ChatGPT에게 설명을 부탁해봤습니다.

🧠 GPT-3.5 (2022)
→ 중학생처럼 똑똑한 AI. 질문 잘하지만 가끔 헷갈림.

🎓 GPT-4 (2023)
→ 고등학생 수준의 AI. 더 정확하고 추론도 잘함.

⚡ GPT-4-turbo (2023 말~)
→ GPT-4보다 빠르고 저렴한 버전. 급식 줄 안 서는 느낌!

🧑‍🎓 GPT-4.5 (비공식 명칭)
→ GPT-4랑 5 사이. 중3.5학년 느낌의 중간단계 모델.

🧞 GPT-4o = o4 (2024)
→ ‘omni’ = 만능! 글, 이미지, 음성까지 다 되는 AI 친구.

🧪 o3
→ GPT-4o의 시험판. 모의고사 버전 느낌.

🎯 o4-mini
→ GPT-4o보다 작고 빠른 축소형. 시험 족보 외우는 친구 느낌.

ChatGPT 사용할 때 어떤 모델을 선택해야할지 망설여집니다. 모델명만 봐서는 어떤게 좋은지 모르겠더라고요. 그래서 ChatGPT에게 설명을 부탁해봤습니다. 🧠 GPT-3.5 (2022)→ 중학생처럼 똑똑한 AI. 질문 잘하지만 가끔 헷갈림. 🎓 GPT-4 (2023)→ 고등학생 수준의 AI. 더 정확하고 추론도 잘함. ⚡ GPT-4-turbo (2023 말~)→ GPT-4보다 빠르고 저렴한 버전. 급식 줄 안 서는 느낌! 🧑‍🎓 GPT-4.5 (비공식 명칭)→ GPT-4랑 5 사이. 중3.5학년 느낌의 중간단계 모델. 🧞 GPT-4o = o4 (2024)→ ‘omni’ = 만능! 글, 이미지, 음성까지 다 되는 AI 친구. 🧪 o3→ GPT-4o의 시험판. 모의고사 버전 느낌. 🎯 o4-mini→ GPT-4o보다 작고 빠른 축소형. 시험 족보 외우는 친구 느낌.

ChatGPT 버전명 설명

공공디자인, 중앙정부를 넘어 Public Design Beyond Central Government Report 2025 핵심 인사이트 및 권고안 2025년 5월 7일 영국 디자인카운슬 '공공부문에서 디자인이 ...

공공디자인, 중앙정부를 넘어 - 영국 디자인카운슬, 2025

영국 디자인카운슬이 2025년 5월 발표한 'Public Design Beyond Central Gorvernment Report 2025'를 번역한 내용입니다. 현재 UX 업계에서 UX 리서치, UX 라이팅이 처한 상황과 유사한 상황에서 - 예산이 삭감되는 상황에서 그 역할을 지속할 것인가? 예전처럼 프로덕트 디자이너에게 통합할 것인가? 등의 논의 - 더 나은 사용자 경험을 고민하는 분들에게 일독을 추천합니다. 아래 링크를 통해서 원문 보고서*를 다운로드하실 수도 있습니다.

*보고서는 디자인카운슬의 ‘디자인 이코노미(Design Economy)’ 연구의 일환으로 2022년에 공공부문 종사자 1,018명을 대상으로 실시한 설문조사와, 2023~2024년에 공공디자인 리더 32명이 참여한 두 차례의 참여형 워크숍을 기반으로 했습니다.

"지금 영국 공공부문은 국가 전반의 구조적 위기를 반영하며 큰 압박에 놓여 있다. 향후 예산은 실질적으로 삭감될 가능성이 크고, 이미 NHS나 아동 특수교육과 같은 주요 영역에서는 대중의 신뢰가 흔들리고 있다. 이럴 때일수록 디자인 역량을 사치로 취급하며 우선순위에서 밀려나게 해서는 안 된다. 디자인은 어려운 시기에 더욱 절실한 자산이다. 디자인 역량을 활용하면 재정 제약 속에서도 시민과 함께 더 나은 서비스와 결과를 만들 수 있다."

[ 큐레이터의 문장 🎒 ]

1️⃣ 현재 공공부문 조직의 88%는 디자인이 자사에 중요한 역할을 한다고 답했다.

2️⃣ 영국 지방정부 50%가 내부에 서비스 디자이너를 고용하고 있다.

3️⃣ 공공부문에서 디자인이 가장 많이 활용되는 영역은 서비스와 프로세스 개선(71%)이다.

4️⃣ 현재 공공부문에서 58%는 디자인 업무를 하고 있다고 답했지만, 그중 스스로를 전문가라고 평가한 비율은 13%에 불과하다.

5️⃣ 응답자의 58%는 자신이 하는 일에 디자인이 포함된다고 답했으며, 약 1/3은 조직 전략 수준에서 디자인을 활용하고 있다고 응답했다.

https://www.designdb.com/?menuno=790&bbsno=31543&siteno=15&act=view&ztag=rO0ABXQAOTxjYWxsIHR5cGU9ImJvYXJkIiBubz0iNTkxIiBza2luPSJwaG90b19iYnNfMjAxOSI+PC9jYWxsPg%3D%3D#gsc.tab=0

영국 디자인카운슬이 2025년 5월 발표한 'Public Design Beyond Central Gorvernment Report 2025'를 번역한 내용입니다. 현재 UX 업계에서 UX 리서치, UX 라이팅이 처한 상황과 유사한 상황에서 - 예산이 삭감되는 상황에서 그 역할을 지속할 것인가? 예전처럼 프로덕트 디자이너에게 통합할 것인가? 등의 논의 - 더 나은 사용자 경험을 고민하는 분들에게 일독을 추천합니다. 아래 링크를 통해서 원문 보고서*를 다운로드하실 수도 있습니다. *보고서는 디자인카운슬의 ‘디자인 이코노미(Design Economy)’ 연구의 일환으로 2022년에 공공부문 종사자 1,018명을 대상으로 실시한 설문조사와, 2023~2024년에 공공디자인 리더 32명이 참여한 두 차례의 참여형 워크숍을 기반으로 했습니다. "지금 영국 공공부문은 국가 전반의 구조적 위기를 반영하며 큰 압박에 놓여 있다. 향후 예산은 실질적으로 삭감될 가능성이 크고, 이미 NHS나 아동 특수교육과 같은 주요 영역에서는 대중의 신뢰가 흔들리고 있다. 이럴 때일수록 디자인 역량을 사치로 취급하며 우선순위에서 밀려나게 해서는 안 된다. 디자인은 어려운 시기에 더욱 절실한 자산이다. 디자인 역량을 활용하면 재정 제약 속에서도 시민과 함께 더 나은 서비스와 결과를 만들 수 있다." [ 큐레이터의 문장 🎒 ] 1️⃣ 현재 공공부문 조직의 88%는 디자인이 자사에 중요한 역할을 한다고 답했다. 2️⃣ 영국 지방정부 50%가 내부에 서비스 디자이너를 고용하고 있다. 3️⃣ 공공부문에서 디자인이 가장 많이 활용되는 영역은 서비스와 프로세스 개선(71%)이다. 4️⃣ 현재 공공부문에서 58%는 디자인 업무를 하고 있다고 답했지만, 그중 스스로를 전문가라고 평가한 비율은 13%에 불과하다. 5️⃣ 응답자의 58%는 자신이 하는 일에 디자인이 포함된다고 답했으며, 약 1/3은 조직 전략 수준에서 디자인을 활용하고 있다고 응답했다. https://www.designdb.com/?menuno=790&amp;bbsno=31543&amp;siteno=15&amp;act=view&amp;ztag=rO0ABXQAOTxjYWxsIHR5cGU9ImJvYXJkIiBubz0iNTkxIiBza2luPSJwaG90b19iYnNfMjAxOSI+PC9jYWxsPg%3D%3D#gsc.tab=0

www.designdb.com

⟪디자인의 역할은 프로세스에서 낭비를 줄이고 생산성을 개선하는 것

안녕하세요.
데이터를 재미있고 가치있게 배울수 있도록
돕는 데이터 리차드입니다.

DADB는 Data Analyst Digital Brain을 의미합니다.
데이터 분석가를 위해 노션으로 만든 디지털 도구로

👨🏻‍💻 데이터 분석가가 어떤 업무를 하는 사람(Who is DA)인지 알려줍니다.
🔗 데이터 분석에서 가장 많이 사용하는 프레임워크(Framework)를 소개합니다.
🔧 데이터 분석에 필요한 스킬셋(Skillset)을 알려줍니다.
🔁 데이터 분석 프로세스(Process)에 대해 알려줍니다.
📖 데이터 분석 학습자료(Resource) 에 대해 알려줍니다.

성장하는 데이터 분석가가 되고 싶은 탐험가들,
데이터 분석 프로젝트를 끝까지 완수하고 싶은 탐험가들,
데이터 분석을 어떻게 시작해야 할지 막막한 탐험가들을 위해
만든 DADB는

현재 #사전예약 을 받고 있어요.
출시 예정 일자는 10월 20일입니다.

데이터를 더욱 재미있고 가치있게 배울수 있도록
#데이터리차드 가 함께 하겠습니다.

👇 사전 신청 링크는 여기에 있어요
https://tally.so/r/wvD2Rl

#DADB #데이터분석가 #디지털브레인

안녕하세요. 데이터를 재미있고 가치있게 배울수 있도록 돕는 데이터 리차드입니다. DADB는 Data Analyst Digital Brain을 의미합니다. 데이터 분석가를 위해 노션으로 만든 디지털 도구로 👨🏻‍💻 데이터 분석가가 어떤 업무를 하는 사람(Who is DA)인지 알려줍니다. 🔗 데이터 분석에서 가장 많이 사용하는 프레임워크(Framework)를 소개합니다. 🔧 데이터 분석에 필요한 스킬셋(Skillset)을 알려줍니다. 🔁 데이터 분석 프로세스(Process)에 대해 알려줍니다. 📖 데이터 분석 학습자료(Resource) 에 대해 알려줍니다. 성장하는 데이터 분석가가 되고 싶은 탐험가들, 데이터 분석 프로젝트를 끝까지 완수하고 싶은 탐험가들, 데이터 분석을 어떻게 시작해야 할지 막막한 탐험가들을 위해 만든 DADB는 현재 <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.linkedin.com/feed/hashtag/?keywords=%EC%82%AC%EC%A0%84%EC%98%88%EC%95%BD&amp;highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7118482131386843138">#사전예약</a> 을 받고 있어요. 출시 예정 일자는 10월 20일입니다. 데이터를 더욱 재미있고 가치있게 배울수 있도록 <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.linkedin.com/feed/hashtag/?keywords=%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%A6%AC%EC%B0%A8%EB%93%9C&amp;highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7118482131386843138">#데이터리차드</a>&nbsp;가 함께 하겠습니다. 👇 사전 신청 링크는 여기에 있어요 <a target="_blank" rel="noopener noreferrer nofollow" href="https://tally.so/r/wvD2Rl">https://tally.so/r/wvD2Rl</a><a target="_blank" rel="noopener noreferrer nofollow" href="https://tally.so/r/wvD2Rl￼￼#DADB"> #DADB</a>&nbsp;<a target="_blank" rel="noopener noreferrer nofollow" href="https://www.linkedin.com/feed/hashtag/?keywords=%EB%8D%B0%EC%9D%B4%ED%84%B0%EB%B6%84%EC%84%9D%EA%B0%80&amp;highlightedUpdateUrns=urn%3Ali%3Aactivity%3A7118482131386843138">#데이터분석가</a>&nbsp;#디지털브레인

@AZ 안녕하세요. 
현재 DADB는 전반적인 데이터 분석 프로세스를 알려주는 도구로 제공되고 있습니다. 특정 툴을 다루고 있지는 않는 점 알려드립니다 :)

처음 배워도 재미있고 가치있는 DATA/AI 교육을 만듭니다.

𝙍𝙞𝙘𝙝𝙖𝙧𝙙 

당신이 DATA/AI를 재미있고 가치있게 배울수 있도록 돕습니다.
Founder @ datarichard (datarichard.super.site)


새로워진 DADB를 만나보세요

댓글 2

비슷한 게시물

주간 인기 TOP 10

추천 프로필