AI 시대, 개발자의 해자는 문제를 발견하는 능력에 있다

AI가 발전하면서 직무의 경계가 빠르게 흐려지고 있다.

예전에는 기획자가 요구사항을 정의하고, 디자이너가 화면을 만들고, 개발자가 그것을 구현하는 식으로 역할이 비교적 명확하게 나뉘어 있었다.

하지만 이제는 다르다.

PM도 AI를 이용하면 간단한 서비스를 직접 만들 수 있고, 개발자도 디자인이나 기획 업무를 어느 정도 수행할 수 있다. 디자이너 역시 코드를 몰라도 인터랙션이 포함된 프로토타입을 만들 수 있다.

그렇다면 이런 시대에 개발자가 가진 '해자', 즉 비개발자와 차별화되는 포인트는 무엇인가?

단순히 "개발을 더 잘한다"는 답은 충분하지 않다.

코드를 더 빠르게 짜고, 알고리즘을 더 많이 알고, 프레임워크를 더 능숙하게 사용하는 것이 어떤 실질적인 차이를 만들어내는지를 설명해야 한다.

나는 개발자의 해자를 크게 두 가지로 나눠볼 수 있다고 생각한다.

하나는 누군가 정의한 문제를 더 잘 해결하는 능력이고,

다른 하나는 아직 정의되지 않은 문제와 가능성을 발견하는 능력이다.

이 글에서는 두 번째에 대해 이야기해보려고 한다.

주어진 요구사항 밖을 보는 능력

일반적인 제품 개발 과정을 단순화하면 다음과 같다.

PM이 문제를 발견한다.

"사용자가 이런 부분에서 불편을 겪고 있는 것 같다."

그 문제를 요구사항으로 만든다.

"이런 기능을 추가하면 좋겠다."

그리고 개발자는 이를 구현한다.

이 구조에서는 개발자의 역할이 기본적으로 solution provider에 가깝다.

문제는 이미 정의되어 있고, 개발자는 그것을 어떻게 구현할지를 고민한다.

AI가 빠르게 발전하면서 가장 강하게 자동화되고 있는 것도 바로 이 영역이다.

"이 API를 만들어줘."

"이 화면을 구현해줘."

"이 데이터를 가공해줘."

라고 요구하면 AI가 상당한 수준의 결과물을 만들어낸다.

물론 아직 복잡한 시스템에서는 개발자의 판단과 검증이 필요하다. 하지만 적어도 이미 잘 정의된 문제를 코드로 변환하는 비용은 계속 떨어지고 있다.

그렇다면 개발자는 어디에서 더 큰 가치를 만들 수 있을까?

문제가 개발자에게 전달되기 전에 개입하는 것이다.

즉,

"어떻게 만들 것인가?"

뿐만 아니라

"애초에 무엇을 만들어야 하는가?"

를 생각하는 것이다.

기술을 깊게 알면 다른 문제가 보인다

여기서 개발자가 가진 독특한 강점이 생긴다.

어떤 기술을 깊이 이해하면 단순히 그 기술을 잘 사용할 수 있게 되는 것이 아니다.

세상을 보는 방식 자체가 달라진다.

예를 들어 어떤 제품에서 사용자가 반복적으로 비슷한 작업을 하고 있다고 해보자.

PM의 눈에는 이것이 UX 개선 문제로 보일 수 있다.

"클릭 횟수를 줄이면 되지 않을까?"

하지만 개발자의 눈에는 전혀 다른 문제가 보일 수 있다.

"이 작업은 사실 사용자가 직접 할 필요가 없는데?"

여기서 자동화라는 새로운 해결 방향이 나온다.

또 어떤 서비스에서 사용자가 계속 검색하고 필터링하면서 원하는 정보를 찾고 있다고 해보자.

표면적인 해결책은 검색 UI를 개선하는 것이다.

하지만 데이터 구조와 AI 기술을 이해하는 개발자는 이렇게 생각할 수도 있다.

"사용자가 직접 찾게 하는 대신 시스템이 필요한 순간에 먼저 보여줄 수 있지 않을까?"

같은 현상을 보고도 전혀 다른 제품을 상상하게 되는 것이다.

이 차이는 단순히 개발자가 더 창의적이어서 생기는 것이 아니다.

기술적으로 가능한 것에 대한 지식이 문제를 인식하는 방식에 영향을 미치기 때문이다.

기술은 해결책이 아니라 새로운 문제를 발견하는 렌즈다

우리는 보통 기술을 문제를 해결하기 위한 도구라고 생각한다.

문제가 먼저 있고,

그 문제를 해결하기 위해 데이터베이스나 AI, 분산 시스템 같은 기술을 선택한다.

하지만 실제로는 반대 방향도 존재한다.

새로운 기술을 알게 되면서 이전에는 문제라고 인식하지 못했던 것을 문제로 보기 시작한다.

스마트폰이 없던 시절에는

"왜 길에서 컴퓨터를 사용할 수 없지?"

가 중요한 문제는 아니었다.

GPS와 모바일 인터넷이 보편화되자 위치 기반 서비스라는 거대한 제품 공간이 열렸다.

LLM도 마찬가지다.

예전에는 사람이 읽고, 분류하고, 요약하고, 판단해야 했던 수많은 작업이 너무 당연해서 굳이 "문제"로 인식되지 않았다.

기술의 비용 구조가 바뀌자 갑자기 질문할 수 있게 됐다.

"이걸 왜 사람이 직접 하고 있지?"

기술을 깊게 이해하는 사람은 이런 질문을 더 일찍 할 수 있다.

