콜봇 프로젝트 회고

기간 2025.09.15 ~ 2025.12.31

회사에서 9월 중순부터 연말까지, 약 3개월간 콜봇 프로젝트에 참여하게 되었다.

팀장님과 다른 동료분 한분까지 포함해 3명이서 프로젝트를 진행하도록 계획 되었으나,
두 분은 비상주로 필요할 때 지원만 받고 사실상 혼자 프로젝트를 진행하게 되었었다.

요구사항이 간단해서 혼자 충분히 할 수 있겠다 생각했지만..
역시 실제 투입되 보니 바빴으며, 생각보다 깨우친 부분도 많아 정리하고자 한다.

---

1. 중앙화

이번 프로젝트를 하면서 중앙화의 중요성을 다시 느끼게 되었다.

시나리오 자체는 서로 달랐지만, 실제로는 공통된 성격의 데이터를 다루는 경우가 적지 않았다.
예를 들어 청구서 재발행, 청구서 수령 방법 변경처럼 기능은 다르지만 비슷한 데이터를 사용하는 경우가 있었다.
그런데 이런 항목들이 시나리오별로 각각 다른 서비스 레이어에 흩어져 있어, 변경이 필요할 때마다 관련 코드를 하나씩 직접 확인해야 했다.

이후 이 부분을 도메인별 Enum으로 관리하도록 개선했다.
그 결과 어떤 시나리오에서 해당 값을 사용하는지 파악하기 쉬워졌고, 프로젝트 후반에는 변경 작업에 드는 시간도 많이 줄었다.
프로젝트를 진행할수록 공통 개념을 한곳에서 관리하는 구조의 차이가 더 크게 느껴졌다.

추가로 콜봇 시스템은 외부 API 호출을 통해 처리되는 경우가 많았고, 특정 외부 API는 거의 모든 시나리오에서 공통으로 사용되고 있었다.
이번 개발 과정에서는 특정 컬럼이 실제 어디에서 사용되는지 전수조사가 필요한 상황도 있었다.

그런데 기존 구조는 외부 API 응답을 DTO로 변환하지 않고 Map 형태로 전달하고 있었고,
각 서비스 레이어에서 어떤 곳은 Map 그대로 사용하고 어떤 곳은 다시 DTO로 변환해 사용하는 식으로 일관성이 없었다.

문제는 IDE가 get("column") 형태의 사용처까지는 명확하게 추적해주지 못한다는 점이었다.
그래서 특정 컬럼의 사용 여부를 확인하는 데 시간이 많이 들었고, 어디까지 확인했는지 관리하는 것도 쉽지 않았다.

이 경험을 통해 외부 API 조회 서비스에서 단순 호출만 담당하는 것이 아니라,
DTO 변환까지 함께 책임지도록 설계했으면 훨씬 관리하기 쉬웠겠다는 생각이 들었다.

사실 이전 프로젝트에서는 비슷한 방식으로 구조를 정리한 경험이 있었기 때문에,
이번에는 기존 구조의 단점이 더 크게 느껴졌던 것 같다.

시간 여유가 있었다면 이 부분도 개선했겠지만, 그러지 못한 점은 아쉬움으로 남는다.
앞으로 비슷한 구조를 잡게 된다면, 단순한 값 관리보다 공통 책임과 변환 규칙까지 함께 묶어 관리하는 쪽으로 가져갈 것 같다.

---

2. 사용하지 않는 코드는 지우자

이번 프로젝트에서는 예전에 작업하다가 반영이 취소되어 주석으로 남겨둔 코드나,
다른 화면에서 복사해왔지만 실제로는 사용하지 않는 함수들이 남아 있는 경우를 종종 볼 수 있었다.

개발 당시에는 나름의 이유가 있었을 것이다.
나중에 다시 사용할 수도 있고, 당장은 지우기 애매해서 주석으로 남겨두었을 수도 있다.
하지만 시간이 지나고 다시 코드를 보게 되면, 그런 흔적들은 대부분 도움이 되기보다 오히려 판단을 어렵게 만들었다.

주석으로 이유를 남겨두더라도 결국 시간이 지나면 맥락이 흐려지고,
지금 이 코드가 정말 필요한지 확신할 수 없어 쉽게 지우지 못하는 상태가 된다.
그렇게 되면 사용하지 않는 코드가 그대로 남아 코드베이스를 더 복잡하게 만든다.

이번 프로젝트에서는 형상 관리를 위해 Git을 사용하고 있었기 때문에,
굳이 이전 시도나 보류된 코드를 코드 내부에 남겨둘 필요는 없다고 느꼈다.
차라리 관련 내용을 커밋으로 남겨두고, 현재 시점에 필요 없는 코드는 과감하게 제거하는 편이 더 낫다고 생각했다.

