기업 AI 추진이 막히는 이유, 그리고 CIO의 돌파구

지난 1년 동안 AI 프로젝트를 추진했지만 기대에 미치지 못하거나 완전히 실패한 CIO는 결코 드물지 않다. AI 프로젝트 투자는 급증하고 있지만, 가트너 조사에 따르면 기업의 거의 절반은 여전히 실질적인 비즈니스 가치를 입증하는 데 어려움을 겪고 있다. 리전스은행 최고데이터·애널리틱스책임자(CDAO) 매너브 미스라는 “사람들이 비현실적인 기대를 갖고 뛰어들었고, 가장 큰 실망도 바로 거기서 비롯됐다”라고 말했다. 그는 다수의 현업 전문가들과 마찬가지로 “문제는 기술 자체가 아니라 이를 둘러싼 요소들”이라고 지적했다. 실제로 조직적·운영적·구조적 실패가 프로젝트 전 과정에서 발목을 잡고 있다는 설명이다.

CIO 조직은 모델 선택이나 플랫폼 아키텍처, 데이터 파이프라인 측면에서는 명확한 전략을 갖추고 있을 수 있다. 하지만 실제로는 잘못된 프로젝트를 선택하거나, 비즈니스 성과와 성공 지표를 충분히 구체적으로 정의하지 못하거나, 현업 리더와의 협업이 부족하거나, 사용자들을 초기 단계부터 참여시키지 못하는 경우가 많다.

AI 프로젝트는 사용자들의 불안과 의구심에도 직면한다. 금융 기술 기업 잭헨리(Jack Henry)의 최고데이터책임자(CDO) 키스 풀턴(Keith Fulton)은 “과거에는 해외 인력 대체자를 교육하라는 요구를 받았고, 이제는 우리를 대체할 AI를 훈련시키는 상황이 됐다”라고 말했다.

하지만 적어도 현재 시점에서 LLM은 생산성을 높일 수는 있어도 여전히 인간의 검토와 검증이 필요하다. 풀턴은 “AI는 뛰어난 인턴 같지만 반드시 가이드가 필요하다”라고 설명했다.

콜로니얼 파이프라인 전 최고기술·데이터책임자였던 아프신 탈라사즈는 “과거의 플레이북은 더 이상 효과적이지 않다”라며 “세부 사항까지 깊이 파고들고, 무엇을 하려는지 명확히 정의하며, 기대치를 분명히 해야 한다”라고 말했다.

이 같은 기본적인 실수가 다음 AI 프로젝트의 치명적인 약점이 되어서는 안 된다는 지적이다.

AI 프로젝트는 CIO 혼자 이끌 수 없다

FTI컨설팅 AI·디지털전환 부문 총괄인 수밋 굽타(Sumeet Gupta) 수석매니징디렉터는 CIO 혼자 AI 센터오브엑설런스(CoE)를 운영하도록 하는 것은 거의 성공 공식이 아니라고 지적했다.

그는 “CIO는 종종 플랫폼 중심 시각으로 프로젝트를 추진하게 되는데, 실제 문제는 거기에 있지 않다”라며 “AI 프로젝트는 기술 프로젝트가 아니라 AI를 활용해 원하는 비즈니스 성과를 달성하는 사업 프로젝트”라고 설명했다.

이어 “반드시 적절한 현업 책임자와 공동으로 프로젝트를 이끌어야 하며, 근본적인 비즈니스 문제는 바로 그 과정에서 해결된다”라고 덧붙였다.

풀턴 역시 AI 프로젝트는 비즈니스 조직이 주도해야 한다고 강조했다.

그는 “현업 리더가 먼저 기회를 발굴하고, 이후 AI 전문가들이 그 가능성을 검토해 우선순위를 정해야 한다”라며 “이 과정에서 컨설턴트에 지나치게 의존해서는 안 된다”라고 말했다. 이어 “조직 내부에서 신중한 시각을 유지해줄 파트너가 필요하다”라고 덧붙였다.

풀턴은 이 같은 교훈을 일찍 경험했다고 설명했다.

그는 “유일하게 실패한 실험은 1년 전 진행한 컨설팅 프로젝트였다”라며 “재무 부문에서 AI 활용 사례를 찾기 위해 진행됐지만 결국 당시 기술 수준으로는 유의미한 사례를 발굴하지 못했다”라고 말했다.

