개발이 즐겁지 않다는 말을 읽고

Baldur Bjarnason이 2026년 8월 27일에 쓴 블로그 회고 글에는 이런 문장이 나온다.

I don’t enjoy my field any more because the field is gone.

자신의 분야가 사라졌기에 이제 그 분야를 즐길 수 없다는 말이다. 이 문장을 읽고 잠시 멈췄다. 오래 해온 일이 즐겁지 않아졌을 때, 그 이유를 어디에서 찾아야 할까. 내 관심이 달라진 걸까. 아니면 내가 좋아했던 일을 할 여건이 달라진 걸까.

저자는 전자책과 출판, 웹 개발을 오가며 일해왔다. 개발과 관리에 관해 쓰던 그는 생성형 AI를 살펴본 뒤 강한 비판자가 됐다. 오류와 변동성, 동의와 저작권 등 여러 문제를 들어 생성형 AI 자체가 건전한 개발 및 관리와 양립할 수 없다고 본다. 원문의 AI 비판은 상당히 단호하다.

그 결론에 모두 동의하기는 어렵다. AI를 사용하는 작업의 범위도, 결과를 검증하는 방식도 서로 다르다. 모든 사용이 결국 해롭다는 결론을 받아들이려면 그 차이까지 설명할 근거가 필요하다. 특히 개발 교육 시장에서 겪은 어려움만으로 웹 개발 전체가 사라졌다고 판단하기에는 범위가 너무 넓다.

다만 그의 실망을 새로운 도구에 적응하지 못한 반응으로 넘겨버리고 싶지는 않다. 저자는 교육 일감이 줄고 동료들의 사업이 문을 닫는 모습을 전한다. 그러면서도 불필요한 문제에 시달리지 않고 개발에 집중할 때는 여전히 그 일을 좋아한다고 쓴다. 이 대목을 읽으면, 무엇을 만들고 싶은 마음과 그것을 직업으로 지속할 여건 사이의 간격이 보인다.

개발에서 좋아했던 순간을 떠올려보면 코드의 양만으로는 설명하기 어렵다. 이해되지 않던 동작의 원인을 찾거나, 복잡했던 흐름을 단순하게 바꾸거나, 사용자가 막히던 부분을 해결하는 과정에 즐거움이 있다. 그 과정에는 코드를 쓰는 시간만큼 읽고 의심하고 확인하는 시간도 들어간다.

가령 몇 분 만에 화면을 하나 만들었다고 하자. 시연에서는 잘 작동한다. 그런데 네트워크가 끊기면 어떻게 되는지, 권한이 없는 사용자가 접근하면 무엇을 보게 되는지, 같은 버튼을 연달아 누르면 요청이 중복되는지는 아직 모른다. 그 질문에 답하는 일까지 해야 제품을 맡길 수 있다. 처음 화면이 나타날 때의 속도는 전체 작업의 일부다.

그래서 생산성이 좋아졌다는 말을 들으면 어디까지를 작업으로 셌는지부터 확인하고 싶다. 초안을 만드는 데 걸린 시간인지, 검토와 수정까지 포함한 시간인지에 따라 이야기가 달라진다. 생성은 빨라졌는데 검토할 사람이 줄었다면, 그 팀은 늘어난 결과물을 감당할 수 있을까. 도구를 들여올 때 이 부담을 누가 맡는지도 함께 결정해야 한다.

원문에서 또 눈에 들어온 이야기는 비판이 쓰이는 방식이다. 저자는 AI의 사업상 위험을 설명한 책이 일부 컨설턴트에게는 도입을 돕는 자료로 쓰였다고 회고한다. 멈추게 하려고 설명한 위험이 관리 가능한 항목으로 받아들여졌다는 것이다. 그는 이를 계기로 책과 글의 방향을 바꿨다.

여기에는 기술을 설명하는 사람이 생각해볼 문제가 있다. 같은 설명을 읽어도 독자가 이루려는 목적에 따라 행동은 달라진다. 작성자가 오류 가능성을 경고해도, 도입을 이미 결정한 사람은 그 부분을 검토 절차를 추가하라는 조언으로 읽을 수 있다. 위험을 설명하는 일만으로 상대의 목적까지 바꿀 수는 없다.

그렇다고 위험을 자세히 설명하는 일을 포기해야 할까. 나는 계속 설명하는 편이 낫다고 생각한다. 도입 여부를 아직 결정하지 않은 사람에게도, 이미 쓰고 있는 도구를 점검하려는 사람에게도 구체적인 정보가 필요하다. 다만 비용을 지불하는 사람과 이익을 얻는 사람이 다를 때는 그 차이도 적어야 한다. 회사의 처리량이 늘어도 검토자의 일이 감당하기 어려워졌다면, 처리량만으로 그 변화를 평가할 수는 없다.

글의 끝에서 저자는 출판과 기술 사이에서 느꼈던 소외를 돌아본다. 앞으로는 여러 분야의 경계에서 일하는 사람들이 덜 외롭게 느끼도록 돕고 싶다고 쓴다. 마지막 대목은 그래서 앞부분의 강한 비관과 조금 다른 인상을 남긴다. 함께 일하고 이야기할 사람을 다시 찾으려는 마음이 보인다.

이 글을 읽고 나서도 좋아하는 일을 계속하려면 어떤 조건이 필요한가 하는 질문이 개발이 끝났다는 결론보다 오래 남았다. 결과를 직접 이해할 시간이 있는지, 잘못된 선택을 되돌릴 수 있는지, 품질에 관한 우려를 꺼냈을 때 누군가 함께 살펴주는지. 이런 조건이 사라지면 직함은 같아도 하루 동안 하는 일은 꽤 달라질 수 있다.

새로운 도구를 익히는 일과 함께, 그 도구를 쓴 뒤에도 내가 맡은 결과를 설명할 수 있는지 확인하고 싶다. 얼마나 빨리 만들었는지만 묻지 않고 왜 이렇게 만들었는지도 이야기할 수 있는 동료들이 있었으면 한다. 그런 대화를 나눌 수 있을 때 개발을 오래 좋아할 수 있을 것 같다.