반응형
반응형

당신이 커리어를 설계하지 않으면, 누군가가 대신 설계할 것이다 (2014)

 

If You Don't Design Your Career, Someone Else Will - Greg McKeown

  • 일상과 업무에 몰두한 나머지 자신의 커리어를 성찰하지 못하는 함정을 지적하며, 이를 벗어나기 위한 구체적 절차를 제시
  • 지난 12개월을 검토하고 주요 프로젝트·성과를 목록화한 뒤, 그 안의 흐름과 의미를 분석하도록 권장
  • 제한 없는 사고로 이상적인 커리어 방향을 구상하고, 현실적 제약으로 지나치게 빨리 포기하지 말 것을 강조
  • 목표를 여섯 가지로 정리한 후 단 하나의 핵심 목표만 남기고 집중하며, 이를 방해하는 ‘좋은 일들’을 과감히 거절해야 함
  • 짧은 시간의 성찰이 향후 수천 시간의 삶의 질을 바꿀 수 있음을 강조하며, 스스로 커리어를 설계할 필요성을 환기

커리어를 스스로 설계해야 하는 이유

  • 사람들은 종종 삶을 사느라 바빠서 삶을 생각하지 못하는 함정에 빠짐
    • 커리어에서도 마찬가지로, 일에 몰두한 나머지 커리어 자체를 돌아보지 못하는 경우가 많음
  • 이러한 상태를 피하기 위해 휴일 중 몇 시간을 투자해 커리어를 성찰하는 과정을 제안

8단계 커리어 성찰 프로세스

  • 1단계: 지난 12개월 검토
    • 한 해를 월별로 돌아보며 시간 사용처, 주요 프로젝트, 책임, 성과를 목록화
    • 복잡하게 만들 필요 없이 단순한 기록으로 충분함
  • 2단계: ‘무슨 일이 일어나고 있는가?’ 질문
    • 목록을 검토하며 실제로 어떤 일이 진행 중인지, 왜 중요한지, 어떤 추세가 있는지 분석
    • 이러한 추세가 계속될 경우의 결과를 생각
  • 3단계: ‘무엇이든 할 수 있다면 무엇을 할 것인가?’ 질문
    • 비판 없이 자유롭게 아이디어를 적어내며, 제약 없는 사고를 유도
  • 4단계: 3단계 아이디어 확장
    • 현실적 제약 때문에 지나치게 빨리 포기하지 말고, 진정 원하는 방향을 더 깊이 탐색
    • “비현실적이다”라는 이유로 배제된 길이 실제로는 정당한 커리어 경로일 수 있음
  • 5단계: 향후 12개월 목표 6가지 작성
    • 달성하고 싶은 주요 커리어 목표를 우선순위에 따라 정리
  • 6단계: 하위 5개 목표 삭제
    • 단 하나의 ‘진정한 북극성’ 목표에 집중
    • 업무의 소용돌이 속에서도 방향을 잃지 않게 함
  • 7단계: 이번 달 실행 계획 수립
    • 3~4주 내 달성 가능한 단기 성과(quick wins) 를 설정
  • 8단계: ‘무엇을 거절할 것인가’ 결정
    • 핵심 목표 달성을 방해하는 ‘좋은 일들’을 목록화하고, 삭제·연기·위임 방안을 마련
    • Ralph Waldo Emerson의 말을 인용해, “주된 목적에서 벗어나 여기저기 일하는 것이 개인과 국가를 파산시킨다”고 경고
    •  
반응형
반응형

10년 차 PM이 '관리자'라는 타이틀을 버리고 'Product Architect'가 된 이유

 

AI가 코딩하고 디자인하는 시대, "일정 조율하고 리소스 관리하는" 전통적인 PM의 역할은 유효할까요?

2026년 새해를 맞아, 지난 10년간 저를 정의했던 PM(Product Manager)이라는 껍질을 깨고 'Product Architect'로 역할을 재정의했습니다. 단순히 이름만 바꾼 것이 아닙니다. 일하는 방식과 툴, 관점을 완전히 뜯어고쳤습니다.

