2026 상반기 회고

상반기 회고를 쓰려고 지난 기록을 다시 열어봤다.

분명 많은 일을 했다. 기능도 만들었고 장애도 해결했고 오래된 시스템을 옮기는 작업도 했다.

그런데 막상 기억나는 것은 많지 않았다.

몇 달 전 나는 생산성은 늘었고, 몰입은 사라졌다는 글을 썼다. 일을 많이 끝내고도 오늘 무엇을 했는지 잘 떠오르지 않는다고 적었다. 상반기 회고가 늦어진 이유도 어쩌면 비슷한 데 있었는지 모른다.

기록을 하나씩 다시 읽고 나서야 그 시간 동안 달라진 것이 조금씩 보이기 시작했다.

처음에는 코드를 이해하는 것만으로 벅찼다. 지금은 코드를 바꾸고 나서 어디까지 문제가 생길지를 더 걱정한다.

덜 헤매게 된 대신, 조금 더 무서워하게 되었다.

⸻

3개월 회고 이후

입사 3개월 회고에서는 동시에 너무 많은 것이 처음이었다고 썼다.

비즈니스 도메인도 처음이었고 Python도 낯설었으며 비동기 작업을 다루는 것도 익숙하지 않았다. 기능 하나를 수정하려면 어디에서 요청이 시작되고 어떤 서비스를 거쳐 무엇이 바뀌는지부터 찾아야 했다.

그때는 코드를 읽어도 내가 지금 무엇을 보고 있는지 알기 어려웠다.

반년이 지난 지금은 모든 것을 알게 되었을까.

당연히 아니다.

여전히 처음 보는 코드가 많고 새로운 업무를 받을 때마다 모르는 도메인이 나타난다. 그래도 어디서부터 확인해야 하는지는 조금 알게 되었다.

요청이 시작되는 곳을 찾고 상태가 변하는 지점을 따라가며 그 과정에서 발생하는 부수효과를 확인한다. 코드 한 줄만 보기보다 그 앞과 뒤에 이어진 흐름을 함께 보려고 한다.

모르는 것이 줄었다기보다, 무엇을 모르는지 찾아가는 법을 조금 배웠다.

기능 하나는 기능 하나로 끝나지 않았다

상반기에는 사장님이 직접 마케팅 캠페인을 만들고 운영할 수 있는 기능을 개발했다.

캠페인을 생성하고 조회하고 수정하는 API를 만들면 되는 일처럼 보였지만 실제 업무는 그렇게 단순하지 않았다.

작성 중인 캠페인이 있고 제출되어 검수를 기다리는 캠페인이 있다. 반려된 캠페인은 다시 수정할 수 있어야 하고 모집 중인 캠페인은 정해진 조건에 따라 연장되거나 중단될 수 있어야 한다. 동시에 같은 요청이 들어오더라도 상태가 잘못 바뀌면 안 된다.

하나의 상태는 사용자 화면에만 존재하지 않았다. 사장님이 보는 화면, 운영자가 사용하는 관리 도구, 여러 백엔드 서비스가 같은 상태를 서로 다르게 이해하면 문제가 생겼다.

구현을 먼저 시작했다가 뒤늦게 상태와 정책을 다시 맞추면서 수정한 일도 있었다. 코드는 이미 동작하고 있었지만 각 시스템이 같은 단어를 같은 의미로 사용하고 있는지는 별개의 문제였다.

이 일을 겪으며 기능을 만든다는 것은 화면에 필요한 API를 채우는 일이 아니라는 것을 배웠다.

누가 상태를 바꾸고 어떤 상태에서 다음 상태로 이동할 수 있는지 먼저 정해야 했다. 실패했을 때 되돌아갈 지점과 다른 시스템에 전달할 정보도 빠뜨릴 수 없었다.

이 질문들이 정리되지 않은 채 작성된 코드는 동작하더라도 아직 끝난 코드가 아니었다.

외부 API가 들어온다는 것

상반기에는 CGV 상품에 외부 API가 연동되었다.

내가 외부 API 자체를 직접 연동한 것은 아니다. 대신 연동 이후 기존 시스템을 새로운 방식에 맞게 옮기고 그 과정에서 생기는 운영 문제를 정리하는 일을 맡았다.

