19 11월 2025

[알아봅시다] 신입 프린시펄 엔지니어를 위한 조언 

[알아봅시다] 신입 프린시펄 엔지니어를 위한 조언 

51P by neo 9일전 | ★ favorite | 댓글 1개
  • Amazon 출신 엔지니어가 Principal(수석) 엔지니어/사이언티스트 역할에 대해 롤모델들로부터 관찰하고 배운 내용을 31가지 조언으로 정리한 글
  • 프린시펄은 사실상 제품·디자인·엔지니어링·문화 전반을 다루는 다역할자로, 판단력으로 폭넓은 업무를 수행함
  • 핵심은 코딩보다 기술 비전, 설계 피드백, 조직 연계이며, 이전 역할에서 핵심이었던 작업은 이제 부차적 업무가 됨
  • 조직이 가치를 두지 않는 것에 가치를 가르치는 일이 큰 부분을 차지하며, 단순히 옳은 판단을 하는 것보다 타인이 공감하고 행동하게 만드는 설득력이 중요함
  • 프린시펄 없이는 일어나지 않을 작업 카테고리에 집중하고, 직접 실행보다 타인을 연결하고 육성하는 것이 더 가치 있을 수 있음
  • 자율성과 책임이 함께 오며, 조직이 집중해야 할 문제를 스스로 찾아야 하고, 필수 경로에서 벗어나 인접한 위치로 전환해야 장기적으로 효과적

1-3. 역할의 본질과 스타일

  • 1번: 프린시펄마다 서로 다른 스타일 존재
    • 한 분야 깊이 파고드는 타입 vs 수평적 영향력 뛰어난 타입
    • 기술적 선구자 vs 복잡성 명료화 타입 vs 여러 조직을 공통 비전으로 정렬하는 타입
    • 자신의 강점에 맞는 스타일을 찾아야 하며, 어떤 스타일도 다른 것보다 더 중요하지 않음

    Amazon은 프린시펄이 hands-on으로 일하기(직접 참여)를 명시적으로 요구하며, 장기간 hands-on이 아닌 경우 실패 가능성이 높음

  • 2번: 이전 역할에서 핵심이었던 작업이 이제는 부차적 업무
    • 직접 코드 작성이 시간의 최선 활용이 아닐 수 있으나, 작업과의 연결 유지를 위해 여전히 코딩 필요
    • 핵심 역할은 기술 비전, 설계 피드백, 후원, 비즈니스·제품·기술 컨텍스트 제공, 새로운 문제 발견, 연결 등

    L7+ 역할의 잘 알려진 이야기: 80% 시간을 코딩에 쓰더라도, 가장 임팩트 있는 부분은 모든 사람을 더 효과적으로 만드는 것
    단일 프로젝트 코딩 집중에서 모든 빌더가 더 잘 빌드하도록 영향력 미치는 것으로 마인드셋 전환
    고품질 코드를 리포지토리에 기여하고 코드가 스스로 말하게 하는 것뿐만 아니라, 설계 제안 피드백, 기술 가이드 작성, 장기 비전 주도 등 다른 노력들이 더 효과적일 수 있음

  • 3번: 기술을 위한 파트타임 PM, 실제로는 모든 것에 대한 파트타이머
    • 제품, 디자인, 엔지니어링, 과학, QA, 채용, 재무, 문화 등 모든 영역
    • “당신의 일이 아닌 것은 없음”
    • 높은 판단력으로 전문 영역 밖으로 나갈 수 있음

4-7. 커뮤니케이션과 영향력

  • 4번: 당신의 역할은 더 많은 커뮤니케이션, 영향력, 적절한 사람을 연결하는 것을 포함
    • 프로젝트는 일반적으로 범위가 크고, 디렉터와 VP를 넘나드는 팀들 포함
    • 효과적인 정렬과 협업 없이는 성공 불가능
    • 조직도를 고객에게 전달하지 않도록 주의 필요
  • 5번: 옳은 것만으로는 절반도 안 됨
    • 다른 사람에게 옳다는 것을 설득하고, 더 중요하게는 행동하도록 충분히 신경 쓰게 만들어야 함
    • 모멘텀 구축 방법, 후원자 찾기, 완수 방법 파악 필요

    때로는 프로젝트를 시작하고 가치를 보여줘야 이를 얻을 수 있음
    프린시펄은 모범을 보여야 하며, 사람들이 위원회를 기다리지 않고 문제 해결에 적극적이길 원함
    “프린시펄이 바로 위원회인데, 누구를 기다리나요 :)”

  • 6번: 조직이 가치를 두지 않는 것에 가치를 가르치는 것이 업무의 큰 부분
    • 청중은 임원부터 실무 IC(Individual Contributor)까지 범위에 포함됨
    • 가장 어려운 작업이며 자주 실패하지만, 미래를 보고 더 넓은 시야를 가진 사람으로서 여전히 해야 함
    • 멘토는 10개 문서 제안 중 약 3개가 실행되면 훌륭한 결과로 간주

    일상 팀 레벨 업무를 담당하는 IC와 달리, L7+ 역할은 회사의 더 넓고 장기적인 관점 취할 공간 보유
    임팩트를 더 객관적으로 평가 가능하며, 그 레벨에서 기여하는 것이 가장 가치를 더함

  • 7번: 프린시펄 없이는 일어나지 않을 작업 카테고리가 존재함
    • 일반적으로 자신이 정말 관심 있는 것과 탁월한 것의 교차점에 위치
    • 빠른 프로토타입 구축하고 리더십과 새로운 고객 경험 공유, 조직 간 또는 업계 다른 실무자들과의 다리 구축, 3년 비전 작성 등
    • 이 카테고리 작업에 집중해야 함
    • 경력이 진행되면서 더 깊고 좁아짐

8-11. 타인을 통한 확장

  • 8번: 가장 가치 있는 일은 직접 작업하는 것이 아니라 연결하는 것
    • 작업하려는 팀을 이미 작업한 팀과 연결하여 재사용하거나 학습하게 함
    • 작업 수행 가능하고 그 과정에서 성장할 적합한 사람 식별 포함
  • 9번: 혼자 할 수 있는 것은 한계가 있음
    • 다른 사람을 코칭하고 멘토링하여 더 효과적이도록 하는 데 시간 투자가 조직에 더 유용
    • 매주 몇 시간(오피스 아워 또는 정기 싱크) 할애
    • 육성하고 싶은 1-2명의 IC 식별하고, 어떻게 도울지 목표 설정

    타인을 통한 확장이 핵심: PE(Principal Engineer)의 성공은 조직이 PE와 동일한 결정을 내릴 수 있을 때
    PE는 다른 모호한 문제로 이동하고 올바른 결과를 달성하는 문화 설정

    모두를 돕고 싶지만, 장기적으로 자신의 자리를 대체할 수 있는 사람 구축에 에너지 집중 필요
    그런 능력을 보이는 모든 사람에게 집중된 시간을 투자해야 하며, 그들이 다시 현재는 잠재력이 덜 보이는 다른 사람들을 도울 수 있음

  • 10번: 타인을 작업에 참여시키는 것에서 작업을 그들의 것으로 만드는 것으로 전환
    • 누군가가 자신을 현재 위치에 도달하게 한 작업을 할 기회로 만듦
    • 지원하고 성공을 위한 설정 제공
    • 고객을 위한 중요한 문제와 흥미로운 기회의 끝없는 백로그가 있으므로 걱정 불필요

    주당 1-2시간을 누군가와 보내며 그들이 자신의 통찰력 하에 40시간 작업 달성하도록 확장하는 것이 진정한 프린시펄 스케일

  • 11번: 타인에게 작업을 줄 때, 이제 그것은 그들의 것
    • 컨텍스트와 가이드 제공 가능하지만, 궁극적으로 방향 설정은 그들의 몫
    • 자신이 취하지 않을 접근법을 취하도록 허용 포함
    • 잘못되면 모두 배우고, 잘되면 자신이 배울 수 있음
    • 단, 프로젝트가 역효과를 낼 수 있는 고위험 일방향 문으로 걸어가는 경우 개입 필요

12-15. 회의와 참여 관리

  • 12번: 회의에서 타인을 위한 공간 창출
    • 때로 회의실은 가장 시니어한 사람의 의견이나 결정을 기대, 질문하여 타인을 위한 공간 창출 가능
    • 참여하지 않는 사람이 보이면, 그들의 강점에 맞는 주제로 부드럽게 끌어들임
    • 회의가 논의에 있어야 할 누군가를 잊었다면, 다음 회의에 추가
  • 13번: 항상 가치를 입증할 필요 없음
    • 가장 효과적인 프린시펄들은 회의 내내 침묵하거나 문서 리뷰에서 거의 코멘트를 남기지 않음
    • 팀과 논의가 잘 진행되고 있다면 훌륭함
    • 작업 흐름에서 한 걸음 물러나 다른 곳에 에너지 집중 가능

    주의: 참석하고 침묵하면 암묵적 승인의 의미, 멀티태스킹과 참석의 의미 주의

  • 14번: 임원과의 회의에서 안건의 모든 주제를 다룰 필요 없음
    • 임원들이 주제에 몰입하고, 의미 있는 질문하고, 그들만이 할 수 있는 결정을 내리거나 장애물 제거하면 좋은 회의
  • 15번: 폭넓은 역할에서 일하면 전체 주간이 들어오는 모든 것으로 가득 찰 수 있음
    • 리뷰, 에스컬레이션, 이메일, 도움 요청 등 포함
    • 조직에 오래 머물수록 더 큰 문제가 될 수 있으며, 많이 알거나 신뢰를 얻어 “go-to” 사람이 됨
    • 결과적으로 모든 회의의 “필수” 참석자가 됨
    • 시간을 지키는 법을 배우지 않으면 정말 관심 있는 아이디어를 추진할 시간이 없음
    • 모든 회의에 있거나 모든 아이디어에 의견을 가질 필요 없음, 중요한 것만

    멘토가 공유한 것: 생각할 시간은 꼭 필요함, 회의에서 회의로 가면 처리하고 앞을 볼 수 없음
    다음 큰 것을 찾기 위해 질 높은 사고 시간 스케줄하고 회의에서 연결 해제 필요

    위임할 방법을 찾아야 함: 다른 사람을 그 사람으로 설정하여 시간 확보, 자신을 자유롭게 하는 이점뿐만 아니라 새로운 사람이 성장하도록 돕는 범위 마련

16-19. 임팩트와 커뮤니케이션

  • 16번: 작업 중인 것에 프린시펄이 왜 필요한지 설명 못하면 잘못된 것에 작업 중일 수 있음 (L6에도 적용 가능)
  • 17번: 지위로 인해 때로는 상대적으로 적은 노력으로 결과 개선 가능
    • 타이틀은 조직적 특권을 부여하며, 관계와 컨텍스트에 대한 더 큰 접근 제공
    • 경험과 결합하여 모퉁이를 더 잘 볼 수 있음
    • 따라서 상당히 적은 노력 투자로 프로젝트의 성공 가능성과 결과를 의미 있게 개선 가능
    • 높은 ROI이며, 이런 기회를 발견하면 행동
  • 18번: 타이틀은 가지지 말아야 할 때도 신뢰성의 아우라 제공
    • 때로 사람들은 자신의 즉흥적 코멘트를 과도하게 해석, 특히 잘 모르는 경우
    • 결과적으로 자신이 한 캐주얼한 코멘트 때문에 많은 작업 수행 가능
    • 시간과 노력 낭비 가능
    • 따라서 아는 것, 모르는 것, 요청하는 것, 단순히 코멘트하는 것을 명확히 해야 함
  • 19번: “무엇”만 말하지 말고, “왜” 그렇게 생각하는지도 공유
    • 다른 사람이 더 나은 결정을 내리도록 도움
    • 다른 사람들이 “프린시펄 <이름>이 이렇게 말했으므로 우리는…”이라고 말하며 완전히 이해하지 못하고 따라하는 것을 줄임

    L7 입력이 필요한 문제는 보통 상당한 불확실성 하의 결정 포함
    중요하지만 어려운 것: 정신 모델 명확히 표현하기 – 모든 정보 없이 판단에 도달하는 방법, 왜 특정 지식이 다른 데이터 포인트보다 중요한지

