CTO Interview with Ed Plowman of Imagination Technologies
Ed Plowman is Chief Technology Officer at Imagination Technologies, where he leads technology strategy, advanced architecture research and long-term innovation initiatives. He focuses on the convergence of graphics, compute and artificial intelligence, helping shape the next generation of efficient and adaptable computing platforms for automotive, edge and intelligent systems markets.
에드 플라우만(Ed Plowman)은 이매지네이션 테크놀로지스(Imagination Technologies)의 최고기술경영자(CTO)로, 기술 전략, 첨단 아키텍처 연구 및 장기적인 혁신 이니셔티브를 이끌고 있습니다. 그는 그래픽, 연산, 인공지능의 융합에 초점을 맞추며, 오토모티브, 엣지, 지능형 시스템 시장을 위한 차세대 고효율·적응형 컴퓨팅 플랫폼을 구체화하는 데 기여하고 있습니다.
What brought you to Imagination Technologies?
My connection with Imagination Technologies goes back a long way. Early in my career I worked alongside teams putting Imagination graphics technology into real products, so I saw first-hand what a well-designed, efficient architecture could enable.
저와 이매지네이션 테크놀로지스의 인연은 꽤 오래전으로 거슬러 올라갑니다. 커리어 초기 저는 이매지네이션의 그래픽 기술을 실제 제품에 적용하는 팀들과 함께 일하며 잘 설계되고 효율적인 아키텍처가 무엇을 가능하게 하는지 직접 목격했습니다.
What always appealed to me was the willingness to challenge conventional thinking and take on genuinely difficult engineering problems. When the opportunity came to join Imagination and help shape where the technology goes next, it felt less like joining somewhere new and more like picking up a thread that had run through much of my career.
제게 항상 매력적으로 다가왔던 점은 통념에 도전하고 진정으로 어려운 엔지니어링 난제에 기꺼이 뛰어드는 태도였습니다. 이매지네이션에 합류하여 기술이 나아갈 다음 단계를 구체화할 기회가 찾아왔을 때, 그것은 완전히 새로운 곳에 발을 들이는 느낌이라기보다는 제 커리어 전반에 걸쳐 이어져 온 흐름의 실을 다시 이어 잡는 느낌에 가까웠습니다.
That is particularly interesting now. AI and increasingly complex workloads are changing what customers need from computing platforms, and efficiency and adaptability matter at least as much as headline performance.
이는 지금 시점에서 특히 흥미로운 부분입니다. AI와 점점 더 복잡해지는 워크로드는 고객이 컴퓨팅 플랫폼에 요구하는 바를 바꾸고 있으며, 표면적인 성능만큼이나 효율성과 적응성이 중요해지고 있습니다.
What is the biggest challenge your customer is facing?
The biggest challenge is not generating more TOPS. It is turning those TOPS into useful work.
가장 큰 과제는 더 많은 TOPS(초당 연산 횟수)를 생성하는 것이 아닙니다. 그 TOPS를 유용한 작업으로 전환하는 것입니다.
Customers are trying to run graphics, computer vision, AI inference, sensor processing and conventional software at the same time, usually inside fixed power, thermal and cost envelopes. Everything is competing for the same resources.
고객들은 일반적으로 고정된 전력, 발열, 비용 제약 내에서 그래픽, 컴퓨터 비전, AI 추론, 센서 처리, 기존 소프트웨어를 동시에 실행하려고 애쓰고 있습니다. 모든 요소가 동일한 리소스를 차지하기 위해 경쟁하고 있는 셈입니다.
The industry likes peak performance numbers, but customers don’t ship benchmarks. They ship products. Memory bandwidth, data movement, utilisation, latency and software overhead can matter as much as the theoretical capability of the compute. If you cannot get at the performance efficiently, the number on the datasheet is largely academic.
업계는 최고 성능 수치를 좋아하지만, 고객들은 벤치마크를 출하하지 않습니다. 그들은 제품을 출하합니다. 메모리 대역폭, 데이터 이동, 활용도, 지연 시간(latency), 소프트웨어 오버헤드는 연산 장치의 이론적 성능만큼이나 중요할 수 있습니다. 성능을 효율적으로 활용할 수 없다면 데이터시트상의 숫자는 학술적인 의미에 불과합니다.
So the real problem is useful, predictable performance in the system, not simply making the TOPS number bigger.
따라서 진정한 문제는 단순한 TOPS 수치 키우기가 아니라 시스템 내에서 유용하고 예측 가능한 성능을 확보하는 것입니다.
Why is your approach to solving this problem unique?
Our bias is towards adaptable, programmable compute rather than hardening everything around today’s workload. AI is moving extraordinarily quickly. Model architectures, data formats and optimisation techniques can change in months, while semiconductor development cycles are measured in years.
저희는 오늘의 워크플로우에 모든 것을 하드웨어로 고정(hardening)하기보다는 적응 가능하고 프로그래밍 가능한 연산에 중점을 둡니다. AI는 엄청나게 빠른 속도로 발전하고 있습니다. 모델 아키텍처, 데이터 포맷, 최적화 기법은 수개월 만에 바뀔 수 있는 반면, 반도체 개발 주기는 수년 단위로 측정됩니다.
That makes flexibility important. We optimise for delivered performance, not benchmark performance. Customers cannot ship theoretical TOPS; they have to ship a product that does useful work within real power, thermal, memory and cost constraints.
그렇기 때문에 유연성이 중요합니다. 저희는 벤치마크 성능이 아니라 실제로 구현되는 성능(delivered performance)을 최적화합니다. 고객들은 이론상의 TOPS를 출하할 수 없습니다. 실제 전력, 발열, 메모리, 비용 제약 내에서 유용한 작업을 수행하는 제품을 출하해야 합니다.
That also means looking at the whole problem. There is little point scaling the compute engine if memory movement, orchestration or software stops you using it. Efficient parallel processing matters, but so do the compiler, tools, workload mapping and the software ecosystem around it.
이는 또한 전체적인 관점에서 문제를 바라보는 것을 의미합니다. 메모리 이동, 오케스트레이션, 소프트웨어가 발목을 잡는다면 연산 엔진의 규모를 키우는 것은 큰 의미가 없습니다. 효율적인 병렬 처리가 중요하지만, 컴파일러, 툴, 워크플로우 매핑, 그리고 그 주변의 소프트웨어 생태계 역시 똑같이 중요합니다.
The aim is fairly simple: keep the architecture open and adaptable enough that customers can optimise for what they actually need, including workloads we cannot predict perfectly today.
목표는 비교적 단순합니다. 아키텍처를 충분히 개방적이고 적응력 있게 유지하여, 고객이 오늘날 완벽하게 예측할 수 없는 워크로드를 포함하여 자신들이 실제로 필요로 하는 것에 맞춰 최적화할 수 있도록 하는 것입니다.
What other approaches are being used to solve this problem?
There are perfectly valid alternatives. One is a tightly integrated hardware and software ecosystem, where the whole stack is controlled and optimised together. That has produced some very impressive results, particularly in cloud AI.
완전히 타당한 대안들도 존재합니다. 그중 하나는 전체 스택이 함께 제어되고 최적화되는 긴밀하게 통합된 하드웨어 및 소프트웨어 생태계입니다. 이 방식은 특히 클라우드 AI 분야에서 매우 인상적인 결과를 만들어냈습니다.
Another is dedicated neural processing hardware. If the workload matches the assumptions made when the hardware was designed, that can be extremely efficient.
또 다른 접근은 전용 신경망 처리 하드웨어입니다. 워크플로우가 하드웨어 설계 시점의 가정과 일치한다면 극도로 효율적일 수 있습니다.
The question is how long those assumptions remain true. Fixed-function hardware absolutely has a place, but the more specialised you become, the more certain you need to be about the workload. AI is not especially good at giving us that certainty at the moment.
문제는 그러한 가정들이 얼마나 오래 유효한가 하는 점입니다. 고정 기능 하드웨어는 분명 그 자리가 있겠지만, 특화될수록 워크플로우에 대해 더 확실히 예측할 수 있어야 합니다. 현재로서는 AI가 그러한 확실성을 가져다주지는 못하고 있습니다.
So it is really a question of where you draw the line between specialisation, programmability and efficiency and how expensive it is to move that line later.
결국 특수성과 프로그래밍 가능성, 효율성 사이의 경계를 어디에 그을 것인지, 그리고 나중에 그 경계를 옮기는 데 얼마나 큰 비용이 드는가의 문제입니다.
What challenges will your customers face in the near future?
Uncertainty is probably the biggest one. We make technology decisions years before products reach the market, while an important AI technique can move from a research paper to deployment in months.
불확실성이 아마도 가장 큰 과제일 것입니다. 우리는 제품이 시장에 출시되기 수년 전에 기술 결정을 내리지만, 중요한 AI 기술은 연구 논문 발표에서 배포까지 수개월 만에 전환될 수 있습니다.
Automotive makes that particularly stark. Validation and safety requirements are substantial, product development takes years and vehicles can remain in the market for well over a decade. You are effectively making architectural bets today against workloads that may not properly exist yet.
오토모티브 분야에서는 이 문제가 특히 두드러집니다. 검증 및 안전 요건이 매우 엄격하고, 제품 개발에는 수년이 걸리며, 차량은 10년이 넘는 기간 동안 시장에 머물 수 있습니다. 사실상 아직 제대로 존재하지 않을지도 모르는 미래의 워크플로우를 상대로 오늘 아키텍처 베팅을 하고 있는 셈입니다.
That is why I keep coming back to flexibility. Raw performance still matters, obviously, but customers also need platforms that remain useful when the workload changes underneath them. Over-specialise too early and today’s optimisation can become tomorrow’s constraint.
제가 유연성을 거듭 강조하는 이유가 바로 여기에 있습니다. 물론 원초적 성능은 여전히 중요하지만, 고객들에게는 그들의 발밑에서 워크플로우가 바뀔 때도 여전히 유용하게 작동하는 플랫폼이 필요합니다. 너무 일찍 과도하게 특화해 버리면 오늘의 최적화가 내일의 제약이 될 수 있습니다.
How has AI changed your business strategy?
We increasingly don’t think of AI as a separate market. It is becoming part of almost every market we serve and, increasingly, part of graphics itself. That reinforces the case for efficient parallel compute, scalable software and architectures that can support a broad mix of workloads.
우리는 점점 더 AI를 별개의 시장으로 생각하지 않습니다. AI는 우리가 서비스하는 거의 모든 시장의 일부가 되어가고 있으며, 점차 그래픽 그 자체의 일부가 되고 있습니다. 이는 효율적인 병렬 연산, 확장 가능한 소프트웨어, 그리고 광범위한 워크플로우 조합을 지원할 수 있는 아키텍처의 필요성을 더욱 강화합니다.
It has also changed how I think about the balance between hardware and software. There are important things we can and should do in hardware, but the bigger opportunity is often in software: compilers, tooling, workload mapping and using AI itself to optimise applications for the architecture. You cannot bridge every software gap simply by throwing more engineers at it.
또한 이는 하드웨어와 소프트웨어 간의 균형에 대한 저의 생각도 바꾸어 놓았습니다. 하드웨어 영역에서 반드시 해야 하고 할 수 있는 중요한 일들이 있지만, 더 큰 기회는 종종 소프트웨어에 있습니다. 컴파일러, 툴링, 워크플로우 매핑, 그리고 아키텍처에 맞게 애플리케이션을 최적화하기 위해 AI 자체를 활용하는 것이 그것입니다. 단순히 엔지니어 수를 늘린다고 해서 모든 소프트웨어의 공백을 메울 수 있는 것은 아닙니다.
The same applies internally. AI can take repetitive analysis and optimisation work away from engineers and give them more time for the difficult problems where engineering judgement actually matters.
사내에서도 마찬가지입니다. AI는 엔지니어들의 반복적인 분석 및 최적화 업무를 덜어주고, 엔지니어링적 판단이 진정으로 중요한 어려운 문제에 더 많은 시간을 쏟을 수 있게 해줍니다.
For me the strategic lesson is straightforward: AI is moving too quickly to pretend we know exactly what the dominant workload will look like several years from now. Build efficient, malleable hardware, invest heavily in the software that makes it useful, and keep enough flexibility to move when the market moves.
제게 전략적 교훈은 명확합니다. AI는 몇 년 후의 지배적인 워크플로우가 어떨지 정확히 알고 있다고 자부할 수 없을 만큼 너무 빠르게 움직이고 있습니다. 효율적이고 변형 가능한 하드웨어를 구축하고, 이를 유용하게 만드는 소프트웨어에 막대하게 투자하며, 시장이 움직일 때 함께 움직일 수 있는 충분한 유연성을 유지하는 것, 그것이 답입니다.