연동된 API는 핀의 유효성을 확인하고 사용 처리하고 취소 처리하는 세 가지였다. 각각 요청을 보내고 응답을 받아 저장하면 되는 일처럼 보였다.

이미 운영 중인 시스템에 외부 API를 붙이는 일은 새로운 기능 하나를 만드는 것과 달랐다.

그전까지 핀은 여러 서비스와 운영 절차를 거쳐 관리되고 있었다. 핀을 등록하고 판매하고 사용하고 취소하고 환불하는 경로가 각각 다른 코드와 데이터에 얽혀 있었다. 사람이 직접 처리하던 작업도 있었고 오래된 서비스만 알고 있는 규칙도 있었다.

그 위에 새로운 API가 들어오자 고려해야 할 것이 한꺼번에 늘어났다.

기존 핀과 새로 발급된 핀이 함께 존재할 때는 어느 시스템의 데이터를 기준으로 볼지 정해야 했다. 외부 API 호출은 성공했는데 내부 저장에 실패한 경우도 대비해야 했다. 취소 요청과 실제 취소 완료, 결제 환불을 각각 누가 기록할지, 운영자가 어느 화면에서 상태를 확인하고 다시 처리할지도 문제였다.

외부 API는 기존 시스템 바깥에 있던 복잡성까지 안으로 가져왔다. 우리 코드만 잘 동작한다고 끝나지 않았다. 외부와 내부 시스템의 상태가 계속 같은 의미를 가져야 했다.

이 과정에서 기존 구조의 애매한 부분도 드러났다. 하나의 컬럼이 어떤 코드에서는 취소 요청을, 다른 코드에서는 실제 환불 완료를 의미하고 있었다. 평소에는 우연히 맞아떨어지던 규칙이 새로운 흐름과 만나자 더 이상 우연에 기대기 어려워졌다.

한 번에 모든 것을 바꾸기에는 위험했다. 상품별로 기존 경로와 새로운 경로를 선택할 수 있는 기준을 만들었다. 데이터가 적은 상품부터 조금씩 옮기고 문제가 생기면 해당 상품만 기존 경로로 되돌릴 수 있게 했다.

전환이 끝난 뒤에는 새로운 경로를 추가하는 것만큼 기존 경로를 지우는 일도 중요했다. 남아 있는 의존성을 하나씩 찾고 중복된 라우팅을 없애며 서로 다른 의미로 사용하던 상태를 분리했다. 사람이 반복하던 유효기간 갱신 같은 작업도 스케줄러로 옮겼다.

아직 모든 것이 깔끔해진 것은 아니다. 오래 운영된 시스템은 한 번의 작업으로 정리되지 않았고 지금도 남아 있는 경로가 있다.

그래도 얽히고설킨 채 운영되던 시스템이 조금씩 나아지는 과정은 볼 수 있었다.

큰 그림을 새로 그려 한 번에 교체한 것은 아니었다. 애매했던 상태 하나를 분리하고 수동 작업 하나를 자동화하며 더 이상 사용하지 않는 의존성 하나를 제거했다.

시스템을 개선한다는 것은 완전히 새로운 것을 만드는 일만은 아니었다. 이런 작은 정리를 실제 운영에 계속 반영하는 일도 필요했다.

빠르게 만들고 빠르게 깨뜨렸다

결제와 외부 서비스의 통신 방식을 수정하면서 영향 범위를 충분히 확인하지 못해 다른 결제 경로에 문제를 만든 적이 있다. 의존성을 올리면서 두 개의 lockfile이 서로 다른 버전을 가리키는 것을 놓쳐 운영 서버가 정상적으로 실행되지 않은 적도 있다.

두 문제 모두 수정하려던 코드 자체만 보면 그럴듯했다. 문제는 그 코드가 어디에서 사용되고 실제 배포 환경에서는 어떤 기준으로 실행되는지를 끝까지 확인하지 않았다는 데 있었다.

나는 종종 눈앞의 문제를 해결하면 일이 끝났다고 생각했다.

