기술 트렌드를 쫓지 않는 법: 현명한 기술 선택

새로운 기술이 등장할 때마다 따라가야 한다는 압박을 저는 꽤 오래 느꼈습니다. 개발자 모임에서 누군가 새로운 도구를 소개하면 제가 뒤처지는 것처럼 불안했고, 회사에서도 유행하는 기술을 사용해야 더 세련된 결과물이 나올 것이라고 생각했습니다. 하지만 여러 프로젝트를 거치면서 기술의 이름보다 중요한 것은 해결하려는 문제의 크기와 팀이 감당할 수 있는 복잡성이라는 사실을 배웠습니다. 지금은 새로운 기술을 만났을 때 먼저 반가워하기보다, 우리에게 정말 필요한지부터 차분하게 따져보는 편입니다.

유행은 필요성을 대신해 주지 않는다

몇 년 전 회사에서 내부 업무용 화면을 새로 만든 적이 있습니다. 당시 주변에서는 최신 화면 구성 도구가 빠르고 편리하다는 이야기가 많았고, 저도 별다른 검토 없이 그 도구를 선택했습니다. 작은 화면 하나를 만드는 데는 실제로 속도가 잘 나왔지만, 두 달 뒤 담당자가 바뀌면서 문제가 드러났습니다. 팀원 대부분이 사용법을 익히지 못해 수정할 때마다 문서를 찾아야 했고, 공식 자료가 부족한 부분에서는 시행착오가 길어졌습니다. 결국 기능 자체보다 도구를 유지하는 시간이 더 많이 들었습니다.
그때 저는 기술 선택을 ‘무엇이 가장 앞서 있는가’가 아니라 ‘우리의 목적에 무엇이 충분한가’라는 질문으로 바꿨습니다. 사용자가 백 명도 되지 않는 사내 화면이라면 성능을 극한까지 끌어올리는 선택보다, 새로 온 사람이 며칠 안에 구조를 이해할 수 있는 선택이 더 합리적일 수 있습니다. 물론 오래된 방식만 고집하자는 뜻은 아닙니다. 다만 유행한다는 이유만으로 복잡한 도구를 들여오면, 얻는 이익보다 학습 비용과 관리 부담이 커질 수 있다는 점을 기억하게 됐습니다.

선택 전에 문제를 문장으로 적는다

저는 예전에는 기술 이름부터 검색했습니다. ‘요즘 많이 쓰는 화면 도구’, ‘빠른 저장 방식’처럼 검색하다 보면 수많은 비교 글이 나오고, 어느 순간 우리 문제보다 다른 사람의 평가에 끌려가게 됩니다. 지금은 반대로 불편한 상황을 먼저 한 문장으로 적습니다. 예를 들어 “고객 문의가 들어왔을 때 담당자가 세 가지 화면을 오가며 같은 내용을 반복해서 확인한다”처럼 현재의 문제를 구체적으로 씁니다. 이렇게 적으면 무엇을 새로 도입할지보다 업무 흐름에서 어디를 줄여야 하는지가 먼저 보입니다.
한 번은 팀에서 보고서 작성 시간을 줄이기 위해 큰 규모의 업무 도구를 검토한 적이 있습니다. 자료를 한곳에 모으고 권한을 세밀하게 나눌 수 있다는 설명은 매력적이었지만, 실제로 우리가 겪는 문제는 매주 한 번 파일 이름을 잘못 쓰는 정도였습니다. 그래서 처음부터 거대한 해결책을 적용하는 대신, 파일 양식을 통일하고 제출 전 확인 항목을 세 개로 줄였습니다. 결과적으로 보고서 작성 시간은 눈에 띄게 줄었고, 구성원들이 새 화면을 익히는 데 쓸 시간도 아낄 수 있었습니다. 문제를 정확히 쓰는 일이 때로는 기술 도입보다 강력했습니다.

작게 시험하고 되돌릴 수 있게 한다

