1 6월 2014

弘益人間 (홍익인간)

사용자의 삶의 만족도를 높이고 불쾌함과 짜증을 감소시키는 견고하고 에러없는 소프트웨어 개발을 목표로 세월이 지나도 혁신적인 활동을 “에스 테크 스타 닷컴”은 이어갑니다.  좋은 소프트웨어 창출로 정보기술의 弘益人間 (홍익인간)을 구현합니다.

 


 

 

 

 

 

혼자가 아닌 나!


 

Loading

1 6월 2014

comphy’s profile

2014년
대한민국 공군 사이버전실습 및 대응체계 개발:평택공군제7전대
에스테크스타닷컴 에스천사게임즈 오픈
ebook 출판 예정

2013년
KT BIT OSS 프로젝트

2012년
삼성전자 가전사업부 표준화파트너 시스템 개발 (Java,JSP,Oracle)
행안부 종합장애대응체계 / 복지부 행복e음 유지보수

2011년
삼성전자 스마트그리드 서버 및 스마트TV 앱 검증 서버
삼성bada 2.0 검증 어플리케이션 개발 (MWC2011출품)

2010년
[LGU+] 패킷관련 프로젝트
[수원,구미] 삼성전자 MMP 프로젝트 (터치모바일플랫폼) : 피쳐폰의 스마트화

2009년
[천안] 삼성코닝 정밀유리 : S-Contour 프로젝트

2008년
삼성전자 소프트웨어연구소 QMO과제 수행

 

 

 

 

Loading

19 4월 2012

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

네 시작은 미약하였으나 네 나중은 심히 창대하리라.

Your beginnings will seem humble, so prosperous will your future be….

나라장터 조달업체 등록 : 2014-07-04

한국SW산업협회 소프트웨어사업자등록 : B14-87964

출판업 신고 : 수지구청 제 123호

통신판매업 신고 : 제2012-용인수지-0185호

사업자 신고 : 용인 142-07-27414

sjkim_cc

 

 

Loading

13 5월 2999

Web Cloud & mobile App Business working Link

Web Cloud & mobile App Business working Link

  1. Biz Design Workplace
  2. Biz marketing tools Workplace
  3. Biz reference datas
    1. 프리렌서 업무 [크몽] : https://kmong.com/
    2. 모바일 앱 시장조사 [와이즈앱] : https://www.wiseapp.co.kr/
    3. 프리렌서 업무 [위시켓] : https://www.wishket.com
    4. 프리랜서 업무 [프리모아] : http://www.freemoa.net/
    5. 프리렌서 업무 [이렌서] : http://www.elancer.co.kr/
  4. Biz online Developing tool
  5. cloud developer console
    1. microsoft azure : https://azure.microsoft.com/ko-kr
    2. google developer console : https://console.cloud.google.com/?hl=ko
    3. amazon AWS : https://aws.amazon.com/ko/console/
  6. Mobile App Biz market
    1. android developer console : https://play.google.com/apps/publish/?hl=ko
    2. onestore (T Store) : http://dev.onestore.co.kr/devpoc/index.omp
    3. apple app store : https://developer.apple.com/app-store/
  7. 지적재산권 등록
    1. 특허정보검색(KIPRIS) : http://www.kipris.or.kr/khome/main.jsp
    2. 특허로(특허출원) : http://www.patent.go.kr/portal/Main.do

 

 

 

Loading

13 5월 2999

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

매일 들르는 곳 : nooksurfer : ホームページの閲覧えつらん者しゃ

 

 

자주 들르는 곳 : Frequent stop :

 

모바일 (게임)개발툴 사이트

 

 

 웹 (사이트) 개발

 

 

디지털 마켓

 

 

멀티미디어 리소스 (마켓)

 

인문학과 사회와 재경학에 관심을 가져보자

 

오프라인 교육 기관

 

Loading

18 10월 2026

[인공지능 개발자] 게임 개발용 AI 하네스를 설계하는 방법 

[인공지능 개발자] 게임 개발용 AI 하네스를 설계하는 방법 

28P by GN⁺ | ★ favorite | 댓글 1개
  • 게임에서 LLM을 효과적으로 쓰려면 코드뿐 아니라 게임 상태, 데이터, 실행 결과를 에이전트가 읽고 조작할 수 있게 만들어야 함
  • 결정론적 상태 재현과 저장/불러오기를 개발 초기부터 설계하면, 에이전트가 같은 조건에서 변경을 반복 검증할 수 있음
  • 단일 객체 타입과 명령 패턴으로 상태 변경을 구조화하고 데이터를 외부로 분리하면, 재컴파일 없이 게임을 조작하고 수치를 시험하는 반복 작업이 가능함
  • 게임 시뮬레이션을 엔진과 별도 라이브러리로 분리하고, 이미지 차이와 텍스트 프로파일링 결과를 제공하면 에이전트가 변경 효과를 더 쉽게 평가할 수 있음
  • 이 구조에서는 게임 자체가 하네스가 되어 전체 반복 주기를 수초 안에 돌릴 수 있음. 다만 주된 적용 대상은 큰 프로젝트이며, 작은 게임에는 이런 설계가 필요하지 않을 수 있음

웹 개발과 달리 게임이 LLM에 불투명한 이유

  • mood.site는 ChatGPT 웹 인터페이스에 코드를 복사해 넣는 방식으로 약 2~3주간 밤에 작업해, 총 20시간 정도에 구현한 사례임
    • 직접 검증할 부분이 많고 작업 방식도 불편했지만, 실제로 작동하는 사이트를 완성했으며 이후 LLM 활용의 시험대가 됨
    • Claude Code와 후속 Claude 모델을 사용한 개인 경험에서는 웹 기술 스택으로 구현하지 못할 일이 거의 없다고 느낄 만큼 발전했음
  • 게임 개발에서는 반대로 LLM이 제대로 작업하지 못하는 경험이 반복됨
    • 약 15년의 게임 프로그래밍 경험에 비해 Svelte 웹 앱 경험은 적다는 점이 코드 품질 판단에 편향을 줄 수 있음
    • 공개된 고품질 웹 프로젝트가 많다는 점은 웹 코드 품질을 기대할 근거지만, 게임 학습 데이터가 훨씬 적다는 것은 추정임
  • 게임에는 코드로 쉽게 표현하기 어려운 에셋과 여러 시스템이 있으며, 웹에서 다루는 텍스트와 레이아웃도 그중 일부에 불과함
    • Three.js 기반 일회성 게임 생성은 에셋을 단순한 상자형 기본 도형으로 표현해 에셋 제작, 규격 맞춤, 처리 작업을 상당 부분 건너뜀
    • 이런 결과물은 LLM이 만드는 평균적인 형태를 벗어난 창작자의 개성이 부족한 경우가 많지만, 모든 요소를 코드로 표현한다는 점에서는 LLM이 이해하고 수정하기 쉬움
  • 기존 게임에서 중요한 비코드 요소가 불투명하게 남아 있으면, LLM은 그 요소를 조작하거나 변환하는 작업에서 막힘
    • 여기서 다루는 문제는 사회적 영향이 아니라 개발 도구로서의 역량임
    • 게임에서 LLM을 잘 쓰는 문제를 게임이나 LLM의 본질적 한계보다 컨텍스트 문제로 접근함

