[코드 리디자인 일지] Ep.3: 어제 배포한 내 코드 뜯어보기 - '운빨'요소 제거🧽🫧

🧩 배경

배포 다음 날이라 간만에 찾아온 평화로운 시간~ 커피 한 잔 마시며 어제 배포한 코드를 다시 훑어봤다.

분명 기능은 잘 돌아가고 있었지만 어딘가 모르게 마음 한구석이 간지러웠다.

"지금은 문제없지만, 데이터 구조가 조금이라도 바뀌면 바로 터지는 거 아냐?" 하는 불안함도 있고 뭔가 더 좋은 구현방법이 있을 것 같고(100%)

마침 시간도 좀 남겠다

이 찜찜함을 '근거 있는 코드'로 바꿔보기로 했다.

 

💭 고민의 내용

가장 문제는 인덱스(i)에 의존하는 루프였다.

LLM에 프롬프트를 던지고 응답을 받아올 때, 나는 당연히 보낸 순서대로 돌아올 거라 믿고 tmp_list[i] 같은 식으로 데이터를 매핑했다.

그런데 문득 겁이 났다.

"만약 네트워크가 튀어서 순서가 뒤바뀌면? 중간에 하나가 누락되면?"

내 코드는 엉뚱한 사람에게 엉뚱한 답변을 매핑하거나, 아예 터져버릴 게 뻔했다(절대 안 됨..)

게다가 modelId라는 변수 하나가 엔진 이름(GPT-4 등)도 됐다가

프롬프트 종류(기본 설정 등)도 됐다가 하며 자기 정체성을 잃고 방황하고 있었다.

코드를 읽는데 자꾸 '어? 이게 여기서 왜 나와?' 싶은 제동이 걸렸다.

내 건데 잘 안 읽히는 느낌? 최악이야ㅠㅠ

 

 

🛠️ 해결을 위한 시도들

이거보다 더 견고한(Robust) 방식이 분명 있을 거다!

AI에게  "이거 왜 위험해?", "더 안전하게 바꾸려면 어떻게 해야 해?"라고 계속 질문을 던졌다.

 

처음엔 막막했다. LLM 응답값에는 고유 키가 없는데, 어떻게 순서가 아닌 ID로 매칭을 시키지?라는 생각에 갇혀 있었다.

하지만 머리를 맞대고 고민하다 보니 답은 의외로 가까운 곳에 있었다.

메시지 리스트(비동기 프롬프트 리스트)를 구성할 때 이미 우리는 ID 정보를 가지고 있잖아?!!?!😲

결국 인덱스로 데이터 뒤를 쫓는 대신 프롬프트 리스트를 만들 때부터 아이디값 확실히 주고 그걸 기반으로 딕셔너리 매핑을 하도록 구조를 바꿨다.

비어있는 결과에 대해서도 "에라 모르겠다" 하고 넘기는 게 아니라

확실하게 실패 처리를 해서 예외가 전파되지 않도록 로직을 짰다.

 

📈 변화

 

1. 데이터 매핑의 안정성: 이제 응답 순서가 뒤죽박죽으로 와도 상관없다. 자기 주소(ID)를 찾아가게 만들었으니까!
2. 예외 처리의 디테일: 전에는 하나가 비어있으면 전체가 죽을까 봐 걱정됐는데 이제는 비어있는 놈만 골라내서 '실패'라고 명시하고 나머지는 살릴 수 있게 되었다.
3. 가독성: modelId가 프롬프트 선택까지 도맡던 억지스러운 역할을 떼어냈다. 값이 없으면 default를 보게 하는 Fallback 로직을 넣으니 흐름이 훨씬 자연스러워졌다. 보기도 편하고 ㅎㅎ

 

 

📌 회고 & 다음 목표

"작동하는 코드"와 "근거 있는 코드"는 완전히 다르다는 걸 다시 한번 느낀 오늘이다.

전자는 운에 맡기는 거고, 후자는 내가 통제하는 거다.

이번에 딕셔너리 매핑으로 바꾸면서 느낀 카타르시스는 단순히 버그를 잡았을 때보다 컸다.

내 설계에 '이유'가 생겼기 때문이다.

오늘 이 사소한 리팩토링 덕분에 내가 짠 코드에 대해 100% 설명할 수 있는 근거를 얻었다(너무 고마운 하루다)

난 단순히 기능을 만드는 개발자가 아니라 유지보수하기 편하고 견고한 설계를 고민하는 개발자가 되고 싶다.

다음에는 이번에 정비한 매핑 구조를 바탕으로 API 응답까지 더 깔끔하게 말아주는 표준 구조를 고민해 봐야겠다