수탁 개발이나 SES, 프리랜서로 참여하는 것 자체를 부정하고 싶은 것은 아닙니다.

다만, AI를 도입했을 때 정보 단절이나 권한 단절이 더욱 눈에 띄게 나타나지 않을까 하는 이야기입니다.

지난 기사에서는 SES나 다중 하청 구조와 같은 현장에서는 AI를 도입한다고 해서 개발이 즉시 능숙해지는 것은 아니라는 이야기를 썼습니다.

이번에는 그중에서도 특히 크다고 느끼는 「히어링(Hearing, 요구사항 청취) 실수」에 대해 생각해 보겠습니다.

AI 에이전트(AI Agent)를 사용하면 구현은 상당히 빨라집니다.

사양서(Specification)를 읽게 하여 정리할 수도 있습니다.

누락 여부 확인이나 설계안의 비교도 가능합니다.

이것은 정말 편리합니다.

하지만 그럼에도 한계가 있다고 느껴지는 장면이 있습니다.

그것은 애초에 첫 히어링이나 요건 이해(Requirement Understanding)가 틀렸을 경우입니다.

AI는 주어진 정보를 바탕으로 생각하는 것은 잘합니다.

하지만 주어지지 않은 업무 배경이나, 듣지 못한 현장의 사정까지 완전히 보완할 수는 없습니다.

오히려 잘못된 전제를 바탕으로 상당히 자연스러운 설계나 코드를 내놓는 경우가 있습니다.

이 기사에서는 AI 시대의 개발에서 히어링 실수가 어떤 문제가 되는지 나름대로 정리해 보겠습니다.

먼저, AI는 히어링이나 요건 정리에 상당히 도움이 된다고 생각합니다.

예를 들어, 다음과 같은 작업입니다.

• 의사록 정리
• 사양서 요약
• 확인 사항 도출
• 업무 플로우(Workflow) 초안 작성
• 화면 항목의 누락 확인
• API나 DB 설계로의 반영
• 테스트 관점 도출

이러한 작업에서 AI는 상당히 강력합니다.

인간만 사양을 읽고 있으면 놓치는 부분이 생길 수 있습니다.

AI에게 사양서나 의사록을 읽게 하면, "이 조건일 때는 어떻게 됩니까?", "이 항목은 어디에서 업데이트됩니까?"와 같은 확인 사항을 제시해 주기도 합니다.

이는 기존의 개발 방식보다 상당히 좋은 방향이라고 생각합니다.

특히 수탁 개발이나 SES 현장에서는 사양 확인 누락이 나중에 큰 재작업(Rework)으로 이어지는 경우가 있습니다.

따라서 구현 전에 AI로 확인 사항을 도출하는 것만으로도 일정 수준의 효과는 있다고 생각합니다.

반면에 AI도 알 수 없는 것이 있습니다.

그것은 애초에 물어보지 못했다는 점입니다.

예를 들어, 고객사의 현장에서는 당연하게 이루어지는 작업이 있습니다.

하지만 그것이 사양서에는 적혀 있지 않습니다.

히어링에서도 화제로 나오지 않았습니다.

의사록에도 남아 있지 않습니다.

이 경우, AI는 그 작업을 전제로 생각할 수 없습니다.

물론 AI가 "이런 예외 작업은 없습니까?"라고 질문 후보를 제시해 줄 수는 있습니다.

그 점은 매우 유효합니다.

하지만 질문 후보를 낼 수 있는 것과 실제 답을 알고 있는 것은 다릅니다.

AI는 현장에서 무엇이 일어나고 있는지를 직접 보고 있는 것이 아닙니다.

고객이 무엇 때문에 곤란해하는지를 멋대로 정확하게 이해할 수 있는 것도 아닙니다.

그렇기 때문에 첫 히어링에서 중요한 정보가 빠져 있으면, AI도 그 빠진 전제 위에서 생각하게 됩니다.

이 부분이 조금 무서운 지점이라고 생각합니다.

AI는 정보가 부족하더라도 그럴듯한 답을 내놓을 수 있습니다.

예를 들어, 다음과 같은 일이 일어납니다.