반면 리전스은행의 미스라는 비즈니스 출신 제품 관리자(Product Manager)를 포함한 팀을 운영하고 있다. 이들은 현업 요구를 명확히 이해하고 있으며, 사업 부문 리더와 함께 실질적인 기회를 발굴한다.

미스라는 “가치를 실현하기 위해 적극적으로 투자할 의지가 있는 임원 스폰서가 필요하다”라며 “비즈니스 책임자 역시 성공이 실제로 어떤 모습인지 명확히 정의하고 있어야 한다”라고 말했다.

성공 지표는 현업이 정해야 한다

CIO는 프로젝트 초기 단계부터 현업 리더와 함께 어떤 지표가 원하는 비즈니스 성과를 의미하는지 합의해야 한다. 또한 비즈니스와 IT 조직은 해당 지표를 분기별로 함께 점검해야 한다.

FTI컨설팅의 수밋 굽타는 “해당 사업의 손익(P&L)을 책임지는 사람이 성과 측정의 책임도 져야 하며, 어떤 지표를 사용할지도 직접 결정해야 한다”라고 말했다.

그는 “측정 방식에 대해서는 CIO가 의견을 제시할 수 있지만, 손익에 연결되는 실제 비즈니스 KPI는 반드시 사업 책임자가 정해야 한다”라고 설명했다.

다만 프로젝트 성공을 위해서는 단순한 경영진의 지지만으로는 충분하지 않다.

사용자 참여 없이는 AI 도입도 어렵다

아무리 잘 설계된 IT 프로젝트라도 직원들이 실제로 사용하지 않으면 의미가 없다. 특히 AI 프로젝트에서는 이런 문제가 더욱 두드러진다.

굽타는 한 기업 사례를 언급하며 “AI 모델용 래퍼(wrapper)를 개발하는 데 투자했지만 결국 차별화된 비즈니스 가치를 만들지 못했다”라고 말했다.

그는 “AI CoE 팀은 흥미로운 프로젝트라고 생각했지만, 더 넓은 사용자 조직을 논의 과정에 참여시키지 않았다”라고 설명했다.

풀턴은 AI에 대한 두려움과 냉소주의도 여전히 크다고 지적했다.

그는 “사람들이 AI를 대체자가 아니라 업무를 돕는 도구로 인식하도록 만드는 조직 변화관리(change management)가 매우 큰 과제”라며 “AI가 추천 결과를 만들 수는 있지만, 고객에게 전달하기 전 인간의 검토는 필수적인 검증 단계”라고 말했다.

이 때문에 사용자들은 프로젝트 초기부터 모든 단계에 참여해야 한다는 설명이다.

굽타는 “기술팀이 복잡한 AI 제품을 만들었지만 현업 사용자들이 프로세스 자체에 참여하지 않았기 때문에 실제로는 사용되지 않은 사례를 수없이 봤다”라며 “특히 기술 기반 혁신 프로젝트에서는 절대 성공할 수 없는 방식”이라고 말했다.

리전스은행의 미스라도 초기 공감대를 충분히 확보하지 못해 프로젝트 배포가 지연된 사례를 언급했다.

그는 “누군가 ‘이게 제대로 작동할지 모르겠다’라고 말하기 시작하면 의심이 확산되는 악순환이 시작된다”라고 설명했다.

그는 초기 지지자를 발굴·지원하고, 동료들을 위한 워크숍을 운영하며, 분기별 사용률과 도입률을 점검하는 단계적 배포 전략을 권고했다.

사용자를 초기 단계부터 참여시키는 또 다른 장점은 변화가 점진적으로 진행되기 때문에 조직이 느끼는 부담이 줄어든다는 점이다.

잭헨리는 특히 사용자 코칭에 큰 비중을 두고 있다. 풀턴은 “10명 규모의 전담팀이 사용자들의 AI 도구 활용을 지원하고 있다”라며 “올바르게 안내하면 충분히 사용자들을 설득할 수 있지만, 적합하지 않은 경우 억지로 강요하지는 않는다”라고 말했다.

굽타는 결국 사용자들을 변화 과정에 참여시키고 책임감을 부여해야 한다고 강조했다.

그는 “AI가 워크플로우에 어떤 영향을 미칠지, 필요한 변화는 어떻게 해결할지에 대한 논의 과정에 사용자들을 반드시 포함시켜야 한다”라고 말했다.

워크플로우와 변화관리 영향까지 함께 검토해야

AI를 활용한 자동화를 추진하기 전에 CIO와 주요 이해관계자들은 현재와 미래의 워크플로우를 함께 검토해야 한다. 특히 생산성과 직원들의 업무 방식에 어떤 영향을 미칠지까지 고려해야 한다.

