개발의 현황

얼마 전의 일입니다. 집에서 쉬고 있는데 어머니께서 부르시더라고요. 예 하고 뛰어갔더니 홈쇼핑 방송을 보시다가 스마트폰으로 주문한다면 싸다는 말에 앱을 설치하셨는데 진행이 잘 안 된다고 하시더군요. 사실 저희 어머니는 개발자 아들을 두기는 하셨지만, IT나 스마트폰 등에 대한 지식은 정말 평범하셨고, 딱히 앱을 설치하고 사용하시는 것 자체에 어려움을 겪으시는 분은 아니었습니다. 그래서 무슨 일인가 들여다보니 회원가입을 못하고 계시더라고요. 사실 우리나라에서 스마트폰 앱을 사용하다 보면 회원가입부터 해야 하는 경우는 정말 많지 않습니까? 그래서 도대체 어디서 막히셨나 봤더니 회원가입 여부를 판단하기 위해서 이름을 입력하려고 하셨는데, "이름에 공백이 있으면 안 됩니다."라는 메시지가 자꾸 뜨더랍니다.

물론 저희 어머니가 성과 이름 사이에 공백을 넣는 표기법을 고수하신 것도 아니고, 이름을 입력하고 꼭 빈칸을 입력하는 습관을 지니신 것도 아니었습니다. 그래서 뭐가 문제일까 하고 고민하다가 제가 직접 이름을 치고 주민등록번호를 친 다음 가입 여부 확인 버튼을 눌러봤죠. 그런데 또 "이름에 공백이 있으면 안 됩니다." 라는 메시지가 뜨는 것 아니겠습니까? 보통 사람은 자신이 실수했다는 것을 처음부터 인정하지는 않으니까 저도 그렇게 생각했습니다. 이거 결함이네. 버그다. 회원 가입이 아예 안 되게 배포가 됐네. 그렇게 상황을 이해하려고 하는데 저 공백이라는 단어가 묘하게 거슬렸습니다. 그래서 가만히 생각해보니 갑자기 뭔가 인과관계가 맞아떨어지는 듯한 느낌이 들었습니다.

사용패턴에 따라 다르겠지만, 보통 자기 이름은 스마트폰으로 자주 입력하게 됩니다. 당연히 스마트폰에 설치된 키보드의 자동완성 패턴에 자기 이름은 매우 높은 순위로 등록되기 마련입니다. 그래서 이름을 입력하라고 했을 때 어머니께서 성만 입력했는데도 성함이 자동완성으로 떴던 것입니다. 그 상황에서 두 글자를 더 타이핑할 이유는 별로 없었습니다. 그냥 자동완성된 이름을 터치해서 입력하고 넘어갔죠. 그런데 이 자동완성 기능이라는 게 기본적으로 단어를 입력해주는 기능이다 보니까 보통 단어를 입력해주고 한 칸의 공백을 추가로 넣어줍니다. 아이폰이건 안드로이드건 자신들의 추천 시스템에 자신이 있는지 이전 자동완성 단어에 기초해서 다음 단어도 바로 추천해서 연속적으로 입력 가능하도록 말이죠. 그렇게 공백은 의식하지도 못하는 사이에 이름과 함께 입력이 된 것입니다.

순간 굉장히 답답하다는 생각이 들었습니다. '이런 것도 생각 못 하고 만드나?'라는 일반적인 사용자들의 인식과 달리 개발자들은 보통 앱을 개발할 때 정말 그런 것도 저런 것도 많이 놓치면서 개발을 합니다. 세간의 인식과는 다르게 모든 개발자들이 스마트폰을 하루 종일 사용하지는 않으니까요. 자동완성이라는 것이 있고 공백이 들어간다는 것을 떠올리기 보다는 모든 사용자들이 키보드를 이용해서 자신의 이름을 정확히 입력할 것이라고 믿는 쪽이 훨씬 일을 줄일 수 있습니다. 그래서 의도적으로 혹은 정말로 잘 몰라서 자동완성 기능을 통한 입력은 놓칠 수도 있습니다. 이런 일은 정말 비일비재하게 일어납니다.

