AI가 소프트웨어 개발을 흔들면서 개발자들 사이에서 부쩍 자주 들리는 말이 있다. "LLM이 코딩은 잘할지 몰라도, 원래 소프트웨어에서 코드는 어려운 부분이 아니었다"거나 "코딩은 쉽고, 무엇을 만들지 정하는 게 어렵다"는 주장이다. 얼핏 겸손하고 통찰력 있어 보이지만, 개발자 senko는 이런 화법이 오히려 프로그래머 전체에 대한 모욕에 가깝다고 지적한다. 그의 글은 답을 제시하기보다, 지금 업계에 퍼진 자기 위안(cope)의 언어를 걷어내고 실무자가 직면한 변화를 정직하게 보자고 요구한다.
'코딩은 쉽다'는 말의 자기모순
필자의 반박은 일련의 질문 형태로 이어진다. 코딩이 쉬웠다면 왜 프로그래머는 저금리 시대 이전부터도 높은 수요와 연봉을 누렸는가. 왜 AI가 5,000줄짜리 PR을 쏟아내기 훨씬 전부터 과로와 번아웃이 만연했는가. 왜 기업은 이른바 '10배 개발자'를 찾아 리트코드 면접으로 검증했고, 갓 졸업한 신입은 그 자리를 쉽게 채우지 못했는가. 『클린 코드』나 『실용주의 프로그래머』 같은 두꺼운 책, 크누스의 『컴퓨터 프로그래밍의 예술』, SICP, 그리고 수많은 부트캠프와 학위 과정은 왜 존재하는가. 코드가 하찮다면 왜 사람들은 자기 코드가 복제될 때 분노하며, 왜 그토록 많은 소프트웨어가 여전히 버그투성이인가.
반대편 주장, 즉 '무엇을 만들지 정하는 것이 진짜 어렵다'는 명제에도 필자는 같은 방식으로 칼을 들이댄다. 정말 그것이 핵심 난제라면 왜 상당수 프로덕트 매니저는 헤매는 것처럼 보이고, 왜 그들에게는 개발자만큼 까다로운 다단계 면접이 없으며, 왜 더 높은 보수를 받지 않는가. 시장 조사자, 사용성 전문가, 고객 성공 담당자, 비즈니스 분석가가 소프트웨어 회사에서 록스타 대접을 받지 못하는 현실은 이 명제와 어긋난다. 영업이 고객에게 새 기능을 약속해 계약을 따내면, 그것이야말로 진짜 수요를 발굴한 것인데도 개발자들이 화를 내는 것 역시 마찬가지다.
개발자들이 스스로에게 하는 이야기들
필자가 관찰한 개발자들의 정체성 서사도 도마 위에 오른다. 현실의 많은 프로그래머는 이해관계자나 고객과 대화하기를 그리 원하지 않으며, '우선순위를 명확히 한다'는 말은 실제로는 '무엇을 할지 정해주고 이틀마다 바꾸지만 말라'는 요구에 가깝다고 그는 꼬집는다. "나는 코드를 짜는 게 아니라 고객의 문제를 푼다"고 말하면서도 정작 고객 이해는 지어낸 사용자 페르소나 수준에 머무는 경우, 반대로 "소프트웨어 개발은 이론 구축이며 프로그램은 곧 증명"이라며 모든 커밋이 이야기를 담아야 한다고 믿는 장인주의 사이에서, 두 가지를 동시에 진심으로 해내는 사람은 드물다는 것이다. 필자는 장인정신과 고객 공감을 함께 갖춘 개발자가 존재함을 부정하지 않되, 우리가 지향해야 할 지점은 결국 '무엇을 만드는가에 대한 깊은 이해'와 '왜 만드는가에 대한 깊은 이해' 양쪽이라고 정리한다.
핵심은 어느 한쪽을 폄하하는 태도 자체가 문제라는 점이다. "코드는 쉽다"는 말도, 정반대로 "코드는 자동화할 수 없는 인간의 예술"이라는 말도, 필자가 보기엔 모두 현실을 외면한 자기 위안이다. 그리고 위안은 생존을 보장하지 않는다. 그가 원하는 것은 위안이 아니라 번영이다.
변하는 것과 변하지 않는 것
다만 그가 말하는 '번영'은 LLM 열차에 무작정 올라타라거나, AI 에이전트 부대의 관리자가 되라는 뜻이 아니다. 동시에 'AI 코드는 훔친 쓰레기이니 끝까지 싸우면 거품은 알아서 꺼진다'는 반대편 냉소도 아니다. 그는 업계가 지각변동의 한가운데 있음을 인정하고, 무엇이 바뀌고 무엇이 결코 바뀌지 않는지를 구분하자고 제안한다. 변하지 않는 축은 분명하다. 소프트웨어는 더 복잡해지고, 비트로트와 엔트로피 탓에 유지보수는 영원히 필요하며, 추상화의 탑은 계속 높아진다. 사용자는 늘 더 많은 것을 원하면서 더 적게 지불하려 하고, 자신이 무엇을 원하는지조차 정확히 모른다. 비용을 내는 고객과 실제 사용하는 사용자 사이의 간극, 그리고 과대광고를 파는 장사꾼도 사라지지 않는다.
동시에 기술은 늘 바뀌어 왔고 그 변화를 주도한 것은 다름 아닌 프로그래머 자신이었다. 이제 아무도 천공카드를 쓰지 않고 어셈블리나 코볼을 다루는 사람도 드물다. C·C++에서 메모리 버그와 싸우며 얻은 상처는 러스트·고·파이썬·자바스크립트의 시대에 상당 부분 무의미해졌고, valgrind나 PHP4 시절의 mysql_real_escape_string() 같은 지식도 필자에게는 다시 쓸 일 없는 유물이 되었다. 변화가 일어난다는 사실 자체를 받아들이되, 새로운 것에 호기심과 비판 정신을 균등하게 가지라는 것이 그의 조언이다. 과장과 실제로 작동하는 것을 구분하고, 매년 옮겨가는 골대에 휘둘리지 말고 지난 1년 혹은 5년의 변화 속도를 냉정히 가늠하라는 것이다.
실무자를 위한 방향
구체적 처방은 연차에 따라 갈린다. 시니어라면 자기 전문성을 더 파고드는 데서만 안주하지 말고 사용자 경험, 고객 인터뷰, 자신이 속한 도메인의 비즈니스 전략을 배우라고 권한다. 실제로 그 일을 직접 하게 되든 아니든, 소프트웨어가 사용자 손에 닿기까지 얼마나 많은 작업이 필요한지 이해하게 된다는 이유에서다. 반대로 주니어라면 소프트웨어가 실제로 어떻게 동작하는지를 더 깊이 파고들라고 말한다. 포인터·재귀·메모리 계층은 자바스크립트 개발자에게도, HTTP와 네트워크 프로토콜은 워드프레스 플러그인 개발자에게도 쓸모가 있으며, 당장 필요 없어 보여도 알고리즘과 자료구조를 익히고 '왜'와 '정확히 어떻게'를 묻기를 두려워하지 말라는 것이다.
한국의 실무자에게 이 글이 갖는 함의는 특정 도구의 채택 여부가 아니라 태도의 재조정에 있다. 기술과 코드가 어렵다는 사실을 인정하는 것과, 그것만으로는 충분하지 않다는 사실을 인정하는 것은 모순이 아니다. 필자가 마지막으로 남기는 문장은 이 글 전체를 압축한다. 당신이 누구든, 이해와 판단, 공감과 취향을 AI에 외주 주지 말고 책임을 포기하지 말라는 것. 즉 자기 자리를 지키는 '고기 프록시'로 전락하지 말라는 경고다. 다만 이 글은 개인 개발자의 경험과 관찰에 기댄 에세이인 만큼, 조직 차원의 인력·보상 구조나 산업 통계를 뒷받침하는 근거를 제시하지는 않는다는 점은 감안해 읽을 필요가 있다.