더 많이 만들 수 있는데, 왜 예전만큼 뿌듯하지 않을까
“예전에는 이것보다 훨씬 작은 걸 만들고도 좋아했는데.”
최근 작업을 마치고 든 생각입니다.
지금은 더 많이 알고, 더 복잡한 서비스도 만들 수 있습니다. AI와 함께라면 엄두도 못 냈을 일까지 해냅니다.
그런데 결과물을 보는 마음은 예전과 다릅니다.
개발을 시작했을 때는 작은 기능 하나가 의도대로 움직이는 것만으로도 신기했습니다. 며칠을 고민해 문제를 해결하면, 누가 알아주지 않아도 뿌듯했습니다.
지금은 먼저 찾아봅니다. 이미 잘 만들어진 것은 없는지, AI라면 어떻게 해결하는지. 제가 오래 고민한 것보다 더 좋은 답이 있을 때가 많습니다.
그 답을 가져다 쓰는 게 합리적입니다. 제가 직접 설계하며 놓친 문제를 발견하기도 합니다. 그런데 더 좋은 결과를 얻고도 허무할 때가 있습니다.
‘내가 문제를 해결한 걸까, 남이 해결한 문제를 잘 찾아낸 걸까.’
더 많은 일을 하게 됐는데, 내 생각과 실력이 어디에 있는지 헷갈립니다.
AI에게 일을 맡길 때도 그렇습니다. 한 번은 AI의 검사가 모두 통과했습니다. 나중에 보니 실제 서비스와 다른 버전으로 검사하고 있었습니다. 초록색 표시에 안심했지만, 필요한 조건이 확인됐는지는 모르고 있었던 겁니다.
돌아간다는 말만 믿고 싶지는 않습니다. 그러면 구현 하나하나를 파고들고, 모든 과정을 이해하는 데 시간을 써야 할까요.
제가 신경 쓸 건 구현만이 아니었습니다. 서비스가 실제로 필요한 문제를 해결하는지, 사람들이 어디서 불편을 겪는지, 한 번 찾아온 사용자가 왜 다시 오지 않는지도 알아야 합니다.
문득 회사 대표가 떠올랐습니다.
모든 부서원의 일과 결과물이 만들어진 과정을 하나하나 아는 사람이 좋은 대표일까요?
세부 사항을 이해하는 건 중요합니다. 하지만 거기에만 집중하느라 회사가 어디로 가고 있는지, 고객이 무엇을 원하는지 놓친다면 어떨까요.
AI에게 컨텍스트의 한계가 있듯, 사람의 시간과 집중력에도 한계가 있습니다. 한 부분을 깊이 들여다보는 동안 다른 곳에 쓸 여유는 줄어듭니다.
중요한 건 모든 것을 아는 게 아니라, 무엇을 직접 이해하고 확인해야 하는지, 어디에 집중해야 하는지 선택하는 일인지도 모르겠습니다.
중요한 구현은 이해하고 검증해야 합니다. 동시에 그것들이 모여 어떤 서비스를 만들고, 사용자에게 어떤 가치를 주는지도 살펴야 합니다.
어쩌면 제가 바꿔야 하는 건 개발 방식만이 아니라 뿌듯함을 느끼는 기준일지도 모르겠습니다.
구현 하나하나를 직접 해결했는지만 바라보는 대신, 그것들이 모여 어떤 서비스를 만들었는지. 그리고 그 서비스가 누군가에게 어떤 가치를 주는지까지 보는 것.
예전처럼 작은 문제를 직접 해결했을 때의 즐거움은 여전히 소중합니다. 하지만 AI가 앞으로 더 많은 것을 구현해 줄수록, 저도 조금 더 큰 그림에서 성취를 찾는 연습이 필요할 것 같습니다.
내가 얼마나 많은 코드를 직접 만들었는지가 아니라, 한정된 시간과 집중력을 어디에 쓰고, 그 선택으로 어떤 결과를 만들어냈는지로요.