들어가며

2026년 상반기는 거의 회사에 적응하고 에디터를 배우는 시간이었다.

상반기 동안 머지된 PR은 203개였고 커밋은 669개였다. 이슈도 100건 정도 다뤘다. 숫자로 보면 꽤 많은 일을 한 것 같은데, 다시 보면 대부분은 그래픽 에디터라는 도메인을 조금씩 이해해가는 과정에 가까웠다.

미리디에 오기 전에는 SVG를 깊게 다뤄본 적이 없었다. 이미지를 그리는 형식 정도로만 생각했는데, 실제 에디터 안에서 SVG를 다루는 일은 훨씬 복잡했다. path, transform, viewBox, bounding box 같은 개념이 계속 나왔고, 각각이 화면에서 보이는 결과와 직접 이어졌다.

바운딩 박스도 처음 생각했던 것처럼 단순하지 않았다. 요소를 감싸는 사각형 정도로만 생각했는데, 회전한 요소의 바운딩 박스, 그룹 안에서의 바운딩 박스, 리사이즈 중에 계산해야 하는 바운딩 박스가 다 달랐다. 같은 요소를 보고 있어도 어느 기준에서 보느냐에 따라 값이 달라졌다. (이게 아직도 제일 어렵다)

처음에는 내가 뭘 모르는지도 잘 몰랐다. 그래서 하나를 이해하는 데 시간이 오래 걸렸고, 어떤 날은 꽤 답답했다. 그래도 상반기를 지나고 보니, 처음에는 전혀 감이 없던 개념들이 조금씩 연결되기 시작했다. 아직 익숙하다고 말하기는 어렵지만, 적어도 어디서 막히는지 정도는 알게 됐다.

이번 회고는 대단한 성과를 정리한다기보다는, 낯선 도메인에 적응하면서 무엇을 배웠고, 어떤 부분이 아쉬웠고, 하반기에는 어떤 방식으로 일해보고 싶은지를 적어보려고 한다.

모르는 걸 문서로 남겼다

상반기에 잘했다고 생각하는 것 중 하나는 문서를 꽤 많이 쓴 것이다.

담당 시스템을 이해하기 위해 가이드 문서를 8편 정도로 정리했다. 자료구조, 렌더링 파이프라인, 컨버팅 방식, 핵심 파일의 역할 같은 것들을 하나씩 썼다. 처음부터 누군가에게 설명하려고 쓴 것은 아니었다. 내가 이해하려고 쓴 기록에 가까웠다.

에디터 도메인은 코드만 읽는다고 바로 이해되지 않았다. 어떤 값이 왜 그렇게 계산되는지 알려면, 화면에서 요소가 어떻게 보이고 내부 모델에서는 어떤 좌표를 들고 있고 렌더링 단계에서는 어떤 보정이 들어가는지를 같이 봐야 했다. 적어두지 않으면 금방 헷갈렸다.

그렇게 쓴 문서가 나중에는 나만 보는 문서가 아니게 됐다. 새로 합류한 동료가 볼 수도 있고, 시간이 지난 뒤의 내가 다시 볼 수도 있고, AI 에이전트에게 맥락을 설명할 때도 쓸 수 있었다.

예전에는 문서를 정리해두면 좋은 것 정도로 생각했다. 지금은 조금 다르게 생각한다. 낯선 도메인을 배울 때 문서는 결과물이라기보다 배우는 방법에 더 가깝다. 내가 뭘 알고 있고, 뭘 아직 헷갈려 하는지 쓰면서 더 잘 보였다.

성능을 근거로 말하는 연습을 했다

성능을 볼 때 이전에는 개발자 도구나 간단한 로그로 대략적인 병목을 확인하는 정도에 가까웠다. 문제를 찾는 데는 충분할 때도 있었지만, 두 구현 방식을 비교하고 "이쪽이 더 낫다"고 말하기에는 부족했다. 같은 입력인지, 같은 환경인지, 어떤 작업을 기준으로 비교하는지에 따라 결과가 쉽게 달라질 수 있기 때문이다.

이번에 렌더링 성능을 비교하면서 그 부분을 조금 더 의식하게 됐다. 단순히 한 번 실행해보고 빠르다 느리다를 말하는 대신, 비교할 조건을 맞추고 여러 번 측정하면서 결과를 정리했다. 브라우저 개발자 도구에서 보는 지표도 그냥 숫자로만 보지 않고, 실제 사용자 동작과 어떻게 이어지는지 같이 보려고 했다.