20-24. 조직과의 연결 유지

  • 20번: 팀과 연결을 유지할 메커니즘 찾기
    • 설계 리뷰, 주간 데모, 근처에 앉아 듣기, 팀 점심, 캐주얼한 복도 대화 등
    • 조직의 맥박을 유지하고 주요 문제나 기회가 어디에 있는지 파악하는 데 도움
  • 21번: 팀이 더 큰 그림을 계속 보도록 도움
    • 실무 레벨이 일의 두꺼운 부분과 일상 전달에 집중할 때, 때로 더 크고 장기적인 문제/기회를 놓치고 지역 최적에 갇힐 수 있음
    • 보유한 컨텍스트로 팀에게 이를 상기시키는 데 도움 가능
  • 22번: 실용적이어야 함; 큰 그림 보기와 지역 솔루션 수용 균형
    • 세부 사항에 대해 실무 레벨과 상담하고 경청, 그들이 현장 전문가
  • 23번: 한두 시간만 함께한 사람에 대한 리뷰나 승진 피드백 요청받을 수 있음
    • 전체 행동의 작은 샘플에 기반한 낮은 품질 피드백 제공하는 대신 거절 가능
  • 24번: 인턴과 멘토와 상호작용할 시간 만들기
    • 인턴십 동안 몇 번의 접점이 혁신적일 수 있음
    • 초기 체크인(필요시 방향 수정), 데모 데이 참석 포함
    • 멘토, 인턴과 함께 인턴십 이후에도 계속 가치 있는 결과물 향해 작업
    • 제품 1-페이저, 작동하는 소프트웨어, 기술 문서 포함

25-28. 프린시펄로서의 전환과 책임

  • 25번: 프린시펄에 도달하려면 필수 경로에 자신을 놓아야 함. 프린시펄로서 효과적이고 그 이상으로 가려면 적극적으로 자신을 제거해야 함
    • 이전에는 “go-to” 사람이었지만, 필수에서 인접으로 전환 필요
    • 조직은 점점 더 자신으로부터 혜택을 받아야 하지만, 효과적이기 위해 의존해서는 안 됨
    • 자신이 만드는 기여를 다른 사람이 할 수 있도록 권한 부여 방법 생각

    필수 경로 프로젝트에 자신을 주입하는 것 주의: 집중이 다른 우선순위에 의해 빼앗기기 쉬우므로, 필수 경로에서 벗어나거나 필수 경로에 있다면 정말 엄격하게 고정 필요

  • 26번: 프린시펄로 승진했다면 이미 한동안 프린시펄로 행동해왔기 때문
    • 일반적으로 1년 이상
    • 따라서 타이틀의 증가된 기대에 대해 걱정 불필요
    • 하던 것을 계속하고, 다른 프린시펄들과 교류하고, 스타일 파악하고, 리더십과 협력하여 집중 영역 식별
  • 27번: 큰 자유에는 큰 책임이 따름
    • 작업할 것을 선택하는 자율성이 있지만, 책임과 임팩트에 대한 기대 존재
    • 자유는 원하는 것을 하는 것이 아니라, 해결할 가장 높은 레버리지 문제를 찾는 소유권에 관한 것
    • 무엇을 하라고 들을 것으로 기대하거나 어떤 가이드를 받을 것으로 기대하지 말 것
    • 조직이 집중해야 할 것을 파악할 것으로 기대됨
  • 28번: 리더십과 헌장 정의 및 정렬
    • 한 가지 방법: 작업을 세 버킷으로 분할 – (i) 소유자, (ii) 후원자, (iii) 컨설턴트
    • 컨설턴트: 리뷰에 참여하고 가이드 제공, 시스템이나 제품 의도에 대한 높은 수준 이해
    • 후원자: 위 내용 외에도 아이디어를 조직의 우선순위로 만들고, 정렬 구축과 결정 주도를 위해 작업하며, 이해관계자와 교류
    • 소유자: 위 모든 것 외에도 시스템 전문가이자 첫 번째 연락 지점이며, 설계, 실행, 임팩트의 성공에 대한 거의 집착 수준 보유
    • 본인은 보통 1-2개 프로젝트 소유(>50% 시간), 2-3개 프로젝트 후원(~20% 시간), 나머지 시간 컨설팅

29-31. 개인 성장과 지속가능성

  • 29번: 프린시펄이 되는 것은 외로울 수 있음
    • 모든 팀의 일부이지만 또한 어느 팀의 일부도 아님
    • 열린 대화를 나눌 수 있는 동료 네트워크 구축
    • 같은 회사나 도메인에서 일하는지는 중요하지 않을 가능성
  • 30번: 자신의 필요를 무시하지 말 것
    • 학습, 성장, 웰빙을 지원하는 프로젝트를 위한 시간과 공간 만들기
    • 단기적으로는 이기적으로 느껴질 수 있지만, 조직에서 번아웃되는 것보다 훨씬 선호됨
    • 자신을 건강하고 행복하고 성장하게 유지하는 작업을 적극적으로 찾으면 조직도 혜택을 받으며, 조직이 자신을 유지하기 더 쉬움
    • 매니저와 협력하여 균형 방법 파악
  • 31번: 계속 학습할 것; 업계는 빠르게 움직임
    • 아무것도 가르쳐주지 않거나 최소한 작업과 관련 없는 것을 가르치는 프로젝트를 맡으면 뒤로 가는 것
    • 때로는 불가피하며, 그런 프로젝트가 오면 타임박스 설정
    • 학습이 직무에서만 올 필요 없음
    • 논문과 기술 교과서를 읽고, 주말에 프로토타입을 해킹하여 새로운 아이디어와 기술을 더 잘 이해하는 시간을 찾는 PE들 존재

기타 리소스

참고: Amazon/Google의 Principal Tech IC는 “관리직에 준하는 전략적 역할을 하는 최고 기술 리더” 라는 점에서 한국에서의 “수석 엔지니어” 보다는 더 상위 개념임

[출처] https://news.hada.io/topic?id=24268&utm_source=weekly&utm_medium=email&utm_campaign=202546

Loading

7 11월 2025

[인공지능 기술]  스타트업에게 좋은 소식: 기업들은 AI를 제대로 구현하지 못하고 있다

[인공지능 기술]  스타트업에게 좋은 소식: 기업들은 AI를 제대로 구현하지 못하고 있다

  • MIT의 연구 조사결과 기업 AI 프로젝트가 95% 실패율을 보인다고 하지만, 실제로는 대기업이 AI를 자체 구축하지 못하는 구조적 문제를 드러낸 것
  • 대기업들은 내부 IT팀이나 컨설팅 회사를 통해 AI 시스템을 구축하려 하지만, 제품 개발 역량 부족과 정치적 장벽으로 대부분 실패
  • 외부 스타트업 벤더를 선택한 프로젝트의 성공률이 자체 개발보다 훨씬 높았으며, 기업들은 이제 스타트업의 솔루션에 의존할 수밖에 없는 상황
  • 대기업 엔지니어링 팀 내부에 AI 회의론자들이 다수 포진해 있어 실제 작동하는 제품을 만들 수 없으며, 이것이 스타트업에게 전례 없는 기회를 제공
  • AI 네이티브 시스템 구축과 전환 비용으로 인한 높은 진입장벽이 형성되어, 제대로 작동하는 솔루션을 만들 수 있는 스타트업에게 유리한 환경 조성

MIT 연구 보고서의 실제 내용

  • AI 인플루언서들이 퍼뜨린 왜곡된 해석: X와 YouTube에서 “95% AI 프로젝트 실패율”을 “AI는 사기다” 라는 증거로 제시
  • 실제 연구 내용은 기업의 AI 도입 방식과 성공 요인에 대한 분석이며, AI 에이전트의 실제 작동 방식과 효과적인 접근법을 확인
  • 대학생들조차 트윗 버전만 읽고 “YC가 말하는 AI 스타트업들이 작동하지 않는다”고 잘못 결론

기업 AI 도입의 구조적 실패 원인

  • 내부 IT 시스템의 고질적 문제: 대부분의 기업 내부 IT 시스템이 품질이 낮으며, Ernst & Young이나 Deloitte 같은 컨설팅 회사를 고용해도 문제가 두 배로 증가
  • Apple도 소프트웨어 개발에 실패: 무한한 자본과 인재 접근성을 가진 Apple조차 캘린더 앱에서 매일 버그 발생
    • 일반 기업이나 IT 부서가 좋은 소프트웨어를 만들기 어려운 현실을 보여주는 사례
  • 조직 내 정치적 갈등: 대기업에서 정교한 소프트웨어 배포 시 여러 팀이 관여하면서 정치적 싸움과 영역 다툼 발생
    • 컨설턴트들이 데이터 과학팀, 고객지원팀, IT팀 등을 중재하며 요구사항 문서 작성
    • 하지만 컨설턴트들은 실제 소프트웨어 구축 기술 전문성 부족
  • 레거시 시스템의 한계: 기업 내부 시스템이 너무 오래되고 사일로화되어 있어, 외부 컨설팅 전문성과 소프트웨어 구축 역량이 동시에 필요
  • 최종 결과물은 위원회가 디자인한 낙타 같은 형태로, 실용성 없는 타협의 산물

성공적인 스타트업 사례들

  • Tactile (비즈니스 의사결정 엔진)

    • 은행의 KYC/AML 실시간 처리: 대출 신청자의 신용 확인과 비즈니스 규칙 검증을 일일 수백만 건 규모로 처리
    • Citibank와 JP Morgan이 자체 개발 시도했으나 3~5년과 수천만 달러 소요
    • Tactile은 REST API로 실시간 의사결정 제공, 최신 AI 모델 플러그인 가능, 예산의 일부와 훨씬 짧은 시간에 구축
  • Greenlight (은행용 AI 시스템)

    • 한 은행이 기존 벤더 Ernst & Young에게 AI 시스템 구축 요청
    • Ernst & Young이 1년간 개발했으나 완전히 실패
    • 은행이 다시 Greenlight에 접촉해 현재 완전히 배포되어 작동 중
  • 연구 결과: 외부 벤더 vs 내부 개발

    • 조사된 프로젝트 중 2/3가 자체 개발 또는 컨설팅 회사 협력
    • 1/3만이 Greenlight나 Tactile 같은 외부 벤더 제품 구매
    • 외부 벤더 선택 시 성공률이 자체 개발보다 훨씬 높음