FTI컨설팅의 수밋 굽타는 “워크플로우 재설계와 변화관리(change management)는 항상 함께 가야 한다”라고 말했다.

그는 “실제로 한 기업에서는 AI 제품을 도입했지만 변화관리를 제대로 하지 않아 오랫동안 활용되지 못한 사례가 있었다”라고 설명했다.

해당 기업은 핵심 업무 영역에서 대규모 수작업을 줄이고 프로세스 정확도를 높이기 위해 비교적 복잡한 에이전틱 AI 워크플로우를 설계했다. 하지만 이를 제대로 정착시키기 위해서는 인력 운영모델과 조직 변화관리 문제를 함께 해결해야 했다.

굽타는 “이 작업이 적절한 시점에 이뤄지지 않았다”라며 “AI 워크플로우 자체는 매우 잘 설계되고 개발됐지만 실제 현업에서는 수개월 동안 제대로 활용되지 못했다”라고 말했다.

그는 모든 프로젝트에 이른바 ‘퍼스트 프린서플(first principles)’ 접근 방식을 적용한다고 설명했다. 우선 워크플로우를 통해 해결하려는 문제가 무엇인지, 원하는 결과는 무엇인지, 필요한 입력 데이터는 무엇인지를 정의한 뒤 AI 환경에서 미래 프로세스가 어떻게 작동할지 다시 설계해야 한다는 의미다.

그는 “이런 제약 조건을 기반으로 설계해야 한다”라며 “AI 시대에 가장 큰 문제는 기존 방식을 재창조하거나 재구상하려는 노력이 부족하다는 점”이라고 지적했다. 이를 위해서는 현업 리더와 사용자 모두의 참여가 필요하다는 설명이다.

반면 잭헨리의 키스 풀턴은 처음부터 모든 프로세스를 전면 재설계하는 방식에는 다소 신중한 입장을 보였다.

그는 “업무 프로세스 혁신(BPR)은 지난 20년 동안 계속 논의돼 왔지만 기대만큼 성과를 내지는 못했다”라며 “비용이 많이 들고 대기업에는 수백, 수천 개의 프로세스가 존재하기 때문”이라고 설명했다.

현재 에이전틱 AI는 복잡한 프로세스보다는 비교적 단순한 업무 프로세스에서 더 효과적으로 작동하고 있다는 분석이다.

다만 AI 에이전트는 점차 비즈니스 프로세스를 이해하고 최적화하는 방향으로 발전하고 있다.

풀턴은 “과거에는 RPA 도구로 워크플로우 다이어그램을 직접 설계해야 했지만, 이제는 LLM에 필요한 절차를 설명하면 스스로 워크플로우를 구성하기 시작한다”라고 말했다.

그러나 인간의 세밀한 설정 없이 복잡한 다단계 엔터프라이즈 워크플로우를 자율적으로 최적화할 수 있는 AI 에이전트는 아직 초기 단계에 머물러 있으며, 대규모 환경에서 충분히 검증되지 않았다고 그는 덧붙였다.

한편 아무리 의도가 좋은 워크플로우 설계와 조직 변화관리 계획이라도 데이터 요구사항에 대한 정확한 이해가 없다면 제대로 작동하기 어렵다는 지적도 나온다.

데이터 준비 부담이 프로젝트를 마비시킨다

AI 프로젝트를 시작하기 전에 모든 데이터를 완벽하게 준비해야 한다는 통념은 오히려 프로젝트 추진 자체를 가로막을 수 있다.

FTI컨설팅의 수밋 굽타는 “많은 기업이 데이터가 완벽하지 않으면 AI가 제대로 작동하지 않을 것이라고 생각한다”라고 말했다. 하지만 모든 프로젝트가 정제된 고품질 데이터를 요구하는 것은 아니라는 설명이다.

그는 “기업들은 실제 사용 사례와는 무관한 데이터 문제에 지나치게 집착하다 프로젝트를 지연시키는 경우가 많다”라고 지적했다.

잭헨리의 키스 풀턴 역시 “데이터는 머신러닝 모델에는 매우 중요한 요소지만 대부분의 거대언어모델(LLM) 프로젝트에서는 상대적으로 덜 중요하다”라고 말했다.

다만 복잡한 예측 모델이나 고객 단위 개인화, 영업 리드 스코어링 같은 프로젝트에서는 데이터 중요성이 커진다고 설명했다.

