“코딩은 애초에 어려운 일이 아니었다”는 말은 모든 프로그래머에 대한 모욕이다
소프트웨어 개발이라는 직업이 격변의 한가운데에 있다. AI 혁명이 결국 어떤 결말을 맞을지는 아무도 모른다. 하지만 프로그래밍을 비롯해 일과 삶의 여러 측면이 바뀌리라는 점은 분명하다.
최근 자주 듣는 말은 대체로 “LLM이 코딩은 잘할지 몰라도, 소프트웨어에서 코딩은 애초에 어려운 부분이 아니었다”, “코딩은 쉽고, 무엇을 코딩할지 알아내는 일이 어렵다”로 요약된다.
나는 이 말이 전 세계 모든 프로그래머를 심하게 모욕한다고 생각한다.
코딩이 쉽다면…
코딩이 쉽다면 프로그래머는 왜 수요가 많았고, 오랫동안 높은 연봉을 요구할 수 있었을까(ZIRP 이전에도 말이다)? AI가 5,000줄짜리 PR을 쏟아내기 전부터 스트레스와 과로, 번아웃이 심했던 이유는 무엇일까? 기업들은 왜 10배의 생산성을 내는 닌자 록스타 개발자를 찾으며 지원자에게 LeetCode 면접을 치르게 했을까? 그렇게 쉬운 일이라면 갓 대학을 졸업한 주니어도 뭔가 뚝딱 만들어낼 수 있지 않을까?
코딩이 쉽다면 왜 Clean Code나 The Pragmatic Programmer처럼 문을 괴는 데 쓸 만큼 두꺼운 책이 나왔을까? The Art of Computer Programming은 여름에 가볍게 읽을 책인가? SICP는 거실 탁자에 장식해 두는 책인가? 왜 코딩 부트캠프가 있고, 심지어 대학 학위 과정 전체가 코딩을 가르치는 데 전념할까?
코딩이 쉽다면 Carmack은 그저 때와 장소를 잘 타고났을 뿐일까? 우리는 왜 Fabrice Bellard를 천재라고 생각할까?
코딩이 쉽다면 사람들은 AI든 다른 누구든 자신의 코드를 복사할 때 왜 화를 낼까? 그토록 하찮은 일에 땀과 영혼, 엄청난 시간을 쏟아부은 것처럼 행동하는 이유는 무엇일까?
코딩이 쉽다면 왜 이제 많은 사람이 자신의 정체성과 직업적 의미를 빼앗긴다고 느낄까?
코딩이 쉽다면 소프트웨어에는 왜 빌어먹을 버그가 그렇게 많을까?
무엇을 만들지 정하는 일이 어렵다면…
무엇을 만들지 정하는 일이 어렵다면 왜 그토록 많은 제품 관리자가 갈피를 못 잡는 것처럼 보일까? 왜 그들에게는 엄격한 10단계 면접을 치르게 하지 않을까? 왜 개발자보다 더 많은 보수를 받지 않을까?
무엇을 만들지 정하는 일이 어렵다면 시장 조사원과 사용성 전문가, 심지어 고객 성공 담당자는 왜 소프트웨어 회사에서 록스타로 대우받지 못할까? “고객을 이해하는 일”이 더 어렵다면 비즈니스 분석가는 왜 서류 작업이나 하는 사람으로 무시당할까?
구현은 쉽고 수요를 찾는 일이 더 어렵다면, 영업 담당자가 계약을 성사시키려고 고객에게 새 기능을 약속할 때 프로그래머는 왜 화를 낼까? 영업 담당자는 사람들이 돈을 낼 진짜 수요를 찾아낸 것 아닌가!
코딩이 쉽다면 모두가 같은 것을 열 가지 버전으로 만들어 놓고 어느 것이 성공하는지 확인하면 되지 않을까?
중간값에 해당하는 프로그래머는 없다
또 하나의 상투적인 말은 “소프트웨어 개발 업무의 대부분은 이해관계자와 대화하고, 고객의 요구를 이해하며, 우선순위를 명확히 파악하는 일이다”라는 주장이다.
나는 경력 내내 많은 프로그래머를 만났지만, 이해관계자와 대화하고 싶어 하는 사람은 거의 없었다. 고객과 대화하려는 사람은 더 드물었다(프리랜서와 창업자, 특히 소프트웨어 개발 업체 창업자는 예외다). 그리고 “우선순위를 명확히 파악한다”는 말은 결국 “할 일을 그냥 알려 주고 이틀마다 바꾸지만 마라”라는 뜻이다.
어떤 소프트웨어 개발자는 “나는 코드를 작성하는 게 아니라 고객의 문제를 해결한다”고 말한다. 그러고는 모나드와 메모리 안전성, DRY 원칙에 관한 의견을 늘어놓는다. 정작 고객에 대해서는 지어낸 “사용자 페르소나”밖에 모르면서, “affordance”를 부모님이 주말에 나가서 즐겁게 놀라고 주던 용돈쯤으로 생각한다.
또 어떤 이들은 “소프트웨어 개발은 이론을 구축하는 일이다”라고 말한다. 프로그램은 사실 증명, 즉 수학적 증명이며 모든 커밋은 하나의 이야기를 들려줘야 한다는 것이다. PHP 파일을 FTP로 올려 고객의 문제를 해결하는 일은 중대한 죄악으로 여긴다.
소프트웨어 개발이라는 기예를 깊이 아끼면서 고객에게 진심으로 공감하는 개발자가 없다는 뜻은 아니다. 다만 그런 사람이라면 분열된 자아에 관해 전문가와 상담해 보는 편이 좋을지도 모른다.
무엇이 중요한가?
사용자와 대화하고, 사용자의 경험을 이해하고 공감하며, 고객의 문제를 해결하고, 모든 이해관계자가 같은 내용을 공유하는 일은 소프트웨어 프로젝트의 성공에 매우 중요하다고 생각한다.
좋은 코드를 만드는 일 역시 기술과 인내심, 세부 사항에 대한 주의, 경험과 지혜가 필요한 기예이며, 앞으로도 계속 중요하다고 생각한다.
둘 다 하면 안 될 이유가 있을까?
할 수 있는 한 두 가지를 모두 목표로 삼아야 한다. 우리가 만드는 시스템을 깊이 이해하는 동시에, 그 시스템을 왜 만드는지도 깊이 이해해야 한다.
“코드는 쉽다”고 목소리를 높이거나, 반대로 “코드는 예술이자 인간의 창조적 표현이므로 자동화할 수 없다”고 외치는 것은 현실을 외면하는 일일 뿐이다.
그저 현실을 견디려고 스스로를 달래는 말이다. 당신에게 필요한 것은 자기 위안이 아니라 번영이다.
그렇다고 “LLM 유행에 올라타라”는 뜻은 아니다. “AI 에이전트 부대를 관리하는 사람이 되라”는 말도 아니다. “AI가 생성한 코드는 훔친 조악한 쓰레기이니 필사적으로 맞서 싸워라. 어차피 거품은 곧 터진다”는 뜻도 아니다.
다만 업계 전체를 뒤흔드는 지각변동의 한가운데에 있다는 사실은 인정해야 한다. 적응할 방법을 찾아야 한다. 무엇이 바뀔 가능성이 크고 무엇이 결코 바뀌지 않는지 이해해야 한다.
바뀌지 않는 것은 무엇인가?
소프트웨어는 더 복잡해질 것이다. 소프트웨어에는 언제나 유지보수가 필요하다. 비트 부식은 피할 수 없는 현실이고, 엔트로피도 마찬가지다. 좋든 나쁘든 기술은 하드웨어와 소프트웨어 양쪽에서 발전할 것이다. 추상화의 탑, 아니 마천루는 계속 높아질 것이다.
사용자는 언제나 더 많은 것을 원하면서도 더 적은 돈을 쓰려 할 것이다. 자신의 필요와 욕구를 제대로 전달하지 못하는 문제도 계속될 것이다. 더 나쁜 점은 자신이 정확히 무엇을 원하는지 여전히 모른다는 것이다. 소프트웨어 비용을 실제로 지불하는 고객과 이를 사용하는 사용자 사이의 단절도 남을 것이며, 기업의 필요와 고객의 필요 사이의 긴장도 사라지지 않을 것이다.
바뀌는 것은 무엇인가?
프로그래머는 처음부터 자기 업계를 스스로 뒤흔들어 왔다. 이제 펀치 카드를 쓰는 사람은 없다. 어셈블리어나 COBOL로 코딩해야 하는 사람도 극소수다. C나 C++의 메모리 버그와 싸우며 수십 년을 보내고 상처까지 얻었지만, 그런 경험은 Rust, Go, Python, JavaScript 시대에는 쓸모가 없다.
나는 valgrind의 가치를 알 만큼 나이가 들었고, PHP4 시대의 mysql_real_escape_string()도 기억한다. 이제 평생 다시 쓸 일 없는 것들이다. 심지어 그리 오래전 일도 아니다! 나는 dBase, Clipper, HyperCard, Access 시대를 간발의 차이로 비껴갔다. 하지만 가게나 카페에 가면 그런 기술이 아직 돌아가는 모습을 볼 수 있다. 한때는 베이지색이었지만 먼지가 쌓여 이제 황갈색이 된 미디 타워가 맞춤형 업무 솔루션을 여전히 즐겁게 실행하기도 한다. 백업이라고? 무슨 백업?
어떻게 번영할 것인가?
변화는 일어난다는 사실을 받아들여라. 새로운 것을 똑같은 비중으로 호기심 있게, 또 비판적으로 바라보라.
과장이 많다는 점을 이해하고, 허풍과 실제로 작동하는 것, 그리고 어느 정도까지 작동하는지를 구별하려 노력하라. 성공의 기준이 계속 바뀐다는 사실도 유념해야 한다. 한발 물러서서 지난 1년이나 5년을 돌아보고 기술적·경제적·사회적 변화의 속도를 평가하라.
당신의 역할과 책임은 반드시 달라질 것이다. 자신의 분야와 인접한 영역이나 역할을 더 잘 이해하는 데 기꺼이 시간과 노력을 투자하라.
시니어 개발자라면 전문성을 더 깊이 쌓는 데서 위안만 찾지 마라. 사용자 경험과 고객 인터뷰, 자신이 속한 업계 기업들의 사업 전략을 배워라. 다른 업무를 실제로 맡을 일이 전혀 없더라도, 소프트웨어 하나가 사용자의 손에 들어가기까지 얼마나 많은 일이 필요한지 더 잘 이해하는 데 도움이 된다.
이제 막 시작했거나 아직 주니어라면 소프트웨어가 작동하는 원리를 깊이 이해하는 데 투자하라. JavaScript 개발자라도 포인터와 재귀, 메모리 계층 구조를 이해하면 도움이 된다. WordPress 플러그인을 만들더라도 네트워크 프로토콜과 HTTP의 작동 방식을 알아두면 유용하다. 당장 필요하지 않더라도 LeetCode 문제를 풀고 알고리즘과 자료 구조를 배워라. 왜 그런지, 정확히 어떻게 작동하는지 묻기를 두려워하지 마라.
영감을 얻는 데 도움이 될 만한 책과 자료를 몇 가지 소개한다.
Structure and Interpretation of Computer Programs(PDF)
한 가지 더
누구든 자신의 이해력과 판단력, 공감 능력, 안목을 AI에 맡기지 마라. 자신의 책임을 포기하지 말라. AI가 현실 세계에 개입하도록 대신 움직이는 인간 프록시가 되지 마라.
source https://blog.senko.net/code-was-never-the-hard-part-is-an-insult-to-all-programmers
HN에서는 “코드가 어려운 적은 없었다”는 말을 프로그래밍의 가치를 깎아내리는 주장으로 볼지, 개발 과정의 실제 병목을 가리키는 표현으로 볼지를 두고 시각이 엇갈렸다. 핵심은 ‘코딩’의 범위다. 문법과 API를 찾아 정해진 구현을 옮기는 일만 뜻한다면 상대적으로 단순하다. 그러나 설계와 추상화, 데이터 모델링, 운영 제약까지 포함한다면 쉽다고 단정하기 어렵다.
기업에서 일한 개발자들은 요구사항을 구체화하고 고객의 실제 필요를 파악하는 데 더 큰 부담을 느꼈다고 했다. 잦은 우선순위 변경과 미완성 티켓, 조직 간 조율, 테스트와 배포, 장애 대응(on-call)이 구현보다 많은 시간과 에너지를 소모했다는 경험도 반복됐다. 반대로 커널 최적화처럼 정답이 정리되지 않은 문제나 새로운 기술적 난제를 다룰 때는 구현 자체가 가장 어려운 작업이 된다. 직무와 경력, 문제의 성격을 무시한 채 하나의 문장으로 일반화하기 어려운 이유다.
LLM의 효용도 같은 기준에서 평가됐다. 자주 쓰지 않아 매번 찾아보던 표준 라이브러리 사용법이나 작은 변경을 맡기면 생산성을 높일 수 있다. 하지만 코드베이스 전체를 넘기면 개발자의 이해가 실제 변경 사항을 따라가지 못하고, 버그와 보안 문제를 찾아내는 부담이 커진다. 작게 요청하고 직접 검토할 때는 유용하지만, 넓은 범위를 맡길수록 설계와 검증을 위한 전문성이 더 필요하다는 설명이다.
결국 따져야 할 것은 코드 작성량이 아니라 판단과 책임의 범위다. 구현 전에 무엇을 결정해야 하는지, 코드를 쓰면서 어떤 문제가 새로 드러나는지, 누가 정확성과 유지보수성, 운영 가능성을 검증하는지 확인해야 한다. AI의 효과 역시 생성 속도보다 개발자가 설계 의도와 시스템에 대한 이해를 계속 유지할 수 있는지를 기준으로 판단해야 한다.