스타트업이 성공하는 이유

  • 폴리매스(polymath) 부족 문제: 제품과 엔지니어링 모두에 능숙한 인재가 극히 드묾
    • 뛰어난 엔지니어들이 코딩에만 집중하며 은행 직원 같은 도메인 사용자와 소통 불가
    • 도메인 전문가들은 코딩이나 기술, 디자인, 제품 출시 역량 부족
  • Windsurf 사례: 엔지니어링 학위 없는 영업 리더가 Windsurf로 자체 도구 제작
    • IQ 150급 조직에서는 이미 발생 중이지만, 대부분의 조직에서는 아직 불가능
  • 스타트업 형태의 공백: 모든 비즈니스 프로세스와 시스템에 스타트업이 채워야 할 공백 존재
  • 희귀한 역량 조합 필요: 최신 AI 이해도, 제품 감각, 인간적 프로세스 이해를 모두 갖춘 인재
  • Castle AI 사례 (모기지 서버)

    • 레거시 벤더들의 AI 추가 시도: 수십 년 된 시스템 위에 AI를 덧붙이며 경쟁 대응
    • 은행들이 신뢰하는 기존 벤더와 베이크오프(bake-off) 경쟁 필수
    • 많은 경우 벤더 솔루션이 “AI를 그냥 얹은” 수준으로 매우 열악
    • Castle AI는 처음부터 네이티브로 구축된 제품 감각으로 대형 은행 계약 체결
    • 배치 후 1년 만에 성과 달성
  • Reducto 사례 (문서 처리)

    • YC 런치를 통해 FAANG 기업이 직접 발견: 배치 후 154일 만에 FAANG 기업 계약 체결
    • 해당 기업은 수년간 자체 솔루션 구축 시도
      • 오픈소스, AWS Tesseract 등 다양한 OCR 솔루션 시도했으나 실패
    • 제품 우수성(product excellence) 으로 계약 획득
    • 내부팀과 경쟁하며 조직 정치를 섬세하게 탐색해야 했음
      • MIT 보고서에서도 언급된 과제
    • 현재 1~2년 이상 프로덕션 환경에서 운영 중

성공 전략

  • 챔피언 키우기: 똑똑한 젊은이들에게 기회를 주고 싶은 내부 인물 확보
  • 이상적인 기업 내부 챔피언 유형
    • 스타트업 꿈을 가졌지만 위험회피적인 직원: 실제로는 창업하지 않을 사람들
    • 흥미로운 스타트업을 통해 대리만족을 경험하려는 성향
    • 자신이 스타트업 여정에 함께한다고 느끼며 창업자의 성공을 원함
    • 내면의 스타트업 꿈을 키우고 싶어하는 사람들 찾기
  • 창업자가 취할 자세
    • 정장을 입거나 Microsoft 홈페이지를 모방하는 등 형식주의 따르지 말 것
    • 진정성 있게 스타트업답게 행동하는 것이 중요
    • 똑똑하고 현명하게 보이는 것은 중요하지만, 과도한 형식은 불필요

기업의 AI 도입 의지와 스타트업 기회

  • MIT 보고서의 긍정적 핵심 메시지: 기업들의 압도적인 AI 도입 수요
  • 과거 TripleByte 운영 시절보다 FAANG 기업에 AI 에이전트 판매가 훨씬 용이
  • 기업들은 기존 소프트웨어 회사나 후기 단계 스타트업에서 솔루션 구매 선호
    • 더 많은 자금과 덜 위험해 보이는 업체 선호
  • 근본적으로 제품을 만들 수 없는 구조적 문제:
    • 대기업 엔지니어링 팀이 AI를 믿지 않는 사람들로 구성
    • 코드 생성 도구 사용하지 않음
    • MIT 연구가 과대평가라고 말하면 리트윗하며 좋아함
    • 믿고 싶은 내러티브에 집착
  • 엔지니어들이 믿지 않으면 작동하는 제품 구축 불가능
  • 스타트업에게 전례 없는 기회: 작동하는 제품을 만들면 기업들이 대화할 수밖에 없음
    • 내부 구축 불가능, 기존 회사에도 갈 수 없는 상황

AI 회의론자들에게 보내는 메시지

  • 직접 시도해보라

    • 엔지니어라면 실제 프로젝트에 투자해 사용해볼 것
    • 한 번 시도해 변수 이름 오류 났다고 포기하지 말 것
    • 메인 업무가 아닌 재미있는 사이드 프로젝트로도 가능
    • “Vibe Coding Dad’s Night” 사례: 기술적이지 않은 집주인이 세입자 임대료 확인 시스템 제작
    • 10배 엔지니어를 100배로, 1배 엔지니어를 10배로 만드는 도구
    • 내면의 감정을 극복해야 하는 과제
  • Andrej Karpathy 인터뷰 왜곡 사례

    • 트윗: “Karpathy가 에이전트가 과대평가되었다고 말함”
    • 실제 발언: 에이전트에게 프롬프트만 주고 완벽한 결과를 기대할 수 없으며, 올바른 데이터, 컨텍스트, 평가, 도구 작업 필요
    • 실제 의미: 스타트업과 소프트웨어 개발자들에게 엄청난 기회
      • 구축해야 할 훌륭한 도구가 아직 산더미
    • AI는 도구이며 더 잘 작동하도록 도와야 함, 마법처럼 작동하길 기대하면 안 됨

AI 네이티브 시스템 재구축은 기회

  • 모든 시스템을 AI 네이티브로 완전히 재작성 필요
  • 소프트웨어가 AI와 함께 작동하도록 완전히 새로 작성되어야 함
  • 창업자들에게 무한한 기회 제공
  • “일단 시스템 훈련에 시간을 투자하면, 전환 비용이 감당할 수 없을 정도로 높아질 것
  • 이것이 바로 해자(moat): ChatGPT 래퍼가 해자가 없다고 걱정하는 사람들에게 명확한 답

결론: 스타트업의 기회

  • AI 비관론자들의 잘못된 해석: 95% 실패율을 AI 불가능의 증거로 왜곡
  • 실제 메시지: AI 구현이 매우 어려우며 5%만 성공
  • 하지만 YC 합격률은 1% 미만: 그 1%의 창업자들이 성공하는 상위 1% 구현 사례 창출
  • 성공 요인: 뛰어난 기술력 + 폴리매스적 역량 + 타인에 대한 이해
    • 50억 달러 핀테크 CIO가 진정으로 원하는 것을 이해
  • 5%에 포함될 수 있다는 자신감: 실제로 뛰어나다면 절대 가능하며, YC에 수많은 사례가 존재함

[출처] https://news.hada.io/topic?id=24197

Loading

2 11월 2025

[인공지능 기술] 텐서플로우(TensorFlow)에서 파이토치(PyTorch)로 환승하기

[인공지능 기술] 텐서플로우(TensorFlow)에서 파이토치(PyTorch)로 환승하기

*해당 포스팅은 이 원문을 번역, 정리(요약)한 것입니다.

텐서플로우가 파이토치보다 1년 먼저 나왔지만, 최근 많은 개발자들이 텐서플로우에서 파이토치로 넘어가고 있는 실정이다.

이번 아티클에서는 텐서플로우에서 파이토치로 넘어가는 방법에 대해 이야기하려고 한다. 

먼저 각 딥러닝 프레임워크를 사용하는 이유에 대해 살펴본 후, 간단한 예제를 통해 파이토치와 가까워지는 시간을 가져보려 한다.

1. 프레임워크 개요

1.1. 텐서플로우

2015년 구글에서 발표한 딥러닝 프레임워크. 텐서플로우 2.0로 업데이트되면서 케라스(keras)와 통합되었다.

1.2. 파이토치

2016년 페이스북에서 발표한 딥러닝 프레임워크. 파이썬 언어와 자연스럽게 어우러진다는 장점이 있다.

파이토치를 텐서 단위의 딥러닝 모델을 GPU 위에서 계산할 수 있는 플랫폼으로 이해할 수 있다.

동적인(dynamic) 그래프를 생성하고, 그때그때(on the fly) 모델의 동작 원리를 살펴볼 수 있다.

2. 왜 텐서플로우에서 파이토치로?

– 파이토치와 다르게 텐서플로우는 정적인(static) 그래프를 생성한다.

– 파이토치는 특정 그래프 작업에 맞춰 모델을 정의하고 조작할 수 있다. (RNN처럼 입력 길이가 가변적인 상황에서 유용)

– 파이토치는 근본적으로 파이썬을 기반으로 개발되었기 때문에 좀더 직관적이다.

– 텐서플로우가 익히기 좀더 까다로운 편. 

– 신속하게 프로토타입을 개발하고 연구하는 데 파이토치가 가장 적합하다.

3. 텐서플로우에서 파이토치로 넘어가기

GPU 환경에서 두 프레임워크를 설치하는 과정은 생략하겠습니다.

텐서플로우에서 파이토치로 넘어가는 건 그렇게 복잡한 편이 아니다.

파이토치는 문제를 해결하는 데 있어 파이써닉한 접근방식을 취하기 때문이다.

3.1. 텐서 다루기

각 프레임워크에서 임의의 텐서를 초기화해보자. 방법은 크게 다르지 않다.

텐서플로우

import tensorflow as tf

rank2_tensor = tf.constant([[1, 2],
                            [3, 4],
                            [5, 6]], dtype=tf.int32)

파이토치

import torch

rank2_tensor = torch.tensor([[1, 2],
                             [3, 4],
                             [5, 6]], dtype=torch.int32)

간단한 텐서 연산을 수행해보자.

텐서플로우

a = tf.constant([[1, 2],
                 [3, 4]])
b = tf.constant([[1, 1],
                 [1, 1]])
                 
a = tf.Variable(a)
b = tf.Variable(b)

print(tf.add(a, b), "n")
print(tf.multiply(a, b), "n")
print(tf.matmul(a, b), "n")

파이토치

a = torch.tensor([1, 2, 3], dtype=torch.float)
b = torch.tensor([7, 8, 9], dtype=torch.float)

print(torch.add(a, b))
print(torch.subtract(b, a))
print(a.mul(b))
print(a.dot(b))

3.2. 작동 메카니즘

딥러닝 프레임워크는 연산 그래프를 활용한다. 연산 그래프는 최선의 결과를 얻기 위해 연산이 이루어져야 하는 순서를 정의한다.

딥러닝 모델을 계산하기 위해 크게 두 개의 인터프리터가 사용되는데,

하나는 프로그래밍 언어에 이용되고(대부분의 경우 파이썬) 나머지 하나는 연산 그래프를 뜻대로 조작하는 데 사용된다.

따라서 연산 그래프를 세팅할 때는 파이썬 같은 프로그래밍 언어를 통해, 실행 메카니즘은 다른 언어를 통해 이루어지게 된다.

애초에 효율성 및 최적화 문제 때문에 이런 이상한(?) 세팅이 구성됐다고 볼 수 있다.

텐서플로우의 경우 정적인 연산 그래프를 활용한다. 전형적인 “Define and Run” 방식으로 작동한다. 처음에 모든 변수들을 생성, 연결한 다음, 이들을 정적인 세션에 초기화하게 된다.

하지만 이렇게 정적인 그래프에 변수 파라미터를 정의하는 방식이 비효율적이라고 여겨지기도 한다. 특히 RNN 형식의 모델을 쓰는 경우에 그렇다.

Define-and-Run : 연산 그래프를 먼저 정의한 후에 데이터를 흘려보내 결과를 얻는 방식

정적인 텐서플로우 그래프를 살펴보자.

import tensorflow as tf

a = tf.Variable(15)
b = tf.Variable(5)

prod = tf.multiply(a, b)
sum = tf.add(a, b)

result = prod/sum
print(result)

파이토치의 경우, 동적인 그래프를 활용하기 때문에 코드를 입력할 때 연산 그래프가 설계된다.

유저가 변수를 처음 선언할 때 연산 그래프가 바로 만들어지고, 각 훈련 iteration 마다 연산 그래프가 다시 만들어진다.

정적인 그래프보다 동적인 그래프를 선호하는 이유는, 다른 요소는 건드리지 않고 필요한 요소들만 수정할 수 있기 때문이다.

이러한 방법의 단점을 꼽자면 그래프를 재설계 하는 데 종종 시간이 좀더 걸린다는 점이다.

아래 움짤은 파이토치 작동 방식을 보여준다.

