2026 회고

2026년에는 데이원컴퍼니를 떠나 토스플레이스로 이직했다.

토스플레이스로 옮기면서 기대했던 건 개발자가 제품 의사결정에 더 가까이 참여하는 일이었다. 정해진 기획을 구현하는 데서 끝나지 않고, 어떤 문제를 풀어야 하는지부터 함께 이야기하고 싶었다.

목적조직 안에서는 실제로 그런 기회가 있었다. 개발자는 기술적인 제약만 설명하는 사람이 아니라, 제품의 방향과 우선순위에 의견을 낼 수 있는 구성원이었다. 대신 내가 낸 의견이 제품에 어떤 결과를 만드는지도 직접 생각해야 했다.

좋은 조직에 가면 좋은 코드가 나올까

토스플레이스에 오기 전에는 조금 막연한 기대가 있었다.

좋은 개발자들이 모여 있는 회사라면 코드도 전반적으로 잘 정돈되어 있을 것 같았다. 개발자들 사이의 기술 교류도 활발할 것 같았다. 어떤 문제를 발견하면 더 나은 기술을 선택하고, 그 선택을 제품에 반영하는 과정도 자연스럽게 이어질 거라고 생각했다.

실제로 토스플레이스는 코드 품질을 높게 지향했다. 다만 높은 기준이 있다고 해서 코드가 저절로 좋아지는 건 아니었다.

그 기준에 맞는 결과를 만들려면 결국 내가 충분히 문제를 이해하고 고민해야 했다. 팀의 일을 처리하면서 기술 부채도 해결해야 했고, 지금 필요한 기능과 더 나은 구조 사이에서 계속 판단해야 했다.

사일로에서 일한다는 것도 비슷했다. 제품에 깊게 들어가서 빠르게 결정할 수 있다는 장점이 있지만, 모든 문제를 원하는 방식으로 해결할 수 있다는 뜻은 아니었다.

예를 들어 앱 라우터의 스트리밍 렌더링을 활용하면 더 나은 제품을 만들 수 있겠다고 생각해도, 현재 인프라와 클라이언트 구조 안에서는 클라이언트 사이드 렌더링을 유지해야 하는 경우가 있었다. 더 좋은 기술이나 구조를 알고 있어도 지금 당장 선택할 수 없는 순간이 있었다.

처음에는 이런 상황이 아쉽게 느껴졌다. 좋은 기술을 알고 있고, 그 기술을 적용했을 때 어떤 장점이 생기는지도 알고 있는데 현재 제품의 조건 때문에 적용하지 못했기 때문이다.

하지만 제품을 만드는 일은 기술만으로 결정되지 않았다. 이미 운영 중인 시스템이 있고, 팀이 해야 할 일이 있고, 사용자에게 제공해야 하는 기능이 있었다.

기술 부채를 해결하는 일과 메인 업무를 동시에 진행하려면 단순히 기술적으로 옳은 답을 찾는 것만으로는 부족했다. 지금 이 문제를 해결하는 게 맞는지, 해결한다면 어디까지 해야 하는지, 이 작업이 팀의 목표와 연결되어 있는지를 계속 판단해야 했다.

운영 중인 기능을 바로 맡았다

첫 DRI는 운영 중인 기능을 개선하는 일이었다. 신규 입사자라고 해서 한 발 물러나 업무를 보조하는 방식은 아니었다. 내가 맡은 일은 직접 이해하고, 판단하고, 끝까지 해결해야 했다.

한편으로는 기분이 좋았다. 나를 바로 투입할 수 있는 사람으로 인정해준다는 느낌이 들었기 때문이다. 아직 조직과 서비스에 익숙하지 않은 사람이라도, 내가 맡은 영역에서는 책임 있는 역할을 할 수 있다고 봐준 셈이다.

하지만 문제가 생겼을 때는 조금 달랐다.

신규 입사자라는 이유로 보호받기보다는, DRI를 가지고 있다는 이유로 스스로 문제를 해결해야 했다. 서비스에 문제가 생기면 먼저 상황을 파악하고, 코드를 읽고, 원인을 추측하고, 필요한 사람에게 질문해야 했다.

처음에는 조금 가혹하다고 생각했다. 서비스와 코드를 충분히 알지 못하는 상태에서 운영 중인 기능을 맡았기 때문이다.

