왜 'just prompt better'가 작동하지 않을까

Source: Hacker News

이번 주 초에 우리는 “코딩 어시스턴트가 잘못된 문제를 해결하고 있다”라는 글을 게시했으며, 이 글은 해커 뉴스 메인 페이지에 올라가 다양한 산업과 역할의 개발자들로부터 반응을 얻었습니다.

우리는 **40+**개의 설문 응답과 코딩 어시스턴트가 소프트웨어 개발에 미치는 영향에 대한 뜨거운 논쟁을 통해 많은 것을 배웠습니다. 후자는 별도의 글로 다룰 가치가 있으며, 코딩‑에이전트 설정에 대한 모범 사례를 정리한 별도 포스트가 진행 중입니다.

하지만 이번 후속 글에서는 우리에게 중요한 인사이트를 연결해 준 주요 결과에 초점을 맞추겠습니다: AI 도입이 평균적으로 개발 시간이 절감되는 만큼 리뷰, 재작업, 재조정 작업에 소요되는 시간이 증가한다는 점 (Atlassian, 2025). 우리는 전체 제품 수명 주기 전반에 걸친 마찰 지점을 보여 주기 위해 논평자들의 직접적인 사례를 활용할 것입니다.

발견 1: 커뮤니케이션 마찰이 핵심 고통 포인트

우리는 개발자들에게 물었습니다:

• 언제 코드가 사람들이 생각하는 대로 작동하지 않는다는 것을 발견합니까?
• 누가 기술적 제약을 발견했을 때 알아야 합니까?

왼쪽: 기술 제약의 3분의 1이 이미 제품 대화에 포함되어 있었습니다. 오른쪽: 이러한 제약의 70 %는 코드베이스와 정기적으로 상호작용하지 않는 사람들에게 전달되어야 합니다.

이 차트들을 종합하면, 우리가 다루고 있는 문제의 깊이 있는 교차 기능적 특성을 드러냅니다.

관찰 1 – 계획 단계에서 발견된 제약

제약의 3분의 1이 계획 세션(스프린트 계획, 제품‑엔지니어링 동기화, PM과의 1:1) 중에 발견됩니다. 좋은 소식처럼 들리지만—문제는 전체 맥락에 있습니다. 작은 결정은 제품 제약을 발견한 설계/엔지니어링에 의해 내려져야 하지만, 이를 이해관계자에게 전달하는 일은 어렵고, 시간도 많이 걸리며, 종종 비효율적입니다.

제약을 드러내는 것이 어려운 이유

논평가들은 두 가지 일반적인 도전 과제를 지적합니다:

1. 복잡한 기술적 의존성을 즉석에서 명확히 표현하기
2. 그러한 의존성을 비즈니스 영향으로 번역하여 제품 범위 결정에 실질적인 변화를 주는 것

“시니어 엔지니어는 ‘간단한 필터’가 세 개의 마이크로서비스에 영향을 미친다는 것을 기억할 수 있습니다. 중급 엔지니어는 그렇지 못합니다 — 기술이 부족해서가 아니라 인지 부하가 비현실적이기 때문입니다.”

“나는 반박할 수 있지만, 때로는 효과가 있고, 때로는 그들이 정치적 이유로 기술적 문제를 무시하기도 해서 결국 항상 내 문제로 남게 됩니다.”

**70 %**의 기술 제약이 코드베이스와 정기적으로 상호작용하지 않는 사람들에게 전달되어야 할 때, 알려진 문제는 고통이 나중에 드러날 때까지 해결되지 않는 경우가 많습니다.

관찰 2 – 구현 단계에서 발견된 제약

**50 %**의 제약이 구현 중에만 발견된다면? 왜 이렇게 많이 발생하고 어떻게 해결될까요?

• 제품 회의는 종종 세부 사항에 대해 ‘대강’ 접근합니다. 작고 부적절한 가정이 프로젝트를 가장 크게 지연시킵니다.
• 이러한 문제는 직접 코딩을 시작할 때 비로소 발견됩니다. 변수와 함수 호출을 살펴보다가 다른 곳의 프로세스가 변경된 것을 갑자기 떠올립니다.
• 제품 회의가 기능 사양을 대략적으로 다루기 때문에, 일부 기술적 골격이 마련된 후에야 엔지니어링 현실과 제품 요구사항 사이의 정확한 충돌이 드러납니다. 즉, 악마는 세부에 있습니다.

