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

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

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

29 6월 2026

[一日30分 인생승리의 학습법] 잘못된 추상화보다 중복을 선호하라 (2016) 

[一日30分 인생승리의 학습법] 잘못된 추상화보다 중복을 선호하라 (2016) 

29P by GN⁺  | ★ favorite | 댓글 6개
  • 잘못된 추상화보다 코드 중복이 훨씬 싸며, 성급한 공통화가 장기 유지보수 비용을 키운다고 봄
  • 처음에는 합리적이던 추출도 요구사항이 조금씩 달라지면 매개변수와 조건문이 붙어 원래 의도를 흐림
  • 공통 추상화가 여러 아이디어를 떠안기 시작하면 코드는 조건 중심 절차로 변하고, 새 기능을 넣을수록 더 깨지기 쉬워짐
  • 기존 코드에 들인 노력을 지키려는 매몰비용 오류를 경계하고, 필요하면 추상화를 호출부로 다시 인라인해 실제로 필요한 코드만 남겨야 함
  • 잘못된 추상화가 드러났다면 중복을 다시 도입해 현재 요구사항의 공통점을 새로 관찰하고, 그다음에 다시 추출하는 편이 더 빠름

잘못된 추상화가 만들어지는 흐름

  • “duplication is far cheaper than the wrong abstraction”라는 문장은 RailsConf 2014 발표의 일부였지만 이후에도 계속 회자됨
  • 흔한 실패 경로는 다음과 같음
    • 개발자 A가 중복을 발견함
    • 중복을 메서드나 클래스로 추출하고 이름을 붙여 새 추상화를 만듦
    • 호출부의 반복 코드를 새 추상화 호출로 대체함
    • 시간이 지나 거의 맞지만 완전히 같지는 않은 새 요구사항이 등장함
    • 개발자 B가 기존 추상화를 유지하려고 매개변수를 추가하고, 값에 따라 다른 경로를 타는 조건문을 넣음
    • 이후 새 요구사항마다 매개변수와 조건문이 늘어나며 코드 이해가 점점 어려워짐
  • 한 번 만들어진 코드는 보존해야 할 투자처럼 보이기 쉬움
    • 이미 들인 노력을 아깝게 여기는 심리가 작동함
    • 코드가 복잡하고 이해하기 어려울수록, 그만큼 중요하고 오래 걸렸을 것처럼 느껴져 버리기 어려워짐
    • 이는 매몰비용 오류와 연결됨

중복으로 되돌아가 다시 추출하기

  • 잘못된 추상화 위에서 새 요구사항을 계속 구현하면 공유 코드는 조건문 중심으로 변하고, 기능을 추가할수록 더 불안정해짐
  • 이때 빠른 길은 더 밀어붙이는 것이 아니라 뒤로 돌아가는 것임
    • 추상화된 코드를 각 호출부에 다시 인라인해 중복을 재도입함
    • 각 호출부에서 전달하던 매개변수를 기준으로 실제 실행되는 코드만 확인함
    • 해당 호출부에 필요 없는 코드를 삭제함
  • 인라인 과정은 추상화와 조건문을 함께 제거하고, 각 호출부를 자신에게 필요한 코드만 가진 상태로 줄임
  • 같은 추상화를 호출하는 것처럼 보였던 코드도 실제로는 각 호출부가 상당히 고유한 코드 경로를 실행하고 있었을 수 있음
  • 이전 추상화를 완전히 제거한 뒤에야 중복을 다시 관찰하고, 현재 요구사항에 맞는 새 추상화를 추출할 수 있음
  • 매개변수와 조건 경로가 공유 코드에 계속 추가되고 있다면 그 추상화는 더 이상 맞지 않을 가능성이 큼
    • 처음에는 맞는 추상화였을 수 있음
    • 요구사항이 바뀌면서 더 이상 같은 형태로 유지하기 어려워졌을 수 있음
  • 잘못된 추상화에서는 중복을 다시 도입하는 일이 후퇴가 아니라 더 나은 전진이 됨

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

Loading

18 5월 2026

[인공지능 기술] 로컬 AI가 표준이 되어야 함 

