좋은 개발자

정답을 알려줘

인호준

Full Speed Ahead

2022-09-22

비교적 최근에, 지금 다니는 회사의 CTO님이 꽤나 근본적인 질문을 주셨었습니다.

좋은 개발자란 어떤 개발자인가?

물론 다른 회사에서도 물어보는 단골 질문이기 때문에 실제 면접관으로 참여하며 들었을 땐 내가 대답하는 게 아니니 그러려니 하고 깊게 생각하진 않았었는데 이 질문을 답하려고 하니 말문이 막혔어요. 답변을 작성하기 위해 무려 퇴근하고 컴퓨터에 앉아서 고민할 만큼.

이 질문이 우리에게 어떤 울림을 주는 목적이거나 잘못에 대한 우회 징계와 같은 성격을 띠진 않았고, 개발자 채용을 위한 우리들의 인재상을 종합한다는 명확한 이유가 있었기 때문에 같이 일하기 좋고 말이 잘 통하는 동료 정도로 적어서 제출했던 기억이 납니다.

지금 다시 생각해보니 좋은 동료뿐만 아니라, 이를 넘어서는 이상적인 좋은 개발자는 어떤 사람인가에 대한 대답은 꽤 비즈니스 친화적이지 못하고 학자나 엔지니어에 가까웠습니다. 어쩌면 CTO나 리드급 레벨의 마인드나 실력을 요구하는 수준이기도 했고요. 그래서 이상적이라는 생각이 들었습니다. 지금 뽑아서 같이 일할 동료들은 절대 이 기준을 두고 뽑으면 안 되겠구나 싶었습니다.

하지만 어쩌면 결국에 제가 생각한 좋은 개발자가 진짜 좋은 개발자라면 기간이 얼마나 걸리든 그 경지에 도달해야 합니다. 만약 그 정의가 틀렸다면 신념이나 직업관 정도로 포장해서 말하고 다니면 좋겠습니다. 이제 막 3년 차에 접어든 주니어 프런트엔드 개발자가 생각한 좋은 개발자의 기준 3가지는 비즈니스, 사용자 경험, 개발자 경험입니다.

비즈니스

비즈니스가 첫 번째 기준가치로 소개되다니 조금은 속물 같죠? 하지만 이 기준은 사실 1순위가 아니라 0순위입니다. 우리는 항상 급여를 받습니다. 본인의 회사를 만들어서 운영하더라도 마찬가지입니다. 돈이 어디서 셈 솟지는 않으니까요. 그렇다면 회사에서 요구하는 것을 정확하고 빠르게 이행해주는 것은 어떤 조직 구성원이든 당연한 것입니다.

즉 첫 번째 가치는 개발자뿐만 아니라 모든 직장인에게 해당한다고 볼 수 있습니다. 우리의 최우선 가치가 비즈니스라는 사실은 회사에 소속되어 있는 동안만큼은 절대 잊어서는 안 되고 가치판단에서 예외 되어서는 안 됩니다.

그럼에도 불구하고 이 가치가 좋은 개발자의 기준에 있는 이유는 개발자 중에는 이를 망각한 학자들이 꽤 있다는 점입니다. 항상 최신 기술만을 갈망한다던가 클린 코드, 클린 아키텍처만을 지향하는 사람들을 예로 들 수 있겠습니다. 두 가지 모두 정말 중요하다는 사실을 모두 알지만 최우선 순위는 아니에요.

클린 코드와 아키텍처

엉망진창 스파게티 코드를 마주해본 적 있나요? 저는 안타깝게도 있습니다. 제 기준에서 어떻게 이렇게 보기 힘든 코드를 프런트엔드에서 작성할 수 있을까 싶을 정도였어요. 아마 모든 개발자들이 지금 당장 에디터를 켜고 본인의 프로덕트 코드를 열면 비슷한 생각이지 않을까 싶어요.

저도 클린 코드라는 책도 읽었고, 그 목적과 방향성에 공감하며 그렇게 코드를 작성하려고 노력합니다. 하지만 비즈니스와 시간 앞에는 장사 없다는 점을 다 아실 거예요. 당장 잘못된 것을 알더라도 비즈니스 요구사항을 충족하기 위해 스스로 레거시를 생산해내기도 하니까요.

그럼에도 불구하고 모든 기준 앞에 위치한 것이 비즈니스입니다. 우리는 프로덕트가 비즈니스 요구에 맞게 동작해야 한다는 목적을 우선 달성해야 합니다.

저 또한 이런 상황이 괴롭기도 하고, 어떤 때에는 개발을 하는 게 아니라 그냥 사무직원인 것처럼 느껴지기도 합니다. 하지만 비즈니스가 제1원칙이어야 한다는 점은 우리가 어떤 조직에 소속해있는 한 무너지지 않습니다.

사용자 경험