컨텍스트 관리와 하네스의 역할

  • LLM 호출의 기본 구성은 시스템, 어시스턴트, 사용자 프롬프트로 구분할 수 있음
    • 시스템 프롬프트는 서비스 사용자에게 공통으로 적용되는 모델의 기본 지침이며, 공개되거나 유출된 사례를 참고할 수 있음
    • 어시스턴트 프롬프트는 입력에 대한 모델의 응답과 상호작용을 안내하는 부분임
    • 사용자 프롬프트에는 채팅과 코드 등 대부분의 입력이 들어가며, 컨텍스트는 주로 사용자와 어시스턴트 영역에 쌓인 토큰을 가리킴
  • 세션에서 새 메시지를 보낼 때 이전 메시지도 함께 다시 전달되므로, 과거의 잘못된 정보가 이후 작업에 계속 영향을 주는 컨텍스트 오염이 발생할 수 있음
  • 게임마다 요구 사항이 달라 엔진이 있어도 모든 게임에 통하는 제작 템플릿이나 표준 도구를 기대하기 어려움
  • 하네스(harness) 는 예상 입력에 대해 에이전트가 취할 행동 패턴을 구성한 것으로, Claude Code 같은 도구도 여기에 해당함
    • 특정 작업에 맞게 확장하거나 추상화할 수 있으며 브라우저 반복 작업, 원격 측정, 프로파일링, 티켓과 문서 작성 같은 소프트웨어 개발 생명주기 작업까지 연결할 수 있음
    • 하지만 코드만 보는 하네스로는 게임의 비코드 요소를 다루는 문제가 해결되지 않음
  • 필요한 것은 게임이라는 블랙박스를 열어 더 많은 요소에 LLM이 직접 접근할 수 있게 만드는 것임
    • 아래 기법 상당수는 AI 없이도 게임 개발에 도움이 되는 설계이며, AI와 결합하면 효과가 커짐

고정된 난수와 결정론적 상태 재현

  • 결정론의 목표는 특정 게임 상태를 쉽고 정확하게 재현하는 것임
    • 개발 막바지에 도입하면 근본적인 구조 변경이 필요할 수 있으므로, 첫 코드부터 설계 제약으로 삼는 편이 좋음
  • 게임 시작 시 시드가 있는 단일 난수원을 만들고, 비결정적 동작에 필요한 난수 호출을 모두 이 경로로 통일함
    • 같은 순서로 호출하면 30번째 난수 호출도 매번 같은 값을 얻는 식으로 상태 재현의 기반을 마련할 수 있음
  • 같은 상태를 처음부터 반복 재현할 수 있어야 에이전트가 상태 복원 실패에 시간을 쓰지 않고 변경 자체를 검증할 수 있음

스크린샷보다 이미지 차이를 평가하기

  • 엔진의 스크린샷 기능과 함께 UI와 게임플레이 레이어를 개별적으로 끄고 켜는 기능을 마련함
    • UI 스타일을 수정할 때 뒤쪽 게임플레이를 숨기는 식으로, 평가 대상과 무관한 시각적 정보를 줄일 수 있음
  • 변경 전후 스크린샷을 그대로 주는 것만으로는 멀티모달 LLM도 무엇이 바뀌었고 목표에 가까워졌는지 판단하기 어려울 수 있음
    • 이미지에서 무관한 부분까지 처리하면서 생기는 잡음도 컨텍스트 오염이 될 수 있음
    • 예를 들어 행사 홈페이지의 해골만 해적으로 바꾸려 해도 모델은 전체 이미지를 처리함
    • Google Stitch처럼 이미지에 요청을 주석으로 붙일 수 있더라도, 나머지 화면 정보가 함께 전달되는 문제는 남음
  • 이미지 차이 비교와 잘라내기를 결합하면 변경 영역과 목표 이미지와의 차이를 더 명확하게 평가할 수 있음
    • 무료 명령줄 도구 odiff는 두 이미지의 차이를 이미지로 출력하고, ‘85% 유사’와 같은 정량적 비교 값도 제공함
    • 에이전트는 이 값을 반복 작업 사이의 안정적인 평가 기준으로 삼아 차이를 줄이거나 유사도를 높일 수 있음
  • 시각적 변경이라면 내부 수정과 검증을 여러 차례 수행한 뒤 스크린샷 비교로 돌아오는 반복 구조를 만들 수 있음
  • 목표는 원하는 결과에 필요한 최소 변경을 빠르게 검증하는 것임
    • 거의 독립적으로 평가할 수 있는 안정적이고 단순한 기준 상태를 유지해, 그 위에 쌓는 변경이 광범위한 기술 부채로 번지지 않도록 함

저장/불러오기와 Thing 중심 개발

  • 결정론적 상태에 얼마나 가까운지는 정확히 같은 상태를 얼마나 쉽게 저장하고 불러올 수 있는가로 확인할 수 있음
    • 저장/불러오기를 나중에 추가할 기능으로 보지 말고, 개발 시작부터 함께 설계해야 함
  • 강한 객체지향 계층에서는 서로 다른 객체처럼 보이는 대상이 실제로는 비슷한 구성 요소의 조합인 경우가 있음
    • 나무는 메시와 충돌체를, 개는 메시와 충돌체에 이동 능력을 더 가짐
    • 이동은 개에만 고유한 성질이 아니므로, 코드 관점에서는 둘 다 구성 요소를 조합한 대상으로 볼 수 있음
  • Thing 중심 개발(Thing-Driven Development) 은 모든 대상을 하나의 Thing 타입으로 표현하는 접근임
    • 공통 수치 필드와 isAlive 같은 생존 상태를 두고, 구체적인 종류는 열거형 값으로 구분해 처리함
    • 100개 클래스와 상속 관계를 이해한 뒤 확장 위치를 결정하는 대신, AI가 수정할 단일 기준점을 갖게 됨
  • 단일 객체 타입은 직렬화와 역직렬화 경로도 단순하게 만듦
    • 게임을 Thing의 거대한 목록으로 보고 하나의 경로로 저장하고, 역순으로 불러올 수 있음
    • 여러 타입과 상속 트리에서는 역직렬화 순서, 객체와 자식 연결, 다형적 역직렬화 같은 복잡성이 생길 수 있음
  • 같은 방식으로 턴 번호를 필드에 넣고 GameManager 종류를 두어 게임 전체 상태도 표현할 수 있음
    • 실제 구현에는 추가 복잡성이 있으며, Dreams 제작진이 유사한 구조를 이야기한 Wookash 팟캐스트 에피소드를 참고할 수 있음
    • 메모리 비용에 대한 우려와 관련해서는 Computer, Enhance!의 관련 문답을 참고할 수 있음

명령 패턴으로 상태를 직접 조작하기

  • 단일 대형 구조체 방식에서는 모든 변경 대상이 같은 타입이므로, 명령 패턴(Command Pattern)을 적용하기 쉬움
    • 객체를 느슨한 함수 호출로 직접 변경하는 대신, 변경 요청을 가능하면 직렬화할 수 있는 객체로 만들고 처리기를 거쳐 적용함
  • 시작 상태와 플레이어의 명령 기록이 있으면, 버그가 난 상황을 명령 재생으로 재현할 수 있음
    • 플레이어에게 행동을 물어보고 사람이 다시 플레이할 필요 없이, AI 에이전트도 기록을 재생하며 변경 영향을 확인할 수 있음
  • 명령은 게임 안에서만 생성할 필요가 없음
    • 사람이나 AI가 텍스트 편집기에서 명령을 작성해 실행 중인 게임에 전달하면 재컴파일 없이 조작할 수 있음
    • 타입이 있는 공통 인터페이스 덕분에 매번 별도 처리 로직이나 리플렉션을 추가할 필요가 줄어듦
  • 컴파일을 기다리지 않고 시험할 수 있는 범위가 넓을수록 에이전트의 실행과 검증 주기가 짧아짐