• 잘못된 요건을 깔끔하게 정리함
• 부족한 사양을 자연스럽게 보완함
• 그럴싸한 업무 플로우를 작성함
• 그럴듯한 화면 설계를 만듦
• 동작하는 코드를 구현함
• 테스트 케이스까지 준비함

사람이 보기에는 완성도가 상당히 높아 보일 때가 있습니다.

하지만 전제가 틀렸다면 그 완성도는 별 의미가 없습니다.

예를 들어, 실제로는 승인 플로우(Approval Flow)가 2단계인데 1단계라고 생각하여 설계해 버리는 경우.

실제로는 월말에만 특별 처리가 있는데 일반 처리만으로 만들어 버리는 경우.

실제로는 수작업으로 보정하고 있는 업무가 있는데 시스템상에는 존재하지 않는 것으로 취급해 버리는 경우.

이 경우 AI가 아무리 깔끔하게 구현해도 실제 업무에는 맞지 않습니다.

AI의 출력이 자연스럽게 보일수록 전제가 틀렸다는 사실을 알아차리기 어려워질 가능성도 있습니다.

구현 실수는 비교적 찾기 쉬운 경우가 있습니다.

테스트가 실패한다.

화면에서 에러가 발생한다.

타입 체크(Type Check)를 통과하지 못한다.

API의 응답(Response)이 예상과 다르다.

이러한 문제는 도구나 리뷰를 통해 발견할 수 있습니다.

하지만 히어링 실수는 조금 다릅니다.

사양서대로 만들어져 있다.

테스트도 통과한다.

화면도 동작한다.

리뷰에서도 큰 문제는 발견되지 않는다.

그런데도 고객에게 보여주면 "그런 의미가 아니었다"라는 말을 듣게 되는 경우가 있습니다.

이것은 코드의 품질 문제라기보다, 이해하고 있던 업무나 목적이 어긋났다는 문제입니다.

AI를 사용하면 구현 실수 (Implementation error)는 줄일 수 있을지도 모릅니다.

하지만 업무 이해의 차이까지 자동으로 사라지는 것은 아닙니다.

오히려 구현 속도가 빨라짐으로써, 잘못된 이해를 가진 채로 앞으로 나아가기 쉬워지는 경우가 있습니다.

자사 프로덕트라면 사양이 의심스러울 때 즉시 확인할 수 있는 경우가 있습니다.

프로덕트 오너 (Product Owner)에게 묻는다.

업무 담당자에게 묻는다.

옆 팀에 묻는다.

과거의 의사결정을 알고 있는 사람에게 묻는다.

물론 자사 개발이라도 쉽지는 않지만, 질문할 대상이 보이는 경우가 많습니다.

반면, SES나 다중 하청 현장에서는 질문이 전달되기 어려운 경우가 있습니다.

예를 들어, 개발자가 의문이 생겨도 고객에게 직접 물어볼 수 없습니다.

질문은 리더를 거치고, 원청을 거치고, 다시 다른 창구를 거칩니다.

돌아온 답변도 배경이 생략된 짧은 문장이 되어 있습니다.

이렇게 되면 AI가 좋은 확인 사항을 제시해 주더라도, 그것을 올바르게 해소하기가 어려워집니다.

AI가 "이 부분을 확인하는 것이 좋습니다"라고 말합니다.

하지만 현장의 구조상 간단히 확인할 수 없습니다.

이 상태에서는 AI의 힘만으로는 한계가 있습니다.

문제는 AI의 성능이라기보다, 질문이 흐르는 경로와 판단이 돌아오기까지의 구조에 있다고 생각합니다.

개발에서 중요한 정보는 반드시 사양서 (Specification)에 깔끔하게 적혀 있다고 단정할 수 없습니다.

예를 들어, 다음과 같은 정보입니다.

• 왜 그 기능이 필요한가
• 어떤 업무가 가장 곤란한 상황인가
• 무엇을 바꾸면 현장이 어려워지는가
• 어떤 예외 케이스 (Exception case)가 자주 발생하는가
• 과거에 어떤 운용 방식으로 실패했는가
• 이번에는 무엇을 의도적으로 포기했는가
• 장래에 어떤 방향으로 확장하고 싶은가

