AI 시대 개발자의 자리 (5/5) — 호기심의 범위가 능력의 범위가 된다
AI 시대 개발자의 자리 (5/5) — 호기심의 범위가 능력의 범위가 된다
1편에서는 결국 문제해결로 귀결된다고 썼다. 2편에서는 세 직군의 성숙도가 전부 다르다고, 3편에서는 기술로 깊어지는 길과 사업으로 넓어지는 길이 갈린다고 썼다. 4편에서는 토큰이 원가가 되면서 기술 결정이 손익 결정이 됐다고 썼다.
그러면 마지막 질문이 남는다. 그 사람이 될 수 있는지를 무엇이 정하는가.
연차는 아니다. 내가 본 면접에서 연차 자체를 물은 곳은 거의 없었다. 학위도, 다룰 수 있는 언어 개수도 아니었다. 내 결론은 이거다.
앞으로 한 사람의 능력의 범위는, 그 사람이 궁금해한 범위와 거의 같아진다.
1. 병목이 옮겨갔다
예전에는 궁금한 게 생겨도 확인하기까지 비용이 컸다.
| 예전 | 지금 | |
|---|---|---|
| 새 기술이 궁금할 때 | 책 사고, 예제 찾고, 환경 세팅에 며칠 | 질문하고 한 시간 안에 돌려봄 |
| 다른 분야가 궁금할 때 | 그 분야 사람을 찾아야 함 | 개요를 바로 설명받고 틀린 부분만 확인 |
| 만들어보고 싶을 때 | 주말 한 달 | 주말 하루 |
| 안 될 때 | 막히면 거기서 끝 | 막힌 지점을 설명하고 다음 수를 받음 |
이 변화의 결과가 중요하다. "할 수 있는가"가 병목이던 시대에서, "무엇을 할 생각을 했는가"가 병목인 시대로 넘어왔다.
실행이 비쌀 때는 실행력이 실력이었다. 실행이 싸지면 실행력은 기본값이 된다. 그러면 남는 차이는 하나다. 애초에 그걸 해볼 생각을 했는지.
2. AI는 안 물어본 것을 절대 알려주지 않는다
이게 가장 실무적인 이유다.
AI는 질문의 함수다. 내가 던진 범위 안에서만 답한다. 아주 똑똑하게 답하지만, 내가 존재를 모르는 것에 대해서는 아무 말도 해주지 않는다.
같은 도구를 쓰는 두 사람이 이렇게 갈린다.
| 물어본 것 | 받는 것 | |
|---|---|---|
| A | "이 코드 에러 고쳐줘" | 고쳐진 코드 |
| B | "이 코드 에러 고쳐줘" → "왜 이 구조면 이 에러가 나?" → "그럼 이 패턴을 쓰는 다른 곳도 같은 문제야?" | 고쳐진 코드 + 원인 + 같은 문제가 있는 다른 지점 |
둘은 같은 모델을 쓰고, 같은 시간을 쓴다. 결과물의 차이는 순전히 세 번째 질문을 떠올렸는지에서 온다.
그래서 요즘 실력 차이가 예전보다 더 빨리 벌어지는 느낌이 든다. 도구는 평등하게 주어졌는데, 질문의 범위는 평등하지 않기 때문이다.
3. 넓게 가본 게 헛되지 않았던 이유
1편에서 망치 이야기를 했다. 못을 박아야 하는데 망치를 만드는 데 시간을 쓰고 있다고. 그럼 하네스니 루프니 하는 것들을 다 해본 건 낭비였을까.
아니었다. 그리고 이 구분이 이 글에서 제일 중요한 부분이다.
다 해봤기 때문에 "그게 핵심이 아니다"라고 말할 자격이 생겼다. 안 해보고 그 말을 하면 그냥 뒤처진 사람의 변명이 된다. 해보고 나서 하면 판단이 된다.
면접에서도 그랬다. 새 개념에 대한 회의적인 의견을 말했을 때 반응이 좋았던 건 내 의견이 특별해서가 아니라, 직접 해보고 어디서 멈췄는지 구체적으로 말할 수 있었기 때문이었다. 멈춘 지점을 말하면 그건 경험이고, 안 해봤다고 하면 그건 태도다.
핵심은 이거다. 호기심의 범위를 넓히는 비용이 싸졌으니, 넓게 가보는 게 예전보다 훨씬 이득이다. 예전에는 곁눈질이 사치였다. 지금은 곁눈질이 전략이다.
내가 만든 이력서 관리 서비스도 시작이 거창하지 않았다. "내가 지원한 곳을 왜 아직 스프레드시트로 관리하고 있지?" 이 한 문장이었다. 그 질문이 없었으면 서비스도 없고, 1편에서 쓴 도그푸딩 경험도 없고, 이 시리즈도 없다.
4. 호기심과 산만함은 다르다
여기서 조심할 게 있다. 호기심이 능력이 되는 건 조건이 붙는다. 그냥 여기저기 손대는 건 산만함이고, 그건 능력이 안 된다.
| 능력이 되는 호기심 | 되지 않는 호기심 |
|---|---|
| 끝까지 한 번은 가본다 (작더라도 완성) | 시작만 계속 늘어난다 |
| 왜 안 됐는지 한 줄 남긴다 | 재미없어지면 그냥 덮는다 |
| 남에게 보여주고 평가를 받는다 | 혼자만 알고 끝난다 |
| 깊게 파본 경험이 최소 하나 있다 | 전부 표면만 훑는다 |
| 궁금함의 방향이 "못"을 향한다 | 도구를 위한 도구로 계속 빠진다 |
마지막 줄이 1편의 망치 이야기와 연결된다. 호기심 자체가 좋은 게 아니다. 호기심이 실제 문제를 향할 때만 능력이 된다. 도구를 개선하는 재미에 빠지는 것도 호기심이지만, 그건 회사 입장에서 비용이다.
그리고 네 번째 줄도 중요하다. 넓이가 값이 되려면 깊이를 한 번은 경험해봤어야 한다. 하나를 끝까지 파보면 "끝까지 파면 어떤 게 나오는지"를 알게 된다. 그 감각이 있으면 다른 분야를 얕게 훑어도 어디가 진짜 어려운 지점인지 짐작할 수 있다. 그 경험이 없으면 모든 분야가 다 쉬워 보인다.
5. 호기심의 범위를 넓히는 방법
추상적인 이야기로 끝내면 아무 소용이 없으니, 내가 실제로 하고 있는 것을 적는다.
- "왜 이렇게 되어 있지?"를 그때그때 적어둔다. 답을 찾는 건 나중이다. 중요한 건 질문을 흘리지 않는 것이다. 이상하다고 느낀 순간은 하루만 지나면 사라진다
- 가장 작은 버전으로 만들어본다. 목표는 완성이 아니라 "어디서 막히는지" 확인이다. 막히는 지점이 그 분야의 진짜 난이도다
- 막힌 지점을 한 줄로 남긴다. 이게 나중에 판단의 근거가 된다. "해봤는데 여기서 멈췄다"는 문장은 면접에서도, 회의에서도 힘이 있다
- 남에게 보여준다. 1편에서 말한 것처럼, 밖에 나가서 평가받는 것까지가 한 사이클이다
- 한 가지는 계속 깊게 판다. 넓이만 있으면 근거가 없다
여기에 한 가지 더. 글로 남긴다. 이 블로그가 나한테는 호기심의 기록이다. 글 개수가 실력의 증거는 아니지만, 서로 다른 몇 개의 주제를 건드렸는지는 호기심의 범위를 그대로 보여준다. 그리고 그 기록은 나중에 남이 나를 판단할 때 실제로 쓰인다.
6. 그럼 기초는 필요 없어진 걸까
호기심이 전부라고 하면 꼭 나오는 반론이다. 아무것도 모르는 사람이 호기심만 가지고 되겠냐는 것이다. 맞는 지적이고, 내 생각은 이렇다.
기초는 질문의 해상도를 정한다.
같은 화면을 보고도 던질 수 있는 질문이 다르다.
| 기초가 없을 때 | 기초가 있을 때 |
|---|---|
| "느린데요" | "첫 응답이 느린가요, 전체가 느린가요?" |
| "에러 났어요" | "요청이 안 갔나요, 갔는데 응답이 틀렸나요?" |
| "AI가 이상하게 답해요" | "같은 입력에 매번 다르게 답하나요?" |
| "비용이 많이 나와요" | "요청 수가 늘었나요, 요청당 크기가 늘었나요?" |
오른쪽 질문을 던지면 답이 한 번에 온다. 왼쪽 질문을 던지면 대화를 다섯 번 더 해야 한다. AI 시대에 기초가 값을 잃은 게 아니라, 기초의 용도가 "직접 푸는 데"서 "정확히 묻는 데"로 옮겨간 것이다.
그래서 순서가 이렇게 된다. 기초가 질문의 해상도를 만들고, 호기심이 질문의 범위를 만든다. 해상도 없는 범위는 얕고, 범위 없는 해상도는 좁다. 둘 다 필요한데, 예전에는 해상도 쪽에 시간이 다 들어갔고 지금은 범위 쪽에 쓸 시간이 생겼다.
7. 면접에서 호기심은 생각보다 잘 드러난다
이번에 면접을 여러 번 보면서 알게 된 건데, 회사는 호기심을 직접 묻지 않는다. 대신 이런 질문으로 확인한다.
- 최근에 새로 알게 된 것 중에 인상 깊었던 게 뭔가
- 회사에서 시키지 않았는데 해본 일이 있나
- 지금 우리 제품을 쓰면서 이상하다고 느낀 게 있나
- 그 문제를 발견한 계기가 뭐였나
마지막 질문이 특히 그렇다. "어떻게 풀었나"는 실행력을 보는 질문이고, "어떻게 발견했나"는 호기심을 보는 질문이다. 같은 사례를 말해도 발견 과정을 설명할 수 있는 사람과 못 하는 사람이 갈린다.
그리고 세 번째 질문이 나오면 거의 확실하다. 지원자가 회사 제품을 궁금해서 미리 써봤는지를 보는 것이다. 여기서 구체적인 불편함을 하나 말할 수 있으면 그 자체로 답이 된다. 준비를 많이 했다는 신호가 아니라, 궁금해서 만져봤다는 신호라서 힘이 있다.
반대로 이런 답은 잘 안 먹혔다. 새로 알게 된 것을 물었을 때 개념 이름만 나열하는 경우다. 이름은 누구나 안다. 직접 눌러봤다는 이야기가 붙어야 다르게 들린다.
8. 시리즈를 마치며
세 편을 한 줄씩 줄이면 이렇다.
| 1편 | 만드는 것과 쓰는 것은 다르다. 회사가 찾는 건 망치를 잘 만드는 사람이 아니라 못을 박는 사람이다 |
| 2편 | FDE만 직무로 굳었고, AI Native Engineer는 개발자의 기본값이고, GTM Owner는 아직 역할 개념이다 |
| 3편 | 기술로 깊어지는 길과 사업으로 넓어지는 길이 갈리고, FDE가 그 사이에 있다 |
| 4편 | 토큰이 원가가 되면서 모델 선택과 캐시 설계가 그대로 손익 결정이 됐다 |
| 5편 | 그걸 할 수 있는지는 무엇을 궁금해했는지가 정한다 |
AI가 개발자를 대체한다는 말을 나는 이렇게 고쳐 읽는다.
AI는 "시키면 하는 일"을 대체한다. 무엇을 시킬지 정하는 일은 남는다. 그리고 무엇을 시킬지는 무엇을 궁금해했는지가 정한다.
지식은 이제 거의 공짜다. 실행도 많이 싸졌다. 남은 희소 자원은 "이게 왜 이렇게 되어 있지?"라고 묻는 횟수다.
그게 그 사람의 능력의 한계선이 될 거라고 생각한다.
backtodev
A 40-something PM returns to code. Learning, failing, and growing.