속도를 만드는 것은 도구가 아니라 질문의 품질이다

Jun 29, 2026

6 min read

3 views

76%

우리가 정말 최적화해야 하는 것은 무엇인가

100억 행을 4초에 처리하는 시스템을 보면 사람들은 먼저 알고리즘을 떠올린다. 더 좋은 언어, 더 빠른 런타임, 더 영리한 병렬화. 그런데 실제로 성능을 끌어올리는 과정의 핵심은 종종 전혀 다른 곳에 있다. 문제를 얼마나 정확하게 정의했는가, 그리고 제약 조건을 얼마나 명료하게 전달했는가가 속도의 상한을 결정한다.

이 점은 코드 한 줄만의 이야기가 아니다. 디버깅에서도 마찬가지다. 에러 메시지 하나만 던지고 “왜 안 되죠?”라고 묻는 질문과, 기대 동작, 입력값, 재현 코드, 증상, 변경 이력까지 붙여서 묻는 질문은 전혀 다른 결과를 낳는다. 전자는 운에 기대고, 후자는 엔지니어링을 한다.

흥미로운 사실은, 고성능 시스템을 만드는 능력과 좋은 프롬프트를 설계하는 능력이 같은 구조를 공유한다는 점이다. 둘 다 문제를 풀기 전에 문제를 재구성하는 기술이다. 그리고 그 재구성의 질이 곧 결과의 질이다.

성능은 계산의 결과이기 전에, 질문의 정밀도에서 먼저 결정된다.

좋은 프롬프트와 좋은 최적화는 같은 방식으로 작동한다

많은 사람은 프롬프트 엔지니어링을 말을 잘 거는 기술쯤으로 생각한다. 하지만 실제로는 그렇지 않다. 그것은 문맥 압축 기술이며, 더 정확히 말하면 문제 정의 기술이다. “리팩토링해줘”보다 “시니어 타입스크립트 개발자처럼, 타입 안정성을 유지하면서 중복을 줄이고, 함수 경계를 명확히 하며, 설명도 덧붙여줘”가 훨씬 강력한 이유는 단순히 예의가 있어서가 아니다. 목표 함수가 더 잘 정의되기 때문이다.

이것은 성능 최적화와 놀랍도록 닮아 있다. 예를 들어 10억 행 처리 문제에서 “더 빠르게 해주세요”는 아무런 정보도 주지 않는다. 반면 데이터 크기, 메모리 상한, I/O 병목, 병렬화 가능성, 런타임 특성 같은 제약을 명시하면 탐색 공간이 급격히 줄어든다. 즉, 좋은 최적화는 무한한 가능성을 좁히는 일이고, 좋은 프롬프트 역시 무수한 답변을 좁혀서 원하는 해를 유도하는 일이다.

여기서 중요한 통찰은 이렇다. 속도 향상은 흔히 더 많은 계산을 의미하지 않는다. 오히려 불필요한 탐색을 제거하는 것에 가깝다. 디버깅도 마찬가지다. 에러를 빨리 고치는 사람은 코드를 더 빨리 읽는 사람이 아니라, 어디를 볼지 더 빨리 결정하는 사람이다.

이 관점에서 보면, 프롬프트는 단지 AI를 다루는 인터페이스가 아니다. 사고의 압축 포맷이다. 최적화와 디버깅 역시 같은 포맷을 따른다. 목표를 선명하게 하고, 제약을 적고, 관찰 가능한 증거를 붙이고, 원하는 결과와 현재 결과의 차이를 드러내는 것. 이 네 가지가 있으면 시스템은 훨씬 더 빨리 수렴한다.

병목은 코드에만 있지 않다: 문제 서술이 병목이 된다

대규모 성능 개선에서 가장 흔한 실수는 병목을 기술 스택 내부에서만 찾는 것이다. 그러나 현실에서는 병목이 코드가 아니라 서술에 있을 때가 많다. 문제를 모호하게 말하면, 그 모호함이 곧 탐색 비용으로 되돌아온다. AI에게도, 사람에게도, 팀에게도 마찬가지다.

예를 들어 다음 두 요청을 비교해 보자.

“이거 좀 최적화해줘.”
“현재 병목은 파일 읽기 단계이고, 메모리는 2GB 이하로 유지해야 하며, 결과는 기존과 완전히 동일해야 한다. Java 21 환경에서 처리 시간을 30퍼센트 줄이고 싶다.”

