[개안뽑] ㊹개발자 역량 기준은 지능, 집중력이 아니라 센스다

Picture

Member for

3 months 4 weeks

Real name

Keith Lee

Bio

Head of GIAI Korea
Professor of AI/Data Science @ SIAI

Input

2024-01-30 18:30

개발자는 '만드는' 사람이 아니라 '문제를 해결하는' 사람
어떤 문제를 어떻게 해결할 수 있는지에 대한 센스를 갖추고 있어야 뛰어난 개발자
국내에서 찾기 쉽지 않은 인력, 해외에는 넘쳐나는만큼 노동 시장 접근 전략에 근본적인 고민 해 봐야

뛰어난 개발자의 기준은 뭘까?

그간 개발자 채용에서 수 많은 실패를 겪었는데, 이제 더 이상 한국에서 개발자를 뽑지 말자고 마음의 결정을 내린 시점이 되니 아이러니컬하게도 뛰어난 개발자를 판단할 수 있는 시야가 생긴 것 같다. 어쩌면 뛰어난 개발자를 볼 수 있는 눈이 생겼는데, 내 눈에 뛰어난 분들이 안 보이니까 결국 안 뽑게 된 것이 아니냐는 가까운 지인의 평가가 맞을지도 모르겠다.

내 눈에 뛰어난 개발자의 가장 핵심적인 요건은 '센스'다. 어떤 문제가 있다고 말이 나오면 그걸 어떻게 해결해야하는지, 그것도 가장 빠르고 효과적으로 해결할 수 있는 방법을 전체 시스템 관점에서 뽑아낼 수 있는 사람이 가장 뛰어난 개발자라고 생각한다. 그간 겪은 분들은 보통 그 문제가 무슨 문제인지 인지하는데도 시간이 걸렸고, 적절한 해법을 찾는 자료 검색 및 자료 이해에도 많은 시간을 써야 했고, 실제로 회사 서비스에 적용하는데는 굉장히 오랜 시간이 걸렸다. 이런 분들은 아무리 경력이 길게 쌓여도 좋은 개발자가 아닌 것이다.

개발자 역량의 기준은 '센스'다?

여러 웹서비스를 하나로 통합하면서 웹 사이트가 계속 무거워진다는 느낌을 받았다. 실제로 관리자 페이지가 열리는 속도가 매일 조금씩 느려지다가, 어느 시점에는 10초, 20초씩 기다리는 상황이 발생하니까, 직원들더러 관리자 페이지를 쓰라고 하기가 미안해지는 수준이었다. 예전에 개발자들이 만들어 놓고 간 시스템과 별반 달라지는 것이 없는 상황이 됐는데, 몇 달 동안 고생해서 시스템 만들었다고 하더니 뭐했냐는 말이 나올 것 같아서 답답했다.

결국은 DB를 읽어오는데 많은 시간이 걸리기 때문인데, 구글 검색을 해보면 DB에서 자료를 읽어오는데 걸리는 시간을 측정할 수 있는 'DB 쿼리 모니터(Query Monitor)'를 설치해서 문제의 원인을 파악해라는 설명들을 볼 수 있다. 써 보면 알겠지만, 어지간한 서비스들은 DB를 읽어오는 시간 자체는 별로 걸리질 않는다. 여러분이 접속 중인 파비리서치도 글을 쓰는 시점에 글을 모아놓은 테이블이 100MB가 조금 넘는 크기인데, 테이블의 크기가 크기는 하지만 읽어오는 속도는 0.1초 정도 밖에 걸리지 않는다. 그럼 도대체 뭐가 원인일까?

웹 서버 시스템을 잘 모르던 예전에는 그냥 워드프레스에서 추천해주는 속도 개선용 '캐시(Cache)' 프로그램들 몇 개를 깔았다 지웠다를 해 보면서 속도 테스트를 해봤었는데, 시스템에 대한 이해가 좀 더 쌓이니까 구조적인 생각을 하게 됐다. 관리자 페이지를 보는데는 DB에서 자료를 읽어오는 것과 더불어, 모든 정보를 html로 바꾸는 작업도 포함되고, 글을 모아놓은 테이블 정보와 연결된 다른 정보들을 읽어오는 작업도 포함된다. 그럼 html로 바꾸는 작업도 캐시에 추가하고, 글 테이블 이외에 연결되는 다른 테이블들도 바뀌는 내용이 없으면 캐시에 추가해놓으면 되지 않을까?

