시니어 엔지니어인 줄 알았는데, 도메인 전문가였습니다

회사에서 인정받는 엔지니어인데 이직이 잘 안 되는 분들을 봐왔습니다. 현재 회사에서는 PM과 관계도 좋고, 일정 안에 기능을 잘 만들어내고, 비개발자 동료들에게 "일 잘하는 개발자"로 통합니다. 그런데 이직 시장에 나가면 상황이 달라집니다. 면접에서 고전하고, 기술 역량이 높은 팀에서는 좋은 평가를 받지 못합니다.

이런 분들에게는 몇 가지 공통점이 있었습니다.

다른 엔지니어들과의 기술적 논의를 회피합니다

자신이 맡고 있는 프로젝트가 아니면 관심을 두지 않습니다. 팀에 공통 라이브러리가 있어도 자기 프로젝트에 맞춘 별도 라이브러리를 만듭니다. 팀에서 함께 만드는 인프라나 공통 모듈에는 기여하지 않습니다. 기여하지 않는 것이 아니라 못하는 경우도 있습니다. 확장성을 고려한 설계를 해본 경험이 없기 때문입니다.

코드 리뷰에서도 비슷한 패턴이 나타납니다. 도메인 로직에 대해서는 날카로운 의견을 내지만, 설계나 구조에 대한 논의에서는 조용합니다. 기술적으로 더 나은 방법이 있는지 고민하기보다, 이미 익숙한 방식으로 빠르게 구현하는 데 집중합니다.

어려운 기술적 문제 해결을 다른 엔지니어에게 의존합니다

어떤 구현이든 최대한 팀에서 기존에 하던 방식대로 코딩합니다. 검증된 패턴을 따르는 것 자체는 나쁘지 않습니다. 문제는 새로운 기술적 도전이 필요한 상황에서도 같은 태도를 유지한다는 것입니다.

성능 최적화가 필요하거나, 기존에 없던 아키텍처를 설계해야 하거나, 복잡한 동시성 문제를 해결해야 할 때, 이런 문제들은 자연스럽게 다른 엔지니어에게 넘어갑니다. 본인이 직접 해결한 기술적 문제의 범위가 좁습니다. 티켓에 적힌 요구사항을 구현하는 것과 기술적 문제를 해결하는 것은 다른 능력입니다.

시니어 엔지니어가 아닌, 주니어 도메인 전문가입니다

이것이 이 글의 요점입니다. 그들은 오랫동안 한 회사에 머물면서 그 시스템에 대한 이해도가 높아졌습니다. 어떤 테이블에 어떤 데이터가 있는지, 어떤 API가 어떤 비즈니스 로직을 처리하는지, 어떤 레거시 코드를 건드리면 안 되는지 잘 알고 있습니다.

이 도메인 지식 덕분에 일정 내 구현이 가능하고, PM과 원활하게 소통하며, 좋은 평가를 받습니다. 비개발자 직군에게는 "내 요청을 잘 해결해주는 개발자"로 인식됩니다.

하지만 기술적 역량만 놓고 보면 주니어에 가깝습니다. 도메인 지식이 기술 역량의 부족을 가려주는 구조입니다. 시스템을 오래 써왔기 때문에 빠르게 구현할 수 있는 것이지, 엔지니어링 역량이 뛰어나서 빠른 것이 아닙니다.

기술 역량이 높은 팀으로의 이직이 어렵습니다

소속된 회사의 도메인 전문가이기 때문에, 회사 밖에서는 그 역량의 가치가 급격히 떨어집니다. 이전 회사의 데이터 모델을 아는 것은 새 회사에서 아무 의미가 없습니다.

인터뷰에서는 엔지니어가 면접관으로 옵니다. 제대로 된 개발 팀이라면 그들도 알고 있습니다. 그가 티켓만 처리해왔는지, 엔지니어 역량을 쌓기 위해 노력해왔는지. 시스템 설계 질문에서, 문제 해결 과정에서, 기술적 트레이드오프에 대한 논의에서 차이가 드러납니다.

도메인 경험은 기술 위에 쌓여야 합니다

도메인 전문가 엔지니어가 되면 안 된다는 이야기가 아닙니다. 도메인 경험이 중요한 프로젝트도 있고, 그것이 정말 도움이 될 때가 있습니다. 헬스케어, 금융, 물류 같은 분야에서는 도메인 이해 없이는 좋은 시스템을 만들기 어렵습니다.

하지만 제품은 계속 변합니다. 도메인이 바뀔 때마다 역량이 0으로 돌아갈 수 있습니다. 반면 탄탄한 기술 역량은 도메인이 바뀌어도 유지됩니다. 시스템 설계 능력, 성능 최적화 경험, 복잡한 문제를 분해하는 능력은 어떤 도메인에서든 통합니다.

도메인 경험은 탄탄한 기술적 역량 위에 쌓여야 합니다. 그래야 이직 가능성도, 새로운 환경에 대한 적응력도 함께 확보할 수 있습니다.

요약

회사에서 인정받는 것과 엔지니어로서 성장하는 것은 다른 축입니다. 도메인 지식으로 현재 회사에서 좋은 평가를 받고 있다면, 그것이 기술 역량의 착각으로 이어지고 있지는 않은지 점검해볼 필요가 있습니다.