정적 데이터를 코드 밖으로 분리하기

  • 여기서 데이터는 Type, attackDamage, walkSpeed, boatSpeed처럼 객체의 기본 특성을 정의하는 정적 운영 데이터를 뜻함
    • 게임 중 수정 효과가 적용되거나 플레이어에게 수치가 직접 보이지 않더라도, 객체의 기본 형태를 규정하는 값임
  • 이런 값을 코드에 직접 넣으면 기본 이동 속도 하나를 바꾸는 데도 재컴파일하거나 외부 호출용 함수 바인딩을 작성해야 함
  • 데이터를 게임 외부에 두고 역직렬화한 뒤 객체 생성과 연결하면, 데이터 원본을 바꾸는 방식으로 반복 작업이 가능함
    • 개발자, 에이전트, 다른 팀원 모두 에디터 접근 없이 게임 빌드만으로 데이터를 시험할 수 있음
  • Cantata 개발에서는 비프로그래머 팀원 약 7명에게 게임 빌드와 자체 데이터 편집기 Depot을 제공함
    • 팀원이 Depot에서 값을 바꾸면 게임 빌드가 변경 데이터를 읽어 적용하므로 새 빌드를 받을 필요가 없었음
    • 이 도구는 독립 제품으로 발전 중이며, 다른 팀은 Google Sheets나 자체 데이터 도구를 사용하기도 함
  • AI에도 팀의 데이터 도구 사용법을 익히게 하면, 다른 팀원처럼 빌드를 반복 생성하지 않고 변경을 시험할 수 있음
    • 핵심은 반복 주기의 병목 제거임

시뮬레이션을 엔진 밖의 독립 라이브러리로 만들기

  • 게임 로직과 UI, 시각 효과가 섞이면 간단한 테스트나 버그 재현에도 모델, 사운드, 장면을 포함한 게임 전체 실행이 필요해짐
    • 문제가 시뮬레이션, 모델, 장면 설계 중 어디에서 발생했는지도 구분하기 어려워짐
  • 블랙박스 게임 아키텍처(Blackbox Game Architecture) 에서는 시뮬레이션을 엔진 밖의 별도 DLL이나 라이브러리로 둠
    • 엔진은 명령을 보내고, 시뮬레이션은 갱신된 상태를 반환함
    • 엔진은 전체 상태 또는 이전 상태와의 차이를 해석해 화면과 소리를 갱신하며, 시뮬레이션이 상태의 기준이 됨
  • 이동의 경우 애니메이션, 모델, 효과음, 이동 시작과 종료, 시야 갱신 등이 얽혀 있어도 핵심은 입력에 따라 A에서 B로 위치가 바뀌는 것임
    • 엔진이 Thing의 이동 요청을 보내면 시뮬레이션이 목적지의 유효성을 확인하고 이동 결과를 반환함
    • 엔진에서 먼저 걸러낼 수도 있으며, 반환 상태 비교나 승인된 명령 버퍼 등을 통해 이동을 감지할 수 있음
    • 최종적으로 시뮬레이션이 이동했다고 판단하면 엔진은 그 결과에 따라 객체를 움직임
  • 분리된 코어에는 어떤 주체든 명령을 보낼 수 있음
    • 상태와 차이만 소비하는 구조에서는 결과가 로컬, 네트워크, LLM 중 어디에서 왔는지가 중요하지 않아 네트워크 구현도 쉬워짐
    • 상태, 로직, 데이터의 강한 결합 때문에 필요했던 복잡한 테스트 준비도 줄일 수 있음
  • 엔진 없이 순수 C# 프로젝트와 표준 도구로 시뮬레이션을 빠르게 테스트할 수 있음
    • 플레이어 경험을 구현하는 층과 분리해 시뮬레이션, 가설 검증, 테스트를 직접 수행할 수 있음
    • Brian Cronin의 Roguelike Celebration 발표는 Monster Train에 적용한 방식을 다루며, Solium Infernum 팀도 Game Data Podcast에서 유사한 기법을 소개했음

텍스트 프로파일링으로 변경 영향을 평가하기

  • 변경이 실제 게임에 원하는 영향을 줬는지는 영향 평가로 확인해야 함
    • 일반적인 테스트뿐 아니라 고정된 게임플레이 시나리오로 밸런스 영향을 확인하는 방법도 있지만, 구체적인 구성은 게임마다 달라짐
  • 공통적으로 중요한 성능 평가는 보통 Unity/Unreal 내장 프로파일러나 dotMemory 같은 사람 중심 도구에 의존함
    • 사람이 호출 스택과 그래프를 살펴보는 인터페이스는 에이전트가 읽기 어려움
    • Unity도 프로파일러를 에이전트가 더 잘 읽을 수 있게 하는 작업을 진행 중임
  • AI가 읽기 쉬운 텍스트 형태의 원시 캡처 결과를 제공하면 반복 평가를 돕기 쉬움
    • 무료 도구 samply는 프로젝트에 연결해 실행하고 캡처 결과를 콘솔로 출력할 수 있음
    • 에이전트가 소스와 문서를 읽어 평가 방식을 파악하면, 캡처와 수정의 반복을 사실상 자율적으로 수행할 수 있음

게임 자체를 하네스로 만들되 규모에 맞게 적용하기

  • 결정론적 입력, 구조화된 상태 변경, 외부 데이터, 독립 시뮬레이션, 이미지 비교, 성능 평가를 연결하면 게임 중심 하네스가 됨
  • 데이터 중심이며 바이너리로 분리되고 재컴파일이 필요 없는 작업 흐름에서는, 에이전트가 전체 반복 주기를 수초 안에 수행할 수 있음
    • 각 단계가 게임과 작업 목표를 더 잘 이해하도록 돕고, 충분히 빠른 검증은 중요한 시점에만이 아니라 매 변경마다 실행할 수 있음
  • 다만 이 설계가 모든 프로젝트에 필수인 것은 아님
    • 실제로 출시 작업 중인 아주 작은 프로젝트에는 이 기법들을 전혀 사용하지 않았으며, 별도의 하네스 작업이 많이 필요하지 않았음
    • 주된 적용 대상은 더 큰 게임 프로젝트이며, 규모가 커질 때 이런 도구와 구조의 필요성이 커짐

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

Loading

6 9월 2026

[인공지능 기술]  25년 전 닷컴버블 때도 똑같았다: Nature가 경고하는 AI 논문과 살아남는 1% 연구자