그런데 도대체 어떤 자료들을 추가로 더 읽어오길래 그렇게 오랜 시간이 걸리는걸까?

카테고리 정보, 태그 정보, 그 외에 내가 쓰고 있는 여러 서비스들과 연결된 정보들을 다 읽어오느라 상당한 시간이 걸리는 것을 알게 됐다. 그런데, 우리 회사가 더 이상 안 쓰는 카테고리와 태그가 많이 있는 것들이 문제의 원인 중 하나라는 것을 알게 됐고, 안 쓰는 태그들을 대규모로 삭제했다. 태그를 모아놓은 테이블의 크기가 줄어드니 태그와 글을 연결하는 작업도 훨씬 더 빨라지더라. SQL 구조상 Join이라고 불리는 함수를 이해하고 있으니 좀 더 쉽게 처리가 된 작업이기는 했는데, Join을 많이 해야되면 될 수록 문제가 생긴다는 것을 깨닫고, 우리 회사에서 쓰는 각종 플러그인들 중에 Join을 하도록 만드는 모든 서비스들을 제거해버리거나, 플러그인 코드를 수정해 버렸다. 20초씩 기다려야 했던 관리자 페이지가 7~8초로 줄어들었다.

문제의 원인 뒤에 숨은 또 다른 원인을 찾을 수 있어야

그리고는 DB를 캐시해주는 Redis Object Cache를 썼는데, 이것도 예전 같았으면 그냥 설치만 하고 돌아가기만 하면 알아서 잘 될 것이라고만 생각했을텐데, 이제는 경험치가 쌓이니 작업 방식이 달라졌다. 우선 DB를 캐시해주는 각종 서비스들을 Object Cache라고 부른다는 것, Redis라는 프로그램과 경쟁하는 여러 서비스들이 있다는 것, Redis는 DB에서 불러오는 정보를 압축하는 방식을 따로 갖고 있다는 것 등을 일단 알아냈다.

먼저 Object Cache의 여러 서비스들이 무슨 작업을 하는지, 우리 회사 사정에 맞는지를 가늠해보고, 내 목표대로 DB에서 불러온 값을 잘 저장할 수 있는지, 다른 서비스들과 충돌이 일어나는 일은 없는지를 따져봤다. 온갖 문제가 다 생기는 바람에 거의 1주일을 허비하고 심지어는 백업해놓은 DB를 복원해야하는 일까지 발생했는데, DB 정보들을 PHP 파일로 변경해서 갖고 있는 방식, PHP와 SQL을 잇는 SQLite3을 이용해는 방식, 캐시 파일 접근 속도를 높이기 위해 램 디스크를 이용하는 방식 등등을 모두 확인하고 점검한 후에 결국 현재의 셋팅으로 확정하게 됐다.

지금은 Redis Object Cache에서 파일 압축 방식을 Relay라는 걸 쓰면서 Redis 버전을 낮춰 호환성을 맞췄다. 시간을 너무 많이 쓰게 됐는데, 캐싱 방식이 DB 전체를 어떻게 읽어와서 저장하는지를 몰랐던 탓에 많은 시간을 썼고, 괜히 무리해서 강제로 파일 여러개를 만드는 방식의 개조보다, Relay로 압축하는 편이 더 파일 크기를 줄일 수 있다는 것을 뒤늦게 알게 됐다. 지금은 관리자 페이지가 뜨는데 평균 4초 정도 걸린다. 새로 만든 워드프레스의 관리자 페이지가 2~3초 정도 걸리는 것을 생각해보면, 굉장히 효율화가 이뤄진 셈인데, 문제의 원인을 제대로 파악하고 프로그램의 특성을 이해했었다면 훨씬 더 빠르게 작업이 이뤄질 수 있었을 것이다.

어디에서 무슨 문제가 발생했기 때문에 내 눈 앞에 이렇게 나타나는지 알아낼 수 있어야

