코딩과 무엇을 만들지 결정하는 일 모두가 소프트웨어 개발에서 중요한 이유, 그리고 AI 시대에 개발자가 적응하고 성장하는 방법을 살펴본다.
소프트웨어 개발이라는 직업은 격변의 한가운데에 있다. AI 혁명이 결국 어떻게 전개될지는 아무도 모르지만, 프로그래밍을 포함해 일과 삶의 많은 측면이 바뀔 것이라는 점은 분명하다.
요즘 내가 자주 듣는 말은 결국 “LLM은 코딩을 잘할지 모르지만, 소프트웨어는 애초에 어려운 부분이 아니었다”와 “코딩은 쉽고, 무엇을 코딩할지 알아내는 일이 어렵다”로 요약된다.
나는 이것이 어디에나 있는 모든 프로그래머에 대한 심각한 모욕이라고 믿는다.
코딩이 쉽다면, 프로그래머는 왜 수년간 수요가 높았고 큰 연봉을 요구해 왔을까(ZIRP 이전에도 그랬다)? AI가 5000줄짜리 PR을 쏟아내기 전부터 스트레스, 과로, 번아웃이 그토록 심했던 이유는 무엇일까? 기업들은 왜 10배 성과를 내는 닌자 록스타 코더를 찾고 리트코드 면접을 보게 했을까? 정말 그렇게 쉽다면 대학을 갓 졸업한 주니어도 무언가를 뚝딱 만들어낼 수 있었을 것이다.
코딩이 쉽다면, 왜 Clean Code나 The Pragmatic Programmer 같은 묵직한 책들이 있을까? The Art of Computer Programming은 가벼운 여름 독서일까? SICP는 커피 테이블 위에 놓는 책일까? 왜 이를 위한 부트캠프가 있고, 심지어 대학 학위 과정 전체가 존재할까?
코딩이 쉽다면, Carmack은 그저 적절한 때에 적절한 장소에 있었던 것뿐일까? 우리는 왜 Fabrice Bellard를 천재로 여길까?
코딩이 쉽다면, 사람들은 왜 AI나 다른 누군가가 자기 코드를 복사하는 데 화를 낼까? 왜 그렇게 사소한 것에 땀과 영혼, 그리고 엄청난 시간을 쏟아부은 것처럼 행동할까?
코딩이 쉽다면, 왜 많은 사람이 이제 자신의 정체성과 직업적 목적을 빼앗기고 있다고 느낄까?
코딩이 쉽다면, 소프트웨어에는 왜 이렇게 지독하게 버그가 많을까?
무엇을 만들지 결정하는 일이 어렵다면, 왜 এত এত 제품 관리자가 무능해 보일까? 왜 그들에게는 엄격한 10단계 면접이 없을까? 왜 그들은 개발자보다 더 많은 돈을 받지 않을까?
무엇을 만들지 결정하는 일이 어렵다면, 왜 시장 조사자, 사용성 전문가, 그리고—제기랄, 고객 성공 담당자조차—소프트웨어 회사에서 록스타로 여겨지지 않을까? “고객을 이해하는 것”이 더 어렵다면, 왜 비즈니스 애널리스트는 서류만 처리하는 사람으로 얕보일까?
구현은 쉽고 수요를 찾는 일이 더 어렵다면, 영업사원이 판매를 성사시키기 위해 고객에게 새 기능을 약속할 때 프로그래머는 왜 화를 낼까? 사람들이 돈을 낼 진짜 수요를 찾아낸 것 아닌가!
코딩이 쉽다면, 왜 모두가 그냥 어떤 것의 변형을 열 가지 만들어 보고 무엇이 잘되는지 확인하지 않을까?
또 다른 진부한 말은 “소프트웨어 개발 업무의 대부분은 이해관계자와 이야기하고, 고객의 필요를 이해하며, 우선순위를 명확히 하는 일이다”라는 것이다.
나는 경력 내내 많은 프로그래머를 만났지만, 그들 중 이해관계자와 이야기하고 싶어 하는 사람은 극히 드물었고 고객과는 더더욱 그랬다(프리랜서와 창업자, 특히 소프트웨어 개발 업체의 창업자는 예외다). 그리고 “우선순위를 명확히 하는 것”은 결국 “그냥 내가 뭘 해야 하는지 말해 주고 이틀마다 바꾸지만 마”로 귀결된다.
어떤 소프트웨어 개발자는 “나는 코드를 쓰는 게 아니라 고객의 문제를 해결한다”라고 말한다. 하지만 곧바로 모나드, 메모리 안전성, DRY 원칙에 관한 의견을 늘어놓는다. 그들의 고객 이해란 지어낸 “사용자 페르소나”이고, “어포던스”를 주말에 나가서 즐겁게 놀 수 있도록 부모님이 주시던 용돈이라고 생각한다.
또 다른 이들은 “소프트웨어 개발은 이론을 구축하는 일이다”라고 말할 것이다. 프로그램은 실제로 증명이다(수학적 증명이라는 뜻에서). 모든 커밋은 이야기를 들려줘야 한다. 그리고 PHP 파일을 FTP로 올려 고객 문제를 해결하는 일은 중대한 죄악이다.
나는 소프트웨어 개발이라는 기술에 깊이 신경 쓰면서 동시에 고객에게 진정으로 공감하는 개발자가 없다는 뜻으로 말하는 것이 아니다. 다만 그런 사람들은 해리성 정체감 장애 전문가를 만나보고 싶어 할지도 모른다고 생각한다. (추신 편집: 이 문장은 지나치게 나갔다. “그 일을 할 수 있는 사람은 극히 드물다”는 농담으로 쓴 것이며, 실제로 나는 다음 절에서 그것을 지지한다. 내 잘못이다)
나는 사용자와 대화하고, 그들의 경험을 이해하고, 그들에게 공감하고, 고객의 문제를 해결하며, 모든 이해관계자의 뜻을 맞추는 일이 소프트웨어 프로젝트의 성공에 결정적이라고 믿는다.
또한 좋은 코드를 만드는 일은 기술, 인내, 세부 사항에 대한 주의, 경험, 지혜를 필요로 하는 장인정신이며, 앞으로의 시대에도 계속 중요할 것이라고 믿는다.
왜 둘 다 하지 않는가?
우리가 해낼 수 있는 범위에서, 나는 두 가지 모두를 목표로 해야 한다고 생각한다. 우리가 구축하는 시스템에 대한 깊은 이해와, 왜 그것을 구축하는지에 대한 깊은 이해를 함께 갖추는 것이다.
“코드는 쉽다” 혹은 정반대 극단으로 “코드는 자동화할 수 없는 창의적인 인간 표현인 예술이다”라고 큰 소리로 선언하는 것은 그저 현실을 외면하는 일이다.
그것은 자기위안이다. 그리고 당신이 원하는 것은 자기위안이 아니라 번영이다.
이 말은 “LLM 열차에 올라타라”는 뜻이 아니다. “AI 에이전트 무리의 관리자가 되어라”는 뜻도 아니다. 또한 “AI가 생성한 코드는 훔친 쓰레기이니 죽기 살기로 맞서라, 어차피 거품은 곧 꺼질 것이다”라는 뜻도 아니다.
하지만 우리가 업계 전체의 지각 변동 한가운데 있다는 점은 인정하라. 우리는 어떻게 적응할지 알아내야 한다. 무엇이 바뀔 가능성이 크고 무엇이 절대 바뀌지 않는지 이해해야 한다.
소프트웨어는 더 복잡해질 것이다. 소프트웨어는 언제나 유지보수가 필요하다. 비트 부식은 삶의 사실이다. 엔트로피도 그렇다. 기술(하드웨어와 소프트웨어)은 좋든 나쁘든 앞으로 나아갈 것이다. 추상화의 탑(마천루?)은 계속 더 높아진다.
사용자는 언제나 더 많은 것을 원하면서 더 적게 지불할 준비가 되어 있을 것이다. 그들은 여전히 자신의 필요와 바람을 어떻게 전달해야 하는지 모를 것이다. 더 나쁜 것은, 자신이 정확히 무엇을 원하는지도 여전히 모를 것이라는 점이다. 고객(실제로 소프트웨어 비용을 지불하는 사람)과 사용자(그것을 사용하는 사람) 사이의 단절은 계속 존재할 것이며, 사업의 필요와 고객의 필요 사이의 긴장도 마찬가지일 것이다.
또한, 약장수는 결코 부족하지 않을 것이다. 오늘의 기술은 나타났다 사라진다(나는 아직도 새로운 VR 르네상스를 기다리고 있다!).
프로그래머는 처음부터 우리 업계 자체를 혁신하는 일을 해왔다. 이제 아무도 천공 카드를 쓰지 않는다. 어셈블리나 COBOL로 코딩해야 하는 사람도 극히 적다. C나 C++에서 메모리 버그와 싸우며 보낸 수십 년과 그 증거인 흉터는 Rust, Go, Python, JavaScript 시대에는 아무런 가치가 없다.
나는 valgrind를 고마워할 만큼 나이가 들었고, PHP4 시대의 mysql_real_escape_string()도 기억한다. 이제 내 삶에서 다시는 필요하지 않을 것들이다. 그런데 그것도 그리 오래전 일이 아니다! 나는 dBase, Clipper, HyperCard, Access 시대를 간발의 차로 놓쳤다. 지금도 상점이나 카페에서, 혹은 먼지 쌓인 한때 베이지색이었으나 이제 황갈색이 된 미디 타워에서 어떤 맞춤형 비즈니스 솔루션을 여전히 즐겁게 돌리는 모습을 볼 수 있는 기술들이다(백업? 무슨 백업?).
변화가 일어난다는 사실을 받아들여라. 새로운 것에 대해 호기심과 비판적 태도를 똑같이 가져라.
과장 광고가 많다는 점을 이해하고, 허풍과 실제로 작동하는 것(그리고 어느 정도까지 작동하는지)을 구별하려 노력하라. 끊임없이 옮겨 가는 목표 지점도 인식하라. 한 걸음 물러나 지난 1년이나 5년을 돌아보고 변화의 속도(기술적, 경제적, 사회적)를 평가하라.
당신의 역할과 책임은 반드시 바뀔 것이다. 자신의 분야나 역할과 인접한 분야 또는 역할을 더 잘 이해하는 데 시간과 에너지를 투자할 의지를 가져라.
시니어 개발자라면, 전문성을 깊게 하는 데서만 위안을 찾지 마라. 사용자 경험, 고객 인터뷰, 또는 당신이 속한 분야 기업들의 비즈니스 전략을 배워라. 실제로 그 다른 일들을 해야 하게 될지와 상관없이, 소프트웨어 한 조각을 사용자의 손에 쥐여 주기 위해 이루어지는 모든 작업을 더 잘 이해하게 될 것이다.
막 시작했거나 주니어 역할에 있다면, 소프트웨어가 어떻게 작동하는지에 대한 이해를 깊게 하는 데 투자하라. JavaScript 개발자라도 포인터, 재귀, 메모리 계층 구조를 이해하면 도움이 된다. WordPress 플러그인을 만들더라도 네트워크 프로토콜과 HTTP가 작동하는 방식을 이해하면 유용하다. 필요하지 않더라도 리트코드를 풀고 알고리즘과 자료 구조를 배워라. _왜_와 _정확히 어떻게_를 묻는 것을 두려워하지 마라.
영감을 위해, 도움이 될 만한 몇 권의 책과 기타 자료를 소개한다.
당신이 누구든, 이해력, 판단력, 공감 능력, 취향을 AI에 외주 주지 마라. 당신의 책임을 포기하지 마라. 고기 프록시가 되지 마라.
추신. Hacker News와 Lobsters에 흥미롭고 통찰력 있는 댓글이 많이 달렸다. 이 글은 정말 사람들의 신경을 건드렸다. 사람들이 가진 경험이 얼마나 다양한지, 또 그들이 코딩, 프로그래밍, 개발, _엔지니어링_을 얼마나 서로 다르게 정의하는지 무척 흥미롭다.