3.3. 반복 훈련(training loops)에서의 비교

텐서플로우에서 훈련 루프를 만드는 과정은 다소 복잡하고 직관과는 거리가 멀다.

보통은 tf.function을 데코레이터로 써서 정적 그래프 관점에서 모델을 컴파일 한다. 

일반적으로 텐서플로우는 즉시 실행(eager execution)을 활용한다. 이는 디버깅에는 용이하지만 빠른 실행에는 불리하다.

따라서 tf.function을 활용해서 전역적인(global) 퍼포먼스 최적화를 적용한다.

즉시 실행 (Eager execution) : 그래프 생성 없이 연산을 즉시 실행하는 명령형 프로그래밍 환경

그 다음 학습 과정을 정의할 때는 Gradient Tape 기능을 통해 자동 미분(automatic differentiation)을 수행한다.

그래디언트 값이 적용되고, 역전파 과정이 이루어질 때, 최종적으로 훈련 파라미터가 업데이트 된다.

모델의 훈련을 끝내고 나면 원했던 값들을 리턴 받을 수 있다.

@tf.function
def train_step(x, y):
     with tf.GradientTape() as tape:
          logits = model(x, training=True)
          loss_value = loss_fn(y, logits)
     grads = tape.gradient(loss_value, model.trainable_weights)
     optimizer.apply_gradients(zip(grads, model.trainable_weights))
     train_acc_metric.update_state(y, logits)
     return loss_value

파이토치에서 학습 루프를 정의하는 건 보다 간단하고 직관적이다. 변수를 생성하고 동적 그래프를 그때그때 정의하면서 모델을 학습할 수 있다. 데이터와 타겟을 디바이스(CPU/GPU)에 할당하고 순전파를 연산한다.

모델이 순전파(feed-forward) 연산을 마치고 나면, pytorch의 사전 정의된 개체들을 통해 역전파 과정을 수행할 수 있다. 그래디언트를 계산하고, 역전파 방법론을 적용함으로써 파라미터를 업데이트 한다.

for epoch in range(epochs):
     for batch, (data, target) in enumerate(train_loader):
          # cuda 파라미터 가져오기
          data = data.to(device=device)
          target = target.to(device=device)
          # 순전파
          score = model(data)
          loss = criterion(score, target)
          # 역전파
          optimizer.zero_grad()
          loss.backward()
          optimizer.step()

4. MNIST로 파이토치 이해하기

필요한 라이브러리를 불러온다

import torch
import torchvision
import torch.nn as nn
import torch.nn.functional as F
from torch.utils.data import DataLoader

import numpy as np
import matplotlib.pyplot as plt

디바이스 파라미터를 설정한다. 

device = torch.device('cuda' if torch.cuda.is_available() else cpu)

하이퍼파라미터를 세팅한다.

num_classes = 10
input_size = 784
batch_size = 64
lr = 0.0001
epochs = 3

텐서플로우처럼 파이토치도 MNIST 등 기본 데이터셋을 불러올 수 있다.

T = torchvision.transform.Compose([torchvision.transforms.ToTensor()])

X_train = torchvision.datasets.MNIST(root='/datasets', \
                                     train=True, \
                                     download=True, \
                                     transform=T)
train_loader = DataLoader(dataset=X_train, batch_size=batch_size, shuffle=True)

X_test = torchvision.datasets.MNIST(root='/datasets', \
                                     train=False, \
                                     download=True, \
                                     transform=T)
test_loader = DataLoader(dataset=X_test, batch_size=batch_size, shuffle=True)

“Linear” function 으로 정의되는 fully connected layer 를 선언할 것이다.

텐서플로우였다면 Dense function을 사용했을 거라는 점을 기억하자.

class neural_network(nn.Module):
     def __init__(self, input_size, num_classes):
          super(neural_network, self).__init__()
          self.fc1 = nn.Linear(in_features=input_size, out_features=50)
          self.fc2 = nn.Linear(in_features=50, out_features_num_classes)
          
     def forward(self, x):
          x = self.fc1(x)
          x = F.relu(x)
          x = self.fc2(x)
          return x

이제 loss 와 옵티마이저를 선택해보자.

학습에 있어서는, 순전파를 수행한 다음 최적의 가중치를 학습하기 위해 역전파를 적용할 것이다.

# 손실함수와 옵티마이저
criterion = nn.CrossEntropyLoss()
optimizer = torch.optim.Adam(model.parameters(), lr=lr)

# 훈련
for epoch in range(epochs):
     for batch, (data, target) in enumerate(train_loader):
          data = data.to(device=device)
          target = target.to(device=device)
          
          data = data.reshape(data.shape[0], -1)
          
          # 순전파
          score = model(data)
          loss = criterion(score, target)
          
          # 역전파
          optimizer.zero_grad()
          loss.backward()
          optimizer.step()

모델을 평가해보자.

def check_accuracy(loader, model):
    num_correct = 0
    num_samples = 0
    model.eval()

    with torch.no_grad():
        for x, y in loader:
            x = x.to(device=device)
            y = y.to(device=device)
            x = x.reshape(x.shape[0], -1)

            scores = model(x)
            _, predictions = scores.max(1)
            num_correct += (predictions == y).sum()
            num_samples += predictions.size(0)

        if num_samples == 60000:
            print(f"Train accuracy = {float(num_correct) / float(num_samples) * 100:.2f}")
        else:
            print(f"Test accuracy = {float(num_correct) / float(num_samples) * 100:.2f}")

    model.train()
    
check_accuracy(train_loader, model)
check_accuracy(test_loader, model)

5. 꼭 파이토치여야 할까?

5.1. 파이토치의 장점

1. 본질적으로 파이써닉하다

파이토치로 된 코드는 파이써닉하다. 즉, 절차적인 코딩 방식이(procedural coding) 파이썬 요소와 유사하다.

텐서플로우로 작업할 때는 코드가 다소 low-level에 있어 이해하기가 어렵다.

(이런 이유로 keras 같은 high-level API가 텐서플로우 2.0으로 통합되고 있다.)

파이토치의 기능들은 Numpy, Scipy, Cpython과 같은 다른 라이브러리와 함께 적용하기 좋다.

또 파이토치의 문법이나 응용 방식이 정통 파이썬 프로그래밍 방식과 매우 유사하기 때문에 학습 난이도가 낮다.

2. 문서화가 잘 되어 있고 커뮤니티가 잘 형성되어 있다

3. 동적 그래프

메모리를 미리 지정하기 어려울 때 동적으로 생성된 그래프를 유용하게 쓸 수 있다.

4. 많은 개발자들이 프로젝트에 파이토치를 활용하고 있다

5.2. 파이토치의 단점

1. 시각화 기술이 부족하다

텐서플로우의 경우 텐서보드(Tensorboard)라는 시각화 툴킷을 통해 학습 및 검증 정확도 및 loss, 모델 그래프, 히스토그램, 이미지 등 다양한 요소를 모니터링 할 수 있다. 파이토치에 Tensorboard를 활용하는 것도 방법이다.

2. 배포를 위해서는 API 서버가 요구된다

텐서플로우의 장점 중 하나가 프로덕션 툴이 다양하다는 것이다. production-ready 상태로 빌드되기 때문에 텐서플로우의 확장성이 크다.

inference나 학습된 모델 주기(lifetimes) 등을 다룰 수 있다.

오늘은 텐서플로우와 파이토치를 비교하며 대략적으로 파이토치가 어떤 프레임워크인지 살펴보았다.

다음 글에서는 파이토치의 모델 정의, 학습, 추론에 대해 자세하게 살펴보겠다.

[출처] https://woo-niverse.tistory.com/246

Loading

26 10월 2025

[기술 에세이] [기술 블로그] 개발은 나이와 함께 익어간다 

[기술 에세이] [기술 블로그] 개발은 나이와 함께 익어간다 

72P by xguru 11일전 | ★ favorite | 댓글 15개

아마존 CTO Werner Vogels 박사의 글

  • 이런 속삭임을 들었음. “이제 그도 나이가 들었는데, 누가 후임이 될까?”
    • 사람들이 진지하게 물음. “은퇴는 언제 하실 건가요?”
    • Amazon에서 거의 25년을 보냈고, 매년이 다르고 놀라웠던 시간들이었지만, 그는 여전히 학계를 떠나 Amazon에 합류하기로 했던 그날만큼 젊은 마음을 가지고 있음
  • 나이가 들어가는 개발자로서 좋은 점은, 이미 많은 문제를 직접 경험해봤다는 것
    • 젊은 개발자들이 오늘 마주하는 어려움들을 이전에도 겪었고, 비록 지금은 겉모습이 조금 달라 보일지라도 본질은 같음
    • 수많은 프로젝트를 거치며 실전 경험을 쌓았고, 실패도 셀 수 없이 많았음
    • 이제 머릿속 절반은 무엇이 현실적으로 작동하는지를 알고 있고, 그중 일부는 위험 신호를 감지하는 감각으로 훈련되어 있음
  • 남은 공간은 창의성을 위한 자리
    • 다양한 신호를 받아들이고, 정신적 모델을 세우며, 새롭고 독창적인 해결책을 찾는 일
    • 이것이야말로 개발자로서의 가장 큰 즐거움
    • 매일 무언가 새로운 것을 만들 수 있는 직업이 얼마나 될까?
    • 나는 이 사실을 결코 당연하게 여기지 않음
  • 나이 든 개발자로서, 당신은 이미 패턴이 반복되는 세상을 여러 번 보았음
    • 세상을 바꿀 것처럼 떠들던 회사들이 결국은 구멍 난 치즈 같은 결과를 내놓는 모습을 수없이 봄
  • 그리고 AI의 시대가 도래했음
    • 지난 15~20년 동안 우리가 사용해온 NLP, 음성인식, 번역, 이미지 인식, 추천 시스템, 사기 탐지 등과 같은 AI가 아님
      • Amazon.com을 지탱해온 기반 기술들이지만, 지금 이야기하는 것은 생성형 AI
      • 나이 든 개발자인 나에게도 이건 정말 흥미로운 변화로 느껴짐
    • 실험 속도가 엄청나게 빨라졌기 때문
      • 건강한 회의감(scepticism)을 가진 숙련된 빌더의 손에 들어가면, 이것은 매우 강력한 도구가 됨
      • 하지만 동시에 도전적이기도 함
      • 다른 기술들처럼 출시 전 교육이나 준비 기간이 없었기 때문
      • 마치 마법이 병에서 갑자기 튀어나오듯 세상에 퍼졌고, 모두가 예상치 못한 탓에 과열된 기대가 폭발함
    • 이 상황은 낯설게 느껴졌음
      • 왜냐하면 지금까지의 소프트웨어는 1년에 한 번 나오는 마이너 버전 업그레이드를 통해 진화했기 때문
      • Windows 3가 3.1이 되기까지 2년이 걸렸고, Mac OS X도 2001년부터 2019년까지 소수점 버전만 업데이트하다가 최근에야 매년 주요 버전이 바뀌기 시작했음
      • 그런데 지금은 매주 모델이 교체되고, 새로운 버전이 나올 때마다 리더보드 순위가 바뀌는 세상이 되었음
  • AWS는 언제나 B2B 기업이었음
    • 우리는 고객들이 자신의 고객을 위해 혁신할 수 있도록 기술의 빌딩 블록(S3, EC2, DynamoDB, Lambda, DSQL 등) 을 제공해왔음
    • 그런데 이 AI 열풍 속에서 갑자기 B2C 기업들과 비교되기 시작했음. 솔직히 답답했음
  • 하지만 경험은 방향을 알려줌
    • 우리는 본질로 돌아갔음
    • 기술(이번에는 모델)에 대한 접근을 대중화하고, 고객 선택권을 보장하며, 프라이버시와 보안을 최우선으로 두었음
    • 또한 안전과 컴플라이언스를 위한 가드레일을 제공하고, 자동 추론(automated reasoning) 을 통해 모델 오류 가능성을 줄였음
    • 이것이 수십 년 동안 반복되는 패턴 속에서 배운 교훈임
      — 무엇이 진짜로 작동하는지를 알고 있다는 것
  • 노련한 개발자는 매주 쏟아지는 새로운 모델 발표와 기능 추가 소식에도 조급해하지 않음
    • 이런 일은 수없이 봤음 = 새로운 기술, 같은 패턴
  • 지난 수십 년 동안 나이든 개발자는 아마 열 개가 넘는 프로그래밍 언어를 배우고, 수많은 오픈소스 라이브러리와 플랫폼을 경험했을 것임
    • 언제나 기술 트렌드를 관찰하고, 논문을 읽고, 새로운 방향을 공부하는 일을 즐겼음
    • 그것이 개발자의 재미였기 때문
    • 그래서 그의 회사가 생성형 AI에 적합한 문제를 다룰 준비가 되었을 때, 그는 이미 준비되어 있었음
    • 또한 Marc Brooker의 훌륭한 글 “LLM-driven development”를 읽었고, 그 조언을 따를 계획임
  • 내가 만나는 거의 모든 고객은 이렇게 물어봄 : “우리는 생성형 AI로 뭘 해야 할까요?”
    • 이 질문에 대한 최고의 답변은 우리의 똑똑한 과학자 Byron Cook의 말임 : “질문에 즉시 답변하지 못해 죄송한데, 왜 이런 질문을 하셨을까요?”
    • 고객의 90%는 생성형 AI가 자사 문제를 해결할 거라 믿어서 묻는 게 아니라, 단지 뒤처질까 봐 불안해서 묻는 것임
      • FOMO(Fear of Missing Out) 때문임
  • 그리고 노련한 개발자는 이럴 때 멈출 줄 앎. 잠시 멈춰서, 신중하게 생각함
    • 그는 젊은 개발자들에게 장단점을 공부하라고 격려하고, 경영진에게는 Jeff Lawson의 《Ask Your Developer》 같은 책을 읽으라고 권함
  • 그 다음엔, 늘 그래왔듯이 고객과 깊이 대화함
    • 그들의 도전 과제를 듣고, 문제를 탐색하고, 아키텍처와 마이그레이션, 도구를 제안함
    • 그리고 때로는 그 해답이 생성형 AI일 수도 있음
  • 하지만 나이 든 개발자로서, 당신은 이미 알고 있음

