人-ware : Forwards Veritas

예측 대상 정의: 사용자가 알고 싶은 것과 실제로 결정해야 하는 것 구분하기예측 기능을 만들 때 가장 먼저 해야 할 일은 모델을 고르는 것이 아닙니다.데이터를 모으는 것도 아닙니다.가장 먼저 해야 할 일은 무엇을 예측할 것인가를 정의하는 것입니다.그런데 이 질문은 생각보다 어렵습니다. 사용자가 말하는 “알고 싶은 것”과 실제로 업무에서 “결정해야 하는 것”이 항상 같지는 않기 때문입니다.예측 대상 정의의 핵심은 이 둘을 구분하는 데 있습니다.사용자가 알고 싶은 것 ≠ 사용자가 실제로 결정해야 하는 것이 차이를 구분하지 못하면 예측 기능은 흥미로운 숫자를 보여주지만, 실제 의사결정에는 도움이 되지 않는 기능이 될 수 있습니다.사용자가 알고 싶은 것사용자는 보통 자연스러운 언어로 질문합니다.월드컵 우승 확률..

예측 기능 성숙도 모델예측 기능은 한 번에 완성되지 않습니다.처음부터 완벽한 데이터 파이프라인, 정교한 모델, 실시간 재예측, 이력 관리, 시나리오 분석, 자동화된 운영 체계를 모두 갖추기는 어렵습니다. 대부분의 예측 기능은 작은 리포트나 분석 화면에서 시작해, 사용자의 질문을 따라 점진적으로 성숙합니다.Prediction-Driven Product Development Framework에서는 예측 기능의 성숙도를 다음과 같이 볼 수 있습니다.1단계. 리포트형 예측2단계. 대시보드형 예측3단계. 비교/이력형 예측4단계. 시나리오형 예측5단계. 운영 자동화형 예측 제품이 단계는 단순히 기술 수준을 나눈 것이 아닙니다.각 단계는 사용자가 예측을 어떻게 이해하고, 비교하고, 행동으로 연결할 수 있는지를 기준으..

예측 기반 제품 기능의 핵심 개념예측 기반 제품 기능을 설계할 때 가장 먼저 구분해야 하는 것이 있습니다.예측값, 의사결정, 사용자 행동, 운영 기준 시점입니다.이 네 가지는 서로 연결되어 있지만 같은 개념은 아닙니다. 예측 기능이 실패하는 많은 이유는 이 개념들을 구분하지 않고 “모델이 예측값을 내면 기능이 완성된다”고 생각하는 데서 시작됩니다.하지만 실제 제품에서는 예측값 하나만으로 사용자가 움직이지 않습니다.사용자는 예측값을 보고, 그 의미를 해석하고, 현재 상황과 비교하고, 판단한 뒤, 어떤 행동을 선택합니다. 그리고 이 모든 과정은 “언제 기준의 데이터인가”라는 운영 기준 시점 위에서 해석됩니다.예측값은 출발점일 뿐이다예측값은 모델이 만들어낸 결과입니다.예를 들어 월드컵 우승 확률 예측 기능이라..

개요Prediction-Driven Product Development Framework의 목적과 적용 범위AI 예측 모델을 만드는 일과, 그 예측 모델을 제품 기능으로 만드는 일은 다릅니다.모델을 만드는 일은 주로 “얼마나 잘 맞히는가”에 집중합니다.제품 기능을 만드는 일은 “사용자가 이 예측을 보고 어떤 판단을 할 수 있는가”에 집중합니다.Prediction-Driven Product Development Framework는 바로 이 차이에서 출발합니다.이 프레임워크의 목적은 예측 모델을 단순한 분석 결과나 대시보드 숫자가 아니라, 사용자의 의사결정을 돕는 제품 기능으로 설계하고 발전시키는 것입니다.왜 이 프레임워크가 필요한가많은 AI 프로젝트는 모델 개발 단계에서는 꽤 성공적으로 보입니다.데이터를 ..

서문왜 예측 모델은 제품 기능으로 다시 설계되어야 하는가AI 예측 모델을 만든다고 하면 보통 먼저 떠올리는 것은 데이터, 알고리즘, 정확도입니다.어떤 데이터를 모을 것인가.어떤 모델을 쓸 것인가.정확도는 얼마나 나오는가.실제 결과와 얼마나 잘 맞는가.물론 이 질문들은 중요합니다. 예측 기능의 출발점에는 언제나 데이터와 모델이 있습니다. 하지만 예측 모델이 실제 제품 안에서 사용되는 순간, 문제의 중심은 달라집니다.중요한 것은 더 이상 모델이 어떤 숫자를 냈는가만이 아닙니다.사용자가 그 숫자를 보고 무엇을 판단할 수 있는가가 더 중요해집니다.사용자는 확률값 하나를 보기 위해 예측 기능을 쓰지 않는다사용자는 예측 기능을 사용할 때 단순히 숫자 하나를 보고 싶어 하지 않습니다.예를 들어 월드컵 우승 확률 예측..