실제로 남겨진 코드가 도움이 되는 경우보다, 다음 판단을 방해하는 경우가 더 많았다.
앞으로는 비슷한 상황이 생기더라도 주석으로 남겨두기보다, 지금 기준에서 필요 없는 코드는 정리하는 쪽으로 가져갈 것 같다.

---

3. Map을 쓴다면 정말 필요한지부터 따져보자

이번 프로젝트를 하면서 가장 힘들었던 부분 중 하나는 Map 사용이었다.

Map은 구조를 유연하게 가져갈 수 있다는 점에서는 분명 장점이 있다.
어떤 값이든 자유롭게 넣고 꺼낼 수 있고, 빠르게 연결해야 하는 상황에서는 편하게 느껴질 수도 있다.
하지만 실제로 프로젝트를 진행하면서는 그 장점보다 단점을 훨씬 더 크게 느꼈다.

우선 디버깅이 어려워졌다.
어떤 값이 어디에서 들어왔는지, 중간에 어떤 형태로 바뀌었는지 추적하기가 쉽지 않았다.
비즈니스 로직에서도 필요한 값을 put으로 하나씩 넣어야 하다 보니 코드가 불필요하게 길어지기도 했다.

더 힘들었던 부분은 코드 응집도가 쉽게 무너진다는 점이었다.
여러 사람을 거쳐 작성된 코드에서는 원래 사용하던 객체와는 전혀 다른 위치에서 갑자기 값을 추가하거나,
예상하지 못한 시점에 Map에 데이터를 넣는 경우도 있었다.
이런 구조는 흐름을 이해하기 어렵게 만들고, 수정 시점에도 부담을 크게 만든다.

처음에는 Map을 사용하면 자유도가 높아져서 변경에도 유연할 것처럼 보일 수 있다.
하지만 실제로는 값 하나가 바뀌거나 구조가 조금만 수정되어도 관련 로직을 함께 손봐야 하는 경우가 많았다.
결국 유연해 보였던 구조가 유지보수 측면에서는 오히려 더 불편하게 작동한 셈이다.

DTO로 명확하게 표현할 수 있는 구조라면, 가능하면 Map보다 DTO를 우선하는 편이 훨씬 관리하기 쉬웠다.
앞으로 비슷한 구조를 잡게 된다면, 편의성 때문에 Map을 먼저 선택하기보다 정말 필요한 경우인지부터 먼저 따져볼 것 같다.

---

4. AI가 알려준 답도 결국 검증이 필요하다

프로젝트 중 서버의 아파치 프로세스가 계속 증가하는 이슈가 있었다.
처음에는 GPT를 활용해 SSE 연결 문제일 가능성을 빠르게 좁혀 나갔고,
jmeter로 재현할 수 있는 형태까지 정리할 수 있었다.

이 과정 자체는 분명 도움이 되었지만,
동시에 AI가 제시한 답을 너무 빠르게 받아들이고 있었다는 점도 느끼게 되었다.

원래라면 먼저 확인했어야 할 운영 환경 설정이나
아파치 공식 문서를 기준으로 현재 설정이 실제로 가능한 구조인지 확인하는 과정이 있었어야 했는데,
그 부분보다 AI가 제시한 해결 방향을 먼저 따라가고 있었다.

실제로는 이미 시도했지만 효과가 없었던 방법을 다시 제안하는 경우도 있었고,
이걸 보면서 AI가 방향을 잡는 데는 도움을 줄 수 있어도
그 자체가 정답은 아니라는 점을 다시 느끼게 되었다.

결국 이 문제는 인프라팀 동료와 함께 http2 모듈을 제거하면서 해결했는데,
이번 일을 통해 AI가 준 답도
반드시 현재 환경과 공식 문서, 그리고 실제 로그를 기준으로 검증하면서 사용해야 한다는 점을 확실히 느끼게 되었다.

---

마치며

3개월이라는 길지 않은 기간이었지만,
이번 콜봇 프로젝트를 통해 여러 가지를 다시 느낄 수 있었다.

중앙화가 왜 중요한지
사용하지 않는 코드를 왜 남기면 안 되는지
Map을 왜 더 신중하게 써야 하는지
그리고 AI가 준 답도 왜 검증이 필요한지까지
실제 프로젝트를 진행하면서 더 명확하게 체감할 수 있었다.

당시에는 바쁘게 지나갔지만,
이렇게 정리해두면 이후 비슷한 상황을 마주했을 때
조금 더 나은 판단을 할 수 있을 것 같다.

이번 회고는 단순히 지나간 프로젝트를 정리하는 기록이라기보다,
앞으로 개발하면서 계속 가져가야 할 기준을 다시 적어두는 글로 남기고 싶다.