[인공지능 기술]  25년 전 닷컴버블 때도 똑같았다: Nature가 경고하는 AI 논문과 살아남는 1% 연구자

  • (00:00~01:29) 연구자의 고민은 ‘AI를 써도 되나?’가 아니다
    • AI를 어디까지 사용할지가 아니라, 앞으로 연구자의 경쟁력이 어디에서 결정될 것인가가 핵심 질문이다.
    • 현재 학계는 연구 평가 기준과 연구자의 역할 자체가 AI로 인해 재편되는 과도기에 있다.
  • (01:29~05:16) 닷컴버블 시기의 인터넷 혁명과 AI 혁명의 공통점
    • 1990년대 후반에도 전자저널은 편리했지만 쉽게 신뢰받지 못했다.
    • 처음에는 “사용 여부”가 논쟁이었지만 시간이 지나면서 “책임을 누가 질 것인가”가 중요한 기준으로 바뀌었다.
    • AI 역시 같은 과정을 거치며 사용보다 검증 책임이 중요해지고 있다.
  • (05:16~06:41) Nature와 NeurIPS가 요구하는 AI 활용 원칙
    • AI는 연구를 보조할 수 있지만 연구의 판단과 책임은 연구자에게 있다.
    • AI가 생성한 결과는 반드시 사람이 검증하고, AI 사용 사실을 투명하게 공개해야 한다.
    • 앞으로 연구자는 AI를 얼마나 썼는지가 아니라 AI 결과를 얼마나 검증했는가로 평가될 가능성이 높다.
  • (06:41~09:35) AI 활용 능력은 곧 기본기가 된다
    • 인터넷 사용법이 특별한 기술이 아니게 된 것처럼 AI 활용법도 빠르게 평준화된다.
    • 프롬프트 기술이나 AI 사용법 자체는 경쟁력이 오래 지속되지 않는다.
    • 희소해지는 능력은 AI 결과를 의심하고 검증하는 사고력이다.
  • (09:35~12:45) 연구 주제 자체가 AI 중심으로 이동한다
    • 인터넷 등장 후 문헌정보학에서는 ‘웹 계량학(Webometrics)’이 몇 년 만에 핵심 연구 분야가 되었다.
    • AI 시대에도 기존 연구를 반복하는 것이 아니라,
      • AI 때문에 새롭게 가능해진 연구 질문
      • AI를 활용해야만 검증 가능한 문제
        를 찾는 연구자가 경쟁력을 갖는다.
  • (12:45~14:56) 논문 양보다 질문의 질이 중요해진다
    • AI는 논문 작성 자체를 매우 쉽게 만든다.
    • 따라서 단순히 논문 편수가 많다는 사실의 가치가 점점 낮아질 가능성이 크다.
    • 앞으로는 새로운 연구 질문을 발견하는 능력이 가장 희귀한 역량이 된다.
  • (14:56~16:21) 새로운 디지털 격차는 AI 인프라에서 발생한다
    • 인터넷 시대에는 회선 속도가 경쟁력이었다.
    • AI 시대에는 GPU, AI 장비, 데이터, 연구 환경이 새로운 경쟁력이 된다.
    • 격차는 사라지는 것이 아니라 형태만 바뀌어 다시 나타난다.
  • (16:21~17:49) 연구실 선택 기준도 달라진다
    • 학교 이름이나 논문 수보다
      • 자신의 질문을 검증할 데이터
      • AI 활용 환경
      • 협업 가능한 연구실
        을 갖춘 곳이 더 중요해진다.
  • (17:49~19:12) AI 시대 연구자의 핵심 역량
    • AI는 정보를 평준화했고 이제는 답 생성도 평준화하고 있다.
    • 앞으로 가장 중요한 능력은
      • 무엇을 질문할 것인가
      • 어떤 답을 믿을 것인가
      • 어떤 근거로 검증할 것인가
        를 판단하는 능력이다.
    • 연구자는 AI를 많이 사용하는 사람이 아니라 질문을 선택하고 결과에 책임질 수 있는 사람이 되어야 한다.

핵심 메시지 5가지

  1. AI 활용 능력은 경쟁력이 아니라 곧 기본기가 된다.
  2. 연구자의 경쟁력은 AI가 만든 답을 검증하는 능력에서 나온다.
  3. 논문 수보다 ‘새로운 연구 질문’을 만드는 능력이 더 중요해진다.
  4. AI는 연구를 대신하는 것이 아니라 연구 병목을 다른 곳으로 이동시킨다.
  5. AI 시대 최고의 연구자는 답을 가장 많이 만드는 사람이 아니라, 가장 중요한 질문을 선택하는 사람이다.

Glasp 관련 인사이트

Glasp의 AI 협업 관련 자료에서도 비슷한 결론을 제시한다. AI를 단순한 자동화 도구가 아니라 맥락을 제공하고 함께 사고하는 협업자로 활용해야 하며, 작업 속도가 빨라지는 것과 실제 학습·이해가 깊어지는 것은 다른 문제라고 강조한다. 따라서 AI가 만든 결과를 비판적으로 검토하고 자신의 판단 근거를 축적하는 과정이 장기적인 경쟁력이 된다.

Loading

9 8월 2026

[인공지능 기술] [AX 현주소 ①] AI 열풍 3년째…‘AI 혁신’은 AX로 이어졌나 / AI 도입 가속에도 AX는 정체…기초 DX·데이터·인프라가 관건

[인공지능 기술] [AX 현주소 ①] AI 열풍 3년째…‘AI 혁신’은 AX로 이어졌나 / AI 도입 가속에도 AX는 정체…기초 DX·데이터·인프라가 관건

[AX 현주소 ①] AI 열풍 3년째…‘AI 혁신’은 AX로 이어졌나

  •  양승갑 기자
  •  
  •  승인 2026.02.23 17:55

AI 도입 가속에도 AX는 정체…기초 DX·데이터·인프라가 관건

238073_243044_2720.jpg
[사진=구글 제미나이 생성]

[아이티데일리] 2022년 말 등장한 챗GPT는 인공지능(AI)의 활용 방식을 근본적으로 바꿔놓았다. 이에 따라 AI는 더 이상 일부 기업의 연구 실험실에서 시험되던 기술이 아니라 누구나 일상적으로 사용하는 도구로 빠르게 자리 잡았다. 문서 작성과 고객 응대를 넘어 이제는 의사결정 과정과 운영 전략 수립에도 AI가 활용되는 단계에 이르렀다.

그렇다면 기업이 진정한 의미의 AX를 실현하려면 무엇이 달라져야 할까. 기술 도입을 넘어 데이터 체계와 인프라, 조직 운영 방식까지 재구성하는 전환은 어떻게 가능할까. AX를 이루기 위한 과제와 조건, 그리고 이를 뒷받침하기 위한 관련 업계의 움직임을 짚어본다.

AI 도입 늘었지만…전사적 AX는 ‘제자리 걸음’

‘AI 전환(AX, AI Transformation)’은 단순히 AI를 도입하는 수준을 넘어 이를 중심에 두고 조직의 운영 체계를 재설계하겠다는 움직임을 일컫는다. AX는 기존의 ‘디지털 전환(DX, Digital Transformation)’과도 결이 다르다. DX가 업무 프로세스를 시스템화하고 효율화하는 데 초점을 맞췄다면 AX는 판단과 실행의 구조 자체를 AI 기반으로 재편하는 데 방점이 찍혀 있다.

이런 움직임 속에 산업 전반의 AI 도입 사례도 빠르게 늘고 있다. 제조업은 설비 이상 탐지와 품질 검사 자동화, 생산 스케줄 최적화 등 공정 단계에 AI를 접목하고 있으며 금융권은 대출 심사 고도화와 이상 거래 탐지, 내부 문서 자동화 등 업무 효율 개선에 무게를 두고 있다. 유통·물류 기업 역시 수요 예측 모델과 재고 관리 시스템, 배송 경로 최적화 알고리즘 등을 도입하며 운영 효율을 끌어올리는 방향으로 AI 활용 범위를 넓히고 있다.

다만 이러한 확산이 곧바로 전사 차원의 AX로 이어지고 있는 것은 아니라는 평가도 나온다. 상당수 기업이 AI를 특정 기능이나 부서 단위에 접목하는 데 그치고 있다는 의견이다.

일례로 보스턴컨설팅그룹(BCG)이 2024년 발표한 조사에 따르면 전 세계 기업의 78%가 최소 한 가지 이상의 비즈니스 기능에 AI를 도입했다고 응답했다. 다만 AI를 통해 ‘상당한 비즈니스 가치’를 창출했다고 답한 기업은 4%에 불과했다. 또 다른 분석에서는 AI 도입 기업의 74%가 가치 창출과 이를 조직 전반으로 확장하는 과정에서 어려움을 겪고 있다고 밝혔다.

