초점을 맞추는 일

안녕하세요! Pit 팀에서 개발 인턴으로 일하고 있는 김나현입니다.
첫 기록은 개발 온보딩 이야기로 시작해 보려고 해요.

#00 남겨둔 질문 하나

온보딩 첫 과제는 서비스의 도메인 구조를 파악하는 리포트였습니다.
나름대로 리포트를 다 쓰고 나서 마지막에 이런 질문을 슬쩍 적어 두었어요.

도메인의 모든 기능을 다이어그램으로 만들어야 하는 건가? 세부 사항은 어디까지 표기해야 하는 거지?

그때는 별생각 없이 던진 질문이었는데요. 인증, 결제, 진단 도메인을 차례로 읽는 내내 저를 가장 오래 따라다닌 게 바로 이 질문이었습니다.
이제부터는 제가 "어디까지 그릴 것인가"에 답해보려 한 과정을 기록해보겠습니다.

#01 화면으로 그린 첫 지도

처음 기준은 화면이었습니다.
서비스를 직접 이리저리 눌러 보고, 코드베이스 폴더 구조와 맞춰 보면서 도메인을 나눴어요.
인증, 사용자, 진단, 자기인식, 워크스페이스, 결제, 파트너, 관리자, 쿠폰, 포인트. 세어 보니 10개였습니다.

도메인마다의 '경계' 칸에는 이 도메인이 무엇을 하지 않는지, 옆 도메인과 어디서 갈리는지 적어보았어요.
예를 들어 비밀번호 변경은 계정 정보를 바꾸는 일이지만, 저는 사용자가 아니라 인증 쪽에 넣었습니다.
(거기 아니야…돌아와!!)

서비스를 열심히 둘러보며 도메인을 파악해 보았습니다.
하지만 이건 사용자 눈에 보이는 서비스의 지도였습니다. 코드의 지도는 아직 없었죠.
그 지도를 그리는 게 다음 과제였습니다.

#02 AI야 잠시만 이별하자..

다음은 도메인별 코드 리뷰였습니다.
시퀀스 다이어그램으로 흐름을 그리고, 플로우차트로 책임을 정리하고, 마지막에 의도 정합성과 구조 무결성, 두 축으로 코드를 판단하는 틀이 주어졌어요. 이 과정에서 처음에는 AI 사용을 줄이고, 코드를 직접 하나하나 보며 만들어야 한다는 조건이 붙었어요.

직접 코드를 열어 보니 제 지도와 다른 곳이 하나둘 보이기 시작했어요.
인증에서 처리될 줄 알았던 기능들이 사용자, 메일 쪽에서 처리되고 있었거든요.
화면에서는 한 덩어리였던 인증이 코드에서는 세 서비스에 나눠 살고 있었던 거죠.

경계를 보는 기준이 화면에서 코드의 호출 관계로 넘어간 순간이었습니다.

다만, 첫 리뷰 자체는 엉망이었어요.
(분명 읽은 코드인데도 기억이 나지 않고 못 보고 지나친 부분이 알고 보니 중요한 부분이고…)

#03 넘겨 읽은 곳에서 분기가 빠진다

코드를 보기 전 앞의 리뷰에서 발생한 문제를 생각해 보았어요.

“빈 부분이 많아서 리뷰가 허술해져.”
→ “코드를 조금 더 세세히 봐야 할까?”
→ “읽은 부분에서의 빈 부분은 왜 생기는 걸까?”
→ “읽었던 부분이라도 막상 리뷰할 때 보면 잘 모르겠어.”

계속해서 고민하는 동시에 컴퓨터 화면에는 하염없이 코드를 띄워두었어요. 그러던 순간

“…내가 저걸 읽었던가?”

메서드 안에서 돌아가는 로직에 집중하는 사이에 무심코 넘겨버린 밖의 코드들이 보였습니다.
사실 지금 와서 생각해보면 당연한 부분이었어요.
코드는 단순히 하나의 로직을 딱 실행한다고 돌아가는 게 아닌데 이를 매번 대신 읽어주던 AI 없이 제가 직접 읽다보니 생긴 일이었죠.

그래서 요청이 DTO, Controller, Service, Entity를 거쳐 DB까지 가는 기본 구조부터 다시 잡았습니다.
그다음엔 엔드포인트마다 읽은 흐름을 처음부터 끝까지 문장으로 썼어요. AI에게는 대신 읽어 달라고 하지 않고, 제가 쓴 문장이 코드와 맞는지 확인받았습니다. 결제 생성 요청 하나의 흐름 노트가 화살표 수십 개짜리 문단이 되었어요.
(쓰는 저도 숨이 차는 분량이었습니다.)