AI Agent라는 개념은 인공지능 분야의 일반적인 프레임워크로, 특히 Stuart Russell과 Peter Norvig의 저서 Artificial Intelligence: A Modern Approach에서 다음과 같이 정의하고 있다."An agent is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through actuators."(Agent는 센서를 통해 환경을 인식하고, 액추에어터를 통해 환경에 영향을 주는 존재이다.)이 정의는 물리적인 로봇 뿐만 아니라, 소프트웨어 에이전트(예: 검색 봇, 게임, AI, 추천시스템), 자율주행차, 가상 비서 (예:..

API-first 방식은 인터넷과 디지털 기술 발전과 밀접하게 연결되어 있다. 2000년대 초반에 웹 서비스와 소프트웨어 애플리케이션은 점점 더 복잡해지고, 다양한 플랫폼 및 디바이스 간의 연동이 필수적이 되면서 개발 프로세스와 아키텍처에 새로운 접근 방식이 필요하게 되었다. API-first 필요성 웹서비스와 REST: 2000년대 초, 웹 서비스가 등장하면서 소프트웨어 컴포넌트들 간의 상호작용을 위한 표준화된 방법이 필요하게 되었다. REST(Representational State Transfer) 아키텍처 스타일의 등장은 이러한 요구를 충족시켰고, 간단하고 표준화된 방법으로 다른 시스템과 통신할 수 있는 API 의 기반이 되었다. 클라우드 컴퓨팅의 부상: 2000년대 중반, 클라우드 컴퓨팅의 부상..

소프트웨어 아키텍트는 복잡한 시스템의 설계와 구현을 지휘하는 핵심 인물로, 프로젝트의 기술적 비전을 설정하고 구현 팀이 이를 따를 수 있도록 가이드한다. 이들은 고수준의 의사결정을 내리며, 시스템의 성능, 안정성, 확장성을 보장하는 데 핵심적인 역할을 한다. 전통적으로, 소프트웨어 아키텍트는 프로젝트의 성공에 있어 불가결한 요소로 여겨져 왔다. 그러나, 최근 기술의 급속한 발전과 산업의 변화는 이 역할을 근본적으로 변화시키고 있다. 클라우드 서비스의 보편화, 데브옵스 문화의 확산, 그리고 민첩한 개발 방법론의 채택은 소프트웨어 개발 과정을 더욱 민첩하고 통합적으로 만들었다. 이러한 변화는 아키텍트의 전통적인 역할이 사라지거나, 적어도 이전과는 매우 다른 형태로 변모하고 있음을 시사한다. 이 글에서는 소프..

역사는 자주 반복되며, 이러한 패턴은 IT 역사에서도 명확하게 관찰된다. 특히 국내 상황을 예로 들면, 과거와 현재를 잇는 놀라운 유사성을 발견할 수 있다. 한국은 20세기 중반까지만 해도 경제적으로 낙후된 국가였지만, 이후 눈부신 경제 발전을 이루며 세계적인 IT 강국으로 자리매김했다. 이러한 변화는 한국 역사상 가장 혁신적이고 급진적인 발전 중 하나로, IT 역사에서도 비슷한 순간들이 발견된다. 한국의 경제 발전은 60년대의 경제 개발 계획을 시작으로, 집중적인 산업화와 기술 혁신을 통해 이루어졌다. 이는 IT 분야에서도 유사하게 발견된다. 예를 들어, 90년대 후반 인터넷의 상업화와 함께 시작된 디지털 혁명은 전 세계적으로 비즈니스, 커뮤니케이션, 엔터테인먼트의 방식을 근본적으로 변화시켰다. 한국은..

시스템을 만들때에 사용자(user)의 요구를 충족시키는 것이 제일 목적이라고 말한다. 보통 사용자라고 함은 시스템이 제공하는 서비스를 직접 사용해서 원하는 것(가치)을 얻는 행위를 하는 액터를 일컫는다. 이러한 사용자는 불특정 다수가 될 수도 있겠지만, 업무 시스템과 같이 특정 업무를 위한 시스템의 경우에는 명확한 업무 사용자가 정의된다. 어떠한 사용자이든 이들은 시스템을 직접 다루거나 처리하는 형태가 아닌 그저 수동적으로 시스템이 일방적으로 제공하는 서비스를 사용할 뿐이다. 하지만, 최근의 시스템들은 사용자들에게 어느정도는 능동적인 행위를 부여하는 형태로 서비스를 제공하기 시작한다. 예전에는 HTML을 그저 브라우저를 통해 화면에 보여지는 요소를 만드는 형태로만 쳐다보았다면, 지금의 사용자들은 직접 자..