이와 관련해 리전스은행의 매너브 미스라는 “그런 경우에는 프로젝트에 실제로 필요한 핵심 데이터가 무엇인지 먼저 식별한 뒤 그 부분에만 집중해야 한다”라고 조언했다.

그는 “AI 기반 데이터 정제·통합·준비 도구를 활용하면 데이터 문제를 훨씬 쉽게 해결할 수 있다”라고 덧붙였다.

반면 가트너의 아비바 라이탄(Avivah Litan) VP 겸 수석 애널리스트는 실제로 우려해야 할 데이터 문제도 적지 않다고 지적했다.

그는 데이터 품질 문제와 메타데이터·데이터 계보(lineage) 정보 부족이 규제 준수와 설명 가능성, 규제기관 보고를 어렵게 만들 수 있다고 설명했다. 또한 데이터 사일로와 미성숙한 메타데이터 관리 체계 역시 규제 대응 준비를 가로막는 주요 요인이라고 덧붙였다.

데이터 준비 부담이 프로젝트를 마비시킨다

AI 프로젝트를 시작하기 전에 모든 데이터를 완벽하게 준비해야 한다는 통념은 오히려 프로젝트 자체를 가로막는 요인이 될 수 있다.

FTI컨설팅의 수밋 굽타는 “많은 기업이 데이터가 충분하지 않으면 AI가 제대로 작동하지 않을 것이라고 생각한다”라고 말했다. 하지만 모든 프로젝트가 완벽하게 정제된 데이터를 필요로 하는 것은 아니라는 설명이다.

그는 “기업들이 실제 사용 사례와는 무관한 데이터 문제에 지나치게 집착하다 프로젝트 추진 자체가 멈춰버리는 경우가 많다”라고 지적했다.

잭헨리의 키스 풀턴 역시 “데이터는 머신러닝 모델에서는 매우 중요한 요소지만 대부분의 거대언어모델(LLM) 프로젝트에서는 상대적으로 덜 중요하다”라고 말했다.

다만 복잡한 예측 모델이나 고객 단위 개인화, 영업 리드 스코어링 같은 프로젝트에서는 데이터 중요성이 커진다고 설명했다.

리전스은행의 매너브 미스라는 “그런 경우에는 프로젝트에 실제로 필요한 핵심 데이터가 무엇인지 먼저 식별한 뒤 그 부분에만 집중해야 한다”라고 조언했다.

그는 “AI 기반 데이터 정제·통합·준비 도구를 활용하면 데이터 문제를 훨씬 쉽게 해결할 수 있다”라고 덧붙였다.

반면 가트너의 아비바 라이탄(Avivah Litan) VP 겸 수석 애널리스트는 실제로 우려해야 할 데이터 문제 역시 적지 않다고 지적했다.

그는 데이터 품질 문제와 메타데이터·데이터 계보(lineage) 정보 부족이 규제 준수와 설명 가능성, 규제기관 보고를 어렵게 만들 수 있다고 설명했다. 또한 데이터 사일로와 미성숙한 메타데이터 관리 체계 역시 규제 대응 준비를 가로막는 주요 요인이라고 덧붙였다.

AI는 똑똑하지만 항상 신뢰할 수 있는 것은 아니다

아프신 탈라사즈는 AI 오케스트레이션과 관측 가능성(observability) 측면에서 거버넌스가 매우 중요하다고 강조했다.

그는 “AI 에이전트는 의도하지 않은 행동을 할 수 있으며, 이를 추적하고 가시화할 수 있어야 한다”라고 말했다.

잭헨리의 키스 풀턴은 기업들이 LLM에 지나치게 많은 역할을 기대하고 검증 절차 없이 신뢰하는 것이 대형 실패의 근본 원인이라고 지적했다.

그는 “LLM은 예상치 못한 실수를 하기도 하고, 어리석은 오류를 범하기도 하며, 특정 산업이나 업무 영역에 대한 맥락 이해도 부족하다”라고 설명했다.

이어 “출력 결과를 평가할 때 단순한 ‘똑똑함’을 실제 경험과 맥락 이해로 착각해서는 안 된다”라며 “모든 AI 결과물은 실제 운영 환경에 적용하기 전에 반드시 인간의 검토를 거쳐야 한다”라고 강조했다.

보다 복잡한 작업에서는 LLM이 처리 가능한 토큰 윈도우를 넘어서는 맥락을 요구받을 경우 방향을 잃는 문제도 발생할 수 있다.