맥킨지가 2025년 공개한 보고서에서도 AI를 실험 단계를 넘어 전사적으로 확장했다고 응답한 기업은 20%대 초반 수준에 머물렀다. AI 도입 자체는 빠르게 늘고 있지만, 이를 기업 전반의 AX로 연결하는 과정에는 여전히 높은 장벽이 존재한다는 의미다.

그렇다면 이러한 간극은 어디에서 비롯되는 것일까. 핵심은 AX가 단순한 기술 도입의 문제가 아니라 기업의 운영 구조 전반을 재구성하는 과제라는 데 있다. 특정 업무에 AI를 적용해 성과를 내는 것과 조직의 의사결정·권한·책임 체계를 AI 중심으로 재설계하는 일은 차원이 다른 문제다.

예컨대 생성형 AI를 고객센터에 도입해 상담 응답 시간을 단축하고 반복 문의를 자동 처리하는 것은 분명 의미 있는 AI 활용 사례다. 제조 현장에서 불량 검출에 AI를 적용하는 경우도 마찬가지다. 사람이 육안에 의존하던 공정을 자동화함으로써 검사 속도를 높이고 미세 결함을 조기에 발견해 불량률을 낮출 수 있기 때문이다.

다만 데이터 수집과 정제, 모델 학습과 배포, 성능 모니터링과 재학습으로 이어지는 전 주기 체계를 설계하는 일은 다르다. 이보다 더 나아가 그 결과를 실제 의사결정과 업무 프로세스에 반영하도록 재조정해야 한다는 점에서 이는 단순한 시스템 도입을 넘어선다.

238073_243045_3145.jpg
제조 현장에서의 AI는 기술검증 단계에 머문 채 확산하지 못하는 사례가 반복되고 있다. 자동화 설비가 가동 중인 스마트 공장 내부를 AI로 생성한 이미지.

“AX 이전의 숙제…기초적인 DX부터 안돼”

이 지점에서 확인해야 할 것이 기업의 준비 수준이다. 업계에 따르면 상당수 기업은 AX에 앞서 선행돼야 할 DX조차 완전히 마무리하지 못한 상태에 머물러 있다. 데이터가 부서별로 분절됐고 통합과 표준화가 충분히 이뤄지지 않아 “데이터는 많은데 정작 활용 가능한 데이터는 없다”는 상황도 적지 않다.

여기에 모델 학습을 추진하려 해도 고품질 데이터가 부족하고 사전 학습이나 파인튜닝을 수행할 인프라와 운영 환경 역시 충분히 갖춰지지 않은 경우가 많다는 지적이 따른다. 결국 성과를 가로막는 요인은 개별 기술의 한계라기보다 이를 지탱할 체계와 기반의 문제라는 분석으로 이어진다.

이 같은 한계는 제조업 비중이 높은 국내 산업 구조에서 더욱 선명하게 드러난다. 공장 환경은 일반적인 IT 인프라와 달리 폐쇄망으로 운영되는 경우가 많고 설비마다 데이터 포맷도 제각각이다. 시계열 데이터와 이미지, 로그 데이터가 뒤섞여 축적됐지만, 이를 학습에 곧바로 활용할 수 있도록 정제·표준화한 체계는 충분히 갖춰지지 않은 경우가 적지 않다.

이러한 환경은 모델의 현장 적용 과정에서 한계로 이어진다. 연구실 환경에서 99%의 정확도를 기록한 모델이라도, 실제 공정에 배포되면 조명 변화나 설비 진동, 원자재 편차와 같은 변수에 직면해 성능이 저하되는 사례가 발생한다. 많은 기업이 기술검증(PoC) 단계에서는 의미 있는 결과를 확인하면서도, 이를 생산라인 전반으로 확장하지 못하는 배경에는 이 같은 간극이 자리하고 있다.

이와 함께 AI를 도입하기만 하면 곧바로 성과로 이어질 것이라는 인식 역시 제약 요인으로 작용한다. 그러나 실제 현장에서는 도메인 전문가와 AI 인력이 긴밀히 협업하며 모델을 지속적으로 개선하는 운영 체계가 전제돼야 한다.

이와 관련해 한국인공지능·소프트웨어산업협회(KOSA) 안홍준 본부장은 “전반적으로 아직 넘어야할 산이 많지만 가장 많이 하는 이야기는 ‘기초적인 DX조차 완전히 이뤄지지 않았다’는 점”이라며 “AX는 데이터가 충분히 디지털화됐고 체계적으로 축적·관리되는 환경이 전제돼야 가능한데, 그 준비가 안 된 기업들이 적지 않다. 데이터가 정리돼 있지 않으니 AX를 하고 싶어도 출발점부터 막히는 경우가 많다”고 말했다.

그러면서 “같은 맥락으로 수요 기업 입장에서는 AI 전문기업이 들어와 프로젝트를 수행하길 기대하지만 현장에서는 확보할 수 있는 데이터가 제한적이거나 활용 가능한 형태로 정제되지 않은 경우가 많다”며 “그러다 보니 민간 차원에서 사전 학습을 통해 성능을 충분히 끌어올릴 기회도 부족하다. 이런 한계가 AX 확산을 더디게 만드는 요인이라고 본다”고 덧붙였다.

뤼튼AX 박민준 대표는 “AI 전환은 교육·컨설팅·구축이 유기적으로 맞물려야 완성된다”며 “전환의 필요성은 알고 있지만 이후 무엇을 어떻게 실행할지 모르는 기업이 많은 경우가 많다. 실제 현장에서 AI로 발생하는 경제적 효용을 체감하는 체계까지 설계해야 한다”고 설명했다.

그렇다면 이처럼 복잡하고 대규모 비용을 필요로 하는 AX를 기업들은 왜 시도하는 것일까. 역설적으로 그 배경에는 AI 확산으로 한층 가속화된 경쟁 환경이 자리하고 있다. 기업들이 설계·생산·고객 대응 전반에 AI를 접목해 속도와 정확도를 끌어올리면서 기존 방식에 머문 기업과의 격차가 점차 벌어지는 상황이다.

이러한 환경에서는 단순히 AI 솔루션 몇 개를 도입하는 수준으로는 경쟁력을 유지하기 어렵다. 데이터가 실시간으로 축적되고 분석 결과가 다시 생산과 서비스 전략에 반영되는 선순환 구조를 갖춘 기업만이 변화의 속도를 따라갈 수 있기 때문이다. 결국 AX는 개별 AI 기술을 얼마나 많이 도입했는지가 아니라 AI를 중심으로 얼마나 빠르게 학습하고 진화하는 조직 체계를 갖췄는지에 달려 있다.

올바른 AX 하려면…데이터 체계·GPU 인프라·실행 조직 등 갖춰야

이 같은 맥락에서 관련 업계는 ‘올바른 AX’를 위해 몇 가지 조건이 전제돼야 한다고 입을 모은다. 우선 데이터의 표준화와 거버넌스 정립이 선행돼야 하며, 모델 역시 일회성 개발로 끝나는 것이 아니라 반복 학습과 개선이 가능한 운영 체계로 관리돼야 한다는 것이다. 동시에 성능을 지속적으로 측정·관리할 수 있는 구조를 마련하고, AI의 결과가 실제 권한과 책임 체계에 반영되도록 조직 설계를 병행해야 한다는 요구도 따른다.