[인공지능 기술] 로컬 AI가 표준이 되어야 함 

28P by GN⁺ 7일전 | ★ favorite | 댓글 6개
  • 앱 기능에 OpenAI나 Anthropic API를 붙이는 흐름이 흔해졌지만, 클라우드 호스팅 AI 모델 의존은 서버 장애·결제 문제만으로 기능이 멈추고 개인정보 부담까지 커지게 만듦
  • 현대 기기에는 Neural Engine 등 강력한 온디바이스 연산 능력이 있지만, 대부분 유휴 상태로 방치된 채 서버 응답만 기다리고 있음
  • 예를 들어, Apple의 FoundationModels 프레임워크를 활용하면, 서버 없이 기기에서 직접 요약·분류·추출 등의 AI 기능을 구현 가능
  • The Brutalist Report의 native iOS client는 기사 요약을 Apple 로컬 모델 API로 온디바이스에서 생성해 서버 우회, 프롬프트·사용자 로그, 벤더 계정, 콘텐츠 보관 각주가 필요 없게 함
  • 로컬 모델은 클라우드 모델만큼 똑똑하지 않을 수 있지만, 요약·분류·추출·재작성·정규화 같은 데이터 변환 작업에는 충분할 수 있으며 클라우드 모델은 정말 필요할 때만 써야 함

클라우드 AI 의존의 문제점

  • 개발자들이 앱 기능에 OpenAI나 Anthropic API 호출을 무분별하게 추가하는 트렌드가 확산 중
  • 이런 방식은 소프트웨어를 취약하고, 프라이버시를 침해하며, 근본적으로 불안정하게 만듦
    • 서버 장애나 신용카드 만료 시 앱이 작동을 멈추는 구조
  • 사용자 콘텐츠를 서드파티 AI 제공자에게 스트리밍하는 순간, 제품의 성격 자체가 변함
    • 데이터 보존, 동의, 감사, 유출, 정부 요청, 학습 데이터 사용 등의 문제가 수반
  • 네트워크 상태, 외부 벤더 가동률, rate limit, 계정 결제, 자체 백엔드 상태에 모두 의존하게 되어 스택이 복잡해짐
  • 결과적으로 UX 기능 하나가 비용이 발생하는 분산 시스템으로 바뀌는 셈임
  • 로컬에서 처리 가능한 기능을 굳이 클라우드로 보내는 것은 자충수

로컬 디바이스 활용의 당위성

  • 현재 주머니 속 기기의 실리콘은 10년 전과 비교할 수 없을 만큼 빠르며, 전용 Neural Engine이 대부분 유휴 상태
    • 그 사이 버지니아 서버 팜에서 JSON 응답을 기다리는 구조는 비합리적
  • “AI everywhere”가 목표가 아니라 유용한 소프트웨어가 목표여야 함
  • 로컬에서 처리 가능한 기능이라면, 외부 의존성을 선택하는 것 자체가 불필요한 피해

The Brutalist Report의 온디바이스 요약

  • The Brutalist Report는 1990년대 스타일 웹에서 영감을 받은 뉴스 애그리게이터 서비스임
  • 최근 native iOS client를 만들면서 고밀도 뉴스 읽기 경험을 유지하는 것을 설계 목표로 삼음
  • iOS 클라이언트는 강한 대비의 헤드라인 목록, 웹을 읽기 어렵게 만든 요소를 제거하는 리더 모드, 선택적으로 기사를 요약하는 “intelligence” 뷰를 포함함
  • 핵심은 요약이 Apple의 로컬 모델 API를 통해 온디바이스에서 생성된다는 점임
  • 서버 우회, 프롬프트나 사용자 로그, 벤더 계정, “콘텐츠를 30일 보관한다”는 식의 각주가 필요 없음
  • 모든 AI 사용이 서버 측에서 일어난다고 받아들이는 흐름이 너무 자연스러워졌고, 이를 되돌리려면 업계 차원의 노력이 필요함
  • 일부 사용 사례는 클라우드 호스팅 모델만 제공할 수 있는 지능을 요구하지만, 모든 사용 사례가 그런 것은 아니므로 신중한 판단이 필요함

