점심 메뉴를 고를 때 두 부류의 사람이 있다. 네이버 지도를 열고 반경 500m 내 모든 식당의 별점을 비교하면서 "오늘 가능한 최선의 한 끼"를 찾는 사람. 그리고 회사 앞 국밥집 문을 열고 "여기 괜찮겠다" 하며 앉는 사람.

의사결정 과학에서는 전자를 maximizer, 후자를 satisficer라고 부른다. 허버트 사이먼이라는 경제학자가 만든 개념인데, 흥미로운 연구 결과가 있다. maximizer가 객관적으로 더 나은 선택을 하는 경우가 많다. 연봉도 높고, 식당도 맛있는 곳을 고른다. 그런데 만족도는 satisficer가 더 높다. 더 좋은 걸 골랐는데 더 불행하다. "혹시 더 나은 선택지가 있었을까?" 하는 생각이 끊이지 않으니까.

개발자 커리어에도 이 구조가 그대로 적용된다는 걸 최근에야 제대로 깨달았다.

기대치라는 트레드밀#

한 투자 칼럼니스트가 쓴 글에 이런 문장이 있었다. "기대치가 수입보다 빠르게 올라가면, 아무리 벌어도 절대 부자가 된 기분이 들지 않는다." 이건 돈 이야기였지만, 커리어에 대입하면 섬뜩할 정도로 정확하다.

트위터를 열면 20대 초반에 오픈소스 메인테이너인 사람이 있다. 컨퍼런스에서 발표하고, 개인 SaaS를 운영하고, 팔로워가 만 명이 넘는다. 프로필에 "Staff Engineer"라고 적혀 있다. 이런 사람을 매일 보면 기준선이 올라간다. 나도 저 정도는 해야 하는 거 아닌가. 매일 JIRA 티켓 처리하고, 코드 리뷰하고, 점심 먹고, 퇴근하는 내 하루가 초라해진다.

3년 전의 내가 지금의 나를 보면 "대단하다"고 했을 거다. 그때는 useEffect에서 cleanup 함수를 왜 써야 하는지도 몰랐으니까. 지금은 비동기 상태 관리 패턴을 설계하고, 성능 병목을 프로파일러로 잡고, 주니어 코드 리뷰를 한다. 객관적으로 많이 성장했다. 그런데 지금의 나는 5년차, 7년차의 기준으로 나를 본다. 트위터에서 보이는 동년배 천재는 극단적인 아웃라이어인데, 그걸 기본값으로 놓고 나를 깎아내리고 있다.

이게 트레드밀이다. 실력은 올라가는데 기대치가 더 빨리 올라가니까 영원히 "부족하다"는 느낌에서 못 벗어난다.

Satisficing은 게으름이 아니라 전략이다#

Satisficing을 처음 알았을 때는 "그냥 대충 살라는 거 아닌가" 싶었다. 그런데 파고 들어가면 전혀 다른 이야기다.

핵심은 이거다. "충분히 좋은" 기준을 먼저 정하고, 그 기준을 넘으면 더 이상 비교하지 않는다. 이건 기준이 낮다는 뜻이 아니다. 기준을 의식적으로 선택한다는 뜻이다. 한 에세이스트는 성공한 사람들의 공통점이 "거의 모든 것에 No라고 말하는 능력"이라고 썼다. 더 많은 걸 쌓는 게 아니라, 불필요한 걸 빼는 것이 전략의 본질이라고.

개발자 커리어에서 maximizing은 이런 모습이다. 기술 블로그 주 1회, 오픈소스 기여, 사이드 프로젝트, 새벽 알고리즘, 영어 공부, 독서 모임. 전부 "좋은 개발자"가 해야 하는 일이라고 생각하고 동시에 달린다.

나도 해봤다. 한 달 만에 전부 포기했다. 아무것도 제대로 못 하면서 "왜 나는 이것도 못 하지" 하는 자책만 남았다. 전형적인 maximizer의 함정이다. 가능한 최선을 쫓으니까 어떤 것도 "충분히" 하지 못한다.

지금은 딱 두 가지만 한다. 회사 일 잘 하기, 가끔 블로그 쓰기. 이게 내 "충분히 좋은" 기준이다. 이 기준 안에서는 에너지가 집중되니까 퀄리티가 올라간다. 회사 업무에 집중하니까 코드 리뷰에서 "이 부분 좋네요"라는 코멘트 빈도가 늘었다. 블로그에 집중하니까 검색 유입이 조금씩 생기기 시작했다. 열 가지를 50%로 하는 것보다 두 가지를 90%로 하는 게 결과적으로 더 많은 걸 만들어낸다.