사용자는 회사의 입장에서 고객이라 볼 수 있습니다. 현재 이용 중인 고객이든, 떠나간 고객이든, 잠재고객이든 전부 우리 고객이에요. 그들에게 좋은 경험을 주는 것은 서비스 플랫폼 기업에게 있어 숙명과도 같은 일입니다. 사용자 경험을 증대하기 위해 사실 개발자뿐만 아니라 모두가 노력한다고 봐도 과언이 아니죠.

개발자가 사용자 경험을 생각하지 않는다면, 더 좋은 방식이 있음에도 요구사항대로 동작하게만 만들고 서비스는 더 이상 발전하지 않습니다. 생각보다 다양한 상황이 있고, 이를 모두 고려하긴 힘드니까요. 우리는 최대한 사용자가 불편한 상황을 겪지 않도록 대비해둬야 합니다. 가령 다음과 같은 경우들을 위해서요.

사용자가 지하철에서 우리 앱을 켜면 어떻게 될까?
사용자가 엄청 노후한 휴대폰을 가지고 접근한다면?
Opera 브라우저 유저라면 어쩌지?
푸시를 받았을 때 키보드가 얼려있으면 어떻게 동작하게 할까?

프런트엔드 측면에서 기여할 수 있는 대표적인 케이스인 UI/UX, 성능을 예로 들어볼게요.

UI

버튼인 줄 몰라서 안 눌렀던 버튼, 접근성(Accessibility)이 떨어져서 일부 사용자들에게는 무용지물이던 기능들은 UI의 측면에서 문제가 됩니다. 이를 사용자의 히트맵, 마우스 여정, BreadCrumb 같은 사용자 행동 양상을 분석해서 실험하고 개선해서 좋은 프로덕트로 점점 나아갈 수 있습니다. UI는 우리가 전문가는 아니지만 실제 구현이나 더 나은 UI를 소개하고 제안할 수 있으며 데이터를 다룰 수 있으니 충분히 좋은 경험을 최 앞단에서 보여줄 수 있습니다.

기기마다 다르게 보이는 UI나 브라우저마다 다르게 동작하는 부분을 찾아 폴리필하는 과정도 포함됩니다. 어떤 기기는 접근 가능하고, 다른 기기는 보이지도 않거나 스크롤을 해야 보이는 현상도 종종 찾아볼 수 있거든요.

오류를 오류처럼 보이지 않게, 기다리는 기간도 기다리는 것 같지 않게 처리하는 과정도 매우 중요합니다. 물론 이 과정에서는 잘 설계된 플로우와 예쁜 디자인 에셋, UX를 훼손하지 않는 라이팅이 겸비되어야 하겠지만요, 프런트 레이어에서 사용자의 이탈을 막는 중요한 길목이라고 볼 수 있겠습니다.

성능

성능은 배부른 소리일 수 있습니다. 오동작처럼 보일 만큼 안 좋은 성능이 아닌 이상, 사실 성능이라 함은 사용자의 기기가 노후화되었거나 네트워크 성능이 좋지 않을 때와 같이 환경변수가 많이 개입하기 때문에 조금은 무례하지만 그건 당신 문제다라고 치부해버리고 넘어갈 가능성이 높죠.

하지만 사용자는 그런 점을 고려하지 않습니다. 내 기기가 안 좋다는 나중에 생각하더라도 왜 콘텐츠가 나오지 않지? 왜 흰 화면이 계속 반복되지? 왜? 왜? 를 먼저 생각하기 마련입니다. 이 앱은 잘 되는데 왜 이 앱은 이럴까?라는 생각도 하게 될 거예요.

생각해보면 성능은 사용자 경험의 최전선에 있습니다. 버튼을 눌러도 아무런 동작을 하지 않다가 나중에 처리된다던지, 검색어를 입력했는데 입력이 바로바로 보이지 않는다와 같은 문제는 동작은 되지만 성능으로 인해 사용자 경험을 떨어뜨린 예라고 볼 수 있습니다.

제가 생각하는 좋은 개발자는 잘 된다고 멈추지 않습니다. 사용자 경험을 생각해봤을 때 더 좋은 경험을 줄 수 있는 방법을 생각하고 제안합니다.

개발자 경험

개발자 경험(DX)이라는 용어는 생소하실 거예요. 저도 Next.js의 개발사로 잘 알려진 Vercel의 블로그에서 본 개념으로, 실제 프로덕트를 만드는 개발자가 코드를 작성해서 릴리즈할 때까지 수많은 툴을 사용하고 사용하기 위해 굉장히 많은 학습을 해야 한다는 문제가 있어서 생산성을 많이 떨어뜨립니다. 이 과정을 더욱 쉽고 매끄럽게 만드는 것을 개발자 경험이라고 합니다.

위 글에서 말하는 경험과는 조금 다르지만, 제가 생각하는 개발자 경험은 조금 더 현업에서 개발자들끼리 협업할 때의 상황에 치중해 있습니다. 한마디로 요약하자면, 같은 프로젝트의 모든 개발자들이 쉽고 빠르고 안전하게 개발할 수 있는 환경을 만들어 주는 것을 말합니다.