Apple 생태계의 로컬 AI 도구

  • Apple 생태계에서는 최근 1년 동안 개발자가 내장 로컬 AI 모델을 쉽게 활용할 수 있도록 투자가 이뤄짐
  • 기본 흐름은 FoundationModels를 가져오고, SystemLanguageModel.default의 사용 가능 여부를 확인한 뒤, LanguageModelSession으로 프롬프트를 구성해 응답을 받는 방식임
    import FoundationModels  
    
    let model = SystemLanguageModel.default  
    guard model.availability == .available else { return }  
    
    let session = LanguageModelSession {  
      """  
      Provide a brutalist, information-dense summary in Markdown format.  
      - Use **bold** for key concepts.  
      - Use bullet points for facts.  
      - No fluff. Just facts.  
      """  
    }  
    
    let response = try await session.respond(options: .init(maximumResponseTokens: 1_000)) {  
      articleText  
    }  
    
    let markdown = response.content  
    
  • 긴 콘텐츠는 일반 텍스트를 약 1만 자 단위로 나누고, 각 청크에서 간결한 “facts only” 노트를 만든 뒤, 두 번째 패스로 최종 요약을 결합할 수 있음
  • 이런 작업은 로컬 모델에 잘 맞음
    • 입력 데이터는 사용자가 이미 읽고 있는 콘텐츠라서 기기에 있음
    • 출력은 가벼움
    • 빠르고 비공개로 처리됨
    • 사용자가 방금 불러온 페이지를 요약하는 작업이지, 세계 지식을 새로 만들어내는 작업이 아니므로 초인적 수준의 지능이 필요하지 않음
  • 로컬 AI는 모델의 역할이 우주 전체를 검색하는 것이 아니라, 사용자가 소유한 데이터를 변환하는 일일 때 빛남

신뢰를 만드는 방식

  • 이메일 요약, 노트에서 할 일 추출, 문서 분류 같은 AI 기능은 사람들이 원하지만 신뢰하지 못하는 기능에 속함
  • 일반적인 클라우드 방식은 이런 기능을 모두 “데이터를 서버로 보내도 괜찮은지”를 묻는 신뢰 문제로 바꿈
  • 로컬 AI는 이미 기기에 있는 데이터를 그 자리에서 처리하게 해 이 구조를 바꿈
  • 사용자 신뢰는 2,000단어짜리 개인정보 처리방침으로 만들어지지 않음
  • 애초에 그런 개인정보 처리방침이 필요 없도록 만드는 방식이 신뢰를 만듦

구조화된 출력과 타입 기반 AI

  • Apple이 최근 잘한 선택 중 하나는 “AI output”을 구조 없는 텍스트 덩어리에서 타입이 있는 데이터로 옮긴 점임
  • “모델에게 JSON을 요청하고 잘 나오길 바라는” 방식 대신, 원하는 결과를 나타내는 Swift struct를 정의하는 방식이 더 새롭고 나은 패턴임
  • 각 필드에 자연어 가이드를 주고, 모델에게 해당 타입의 인스턴스를 생성하게 함
    import FoundationModels  
    
    @Generable  
    struct ArticleIntel {  
      @Guide(description: "One sentence. No hype.") var tldr: String  
      @Guide(description: "3–7 bullets. Facts only.") var bullets: [String]  
      @Guide(description: "Comma-separated keywords.") var keywords: [String]  
    }  
    
    let session = LanguageModelSession()  
    let response = try await session.respond(  
      to: "Extract structured notes from the article.",  
      generating: ArticleIntel.self  
    ) {  
      articleText  
    }  
    
    let intel = response.content  
    
  • 이 방식이면 UI가 Markdown의 불릿을 긁어내거나 모델이 JSON 스키마를 기억했기를 기대할 필요가 없음
  • 앱은 실제 필드를 가진 실제 타입을 받아 일관되게 렌더링할 수 있음
  • 앱이 실제로 사용할 수 있는 구조화된 출력을 만들며, 이 과정 전체가 로컬에서 실행됨
  • 단순히 편리한 인터페이스가 아니라 엔지니어링 품질 개선
  • 로컬 퍼스트 앱에서 “AI는 신기한 기능”이 아닌 “신뢰할 수 있는 서브시스템” 으로 기능하게 만드는 차이가 됨