온보딩에서 서비스가 어떤 일을 하는지는 배울 수 있었다. 하지만 코드가 왜 지금과 같은 모습이 됐는지, 과거에 어떤 선택을 거쳐 현재의 구조가 만들어졌는지까지 모두 설명받기는 어려웠다.

코드의 현재 상태는 볼 수 있었지만, 그 상태에 이르기까지의 히스토리는 직접 찾아야 했다.

나는 AI를 활용해서 나를 온보딩했다. 낯선 코드를 설명해달라고 하고, 관련된 파일을 찾아달라고 하고, 특정 구조가 어떤 역할을 하는지 물어봤다. 예전이라면 오래 걸렸을 학습을 훨씬 짧은 시간 안에 진행할 수 있었다.

그래서 코드 자체를 이해하는 데 큰 문제는 없었다. 다만 AI가 설명한 내용이 실제 히스토리와 맞는지는 계속 확인해야 했다. 관련된 커밋과 코드를 다시 찾아보고, 동료에게 질문하고, 내가 세운 가설이 맞는지 검토해야 했다.

AI는 빠르게 이해할 수 있도록 도와줬지만, 그 이해가 맞는지 책임져주지는 않았다.

물론 지금도 장애가 나면 당황한다. DRI를 여러 번 경험했다고 해서 장애가 아무렇지 않아지는 건 아니다. 다만 예전처럼 당황한 상태로 멈춰 있지는 않게 됐다. 어디부터 확인해야 하는지, 어떤 가설을 세워야 하는지, 누구에게 어떤 질문을 해야 하는지는 조금씩 알게 됐다.

자유롭게 결정하는 만큼, 서로 덜 알게 된다

DRI를 맡고 나서 또 하나 낯설었던 건 코드리뷰였다.

처음에는 코드리뷰가 꽤 느슨하다고 생각했다. 내가 기대했던 코드리뷰는 구현 방식뿐 아니라 제품 맥락까지 함께 확인하는 과정이었다.

이 코드가 왜 필요한지, 이 기능이 사용자에게 어떤 영향을 주는지, 지금의 설계가 제품의 방향과 맞는지까지 동료들과 함께 검토하는 방식이다.

그런데 DRI가 있는 구조에서는 조금 다르게 느껴졌다.

이미 DRI가 해당 업무를 충분히 검토했고, 그 결과에 책임을 지고 있을 거라는 전제가 있었다. 그래서 리뷰어는 코드의 생김새와 구현 방식에 집중하면 되는 것처럼 보였다.

네이밍이 괜찮은지, 컴포넌트가 적절히 나뉘었는지, 예외 처리가 빠지지 않았는지, 불필요한 복잡성이 없는지를 확인하는 식이다.

물론 제품 맥락까지 알고 있는 동료라면 코드의 모양과 제품의 의도를 함께 볼 수 있다. 하지만 모든 리뷰어가 모든 제품의 맥락을 알고 있기는 어렵다.

토스플레이스에서는 프론트엔드 챕터라는 기능조직에 속해 있지만, 실제 업무는 각 팀과 사일로라는 목적조직 안에서 진행된다. 같은 프론트엔드 개발자라도 서로 다른 제품을 보고 일한다.

기술적인 고민은 어느 정도 공유할 수 있지만, 그 기능이 왜 필요한지, 어떤 사용자를 위한 것인지, 과거에 어떤 판단을 거쳐 지금의 구조가 됐는지는 팀 밖의 사람이 알기 어렵다.

처음에는 이 구조가 조금 기괴하게 느껴졌다.

개발자가 제품 의사결정에는 자유롭게 참여할 수 있는데, 정작 다른 개발자가 그 의사결정의 배경까지 깊이 이해하기는 어려운 구조였기 때문이다.

제품 결정에는 자유롭게 참여할 수 있었지만, 다른 팀 사람이 그 결정의 배경까지 알기는 어려웠다.

그런데도 코드는 계속 리뷰되고 배포됐다. 지금까지 이 방식이 유지될 수 있었던 건 동료들이 각자의 제품을 충분히 이해하고 맡은 일을 끝까지 책임졌기 때문이라고 생각한다.

나는 제품을 잘 아는 사람이 코드의 의도까지 확인하는 절차가 필요하지 않을까 생각했다. DRI가 잘 검토했을 것이라는 전제만으로 충분한지, 다른 사람이 제품 맥락까지 확인할 방법은 없는지 궁금했다.