응답자들이 말하는 하위 단계 재조정이 비싼 이유

• “구현 중에 발생하는 문제들 때문에 제품 팀이 항상 질문에 답변할 수 있는 것은 아닙니다.”
• “[어려움] 아이디어와 목표가 성공적으로 전달되고 모든 관련자가 이를 이해했는지 확인하는 것—특히 모든 작업이 완료되었음을 확인하는 단계(QA, UAT 등)에서.”

이러한 불만은 발견된 제약에 대한 결정이 파편화된 문서화로 인해 더욱 악화됩니다:

요약하면, 개발자 불만의 핵심은 커뮤니케이션 마찰에 있습니다. 개발자는 발생할 수 있는 문제를 직감하지만, 이를 의사결정자에게 전달하기 어렵거나 자신의 주장을 뒷받침할 증거가 부족해 하위 단계에서(반복 대화와 재작업) 훨씬 더 큰 비용이 발생한다는 것을 알고 있습니다.

메시지는 명확하고 크게 들립니다: what

필요한 것은 또 다른 코드‑분석이나 문서화 도구가 아니라, 탄약처럼 교차 기능 정렬을 상류에서 추진하기 위한 것입니다.

발견 2: 문제는 AI가 좋은 코드를 작성하지 못하는 것이 아니라 — 나쁜 코드를 거부하지 못한다는 것이다

우리 이니셔티브의 동기는 AI 도입이 위에서 제시된 문제들을 악화시킬 것이라는 점을 점점 깨달은 것이었습니다. 사용자 의견을 면밀히 살펴봄으로써 코딩 어시스턴트가 정렬 불일치의 비용을 어떻게 증폭시키는지 정확한 메커니즘을 밝혔습니다.

우리는 AI에 의존한 소프트웨어 개발의 한계를 강조하는 통찰력 있는 의견으로 시작합니다:

“AI가 실패하는 곳 …” (전체 설문 데이터에 이어지는 원본 댓글)

(이 섹션의 나머지 부분에서는 해당 댓글을 확장하고, 숨겨진 제약을 도입하는 AI‑생성 코드의 구체적인 예시를 제시하며, 하위 커뮤니케이션 오버헤드를 완화할 방안을 제안합니다.)

“우리는 비즈니스를 개선하기 위해 새로운 소프트웨어를 구축합니다. 작업은 절대 명확하게 정의되지 않습니다. 때때로 개발자는 계획된 것보다 더 나은 비즈니스 프로세스를 제시하기도 합니다. AI는 코드를 작성할 수 있지만, 먼저 왜 X를 먼저 하는 것이 더 나은 아이디어가 아닌지 설명을 듣지 않으면 코드를 작성하지 않으려 하지 않습니다.” — Quothling

코딩 에이전트는 설계상 수용적이도록 만들어졌습니다. 권한이나 넓은 맥락이 부족해 프롬프트에 반박하지 못합니다. 대부분은 명시된 내용에 대해 명확히 물어볼 뿐이며, “잠깐, X를 대신 고려해 보셨나요?”라고 말하지 않습니다. 인간 개발자는 그런 플래그를 올릴 수 있지만, LLM은 그럴듯한 출력을 내고 바로 진행합니다.

이 특성은 가상 비서에게는 유용할 수 있지만, 훌륭한 엔지니어링 팀원으로서는 부적합합니다. 생산적인 갈등에 참여하려는 자세는 좋은 엔지니어링의 핵심이며, 아이디어 설계 공간을 넓히는 역할을 합니다.

“그냥 프롬프트를 더 잘!” – 왜 한계가 있는가

여러 논평가들이 “그냥 프롬프트를 더 잘!”이라고 답했습니다.

• LLM은 요청받은 대로 정확히 수행합니다. 질문을 하고, 요구사항의 구멍을 찾아내며, 바로 코드를 작성하지 말라고 지시하면 그대로 따릅니다.
• 하지만 우리 설문 조사에 따르면 개발자의 50 %가 구현 과정에서 제약을 발견합니다. “그냥 프롬프트를 더 잘”이라는 입장은 프롬프터가 제품과 기술 제약이 어떻게 충돌할지 정확히 알고 있다고 가정합니다—하지만 우리는 많은 제약이 교차 기능 대화를 통해 반복적으로 드러난다는 것을 반복적으로 확인했습니다.