“로컬 모델은 덜 똑똑하다”에 대한 반론

  • 로컬 모델이 클라우드 모델만큼 똑똑하지 않다는 점은 맞지만, 대부분의 앱 기능에는 해당하지 않음
  • 대부분의 기능이 요구하는 것은 셰익스피어를 쓰거나 양자역학을 설명하는 능력이 아니라, 요약, 분류, 추출, 재작성, 정규화 중 하나를 안정적으로 수행하는 능력
  • 이런 작업에 로컬 모델은 충분히 뛰어남
  • 로컬 모델을 인터넷 전체의 대체물로 쓰면 실망하지만, 앱 내부의 “데이터 변환기” 로 사용하면 왜 서버에 보냈는지 의문이 들 정도
  • 클라우드 모델은 진짜 필요할 때만 사용하고, 사용자 데이터는 제자리에 둬야 함
  • AI를 사용할 때 채팅 박스를 붙이는 것이 아니라, 타입 출력과 예측 가능한 동작을 갖춘 실제 서브시스템으로 활용해야 함

프라이버시와 신뢰 구축

  • 이메일 요약, 노트에서 액션 아이템 추출, 문서 분류 등 사람들이 원하지만 신뢰하지 않는 AI 기능이 다수 존재
  • 클라우드 방식은 이 모든 것을 신뢰 실험으로 전환: “데이터를 서버로 보내주세요, 잘 다루겠습니다”
  • 로컬 AI는 이를 근본적으로 바꿈 — 기기에 이미 데이터가 있고, 기기에서 바로 처리
  • 2,000단어짜리 개인정보 보호정책을 작성해서가 아니라, 애초에 그런 정책이 필요 없는 구조로 신뢰 구축

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

Loading

13 5월 2026

[인공지능 기술] [태평로] AI가 끊어선 안 될 경험의 축적

[인공지능 기술] [태평로] AI가 끊어선 안 될 경험의 축적

[태평로] AI가 끊어선 안 될 경험의 축적

김승범 기자입력 2026. 5. 11. 23:41수정 2026. 5. 11. 23:47
AI 확산으로 청년 일자리 감소
젊은이들이 실무 경험 못 쌓으면
고령화 속에 산업현장 허리 끊겨
사람·기술 공존할 구조 갖춰야

4월 20일 서울 마포구 서울서부고용복지플러스센터에서 구직자가 상담을 기다리고 있다. /뉴스1

2023년 아빈드 크리슈나 IBM 최고경영자는 5년간 7800명의 일자리를 AI(인공지능)로 대체하겠다는 계획을 내놨다. 대대적인 인력 감축과 채용 축소의 신호탄으로 여겨졌다. 하지만 지난 2월 IBM은 올해 미국 내 신입 사원 채용 규모를 3배로 늘리겠다고 발표했다. 니클 라모로 IBM 최고인사책임자는 “신입 채용에 대한 투자를 계속하지 않으면 3~5년 후에는 인재 공급망이 붕괴하고 인재 풀이 고갈될 것”이라고 했다. 단순 업무를 AI가 처리하더라도 사람을 뽑아 키우지 않으면 장차 책임자급 인재 수급에 차질이 생길 수 있다는 IBM 내 위기감이 반영된 것이라는 분석이 나왔다.

세계경제포럼(WEF)이 3월 공개한 AI 관련 분석에도 이와 비슷한 문제의식이 깔려 있다. 이에 따르면, 최근 18개월간 미국 내 신입 채용 공고가 35% 줄었는데 주된 원인은 AI였다. 그런데 기업이 AI 도입으로 신입 채용을 줄여 얻는 단기적 효율이 실상은 장기적인 위험을 가리는 것에 불과하다고 했다. 신규 인력 유입 시스템이 제대로 작동하지 않으면 인재 육성 체계의 균열, 지식 전수의 중단, 조직 문화 쇄신 동력의 약화 등 다양한 부작용이 나타나고 기업이 AI 혁신을 통해 기대했던 미래 역시 실현되기 어려울 수 있다는 것이다.