하지만 정말 답답한 것은 이 앱을 만든 개발자는 놓치지 않았다는 것입니다. 이름에 공백이 있으면 안 된다는 경고창이 떴으니까요. 이 말은 이름에 공백이 포함되었는지를 검사를 했다는 말입니다. 어떤 언어로 이 앱을 만들었는지는 잘 모르겠지만 사실 문자열에 공백이 포함되었는지를 검사하는 것은 그 문제의 단순함과 명쾌함에 비하면 꽤 기술이 필요한 코드입니다. 그런데 그 어려운 과정을 통해서 이름에 공백이 있는지를 검출해내고 나서 도대체 왜 그걸 경고를 하느냐는 말입니다. 사용자가 자신의 실수를 파악하고 다시는 이름에 공백을 넣지 않도록 교육하기 위해서 같은 말도 안 되는 이유가 아니라면 그거 경고할 시간에 그냥 공백을 제거하고 다음으로 넘어가는 쪽이 무조건 좋습니다. 심지어 공백을 검출하는 것보다 공백을 제거하는 쪽이 대부분 언어에서는 훨씬 더 쉽습니다.

그러니까 이런 건 일종의 관습의 오류입니다. 규격화된 개발을 진행하면서 발생하기 쉬운 오류인데, 설계자가 사용자가 입력할 수 있는 필드 하나하나 마다 규칙을 정해서 명세서를 주면 개발자는 그걸 아무 생각 없이 구현합니다. 설계자는 이 필드는 검사(Validation)를 수행하는 것보다는 공백을 처리(Trim)하는 쪽이 개발과 사용성 양쪽에 훨씬 더 유리하다는 사실을 파악하지 못하고, 개발자는 독단적으로 설계를 바꿀 때 감당해야 될 피곤함을 감수하기 싫어서 혹은 정말 아무것도 몰라서 그냥 모든 필드에 기계적인 검사를 수행합니다. 이런 분위기에서는 '우편번호는 6자리'라는 명세에 '이제 5자리인데요?'라는 반항을 하기도 쉽지 않게 됩니다.

제가 막 대학교에 들어갔을 때는 닷컴 버블이 정점을 찍던 시절이었습니다. 그러니까 회사 이름에 닷컴만 들어가면 그 회사가 어떤 회사인지 따져보지도 않고 돈이 몰려들던 그런 시절이었습니다. 닷컴이라는 것이 등장하기 이전의 컴퓨터와 프로그래밍은 정말 소수만의 분야였는데, IT에 돈이 몰리기 시작하니까 온 세상이 인터넷, 프로그래밍, 온라인 게임을 외치기 시작했습니다. 컴퓨터공학과에는 프로그래밍을 해본 적이 없는 입시생들이 몰려들었고, 시장에는 몇 개월 정도의 단기속성 과정을 거쳐 양성된 개발자들이 쏟아지기 시작했습니다.

6년이 지나고 제가 대학교를 졸업할 무렵에는 닷컴 버블이 완전히 가라앉았습니다. 어쨌든 세상에는 IT를 적용해야 할 시스템과 프로세스가 너무나 많았고 만들어야 할 홈페이지도, 인터넷에서 팔기 시작해야 할 상품들도 어마어마하게 많았던 것입니다. 일감은 줄어들지 않았고 시장은 계속 차갑게 성장했습니다. 하지만 시장에 일어났던 큰 변형은 일종의 파괴를 동반했습니다. 프로그래밍의 순수성 보다는 결과물의 빠른 전달이 훨씬 더 높은 우선순위를 가지기 시작한 것입니다.

보통 사람들이 가지기 쉬운 선입견과는 달리, 대형 시스템의 개발에 세세한 로직의 최적화는 크게 중요하지 않은 경우가 많습니다. 반복문이 200번 돌 것을 정교한 알고리즘으로 100번만 돌아도 결과가 나오도록 할 수 있는 개발자보다야 그 시간에 화면 하나를 더 만드는 개발자가 훨씬 더 일 잘하는 개발자로 인정받습니다. 이런 프로젝트에서 말하는 최적화는 프로그래밍의 레벨이 아니라 인프라 레벨에서 이야기되는 경우가 많습니다.

제가 막 회사에 들어갔을 때는 이런 분위기가 업계 전반에 충분히 깔린 다음이었습니다. 큰 회사들은 좋은 소프트웨어를 이야기하기 보다는 높은 생산성을 이야기하기 시작했습니다. 디자인과 구현 혹은 화면, 업무 로직, 데이터를 정교하게 분리하기 위한 목적에서 개발된 프레임워크들은 규격화된 화면을 최대한 빠르게 많이 찍어내기 위한 도구로 쓰였습니다. 애자일은 정신이나 문화보다는 생산성만이 주목받기 시작하더군요. 그리고는 성급한 사람들은 생산성이 오르지 않는다고 애자일 무용론을 펼치기 시작했고요. 그리고는 생산성을 올리는 데는 고전적인 방법 - 험악하고 비인간적인 분위기를 퍼트리는 것 -이 최고라고 믿지요. 