1차로 정리한 뒤에는 피드백을 받았다. 다시 보니 내가 충분히 통제하지 못한 조건이 있었고, 비교 기준도 더 분명하게 잡을 수 있었다. 그래서 측정 방식을 고쳐 2차로 다시 확인했다. 결과 자체도 중요했지만, 나에게 더 남은 것은 성능을 이야기할 때 어떤 근거를 같이 가져가야 하는지 배운 점이었다.

이 경험 이후로 "성능이 좋아졌다"는 말을 조금 더 조심하게 됐다. 숫자가 있어야 하고, 그 숫자가 나온 조건도 같이 설명할 수 있어야 했다. 감으로 느낀 차이를 근거 있는 이야기로 바꾸는 연습을 한 셈이었다.

시키지 않은 일도 조금 했다

업무를 하다 보면 당장 맡은 구현은 아니지만 계속 신경 쓰이는 문제가 있다. 상반기에는 그런 문제를 몇 번 그냥 넘기지 않으려고 했다.

요소 컨버팅 프로세스가 특정 개인의 판단과 기억에 많이 기대어 굴러가고 있다는 것을 보고, 문제를 문서로 정리해서 이야기할 수 있게 만들었다. 당장 기능을 하나 만드는 일은 아니었지만, 계속 그대로 두면 언젠가 병목이 되거나 실수로 이어질 수 있는 구조라고 생각했다.

이런 일을 하면서 조금 배운 것도 있다. 문제를 발견하는 것과 문제를 해결 가능한 형태로 만드는 것은 다르다는 점이다. 그냥 불편하다고 말하면 불만에 가까워지지만, 어떤 상황에서 문제가 생기고, 왜 반복될 수 있고, 어떤 방식으로 줄일 수 있을지 정리하면 논의할 수 있는 주제가 된다.

다만 이 부분은 아쉬움도 있다. 문제를 꺼내는 것과 끝까지 닫는 것은 다른 일이었다. 문서로 문제를 제기하는 것까지는 했지만, 후속 실행이 반기 안에 명확하게 끝나지 않은 것들도 있었다. 하반기에는 문제를 제기할 때 다음 액션과 기한까지 같이 남겨두려고 한다.

AI에 의존하는 만큼 더 잘 이해하고 싶었다

상반기에는 AI의 도움을 많이 받았다. 처음 보는 코드의 흐름을 파악할 때도, 복잡한 변경을 정리할 때도, 테스트나 검증 방법을 생각할 때도 AI를 자주 썼다. 혼자 했으면 더 오래 걸렸을 일들을 훨씬 빠르게 진행할 수 있었고, 실제로 도움을 많이 받았다.

그런데 동시에 고민도 생겼다. AI가 코드를 그럴듯하게 설명해주고 수정안까지 만들어주면, 내가 충분히 이해하지 못한 상태에서도 일이 앞으로 가는 것처럼 느껴질 때가 있었다. 당장은 빠른데, 이게 정말 내 실력이 되고 있는 걸까 하는 생각이 들었다.

특히 에디터 도메인에서는 더 조심해야 했다. SVG, 좌표계, 스케일, 바운딩 박스처럼 작은 차이가 화면의 결과를 크게 바꾸는 영역이 많았다. AI가 제안한 코드가 그럴듯해 보여도, 어떤 기준 좌표를 쓰는지, 어떤 데이터 조합에서 깨질 수 있는지, 기존 규약과 맞는지 내가 직접 확인하지 않으면 불안했다.

그래서 요즘은 AI를 그냥 정답을 주는 도구로 쓰기보다, 내 이해를 확인하는 도구로 쓰려고 한다. 먼저 내가 이해한 흐름을 적고, AI에게 이 설명에서 빠진 조건이나 틀린 가정이 있는지 물어본다. 수정안을 받을 때도 바로 붙이기보다, 왜 이 방식이 맞는지, 어떤 케이스에서 깨질 수 있는지, 추가로 봐야 할 엣지 케이스가 무엇인지 같이 묻는다.

이 과정에서 암묵지를 줄이는 것에 대해서도 많이 생각하게 됐다. 에디터에는 "이건 원래 이렇게 봐야 한다", "이 값은 여기서는 이런 의미다", "이 케이스에서는 이 로직을 건드리면 안 된다" 같은 지식이 많았다. 사람끼리는 몇 번 같이 일하다 보면 자연스럽게 익히는 것들이지만, 문서로 남아 있지 않으면 새로 보는 사람도, AI도 제대로 알기 어렵다.

