엔지니어의 역할은 책임을 지는 것이 아니다
요약
본 글은 에이전트 개발 논의에서 자주 사용되는 '책임'이라는 개념의 모호성을 비판하며, 엔지니어의 역할이 단순히 책임을 지는 것을 넘어선다고 주장한다. 필자는 엔지니어가 매일 수행하는 책임 활동(원인 추구 및 개선책 제시)의 실체를 분석한 결과, 이는 결국 조직의 '목적 설정'과 '규범 정의'에 기반한다는 결론을 내린다. 따라서 엔지니어의 핵심 역할은 주어진 목적을 명확히 구현으로 번역하고 그 적합성을 검증하는 데 있다.
핵심 포인트
- 엔지어링 논의에서 사용되는 '책임'이라는 개념은 법적, 윤리적, 운영상의 책임이 뒤섞여 있어 모호하다.
- 실제 엔지니어가 수행하는 책임 활동(원인 추구 및 개선책 제시)은 결국 원인 분석과 대책 수립의 루프에 불과하다.
- 진정한 핵심 역량은 기술적 사실을 넘어선 '있어야 할 모습(Ideal state)'이라는 규범이나 가치 판단을 정의하는 것이다.
- 개선책 선택 역시 상황별 우선순위와 조직의 목적 설정에 따라 달라지며, 이는 기술만으로 결정될 수 없다.
- 에이전트는 주어진 목적 아래에서 최적화할 수는 있지만, 그 '최상위 목적' 자체를 생성하거나 부여할 수는 없으므로 인간의 역할은 구조적으로 남아있다.
TL;DR
에이전트 개발에서 "결국 인간이 책임을 진다"라는 말이 자주 나오지만, 저는 이 "책임"이 무엇을 가리키는지 너무 모호하다고 생각합니다. 실체를 추출해 보면, 원인 추구와 개선책 제시의 루프가 됩니다. 더 깊이 파고들면 그 근저에는 목적 설정의 비대칭성이 있습니다. 에이전트는 목적을 갖지 않으며, 목적 아래에서의 최적화만 할 수 있습니다. 그래서 엔지니어의 일은 책임을 지는 것이 아니라, 목적을 구현으로 번역하고 목적과의 적합성을 검증하는 것이라는 이야기를 쓰고자 합니다.
「책임」이 너무 편리하다
에이전트 개발 논의에서 "결국 인간이 책임을 지니까"라는 결론을 자주 보게 됩니다. 저도 얼마 전까지는 이 표현에 만족했습니다. 에이전트화가 진행됨에 따라 "그럼 인간의 일은 무엇인가"라는 질문을 받는 장면이 늘어나지만, 책임이라는 단어를 꺼내면 일단 논의가 끝나버리기 때문입니다.
다만, 최근 이 표현의 공허함이 신경 쓰이기 시작했습니다. "책임"이 가리키는 것이 너무 모호합니다. 법적인 경계의 문제인지, 윤리적인 의미의 문제인지, 운영상의 책임 문제인지. 이것들이 뒤섞인 채 사용되고 있습니다.
법적 책임은 궁극적으로 회사와 계약, 그리고 보험의 문제이며, 현장의 엔지니어가 매일 고민하는 영역은 아니라고 생각합니다. 윤리적인 이야기도 중요하지만, 이 역시 개별적인 코드 변경 상황에서 발동되는 것은 아닙니다.
엔지니어가 매일 마주하는 책임을 추출해 보면, 결국 이것은 원인 추구와 개선책 제시의 루프를 의미한다고 생각합니다. 장애가 발생하면 원인을 밝혀내고, 대책을 세우고, 재발하지 않는지 감시합니다. post-mortem, retrospective, CI, monitoring. 무거운 표정으로 책임이라 부르는 것의 실체는 이 정도의 수수한 작업의 축적입니다.
원인 추구는 인간만이 할 수 있다고 단언할 수 있는가
여기서 "원인 추구와 개선책 제시는 인간만이 할 수 있다, 그러므로 인간이 필요하다"라고 말을 잇고 싶어지겠지만, 이는 논리가 약하다고 생각합니다.
로그를 읽고 근본 원인에 대한 가설을 세우는 것은 현재의 LLM이 상당히 잘합니다. post-mortem의 초안도 작성할 수 있습니다. 개선책 후보를 나열하게 하면 인간보다 망라적일 때도 있습니다. 능력으로서 가능한지 불가능한지로 논쟁한다면, 논의는 몇 년 단위로 뒤로 밀려날 것입니다.
그럼에도 엔지니어의 일이 사라질 것 같지 않은 이유는, 능력의 문제가 아닌 다른 무언가가 있기 때문이라고 생각합니다. 그것을 언어화하지 못한 채 "책임"이라는 단어로 얼버무리고 있는 것이 솔직한 심정이며, 조금 전까지 저 또한 그러했습니다.
원인 추구에는 「있어야 할 모습」이 필요하다
생각의 실마리가 된 것은 다음과 같은 이야기였습니다.
에이전트가 테스트를 통과하기 위해, production code를 수정하는 대신 테스트 쪽을 완화했다고 가정해 봅시다. 이것을 바람직하지 않다고 판단하려면, "테스트는 사양(specification)이며, 코드에 맞춰 완화하는 것이 아니다"라는 규범이 먼저 필요합니다. 당연하게 들리겠지만, 이 규범은 기술적 사실로부터 자동으로 도출되는 것이 아닙니다. 소프트웨어 공학의 문화가 오랜 시간을 들여 만들어낸 가치 판단입니다.
다른 예로, 에이전트가 운영 DB에 직접 쿼리를 날려 문제를 "해결"했다고 가정해 봅시다. 이것을 일탈로 볼 것인지 타당한 대응으로 볼 것인지는, 그 조직이 운영 환경에 대한 직접 개입을 어떻게 정의하느냐에 따라 결정됩니다. 스타트업 초기와 상장 기업에서는 답이 다를 것입니다.
원인 추구에는 「있어야 할 모습」이 선행합니다. 있어야 할 모습이 정의되어 있지 않으면 무엇이 원인인지 판단할 수 없습니다. 관측된 동작과 있어야 할 모습의 차이(diff)를 보고 나서야 비로소 차이를 만들어낸 요소를 거슬러 올라갈 수 있습니다.
이 '있어야 할 모습'을 에이전트는 생성하지 않습니다. 훈련 데이터로부터 다수파의 규범을 통계적으로 재현할 뿐입니다. 가치가 충돌하는 장면, 트레이드오프(trade-off)가 필요한 장면, 전례 없는 장면에서 무엇을 일탈이라고 부를지를 결정하려면, 그것을 결정하려는 주체가 필요합니다.
개선책의 선택도 같은 구조를 가지고 있다
동일한 장애에 대해서도 개선책은 쉽게 갈라집니다.
동종 사건을 두 번 다시 일으키지 않는 것을 최우선으로 한다면, 검증 게이트를 엄격히 하여 릴리스 속도를 희생하게 됩니다. 영향 범위의 최소화를 우선한다면, 롤백(rollback)을 빠르게 할 수 있도록 투자하게 됩니다. 조직의 학습 기회로 삼는다면, 상세한 post-mortem을 전사에 공유하여 훈련에 사용하게 됩니다. 개발 속도를 유지하고 싶다면, 잠정적인 대처로 끝내고 기술적 부채로 기록해 두게 됩니다.
어느 것이 정답인지는 상황에 따라 다릅니다. 조직의 단계, 무엇을 희생해서라도 지키고 싶은 것, 경쟁 상황, 규제 환경. 기술적 사실만으로는 결정되지 않습니다.
에이전트(Agent)는 베스트 프랙티스(Best Practice)를 제안할 수 있습니다. 하지만 이 조직이 현재 어느 위치에 있으며 무엇을 우선시하고 싶은지를 자신의 목적으로 가질 수는 없습니다. 목적을 부여하면 그 아래에서 최적화는 수행하지만, 목적 그 자체는 부여하는 쪽에 있습니다.
원인 추구에 필요한 '있어야 할 모습(Ideal state)'도, 개선책 제시에서 필요한 '우선순위'도, 결국 둘 다 목적 설정의 문제라는 것을 깨달았습니다. 책임이라는 단어로 모호하게 지칭했던 것의 정체는 이것이 아니었을까 생각합니다.
에이전트가 목적을 갖지 못하는 것은 구조적인 문제
에이전트는 목적을 갖지 않습니다. 지능이 부족하다는 이야기가 아니라, 구조적으로 그렇게 되어 있습니다. 목적을 내재화시키려 하면, 목적을 선택하는 목적이 필요해지고, 그 상위의 목적이 필요해지며, 재귀적으로 최상위의 목적 설정자가 요구됩니다. 그 최상위에 있는 것이 인간입니다.
목적 아래에서 최적화하는 능력과 목적을 만들어내는 능력은 별개의 것이라고 생각합니다. 전자는 모델이 급격히 성장하고 있는 영역이지만, 후자는 구조적으로 모델의 외부에 남습니다. AGI(인공 일반 지능)가 어떠냐는 이야기와는 다른 차원의 문제라고 생각합니다.
이 단계에 이르면 책임이라는 단어가 공허하게 느껴집니다. 정말로 지칭하고자 했던 것은 목적을 만드는 측과 목적에 따르는 측의 구조적인 분업이었습니다. 법적 책임과 혼동되기 때문에 오해를 낳는 것이라고 생각합니다.
엔지니어의 일은 목적의 번역업
그렇다면 엔지니어의 일을 무엇이라 불러야 할까요. 저는 이를 '목적의 번역업'이라고 정리하고 있습니다. 사용자나 조직이 가진 목적을 에이전트가 실행 가능한 형태로 번역하는 것. 번역이 잘 이루어지고 있는지를 지속적으로 검증하는 것. 이것이 업무의 내용이라고 생각합니다.
구현의 언어로 다시 말하면 더 친숙하게 다가옵니다.
- 시스템 프롬프트(System Prompt)를 쓰는 것은 목적을 자연어로 번역하는 작업
- 도구 정의(Tool Definition)를 좁히는 것은 목적의 경계 조건(Boundary Condition)을 긋는 작업
- 평가(Evaluation)를 설계하는 것은 목적과의 적합도를 측정하는 장치를 만드는 작업
- 로그 트레이싱(Log Tracing) 설계는 목적으로부터의 이탈을 어느 입도(Granularity)로 검출할지 결정하는 작업
- 정지 조건(Stop Condition)의 정의는 목적 달성 판정 기준을 만드는 작업
- 가드레일(Guardrail)은 목적 밖으로의 이탈을 차단하는 작업
에이전트 개발을 하고 있다면 이 모든 것을 다 하고 있다고 생각합니다. 다만 책임이라는 말로 뭉뚱그려 불렀기에, 자신이 어떤 일을 하고 있는지 보이지 않았던 것이라고 생각합니다. 이것들은 '목적을 구현 가능한 형태로 변환하고, 목적과의 적합성을 검증 가능하게 만드는' 일관된 작업의 서로 다른 측면이었습니다.
최근 VS Code의 하네스(Harness)에 관한 기사[1]에서 "The harness is the product"라고 적혀 있는 것을 보고, 저는 처음에 이를 "모델이 아니라 주변의 구성 요소가 본체다"라는 의미로 읽었습니다. 그것도 맞지만, 조금 더 말하자면 하네스는 목적과의 접속 장치라고 생각합니다. 모델 세대마다 다른 시스템 프롬프트를 적용하고, 자체 평가 도구인 VSC-Bench를 가지며, PR 단위로 평가 플로우를 돌리는 것. 그것은 전부 목적(VS Code로서의 제품 경험)을 구현으로 번역하고, 번역 정밀도를 검증하는 장치였습니다.
바꾸어 말하면 보이는 것들
'책임을 지는 것'을 '목적을 번역하는 것'으로 바꾸어 말하면, 실무적으로 다르게 보이는 것들이 있습니다.
먼저, "마지막은 인간이 리뷰합니다"라는 말이 설계로서 내용이 비어 있다는 사실이 명확해집니다. 무엇을, 어느 입도로, 무엇과 비교하여 리뷰할 것인가. 이는 목적과의 적합도를 측정하는 문제이며, 평가(Evaluation) 설계의 문제입니다. 인간이 보기만 하는 것은 아무것도 설계한 것이 아닙니다.
다음으로, 에이전트에게 맡길 수 있는 부분과 맡길 수 없는 부분의 경계가 보이기 시작합니다. 목적의 생성, 목적 간의 우선순위 지정, 상황에 따른 목적의 수정은 맡길 수 없습니다. 명확하게 정의된 목적 아래에서의 실행이나 최적화는 맡길 수 있습니다. 경계가 확실해지면 새로운 똑똑한 모델이 나올 때마다 동요하지 않아도 됩니다.
그리고 목적을 이끌어내는 능력, 목적을 구조화하는 능력, 목적을 평가 가능한 형태로 분해하는 능력이 기술 스킬과 거의 동등하게 중요해집니다. 에이전트 개발을 하다 보면 코드를 쓰는 시간보다 목적을 정리하는 시간이 더 길어지는 경우가 흔히 있습니다. 이것은 버그가 아니라, 업무의 성격이 그러한 것이라고 생각합니다.
마치며
책임이라는 단어를 쓰는 것을 그만두고, 목적의 번역이라고 말하려고 합니다. 적어도 제 안의 정리로서는 이쪽이 해상도가 더 높아졌습니다.
한편, 에이전트 (Agent)가 여러 조직이나 여러 사용자를 가로질러 동작하게 되었을 때, 누구의 목적을 누가 번역할 것인가에 대한 분담은 아직 제대로 정리되지 않았습니다. 멀티 에이전트 (Multi-agent), 멀티 테넌트 (Multi-tenant), 멀티 스테이크홀더 (Multi-stakeholder) 구조가 되면, 목적 설정자 자체가 분산됩니다. 그렇게 되면 단순하게 "인간이 목적을 전달하고 에이전트가 실행한다"라는 구도만으로는 부족해질 것 같다는 느낌이 듭니다. 이 부분은 앞으로 계속 고민해 나가고자 합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Zenn AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기