POOOLING FOREST
우리는 코드를 찍어내는 공장이 되어가고 있는지도 모릅니다 - 기술 생태계가 겪고 있는 본질적인 위기와 AI 시대 속에서 개발자가 나아가야 할 방향에 대해 고민한 내용을
Culture & Philosophy

우리는 코드를 찍어내는 공장이 되어가고 있는지도 모릅니다

기술 생태계가 겪고 있는 본질적인 위기와 AI 시대 속에서 개발자가 나아가야 할 방향에 대해 고민한 내용을 공유합니다. 도구에 종속되지 않는 개발자의 역할에 대하여.

송찬영

CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.

최근 우연히 '모든 웹사이트를 파괴할 웹사이트(A website to destroy all websites)'라는 다소 도발적인 제목의 글을 읽었습니다. 헨리(Henry)라는 작성자가 쓴 이 글은, 과거의 인터넷이 자기 발견과 배움의 '정원'이었다면, 지금의 인터넷은 알고리즘이 지배하는 '주물공장'이 되었다고 한탄합니다. 글을 읽어 내려가며 솔직히 가슴 한구석이 서늘해지는 것을 느꼈습니다. 단순히 인터넷 사용자로서의 향수 때문이 아니었습니다. 지금 우리 개발 조직이, 그리고 기술 생태계가 겪고 있는 본질적인 위기를 정확히 꿰뚫고 있었기 때문입니다.

저도 코딩을 처음 시작했을 때를 기억합니다. 그때의 웹은 투박했지만, 만드는 사람의 '영혼'이 담겨 있었습니다. 엉성한 HTML 태그 하나에도 무언가를 창조한다는 기쁨이 있었죠. 하지만 지금 우리는 어떤가요? 헨리가 지적한 '자동차의 역설'이 우리 엔지니어링 환경에도 그대로 적용되고 있습니다. 처음 자동차는 이동의 자유를 주었지만, 나중에는 도시 전체가 자동차를 위해 설계되면서 인간이 오히려 도로와 주차장을 위해 희생하게 되었습니다. 이반 일리치(Ivan Illich)가 말한 '급진적 독점(radical monopoly)'이자, 도구가 주인을 역전하는 순간입니다.

우리 개발 환경을 돌아봅시다. MSA(마이크로서비스 아키텍처), Kubernetes, 복잡한 CI/CD 파이프라인, 수많은 SaaS 도구들. 처음에는 개발 속도를 높이고 운영을 효율화하기 위해 도입했습니다. 하지만 어느 순간부터 우리는 비즈니스 가치를 고민하기보다, 인프라를 유지보수하고 복잡한 의존성을 관리하는 데 더 많은 시간을 쏟고 있습니다. 주니어 개발자들은 '왜' 이 코드를 짜는지 이해하기보다, Jira 티켓을 처리하고 처리량(Throughput)을 높이는 데 급급해합니다. 우리가 만드는 소프트웨어가 사용자의 삶을 풍요롭게 하는 '도구'가 아니라, 단지 트래픽을 잡아두고 데이터를 수확하는 '덫'이 되어가고 있는 건 아닌지, 뼈저리게 고민했습니다.

최근 생성형 AI의 도입은 이 고민을 더욱 깊게 만들었습니다. Cursor나 Claude 같은 도구는 분명 혁신적입니다. 하지만 이것이 우리를 '생각 없는 코더'로 만들 위험도 큽니다. 실제로 얼마 전, 팀 내 코드 리뷰 과정에서 AI가 작성한 듯한 완벽하지만 영혼 없는 PR(Pull Request)을 마주했습니다. 문법적으로는 완벽했지만, 우리 도메인의 맥락이나 레거시 시스템과의 유기적인 연결에 대한 깊은 고민은 빠져 있었죠. AI를 활용해 더 빨리 '쓰레기 코드'를 양산하는 공장이 될 것인가, 아니면 인간만이 할 수 있는 본질적인 창조에 집중할 것인가. 기로에 서 있다는 생각이 들었습니다.

이 글에서 언급된 '공생을 위한 도구(Tools for Conviviality)'라는 개념은 그래서 중요합니다. 기술은 사용자의 에너지를 빼앗는 것이 아니라, 사용자가 자신의 의지를 더 자유롭게 펼칠 수 있도록 도와야 합니다. 풀링포레스트에서 제가 AI를 도입하는 방식도 이 철학을 따르려 노력하고 있습니다. 단순히 개발 속도를 높여 더 많은 기능을 찍어내기 위함이 아닙니다. 엔지니어가 반복적인 보일러플레이트 코드 작성이나 단순 디버깅에서 해방되어, "이 기능이 진짜 고객에게 필요한가?", "이 아키텍처가 3년 뒤에도 지속 가능한가?"와 같은 본질적인 질문을 던질 시간을 벌어주기 위함입니다.

우리는 경계해야 합니다. 우리의 IDE가, 우리의 프레임워크가, 그리고 AI가 우리를 단순한 '오퍼레이터'로 전락시키지 않도록 말이죠. 개발자는 단순히 코드를 입력하는 사람이 아니라, 문제를 정의하고 해결하는 설계자여야 합니다. 헨리의 글처럼, 우리는 다시금 인터넷을, 그리고 우리가 만드는 소프트웨어를 '배움의 정원'이자 '상상력의 숲'으로 되돌려야 할 책임이 있습니다.

기술의 편리함 뒤에 숨겨진 '산업화의 그늘'을 직시하세요. 그리고 도구에 종속되지 말고, 도구를 부리는 주체가 되시길 바랍니다. 오늘 여러분이 작성한 커밋(Commit)이 기계적인 할당량 채우기가 아니라, 누군가의 문제를 해결하는 의미 있는 한 줄이었기를 진심으로 응원합니다.

지금 읽으신 내용, 귀사에 적용해보고 싶으신가요?

상황과 목표를 알려주시면 가능한 옵션과 현실적인 도입 경로를 제안해드립니다.