자, 이제, 만들어보세요!(Now, Go build!)

[출처] https://news.hada.io/topic?id=23667

Loading

12 10월 2025

▲ “튜토리얼 지옥”을 대체한 “바이브 코딩 지옥”의 등장

13P by GN⁺ 16시간전 | ★ favorite | 댓글 2개
  • 최근 코딩 교육 환경에서 “튜토리얼 지옥” 대신 “바이브 코딩 지옥” 이 새로운 문제로 대두됨
  • 튜토리얼 지옥이 “튜토리얼 없이는 아무것도 만들지 못하는” 상태였다면, 바이브 코딩 지옥은 “AI 없이는 코딩할 수 없고, AI가 생성한 코드가 어떻게 작동하는지 이해하지 못하는” 상태를 의미
  • AI 도구의 과도한 사용이 학습 동기를 저하시키며, AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 역설적 상황이 발생하고 있음
  • AI 도구는 적절하게 활용하면 학습 보조에 큰 도움이 될 수 있으나, 무작정 ‘답만 얻기’식 사용은 건설적 이해 형성에 방해가 됨
  • 학습 과정에서 직접 고민하고 스스로 해결하려는 노력이 핵심, 튜토리얼·AI 보조 없이 문제 해결 경험을 쌓는 자세가 중요함

문제의 배경: 튜토리얼 지옥에서 바이브 코딩 지옥으로

  • 2019년 당시 코딩 교육의 주요 문제는 “튜토리얼 지옥” 이었음
    • 튜토리얼을 따라하는 데는 성공하지만 혼자서는 아무것도 만들지 못함
    • 실제 프로그래밍보다 프로그래밍 관련 동영상 시청에 더 많은 시간을 소비하며, 핵심 개념은 이해하지 못함
    • 결과적으로 피상적 지식만 쌓고, 내부 작동 원리는 이해하지 못해서 현실에서는 코드를 스스로 쓰지 못하는 상태
  • Boot.dev는 이를 해결하기 위해 세 가지에 집중함
    • 심층 커리큘럼: 전통 대학 외부에서도 CS 기초를 배울 필요성 강조
    • 실습 중심 방식: 모든 개념 학습과 함께 코드를 직접 작성
    • 비디오보다 리치 텍스트 강화: 비디오는 수동적 소비에 그칠 위험성 있음
  • 2019년에는 수백만 조회수를 기록하던 긴 YouTube 강의들이 현재는 5만 조회수도 달성하기 어려움
    • FreeCodeCamp, Traversy Media, Web Dev Simplified 등의 채널이 이러한 추세를 보임
  • 그러나 “learn to code”에 대한 Google Trends 데이터는 여전히 높은 관심도를 유지하고 있음
  • Boot.dev에 매일 약 1,300명의 신규 사용자가 등록하며, 최근 18개월간 튜토리얼 지옥에 대한 불만은 줄었지만 새로운 형태의 어려움이 나타남

바이브 코딩 지옥의 정의

  • 튜토리얼 지옥의 특징
    • “튜토리얼 없이는 아무것도 만들 수 없다”
    • “문서를 이해하지 못하니 동영상이 필요하다”
    • “간단한 작업에도 복잡한 프레임워크가 필요하다”
  • 바이브 코딩 지옥의 특징
    • “Cursor의 도움 없이는 아무것도 할 수 없다”
    • “멋진 타워 디펜스 게임을 만들었어요. 여기 링크에요 http://localhost:3000″;
    • “이미지 lazy-load를 위해 Claude가 6,379줄을 추가한 이유를 모르겠어요”
  • 현재 자기주도 학습자들은 많은 것을 만들고 있지만, 소프트웨어 작동 방식에 대한 멘탈 모델을 발전시키지 못하는 프로젝트를 구축
  • AI의 환각(hallucination)과 싸우고, 테스트 통과에만 집중하는 봇과 씨름하며 실제 문제 해결보다는 AI가 생성한 코드를 맹목적으로 신뢰

AI 코딩의 미래와 현실

  • 나는 단기적으로 AI가 개발자를 완전히 대체하지는 않을 것이라는 데 긍정적 입장
    • “AI가 일자리를 빼앗을 때까지 6개월”이라는 말이 나온 지 3년이 지났지만 여전히 개발자를 고용하고 있음
  • GPT-5가 출시되었지만 GPT-4 대비 점진적 개선에 그쳤으며, AGI가 곧 도래하지 않을 것임을 보여주는 증거로 해석됨
  • 매일 AI 도구를 사용하지만 실제로 생산성이 얼마나 향상되는지 확신하지 못함
    • AI가 더 생산적이게 만드는지, 아니면 더 게으르게 만드는지 불분명
  • 2025년 연구 결과: 개발자들은 AI가 20-25% 생산성을 높인다고 가정했지만, 실제로는 19% 느려짐
    • 7조 달러 투자 대비 실망스러운 결과

AI와 학습동기 저하의 위험성

  • AI 활용 문화가 학습자의 동기 부여에 부정적일 수 있음
  • AI 열풍(버블?)에서 가장 우려되는 점은 “왜 배워야 하나? AI가 다 알잖아”라는 태도를 가진 세대가 등장한다는 것
  • AI가 실제로 모든 화이트칼라 직업을 대체하지 못한다면, 주식 시장 버블뿐 아니라 교육받은 인력의 가뭄도 겪게 될 것
  • 기술적 배경이 없는 투자자들은 “AI가 이미 코딩의 전부를 대체했다”고 오해하고, 시니어 개발자들은 여전히 AI 도구를 일상 업무에 통합할 유용한 방법을 찾지 못함
  • AI 리터러시가 낮은 사람일수록 AI를 더 많이 사용하는 경향이 있어 우려됨
    • 궁극적인 ‘Dunning-Kruger(더닝-크루거)’ 함정으로 작용 – 지식이 부족한 사람이 오히려 자신이 잘 안다고 착각하는 현상
    • 학습자들이 “AI가 이미 알고 있으니” 자기계발이 무의미하다고 결론 내림

AI는 학습에 유익한가?

  • 여전히 코딩 배우기에 대한 사회적 관심도 높음
  • AI가 학습에 유익할 수도 있지만, 두 가지 구조적 문제가 존재함
  • 첫 번째: 아첨(sycophant) 문제

    • AI 챗봇은 질문자 의견에 과도하게 동조하는 경향이 있음
    • “ROAS(광고수익률)에 대해” 채팅해보면, 같은 데이터를 놓고 질문 방향에 따라 정반대 결론을 내며, 모두 전문가적 어조로 확신 있게 답함
    • 이는 학습자에게 검증, 비판적 사고, 오류 지적을 경험할 기회를 박탈함
      • 전문가에게 묻는 이유는 우리가 틀렸을 때 알려주기 위함
      • IRC 채팅이나 Stack Overflow는 이를 잘 수행했음(아마도 너무 잘)
      • LLM(대형언어모델) 챗봇은 기존 학습자의 근본적 오해를 바로잡지 못하는 경향이 강함
      • 현재 학생들은 LLM과 편안한 대화를 나누며 필요한 것이 아닌 듣고 싶은 것을 듣게 됨
  • 두 번째 문제: 학습자는 실질적 ‘의견’을 원함

    • AI는 지나치게 균형 잡힌 입장을 제시함
      • “어떤 사람들은 X라고 생각하고 어떤 사람들은 Y라고 생각한다”
      • 학습자가 어느 쪽에 동의할지 결정하기 더 어려워짐
    • “자본주의자 역할” 또는 “마르크스주의 혁명가 역할”을 하도록 프롬프트했지만 만족스러운 결과를 얻지 못함
    • 학습자는 실제 경험에서 나온 의견과 논평을 듣고 싶어함
      • DHH가 Turbo에서 TypeScript를 제거한 이유
      • Anders Hejlsberg가 TypeScript가 JavaScript 개발자에게 해결해주는 것
      • 각 저자의 편견과 맥락이 명확히 드러나는 실제 의견을 통해 미묘한 멘탈 모델이 형성됨
    • LLM 특유의 중립적·조심스러운 답변은 실제 지식 내면화에 방해가 됨

AI가 학습에 진짜 도움 되는 경우

  • AI는 올바르게 사용하면 학습을 위한 놀라운 도구
  • 코딩을 배우기에 이보다 쉬운 시대는 없었음
  • Boot.dev의 Boots(AI 교육 보조 도구) 사례
    • 학생들이 인스트럭터 솔루션(이상적인 정답)을 보는 것보다 AI 튜터(Boots)와 채팅하는 것을 거의 4배 더 많이 사용
    • Boots는 일반 챗봇과 달리 다음 방식으로 학습에 도움 줌
      • 답을 직접 알려주지 않도록 사전 프롬프팅
      • 소크라테스식 방법을 사용하여 학생이 문제에 대해 더 깊이 생각하도록 유도
      • 강사의 솔루션에 접근할 수 있어 정답에 대한 환각 가능성이 훨씬 낮음
      • 즐거운 캐릭터성 부여(마법사 곰)