토스플레이스에서 일하면서 느낀 건, 내가 생각했던 것보다 조직이 훨씬 느슨하다는 점이었다.

모든 사람이 모든 것을 확인하지 않았다. 각자의 책임 범위를 정하고, 그 범위 안에서는 서로의 판단을 믿었다.

처음에는 그 느슨함이 검증의 부족처럼 보였다. 나중에는 DRI가 책임을 분산하는 방식이 아니라, 서로 모든 것을 확인하지 않아도 일할 수 있도록 책임의 위치를 분명하게 만드는 방식일 수 있겠다고 생각하게 됐다.

그렇다고 지금도 완전히 동의하는 건 아니다.

빠르게 일할 수 있다는 장점은 있지만, 제품 맥락이 팀 안에만 갇히면 다른 사람이 문제를 발견하기 어려워진다. DRI의 판단이 틀렸을 때 그것을 발견할 장치도 필요하다.

한 사람이 책임지고 빠르게 결정하는 구조에서, 나머지 사람들은 어디까지 믿고 어디까지 검증해야 하는가. 나는 아직 이 질문에 답을 찾는 중이다.

나는 이 조직에서 잘하고 있는가

나는 이 조직에서 정말 잘하고 있는가.

AI를 활용해 서비스와 코드를 빠르게 이해하고 운영 중인 기능을 개선할 수 있었다. 예전보다 훨씬 짧은 시간 안에 낯선 도메인에 들어갈 수 있게 됐다.

그런데 빠르게 배우고 결과물을 내는 일은 이제 나만의 능력이 아니다. 누구나 AI에게 코드를 설명해달라고 할 수 있고, 필요한 코드를 만들어달라고 요청할 수 있다. 내가 더 잘해야 할 일은 그 다음에 있었다.

AI가 설명한 내용이 실제 서비스의 히스토리와 맞는지 확인하고, 지금 해결하려는 문제가 정말 중요한지 판단하고, 언제 다른 사람에게 도움을 요청할지 결정하는 일이다.

그래서 동료와 함께 조직 전체에서 버그를 제보할 수 있는 자동화 도구를 설계하고 있다. 특정 팀이나 개발자만 문제를 발견하는 게 아니라, 누구나 이상한 상황을 발견했을 때 쉽게 공유하고 필요한 정보까지 남길 수 있도록 만드는 도구다.

에이전트가 모든 문제를 알아서 해결하게 만들 생각은 없다. 버그 제보가 들어왔을 때 관련 코드를 찾고 원인을 추정하는 단계와, 실제 수정안을 반영하기 전에 사람이 확인하는 단계를 나누는 일이 먼저다.

지금 내가 동료와 함께 설계하는 건 조직 전체가 버그를 제보할 수 있는 자동화 도구와, 그 제보를 바탕으로 수정안을 만들 수 있는 에이전트다. 코드를 더 많이 생성하는 것보다, 문제가 들어오고 검증되는 과정을 먼저 잘 만드는 데 관심이 있다.

DRI 구조에서 한 사람이 빠르게 결정하는 건 여전히 중요하다. 다만 그 판단이 한 사람의 경험으로만 남으면 같은 문제가 다시 생겼을 때 조직은 또 처음부터 시작해야 한다. 판단에 필요한 정보를 모으고, 결과를 확인하고, 다음 사람이 이어받을 수 있게 만드는 도구가 있어야 한다.

아직 내가 이 조직에서 정말 잘하고 있다고 말하기는 어렵다. 장애가 나면 여전히 당황하고, 내가 내린 판단이 맞는지 다시 확인할 때도 많다. 다만 혼자 더 빨리 코드를 작성하는 것보다, 문제를 정확히 정의하고 판단 전에 필요한 정보를 모으는 쪽으로 더 잘하고 싶다는 생각은 분명해졌다.

2026년의 나는 AI를 활용해 빠르게 배우는 법을 익혔다. 다음에는 그 능력을 나 혼자 빠르게 일하는 데만 쓰지 않고, 사람의 판단이 더 정확해지고 조직이 같은 문제를 반복하지 않도록 만드는 데 쓰고 싶다.

토스플레이스에서 보낸 올해는 내가 잘하고 있다는 확신을 얻은 해는 아니었다. 대신 어떤 판단을 사람에게 남기고, 그 판단을 돕기 위해 어떤 검증 도구를 만들어야 하는지 고민하기 시작한 해였다.