베슬AI 안재만 대표는 AX를 “전사적 AX는 기업이 자체적으로 AI 모델을 학습·운영할 수 있는 인프라와 체계를 갖추고 이를 통해 조직 전체가 AI를 반복적·지속적으로 활용할 수 있는 구조를 만드는 것”이라며 “비유하자면 AI 도입이 ‘좋은 엔진 하나를 사는 것’이라면 AX는 ‘그 엔진을 직접 만들고 개선할 수 있는 공장 자체를 보유하는 것’에 가깝다”고 밝혔다. 이어 “결국 AX의 핵심은 AI가 일회성 프로젝트가 아니라 기업 고유의 데이터와 도메인 지식을 반영한 모델을 자체적으로 개발·운영할 수 있는 역량을 갖추는 것”이라고 덧붙였다.

슈퍼브에이아이 관계자는 AX를 “기술 도입이 아닌 프로세스의 재정의”라고 설명했다. 이 관계자는 “기존의 AI 도입이 특정 공정의 불량을 잡아내거나 특정 데이터를 분류하는 도구로서의 활용에 그쳤다면, AX는 AI를 통해 데이터가 흐르는 전체 파이프라인을 구축하고 이를 기반으로 의사결정 체계와 비즈니스 모델 자체를 지속 가능한 구조로 바꾸는 것을 의미한다”고 말했다.

마키나락스 관계자는 제조 환경에서의 AX를 강조하기도 했다. 해당 관계자는 “AX는 개별 AI 모델을 도입하는 수준을 넘어 기업의 생산 방식과 의사결정 구조 자체를 AI 중심으로 재설계하는 과정”이라며 “많은 기업이 여전히 AX를 ‘정확도가 높은 모델 하나를 도입하는 것’으로 이해하지만 제조 현장에서의 AX는 전혀 다른 차원의 문제다”고 설명했다. 그러면서 “제조 AX의 본질은 모델 성능이 아니라 현장에서 끝까지 작동하는 운영 체계, 즉 데이터-모델-설비-의사결정을 하나의 흐름으로 연결하는 AI 운영 구조를 만드는 것에 있다”고 덧붙였다.

[출처] https://www.itdaily.kr/news/articleView.html?idxno=238073

Loading

24 7월 2026

 “AI 부업으로 돈 번다는 말, 거짓말입니다” 자동화 ‘딸깍’ 믿다간 망하는 진짜 이유 (f. 이시한 성신여자대학교 교수)

 “AI 부업으로 돈 번다는 말, 거짓말입니다” 자동화 ‘딸깍’ 믿다간 망하는 진짜 이유 (f. 이시한 성신여자대학교 교수)

  • (00:05~03:30) AI 시대 최고의 경쟁력은 ‘의지’이다.
    • AI가 갖지 못하는 가장 중요한 능력은 끝까지 해내려는 의지라고 설명한다.
    • 무명 아이돌 ‘리센느(RESCENE)’의 꾸준한 라이브 방송 사례를 들며, AI는 기준에 따라 포기하지만 사람은 결과가 없어도 계속 도전할 수 있다는 점이 인간의 경쟁력이라고 강조한다.
  • (04:05~06:57) “AI 딸깍으로 돈 번다”는 말은 절반은 거짓이다.
    • AI 자동화만으로 지속적인 수익을 얻는다는 주장은 현실과 다르다고 지적한다.
    • 정말 쉽게 돈이 된다면 그 방법을 팔지 않을 것이며, 현재는 유튜브 등 플랫폼 알고리즘도 AI 양산형 콘텐츠를 적극적으로 제한하고 있다고 설명한다.
    • 반면 AI를 편집·자막·반복 업무 보조 도구로 활용하여 생산성을 높이는 것은 충분히 효과적이라고 말한다.
  • (06:57~09:20) AI 시대에는 ‘많이 만드는 것’보다 ‘큐레이션’이 가치가 된다.
    • AI 덕분에 콘텐츠 생산량은 폭증했지만 소비자의 관심은 늘지 않았다.
    • 따라서 단순 생성보다 좋은 정보를 선별하고, 비교하고, 추천하는 큐레이션 능력이 더 중요한 경쟁력이 된다고 설명한다.
    • AI는 제작 도구이지, 무엇을 만들지 결정하는 것은 결국 사람이다.
  • (09:20~11:50) AI는 돈 버는 기계가 아니라 ‘사업 감각 증폭기’이다.
    • AI에게 처음부터 모든 것을 맡기는 것이 아니라,
      • 아이디어를 검토하고,
      • 수정하고,
      • 질문을 반복하며 함께 발전시키는 방식이 중요하다.
    • AI는 사용자의 감각을 몇 배로 증폭시킬 수 있지만, 원래 감각이 0이면 결과도 0이라는 점을 강조한다.
  • (11:50~14:58) 인간다움은 AI가 못하는 일을 찾는 것이 아니다.
    • “AI가 못하는 것”으로 인간을 정의하면 AI 발전과 함께 그 영역은 계속 줄어든다.
    • 앞으로 인간의 역할은
      • 좋은 질문 만들기,
      • 판단 기준 세우기,
      • 책임지는 일
        로 이동한다고 설명한다.
    • AI 시대 핵심 역량으로 3A를 제시한다.
      • Alliance(사람과 연결하기)
      • Asking(질문과 방향 설정)
      • Accountability(책임)
  • (14:58~17:04) 앞으로는 AI를 쓰는 사람이 아니라 ‘AI를 잘 쓰는 사람’이 경쟁력을 가진다.
    • 인터넷 검색이 이제는 기본 역량이 된 것처럼 AI 사용 자체는 누구나 하게 된다.
    • 차이는 AI와 공동지능(Co-Intelligence)을 형성하여 더 나은 결과를 만드는 사람에게 생긴다고 전망한다.
  • (15:41~17:45) AI 시대 가장 우려하는 미래는 ‘각자도생’이다.
    • AI와만 대화하고 동료와 협업하지 않는 문화가 이미 나타나고 있다고 설명한다.
    • 연구에서도 AI 활용이 늘수록 팀워크와 협업이 약해지는 현상이 보고되고 있으며,
    • AI가 사람 사이의 연결을 끊는 방향이 아니라 협력을 강화하는 방향으로 발전하기를 바란다고 말한다.
  • (17:45~20:20) 기술·인문·비즈니스는 이제 하나로 연결된다.
    • 저자는 기술, 인문학, 비즈니스를 함께 연구하는 이유를 설명한다.
    • 새로운 기술이 등장하면
      1. 사람의 행동이 바뀌고,
      2. 사회가 변하며,
      3. 새로운 경제적 기회가 생긴다.
    • 따라서 AI를 이해하려면 기술만이 아니라 인간과 시장을 함께 이해하는 관점이 필요하다고 강조하며 인터뷰를 마무리한다.

핵심 메시지

  • AI는 자동으로 돈을 벌어주는 기계가 아니다.
  • AI를 잘 활용하는 사람은 자신의 판단력·사업 감각·창의성을 AI로 증폭시키는 사람이다.
  • 앞으로의 경쟁력은 질문하는 능력, 큐레이션, 책임감, 사람과의 협업에서 나온다.
  • AI 시대에도 가장 중요한 자산은 의지와 실행력이다.

 

추가로, Glasp에서 최근 공유된 AI 관련 인사이트 중 이 영상과 가장 맞닿는 내용은 AI는 단순히 업무를 자동화하는 것이 아니라 인간의 학습과 의사결정을 증폭시키는 방향에서 가장 큰 가치를 만든다는 점이다. 이는 영상에서 말한 “AI는 사업 감각을 증폭하는 장치”라는 주장과도 일맥상통한다

Loading

24 7월 2026

[발버둥 청년] AI로 월 천만 원? 제가 직접 해본 현실은 달랐습니다