코드만으로 안 풀리는 곳은 다른 데서 단서를 찾았어요.
어떤 조회 조건이 왜 동작하는지는 실제 데이터 값을 보고서야 이해했고, 백엔드 어디에도 없던 환불 흐름은 프론트엔드를 따라가 보니 상담 채널로 연결되어 있었습니다.

그렇게 분기를 하나도 빠짐없이 담은 다이어그램이 완성되었고 이번에야말로 제대로 된 리뷰를 할 수 있겠다는 생각이었는데…

#04 코드가 넘쳐흐른다

중간 점검차 제 작업물을 보시던 사수분이 말해주셨습니다.

내용이 너무 많고 다이어그램 작성법에 안 맞는 부분들이 있어요.

‘아차!’ 싶었습니다.
빠짐없이 읽는 것과 빠짐없이 그리는 것은 다른 일이었어요.
읽을 때는 꼼꼼히 읽는 것이 맞지만, 그릴 때는 보는 사람이 흐름을 따라올 수 있도록 정리해야 했습니다.

저는 또다시 열심히 작업물을 수정하기 시작했습니다.
나름대로의 중요도와 흐름을 고려하며 제 작업물이 다른 사람들에게도 잘 보이게끔 초점을 맞춰갔어요.(제 강점인 유연이 아주 열일해주었습니다.)

이런 과정 끝에 무사히 리뷰를 마치고 다음 단계로 넘어갔습니다.

#05 '최대한'이 뭘까

다음 단계는 진단 도메인을 대상으로 AI를 최대한 활용한 결과물을 가져오는 것이었습니다.

그런데 이 '최대한'은 어디까지일까요?

이 단어 하나를 붙잡고 한참 고민했어요.
직접 읽을 땐 제 눈만 믿으면 됐지만, 이제는 AI를 활용해서 제가 직접 만들었던 결과물 그 이상을 만들어야 했습니다.
그리고 제 이전까지 AI 활용법은 “해줘”였습니다...

우선 열심히 AI에게 기준을 만들어 주었습니다.
이전 리뷰 때 쓰던 지침과 실제로 만든 자료를 예시로 주고, 흐름 노트 형식, 시퀀스 규칙, 플로우차트 레이아웃처럼 반복되는 규칙은 스킬 파일로 만들었어요. 산출물을 보고 고친 내용은 다시 스킬에 반영했고요. 손으로 찾은 기준을 매번 입 아프게 설명하는 대신 파일에 적어 두었습니다.

다음은 검증이었습니다.
처음엔 AI 두 개에게 수정과 검토를 모두 맡기고, 서로 결과를 주고받다가 두 번 연속 통과하면 받는 방식을 썼어요.
머릿속에서 상상할 때는 그럴듯해 보였는데, 차례로 고치고 검토하다 보니 결국 각자 자기 숙제를 자기가 채점하는 꼴이 됐습니다.
검토가 제대로 될 리가 없었죠.

그래서 역할을 확실히 나눴습니다.
한쪽은 만들기만, 다른 쪽은 검토만. 근거는 코드 라인으로만 삼게 했어요.
AI 검토를 통과해도 끝이 아니었습니다. 마지막엔 제가 실물과 내용을 직접 보고 나서야 확정했어요.
AI 통과는 필요조건일 뿐이니까요.

그런데 끝까지 넘기지 못한 게 하나 있었어요.
흐름 파악과 다이어그램 제작은 둘 다 시간이 오래 걸리는 작업이라서, 세션을 나눠 동시에 돌리고 싶었거든요.
문제는 그렇게 나누면 흐름을 읽은 쪽이 내린 "이 다이어그램엔 여기까지"라는 판단이 그리는 쪽으로 넘어가지 않을 것 같다는 거였습니다.
판단이 끊기면 또 과하거나 비는 다이어그램이 나올 테고요.
결국 두 작업을 한 세션에 두고 속도를 양보했습니다.

형식은 규칙에 맡길 수 있었지만, 무엇을 담을지는 여전히 제가 판단해야 했어요.
첫 리포트에 적어 둔 그 질문은, AI를 아무리 많이 써도 결국 제가 답해야 하는 질문이었습니다.

#에필로그

“초점을 맞추는 일”이란 제목은 이 글을 다 쓰고 나서야 정할 수 있었어요.
너무 가까이서 보면 넘쳐흐르고, 또 멀리 가면 비어 버리는 게 꼭 초점을 맞추는 작업과 닮아보였거든요.

아직도 초점을 한 번에 딱 맞추지는 못하지만, 적어도 초점이 어긋난 걸 알아차릴 수는 있게 된 것 같아요.
어긋난 걸 안다는 건 다시 맞춰볼 기회를 잡을 수 있다는 것이겠죠?
이 마인드로 앞으로의 작업도 열심히 헤쳐 나가 보겠습니다!