그래서 문서를 쓰는 의미도 조금 달라졌다. 예전에는 사람에게 공유하기 위한 문서를 쓴다고 생각했다면, 지금은 AI가 읽을 수 있는 컨텍스트를 쌓는 일이기도 하다고 느낀다. 파트 안에서 반복해서 설명하던 규칙이나 자주 헷갈리는 흐름을 문서로 남겨두면, 동료가 같은 내용을 다시 물어보지 않아도 되고, AI에게도 더 정확한 전제를 줄 수 있다.

중요한 것은 그냥 길게 적는 것이 아니라, 다시 읽히기 좋은 형태로 남기는 것이라고 생각한다. 어떤 값이 어디서 만들어지고 어디에서 변환되는지, 어떤 케이스를 조심해야 하는지, 이 모듈을 수정할 때 어떤 테스트를 봐야 하는지처럼 실제로 판단에 필요한 내용을 남기려고 한다. 그래야 사람도 읽기 쉽고, AI에게 붙여 넣었을 때도 덜 엉뚱한 답을 한다.

엣지 케이스를 찾는 방식도 조금씩 바꿔보고 있다. 단순히 "테스트를 더 만들어줘"라고 하기보다, 이 기능이 깨질 수 있는 조건을 좌표계, 스케일, 회전, 그룹, undo 같은 관점으로 나눠서 물어본다. 그러면 내가 미처 생각하지 못한 조합이 나오기도 하고, 반대로 AI가 너무 일반적인 이야기를 할 때는 내가 도메인 지식을 더 채워 넣어야 한다는 것도 보인다.

결국 AI를 잘 쓰는 것은 더 빨리 코드를 받는 일이 아니라, 더 빨리 좋은 질문을 만드는 일에 가까운 것 같다. 내가 모르는 것을 숨긴 채로 맡기면 결과도 불안해지고, 내가 무엇을 확인하고 싶은지 분명하게 말하면 훨씬 쓸모 있는 답을 받을 수 있었다.

하반기에는 AI를 쓰는 방식을 조금 더 의식적으로 가져가보려고 한다. 수정안을 받기 전에 먼저 내 이해를 적어보기, 변경 뒤에는 깨질 수 있는 조건을 물어보기, 중요한 변경은 AI가 만든 답을 다시 테스트와 문서로 남기기. 그리고 파트 안에 흩어져 있는 암묵지도 조금씩 문서로 바꿔두고 싶다. 사람에게도, AI에게도 같은 맥락을 전달할 수 있는 상태를 만드는 것이 목표다.

일을 잘한다는 게 뭘까 자주 생각했다

상반기에는 일을 잘한다는 게 뭘까 자주 생각했다.

예전에는 일을 잘한다는 것을 주어진 일을 빠르게 끝내고, 문제가 생기면 잘 고치고, 리뷰에서 큰 지적 없이 머지하는 것에 가깝게 생각했던 것 같다. 물론 이것도 중요하다. 하지만 에디터 일을 하면서 그것만으로는 부족하다는 생각이 들었다.

어떤 문제는 빨리 고치는 것보다 제대로 이해하는 것이 더 중요했다. 어떤 문제는 코드를 잘 짜는 것보다, 이 변경이 어떤 데이터에서 깨질 수 있는지 먼저 묻는 것이 더 중요했다. 어떤 문제는 혼자 오래 붙잡는 것보다, 지금 내가 어디까지 봤고 어디가 애매한지 빨리 공유하는 것이 더 나았다.

그런 경험을 하면서 일을 잘하는 사람은 단순히 구현을 빨리 하는 사람이 아니라는 생각이 들었다. 모르는 것을 모른다고 말할 수 있고, 애매한 것을 애매한 상태로 오래 두지 않고, 필요한 사람에게 필요한 시점에 공유할 수 있는 사람에 더 가까운 것 같다.

특히 지금의 나에게 필요한 것은 판단을 더 빨리 드러내는 일이다. 내가 이렇게 이해했는데 맞는지, 이 방향으로 가도 되는지, 이 부분은 위험해 보이는데 더 봐야 하는지 같은 것들을 혼자 오래 들고 있지 않는 것. 그래야 틀렸을 때 더 빨리 고칠 수 있고, 맞았을 때도 더 빠르게 앞으로 갈 수 있다.