[발버둥 청년] AI로 월 천만 원? 제가 직접 해본 현실은 달랐습니다

  • (00:01–00:48) AI로 영상이나 블로그를 자동 생성해 월 1,000만~3,000만 원을 번다는 콘텐츠가 넘쳐나지만, 화자는 이런 성공 사례만 보고 누구나 쉽게 돈을 벌 수 있다는 주장은 현실과 거리가 멀다고 말한다.
  • (00:48–02:22) 직접 AI로 뮤직비디오 스타일의 유튜브 영상을 제작해 업로드한 결과를 공개한다. 약 노출 2,200회, 클릭률 2.6%, 조회수 72회에 그쳤으며, 이것이 대부분 초보 크리에이터가 처음 마주하는 현실이라고 설명한다.
  • (02:22–03:57) 유튜브 추천 시스템은 초반 시청자 반응(클릭률·시청 지속시간)이 좋지 않으면 노출을 확대하지 않는다. 기존 구독자와 팬층이 있는 유명 크리에이터와 신규 채널은 출발선 자체가 다르며, 성공한 AI 크리에이터도 수많은 시행착오와 실험을 거쳤을 가능성이 높다고 강조한다.
  • (03:57–05:38) AI의 발전으로 콘텐츠 제작 진입장벽은 낮아졌지만, 누구나 같은 AI를 사용하기 때문에 차별화는 오히려 어려워졌다. 블로그도 마찬가지로 AI가 글을 써준다고 자동으로 수익이 생기지는 않는다.
  • (04:51–05:38) 실제 블로그 운영 사례를 공개한다. 월간 방문자 2,254명까지 성장했지만 광고 수익은 약 250원 수준이었다. 조회수만으로는 수익이 발생하지 않으며 광고 클릭률이 매우 중요하다는 현실을 보여준다.
  • (05:38–06:17) 유튜브와 블로그는 작은 사업을 운영하는 것과 비슷하다고 비유한다. 유명 프랜차이즈와 신생 식당의 차이처럼, 좋은 콘텐츠라도 사람들이 존재를 모르면 성과를 내기 어렵다고 설명한다.
  • (06:17–07:51) 조회수가 낮다고 콘텐츠의 질이 반드시 나쁜 것은 아니다. 썸네일, 제목, 주제, 편집 방식 등을 지속적으로 개선하며 사람들이 클릭할 이유를 만들어가는 과정이 필요하다고 말한다.
  • (07:02–08:42) AI로 쉽게 돈을 번다는 환상을 버리고 직접 작은 규모라도 시작해 보는 것이 중요하다고 조언한다. 대부분은 오랫동안 낮은 조회수와 거의 없는 수익을 견디며 경험을 쌓아야 하며, 비싼 강의를 먼저 구매하기보다 직접 실행과 실패를 통해 자신만의 방법을 찾는 것이 현실적인 접근이라고 결론짓는다.

핵심 메시지

 

  • AI는 생산성을 높이는 도구이지 자동 수익을 보장하는 기계가 아니다.
  • 유튜브·블로그의 성공은 AI 활용보다 주제 선정, 차별성, 지속적인 개선, 알고리즘 이해, 꾸준한 실행이 더 큰 영향을 미친다.
  • 인터넷에서 보이는 성공 사례는 대부분 결과만 보여주는 생존자 편향(Survivorship Bias)일 가능성이 있으며, 보이지 않는 실패와 반복 실험이 뒤에 존재한다.
  • 현실적인 기대를 가지고 작은 프로젝트부터 검증해 나가는 것이 장기적으로 성공 가능성을 높인다.

Loading

23 7월 2026

[一日30分 인생승리의 학습법] 이봐, 신입, 우린 당신에게 주어진 일이나 끝내라고 채용한 게 아니야

[一日30分 인생승리의 학습법] 이봐, 신입, 우린 당신에게 주어진 일이나 끝내라고 채용한 게 아니야 

42P by GN⁺  | ★ favorite | 댓글 7개
  • 신입(N00b) 엔지니어의 가치는 완료한 작업 수가 아니라, 장차 주변 사람의 생산성까지 높이는 엔지니어로 성장할 가능성에서 결정됨
  • 선임 엔지니어는 신입을 조직을 바꾸는 A / 안정적인 성과를 내는 B / 1년 안에 떠날 가능성이 있는 C로 구분하며, 신입은 자신이 원하는 범주에 해당한다는 신호를 보내야 함
  • B가 되려면 코드가 동작하고 / 진행 상황을 공유하고 / 예상치의 3배 이내처럼 합리적인 시간에 끝내고 / 리뷰어와 운영 담당자에게 불필요한 일을 만들지 않아야 함
  • A는 작업을 많이 끝내는 사람이 아니라, 불필요한 작업을 제거하고 / 효과가 큰 10%를 찾고 / 설계를 개선하고 / 작은 변경을 연속으로 제출하는 등 작업마다 더 많이 학습하는 사람임
  • 뛰어난 성과를 보여주는 활동은 단순히 작업을 닫는 것보다 시간이 더 들지만, 무한정 곁가지에 빠지지 않고 절약한 시간을 자신과 동료에게 도움이 되는 방식으로 투자해야 함

현재 생산성이 아니라 미래의 엔지니어를 채용함

  • 선임 엔지니어가 신입을 바라보는 기준은 크게 세 범주로 나뉨
    • A는 주변 사람의 생산성까지 크게 끌어올리는 변화의 주체가 됨
    • B는 안정적인 성과를 내며 점차 성장함
    • C는 1년 뒤 조직에 남아 있지 않을 가능성이 있음
  • 선임들은 자신의 업무를 수행하는 동시에 각 신입이 어느 범주에 속하는지 판단해야 함
    • A에게는 가능한 한 많은 지원을 제공함
    • B에게는 성숙한 엔지니어가 될 만큼 지원함
    • 조직에 남지 못할 사람에게는 가능한 한 적은 노력을 쓰려 함
  • 신입에게 주어진 작업은 관리자나 기술 리더가 직접 처리하면 더 빠르고 수월하게 끝낼 수 있음
  • 당장의 생산성만 중요했다면 신입을 채용할 이유가 없으며, 회사는 신입이 장차 될 엔지니어를 확보하기 위한 옵션 프리미엄으로 현재의 급여를 지급함
  • 육성이 성공하면 강력한 다음 세대 엔지니어가 생기지만, 실패하면 선임들이 10년 뒤에도 같은 엔지니어링 업무를 계속해야 함

작업 개수만으로는 신입을 평가할 수 없음

  • 한 분기에 작업 40개를 완료한 신입과 20개를 완료한 신입 중 누가 더 나은지는 작업 수만으로 판단할 수 없음
  • 모든 작업의 난도가 같더라도 A/B/C를 가르는 데 필요한 정보는 여전히 부족함
  • 평가의 목적은 단기 산출량을 비교하는 것이 아니라, 신입이 어떤 종류의 엔지니어로 성장하고 있는지 확인하는 데 있음

B와 C를 가르는 기본 신호

  • 작업을 가장 짧은 시간에 닫는 것보다 다음 조건이 중요함
    • 작성한 코드가 실제로 동작함
    • 무엇을 하고 있는지 다른 사람에게 알림
    • 최초 예상 시간의 3배 이내처럼 합리적인 시간에 작업을 끝냄
    • 다른 사람에게 부당할 정도로 많은 추가 업무를 만들지 않음
  • 도움을 요청해 상대방의 시간이 드는 것은 허용되지만, 다음 상황은 나쁜 신호가 됨
    • 리뷰어가 불필요하게 많은 시간을 쓰게 만드는 것
    • 오류 때문에 온콜 담당자가 대응하게 만드는 것
    • 자신이 일으킨 장애 때문에 DevOps 담당자가 출동하게 만드는 것
  • 하지 않은 일을 했다고 속이는 등 평가 체계를 조작하려는 행동은 즉시 C 신호가 됨
  • 누구나 실수로 C 신호를 보낼 수 있지만, 같은 C 신호를 두 번 반복해서는 안 되며 전체적으로는 B에 해당하는 신호가 더 많아야 함