그래서 개발자의 기술적 깊이는 단순히 더 어려운 것을 구현하기 위한 능력에 그치지 않는다.

어떤 것이 이제 가능해졌는지를 남들보다 먼저 알아차리는 능력이기도 하다.

가장 좋은 개발자는 요구사항을 그대로 받지 않는다

개발을 하다 보면 이런 요구사항을 자주 받는다.

"이 버튼을 하나 추가해주세요."

요구사항만 놓고 보면 일은 명확하다.

버튼을 추가하면 된다.

하지만 좋은 개발자는 때때로 한 단계 뒤로 간다.

왜 이 버튼이 필요한지 묻는다.

버튼을 누른 뒤 사용자는 무엇을 하려는지 묻는다.

왜 그 작업을 지금 사용자가 직접 해야 하는지 묻는다.

그러다 보면 처음 전달된 요구사항과 전혀 다른 해결책이 나오는 경우가 있다.

버튼 하나를 추가해달라는 요청이었는데 버튼 자체가 필요 없어질 수도 있다.

사용자가 직접 수행하던 작업을 자동화할 수도 있고,

다른 데이터로 미리 추론할 수도 있고,

애초에 그 단계가 필요 없는 구조로 제품을 바꿀 수도 있다.

여기에는 중요한 차이가 있다.

첫 번째 개발자는 요구사항을 구현해야 할 명세로 본다.

두 번째 개발자는 요구사항을 문제가 존재한다는 하나의 신호로 본다.

나는 AI 시대에 두 번째 유형의 개발자가 훨씬 중요해질 것이라고 생각한다.

PM의 역할을 개발자가 가져가야 한다는 이야기는 아니다

여기서 오해하기 쉬운 부분이 있다.

개발자가 제품의 문제를 발견해야 한다고 해서 개발자가 PM을 대체해야 한다는 이야기는 아니다.

PM이 가지고 있는 강점과 개발자가 가지고 있는 강점은 다르다.

PM은 사용자, 시장, 사업, 조직 등에서 문제를 발견한다.

개발자는 기술과 시스템이라는 관점에서 다른 종류의 문제를 발견할 수 있다.

예를 들어 PM은

"사용자가 이 작업을 어려워한다."

를 발견할 수 있다.

개발자는

"우리가 이미 가지고 있는 데이터라면 이 작업 자체를 없앨 수 있다."

를 발견할 수 있다.

둘 중 하나가 더 우월한 것이 아니다.

보는 방향이 다른 것이다.

그래서 직무의 경계가 흐려진다는 것은 모든 사람이 같은 일을 하게 된다는 뜻이라기보다,

서로 다른 전문성을 가진 사람들이 문제 정의 단계에 더 많이 참여하게 된다는 의미에 가까울 수 있다.

AI가 강해질수록 문제 발견의 가치가 커진다

AI가 발전할수록 구현 비용은 떨어진다.

예전에는 어떤 아이디어가 있어도 그것을 직접 만들어보려면 상당한 개발 비용이 필요했다.

그래서 무엇을 만들 것인지보다 어떻게 만들 것인지가 큰 제약이었다.

하지만 구현 비용이 계속 낮아진다면 병목은 다른 곳으로 이동한다.

만드는 것이 어려운 게 아니라,

무엇을 만들어야 하는지 알아내는 것이 어려워진다.

누구나 빠르게 기능을 만들 수 있다면 기능을 만드는 것 자체는 더 이상 큰 차별점이 되지 않는다.

대신 중요한 것은

• 어떤 문제를 선택할 것인가
• 사람들이 당연하게 받아들이는 불편 중 무엇을 없앨 수 있는가
• 새롭게 가능해진 기술로 어떤 행동 자체를 제거할 수 있는가
• 아직 요구사항으로 표현되지 않은 니즈가 어디에 있는가

가 된다.

그리고 개발자가 기술을 깊게 공부해야 하는 이유 역시 여기에서 다시 설명할 수 있다.

단순히 AI보다 코드를 잘 짜기 위해서가 아니다.

기술적 깊이가 내가 발견할 수 있는 문제의 종류를 넓혀주기 때문이다.

개발자의 해자는 '가능성의 지평'을 넓히는 것일지도 모른다

AI 시대에도 개발자가 계속 깊은 기술적 역량을 가져야 하는 이유는 무엇일까?

예전처럼 모든 코드를 직접 작성해야 하기 때문만은 아닐 것이다.

오히려 중요한 것은

기술을 깊게 이해할수록
세상에서 "바꿀 수 있는 것"이 더 많이 보인다는 점이다.

다른 사람에게는 당연한 제약이 개발자에게는 제거할 수 있는 제약으로 보일 수 있다.

다른 사람에게는 사람이 해야 하는 일로 보이는 것이 자동화 가능한 작업으로 보일 수 있다.

다른 사람에게는 기존 방식 안에서 개선해야 하는 문제로 보이는 것이 개발자에게는 아예 다른 구조로 다시 만들 수 있는 문제로 보일 수 있다.

결국 개발자의 해자는 단순히 더 많은 문제를 해결할 수 있다는 것이 아니다.

어쩌면 더 중요한 해자는

다른 사람이 아직 문제라고 생각하지 않는 것을 문제로 발견하고,
다른 사람이 아직 가능하다고 생각하지 않는 것을 가능성으로 발견하는 능력

일 수 있다.

AI가 답을 만들어주는 능력을 빠르게 민주화하고 있다면,

앞으로 더 희소해지는 것은 좋은 답을 만드는 능력보다

좋은 질문을 발견하는 능력일지도 모른다.