이러한 정보는 화면 항목이나 API 사양보다 글로 옮기기 어렵습니다.

하지만 설계나 구현의 판단에서는 상당히 중요합니다.

AI에게 사양서만 읽히면, 사양서에 적혀 있는 범위 내에서는 잘 생각해 줍니다.

하지만 사양서에 적혀 있지 않은 배경까지는 알지 못합니다.

따라서 AI 시대에는 사양서 자체도 조금 바꿀 필요가 있을지도 모릅니다.

단순히 "무엇을 만드는가"뿐만 아니라, "왜 만드는가", "무엇을 피하고 싶은가", "어디가 미확정인가"까지 적는 것입니다.

그렇게 하지 않으면 AI는 부족한 배경을 스스로 보완하며 진행해 버립니다.

그렇다면 AI는 히어링 실수 (Hearing error)에 대해 무력한 것일까요?

그렇게까지 비관할 필요는 없다고 생각합니다.

AI는 올바른 답을 멋대로 알아낼 수는 없습니다.

하지만 확인해야 할 사항을 도출하는 용도로는 상당히 유용합니다.

예를 들어, 구현 전에 다음과 같이 의뢰합니다.

이 사양을 바탕으로 구현하기 전에,
업무상 확인해야 할 점, 사양이 모호한 점,
나중에 재작업 (Rework)이 될 것 같은 점을 도출해 주세요.
...

이와 같이 갑자기 코드를 쓰게 하는 것이 아니라, 먼저 질문을 던지게 합니다.

이것만으로도 상당히 달라질 것이라고 생각합니다.

AI는 구현자로서뿐만 아니라, 사양 리뷰 (Specification review)의 상대로 사용하는 편이 더 좋은 상황이 있습니다.

개인적으로는 AI 시대에는 "확인 사항"을 좀 더 정식 산출물 (Deliverable)로 취급하는 것이 좋지 않을까 생각합니다.

기존의 개발에서는 확인 사항이 채팅이나 구두로 흘러가 버리는 경우가 있습니다.

하지만 AI를 사용한다면 확인 사항이 상당히 대량으로 나옵니다.

그것을 그 자리에서 소화하는 것에 그치지 않고, 다음과 같이 남겨두는 것이 좋아 보입니다.

• 확인하고 싶은 내용

• 왜 확인이 필요한가

• 확인 대상

• 답변

• 답변에 따라 변하는 설계

• 미답변 시의 잠정 대응

여기까지 남겨두면 나중에 "왜 이 구현을 했는가"를 추적하기 쉬워집니다.

또한 AI에게 다시 읽힐 수도 있습니다.

AI는 대화 도중 전제를 잊어버리는 경우가 있습니다.

하지만 확인 사항과 답변이 문서로 남아 있다면, 그것을 읽게 하여 작업을 계속하기가 수월해집니다.

AI를 사용하면 즉시 동작하는 것을 만들 수 있습니다.

이것은 큰 장점입니다.

일찍 화면을 보여주고 피드백을 받을 수도 있습니다.

다만, 무엇이든 "만든 다음에 확인"해도 괜찮은 것은 아니라고 생각합니다.

특히 업무 흐름 (Workflow)이나 데이터 구조 (Data structure)의 전제가 틀린 경우, 나중에 수정하는 것은 매우 힘듭니다.

화면의 문구나 배치는 나중에 수정하기 쉽습니다.

하지만 상태 관리 (State management), DB 설계, 권한 설계, 외부 연동, 장표의 전제가 어긋나 있으면 재작업의 규모가 커집니다.

AI로 구현이 빨라질수록, "먼저 확인해야 할 것"과 "만든 다음에 확인해도 좋은 것"을 나눌 필요가 있다고 느낍니다.

모든 것을 처음에 완벽하게 결정할 필요는 없습니다.

다만, 나중에 바꾸면 타격이 큰 전제만큼은 구현 전에 확인하는 것이 좋습니다.