바이브 코딩 지옥 탈출법

  • 결론적으로, 튜토리얼 지옥이든 바이브 지옥이든, ‘남에게 맡기지 말고 스스로 해보는 경험’ 이 매우 중요함
    • 튜토리얼 지옥: 비디오 끄고 직접 코드 작성 경험 쌓기
    • 바이브 지옥: 코파일럿 등 AI 자동완성 꺼두고, 스스로 문제 해결 경험 쌓기
  • 피해야 할 것:
    • 에디터 내 AI 자동완성
    • 에이전트 모드 및 AI 자동화 도구로 프로젝트 처리
  • 활용할 수 있는 것:
    • 질문에 답하고, 개념을 설명하고, 예제를 제공하는 챗봇
    • 소크라테스식 방법으로 질문하도록 유도하는 시스템 프롬프트를 통해 깊은 사고 촉진
    • 주장을 할 때 출처를 인용하고 문서에 링크하도록 요청하는 시스템 프롬프트로 정보 신뢰성 확보

핵심 원칙

  • 학습은 반드시 불편해야 함
    • 튜토리얼 지옥은 다른 사람이 코딩하는 것을 보면서 불편함을 피할 수 있게 해줌
    • 바이브 코딩 지옥은 AI가 코드를 작성하게 하면서 불편함을 피할 수 있게 해줌
  • 진짜 학습은 막히고, 좌절하고, 가장 중요하게는 문제 해결을 강제당할 때 일어남
    • 이것이 인간의 신경망이 재배선되는 방식
  • “학습은 어려워야 한다”는 개념을 지나치게 확대하면 형편없는 교육 설계의 변명이 될 수 있음
    • 저자는 이를 옹호하지 않음
    • 개념이 최선의 방식으로 설명되더라도, 학생은 여전히 그것과 씨름하고 새로운 맥락에서 스스로 사용해야 진정으로 이해할 수 있음
  • 진짜 학습 은 직접 막히고, 좌절하고, 자신의 힘으로 돌파하는 과정에서 완성됨

[출처] https://news.hada.io/topic?id=23590

Loading

9 10월 2025

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

[一日30分 인생승리의 학습법] ▲ 2025년 가장 인기 있는 프로그래밍 언어 (spectrum.ieee.org)

  • Python > Java > C++ > SQL > C# > JavaScript > TypeScript > C > Shell > Go > R > PHP > Kotlin > Rust > Dart > Swift
  • IEEE Spectrum 조사 결과 Python이 올해도 1위를 차지, JavaScript는 3위에서 6위로 떨어짐
  • 이 변화는 웹 개발에 많이 쓰이는 JavaScript가 AI 기반 코딩(예: vibe coding)으로 대체되는 흐름과 연관된 것으로 분석됨
  • 전통적으로 사용되던 Stack Exchange 질문 수, GitHub 활동 같은 지표는 AI 도입 이후 급감하여, 언어 인기 측정의 기존 방법이 흔들리는 상황
  • AI 코드 생성이 보편화되면서 언어의 문법·구조 차이 중요성이 줄고, 특정 언어에 집착하지 않는 흐름이 뚜렷해짐
  • 이는 새로운 언어 등장과 생태계 확산을 막고, 결국 프로그래밍 언어 인기도의 개념 자체가 사라질 가능성을 보여줌

개요

  • IEEE Spectrum이 2025년 주요 프로그래밍 언어와 트렌드를 종합적으로 분석한 결과를 발표
  • 이 순위는 취업 시장, 오픈소스 생태계, 학계 및 업계 활용도 등 다양한 관점을 반영
  • 주요 언어별 특징, 성장 배경, 그리고 기술 분야별로 특화된 언어에 대한 정보도 함께 제공

올해의 언어 순위

  • 2025년 Spectrum 기본 순위에서 Python이 1위 유지, JavaScript는 6위로 하락함
  • Jobs 순위에서도 Python이 1위로 올라섰고, SQL은 여전히 채용 시장에서 강력한 경쟁력을 보유함
  • 전체 언어 관련 Stack Exchange 질문 수는 2024년 대비 22% 수준으로 감소했음

순위 산정 기준

  • 인기도: 다양한 온라인 포럼, 소프트웨어 저장소, 구인 구직 데이터, 검색 트렌드 등을 활용해 산정함
  • 현업 활용도: 기업 채용 공고와 오픈소스 프로젝트 참여도를 기준으로 실제 시장에서 많이 쓰이는 언어를 분석함
  • 분야별 분석: AI, 임베디드, 웹, 모바일 등 기술 세부 분야에서 두드러진 언어 선정 기준을 반영함
  • 인기도 측정을 위해 Google 검색량, Stack Exchange 질문, GitHub 활동, 논문 언급 등 다양한 지표를 활용했음
  • 하지만 개발자들이 LLM(ChatGPT, Claude 등)과의 대화로 문제를 해결하면서 공개된 데이터 신호가 줄어듦
  • AI 도구(Cursor 등) 덕분에 질문 자체가 줄어 기존 지표의 유효성이 약화됨

AI와 언어의 경계 희미화

  • 숙련된 개발자부터 초보자까지 AI에 의존하면서 언어의 문법, 제어 구조에 대한 신경이 줄어듦
  • AI는 충분한 학습 데이터만 있으면 어떤 언어로도 코드 생성이 가능함
  • 이에 따라 언어 선택은 하드웨어의 CPU 명령어 차이처럼 부차적인 요소로 전락할 수 있음
  • 향후 언어 인기도 논쟁은 철도 궤간 비교 수준의 비주류 화제로 밀려날 수 있음

새로운 언어의 등장이 더욱 어려워 질 것

  • 과거에는 책, 데모, 샘플 코드만으로도 언어 생태계가 퍼질 수 있었음 (예: The C Programming Language)
  • 그러나 AI는 대량의 학습 데이터를 요구하기 때문에 신생 언어는 지원이 불리함
  • 실제로 덜 사용되는 언어에서 AI가 더 나쁜 결과를 내는 현상이 보고됨
  • 이는 새로운 언어가 임계 질량을 확보하기 어려운 환경을 만들 수 있음

프로그래밍의 미래

  • 현대 언어는 본질적으로 데이터 처리 추상화와 개발자 오류 방지 두 가지 역할을 수행함
  • 그러나 AI 발전은 언어 구조보다 프롬프트 → 중간 언어 → 실행이라는 새로운 흐름을 가능케 함
  • 이 경우 소스 코드를 유지·수정하기보다 프롬프트를 조정해 재생성하는 방식이 자리잡을 수 있음
  • 미래 프로그래머의 역할은 언어 문법보다는 아키텍처 설계, 알고리듬 선택, 시스템 통합 능력에 집중될 전망임

결론과 전망

  • 프로그래밍은 1950년대 컴파일러 등장 이후 최대 변혁기를 맞이하고 있음
  • AI 거품이 일부 꺼지더라도 코드 작성을 돕는 LLM 활용은 지속될 가능성이 높음
  • 따라서 2026년 이후에는 “인기 언어”라는 개념 자체가 의미를 잃을 수 있으며, 인기도를 측정하는 새로운 지표가 필요함

[출처] https://news.hada.io/topic?id=23330

Loading

26 8월 2025

[一日30分 인생승리의 학습법] 유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

[一日30分 인생승리의 학습법] 유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

유능한 리더들은 어떤 능력으로 불확실성을 헤쳐나가는가

67.유능한-리더들이-불확실성을-어떻게-헤쳐나가는가.png

복잡하고 어려운 상황을 유연하게 헤쳐 나갈 줄 아는 리더들은 무엇을 알고, 어떻게 다르게 행동할까? 그런 능력이 있는 리더를 본다면 어떤 모습이 보일까?

이 질문은 Innovation Tactics 카드 덱의 저자 톰과 존이 최근 대화에서 던진 화두다. 보통 이런 역량들은 ‘소프트 스킬’이나 ‘문화 적합도’ 같은 포괄적인 개념으로 치부되곤 한다.

그런데 만약 이 능력들을 명확하게 정의한다면 어떨까?

우리는 먼저 “무엇이 보일까?”라는 질문으로 일반적인 행동들을 묘사했고, 이어서 ‘~할 수 있는 능력’(the ability to…)이라는 형식으로 정의를 작성했다. 설명은 되도록 전문 용어 없이 쉽게 풀어쓰려 노력했다.

또한, 이러한 능력을 가진 사람을 채용하거나, 회사에서 그런 능력을 요구하는 면접을 준비할 때 참고할 수 있도록 인터뷰용 샘플 질문도 포함했다.

참고로 여기서 ‘역량(capabilities)’이라는 단어를 쓴 이유는, 개인이 자신의 환경을 만드는 면도 있지만, 많은 능력은 단순 개인이 아니라 여러 사람의 집단에서 나타나는 특성이나 행동, 능력으로 이해해야 하기 때문이다.

우리가 문제의 일부임을 인정하기 (Accept We Are Part of the Problem)

자신이 현재 상황을 만들거나 악화시키는 데 어떤 역할을 했는지 인지하고 받아들이는 능력.

인터뷰 질문: 문제에 자신이 일조했다는 걸 깨달았던 구체적인 경험을 알려주세요. 그 깨달음에 도달한 과정과 그 후에 행동이 어떻게 달라졌는지 말씀해 주세요.

새로운 상호작용 방식을 장려하기 (Encourage New Interaction Patterns)

개인을 바꾸거나 제거하는 데만 집중하지 말고, 환경 속에서 새로운 소통과 협력의 방식을 촉진하는 능력. 사람들이 서로 관계를 맺고 새로운 정보와 경험에 접할 수 있도록 돕는 역할을 말한다.

인터뷰 질문: 사람들이 새로운 방식으로 소통하거나 정보를 공유하도록 이끈 경험이나, 사람들이 전에 접하지 못한 새로운 정보나 경험을 접하게 한 사례를 이야기해 주세요. 변화의 필요성을 느끼게 된 계기와 그 결과도 함께 알려주세요.

인내하며 다양성을 존중하기 (Patient Divergence)

해답이나 앞으로 나아갈 길을 서두르지 않고 생산적인 다양성을 장려하는 능력. 창의적 탐색을 위한 환경을 조성하고 여러 가지 ‘실마리’를 따라가면서도 강제로 일치시키지 않고 자연스럽게 조율이 일어나도록 하는 것이다.

인터뷰 질문: 복잡한 문제를 다루면서 팀이 서두르지 않고 해결책을 찾아갈 수 있도록 이끈 경험이 있나요? 그 과정을 어떻게 관리했고, 결국 어느 지점에서 방향을 정하게 되었나요?

가능한 요인 다각도로 파악하기 (Identify Plausible Contributors / Multiple “Causes”)

문제에 기여할 법한 여러 요인을 파악하고, 서로 상충하는 듯해도 모두 염두에 두는 능력. 단일 원인만을 찾으려는 충동을 억제하는 것도 포함된다.

인터뷰 질문: 여러 복합적인 원인이 얽힌 문제를 경험한 적 있나요? 그 문제를 어떻게 다루었고, 다음 행동을 어떻게 결정했나요?

현재의 힘 (Power of the Present)

이상적이고 미래지향적인 ‘목표 상태’나 ‘격차’를 개선의 유일한 길로 보기보다는, 지금 이 순간과 현재 상황 속에 잠재된 가능성을 활용하는 능력. 지금 여기에서 출발해, 현재 작동하고 있는 것들을 찾아내고 인접한 여러 선택지를 탐색하는 것에 초점을 맞춘다.  문제가 있거나 힘든 부분에만 집중하는 대신, 현재 잘 작동하는 점들을 찾아 배우고 증폭시켜 장애물을 극복한다.