풀턴은 “그 시점이 되면 정보를 억지로 압축하게 되고, 결국 LLM이 흐름을 잃으면서 환각(hallucination)을 일으키기 시작한다”라고 설명했다.

그는 “LLM은 다양한 작업을 수행할 수 있지만, 작업 규모가 커질수록 오히려 맥락을 놓치기 쉽다”라며 “실제 운영 경험상 장시간 자율적으로 실행되는 프로세스보다 짧고 범위가 제한된 작업이 훨씬 더 안정적인 결과를 제공한다”라고 말했다.

이에 따라 잭헨리는 AI 활용 전략 역시 짧고 제한적인 업무 중심으로 설계하고 있다고 덧붙였다.

예상치 못한 실패는 승인되지 않은 비공식 프로젝트, 이른바 ‘섀도우 AI(shadow AI)’에서도 발생할 수 있다.

탈라사즈는 “섀도우 AI의 가장 큰 문제는 누군가 거버넌스 없이 핵심 업무 프로세스용 AI를 구축하는 것”이라며 “문제가 발생하거나 시스템이 깨졌을 때 이를 추적하거나 관찰할 수 없기 때문에 조직 전체의 지속 가능성과 리스크 관리에 큰 부담이 된다”라고 말했다.

한편 가트너 조사에 따르면 기업의 69%는 직원들이 금지된 AI 도구를 사용하고 있다고 의심하거나 실제 증거를 확보한 상태다.

잭헨리는 이를 최소화하기 위해 의무 교육과 승인 절차 기반의 강력한 데이터 거버넌스를 운영하고 있다.

회사는 공개 챗봇과 같은 승인되지 않은 도구 사용을 엄격히 금지하고 있으며, 직원들이 외부 서비스를 찾지 않도록 100개 이상의 AI 기반 애플리케이션을 내부에 제공하고 있다고 설명했다.

너무 많은 PoC가 중도에 사라진다

아프신 탈라사즈는 파일럿 프로젝트가 실패하는 주요 원인 중 하나로 프로젝트 수행 조직과 기대를 가진 조직 간의 인식 차이를 꼽았다.

그는 “파일럿이 무엇을 목표로 하는지 명확해야 한다”라며 “단순 실험 목적의 프로젝트인지, 아니면 실제 성과 달성 가능성이 높은 프로젝트인지부터 분명히 구분해야 한다”라고 말했다.

일부 파일럿 프로젝트는 비즈니스 효과에 대한 충분한 이해 없이 추진되기도 한다.

FTI컨설팅의 수밋 굽타는 한 기업이 프로젝트의 재무적 가치를 제대로 분석하지 않은 채 AI 프로젝트를 시작한 사례를 소개했다.

그는 “AI 활용 사례를 정의한 이후 실제 투자를 집행하기 전에는 반드시 경제성 분석을 거쳐야 한다”라며 “이 단계는 프로젝트를 계속 진행할지 중단할지를 결정하는 핵심 판단 지점”이라고 설명했다.

이어 “우리가 재무 분석을 진행해보니 해당 AI 프로젝트의 초기 투자비와 지속 운영비가 예상 절감 효과의 중간값보다 더 큰 것으로 나타났다”라고 말했다.

일부 프로젝트는 성능 기준 자체를 충족하지 못하기도 한다.

파일럿 단계에서는 90% 수준의 정확도를 달성할 수 있지만, 이를 99% 수준까지 끌어올리기 위해서는 6개월 이상의 데이터 정제와 튜닝 작업이 필요한 경우가 많다.

하지만 잭헨리 같은 금융 서비스 기업은 사실상 100% 수준의 정확성을 요구한다.

키스 풀턴은 “99%만 정확한 업무 자동화 도구는 실제로는 가치가 없다”라며 “단 한 번의 오류만으로도 현업 리더의 신뢰를 잃게 되고, 결국 파일럿 프로젝트 자체가 중단될 수 있다”라고 말했다.

PoC(개념검증)를 실제 운영 규모로 확장하는 과정에서 문제가 드러나는 경우도 흔하다.

탈라사즈는 “엔지니어들이 만든 PoC가 소규모 환경에서는 잘 작동하더라도 실제 대규모 환경에서는 지나치게 비용이 많이 들거나 구조적으로 확장이 불가능한 경우가 적지 않다”라고 설명했다.

그는 “PoC 자체는 만들 수 있지만 이를 운영 규모로 확장할 설계 역량이나 엔지니어링 인력, 인프라가 부족한 상황도 많다”라고 덧붙였다.