여기서 어려운 점은, 히어링 (Hearing) 실수를 방지할 책임을 업무를 받는 측에만 너무 몰아넣는 것도 옳지 않다는 것입니다.

물론, 받는 측에도 확인할 책임은 있습니다.

모호한 사양 (Specification)을 그대로 구현하지 않고, 질문을 던지는 것은 중요합니다.

하지만, 업무를 주는 측이 배경 정보를 전달하지 못한다면, 받는 측만의 노력으로는 한계가 있습니다.

특히 SES나 다중 하청 구조에서는, 실제로 코드를 작성하는 사람이 업무의 배경에 접근하기 어려운 경우가 있습니다.

그런 상태에서 "AI를 사용하면 알 수 있겠지"라고 생각하게 되면 상당히 위험합니다.

AI를 사용한다면, 발주 측이나 상류 공정 측도 AI가 읽을 수 있는 형태로 정보를 전달할 필요가 있습니다.

예를 들어, 다음과 같은 정보입니다.

• 업무 배경
• 현재의 문제점
• 기존 운용 방식
• 예외 케이스
• 변경해서는 안 되는 사항
• 판단 기준
• 미결 사항

이러한 정보가 있으면 AI는 상당히 사용하기 쉬워집니다.

반대로, 이것들이 없는 상태에서 구현만을 서두르면, AI의 속도가 곧 재작업 (Rework)의 속도가 되어버립니다.

AI 시대에는 히어링 (Hearing)의 가치가 떨어지기는커녕, 오히려 높아지는 것이 아닌가 생각합니다.

왜냐하면, 구현이 빨라질수록 전제의 오류가 그대로 커다란 차이 (Diff)로 이어지기 때문입니다.

AI가 코드를 작성해 준다면, 인간은 코드를 쓰지 않아도 된다.

그렇게 생각하고 싶어지는 장면도 있습니다.

하지만 실제로는, 인간이 해야 할 일은 다른 곳으로 옮겨가는 것이라고 생각합니다.

• 무엇을 확인해야 할지 생각하기
• 누구에게 물어봐야 할지 판단하기
• 답변의 의미를 해석하기
• 업무상의 우선순위를 이해하기
• 사양 (Specification)의 배경을 기록하기
• AI에게 전달할 전제를 정비하기

이러한 부분들은 AI에게 완전히 맡기기 어려운 영역입니다.

AI는 질문을 만들 수는 있습니다.

하지만 그 질문을 누구에게 던질지, 답변을 어떻게 해석할지, 어디까지 사양 (Specification)에 반영할지는 인간 측의 업무로 남습니다.

AI가 히어링 (Hearing) 실수를 완전히 없애주는 것은 아니라고 생각합니다.

다만, 히어링 (Hearing) 실수를 줄이기 위한 보조 도구로서는 상당히 유용하게 사용할 수 있다고 생각합니다.

사양 (Specification)을 정리한다.

확인 사항을 도출한다.

예외 케이스를 찾아낸다.

업무 플로우 (Flow)의 모순을 찾는다.

구현 전에 위험한 전제를 발견한다.

이러한 방식으로 사용한다면 AI는 매우 도움이 됩니다.

한편으로, 애초에 묻지 못한 정보나 현장에만 존재하는 암묵지 (Tacit Knowledge)를 AI가 알아서 올바르게 보충해 주는 것은 아닙니다.

잘못된 전제를 전달하면, AI는 그 전제 위에서 자연스러운 답을 내놓습니다.

그리고 그 답은 언뜻 보기에 매우 잘 만들어진 것처럼 보일 때가 있습니다.

그렇기에 더욱, AI 시대에는 구현 전의 확인이 더욱 중요해진다고 생각합니다.

AI에게 코드를 쓰게 하기 전에, AI에게 질문하게 한다.

사양 (Specification)을 확정하기 전에, 모호한 점을 낱낱이 찾아낸다.

작업을 받는 측뿐만 아니라, 주는 측도 배경을 전달한다.

AI를 잘 활용하기 위해서는 프롬프트 (Prompt) 작성법뿐만 아니라, AI에게 전달할 전제를 만드는 방법을 재검토해야 하는 것이 아닐까요.