빼기가 더하기를 이기는 경우#

흥미로운 실험이 하나 있다. 사람들에게 레고 구조물을 개선하라고 했더니, 대부분 블록을 추가하는 방식을 선택했다. 블록을 빼는 게 더 효과적인 상황에서도. 인간의 뇌는 "더하면 나아진다"는 편향이 있다.

개발자 커리어에서도 똑같다. "뭘 더 해야 성장할까?"는 항상 묻는데, "뭘 안 해야 성장할까?"는 잘 안 묻는다.

내 경우, 가장 효과적이었던 성장 전략은 트위터에서 다른 개발자의 성과를 구경하는 시간을 줄인 거였다. 비교 대상이 줄어드니까 불안이 줄었다. 불안이 줄어드니까 눈앞의 코드에 더 집중할 수 있었다. 집중하니까 결과물의 퀄리티가 올라갔다. 뭘 추가한 게 아니라 뭘 뺐을 뿐인데 실력이 느는 속도가 빨라졌다.

사이드 프로젝트를 억지로 유지하는 것도 그만뒀다. 주말에 쉬기로 했다. 이상하게도 월요일에 코드를 보는 게 전보다 덜 싫어졌다. 주말 내내 코드를 봤을 때는 월요일에 이미 지쳐 있었다. 쉬고 나니까 "어 이거 이렇게 하면 되겠는데"라는 생각이 자연스럽게 떠올랐다. 번아웃 상태에서 억지로 짜낸 아이디어보다 회복된 상태에서 떠오른 아이디어가 훨씬 쓸 만했다.

평범함의 복리#

여기서 하나 짚고 넘어가고 싶은 게 있다. "평범해도 괜찮다"가 "성장 안 해도 된다"는 뜻은 절대 아니다. 성장의 방식이 다른 거다.

10x를 추구하는 성장은 단거리 달리기다. 단기간에 화려한 결과를 만들어내고, 눈에 보이는 성과를 쌓는다. 문제는 지속성이다. 그 속도를 2년, 3년, 5년 유지할 수 있는 사람은 거의 없다. 번아웃이 따라오고, 방향이 흔들리고, 기대치와 현실의 간극에 무너진다.

"충분히 좋은" 성장은 복리 구조다. 투자 세계에서 복리의 핵심은 수익률의 크기가 아니라 중단하지 않는 것이다. 연 50% 수익을 3년 내다가 원금을 날리는 것보다, 연 8%를 20년간 유지하는 게 최종 결과가 훨씬 크다. 커리어도 마찬가지다.

매일 조금씩 나아지는 게 어떤 모습인지 구체적으로 보면 이렇다. 어제는 코드 리뷰에서 "LGTM"만 남겼는데, 오늘은 개선 제안을 하나 달았다. 어제는 에러가 나면 console.log만 찍었는데, 오늘은 소스맵을 따라가서 원인을 찾았다. 어제는 PR 설명에 "로그인 기능 추가"만 썼는데, 오늘은 왜 이 방식을 선택했는지 한 줄 추가했다.

트위터에 올릴 만한 건 아니다. 좋아요 0개짜리 성장이다. 그런데 이런 게 6개월, 1년 쌓이면 꽤 달라진다. 복리의 무서운 점은 초반에는 거의 안 보인다는 거다. 매일 1%씩 나아지는 건 처음 석 달은 아무도 모른다. 6개월이 지나면 슬슬 보이기 시작하고, 1년이 지나면 "이 사람 언제 이렇게 됐지?" 소리를 듣게 된다.

우리 팀에 이걸 증명하는 동료가 한 명 있다. 매일 PR 하나씩 올리는 사람이다. 엄청 빠르지도 않고, 코드가 예술적이지도 않다. 그런데 절대 밀리지 않는다. 스프린트 완수율 100%. 화려하지 않지만 팀에서 제일 신뢰받는다. "이 사람한테 맡기면 나온다"는 신뢰. 1년 전에 합류했을 때는 평범하다고 생각했는데, 지금은 이 사람 없으면 팀이 안 돌아간다. 한 방이 아니라 매일의 반복이 만든 결과다.

Good enough가 exceptional을 이긴 세 번의 경험#

돌이켜보면, 내 커리어에서 "적당한"이 "최고"를 이긴 경우가 확실히 있었다.