이런 분위기에서 로직의 깨끗함이나 알고리즘의 효율성 등을 이야기하는 것이 얼마나 어려운 일인지는 다들 이해해 줄 것이라 믿습니다. 그래서 저는 프로그래밍의 원초적인 매력에 반해서 이 바닥에 뛰어든 사람들이 현실과 이상의 괴리에 견디지 못하고 괴로워하는 것을 자주 봤습니다. 사실 저는 알고리즘이니 로직이니 하는 것에는 큰 관심은 없었고 결과물이 얼마나 쓸모 있는가에 관심이 많은 편이었는데, 저 역시 마음과 달리 급하게 빚은 송편 같은 모습을 한 결과물들이 나오는 것을 보고는 비슷한 괴리와 괴로움을 느끼곤 했습니다. 그러니까 저 이름에 공백조차 빼주지 않는 멍청한 소프트웨어도 그러한 괴리의 결과물이라고 볼 수 있을 것 같습니다.

사실 정말 큰 회사에서 정말 큰 시스템을 만드는데 혼자 순수성을 이야기하면서 프로젝트를 지연시키는 것은 어떤 측면에서 봐도 현명한 일은 아닙니다. 어쨌든 회사가 원하는 방향의 결과물을 내는 것이 회사에서 월급 받는 개발자들이 해야 할 일입니다. 시간은 얼마가 들어도 좋으니 끝내주는 결과물을 내놓으라고 하면 실력을 키우고, 결과물은 어떻게 나와도 좋으니 시간 내에 내놓으라고 하면 정신력을 키우면 되는 것이지요. 필요할 때 그렇게 하라고 월급을 꼬박꼬박 받는 것이니까요.

아까 그 홈쇼핑 앱으로 돌아가서, 어쨌든 이름 뒤의 공백을 지우고 주민등록번호 앞자리를 입력하니까 다음 화면으로 넘어는 갔습니다. 그런데 이미 가입된 아이디가 있다고 했습니다. 이왕이면 가입된 아이디가 뭔지도 알려줬으면 좋으련만 아이디 찾기 버튼을 누르라고 그러더군요. 어쨌든 어머니께 이미 가입하셨으니 아이디 찾기를 하셔서 아이디를 찾으시고 그걸로 로그인 하시면 될 것 같다고 말씀드리고 전화기를 돌려 드렸습니다. 그리고 모든 것이 끝났다고 생각하고 제 방으로 돌아왔습니다. 그런데 잠시 뒤에 또 어머니께서 저를 부르셨습니다. 다시 뛰어가서 보니 아이디는 찾으셨는데 비밀번호를 못 찾으시더라고요. 뭐가 문제일까 전화기를 다시 받아서 살펴봤는데 별로 특별할 것은 없었습니다. 아이디, 이름, 생년월일을 적고 전화인증을 하면 비밀번호를 초기화시켜주는 화면이었습니다. 그래서 뭐가 잘 안되시는지 여쭤보니 생년월일이 끝까지 안 들어간다고 하시더군요. 그래서 보니까 생년월일이 월까지 밖에 입력이 안 되어 있었습니다. 일자가 왜 안 들어가지? 하고 포커스를 옮겨서 숫자를 눌러봤는데 역시나 입력이 되지 않았습니다. 혹시나 하고 생년월일을 지워보니까 맙소사. 입력창에 회색으로 이렇게 가이드가 표시되었습니다. "YYMMDD"

순간 정신이 아득해졌습니다. 아 이 사람들은 공백은 검출할 줄 알면서 생일은 꼭 규격에 맞춰서 받아야 했나. 날짜 선택 컴포넌트 가져다 쓰는 게 어려울 수 있는 거야 이해하지만 그럴 바에는 주민등록번호 앞자리를 입력하라고 쓰던가 생년월일 6자리를 입력하시라고 표시를 해주던가. 세상에 저걸 알아들을 사람이 몇 명이나 된다고 저걸 저렇게 썼을까. 물론 저야 이 상황을 타개하기 위한 두 가지 조건 - (1) YYMMDD가 어떤 의미인지 알고 있을 것 (2) 어머니의 생일이 언제인지 알고 있을 것 -을 모두 만족하고 있었으니 비밀번호는 무리 없이 찾아서 결국 홈쇼핑 앱에 로그인을 시켜드렸습니다.