'AI 시대 생존을 위한 3가지 원칙'을 공유합니다.

  1. 고정관념 깨기: "조율할 대상이 사라졌다"

여전히 개발자, 디자이너 사이를 조율하는 게 PM의 일일까?
AI 시대엔 직접 만들고 책임지는 사람이 가장 안전합니다.

  1. 방식 바꾸기: "익숙한 것이 가장 비효율적이다"
  • 기획서 쓰고 -> 디자인 넘기고 -> 개발 기다리는 '선형적 프로세스'의 종말.
  • 이제 Replit으로 기획과 동시에 구현하고, Snapdeck으로 10분 만에 제안서를 만듭니다.
  1. 재정의하기: "Manager에서 Architect로"
  • 매니저(Manager)로 정의하면 '관리할 일'만 생깁니다.
  • 아키텍트(Architect)로 정의해야 '설계할 가치'가 보입니다.

더 이상 '성실한 관리자'는 정답이 아닙니다. 변화하는 시대, 여러분은 스스로를 무엇으로 정의하고 계신가요?

 

 

 

https://maily.so/insightlog/posts/1gz2796xr3q

 

2026년, 저는 PM이라는 직함을 버리기로 했습니다.

고정관념, 방식, 그리고 업의 재정의에 대하여

maily.so

 

반응형
반응형

소프트웨어 개발의 미래는 소프트웨어 개발자들이다 

https://news.hada.io/topic?id=25448

  • 수십 년간 반복된 “프로그래머의 종말” 예언은 매번 틀렸으며, 기술 발전은 오히려 더 많은 개발자와 프로그램의 증가로 이어져 왔음
  • WYSIWYG, 4GL, No-Code, LLM 등 다양한 자동화 기술이 등장했지만, 실제로는 개발자의 필요성을 줄이지 못했음
  • LLM 기반 도구는 과거 기술보다 신뢰성과 유지보수성이 떨어지며, 대부분의 팀에서 생산성 저하와 품질 악화를 초래함
  • 프로그래밍의 본질적 어려움은 코드 작성이 아니라 인간의 모호한 사고를 논리적으로 변환하는 능력에 있으며, 이는 여전히 인간의 영역임
  • 따라서 AI가 개발자를 대체할 가능성은 낮고, 오히려 숙련된 개발자에 대한 수요가 더 커질 전망임

반복되는 “프로그래머의 종말” 주기

  • 지난 43년간 Visual Basic, Delphi, Executable UML, No-Code, Low-Code 등 다양한 기술이 프로그래머의 필요성을 없앨 것이라 주장되어 왔음
    • 1970~80년대에는 4GL, 5GL, 그 이전에는 Fortran, COBOL, 더 거슬러 올라가면 컴파일러 A-0조차 같은 예언을 받았음
    • 초기 전자식 컴퓨터 COLOSSUS는 물리적 배선으로 프로그래밍되었으며, 이후 세대가 “진짜 프로그래머가 아니다”라 조롱받기도 했음
  • 그러나 결과적으로는 프로그래머 수가 줄지 않고 오히려 증가, 이는 Jevons Paradox의 대표적 사례로 언급됨

LLM과 과거 기술의 차이

  • 과거 기술은 실제로 소프트웨어 생산 속도를 높이고 신뢰성도 확보했지만, LLM은 대부분의 팀에서 반대 효과를 보임
    • LLM은 코드 품질을 낮추고 유지보수를 어렵게 만들어 “LOSE-LOSE” 상황을 초래함
    • 동일한 프롬프트로도 동일한 결과를 내지 못하며, 생성된 코드에는 인간 개발자의 검증과 수정이 필수적임
  • AI가 개발자를 대체한다는 증거는 없음, 최근 인력 감축은 팬데믹 시기 과잉 채용, 금리 상승, 데이터센터 투자 집중 등 경제 요인 때문임