인터뷰 질문: 리더로서 우리는 종종 두 극단 사이에서 고민한다. 한쪽은 우리가 도달하고자 하는 뚜렷한 비전을 향해 큰 도약을 추진하는 것이고, 다른 쪽은 바로 지금 있는 곳에서 시작해 잘 돌아가는 부분을 파악하고 작은 변화를 꾸준히 시도하는 것이다. 이런 긴장을 탐색해야 했던 상황이 있나요? 그때 어떻게 대처했는지 설명해 주세요.

다양한 관점 융합하기 (Blend Diverse Perspectives)

특히 자신의 신념이나 기본값에 도전하는 다양한 관점을 찾아내고 수용하는 능력. ‘가장 많이 아는 사람이 되는 것’을 추구하는 태도를 경계하며, 모든 상황에서 가장 틀린 사람은 자신이 가장 전체적인 시각을 가지고 있다고 믿는 사람임을 인지한다. 대신 여러 관점의 융합을 다수 가능성의 원천으로 보아, 다양한 경로가 나타날 수 있게 한다.

인터뷰 질문: 다양한 관점, 특히 당신이 도전적으로 느꼈던 시각들까지 포용할 필요가 있었던 경험을 이야기해 주세요. 그 경험이 공동의 결정과 이후 행동에 어떤 영향을 미쳤나요?

인내심과 회복 탄력성 (Patience and Self-Repair)

반복적으로 개입하기보다, 특정 상황이 자연스럽게 진행되고 시간이 지나면서 스스로 해결되도록 인내하며 지켜보는 능력.

인터뷰 질문: 어떤 상황에서 개입하지 않고 스스로 해결되도록 둔 경험이 있나요? 그런 결정을 내리게 된 이유와 그 결과는 어땠는지 이야기해 주세요.

영향 예측 (Anticipate Effects)

새롭게 나타나는 행동이나 결과, 그리고 그로 인한 여러 차례의 예상치 못한 파급 효과들을 예견하는 능력(반드시 예측하는 것은 아님). 예상치 못한 결과가 예외가 아니라 규칙임을 받아들이고 끊임없이 상황 신호를 살피는 자세가 필요하다.

인터뷰 질문: 어려운 결정을 내릴 때 예상치 못한 부작용을 미리 점검해야 했던 경험이 있나요? 어떤 점을 특히 주의 깊게 봤나요?

호기심과 가벼운 접근 (Curiosity and Light Touch)

판단하거나 즉시 행동하려는 충동을 억제하고, 마음속에 떠오르는 생각과 감정을 여유롭게 탐색할 공간을 만드는 자세로, 호기심 어린 마음가짐으로 상황에 접근하는 능력.

인터뷰 질문: 즉각적인 판단을 내리려다 스스로 멈추고 호기심을 선택했던 순간을 이야기해 주세요. 그 마음가짐의 변화는 어떻게 일어났나요?

양쪽 모두 인정하기 (Both/And)

서로 반대되는 힘이나 생각들이 상호 의존적임을 인식하고 존중하는 능력. 많은 상황이 어느 하나를 선택하는 ‘양자택일’이 아니라, 겉으로는 모순되는 요소들이 공존하는 ‘양자 모두’를 잘 조율해 나가는 과정임을 이해하는 것이다. 복잡한 문제를 단순한 선택지로 줄여서 해결하려 하지 않는다.

인터뷰 질문: 표면적으로는 단순한 선택 문제처럼 보였던, 양자택일 상황에 직면했지만 실제로는 ‘둘 다’인 상황을 경험한 적 있나요? 그때 어떻게 상황을 해결했나요?

안전하게 개입하기 (Intervene Safely)

부작용이나 해를 최소화하면서 동시에 긍정적인 행동이나 신호, 패턴이 나타나도록 개입하는 능력. 부정적 영향이 나타나면 빠르게 완화하고, 긍정적 효과가 생기면 증폭하고 지속시키는 것이다. 이 기술을 갈고닦아도 항상 성공하거나 옳은 판단만 하는 것은 아니지만, 발전시키면 도움이 된다.

인터뷰 질문: 팀과 함께 새로운 일하는 방식이나 상호작용, 행동 방식을 시도해 본 적 있나요? 무엇을 시도할지 어떻게 결정했고, 계속 강화할지 아니면 바꿀지 어떻게 판단했나요?

직관과 추론의 균형 맞추기 (Abduction and Intuition)

한정된 데이터 안에서 논리적 추론과 직관적 추론(가설추론)을 조화롭게 활용하는 능력. 논리적이고 명확한 결론에만 갇히지 않고, 복잡하고 불명확한 패턴 속에서 직관적으로 도약하는 인간 고유의 능력을 발휘하는 것이다.

인터뷰 질문: 논리와 직관을 함께 활용해야 했던 경험을 이야기해 주세요. 과정과 결과는 어땠나요? 그 과정에서 다른 사람들은 어떻게 참여했나요? 그 과정에서 데이터는 어떻게 활용되었나요, 또는 활용되지 않았나요?

다양한 강점과 역량 수용하기 (Accept Diverse Strengths and Skills)

우리가 개인적으로 갖지 않았거나 중요하게 여기지 않는 강점과 관점을 인정하고 존중하는 능력. 스킬과 영향력을 인지하는 데 있어 전지전능하지 않다는 점을 이해하며, 무심코 개인이나 팀의 중요한 부분을 저평가할 위험이 있음을 인지하는 것이다.

인터뷰 질문: 잘 알지 못하는 강점이나 역량을 평가해야 했던 경험이 있나요? 그 역량이 당신의 가치관과 달라 평가절하될 위험이 있을 때 어떻게 접근했나요?

협력적으로 상황을 파악하고 환경을 만들어 가기 (Collaboratively Sense and Shape)

문제를 단순화하거나(“그냥 ~하면 된다”) 상황 해석을 독점하거나 통제하려는 충동을 억제하며, 다른 사람들과 함께 문제를 이해하고 상황을 개선할 방향을 만들기 위해 협력하는 능력.

인터뷰 질문: 다른 사람들과 함께 문제의 의미를 파악하고, 그들과 협력해 환경을 조성하여 실제 변화를 이끌어낸 경험에 대해 이야기해 주세요.

일치가 아닌 일관성 추구하기 (Coherence vs. Alignment)

모든 세부 사항의 완전한 일치를 강요하기보다는, 경계를 설정하고 ‘넘지 말아야 할 선’은 지키면서도 그 안에서 사람들 스스로 다양한 방향을 폭넓게 탐색하도록 권장하는 능력. 강요된 일치는 취약하다는 점을 인정하고, 일반적으로 일관성 있는 행동이 더 탄탄하고 지속 가능함을 이해한다.

인터뷰 질문: 사람들을 행동하게 해야 하는 상황에서 모두가 세세한 부분까지 완벽히 일치하도록 강요하지 않고도 일을 진행한 경험이 있나요? 이상적인 최종 상태를 정의하지 않고 대략적인 일관된 방향을 어떻게 정했나요?

씨앗을 심고 성장시키기 (Plant Seeds—Help Them Grow)

산출물을 미리 계획하고 완성하는 구조적인 결과물이 아니라, 심고 자라며 진화하는 유기체처럼 바라보는 능력. 범위를 엄격하게 잡기보다는 가볍게 두고, 시간을 엄격한 제한조건이 아닌 가능성을 열어주는 제약으로 활용한다.

인터뷰 질문: 요구사항의 확실성과 타임박스 및 일정 활용을 적절히 조화시키고, 예상치 못한 새로운 가치가 등장할 가능성을 열어 두는 당신의 방식을 보여주는 사례가 있나요?

업무 방식 맞춤 조정하기 (Tailor Ways of Working)

과제의 성격과 상황에 맞게 업무 방식을 조정하는 능력. 상황에 따라 다음 방식을 조합해 활용한다:

  • 단순하게 바로 실행하기
  • 체계적이고 큰 계획 세우기
  • 특정 결과를 목표로 실험하기
  • 비교적 느슨하고 다양한 실험으로 새로운 가능성 관찰하기

 …인간이 관여할 때는 후자의 방법을 선호하는 경향이 있다는 점을 이해한다.

인터뷰 질문: 과제의 특성에 따라 본인과 팀의 업무 방식을 어떻게 달리 적용했는지 대비되는 사례를 공유해 주세요. 계획 수립과 실행 접근 방식을 어떻게 바꾸었나요?

불확실성에 맞서기 (Facing Uncertainty)

A) 상황에서 가장 불확실한 부분으로 적극 다가가되, B) 익숙하고 잘 알고 있는 부분에서 ‘빠른 성과(quick win)’를 얻는 것 사이에서 균형을 맞추는 능력. 불확실성을 난관이 아니라 기회의 신호로 보고, 복잡한 도전을 환영하는 문화를 만드는 것이다 (단순화하려 하지 않고).

인터뷰 질문: 빠른 성과와 주요 불확실성 영역 해결 사이에서 균형을 맞춰야 했던 경험을 이야기해 주세요. 어떤 방식으로 접근했고, 팀에 어떤 지원을 했으며 학습과 성장을 어떻게 이끌었나요?

참고 사항

  1. 실제 면접에서 이 질문들을 사용하기 전에는 반드시 내부적으로 이 역량들에 대해 논의하고 스스로 답변을 준비해 보시길 권합니다. 회사에서 이 역량들이 얼마나 중요하게 여겨지고 있는지, 이 역량을 가진 사람들이 잘 성장하는지 아니면 어려움을 겪는지, 회사 문화가 이런 역량이 발현되는 방식을 어떻게 형성하는지, 그리고 이 역량들을 어떤 단어로 표현하는지 등을 점검해 보십시오.
  2. 이 글에는 아마도 너무 많은 전문 용어와 이론을 사용했을 겁니다. 죄송합니다. 이해하기 쉬운 언어와 현장에서 실제로 적용할 수 있도록 이 역량들을 효과적으로 전달하는 능력을 키우기 위해 계속 노력하고 있습니다!
  3. 명확한 역량을 정의하는 일은복잡성을 고려할 때는 다소 단순화한 측면이 있을 수 있습니다. 이 역량들은 개인 고유의 것이 아니라 환경과 관계에 깊이 얽혀 있습니다. 커뮤니티 내 깊이 있는 분들이 이에 대해 지적하실 수 있음을 알고 있으며, 피드백을 환영합니다.
  4. 모든 일에 이런 접근법을 다 적용할 수 있는 경우는 매우 드뭅니다. 그렇게 하면 팀이 지칠 수 있기 때문입니다. ‘업무 방식 맞춤 조정하기’ 역량 설명에서도 이 점을 언급했습니다. 본 글에서는 복잡한 문제와 환경에 초점을 맞췄지만, 결과는 항상 다양하게 나타난다는 점을 기억하세요.
  5. 많은 조직들은 복잡성을 직접적으로 언급하거나 전문 용어를 사용하지 않더라도, 복잡성을 효과적으로 다루는 방식을 발전시켜 왔습니다. 위에 나열된 역량들이 여러분이나 회사 내 다른 사람들에게는 익숙하지 않거나 낯설게 들릴 수 있다는 점을 인지하며 이 글을 살펴보시기 바랍니다. “우리 회사는 이런 걸 안 한다”고 결론 내리기 전에, 여러분만의 방식과 맥락 속에서 어떻게 이런 역량을 실현하고 있는지 자문해 보시길 바랍니다.

원문: How Capable Leaders Navigate Uncertainty and Ambiguity

[출처] https://blogbyash.com/translation/how-capable-leaders-navigate/

Loading

6 8월 2025

[알아봅시다] [리버스 프롬프트 엔지니어링] Reverse Prompt Engineering

