엔지니어링은 어디에서 시작되는가

이번 달 한 엔지니어가 LLMs are eroding my software engineering career and I don't know what to do라는 제목의 에세이를 발표했습니다.

이 글은 많은 엔지니어들이 가지고 있지만 거의 입 밖에 내지 않는 두려움을 담아 공감을 얻었습니다:

내가 15년간 배운 모든 것이 프롬프트가 된다면 어떨까?

저는 이 두려움이 현실이라고 생각합니다.

하지만 동시에 잘못된 대상을 겨냥하고 있다고 생각합니다.

작가는 수년 동안 개발한 기술들이 LLM을 가진 누구에게나 접근 가능해지는 것을 목격하는 내용을 묘사합니다. 도메인 전문성, 디버깅, 아키텍처 같은 것들입니다.

결론은 이해가 됩니다:

만약 다른 엔지니어가 모델에 프롬프트를 입력하여 비슷한 답변을 얻을 수 있다면, 그 모든 경험이 정확히 무슨 가치가 있었는가?

하지만 저는 그가 잘못된 것을 측정하고 있다고 생각합니다.

소프트웨어 역사 대부분 동안 구현(implementation)은 비용이 많이 드는 일이었습니다.

비용이 많이 들었기 때문에, 우리는 구현을 엔지니어링과 혼동했습니다.

AI는 그 차이를 드러내고 있습니다.

제가 LLM에게 API 작성, 테스트 생성, 인프라 구축 또는 코드 리팩토링을 요청할 때, 종종 놀랍도록 좋은 결과를 보여줍니다.

이것이 증명한 것은 우리가 엔지니어링 작업이라고 생각했던 것 중 상당 부분이 실제로는 **번역 작업(translation work)**이었다는 것입니다.

이미 결정된 솔루션을 가져와 코드로 변환하는 작업입니다.

불편한 질문은 이것입니다:

모델이 그 부분을 할 수 있다면, 무엇이 남는가?

답변은 항상 어려웠던 부분입니다.

제가 다뤄본 가장 어려운 문제들은 결코 구현 문제가 아니었습니다.

그것들은 정의(definition) 문제였습니다.

저는 누군가가 for-loop를 작성하지 못해서 발생한 주요 프로덕션 사고는 본 적이 없습니다.

하지만

그 답들이 존재한다면, 코드를 한 번 작성하는 것 자체는 결코 어려운 일이 아니었습니다.

어려움은 애초에 그 답들을 찾아내는 것이었습니다.

그 지점이 바로 AI를 둘러싼 많은 논의가 궤도를 벗어난다고 생각하는 부분입니다.

사람들은 도메인 전문 지식 (domain expertise)을 마치 사실 (facts)의 집합인 것처럼 이야기합니다.

사실은 언제나 전달하기 가장 쉬운 것이었습니다.

결제 시스템, 광고 경매, 물류 워크플로우 (workflows), 또는 의료 규제 등을 배울 수 있습니다.

충분한 문서만 주어진다면, LLM (대규모 언어 모델) 또한 그것들을 배울 수 있습니다.

도메인 전문 지식이 사실을 아는 것이라고 가정하는 것이 실수입니다.

진짜 가치는 도메인이 모순되거나, 불완전하거나, 정의되지 않은 지점을 식별하는 데 있습니다.

그곳에서 엔지니어링이 시작됩니다.

엔지니어링은 도메인을 암기하는 것이 아닙니다.

엔지니어링은 컴퓨터가 실행할 수 있을 만큼 정밀한 해당 도메인의 모델 (model)을 만드는 것입니다.

이것들은 매우 다른 기술입니다.

한 엔지니어는 백 개의 요구사항을 읽고 코드를 작성하기 시작합니다.

다른 엔지니어는 동일한 백 개의 요구사항을 읽고 그중 20개는 동시에 모두 참일 수 없다는 사실을 깨닫습니다.

그들은 다음과 같은 점을 포착합니다:

• 3개의 모순
• 2개의 누락된 가정
• 아무도 아직 내려져야 한다는 사실을 인지하지 못한 1개의 비즈니스 결정

두 번째 엔지니어는 모델이 아직 신뢰성 있게 수행할 수 없는 일을 여전히 하고 있는 것입니다. 왜냐하면 정답이 아직 존재하지 않기 때문입니다.

누군가는 그것을 발견해야만 합니다.

이것이 제가 AI가 시니어 엔지니어의 가치를 떨어뜨리고 있다고 생각하지 않는 이유입니다.

저는 AI가 구현 (implementation) 뒤에 숨는 것을 더 어렵게 만들고 있다고 생각합니다.

수년 동안 엔지니어들은 순수한 산출량 (output)을 통해 가치를 창출할 수 있었습니다.

무언가를 만드는 속도가 다른 모든 사람보다 빨랐다면, 그것은 중요했습니다.

오늘날 구현의 비용은 무너지고 있습니다.

레버리지 (leverage)는 다른 곳으로 이동하고 있습니다.

차별점은 판단력 (judgment)이 되고 있습니다.

• 진짜 문제를 식별할 수 있는가?
• 복잡하고 무질서한 비즈니스 도메인을 모델링할 수 있는가?
• 적절한 추상화 (abstractions)를 만들어낼 수 있는가?
• 특정 범주의 실패를 방지하는 제약 조건 (constraints)을 정의할 수 있는가?
• 몇 년 후에도 이해 가능한 상태로 유지되는 시스템을 설계할 수 있는가?

그것들은 모든 도구의 혁명 (tooling revolution) 속에서도 살아남는 기술들입니다. 왜냐하면 그 기술들은 단순히 어떻게 만들어지는가가 아니라, 무엇을 만들어야 하는지를 결정하기 때문입니다.

**구현 처리량 (implementation throughput)**을 중심으로 자신의 정체성을 구축해 온 엔지니어들은 아마도 걱정해야 할 것입니다.

**시스템을 이해하는 것 (understanding systems)**을 중심으로 자신의 정체성을 구축해 온 엔지니어들은 기대해도 좋을 것입니다.

AI는 엔지니어링을 없애고 있는 것이 아닙니다.

AI는 점점 더 많은 건설 작업 (construction work)을 제거하고 있으며, 우리로 하여금 엔지니어링의 본질이 무엇인지 직면하게 만들고 있습니다.

AI는 코드를 생성할 수 있습니다.

AI는 패턴을 설명할 수 있습니다.

AI는 도메인을 요약할 수 있습니다.

하지만 요구사항이 충돌하고, 이해관계자(stakeholders)들이 의견을 달리하며, 아직 정답이 존재하지 않을 때, 무엇이 진실인지 결정해야 하는 사람은 여전히 존재합니다.

누군가는 여전히 모델을 정의해야 합니다.

누군가는 여전히 트레이드오프 (tradeoff)를 결정해야 합니다.

누군가는 여전히 모호함을 시스템으로 전환해야 합니다.

그곳이 바로 엔지니어링이 시작되는 지점입니다.