새 기술을 선택할 때 제가 가장 중요하게 보는 기준은 실패했을 때 돌아올 수 있는가입니다. 예전에는 기대가 큰 기술일수록 프로젝트 전체에 빠르게 적용해야 효과를 볼 수 있다고 생각했습니다. 그 결과 한 번은 기존 화면의 핵심 부분을 새 방식으로 한꺼번에 바꿨고, 예상보다 많은 예외 상황이 나타나 일정이 밀렸습니다. 이전 방식으로 되돌리려 해도 변경 범위가 넓어 간단하지 않았습니다. 그 경험 이후에는 실제 서비스 전체가 아니라, 사용자가 적고 영향이 제한된 기능 하나를 골라 먼저 시험합니다.
작은 시험을 할 때도 단순히 “잘 된다”는 느낌만 확인하지 않습니다. 처리 시간, 사용자의 혼란, 담당자가 수정하는 데 걸리는 시간, 자료를 찾는 난이도처럼 기존 방식과 비교할 항목을 미리 정합니다. 이전에 새 편집 도구를 시험했을 때는 화면이 더 현대적으로 보인다는 장점보다, 오류가 났을 때 원인을 찾는 데 시간이 세 배 걸린다는 단점이 컸습니다. 그래서 정식 도입을 멈췄습니다. 처음에는 기회를 놓친 것 같았지만, 나중에는 큰 비용을 내기 전에 멈춘 결정으로 평가받았습니다.

팀의 현실을 기술 조건에 넣는다

기술 선택을 자료의 성능표만 보고 결정하면 실제 운영에서 예상하지 못한 문제가 생깁니다. 팀원이 몇 명인지, 특정 담당자에게 지식이 몰려 있는지, 장애가 생겼을 때 누가 대응할 수 있는지, 몇 년 뒤에도 자료를 구할 수 있는지를 함께 봐야 합니다. 저희 팀은 한때 한 명만 능숙하게 다룰 수 있는 도구를 사용했다가 그 사람이 휴가를 간 동안 간단한 설정 변경도 하지 못했습니다. 도구 자체는 훌륭했지만 팀의 현실과 맞지 않았던 셈입니다.
그 뒤부터 저는 회의에서 “이 기술을 누가 맡을 것인가”를 꼭 묻습니다. 담당자가 정해지지 않는다면 그 선택은 아직 준비되지 않은 상태라고 판단합니다. 또 새로 합류한 사람이 기본 작업을 수행하기까지 며칠이 걸리는지도 살핍니다. 기술 설명을 잘하는 한두 명의 열정만으로는 지속적인 운영이 어렵기 때문입니다. 업무가 바뀌거나 사람이 이동해도 유지되어야 한다면, 최고의 기술보다 충분히 이해할 수 있고 인수인계가 가능한 기술이 더 좋은 선택이 될 때가 많습니다.

기술을 바꾸지 않는 것도 결정이다

모든 문제를 새로운 도구로 해결하려는 습관은 비용을 눈에 보이지 않게 키웁니다. 교육 시간이 생기고, 기존 자료를 옮겨야 하며, 문제가 발생했을 때 원인이 업무인지 도구인지 구분하는 데 시간이 듭니다. 저는 한동안 “더 나은 방식이 있을 텐데”라는 생각만으로 잘 작동하던 업무 절차를 바꾸려 했습니다. 하지만 사용자가 불편을 호소하지 않고, 현재 방식의 비용도 감당 가능한 수준이라면 바꾸지 않는 편이 더 책임 있는 결정일 수 있습니다. 변화 자체가 성과는 아니기 때문입니다.
그렇다고 새로운 흐름을 무조건 외면할 필요도 없습니다. 저는 관심 있는 기술을 개인 메모에 적어 두고, 실제 업무에서 반복되는 불편과 연결될 때만 다시 검토합니다. 그 사이 다른 팀의 경험이나 실패 사례를 살피면서 우리 환경에 적용할 만한 부분이 있는지 확인합니다. 기술을 따라가는 속도를 늦추면 처음에는 뒤처진 듯한 기분이 들지만, 오히려 선택 기준이 선명해지고 불필요한 교체도 줄어듭니다. 제가 얻은 가장 큰 교훈은 모든 유행에 반응하는 사람이 아니라, 필요한 순간에 이유를 설명하며 선택할 수 있는 사람이 오래 성장한다는 사실입니다.
저는 이제 새로운 기술을 볼 때 “이것을 사용하면 우리가 무엇을 덜 하게 되는가?”라고 먼저 묻습니다. 배우는 시간, 유지하는 수고, 실수했을 때의 위험까지 고려한 뒤에도 분명한 이익이 남는다면 작은 범위에서 시험합니다. 반대로 이름만 새롭고 해결하려는 문제가 흐릿하다면 일단 보류합니다. 독자 여러분도 기술을 선택할 때 주변의 속도와 자신을 비교하기보다, 현재 겪는 문제를 정확히 적고 되돌릴 수 있는 작은 결정을 내려 보셨으면 합니다. 현명한 선택은 가장 앞선 것을 고르는 일이 아니라, 내 상황에서 오래 책임질 수 있는 것을 고르는 데서 시작됩니다.