이렇게 어려운 회원가입과 로그인 과정을 거쳐서 얼마나 더 어려울지 모르는 상품검색과 결제 과정을 거쳐서 물건을 사느니 그냥 전화를 걸어서 지금 방송에 나오는 물건을 보내달라고 하는 쪽이 훨씬 사용자들에게는 편한 일이 아닐까 싶습니다. 이런 일이 있을 때마다 IT가 세상을 더 불편하게 만들기도 한다는 사실이 불편하게 다가옵니다. 우리 사회 전반에 흐르는 개발의 무게 중심이 빠른 완성에 모이고 있으니 나타나는 현상이겠지요.

이런 흐름이 바뀌기는 쉽지 않을 것입니다. IT가 원하는 것을 이루기 위한 수단으로 전락한 사회에서는 아무래도 힘들겠지요. 몇몇 스타트업 업체들이 아이디어와 제품의 완성도로 시장에 뛰어들면서 살짝 빛이 보이기도 했습니다만 전체적인 개발 시장의 규모에 비하면 아직은 큰 변화를 일으킬 정도의 규모는 아닙니다. 물론 그러한 업체들과 경쟁하기 위해서 큰 회사들도 일정 수준 이상의 퀄리티를 목표로 삼기 시작했다는 점은 고무적이기는 합니다. 동시에 시장 논리에 의해서 올라가는 품질은 같은 논리로 떨어질 수도 있다는 점에서는 회의적이기도 하지만요.

부정적인 이야기로 글을 쓰다 보면 결론은 그래도 조금은 밝고 희망적인 이야기를 해서 균형을 맞추고 싶은 욕심이 듭니다. 그래서 한 가지 이야기만 더 해보자면 저는 지난 몇 년 동안 회사에 들어온 신입사원들을 교육하는 일도 가끔 했는데, 제가 주로 맡은 일은 신입사원들에게 프로세스, 프로젝트 관리 도구(PMS), 프레임워크 등의 실무 교육을 해주는 일이었습니다. 프로세스, PMS, 프레임워크는 위에서 말했던 생산성의 극대화, 그러니까 개발의 어두운 흐름의 상징과도 같은 존재들이었습니다.

어릴 때부터 프로그래머의 꿈을 키어왔던 신입이건, 회사에 들어와서 프로그래밍을 처음 접한 신입이건 이 시기에는 다들 뭐 하나만 가르쳐줘도 정말 잘 배웁니다. 선배들이 프로세스에서 자유의 박탈을, PMS에서 결과 지상주의를, 프레임워크에서 영혼 없는 개발을 느낀다면 신입사원들은 이러한 일련의 실무들이 가진 본래의 목적 - 완성도 높은 시스템을 실수 없이 빠르고 정확하게 만들어내기 위함 -을 그대로 순수하게 받아들이는 것이 아닐까 느낄 때가 많았습니다.

교육을 마치고 프로젝트에 복귀해서 신입사원들이 이렇게나 순수하더라 라고 이야기하면 보통 듣는 말은 '프로젝트 몇 개만 돌다 보면 우리랑 똑같게 변할걸?'이라는 예상이었고 사실 저는 그 예상이 보통은 맞을거라고 생각합니다. 대형 프로젝트에 투입되는 순간은 육군훈련소 모퉁이를 도는 순간만큼이나 짜릿한 법이니까요. 프로젝트의 현실은 일반적으로 가혹하고 그 현장에서 미치지 않고 살아남기 위해서는 빠르게 현실을 받아들이고 자신을 개발의 흐름에 적응 가능한 형태로 변화해나가는 수밖에 없지요.

그런데 모든 신입사원이 다 그러는 것은 아닙니다. 가끔 보면 충분히 험한 현장을 많이 돌아다녔는데도 여전히 변하지 않은 후배들도 보였거든요. 마치 포식자들의 방해를 뚫고 바다에 도착한 새끼 바다거북을 보는 듯한 느낌이랄까요. 그런 친구들이라고 고민이 없고 방황이 없었던 것은 아니겠지만, 최소한 소프트웨어 개발자가 환경과 상관없이 포기해서는 몇몇 가치들을 아직도 가지고 있다는 점에서는 회사가 순도 높은 패배주의에 빠져들지는 않을 것이라는 확신을 하게 됩니다. 이런 친구들이 많아지면 많아질수록 우리가 좌절보다는 희망을 코드로 옮길 날이 다가올 것이라 믿습니다. 비록 지금의 현황이 아름답지 못하다고 하더라도 그게 모든 것들의 발전을 멈출 이유는 되지 않으니까요.