프로그래밍의 본질적 난제

  • 프로그래밍의 핵심은 인간의 모호한 사고를 논리적으로 정밀한 계산 사고로 전환하는 과정임
    • 이는 천공카드 시절부터 COBOL, Visual Basic, Python에 이르기까지 변하지 않은 어려움임
  • 자연어는 본질적으로 모호하고 비정확하기 때문에, 영어나 프랑스어로 프로그래밍하는 시대는 오지 않을 것이라 Dijkstra의 예언을 인용함
  • 이러한 사고방식을 배우는 것은 가능하지만, 모두가 즐기거나 잘할 수 있는 일은 아니며, 숙련된 인력의 공급은 항상 부족함

AI의 한계와 지속 가능성

  • AGI(범용 인공지능) 은 여전히 멀리 있으며, 인간 수준의 이해·추론·학습 능력이 필요함
  • 대규모 LLM은 막대한 비용과 손실을 초래하고 있어 장기적으로 지속 가능하지 않음
    • 시간이 지나면 모델이 학습한 언어·라이브러리 버전의 제약으로 인해 활용성이 떨어질 가능성 있음
    • 이러한 이유로 초대형 LLM은 ‘Apollo 달 탐사’처럼 비경제적 실험으로 남을 수 있음

미래의 개발 환경 전망

  • 가까운 미래의 소프트웨어 개발은 소규모 언어 모델 기반의 보조 도구가 프로토타입 생성이나 코드 자동완성 등 보조 역할을 수행하는 형태로 예상됨
  • 그러나 중요한 결정과 품질 확보는 인간 개발자가 주도하며, Jevons의 법칙에 따라 개발자 수요는 오히려 증가할 가능성 있음
  • 기업은 지금부터 숙련된 개발자 채용과 교육에 투자해야 하며, 이는 AI 유무와 관계없이 생산성과 신뢰성을 높이는 핵심 전략
반응형
반응형

https://www.mk.co.kr/news/it/11921190

 

“수학 문제에서 중요한 것은 순서입니다. 사칙연산 순서를 알고 있나요?”

아이가 인공지능(AI)에 왜 수학 문제를 틀렸는지 묻자, AI는 답변 대신 질문을 던진다. 소크라테스식 대화법을 구현한 AI 튜터 ‘칸미고’의 모습이다. 칸아카데미가 오픈AI 최신 모델을 기반으로 개발한 이 프로그램은 단순한 대화 수준을 넘어 교육 패러다임을 바꾸고 있다.

최근 에듀테크의 화두는 ‘멀티모달’ 기능이다. 최신 AI 튜터들은 학생의 목소리 톤과 표정, 심지어 문제를 풀 때의 망설임까지 실시간으로 분석한다. 학생이 문제를 풀다 인상을 찌푸리면 AI는 “지금 이 부분이 조금 어렵게 느껴지나 보네. 같이 천천히 다시 해볼까”라며 응원과 함께 문제풀이 힌트를 준다.

과학교육도 진화하고 있다. ‘생성형 AI 기반 동적 가상 실험실’이 대표적인 사례다. 과거 막대한 예산이 들거나 위험했던 화학·물리 실험을 AI가 생성한 정교한 가상현실(VR) 환경에서 수행한다. 학생들은 AI 안내에 따라 분자 구조를 직접 손으로 조작하거나 행성 간 중력을 시뮬레이션하는 경험을 하며 원리를 깨우친다.

교사의 업무도 본질적 변화를 맞이했다. 월스트리트저널 보도에 따르면 지난해 미국 내 주요 교육청은 ‘매직스쿨’과 같은 교사 전용 AI 코파일럿 채택을 전년 대비 3배 이상 늘렸다. 교사들은 AI를 활용해 학생 수백 명에 대한 맞춤형 수업 계획을 몇 분 만에 생성한다. 역사 수업 중에는 에이브러햄 링컨 대통령을 가상세계로 소환해 학생들과 실시간 토론을 벌인다.

주목할 만한 대목은 이 같은 기술적 진보가 전통적 학교의 담장까지 허물고 있다는 점이다. AI가 정교한 학습 설계와 행정 업무를 지원하면서 소규모 공동체 학교인 ‘마이크로스쿨’이나 홈스쿨링을 선택하는 가정이 세계적으로 늘고 있다. 특히 AI 튜터로 핵심 교과 학습을 효율화하고, 남은 시간은 창의적 프로젝트에 할애하는 모델이 대안교육의 주류로 부상하는 추세다.

