Quality Code
Myth와 Legend 사이
지난 주말, 회계학 원론을 보던 중에 좀 묘한 생각이 스쳤습니다. 바로 앞 Too Big to fail 이야기와 연결되는 이야기입니다.
오랫동안 소프트웨어 업계에서 코드 품질은 적잖이 중요한 문제로 여겨 왔습니다. 다만 당연히 수반되어야 할 리팩토링과 단위 테스트에 대해 중요하다고 주장하는 만큼 비용이 투입되었는가 하면… 사람 사는게 거기서 거기죠, 뭐. 코드 퀄리티 & 퀄리티 코드의 문제는 데드라인과 함께 — 개발자 vs. 경영자의 불화를 부르는 양대 산맥이었을겁니다.
개발자라는 종자들이 원체 사람보다 기계와 대화하는 편이라 그 밖의 주변 사람들과는 딱히 불화 없이 잘 지냈는가 하면 뭐… 허허허. 그런데 한 켠으로는 이 널리 보편적인 문제가, 개발자라는 사람들이 경영자의 언어로 제대로 설명하지 못했던 탓도 있겠다는 생각이 드는 겁니다. 바로 회계상 인식이라는 측면에서 말입니다.
소프트웨어 엔지니어링에 많은 개념을 전해 준 현실 건축을 예시로 이야기를 풀어 볼까요. 가령 하나의 서비스를 구축하는 과정을, 상가 건물을 짓고 임대 수익을 얻는 것으로 생각해 봅시다.
엔지니어들은 건물을 짓고, 전기/수도/가스 등 인프라를 연결하며, 마감하고 인테리어를 거쳐 모집된 임차인에게 임대료를 받습니다. 여기서 (땅과 부채는 제외하고) 만들어진 건축물은 사업의 자산으로 인식되며, 임대료라는 매출/수입과 운영비용이라는 매입/지출을 중심으로 사업이 굴러 갑니다.
여기서 엔지니어들이 말하는 코드 퀄리티는 비유하자면 건물의 디자인, 품질, 구조와 같은 것들인데 사실 일상 경영의 입장에서 자산의 /퀄리티/는 장부상 눈앞에 드러나는 대상이 아닙니다. (물론 장부 바깥의 시야에서 그 차이를 잡아낼 수 있어야 좋은 경영자이겠다는 생각도 합니다)
합판 가벽을 세우고 으리으리한 LED 퍼사드를 설치한 모델하우스용 가건물이나, 유명 건축가 설계에 제대로 기초 다지고 철근 콘크리트 타설해서 천천히 올린 건축물이나. 어차피 비슷한 평당 단가로 임대료를 걸어 둘 수 있다면 누가 미쳤다고 콘크리트 건물을 올립니까? 간소한 구축/자산화와 그로 인한 빠른 현금 회전, 높은 수익과 낮은 비용. 꿈만 같은 상황 아닙니까.
그 이후는 마치 동화와 같이 누구나 쉽게 짐작 가능합니다. 처음 한 두 해는 반짝이는 퍼사드로 바가지를 씌울 수 있을지 모릅니다. 하지만 사람/소비자가 바보도 아니고 차츰 같은 임대료가 아니게 됩니다. 줄어드는 매출은 차라리 부차적인 문제입니다. 수선/유지/운영 비용이 줄줄이 터져 나가고, 확장이라도 하려 치면 온갖 문제가 다 생기고. 비 새고 고장나고 임차인 항의가 빗발치고…
곧장 수익성이 악화되니 상대적으로 만만한 고정 비용을 건드리게 됩니다. 일도 안 터지는데 괜히 나가는 화재 보험료나 소방설비 관리비, 청소 용역이나 관리 인력 같은 부분들 말입니다. 그 뒤에 어떻게 되는지는 각자의 상상에 맡기겠습니다. 터져나간 자산 감가 때문에 부채 회전에 실패하던, 불이 나서 홀랑 타 버리던, 임차인들이 줄줄이 나가서 헐값에 팔려 나가던, 무리하게 증축하다 폭삭 내려앉던; 하겠지요. 혹은 너무나 운이 좋아서 그 모든 리스크 팩터가 하나도 터지지 않은 채로 무사히 매각한 후 스타 경영자가 될 수도 있겠지만 말입니다. 마지막은 너무 현실적이었습니까?
현업 엔지니어로서 말하건대, 현행 소프트웨어 업계에서는 오직 기능하는 코드 그 자체를 자산으로 인식하는 경영자 인식이 있습니다. 여기에서 경영 측면의 두 가지 문제점이 발생합니다:
- 미래의 운영/유지 보수 및 확장에 대한 제반 비용은 온전히 숨어 있습니다.
- 직접 기능하지 않는 코드, 혹은 기반 로직 등을 자산에서 놓칩니다.
개인적으로 퀄리티 코드가 반드시 꼭 더 빠른 코드, 더 비용 효율적인 코드, 더 가독성 높은 코드를 의미한다고 생각하진 않습니다. 일부는 서로 트레이드-오프로 상충되는 결과입니다. 그렇지 않습니까? 그 보다 — 비즈니스 목적을 달성하기 위한 전략/전술적 기능 로직으로서 그 생애주기 내에서 적정 비용 &적정 효용을 두루 만족 시키는 코드로 이야기를 하고 싶습니다.
특히 소프트웨어 업계에서 흔한, 빠른 스프린트 / 빠른 확장이 필요한 경우라면 파이썬 서버리스 방식이 가장 비용 효율적이지는 않아도 가장 목적 지향적인 선택이 됩니다. 두어달 캠페인에 잠깐 쓰고 말 서비스에 가건물 같은 개발을 하지 않으면 좋은 상업 엔지니어라 하지 못하겠습니다 (월급 받고 예술하나?) 나 개인적으로는 적은 비용, 그로 인한 리스크 감쇄를 높은 체감효용보다 전략적/상대적으로 선호하는 편이나, 적정한 범위 안에서는 각자의 스타일에 따른 선택이 될 겁니다.
이러한 코드 퀄리티 — 퀄리티 코드가 과거에는 엔지니어 비용과 클라우드 인프라 서비스 비용에 녹아 있었다면, 이제는 그 중 많은 부분이 AI 비용으로 전환/확대되고 있습니다.
또 AI의 작성 코드가 합판 가벽 같은 날림 코드라 하진 않겠습니다. 경험적으로 썩 그리 좋은 결과는 아닐지라도 썩 괜찮은 결과를 얻을 때도 많았으니까요. 계속 발전해 오기도 했고. 그보다도 AI로는 — 퀄리티와 완결성, 전략적 방향성이라는 측면에서 통제 불가능한 랜덤이 된다는 점이 더 큰 문제입니다. 퀄리티가 낮을 수도, 필요보다 높을 수도 있는데, 그것이 일정한 수준이나 방향성을 갖지 못한 상태에서 다량 쌓이는게 문제라는 뜻입니다. 레거시로서 기능하는 상태에서는 그 코드 자산 자체가 큰 문제는 아닙니다.
그 코드를 뜯어 고쳐야 하거나 확장해야 한다면 악몽이 되겠지만.
그리고. 직접 기능에 참여하지 않는 코드/로직 또한 자산이라는 잘 와 닿지 않는다면 시제품 / 목업 / 증정or전시상품을 떠올려 봅시다. 제조 라인이 참조해야 하는 목업이 매출을 일으킵니까? 바이어에게 전달하는 샘플에 비용을 매기나요? 모터쇼에 출품하는 자동차 그거 돈 주면 파는 겁니까? (마지막은 잘 모르겠네요 사려고 해본 적이 없어서) 가끔 고정 비용처럼 느껴지는 이런 비매출 제품/자산은 — 결과적으로 교육&운영 비용을 낮추거나 홍보&마케팅에 쓰이는 되는 등, 장부에 직접적으로 드러나지 않는 매출 증대 or 지출 감소 or 효율/효용 확대 요건이 됩니다.
있을 때는 잘 모릅니다. 없어지면 좀 시리죠.
개발자들에게 백날 코드&제품 퀄리티가 중요하다고 해 봐야, 좋은 샘플 한 조각 던져주는 것만 못합니다. AI에게도 마찬가지입니다. 밑도 끝도 없이 리팩토링 하라는 것 보다 one-shot 샘플을 주고 나머지에 같은 방식으로 적용하라 하는 편이 백 배 낫습니다.
이 맥락에서 — 특히 경영진의 입장에서 오늘의 AI 열풍이 이해 가지 않는 것은 아닙니다. 나를 포함, 적지 않은 현업 엔지니어들이 AI를 인정하고 있기도 하구요. 무엇보다 경영의 입장에서 AI는 몇 푼도 되지 않는 토큰 사용료로 기초 자산이 될 수 있는 코드를 쏟아내 주는 화수분이나 다름 없어 보일겁니다. 얼마나 좋습니까. 작년 이맘때 나도 같은 생각을 했다는 사실은 고백해야겠네요.
지금은, 글쎄요… /작성한 코드/의 단가가 과거 우편 vs. 이메일 수준으로 떨어진 지금, /기능하는 코드/의 자산 가치 또한 작년과는 비교도 할 수 없을 만큼 떨어졌을 겁니다. 특히 소프트웨어 업계에 계신 경영자 여러분은 달라진 자산 가치를 감안해서 새로운 전략을 준비해야 할거라 생각합니다. 다만 기왕의 전제에 따라 소프트웨어 로직/아키텍트의 단가도 따라서 떨어졌는가, 하면, 글쎄요.
곧 치솟아 올라갈 것 같은데.