공통 코드는 생각보다 많은 곳에서 사용되고 있었다. 내 로컬에서 선택된 의존성과 운영 이미지가 선택하는 의존성은 달랐다. 하나의 결제 요청 뒤에는 결제 상태뿐 아니라 상품 발급, 알림, 취소와 환불이 함께 이어져 있었다.

빠르게 이해했다고 생각했고 빠르게 수정했다. 그리고 몇 번은 빠르게 깨뜨렸다.

AI의 도움으로 코드를 파악하고 수정하는 속도는 분명히 빨라졌다. 그 속도만큼 영향 범위를 충분히 이해한 것은 아니었다.

AI가 놓친 것이 아니라 내가 확인하지 않은 것이었다.

복구한 다음에 무엇을 남길 것인가

상반기에는 크고 작은 운영 문제를 여러 번 마주했다.

결제 과정에서 예상하지 못한 요청이 반복되기도 했고 백그라운드 작업이 오랫동안 멈춘 뒤 한꺼번에 쌓여 서버가 버티지 못한 일도 있었다.

장애가 발생하면 빠른 복구가 먼저다. 문제는 복구만 하고 끝냈을 때였다. 비슷한 문제가 다른 모습으로 다시 돌아왔다.

그래서 조금씩 다른 것을 남기기 시작했다.

문제를 재현하는 테스트를 추가하고 여러 서비스를 로컬에서 함께 실행할 수 있는 환경을 만들었다. 한 프로세스에 섞여 있던 주기적인 작업과 일반 작업을 나누고 사람이 반복하던 운영 작업은 관리 API나 스케줄러로 옮겼다.

장애를 해결한 코드가 결과의 전부는 아니었다. 같은 문제가 생겼을 때 더 빨리 발견할 수 있는지, 발생하더라도 더 작은 범위에서 멈출 수 있는지까지 함께 보려고 한다.

완벽하게 막을 수 없다면, 적어도 사고의 반경은 줄일 수 있어야 한다.

나는 Meat Proxy가 되고 있는 걸까

입사 초기와 비교하면 AI를 사용하는 일은 훨씬 익숙해졌다.

낯선 코드를 분석할 때도, 장애의 원인을 추적할 때도, 테스트를 만들 때도 AI를 사용한다. 여러 터미널에서 각기 다른 작업을 동시에 진행하는 것도 이제는 자연스러운 일상이 되었다.

최근 Meat Proxy라는 표현을 접했다.

AI가 만든 결과를 제대로 이해하지 않은 채 다른 사람에게 전달하고 돌아온 피드백을 다시 AI에게 전달하는 사람을 뜻했다. 판단하는 주체가 아니라 AI와 현실 사이에서 입출력만 전달하는 프록시다.

그 표현을 보고 조금 뜨끔했다.

업무 내용을 AI에게 전달하고 만들어진 코드를 실행한다. 리뷰 의견이 달리면 다시 AI에게 전달하고 수정된 코드를 반영한다. 나는 명령어를 입력하고 승인 버튼을 누르지만 정작 왜 그런 코드가 만들어졌는지 충분히 설명하지 못하는 순간이 있었다.

그럴 때 나는 개발을 한 것일까. 아니면 AI가 실제 시스템에 접근할 수 있도록 키보드와 권한을 빌려준 것에 가까웠을까.

AI를 많이 사용한다는 것과 AI를 잘 사용한다는 것은 달랐다.

AI는 내가 보여준 코드와 설명 안에서 그럴듯한 답을 만든다. 오래된 코드가 왜 아직 남아 있는지, 운영자가 어떤 순서로 작업하는지, 실제 배포 환경이 무엇을 기준으로 실행되는지까지 저절로 알지는 못한다.

상반기에 내가 만든 몇 번의 문제도 이 경계를 놓쳤을 때 발생했다. 코드는 그럴듯했고 테스트도 일부 통과했지만 내가 시스템의 맥락과 영향 범위를 충분히 이해하지 못했다.

그렇다고 AI를 덜 쓸 생각은 없다. AI가 없었다면 지금의 속도로 낯선 언어와 시스템을 따라가기 어려웠을 것이다. AI 덕분에 이전보다 훨씬 넓은 범위의 일을 할 수 있게 되었다.