언제 터질지 모르는 레거시 프로젝트에서는 텍스트 하나 바꾸는 것도 두렵고, 새로운 기술로 범벅을 한 신규 프로젝트에서는 뭘 어떻게 쓰는지 몰라서 허덕입니다. 접근 권한에 대한 제한이 하나도 없어서 이 요소에 접근하면 문제가 되지 않을까 가슴을 졸입니다. 좋은 개발자는 이러한 부분까지 신경 써서 개발하고 지속적인 소통을 통해 알게 만듭니다.

모듈화

협업하는 사람들이 자주 사용하는 함수나 구조를 손쉽게 가져다 사용할 수 있도록 모듈화 하는 과정을 생각해볼게요. 예를 들어 날짜 객체를 YYYY년 MM월 DD일로 바꾸는 모듈은 서비스 기업이라면 정말 자주 쓸 거예요. 이 간단한 변환 함수를 사용할 때마다 다시 작성한다면 굉장히 번거로운 일이겠지요. 만약 기획 페이즈에서 모든 날짜 표시 수단을 YYYY.MM.DD로 바꿔주세요라고 요구한다면 이를 손수 다 바꿔야 하는 문제도 있을 것입니다.

위와 같은 사례는 여러 가지 기능이 엮여 조금 더 복잡해질 수 있습니다. 구조나 변수 이름을 직관적으로 짓는 가벼운 과정부터 지속적으로 복잡도를 낮추고, 추상화 레벨을 정해 가져다 쓰는 개발자 입장에서 꼭 알아야 할 정보 말고는 감춰주는 등, 사용자는 모르지만 협업하는 개발자들은 능률이 올라가는 모듈화를 해야 합니다.

문서화

코드는 당시의 상황을 설명하기에 부족할 때가 있지만, 문서는 그렇지 않습니다. 코드만 보고는 왜 그랬는지 추측하기가 쉽지 않다는 뜻입니다. 그 모든 상황을 코드만 보고도 알 수 있다면, 그리고 그런 코드를 작성할 수 있다면 이 글이 아마 필요 없는 분일 가능성이 높겠네요.

문서화는 귀찮은 작업입니다. 분명 비즈니스의 관점에서는 손해일 수도 있으니까요. 하지만 프로덕트 관리의 측면에서는 필요합니다. 최근 프로덕트 관리의 목적에서 안 쓰는 코드 제거 작업을 진행하고 있는데, 어디서 어떻게 쓰고 있는지가 명확하지 않고, 리팩터링을 하려고 해도 왜 이런 로직을 굳이 썼는지에 대한 확신이 없다 보니 작업이 엄청 더뎠습니다.

이게 단순 코드 한두 줄이 아니라 모듈이나 프로젝트 전체가 돼버리면 문제는 더욱 심각해집니다. 왜 이런 모듈을 가져다 썼는지, 왜 이 버전을 고정해두었는지, 왜 잘 되는 모듈을 고쳐서 썼는지 등등 코드만 봤을 땐 이해할 수 없는 모든 기록을 저장해둘 필요가 있습니다.

Outro

최근 어쩌다 저희 프런트엔드 팀을 대표해서 면접에 들어가고 있습니다. 이력서도 검토해보고요. 이 과정에서 느낀 점은 개발자로서의 자기 주관이 명확한 사람을 찾기가 힘들다는 점입니다. 나를 소개하기 전에 어떤 걸 했고 거기서 뭘 담당했다는 말만 적힌, 소위 찍어낸 이력서가 꽤 많았습니다.

만약 제가 면접 자라면 우선 주관을 가질 것 같습니다. 그리고 모든 답변에 그 기준을 끼워 팔 것 같아요. 가령 당신이 만든 캠페인 페이지가 오동작한다는 보고를 받았습니다. 어떻게 하시겠습니까?라는 질문에,

“빨리 고쳐서 배포 나가야죠 하하”

같은 실없는 대답보다는,

“오동작의 경우 사용자 경험을 하락시키므로 일단 마지막 배포 전으로 롤백 후 디버깅을 통해 문제를 해결한 뒤 재배포하겠습니다. 그게 비즈니스의 측면에서 옳습니다”

와 같은 대답이 더 신빙성 있고, 동일한 상황에서 정말로 그렇게 행동할 것 같다는 것입니다. 아무리 틀린 생각이라 하더라도 생각을 가지고 그 생각에 맞는 행동을 하는 개발자, 아니 그런 사람이 좋은 개발자가 아닐까 싶습니다.

개발자가 생각을 멈추고 시키는 대로 만들기만 하면, 생산 노동자의 대부분이 물건을 찍어내는 기계에 의해 지위를 잃어버렸듯 우리도 언젠가 멈춰버릴 것이라고 생각합니다. 우리는 멈춰버릴 자신을 경계해야 합니다.