상반기에는 이걸 머리로는 알면서도 잘 못 했다. 조금 더 보고 말해야 할 것 같고, 더 정리된 뒤에 공유해야 할 것 같았다. 그런데 돌이켜보면 완전히 정리된 뒤에 공유하는 것보다, 덜 정리됐더라도 지금의 생각을 보여주는 편이 더 나았던 순간들이 있었다.

더 빨리 보여주고 싶다

상반기에 또 많이 느낀 것은, 내가 생각보다 결과물을 늦게 보여주는 편이라는 점이다.

얼마 전에도 혼자 그런 생각을 했다. 잠깐 생각하고 일단 해보고, 피드백을 받아서 고치는 사람이 되고 싶다고. 그런데 실제 업무에서는 그게 쉽지 않았다. 내 결과물에 비판적인 평가를 받는 것이 생각보다 부담스러웠다. 틀릴까 봐 분석에 시간을 더 쓰고, 어느 정도 모양이 나온 다음에야 공유하려는 쪽으로 자꾸 기울었다.

하지만 처음 접하는 도메인일수록 혼자 오래 붙잡고 있는 게 꼭 좋은 방법은 아니었다. 내가 놓친 규약을 이미 알고 있는 사람이 있고, 내가 복잡하게 생각한 부분을 더 단순하게 볼 수 있는 사람이 있었다. 일찍 보여주면 그만큼 일찍 틀릴 수 있는데, 그걸 알면서도 잘 못 했다.

하반기에는 공유 시점을 조금 더 앞당기려고 한다. 분석이 하루를 넘기기 전에 한 번, 구현이 절반쯤 진행됐을 때 한 번은 공유해보고 싶다. 완성한 뒤 평가받는 것이 아니라, 방향이 맞는지 중간에 확인받는 방식으로 바꿔보고 싶다.

비판적인 피드백이 편해지는 날이 쉽게 오지는 않을 것 같다. 그래도 편해지기를 기다리기보다, 자주 받아서 조금씩 익숙해지는 쪽이 낫다고 생각한다.

하반기를 생각하며

상반기는 많이 헤맨 시간이었다. 처음 해보는 에디터 일이었고, SVG와 바운딩 박스와 좌표계 앞에서 자주 막혔다. 무엇보다 AI의 도움을 많이 받으면서도, 내가 정말 이해하고 있는지 계속 확인해야 하는 시간이었다.

그래도 남은 것은 있다. 이제는 어떤 문제를 만났을 때 무작정 코드부터 고치기보다, 값이 어디서 시작해서 어디로 가는지 먼저 봐야 한다는 것을 안다. 성능을 이야기하려면 숫자뿐 아니라 측정 조건도 같이 말해야 한다는 것도 배웠다. 문서는 다 알고 난 뒤에 쓰는 것이 아니라, 알아가기 위해 쓰는 것이라는 생각도 하게 됐다.

그리고 일을 잘한다는 것에 대한 생각도 조금 바뀌었다. 빨리 구현하는 것도 중요하지만, 지금 내가 무엇을 알고 무엇을 모르는지 드러내는 것도 중요했다. 혼자 오래 들고 있는 시간이 길어질수록 문제가 작아지는 것이 아니라, 오히려 늦게 발견될 때도 있었다.

하반기에는 더 대단한 사람이 되겠다고 쓰기보다, 조금 더 덜 헤매는 방식을 만들고 싶다. 헷갈리는 흐름은 문서로 남기고, 위험한 변경은 검증을 넓히고, 혼자 오래 붙잡기보다 조금 더 빨리 공유해보려고 한다.

AI도 그런 방식으로 써보고 싶다. 모든 것을 대신해주는 도구라기보다는, 내가 이해했는지 확인하고 엣지 케이스를 같이 찾는 도구로 만들고 싶다. 재현을 만들고, 테스트를 넓히고, 문서가 코드 변경을 따라왔는지 확인하는 일을 조금씩 맡겨보려고 한다.

상반기에는 많이 몰라서 오래 걸렸다. 하반기에는 그때 배운 것들을 내 머릿속에만 두지 않고, 문서와 테스트와 일하는 방식 안에 조금씩 옮겨두고 싶다. 그 정도만 해도 지금보다 조금은 덜 헤매면서 일할 수 있을 것 같다.