A와 B를 가르는 학습 속도

  • 최소한 B에 해당하는 신입 가운데 A를 구분하는 기준은 완료한 작업 수가 아니라 각 작업에서 얼마나 많이 학습하는가임
  • 신입의 현재 생산성이 선임보다 낮은 것은 예상된 상태이며, 중요한 것은 생산성 자체보다 생산성이 향상되는 속도임

A에 해당하는 행동

  • 다음과 같은 행동은 작업을 처리하는 수준을 넘어 학습과 조직의 생산성을 확대하는 A 신호가 됨
    • 해당 작업을 아예 수행할 필요가 없다는 설득력 있는 근거를 만듦
    • 데이터를 분석해 전체 효익의 90%를 만드는 작업 10%를 찾아냄
    • 같은 작업을 여러 방식으로 구현해봄
    • 더 나은 설계를 발견하고, 작업 구현뿐 아니라 주변 코드까지 단순화하는 일련의 diff를 제출함
      • 구현 전에 어려운 변경을 쉽게 만든 뒤 쉬워진 변경을 수행하면 더 좋은 평가를 받음
    • 하나의 큰 diff 대신 여러 개의 작은 diff를 연속으로 제출함
      • 매일 diff를 올리면 추가적인 장점이 있음
    • 비슷한 작업을 단순화하는 내부 도구를 작성함
      • 다시 발생할 비슷한 작업이 없다면 오히려 감점 요인이 됨
    • 공식 작업을 끝내는 데 지장을 주지 않으면서 다른 팀이나 코드 영역에도 유용한 diff를 제출함
    • 배운 내용을 흥미롭고 / 유용하고 / 설득력 있게 문서화함
    • 통찰력 있게 리뷰하고 피드백에 빠르게 대응함
    • 견고한 단위 테스트를 포함함
  • 뛰어난 성과를 보여줄 방법은 실수를 피하는 방법보다 훨씬 다양함

최소 시간보다 합리적인 시간이 중요함

  • A 신호에 해당하는 활동은 작업을 닫는 데 필요한 최소한의 구현만 하는 것보다 더 많은 시간이 걸림
  • 이는 흥미로운 곁가지에 무한정 시간을 써도 된다는 허가가 아님
  • 공식 작업은 언제나 합리적인 시간 안에 끝내야 하지만, 반드시 절대적인 최소 시간에 끝낼 필요는 없음

절약한 시간을 자신과 동료에게 재투자함

  • 추가적인 학습과 개선에 쓸 시간이 없다고 느낄 수 있지만, 시간 관리 / 작업 대기열 관리 / diff 대기열 관리 같은 기술로 진행 속도를 높일 수 있음
  • 그렇게 절약한 시간은 다른 사람에게도 이익이 되는 방식으로 자신의 성장에 투자해야 함

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

Loading

15 7월 2026

[전자출판물] 답부터 말하는 팀장은 무너진다 – 한국 IT 조직을 바꾸는 질문의 기술

[전자출판물] 답부터 말하는 팀장은 무너진다 – 한국 IT 조직을 바꾸는 질문의 기술

2026-07-12-02 답부터 말하는 팀장은 무너진다 축소 - 책 표지 그림 ChatGPT Image 2026년 7월 12일 오후 01_17_17.jpg

 

책소개

한국의 IT 조직에서 팀장은 오랫동안 ‘답을 주는 사람’으로 여겨졌다.

 

회의에서는 가장 먼저 말해야 하고, 문제가 생기면 즉시 해결책을 내놓아야 하며, 구성원의 질문에는 막힘없이 답해야 한다. 모른다고 말하면 권위가 떨어지고, 질문을 많이 하면 준비가 부족한 사람처럼 보일 수 있다는 두려움도 있다.

 

하지만 빠르게 변화하는 IT 프로젝트에서 한 사람이 모든 답을 아는 것은 불가능하다.

 

프로젝트의 실제 문제를 가장 먼저 발견하는 사람은 현장의 개발자이고, 고객의 불편을 가장 가까이에서 듣는 사람은 실무자다. 일정이 무너지고 있다는 사실, 설계가 잘못되었다는 신호, 불필요한 보고와 회의가 생산성을 떨어뜨리고 있다는 문제 역시 현장 구성원이 먼저 안다.

 

문제는 그들이 말하지 않는다는 것이다.

 

팀장의 질문이 의견 요청이 아니라 추궁으로 들리고, 솔직하게 말했다가 책임을 떠안을 수 있다는 두려움이 존재하기 때문이다. 결국 구성원은 침묵하고, 리더는 정확하지 않은 정보로 답을 내리며, 프로젝트는 서서히 무너진다.

 

《답부터 말하는 팀장은 무너진다》는 이러한 한국 IT 조직의 현실에서 출발한다.

 

이 책은 리더가 자신에게 던져야 할 질문, 고객에게 물어야 할 질문, 구성원에게 해야 할 질문, 위기의 순간에 반드시 확인해야 할 질문을 구체적으로 제시한다. 또한 구성원이 리더에게 묻고 싶어 하지만 쉽게 꺼내지 못하는 질문과 그에 대한 답변 방법도 함께 다룬다.

 

“일하는 데 무엇이 방해가 됩니까?”

 

“우리 경영진의 행동 중 당신의 일을 방해하는 것은 무엇입니까?”

 

“이 결정이 이해되지 않는 이유는 무엇입니까?”

 

“프로젝트가 실패한다면 가장 먼저 문제가 될 부분은 어디입니까?”

 

“제가 더 나은 리더가 되기 위해 무엇을 바꾸어야 합니까?”

 

이 질문들은 단순한 대화 기술이 아니다. 프로젝트의 위험을 조기에 발견하고, 구성원의 침묵을 깨며, 리더가 미처 보지 못한 현실을 드러내는 관리 도구다.

 

좋은 리더는 모든 답을 가진 사람이 아니다.

 

좋은 리더는 구성원이 진실을 말할 수 있도록 질문하고, 그 답을 끝까지 들으며, 들은 내용을 행동으로 바꾸는 사람이다.

 

이 책은 답을 독점하는 팀장에서 질문을 설계하는 리더로 변화하고 싶은 사람을 위한 현장형 리더십 안내서다.

 

 

 

목차

 

머리말

 

답을 주는 리더에서 질문하는 리더로

 

서론

 

답보다 먼저 질문해야 하는 이유

 

제1장 리더가 자기 자신에게 던져야 할 질문

제2장 리더가 고객에게 던져야 할 질문

제3장 리더가 구성원에게 던져야 할 질문: 사업에 관하여

제4장 리더가 구성원에게 던져야 할 더 깊은 질문

제5장 특별한 상황에서 던져야 할 질문

제6장 리더가 답해야 할 질문

제7장 특별한 상황에서 답해야 할 질문

제8장 어려운 답변을 전달하는 법

결론

책은 끝나지만 질문은 시작된다

 

부록

현장 리더들이 사용하는 좋은 질문

https://ebook-product.kyobobook.co.kr/dig/epd/ebook/E000013295962

 

Loading