두 번째 요청은 단지 더 자세한 설명이 아니다. 그것은 문제의 경계 조건을 제시한다. 이 경계가 있어야만 실제로 가능한 해법이 걸러진다. 무작정 병렬화를 제안할 수도 없고, 메모리를 더 쓰는 해법도 배제된다. 대신 압축, 배치 처리, 스트리밍, 캐시 전략 같은 진짜 후보들이 등장한다.

디버깅도 같다. “오류가 납니다”는 거의 정보가 아니다. 하지만 “이 입력값에서만 실패하고, 기대 출력은 A인데 실제 출력은 B이며, 실패 직전 변수 값이 C로 바뀐다”는 말은 탐사 좌표가 된다. 좋은 질문은 답을 쉽게 받기 위한 수단이 아니라, 문제를 수학적으로 좁히는 장치다.

이게 왜 중요할까. 많은 팀이 ‘해결 능력’ 부족보다 ‘문제 정의 능력’ 부족으로 시간을 잃기 때문이다. 회의가 길어지는 이유도 종종 같다. 사람들은 의견이 다른 것이 아니라, 서로 다른 문제를 풀고 있다. 누군가는 성능을 말하고, 누군가는 유지보수를 말하고, 누군가는 일정 리스크를 말한다. 같은 단어를 쓰지만, 서로 다른 최적화 함수를 가지고 있는 셈이다.

그래서 고급 엔지니어링의 핵심 역량은 코드를 만지는 손기술보다 문제를 재진술하는 능력이다. 같은 현상을 더 정밀한 언어로 바꾸는 순간, 해법의 질이 달라진다. 이것이 성능 개선과 프롬프트 설계가 만나는 지점이다.

병목을 제거하는 가장 빠른 방법은 병목을 정확히 이름 붙이는 것이다.

전문가가 빠른 이유는 더 똑똑해서가 아니라, 전제를 더 잘 고르기 때문이다

1초도 안 걸리는 Java 구현이 존재한다는 사실은 많은 사람에게 놀라움을 준다. 그런데 이런 성취를 단순히 “천재가 했으니까”로 설명하면 아무것도 배우지 못한다. 더 유용한 질문은 이것이다. 무엇이 그 해법의 탐색 공간을 극단적으로 줄였는가?

전문가의 속도는 종종 계산량이 아니라 전제 선택에서 나온다. 예를 들어 다음과 같은 차이가 있다.

초보자의 사고: 어떻게든 다 돌려서 해결할 수 있을까
전문가의 사고: 이 문제는 정말 모든 데이터를 메모리에 올려야 하는가
더 성숙한 사고: 이 문제는 애초에 어떤 불변량을 유지하면 훨씬 단순해지는가

이 차이는 AI에게 질문할 때도 똑같이 적용된다. “리팩토링해줘”라고 하면 모델은 무수한 가능성을 탐색한다. 하지만 “함수의 책임을 분리하고, 부작용을 줄이고, 오류 처리 경로를 명확히 해줘”라고 하면 탐색의 기준이 생긴다. 즉, 전제를 잘 고르는 능력이야말로 속도의 출발점이다.

이것을 실무적으로 바꾸면 다음과 같은 형태가 된다. 문제를 만났을 때 먼저 해법을 묻지 말고, 다음 세 가지를 적어보는 것이다.

무엇이 변하면 안 되는가
무엇이 반드시 달라져야 하는가
무엇을 측정하면 개선을 판단할 수 있는가

이 세 질문은 최적화, 디버깅, 프롬프트 작성 모두에 통한다. 왜냐하면 이들은 공통적으로 답을 찾는 기술이 아니라 탐색을 제어하는 기술이기 때문이다. 좋은 시스템은 우연히 빨라지지 않는다. 좋은 질문이 우연을 줄인다.

또 하나 중요한 점이 있다. 전문가의 해법은 종종 화려하지 않다. 오히려 제약을 정직하게 인정하고, 문제를 작은 단위로 쪼개고, 측정 가능한 기준으로 다시 쓰는 쪽에 가깝다. 바로 그 소박함 때문에 빠르다. 불필요한 선택지를 제거했기 때문이다.

실전 프레임워크: 답을 묻기 전에 문제를 설계하라

이제 이 통찰을 실제로 사용할 수 있는 형태로 바꿔보자. 아래 프레임워크는 AI에게 질문할 때도, 성능 개선 회의를 할 때도, 버그를 추적할 때도 쓸 수 있다.