각국 정부는 AI 교육을 국가 경쟁력의 핵심으로 보고 과감한 투자를 이어가고 있다. 중국은 작년 9월부터 초등학교부터 AI 교육을 의무화했다. 동시에 저소득층 학생 100만명에게는 고성능 AI 학습 단말기를 보급해 교육 격차 해소에도 활용하고 있다. 싱가포르도 모든 초·중등 학생에게 맞춤형 AI 튜터 시스템을 보급했다. 아랍에미리트(UAE)는 세계 최초의 AI 전문대학(MBZUAI)을 중심으로 유치원부터 고교까지 AI를 필수과목으로 지정해 ‘AI 네이티브’ 세대를 육성 중이다.

 

반면 ‘세계 최초’를 내걸었던 한국의 AI 디지털교과서(AIDT)는 도입 과정부터 진통을 겪은 끝에 활용률이 8%대에 머물러 있다. 박남기 전 광주교대 총장은 “AI 앱을 활용하는 단계에서 ‘교과서’라는 용어에 집착해 불필요한 논쟁이 커진 측면이 있다”며 “학생들이 AI를 비판적으로 수용하는 리터러시 교육과, 교사들이 현장에서 AI를 자유자재로 다룰 수 있는 실용적 연수에 역량을 집중해야 할 시점”이라고 강조했다.

반응형
반응형

Google에서 14년간 얻은 21가지 교훈 (addyo.substack.com)

https://addyo.substack.com/p/21-lessons-from-14-years-at-google

 

21 Lessons from 14 Years at Google

On code, careers, and the human side of engineering

addyo.substack.com

💡 뛰어난 엔지니어의 통찰: 코드 너머의 성공 전략 요약

제시해 주신 내용은 '코드' 자체의 영리함보다는 사용자 문제 해결, 팀 정렬, 조직 운영, 그리고 장기적인 경력 설계에 초점을 맞춘, 선임 엔지니어의 핵심 역량에 대한 깊은 통찰을 담고 있습니다.

핵심 주제와 통찰을 4가지 범주로 나누어 요약 정리했습니다.


1. 👥 팀 협업 및 정렬 (사람과 정치)

뛰어난 엔지니어링은 기술 문제가 아닌, 사람과 조율의 문제입니다.

  • 함께 옳음에 도달하기: 기술 논쟁에서 이기는 것보다 함께 문제 정렬을 이루는 것이 진짜 업무입니다. '강한 의견, 약한 집착'의 태도로 타인을 위한 공간을 창출해야 합니다.
  • 정렬 실패가 속도 저하의 주범: 대규모 조직에서 팀이 느려지는 주된 원인은 실행 부족이 아니라 정렬 실패입니다. 선임 엔지니어는 코드를 빨리 작성하는 것보다 방향, 인터페이스, 우선순위 명확화에 시간을 투자해야 합니다.
  • 영향력의 가시화 (코드 너머의 옹호): 훌륭한 코드는 스스로 말하지 않습니다. 관리자와 동료가 당신을 옹호하도록 가치 사슬을 모두에게 읽기 가능하게 만드는 노력이 필요합니다.

2. ✨ 코드 품질 및 명확성 (기술적 통찰)

코드의 영리함은 오버헤드일 뿐이며, 명확성이 운영 리스크를 줄입니다.

  • 명확성이 시니어의 징표: 코드는 장애 중 새벽 2시에 유지보수할 낯선 사람들을 위한 전략 메모이므로, 영리함 대신 명확성을 최적화해야 합니다.
  • 최고의 코드는 작성하지 않은 코드: 시스템 개선은 추가보다 삭제에서 오는 경우가 많습니다. 디버깅, 유지보수, 설명할 필요가 없는 코드가 최고의 코드입니다.
  • 새로움은 빚: 기술 선택을 작은 '혁신 토큰' 예산으로 다루어야 합니다. 혁신으로 보상받는 곳에서만 혁신하고, 나머지는 알려진 실패 모드를 가진 지루한(표준적인) 기술을 기본값으로 삼아야 합니다.
  • 추상화의 한계: 모든 추상화는 복잡성을 제거하는 것이 아니라 당신이 온콜일 때로 이동시키는 것일 수 있습니다. 추상화가 실패할 때를 대비해 스택의 기본 실패 모드에 대한 작동 모델을 유지해야 합니다.