인간은 프로세스가 깨질 수 있는 상황을 상상할 수 있습니다. Claude(및 다른 LLM)도 설명된 프로세스 내부에서 발생하는 파손에 대해서만 동일하게 할 수 있으며, 이를 명시적으로 지정해야 합니다. 외부 프로세스에서 발생할 미래 문제는 해당 외부 프로세스를 상세히 기술하지 않으면 추론할 수 없습니다 — adithyassekhar.

실제 실험에서 얻은 교훈

Cursor 팀은 최근 장기 자율 코딩 에이전트를 실험했습니다. 초기 시도는 에이전트가 지시를 문자 그대로 해석하고 “희귀한 경로”로 빠져버려 실패했습니다 — Cursor blog. 계획 단계에서 인간 개입이 필요했으며, 이는 에이전트가 기대대로 동작하도록 전체적인 이해를 주입하기 위함이었습니다.

기업 환경에서는 문제가 더욱 두드러집니다.

• 비즈니스 요구사항은 불명확하지만 정밀도가 필수입니다.
• 전체 사양이 단일 문서에 포함되지 않고, 코드베이스, 제품 매니저의 머릿속 모델, 마케터의 약속, 여러 Slack 스레드 등에 흩어져 있습니다.

코드 생성 자동화는 맥락 교환을 의사결정 지점에서 하류로 옮길 뿐이며, 중요한 발견 단계가 생략됩니다.

핵심 긴장 관계

요컨대, AI는 구현 속도를 높이지만 제약이 발견되는 과정을 우회하여 모델이 좋은 결과를 내기 위해 필요한 제품 맥락을 제한합니다. 전형적인 닭‑달걀 문제입니다.

제품 회의에서 가치 끌어내기

우리 사용자 연구는 다음과 같은 중심 긴장을 보여줍니다.

• 기술 제약은 교차 기능 정렬이 필요하지만, 이해관계자 회의에서 이를 전달하기는 맥락 격차와 인지 부하 때문에 어렵습니다.
• 코드 생성은 구현 단계 자체를 잠식합니다. 이 단계에서 추가 제약이 발견되었는데, 이제 그 발견 부담이 코드 리뷰로 이동합니다—여기서는 해결이 더 어렵고 비용도 많이 듭니다.

앞으로의 방향

맥락 문제는 시작 단계에서—제품 회의 중—해결되어야 합니다. 교차 기능 참여자들이 재작업 비용을 발생시키지 않고 아이디어를 제시할 수 있도록 말이죠. AI가 그 과정에 동반한다면…

les the implementation, the planning phase must absorb the discovery work that manual implementation used to provide.

구현을 수행하려면, 계획 단계는 수동 구현이 제공하던 탐색 작업을 흡수해야 합니다.

Achieving this will not be easy. We face a uniquely interdisciplinary challenge that touches both:

1. Human aspects – creating artifacts that non‑technical team members can easily digest to drive alignment.
2. Technical aspects – performing counterfactual analysis to surface potential gaps.

이를 달성하는 일은 쉽지 않을 것입니다. 우리는 인간적인 측면과 기술적인 측면 모두에 걸친 독특한 학제간 과제에 직면해 있습니다:

1. 인간적 측면 – 비기술 팀원들이 쉽게 이해하고 정렬을 이끌어낼 수 있는 산출물을 만드는 것.
2. 기술적 측면 – 잠재적인 격차를 드러내기 위해 반사실 분석을 수행하는 것.

Nevertheless, we are optimistic. As code‑generation models improve, we can bootstrap them for the inverse problem: surfacing constraints. Our role is to build tooling that ensures human developers—who excel at creative problem‑solving—remain on top.

그럼에도 우리는 낙관적입니다. 코드 생성 모델이 개선됨에 따라, 우리는 역 문제, 즉 제약 조건을 드러내는 작업을 위해 이를 부트스트랩할 수 있습니다. 우리의 역할은 창의적인 문제 해결에 뛰어난 인간 개발자들이 여전히 중심에 설 수 있도록 하는 도구를 구축하는 것입니다.

If this mission resonates with you, please drop by and share suggestions or feedback at our Google Group. We would especially appreciate help in architecting our agent harness!

이 사명이 여러분에게 공감된다면, 우리 Google Group 에 방문해 의견이나 피드백을 공유해 주세요. 특히 에이전트 하네스를 설계하는 데 도움을 주시면 감사하겠습니다.