1. 목표를 동사로 쓰지 말고 판정문으로 써라

“최적화해줘”보다 “현재와 동일한 결과를 유지하면서 실행 시간을 절반으로 줄인다”가 낫다. 판정문은 성공 여부를 측정 가능하게 만든다. 목표가 추상적이면 해답도 추상적으로 흐른다.

2. 제약을 먼저 써라

메모리 한도, 언어 버전, API 호환성, 시간 제한, 유지보수성 같은 제약은 방해물이 아니라 설계의 경계다. 경계가 있어야 해법이 현실적이 된다. 제약 없는 최적화는 종종 현업에서 쓸 수 없는 데모로 끝난다.

3. 최소 재현 단위를 확보하라

전체 시스템을 한 번에 설명하려고 하지 말고, 문제가 실제로 드러나는 최소한의 코드, 입력값, 상태 전이를 준비하라. 이것은 디버깅의 기본이자, LLM에게도 가장 강력한 입력이다. 작은 재현은 작은 추측을 낳고, 작은 추측은 빠른 수정을 낳는다.

4. 원하는 답의 형식을 미리 정해라

설명도 필요한지, 단계별 추적이 필요한지, 리팩토링 결과와 함께 이유가 필요한지 명시하라. 형식은 부가 정보가 아니라 문제 해결의 일부다. 답의 형식을 정하면 모델도, 사람도 같은 레일 위에서 생각하게 된다.

5. 나쁜 질문을 먼저 적어보라

“왜 안 돼요?” 같은 질문을 던지기 전에, 그 질문이 왜 약한지 스스로 설명해보라. 그러면 무엇이 빠져 있는지 보인다. 에러 메시지, 기대 결과, 실제 결과, 최근 변경 사항, 입력값. 이 중 무엇이 빠졌는지 찾는 순간, 질문의 질이 올라간다.

이 프레임워크의 핵심은 단순하다. 해결책을 빨리 얻는 것은 질문을 잘하는 것의 부산물이다. 우리는 흔히 답을 찾는 데 집중하지만, 실제로는 답변 공간을 설계하는 것이 더 중요하다.

Key Takeaways

문제 정의가 성능을 만든다. 빠른 시스템은 단지 계산이 빨라서가 아니라, 탐색이 좁혀져 있기 때문에 빠르다.
디버깅 질문은 재현 가능한 실험이어야 한다. 에러 메시지, 기대 동작, 실제 동작, 입력값, 최소 재현 코드가 있어야 한다.
제약 조건은 장애물이 아니라 나침반이다. 메모리, 시간, 호환성, 유지보수성 제약을 먼저 명시하라.
전문가의 속도는 전제 선택에서 나온다. 무엇을 가정할지, 무엇을 배제할지 정하는 능력이 해법을 가른다.
좋은 프롬프트는 사고의 압축 포맷이다. 목표, 문맥, 역할, 출력 형식을 함께 적으면 답의 품질이 눈에 띄게 좋아진다.

결론: 더 빠른 사람은 더 빨리 생각하는 사람이 아니라, 더 정확히 묻는 사람이다

우리는 종종 속도를 계산 능력, 언어 능력, 도구 능력으로 오해한다. 하지만 정말 큰 차이를 만드는 것은 그보다 앞선 층위에 있다. 무엇을 묻고 있는지, 어떤 제약 아래 있는지, 어떤 관찰로 성공을 판정할지를 정하는 능력이다.

10억 행을 4초에 처리하는 일도, 복잡한 버그를 몇 분 안에 좁히는 일도, 정교한 리팩토링을 끌어내는 일도 결국 같은 원리 위에 있다. 문제를 더 크게 보지 말고, 더 선명하게 보라. 질문을 더 길게 만들지 말고, 더 정밀하게 만들라.

진짜 고성능은 코드의 바깥에서 시작된다. 답을 빨리 얻는 기술의 본질은, 정답을 잘 추측하는 것이 아니라 문제를 잘 규정하는 데 있다. 그리고 그 능력을 갖춘 사람은 AI를 쓰더라도, 스스로 디버깅하더라도, 대규모 시스템을 설계하더라도 결국 더 빠르다. 왜냐하면 그들은 컴퓨터보다 먼저, 문제를 수렴시키기 때문이다.