3. 🎯 사용자 문제 해결 및 출시 전략

사용자 문제 해결에 집착하고, 완벽 대신 행동을 우선시해야 합니다.

  • 사용자 문제에 집착: 최고의 엔지니어는 기술부터 적용처를 찾는 대신, 사용자 문제를 깊이 이해하고 거기서 솔루션을 도출합니다. 근본에 도달할 때까지 "왜"를 질문해야 합니다.
  • 행동 편향을 가지고 출시: 완벽 추구는 마비를 초래합니다. **"먼저 하고, 제대로 하고, 더 잘하는 순서"**로 진행하여 현실과의 접촉에서 완벽한 솔루션을 발견해야 합니다. 추진력이 명확성을 만듭니다.
  • 버그조차 의존성: 충분한 사용자가 있다면 모든 관찰 가능한 동작(버그 포함)이 의존성이 됩니다. 호환성 작업(API 은퇴)은 곧 제품 유지보수이며, 시간과 공감을 들여 마이그레이션으로 설계해야 합니다.

4. 📈 경력 및 조직 운영 (장기적 관점)

경력은 의도적으로 설계해야 하며, 조직 운영의 함정을 경계해야 합니다.

  • 측정 지표의 함정: 측정이 목표가 되면 게임화되어 왜곡됩니다. 선임 엔지니어는 속도 지표와 함께 품질/리스크 지표를 쌍으로 제시하고, 통찰 해석을 주장해야 합니다.
  • 모르는 것을 인정하기: '모르겠습니다'라고 말하는 것은 약함이 아니라 허가를 창출합니다. 리더가 불확실성을 인정해야 팀 전체가 학습하고 문제 회피를 막을 수 있습니다.
  • 시간은 돈보다 가치 있는 자원: 경력이 쌓일수록 시간은 재생 불가능한 자원이 되므로, 무엇을 교환하고 있는지 알고 의도적으로 경력을 설계해야 합니다.
  • 네트워크의 복리: 네트워크는 당신이 가질 모든 직장보다 오래 지속됩니다. 거래적이 아닌 호기심과 관대함으로 관계에 투자하는 것이 장기적인 경력 복리 이자를 만듭니다.

 

 

 

반응형
반응형

[DB] NULLIF 함수 , 주요 사용 사례 (NULLIF + COALESCE)

 

NULLIF의 주된 목적은 데이터를 NULL로 표준화하여 다른 COALESCE나 IS NULL과 같은 함수와 결합해 사용하는 데 있습니다.

SELECT
    ProductName,
    COALESCE(
        NULLIF(ProductName, ''),  -- ProductName이 ''이면 NULL을 반환
        '정보 없음'              -- NULL이 되면 '정보 없음'으로 대체
    ) AS StandardizedName
FROM
    Products;

 

ProductName 컬럼에 NULL 또는 **빈 문자열('')**이 들어있을 때, 이를 '정보 없음'으로 통일하여 표시하고 싶을 때 사용합니다.

 

튜닝 및 조언 💡

  • 가독성: CASE WHEN A = B THEN NULL ELSE A END 구문을 대체하는 간결한 방식으로, 쿼리의 가독성을 크게 높여줍니다.
  • NULL 처리의 표준화: NULLIF는 데이터 정제 및 ETL(Extract, Transform, Load) 프로세스에서 특정 "표준 무효 값" (예: -99, 'N/A', 'NA')을 데이터베이스의 표준 NULL 값으로 변환하는 데 매우 유용합니다.
반응형

+ Recent posts