해외에서는 AI 확산에 따른 인적 자원 공백 위험을 이토록 고민하는데 우리는 어떤가. 어느 조직이든 사람이 성장하고 숙련되는 과정은 크게 다르지 않다. 신입 직원은 오랜 기간에 걸친 학습과 훈련, 시행착오와 실전 경험을 통해 전문가로 거듭난다. 이런 축적의 시간을 지나며 중견의 단계에 올라서고, 조직의 중추를 담당하는 핵심 인력으로 자리 잡는다. 조직은 이 같은 인적 자원의 선순환을 동력으로 삼아 지속된다. AI가 신규 인재 유입의 통로를 봉쇄한다면 그 결과는 불 보듯 뻔하다. 인적 자본의 축적을 가로막고 조직의 내재 역량은 결국 고갈될 것이다.

이는 한국 산업 구조상 더 치명적인 문제일 수 있다. 경직된 고용 제도로 해고가 어려운 우리나라에서는 AI로 인한 일자리 충격이 주로 신규 채용의 문을 닫는 방식으로 나타나고 있다. 기존 직원을 내보내지 못하니 비용과 효율성을 따져 AI 활용은 늘리되 새로 사람을 뽑지는 않는 것이다. AI 전환의 비용을 청년들이 다 부담하는 셈이다. 올해 1분기 청년 실업률은 5년 만에 가장 높았다. 주력 산업 일자리가 줄어든 가운데, 전문직·IT 등 AI 확산에 따른 일자리 대체 효과가 큰 업종의 구직난이 겹친 결과다. 기회의 사다리가 끊긴 청년들은 계속 미숙련자로 남게 될 처지다.

이 상태가 방치되면, 우리 사회의 고령화가 가속화하는 가운데 10~20년 후 산업 현장의 허리가 끊어지게 된다. 가뜩이나 제조업 경쟁력이 떨어지는 상황에서 인력 구조의 질적 저하까지 맞물리는 최악의 시나리오에 직면하는 것이다. 특히 노하우 전수가 수직적으로 이루어지는 연공 서열 중심의 한국 기업 문화 특성상, 신입 사원의 부재는 조직의 핵심 자산인 현장 경험의 단절로 이어질 수 있다.

AI의 파고를 거스를 수는 없다. 관건은 사람과 기술이 공존하는 구조를 만드는 데 있다. 정부는 고용 제도를 유연하게 다듬는 한편 현장 경험의 단절을 메울 새로운 인재 양성 트랙을 구축해야 한다. 기업은 당장의 효율에만 매몰되지 말고 미래 인재를 육성하는 데 책임감을 가져야 한다. 노동계의 태도 변화도 절실하다. 일부 노조처럼 생산 현장의 AI 도입을 통제하겠다는 발상은 시대착오적이다. 기술을 막아 세우는 것으로는 일자리를 지켜낼 수 없다.

[출처] https://v.daum.net/v/20260511234115534?s=print_news

Loading

13 5월 2026

판교맨은 오늘도 성장 중입니다 – 판교에서 웃으며 버티는 사람들의 슬픈 농담

판교맨은 오늘도 성장 중입니다 – 판교에서 웃으며 버티는 사람들의 슬픈 농담

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