문제는 AI의 출력과 실제 업무 사이에서 내가 무엇을 더하느냐였다.

선택한 이유를 내 언어로 설명하고 놓친 것이 없는지 의심해야 한다. 직접 검증한 결과에 책임지는 것도 내 몫이다.

AI는 여러 선택지를 제안할 수 있지만 어떤 선택이 지금의 시스템에 맞는지 판단하는 것은 결국 사람의 몫이다.

그러려면 적어도 AI가 만든 코드를 읽고 왜 맞고 왜 틀렸는지를 판단할 수 있어야 한다. 지금 내게 시급한 것은 코드를 더 빠르게 만드는 능력보다, 만들어진 코드를 제대로 판단하는 능력이다.

역설적으로 AI를 많이 사용할수록 공부해야 할 것도 늘어났다.

예전에는 코드를 직접 작성하기 위해 공부했다. 지금은 눈앞에 놓인 코드가 정말 맞는지 판단하기 위해 공부한다. 언어와 프레임워크의 동작 방식, 데이터베이스의 트랜잭션, 메시지 큐의 실패 처리, 실제 배포 환경을 모르면 그럴듯한 코드와 올바른 코드를 구분할 수 없었다.

AI가 답을 빠르게 만들어주는 만큼, 나는 그 답을 의심할 수 있을 정도로 더 많이 알아야 했다.

이 판단 과정이 없다면 생산성은 높아져도, 나는 점점 더 효율적인 Meat Proxy가 될 뿐인지도 모른다.

일을 많이 했다는 것

기록을 다시 읽어보니 상반기에는 생각보다 많은 일을 했다.

작업 목록을 보고도 이상하게 뿌듯하지만은 않았다.

여러 일을 동시에 처리했고 이전보다 훨씬 빠르게 결과물을 만들었다. 그 대신 하나의 문제에 충분히 오래 머문 기억은 많지 않았다.

이전에 썼던 글에서 나는 스스로에게 이런 질문을 남겼다.

나는 지금 일을 더 잘하고 있는 걸까, 아니면 그냥 일을 더 많이 처리하고 있는 걸까.

아직도 답은 모르겠다.

상반기의 기록을 읽으며 한 가지는 알게 되었다. 내가 처리한 일의 개수보다, 문제를 바라볼 때 던지는 질문이 조금 달라졌다.

질문의 순서가 바뀌었다. “어떻게 구현하지?”보다 “이걸 바꾸면 어디까지 달라지지?”를 조금 더 자주 생각한다.

아주 큰 변화는 아닐지도 모른다. 여전히 놓치는 것이 많고 뒤늦게 발견한 영향 범위 때문에 다시 작업하는 일도 있다.

그래도 내가 무엇을 놓쳤는지는 예전보다 조금 더 구체적으로 설명할 수 있게 되었다.

하반기에는

더 많은 일을 처리하겠다는 계획은 세우지 않으려고 한다.

이미 많은 일을 빠르게 처리하는 방법은 알고 있다. 지금 필요한 것은 하나의 작업에 조금 더 오래 머무르는 일인지도 모른다.

구현하기 전에 상태와 정책부터 정리하고 싶다. 데이터가 어디에서 바뀌고 그 뒤에 어떤 작업이 실행되는지 확인한 다음, 내가 놓친 부분은 테스트와 배포 과정이 잡아내도록 만들고 싶다.

그리고 일을 끝낸 뒤에는 무엇을 했는지 기록해두고 싶다. 몇 달 뒤 다시 돌아봤을 때, 완료한 작업의 목록만 남는 것이 아니라 그 일을 하며 내가 무엇을 배웠는지도 기억할 수 있도록.

입사 3개월 회고의 마지막에는 1년 뒤의 내가 조금 덜 헤매고 있기를 바란다고 썼다.

반년이 지난 지금, 실제로 조금 덜 헤매고 있다.

대신 더 많은 것을 확인하고 더 많은 것을 걱정하게 되었다.

어쩌면 그것도 성장의 한 모습일 것이다.