문제의 경계는 직군의 경계와 다르다
프론트엔드 일이라 생각하고 시작했는데, 파고들다 보니 DDL까지 수정하고 있던 적이 있다. 화면의 문제로 보였지만 그 값을 저장할 자리부터 없었다.
그럴 때면 고민하게 된다. 여기까지가 내 일인가. 이쯤에서 "이건 백엔드 쪽입니다"라고 넘기는 게 오히려 맞는 태도가 아닌가.
얼마 전 프로덕트 엔지니어(Product Engineer)라는 역할을 다룬 글을 읽었다(Brian Jenney, IEEE Spectrum). 읽는 동안 새로운 직군의 소개를 보고 있다는 느낌이 들지 않았다. 최근 일하면서 자주 생각하던 내용을 누가 먼저 정리해 놓은 것 같았다.
글의 요지는 이렇다. 명세를 코드로 옮기는 일이 싸지면서, 엔지니어를 가르는 기준이 "주어진 태스크를 잘 구현하는가"에서 "무엇을 풀어야 하는지 알아내는가"로 옮겨간다. 저자는 기업이 이런 사람을 찾기 어려워하는 이유도 코딩 실력보다, 제품을 자기 문제처럼 바라보고 판단하는 엔지니어가 드물기 때문이라고 본다.
"코드는 싸다. 늘 그랬다. 다만 수십 년 동안 코드를 작성하는 데 너무 많은 시간이 들었기 때문에 그게 어려운 부분처럼 보였을 뿐이다."
Brian Jenney (IEEE Spectrum)
그러니 이 글은 유행하는 직함을 하나 더 소개하려는 것이 아니다. 저 이름이 가리키는 방향에 나도 공감하고 있고, 그래서 문제를 소유하는 쪽으로 가려 한다는 이야기를 적어두려는 것이다. 얼마 전에는 문제가 살아 있는 현장으로 먼저 걸어 들어가는 자리에 대해 적었다. 그건 회사 밖으로 나가는 이야기였고, 이번은 회사 안에 그어진 선에 대한 이야기다.
도메인은 구현을 위한 참고자료가 아니었다
원문에서 가장 오래 남은 대목은 고객이 일하는 도메인을 배우라는 조언이었다. 배관 회사용 소프트웨어를 만든다고 배관공이 될 필요는 없지만, 그 일을 하는 사람들이 실제로 무엇에 불평하는지는 알아야 한다는 것이다.
나는 급여와 연말정산을 만든다. 세법과 인사 제도는 매년 바뀌고, 그 규칙은 화면 밖에서 이미 정해져 도착한다. 그래서 도메인 지식을 '구현하려면 읽어야 하는 명세'로 대하기 쉽다. 조건을 읽고 분기를 짜고 검증을 붙이면 끝나는 것으로.
그런데 도메인을 알아야 하는 순간은 구현할 때가 아니라 그 앞이었다.
한번은 민감한 개인정보 항목 하나를 제품의 표준 필드로 추가하는 일을 했다. 법으로 구분이 정해져 있는 항목이라, 그 구분을 값으로 옮기고 필드를 하나 만들면 끝나는 일처럼 보였다.
걸린 건 상태 값이었다. 법이 나눠둔 구분 가운데 일부는 화면에 그대로 노출될 경우, 당사자가 직접 밝히지 않은 정보를 간접적으로 추론하게 만들 수 있었다. 법이 정한 구분을 그대로 옮겨 적는 것이 가장 정확한 구현인데, 그 가장 정확한 구현이 제품에서는 사고가 된다.
그래서 추론의 단서가 되는 값들을 중립적인 하나로 흡수하고, 판정처럼 들리는 이름도 사실만 말하는 이름으로 바꿔 상태 축 전체를 중립화했다.
이건 요구사항에 없었다. 법령을 읽어서 알 수 있는 것도 아니었다. 이 값이 누구의 화면에 뜨고, 그 화면을 보는 사람이 어떤 맥락에 놓여 있고, 잘못 보였을 때 현실에서 무슨 일이 생기는지를 그려봐야 나오는 결정이었다.
그러니 도메인 지식은 개발을 위한 참고자료가 아니라, 무엇이 문제인지 판단하기 위한 재료였다. 규칙을 아는 것과 그 규칙이 현실에서 어떻게 작동하는지 아는 것은 다른 일이다.
문제는 직군을 모르고 생긴다
조직도는 직군으로 나뉘어 있다. 프론트엔드와 백엔드, 기획과 디자인과 인프라. 그런데 문제는 그 선을 모르고 생긴다. 화면의 문제처럼 시작해서 원인이 API에 있고, 더 파보면 데이터 모델이 어긋나 있고, 애초에 제품 정책이 정의된 적이 없다.
그 지점에서 길이 둘로 갈린다. 여기부터는 다른 직군의 영역이라고 넘기거나, 필요한 만큼 들어가 보거나.
단건만 지원하던 다운로드를 여러 건 한 번에 처리하게 만드는 일이 그랬다. 열 개를 받으려면 열 번을 눌러야 했는데, 불편하다는 말이 티켓으로 올라온 적은 없었다. 화면 쪽에서 할 수 있는 일도 없었다. 여러 건을 묶어주는 경로가 서버에 아예 없었으니까.
들어가 보니 문제는 계속 다른 영역으로 넘어갔다. 여러 파일을 묶는 일은 요청 하나에 응답으로 끝낼 수 있는 작업이 아니어서 비동기로 설계해야 했고, 그 파일을 들고 있는 저장소는 우리 팀 밖에 있었다. 둘 사이의 인터페이스와 권한 책임을 누가 갖는지는 누구도 정해둔 적이 없었다. 결국 기획 문서를 쓰고, 작업 큐와 완료 판정의 흐름을 설계하고, 주인이 불분명했던 책임 경계를 공론화했다. 용량 정책도 실제 사용 데이터의 분포를 확인해 다시 정했다.
이 일을 하는 동안 계속 불편했다. 아무도 시키지 않은 일이었고, 내 전문 영역 밖까지 들어가고 있었기 때문이다.
이 일을 끝까지 맡아낸 뒤에는, 아예 무엇을 만들지부터 정해지지 않은 일을 맡게 됐다. 손으로 스프레드시트를 옮기던 작업을 도구로 대체하는 일이었는데, 요구사항 문서가 아니라 "이게 너무 오래 걸린다"는 문제 의식만 있는 상태에서 시작했다. 제품 정의 권한을 위임받아 사용자 시나리오를 정리하고 기획 문서와 데이터 모델을 그린 다음, 프론트엔드 전체와 백엔드 일부를 구현했다.
돌아보면 두 번째 일은 첫 번째 일의 결과였다. 경계를 넘어보겠다고 선언해서 얻은 게 아니라, 한 번 끝까지 맡아낸 경험이 다음 일의 근거가 된 셈이다.
그래서 오너십을 이렇게 정의하게 됐다. 모든 것을 내가 한다는 뜻이 아니라, 내 전문 영역 밖으로 문제가 이어졌다는 이유만으로 문제를 놓지 않는 것.
경계를 넘는 데에도 책임이 따른다
이 정의에는 대가가 딸려 있다. 이 부분을 빼면 오너십을 지나치게 좋게만 설명하게 된다.
넘어간 영역에서 나는 그 영역의 전문가보다 못한 사람이다. 그러니 그쪽의 리뷰를 받아야 하고, 내 판단이 틀렸다는 말을 들을 준비를 해야 하고, 내가 만든 기술적 부채까지 책임져야 한다. 앞의 필드를 더할 때도 운영 중인 데이터를 대량으로 다시 쓰지 않도록 마이그레이션 방식을 검토하고, 기존 값과 호환되는 상태 모델을 설계했다. 이미 운영 중인 영역까지 들어간다면 그 정도의 안전성은 내가 보장해야 했기 때문이다.
경계를 넘는 일은 그 영역을 가볍게 봐도 된다는 허가가 아니다. 그 구분을 놓치면 오너십이라는 말은 월권을 덮는 포장이 된다.
이 차이는 생각보다 또렷하다. 문제를 놓지 않으려고 경계를 넘는 사람은 그 영역의 규칙을 먼저 배우고, 자기가 만든 것을 그 영역의 기준으로 검증받는다. 반대로 내 문제를 빨리 치우려고 경계를 넘는 사람은 돌아가는 것만 확인하고 나온다. 겉으로는 둘 다 '경계를 넘은 것'처럼 보인다.
도구가 낮춘 것과 낮추지 못한 것
여기서 도구 이야기를 하지 않으면 최근 몇 년이 설명되지 않는다.
AI가 없었다면 같은 범위까지 들어가는 비용은 훨씬 컸을 것이다. 주력이 아닌 코틀린과 스프링으로 백엔드를 혼자 쓰는 일, 익숙하지 않은 DDL을 설계하고 검증하는 일이 그랬다. 예전이라면 이런 영역까지 직접 들어가는 일은 엄두를 내기 어려웠고, AI가 그 문턱을 크게 낮췄다.
다만 낮아진 것은 경계를 넘어가는 비용이었다. 넘어간 자리에서 판단할 책임은 그대로 남았다. 구현 속도는 도구에 기댔지만, 상태 축을 어떻게 세울지, 정합성을 어디서 보장할지, 마이그레이션을 운영 중에 실행해도 안전한지는 결국 내가 판단하고 검증해야 했다.
그래서 원문의 주장을 나는 이렇게 읽었다. AI가 왔으니 프로덕트 엔지니어가 되어야 한다는 말이 아니다. AI가 낮춘 것은 구현의 비용이고, 그만큼 무엇을 풀어야 하는지 판단하는 일이 더 선명하게 드러나고 있다. 구현에 많은 시간이 필요했던 때에는 두 능력을 구분하기가 지금보다 어려웠다.
문제가 이어지는 곳까지
프론트엔드를 잘하는 일은 여전히 중요하다. 그건 내가 문제를 푸는 데 가장 잘 쓰는 도구이고, 앞으로도 그럴 것이다.
다만 프론트엔드라는 경계만으로 내가 하는 일을 정의하고 싶지는 않다. 문제의 시작과 끝이 프론트엔드일 필요는 없다. 고객이 실제로 겪는 일을 이해하고, 아직 아무도 문제라고 부르지 않은 것을 문제라고 부르고, 필요하면 익숙하지 않은 영역까지 들어가 해결하는 것. 요즘 프로덕트 엔지니어라는 말을 편하게 받아들이는 이유도 여기에 있다.
결국 내가 소유하고 싶은 것은 특정 레이어의 코드가 아니라, 해결해야 할 문제다.