판교는 늘 미래를 이야기하는 도시다.
하지만 그 미래를 만드는 사람들의 하루는 의외로 소박하고, 반복적이며, 자주 외롭다.
잘 만든 서비스 뒤에는 아무도 기억하지 못하는 야근이 있고, 매끄러운 화면 뒤에는 수십 번의 수정이 있으며, “빠른 대응 감사합니다”라는 짧은 문장 뒤에는 누군가의 긴 하루가 숨어 있다.
《판교맨은 오늘도 성장 중입니다》은 바로 그 보이지 않는 하루들을 담은 콩트 모음집이다.
거창한 사건보다 작은 균열, 대단한 성공보다 미묘한 감정, 화려한 성장보다 “그래도 오늘은 조금 괜찮았다”는 마음을 따라간다.
이 책 속 인물들은 특별하지 않다.
그래서 더 오래 남는다.
회의실 이름은 근사하지만 공기는 건조한 회사, 퇴근 후에도 쉽게 끝나지 않는 하루, 회사 얘기를 하지 않기로 해놓고 결국 또 회사 얘기를 하게 되는 사람들.
그 익숙한 풍경 속에서 독자는 자기 마음의 일부를 발견하게 된다.
이 책은 직장생활의 고단함을 고발하기보다, 그 안에서 끝내 사라지지 않는 작은 온기를 보여준다.
지친 직장인에게는 공감이 되고, 아직 회사 생활을 잘 모르는 사람에게는 현실적인 감정의 풍경이 된다.
무너지지 않기 위해 오늘도 자기만의 방식으로 하루를 건너는 사람들에게, 이 책은 조용한 위로가 되어줄 것이다.

인물정보

저자(글) 지몬테

 

지몬테는 20여 년 동안 컴퓨터 개발자이자 공학자로 살아오며 코드와 회로, 네트워크 속에서 인간과 기술의 경계를 지켜봐 왔습니다. 영화와 게임, 그리고 별과 우주를 향한 상상을 바탕으로, 일상의 작은 균열 틈에서 시작되는 과학적 상상과 인간적인 이야기를 단편 SF로 풀어내고 있습니다. 현실적인 디테일 위에 미래의 가능성을 덧입혀, “조금은 가까운 미래”를 독자와 함께 탐사하는 이야기를 쓰고자 합니다.

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

 

 

 

 

 

Loading

3 5월 2026

[인공지능 개발자] 성공적인 바이브 코딩을 위해서는 AI가 명확하게 이해할 수 있는 기획서(PRD)가 필수

[인공지능 개발자] 성공적인 바이브 코딩을 위해서는 AI가 명확하게 이해할 수 있는 기획서(PRD)가 필수

바이브 코딩(Vibe Coding)은 AI(Claude, Cursor 등)를 활용하여 자연어 명령어(프롬프트)로 개발하는 방식입니다. 성공적인 바이브 코딩을 위해서는 AI가 명확하게 이해할 수 있는 기획서(PRD)가 필수적입니다.
다음은 바이브 코딩을 위한 핵심 기획서 구조와 작성 팁입니다.
 
1. 바이브 코딩 기획서 필수 구성요소
AI에게 컨텍스트를 정확히 전달하기 위해 아래 내용이 포함되어야 합니다:
  • PRD (Product Requirement Document): 왜 이 서비스를 만드는가? (목적, 대상, 핵심 가치)
  • 기능 정의서 (Functional Specs): 기능이 어떻게 작동하는가? (사용자 시나리오, 구체적인 동작 방식)
  • IA (Information Architecture) & 와이어프레임: 어디에 무엇이 있는가? (화면 구조도)
 
2. 기획서 작성 및 활용 루틴
  1. 초안 작성: Claude에게 요구사항을 말하여 기획서(PRD) 및 기술 명세서 작성을 맡깁니다.
  2. 구체화: 생성된 기획서를 바탕으로 시나리오 기반 기능 우선순위를 정리합니다.
  3. Task화: Cursor 등 IDE에서 TASK.md 파일을 생성하여 AI에게 할 일 리스트를 정리하게 합니다.
  4. 반복 개발: Task를 하나씩 AI와 대화하며 구현합니다.
 
3. 성공적인 바이브 코딩을 위한 팁
  • 기획 70%, 코딩 30%: 코딩부터 달려들지 말고, 구조를 충분히 설계해야 속도가 빨라집니다.
  • 환각(Hallucination) 방지: 추상적인 표현 대신 명확한 명사와 동사로 행동을 정의합니다.
  • 작게 시작하기: 처음부터 거대한 기능을 만들기보다, 단일 기능부터 완성해 나갑니다.
기획 단계에서 유저 시나리오(플로우)를 명확히 그리는 것이 가장 중요합니다.
 
 

Loading