하루는 관리자들이 봤던 페이지가 일반 유저에게 보이는 상황이 발생했다. 캐시된 정보가 그대로 남아있는데, 사용자 권한에 따라 분리되질 않았기 때문에 발생했던 문제다. 캐싱 서비스에 문제가 있는 것이 아닐까는 생각을 잠깐 했지만, 사용자 권한과 캐싱이 연동이 잘못된 탓이라는 생각에 권한 제한 프로그램의 설정 값을 변경하면서 문제를 해결했다.

이런 문제들을 프로그램 개발 팀에 질문해보면 훨씬 더 효율적으로 답변을 내놓는다. 이미 여러 사용자들의 문제를 해결해줬기 때문이기도 하겠지만, 그 이전에 사용자들의 문제가 뭐였을지를 짐작해보고 자기들 프로그램의 문제인지, 연관된 다른 프로그램의 문제인지를 직관적인 추론만으로 찾아내는 경우들을 종종 본다. 이런 분들에게는 질문을 하면 바로 답변을 받을 수 있을 것이라는 기대가 경험치로 누적되어 있고, 그 서비스는 당장 기능이 지원되지 않더라도 기대를 갖고 기다리게 된다.

반면, 우리 회사 서버에 직접 접근 권한을 달라고 하면서도 정작 아무런 해결책을 못 내놓는 경우도 자주 겪는데, 그런 경우에는 기다리다 지쳐서 결국 환불을 해 달라고 하거나, 그 전에 나 스스로 다른 대안들을 찾아다닌다. 적절한 대안이 없으면 시스템을 뜯어고치는 수준을 넘어서 서비스 구성을 변경하게 되는 순간도 온다. 원인은 그 분들이 문제 해결을 못 했기 때문인데, 덕분에 나는 만들던 서비스의 코드 몇 줄을 수정하는 것이 아니라, 아예 서비스 구성 자체를 완전히 뜯어고치고, 심지어는 회사 비즈니스 모델도 바꾸는 방식으로 대응해야 하기도 한다.

센스 없는 개발자의 능력 부족 때문에 회사의 비즈니스 모델이 바뀐다고 생각하면 얼마나 개발자의 센스가 중요한지를 공감할 수 있을 것이다.

어떻게 개발자들의 센스를 확인할 수 있을까?

마지막 개발자를 내 보내던 무렵, 이미지가 안 나오는 문제를 해결하는데 1주일이나 썼던 사건을 겪은 적이 있다. 심지어 그 1주일 중에 내가 1시간을 같이 뒤져서 문제의 원인을 파악해 줬는데도 그런 사소한 문제를 해결하는데 1주일이나 걸리는 것을 보고, 앞으로 개발자는 무조건 센스를 확인해서 뽑아야겠다는 생각을 하게 됐다.

위의 이미지 안 나오는 문제처럼, 뭔가 불편을 야기하는 사소한 문제를 하나 만들어놓고, 그 문제를 얼마나 빠르게 효과적으로 해결하는지, 그 때 어떤 해결책을 썼는지 설명하는 능력은 어떻게 되는지를 기준으로 개발자를 뽑아야겠다는 생각을 하게 됐다. 센스와 더불어 학습 속도, 문제 해결력, 논리적 추론 능력 등등을 모두 점검해 볼 수 있을 것이다.

어차피 나 같은 작은 회사 대표가 이런 빡빡한 절차로 개발자를 뽑겠다고 하면 아마 한국 땅에서 1명도 못 뽑을 것이다. 이걸 알고 있기 때문에 더 이상 한국에서 채용하겠다는 생각을 비웠고, 반대로 그런 센스가 넘치는 인력들을 영어권 워드프레스 게시판에서 흔히 볼 수 있는 만큼, 눈을 해외로 돌리겠다고 마음을 먹었다.

지난 몇 달간 해외 인력들과 다양한 교류를 하면서, 좀 더 일찍 눈을 돌렸었더라면 더 좋았을 것 같다는 후회가 가득하다. 이렇게 훌륭한 인재 풀이 있는 시장에 쉽게 접근할 수 있도록 모든 장벽이 내려가 있는 시대인데, 심지어 언어적인 제약도 없는데 왜 나는 그렇게 한국 시장에서 눈을 돌리지 못했을까?