[알아봅시다] [리버스 프롬프트 엔지니어링] Reverse Prompt Engineering

Reverse Prompt Engineering

 
 
 
 

????리버스 프롬프트 엔제니어링 패턴(In English)

1.Can we talk about Reverse Prompt Engineering? By Reverse Prompt Engineering I mean creating a prompt from a given text.

2.Nice. Can you give me a simple example of Reverse Prompt Engineering?

3.Good. Write a short expaination on how dog training works, and Reverse Prompt Engineer the explaination.

4.Great. Can you create a very technical reverse prompt engineering template?

5-1.Reverse Prompt Engineeing the following {text}, capture the TONE and WRITING STYLE of the {text} to include in the prompt:
text = “이 부분에다가 실제 텍스트 내용(오바마 연설, 세익스피어 문구 등의 스타일로)을 넣는다.”

 

5-2-1.Can you reverse engineer the following {product describtion}, capture the writing style an dthe length fo the text:

product describtion= “이 부분에다가 실제 제품 내용(아이폰 제원 등)을 넣는다.”

5-2-2.Rewrite the reverse prompt into a prompt that can be used for any product describtion with a user input feature in the prompt that uses {}:

 

5-3. Reverse engineer the following {html-code} in to a prompt:

html-code=“이 부분에다가 코드(html코드) 넣는다.”

 
 

????방법(In Korean)

 

1.리버스 프롬프터 엔지니어링에 대해 얘기할 수 있을까요? Reverse Prompt Engineering은 주어진 텍스트에서 프롬프트를 생성하는 것을 의미합니다. 

 
 
 
 

2.좋아요. 리버스 프롬프트 엔지니어링의 간단한 예를 들어주시겠어요? 

 
 
 
 

3.좋아요. 강아지 훈련이 어떻게 작동하는지에 대한 간단한 설명을 쓰고, 설명을 리버스 프롬프트 엔지니어인 나에게 작성해주세요. 

 
 
 
 

4.내가 ‘강아지 훈련은, 강아지가 원하는 행동을 보이면 보상을 주어서 그 행동을 강화하고, 원치 않는 행동을 보이면 그 행동에 대해 무시하거나, 보상을 주지 않음으로써 그 행동을 감소시키는 방법입니다. 예를 들어, 강아지가 기본적인 훈련인 “앉아”를 배우기 위해서는, 강아지가 앉아앉은 행동을 보이면 간식이나 칭찬 등의 보상을 주어서 그 행동을 강화하게 됩니다.’와 같은 답을 듣기 위해서는 어떤 프롬프트를 작성해야 되요? 

 
 
 
 

5.내가 당신에게 사용할 수 있는 리버스 프롬프트 엔지니어링 탬플릿을 프롬프트 형태로 제공해 줄 수 있나요? 

 
 
 
 

6.연설문이나 시를 작성하기 위한 리버스 엔지니어링 템플릿을 프롬프트 형태로 제공해 줄 수 있나요? 

 
 
 
 

7.한국어로는 없나요?

 
 
 
 

8.혹시, {text}를 변수로 사용하는 리버스 엔지니어링 프롬프트 템플릿을 제공해 줄 수 있나요? 

 
 
 
 

9.한국어로 제공 부탁해요.

 
 
 
 

10.{text}의 시를 작성하기 위한 프롬프트를 제공해주세요.

text=죽는 날까지 하늘을 우러러

한 점 부끄럼이 없기를,

잎새에 이는 바람에도 

나는 괴로워했다.

별을 노래하는 마음으로 

모든 죽어가는 것을 사랑해야지

그리고 나한테 주어진 길을 

걸어가야겠다.

오늘 밤에도 별이 바람에 스치운다. 

 
 
 
 

11.{text}의 시는 윤동주님의 ‘서시’라는 제목의 시에요. 알고 있나요? 

 
 
 
 

12.{text}와 같은 운율, 어조, 억양을 고려하여 ‘청소년들이 겪는 아픔’에 대한 시로 재창작 부탁해요. 

 
 
 
 

13.{text}와 같은 운율, 어조, 억양을 고려하여 ‘청소년들이 겪는 아픔‘에 대한 시 작성하기

text=죽는 날까지 하늘을 우러러

한 점 부끄럼이 없기를,

잎새에 이는 바람에도 

나는 괴로워했다.

별을 노래하는 마음으로 

모든 죽어가는 것을 사랑해야지

그리고 나한테 주어진 길을 

걸어가야겠다.

오늘 밤에도 별이 바람에 스치운다. 

 
 
 
 

14.재창작하여 작성해주세요. 

 
 
 
 

여기 까지가 리버스 프롬프트 엔지니어링(Reverse Prompt Engineering) 한국어 루틴입니다. 리버스 프롬프트 엔지니어링은 프롬프트 엔지니어가 원하는 답을 하기 위한 질문을 찾는 과정이라 생각하면 됩니다. 아래는 리버스 프롬프트 엔지니어링을 GPT에게 이해시키고 시를 다작한 사례입니다. 

 
 

[출처] https://www.learnmore.co.kr/education/ai-literacy/open-ai/prompt-example/reverse-prompt-engineering

Loading

12 7월 2025

[인공지능 기술] 예상치 못한 AI의 굴욕

[인공지능 기술] 예상치 못한 AI의 굴욕

예상치 못한 AI의 굴욕

[아무튼, 주말]
[아무튼, 레터]

EZDVHUI2FJASRJ5P3UOXNTKD74.png
 
AI 대전환은 거스를 수 없는 흐름이다. AI 기술을 인간의 판단과 어떻게 균형 있게 조화시킬 것인지에 대한 고민이 필요하다.

영국에서 윔블던 테니스 대회가 열리고 있습니다. 148년 역사의 이 대회는 보수적 운영 방식으로 유명합니다. 선수들은 운동복은 물론 모자, 양말, 팔목 밴드, 라켓 손잡이까지 흰색으로 통일해야 합니다. 다만, 2년 전 여성 선수에 한해 어두운 색 속바지를 허용했습니다. ‘바지 혹은 치마보다 길지 않아야 한다’는 조건이 달렸고요. ‘윔블던다운 미미한 변화’라는 말이 나왔습니다.

그런데 올해 대회는 정말 큰 변화가 생겼습니다. 선심을 없애고 ‘인공지능(AI) 심판’을 도입한 것입니다. 코트 주변 카메라들이 공 궤적을 추적해 ‘아웃’ 여부를 판독합니다. 다른 대회도 AI를 많이 활용하지만 ‘전통’을 중시해온 윔블던이기에 놀라운 결정이라는 반응이 많았습니다.

판정의 정확성을 높이기 위한 것인데, 뜻밖의 논란을 불러일으켰습니다. 6일(현지시각) 러시아와 영국 선수가 맞붙은 여자 단식 16강전. 중계 화면상으론 분명히 영국 선수가 친 공이 라인을 벗어났는데도 ‘아웃’ 판정이 나오지 않았습니다. 판독 시스템이 순간 작동을 멈춘 것입니다. 결국 이 포인트는 무효 처리됐습니다. 러시아 선수가 “점수를 도둑맞았다”고 항의했지만 소용없었습니다. 그는 한번 흔들리자 끌려가기 시작했습니다. 이 경기는 러시아 선수가 간신히 이기기는 했지만 승패가 바뀔 뻔했습니다. AI 심판의 말썽은 이게 끝이 아니었습니다. 8일 열린 남자 단식 8강전에서 유형이 다른 오작동을 일으켰습니다.

이쯤 되면 “AI가 윔블던에서 씻기 힘든 굴욕을 당했다”는 말이 나오는 것도 무리가 아니겠네요. 이번 소동은 스포츠의 경계를 넘어 AI의 존재론적 가치를 둘러싸고 다양한 질문이 쏟아지는 계기가 됐습니다. AI 의존도는 어느 정도의 선이 적절한 것일까. AI의 오류로 생기는 피해는 누가 책임지고 어떻게 구제해야 하는가. AI가 특정 개인이나 집단에 대한 불공정하고 차별적인 결과물을 도출할 우려는 없는 걸까.

AI 대전환은 거스를 수 없는 흐름입니다. AI 주도권을 놓고 글로벌 경쟁이 한창입니다. 하지만 AI의 장밋빛 미래에 매몰된 나머지 AI 기술을 인간의 판단과 어떻게 균형 있게 조화시킬 것인지에 대한 인류의 고민이 부족하지는 않은지 걱정되는 것도 사실입니다. 즐거운 주말 보내십시오.

 
 

[출처] https://www.chosun.com/national/weekend/2025/07/12/QZCAYJPLHZH4FMWVBN36XH5EWY/

Loading

28 5월 2025

[인공지능 기술] Gradio 설치 및 실행 방법

[인공지능 기술] Gradio 설치 및 실행 방법

1. Gradio란 무엇인가?


Gradio는 Python으로 개발된 오픈 소스 패키지이다.
Gradio를 사용하면 몇 줄의 코드로 ML 모델, API 또는 임의의 Python 함수에 대해 사용하기 쉽고 커스터마이징할 수 있는 UI 구성 요소를 빠르게 생성할 수 있다.
Gradio GUI를 Jupyter 노트북에 직접 통합하거나 링크로 다른 사람과 공유할 수도 있다.

00 image.png 

2. Gradio 설치


Gradio를 설치하는 방법은 다음과 같다.
터미널에서 다음 명령을 실행하거나 Google Colab에서 실행할 수 있다.

pip install gradio

 Jupyter Notebook을 사용하는 경우에는 다음과 같이 입력한다.

!pip install gradio

 

3. Gradio 애플리케이션을 실행하는 방법


Gradio 애플리케이션을 실행하는 방법을 알아보자.
다음은 사용자의 이름을 입력받아 인사 메시지를 생성하는 간단한 Python 애플리케이션이다.

#!pip install gradio
import gradio as gr

def user_greeting(name):
    return "안녕하세요! " + name + "님, 첫 번째 Gradio 애플리케이션에 오신 것을 환영합니다!????"

app = gr.Interface(fn=user_greeting, inputs="text", outputs="text")
app.launch()

???? 에러 메시지 발생 (ModuleNotFoundError: No module named 'tqdm')

  • 내가 코드를 실행 했을 때는 위와 같은 에러 메시지가 발생 했는데, 에러 메시지에 따르면 gradio 모듈을 찾을 수 없고, gradio 모듈의 일부 파일에서 tqdm 모듈을 찾을 수 없다고 한다.

???? 해결 방법

  • gradio와 tqdm 모듈의 호환성 문제가 있을 수 있기 때문에 gradio와 tqdm 모듈을 최신 버전으로 업데이트 하였다.
    pip install -U gradio
    pip install -U tqdm
    • Gradio 애플리케이션이 실행되었다.

 

명령 프롬프트에서 Gradio 응용 프로그램 실행

Gradio 애플리케이션을 명령 프롬프트에서 실행할 수 있다.
명령 프롬프트에서 다음과 같이 입력한다.

python app.py


애플리케이션을 실행하면 다음의 URL을 열어서 결과를 확인할 수 있다: http://127.0.0.1:7862

  • 이 URL은 각자의 환경에 따라 다를 수 있다.

 

Jupyter Notebook에서 Gradio 애플리케이션 실행

Jupyter Notebook에서 코드를 실행할 수도 있다.
인터페이스를 생성한 후 app.launch()를 사용하여 애플리케이션을 실행할 수 있다.

app = gr.Interface(fn=user_greeting, inputs="text", outputs="text")
app.launch()
  • 이렇게 하면 새로운 위젯이 생성된다.

[출처] Gradio 설치 및 실행 방법

Loading