첫 번째는 사이드 프로젝트다. 최고의 기술 스택, 최고의 아키텍처를 만들겠다며 3개월을 끌었다. 결국 출시 못 했다. 그 다음에 "그냥 작동하면 된다"는 마인드로 주말 이틀 만에 만든 개인 블로그는 지금까지 운영 중이다. 완벽한 0개보다 적당한 1개가 낫다. 이건 산술이 아니라 진짜 경험한 결과다.

두 번째는 기술 선택이다. 새 프로젝트를 시작할 때 한 동료가 최신 기술을 강하게 밀었다. 더 빠르고, 타입 안정성도 높고, 커뮤니티가 성장 중이라고. 나는 "팀원 전부가 이미 잘 아는 기술을 쓰자"고 했다. 결국 익숙한 기술을 골랐고, 프로젝트는 일정 안에 끝났다. 6개월 뒤에 그 최신 기술은 메이저 버전이 바뀌면서 breaking change가 잔뜩 생겼다. 만약 그걸 골랐으면 마이그레이션 지옥을 겪었을 거다.

세 번째는 이직 타이밍이다. 부트캠프 동기 중에 6개월마다 이직하면서 연봉을 빠르게 올린 사람이 있었다. 나는 첫 회사에 2년 넘게 있었다. 조급했지만 그 2년 동안 같은 코드베이스를 유지보수하면서 배운 게 있다. 기술 부채의 무게, 설계 결정이 6개월 뒤에 어떻게 돌아오는지, 팀원이 바뀔 때 문서의 가치가 얼마나 올라가는지. 이건 6개월 만에 이직하면 절대 배울 수 없는 종류의 지식이다. 그리고 이 지식이 결국 다음 이직에서 시니어 레벨의 면접 질문에 답할 수 있게 해줬다.

세 경우 모두 maximizing을 포기하고 satisficing을 선택한 결과다.

기대치를 조절하는 구체적인 방법#

이건 체념이 아니다. 의식적인 기대치 설정이다.

내가 실제로 하는 건 이거다. 6개월 전에 짠 코드를 가끔 열어본다. "이걸 내가 짰다고?" 하면서 부끄러워지면, 그게 성장의 증거다. 6개월 전에 만든 컴포넌트를 열면, 왜 이렇게 긴 useEffect를 쓰고 있는지, 왜 상태를 이렇게 많이 만들었는지 바로 보인다. 이 부끄러움이 트위터의 좋아요 백 개보다 확실한 성장 지표다. 비교 대상이 남이 아니라 과거의 나이기 때문에 트레드밀에 빠지지 않는다.

투자 칼럼니스트의 글에 이런 문장도 있었다. "부유해지는 과정이 부유해진 상태보다 기분이 좋다." 커리어도 마찬가지다. "나는 아직 성장 중이다"라는 상태가 "나는 이제 다 됐다"보다 실제로 더 만족스럽다. 도달해야 할 지점이 아니라 걷고 있는 과정 자체에서 의미를 찾는 거다.

평범함의 수학#

소프트웨어 산업에서 "평범한" 개발자의 역할은 구조적으로 과소평가되어 있다. 대부분의 소프트웨어는 평범한 개발자들이 만든다. 매일 출근해서 이슈 처리하고, 코드 리뷰하고, 미팅하고, 퇴근하는 사람들. 화려하지 않지만 서비스가 돌아가게 하는 사람들.

10x 엔지니어 한 명이 없어도 회사는 돌아간다. "평범한" 개발자 열 명이 동시에 나가면 서비스가 멈춘다. 구조적으로 보면 시스템의 안정성은 소수의 천재가 아니라 다수의 평범한 사람들의 꾸준함에 의존한다.

가끔 비개발자 친구들이 "개발자면 대단하지 않냐"고 묻는다. 안에 들어와서 보면 나도 그냥 직장인이다. 출근하기 싫은 월요일이 있고, 회의가 지루한 오후가 있고, 퇴근하면 치킨 시켜 먹으면서 예능 보는 저녁이 있다.

그런데 그게 나쁜 게 아니다. 어쩌면 그게 최적의 전략이다. 점심 메뉴를 고를 때 모든 식당을 비교하는 사람보다, "여기 괜찮겠다" 하고 들어간 사람이 식사를 더 즐기는 것처럼. 최선을 쫓느라 소진되는 것보다 충분히 좋은 기준 안에서 복리를 굴리는 게 장기적으로 더 멀리 간다. 그리고 장기전에서는 멈추지 않는 사람이 이긴다. 화려한 사람이 아니라.