AI 시대에 더 중요해진 것, 문제를 잘 정의하는 능력
들어가며
요즘은 만드는 속도 자체가 경쟁력이 된 시대처럼 보입니다. 예전에는 하루쯤 걸리던 일이 이제는 한 시간 안에도 얼개가 나옵니다. AI에게 요구사항을 던지면 코드 초안이 나오고, 테스트의 뼈대가 붙고, 리팩토링 방향까지 제안됩니다.
처음엔 저도 자연스럽게 이렇게 생각했습니다.
이제 중요한 건 얼마나 빨리 구현하느냐 아닐까?
그런데 실무와 사이드 프로젝트를 오가며 계속 부딪힌 병목은 다른 곳에 있었습니다. 코드가 안 나와서 멈추는 경우보다, 우리가 지금 무엇을 풀고 있는지 합의하지 못해서 멈추는 경우가 더 많았습니다.
잘못 정의된 문제를 빠르게 푸는 일은 별 의미가 없습니다. 오히려 더 위험할 때도 있습니다. 예전에는 엉뚱한 방향으로 가도 속도가 느려서 중간에 눈치챌 여지가 있었다면, 지금은 그 잘못이 훨씬 빨리 그럴듯한 결과물로 증폭되기 때문입니다.
AI가 구현을 빠르게 만든 건 분명합니다. 하지만 그래서 더 중요해진 것도 분명히 있습니다. 바로, 무엇을 풀어야 하는지 정의하는 능력입니다.
코드는 빨라졌는데, 일은 왜 여전히 어렵지?
AI 코딩 도구를 쓰다 보면 구현의 허들이 낮아졌다는 걸 금방 체감하게 됩니다.
- 대략적인 요구사항만 있어도 기능 초안이 나옵니다.
- 테스트 코드나 반복적인 보일러플레이트는 순식간에 만들어집니다.
- 문서 정리나 리팩토링 제안도 꽤 그럴듯합니다.
문제는 그다음부터였습니다. 막상 더 오래 붙들게 되는 건 코드 작성 자체보다 이런 질문들이었습니다.
- 이 기능은 정말 지금 필요한가?
- 어디까지를 이번 문제의 범위로 볼 것인가?
- 무엇을 기준으로 좋아졌다고 판단할 것인가?
- 사용자의 문제를 푸는 건가, 팀 내부의 불편을 줄이는 건가?
이 질문들은 구현 속도가 빨라졌다고 해서 같이 풀리지 않았습니다. 오히려 구현이 쉬워질수록, 질문이 부실한 상태로 일이 시작될 위험은 더 커졌습니다.
예전에는 구현이 무거워서 시작 전에 한 번 더 생각하게 됐다면, 지금은 “일단 만들어보자”가 너무 쉬워졌습니다. 그리고 그 말은 종종, 문제 정의를 건너뛴 채 달리기 시작했다는 뜻이기도 했습니다.
문제 정의는 생각보다 넓다
예전의 저는 문제 정의를 꽤 단순하게 생각했습니다.
“무엇이 문제인가?”를 한 줄로 적는 일.
그런데 실제로는 그것만으로는 거의 부족했습니다. 지금은 적어도 세 가지가 함께 서 있어야 한다고 느낍니다.
1. 지금 누구의 관점에서 어떤 결정을 내려야 하는가
같은 현상도 누구의 결정 문제로 보느냐에 따라 완전히 다른 일이 됩니다.
개발자는 구현 난이도와 변경 비용을 먼저 볼 수 있고, 디자이너는 흐름이 끊기는 지점을 먼저 볼 수 있고, PM은 일정과 우선순위의 충돌을 먼저 볼 수 있습니다.
그래서 문제를 정의한다는 건 단순히 현상을 적는 일이 아니었습니다. 지금 이 상황에서 누가 어떤 판단을 내려야 하는지 정리하는 일에 더 가까웠습니다.
이게 빠지면 같은 이슈를 보고도 서로 다른 얘기를 하게 됩니다. 누군가는 기술 부채를 말하고, 누군가는 전환율을 말하고, 누군가는 운영 리스크를 말합니다. 각자 틀린 건 아닌데, 같은 문제를 푼다고 보기도 어려워집니다.
2. 어디까지를 이번 문제로 볼 것인가
많은 작업이 꼬이는 이유는 문제를 못 풀어서라기보다, 문제의 경계를 잘못 잡아서라고 느낀 적이 많았습니다.
예를 들어 로그인 이탈률이 높다고 했을 때, 이걸 “인증 구조 개선”의 문제로 볼 수도 있고, “초기 진입 장벽 완화”의 문제로 볼 수도 있습니다.
전자는 백엔드 설계와 보안 흐름으로 향하고, 후자는 게스트 로그인, 온보딩 축소, 첫 경험 최적화 쪽으로 향합니다.
둘 다 말은 됩니다. 하지만 어디까지를 이번 스프린트의 문제로 볼 것인지를 정하지 않으면, 팀은 같은 숫자를 보고도 전혀 다른 답을 만들게 됩니다.
문제를 푼다는 건 종종 정답을 찾는 일보다, 이번에 풀지 않을 것까지 같이 정하는 일이기도 했습니다.
3. 무엇을 좋아졌다고 볼 것인가
이 기준이 빠지면 작업은 끝나고도 끝난 것 같지 않습니다.
- 코드가 더 깔끔해진 것인가?
- 사용자 이탈이 줄어든 것인가?
- 운영 비용이 낮아진 것인가?
- 다음 변경이 더 쉬워진 것인가?
평가 기준 없이 시작한 작업은 거의 반드시 다시 돌아옵니다. 누군가는 좋아졌다고 말하고, 누군가는 아직 아니라고 말합니다.
그래서 지금의 저는 문제 정의를 문장 하나로 보지 않습니다. 누가 판단해야 하는지, 어디까지 풀 것인지, 무엇을 개선으로 볼 것인지를 함께 세우는 일에 더 가깝다고 느낍니다.
AI는 구현을 압축했지만, 책임을 대신 지진 않는다
이 지점에서 개발자의 역할도 조금 달라졌다고 느낍니다. 예전에는 만드는 사람이라는 감각이 더 강했습니다. 직접 구현하고, 직접 디버깅하고, 직접 이어 붙이는 시간이 많았으니까요.
지금도 물론 만듭니다. 다만 그 사이사이에 판단하는 시간이 훨씬 또렷하게 보입니다.
- 어떤 시도를 버릴지
- 어떤 방향을 살릴지
- 어디서 멈출지
- 무엇을 다음 단계로 넘길지
AI는 선택지를 빠르게 늘려줍니다. 하지만 그중 무엇이 맞는지, 무엇이 지금 풀 가치가 있는지, 어디서 멈춰야 하는지는 대신 책임져주지 않습니다.
코드가 돌아간다고 해서 문제가 해결된 것은 아니었습니다. 오히려 더 위험한 경우도 있었습니다. 겉으로는 그럴듯하게 동작하는데, 정작 우리가 풀고 싶었던 문제와는 조금씩 어긋나 있는 경우였습니다.
그래서 요즘은 개발자를 단순히 구현자라고만 부르기엔 부족하다고 느낍니다. 적어도 AI를 적극적으로 쓰는 환경에서는, 구현자이면서 동시에 판단자이고, 필요하면 문제 자체를 다시 정의하는 사람에 더 가까워졌습니다.
좋은 질문이 생산성을 만든다
생산성을 이야기할 때 우리는 종종 출력량부터 봅니다.
- 코드가 얼마나 많이 나왔는가
- 기능이 얼마나 빨리 붙었는가
- PR이 몇 개 만들어졌는가
그런데 실제 체감은 다른 데서 갈렸습니다. 좋은 질문으로 시작한 작업은 AI를 붙였을 때 훨씬 빨리 앞으로 나갔고, 중간에 무너질 가능성도 적었습니다.
반대로 질문이 흐릿한 작업은 초안이 빨리 나와도, 리뷰에서 방향이 흔들리고, 다시 범위를 조정하고, 성공 기준을 뒤늦게 맞추느라 더 많은 시간을 썼습니다.
결국 생산성을 깎아먹는 건 구현 속도 부족이 아니라, 뒤늦은 재정의와 되돌아감인 경우가 많았습니다.
그래서 중요했던 건 “AI를 얼마나 잘 쓰느냐” 이전에, 무엇을 물어야 하는지 아는가였습니다. 이건 단순한 프롬프트 요령의 문제가 아니라, 문제를 좁히고, 우선순위를 정하고, 성공 조건을 언어로 만드는 능력의 문제에 가까웠습니다.
그래서 더 중요해진 사람의 일
AI가 발전할수록 사람의 일이 사라진다기보다, 사람이 끝까지 맡아야 할 일이 더 선명해진다고 느낍니다.
적어도 지금 제게는 그렇습니다.
- 모호한 요구사항에서 진짜 문제를 골라내는 일
- 너무 넓은 과제를 이번 단계의 범위로 좁히는 일
- 산출물보다 결과를 평가할 기준을 세우는 일
- 구현 가능한 답과 풀 가치가 있는 답을 구분하는 일
이런 일들은 구현보다 덜 화려해 보일 수 있습니다. 회의실에서 질문을 정리하고, 문서를 고치고, 같은 말을 다른 표현으로 다시 확인하는 하루는, 겉으로 보면 아무것도 만들지 않은 시간처럼 보이기도 합니다.
그런데 돌아보면 큰 차이는 자주 여기서 났습니다. 코드 한 줄보다 질문 하나가 더 많은 걸 바꾸는 순간이 분명히 있었습니다.
마치며
AI 시대에 더 중요해진 건, 더 빨리 만드는 능력만은 아니었습니다. 오히려 무엇을 만들지, 왜 만들어야 하는지, 무엇을 좋아졌다고 볼지 정하는 능력이 더 중요해졌습니다.
잘 정의된 문제는 구현을 빠르게 만듭니다. 반대로 잘못 정의된 문제는 그 잘못까지 빠르게 키웁니다.
AI는 구현을 압축했습니다. 하지만 책임까지 가져가지는 않았습니다.
그래서 개발자의 역할은 줄어들기보다 바뀌고 있다고 생각합니다. 만드는 사람에서 판단하는 사람으로 완전히 옮겨갔다기보다, 만드는 사람이면서 더 자주 판단해야 하는 쪽으로 움직이고 있다고 느낍니다.
적어도 지금의 저는, 좋은 답을 빨리 내는 사람보다, 좋은 질문을 끝까지 붙드는 사람이 더 오래 남을 거라고 생각합니다.