시간 역시 또 다른 위험 요소다. 파일럿 프로젝트가 종료되면 초기 개발팀이 원래 업무로 복귀하고, 이후 새로운 팀이 프로젝트를 이어받는 경우가 많다. 이 과정에서 핵심 지식이 단절되며 프로젝트 속도가 크게 느려질 수 있다.

탈라사즈는 “개인적으로는 동일한 팀이 PoC부터 실제 운영 단계까지 계속 담당하는 방식을 선호한다”라고 말했다.

굽타는 이를 위해 명확한 생존 지표(proof-of-life milestone)와 에이전틱 워크플로우 사용자 시뮬레이션, 그리고 단계별 정확도 기준이 필요하다고 조언했다.

그는 “적절한 인력과 명확한 마일스톤이 없다면 결국 파일럿 프로젝트는 중도에 멈춰서게 된다”라고 말했다.

운영 단계에 들어가도 지속 가능성은 또 다른 과제

파일럿 프로젝트가 실제 운영 환경에 적용됐고 현재는 정상적으로 작동한다고 해도 문제는 그 이후다. 과연 이 상태를 지속적으로 유지할 수 있을까.

아프신 탈라사즈는 “많은 조직이 아직 프로젝트를 운영 단계까지 올리는 데 집중하느라 지속 가능성까지 충분히 고민하지 못하고 있다”라며 “하지만 결국 반드시 고려해야 하는 문제”라고 말했다.

모델 드리프트(model drift) 같은 운영 이슈를 지속적으로 모니터링하는 것도 중요하지만, 벤더 종속(vendor lock-in) 위험과 증가하는 기술 부채(technical debt) 역시 장기적으로 큰 부담이 될 수 있다.

이런 문제를 설계 단계나 파일럿 단계에서 충분히 고려하지 않으면 실제 운영에 들어간 뒤에는 구조적인 문제로 굳어질 수 있다는 설명이다.

가트너는 데이터와 모델, 워크플로우가 특정 벤더의 API나 데이터 레이크, 플랫폼 도구에 지나치게 종속되는 상황을 경계해야 한다고 조언했다.

대신 개방형 표준(open standard)을 따르고, AI 스택 설계 시 오픈 API와 모듈형 아키텍처를 적용해야 한다는 설명이다.

기술 부채와 관련해서도 가트너는 향후 4년 안에 기업의 절반이 관리되지 않은 생성형 AI 기술 부채로 인해 AI 업그레이드 지연과 유지보수 비용 증가를 경험할 것으로 전망했다.

이에 따라 기업들은 AI 레지스트리(registry)를 유지하고, 모델 카드(model card)를 의무화하며, 드리프트 모니터링 체계를 구축해야 한다고 권고했다. 또한 벤더에게 모델 변경 사항을 사전에 공지하도록 요구할 필요도 있다고 덧붙였다.

결국 다른 IT 프로젝트와 마찬가지로 AI 프로젝트에도 동일한 수준의 IT 라이프사이클 관리 원칙을 적용해야 한다는 의미다.

악마는 디테일에 있다

탈라사즈는 AI 프로젝트에서 해결해야 할 과제가 많지만, 결국 성공 여부는 세부 실행력에 달려 있다고 강조했다.

그는 “데이터와 거버넌스 같은 기술적 요소뿐 아니라 실제 비즈니스 업무가 어떻게 돌아가는지까지 세밀하게 이해해야 한다”라고 말했다.

이어 “업무의 세부적인 흐름까지 깊이 파고들어야 하며, 원하는 비즈니스 성과에서 아래로 내려가고 기술 기반에서는 위로 올라오는 방식으로 접근해야 한다”라고 설명했다.

만약 현재 기술 수준이 문제라면 아이디어 자체를 포기할 필요는 없다는 조언도 나왔다.

잭헨리의 키스 풀턴은 “지난해 여러 개발자용 코드 지원 도구를 테스트했지만 우리 규모의 시스템에서는 제대로 작동하지 않았다”라고 말했다.

하지만 8개월 뒤 같은 도구를 다시 테스트한 결과 상황은 완전히 달라졌다. 그는 “지금은 도입 속도가 폭발적으로 확산되고 있다”라고 설명했다.

이어 “어떤 기술은 ‘절대 불가능한 것’이 아니라 단지 ‘아직 시기가 오지 않았을 뿐’인 경우가 많다”라고 덧붙였다.
dl-ciokorea@foundryco.com