네이버 부스트캠프를 마무리하며

부스트캠프에서의 8개월 여정이 끝났다. 팀원들과 최종 발표를 마치고 헤어지면서, 이제 정말 마지막이라는 생각이 들었다. 그간의 여정을 되돌아보며 정리해보고자 한다.

수료까지의 여정

2024년 6월 24일, 베이직 과정을 시작으로 12월 6일 최종 발표까지 총 여섯 달간 부스트캠프를 수료했다. 각 과정의 기간과 명칭은 다음과 같다.

1. 베이직 (2주) [24.06.24~24.07.05]
   • 베이직 회고
2. 챌린지 (4주) [24.07.15~24.08.09]
   • 챌린지 회고
3. 멤버십 학습 스프린트 (8주) [24.08.19~24.10.18]
   • 학습 스프린트 회고
4. 멤버십 그룹 프로젝트 (6주) [24.10.28~24.12.06]
   • 그룹 프로젝트 회고

긴 여정이었지만, 12월 6일 수료식에서도 뭔가 끝났다는 실감이 들지는 않았다. 어차피 한 달 뒤, 우리는 다시 리팩토링을 위해 모일 예정이었기 때문이다. 😂

수료 후의 리팩토링

리팩토링 과정은 두 번에 걸쳐 진행되었다. 그룹 프로젝트에서 진행된 프로젝트를 리팩토링 하는 과정이었다.

1. CS 리팩토링(3주) [25.01.06~25.01.24]
2. 인공지능 리팩토링 (3주) [25.02.03~25.02.21]

수료 후의 리팩토링 과정은 선택 사항이었으나, 나는 우리 팀과 함께 참여하기로 결정했다.

6주라는 짧은 개발 기간으로 타협했던 부분들을 개선하고, 인공지능 기능까지 추가하며 한 단계 더 성장할 수 있는 기회가 바로 이 리팩토링 과정이라 생각했다. 그래서 망설임 없이 리팩토링을 신청했다!

그룹 프로젝트에서 진행한 Ask-It 서비스를 리팩토링하게 되었다. Ask-It은 실시간 Q&A 서비스로, 질문 답변 채팅이라는 핵심 기능을 가지고 있다. 프로젝트에 대한 자세한 내용은 아래 링크에서 확인할 수 있다.

Ask-It-Refactor

• GitHub
• 메인 페이지
• 방명록 페이지 (핵심 기능 체험 가능)

CS 리팩토링 (3주)

CS 리팩토링은 6주라는 짧은 시간동안 완성해낸 우리 서비스에서 아쉬운 점들을 찾아 해결하고 고도화하는 시간이었다. CS 지식을 기반으로 숙원사업을 해결하는 느낌이었다고 할까.

도전 거리들

가장 처음 도전한 것은 확장성이 부족한 권한 관리 코드의 개선이었다. 기존에는 단순히 flag를 통해 사용자의 권한을 확인하는 방식이었는데, 이는 나중에 권한 구조가 변경될 때마다 코드를 수정해야 하는 문제가 있었다. MySQL의 Role 시스템에서 영감을 받아 RBAC(Role-Based Access Control)를 도입했고, 권한 관리를 DB 레벨에서 처리하도록 개선했다. (RBAC 도입을 통한 권한 관리 로직 개선기)

이 과정에서 4인 페어 프로그래밍을 진행했는데, 드라이버를 맡았을 때 팀원들의 의견을 한 번에 제대로 이해하지 못하는 경험을 했었다. 이 부분이 조금 아쉬웠지만, 그래도 포기하지 않고 계속 페어 프로그래밍을 진행하다보니 이것에 대한 훈련이 되어 갔던 것 같다. 이 경험은 나중에 면접에서 라이브 코딩 테스트를 볼 때에도 큰 도움이 되었다. 이때 생긴 '맷집' 덕분인지, 면접관님들의 힌트를 한 번에 알아듣지는 못하더라도 차분히 이해하려 노력하는 태도를 가질 수 있었다.

테이블을 수정하다가 운영 DB를 날려먹는 실수도 있었다. 당시에는 당황스러웠지만, 이를 계기로 DB Role 설정과 백업의 중요성을 뼈저리게 깨달았고, 평소에 익숙하게 사용하던 'prisma migrate dev' 같은 명령어의 정확한 동작 방식도 다시 공부하게 되었다. (DB 날려먹은 사람의 외양간 고치기)

부하테스트도 인상적인 경험이었다. Artillery를 활용해 다양한 시나리오를 만들어 서버의 한계를 테스트했는데, 처음에는 목표 설정이 불명확해 어려움을 겪었다. 무작정 부하를 주어 서버를 죽여보다가 "이걸 지금 왜 하고 있지?"라는 의문이 들었던 때도 있었다. 명확한 목표 하에서 시나리오를 만드는 것에 어려움을 겪었던 셈이다. 하지만 이런 시행착오를 통해 문제 정의의 중요성을 깨달았고, 구체적인 목표를 세우고 그에 맞는 해결책을 찾아가는 과정의 가치를 배웠다.

이런 경험들을 하나하나 release로 꾸준히 정리해보는 경험도 해봤다!

• ask-it-refactor release

느낀 점

개인적으로 부캠의 모든 과정을 통틀어 이 시간이 가장 난이도 높은 시간이었다고 생각한다. 스스로 기술적인 문제를 정의해야 했기 때문이다. 지금껏 스프린트 과정까진 문제를 부캠에서 제시해주었고, 그룹 프로젝트에선 기획을 토대로 기능을 개발하는 것이 우리들이 정의한 문제였다. 하지만 CS 리팩토링에서는 새로운 기능을 추가하는 것이 아닌, 우리가 직접 서비스의 기술적 문제를 정의하고 개선해야 했다.

이는 생각보다 훨씬 어려운 일이었다. RBAC 도입, DB 재설계, 부하 테스트 등 다양한 기술적 도전을 하면서 깨달은 것은, 단순히 기술을 적용하는 것보다 어떤 문제를 해결하고자 하는지 정의하는 것이 더 어렵다는 점이었다. 이 과정에서 많은 시행착오도 겪었지만, 그 속에서 문제를 정의하는 힘을 기를 수 있었다. 기술적 역량만큼이나 문제를 바라보는 시각과 정의하는 능력이 중요하다는 것을 배운 시간이었다.

인공지능 리팩토링 (3주)

마지막 3주는 인공지능 리팩토링이 진행되었다. NCP 크레딧으로 클로바 스튜디오 서비스를 활용해 우리 서비스를 개선하는 시간이었다. 가장 막막하게 느껴졌던 과정이기도 했다. 어떤 인공지능 기능을 넣을지부터 고민이었고, 단순 API 연동이 과연 서비스에 어떤 도움이 될까 회의적이기도 했다.

하지만 예상과 달리 훨씬 재밌고 유익한 시간이었다. 일단은 기능을 추가한다는 게 참 재밌었다. 아무래도 CS 리팩토링 동안 기능을 추가하지 않고 기술적 도전을 해오다가, 이젠 기능을 추가함으로써 눈에 보리는 성과까지 나오다보니 더 즐겁게 느껴졌던 것 같다.

기획 과정에서의 갈등

기획 과정에서는 팀 내 의견 충돌도 있었다. 대방인 팀이 그간 경험하지 못했던 가장 팽팽한 의견 대립이었는데, Q&A 요약본 제공(내 의견), 질문 작성 보조, 답변 작성 보조 등 서로 다른 방향성을 두고 팀원들의 의견이 나뉘었다. 논의가 교착 상태에 빠졌을 때 멘토님께서 '원하는 요약본 기능의 예시를 만들어보라'는 조언을 주셨다. 추상적인 아이디어를 구체화해보자는 취지였다. 기존 질의응답 데이터를 GPT로 요약해보니 의외의 결과가 나왔다. 요약 과정에서 중요한 정보들이 누락되어 오히려 전체 내용을 보는 게 낫겠다는 생각이 들었다. 이렇게 실제 데이터로 검증해보니 자연스레 의견을 조율할 수 있었다. 추상적인 아이디어를 구체화하여 검증하는 것의 중요성을 배운 순간이었다.

도전 거리들

인공지능 API가 비용이 발생하는 외부 서비스다 보니, API 호출을 최소화하기 위한 다양한 최적화를 고민했다. 사용자가 악의적으로 인공지능 API를 요청할 경우를 제한했고, 느린 AI 응답 속도를 보완하기 위해 스트리밍 방식으로 UX를 개선했으며, 실시간성이 중요치 않은 AI 작업은 배치 처리로 백그라운드에서 처리했다. 단순히 외부 API 하나를 붙이는 작업이 서비스 전반의 아키텍처를 다시 한번 돌아보고 개선하는 계기가 되었다.

특히 기억에 남는 건 AI 채팅 필터링 과정이었다. 우리 서비스에서는 채팅방에 부적절한 내용이 올라오는 것을 막기 위해 AI로 채팅 내용을 필터링하고 있었다. 문제는 AI가 채팅 하나를 필터링하는 데 평균 0.8초가 걸린다는 것이었다. 실시간 채팅방에서 여러 사용자가 동시에 채팅을 보내면 서버가 블로킹되어 모든 채팅이 지연될 우려가 있었다.

이를 해결하기 위해 배치 처리를 도입하기로 했다. 채팅들을 모아뒀다가 한 번에 필터링하는 방식이었다. 처음에는 API 서버에 배치를 구현했는데, 여기서 또 다른 문제가 생겼다. 필터링이 끝난 채팅을 다시 모든 사용자에게 전달하려면(브로드캐스팅) API 서버가 SOCKET 서버를 호출해야 했고, 이는 서버 간 불필요한 의존성을 만들었다. 결국 실시간 통신을 담당하는 SOCKET 서버에서 직접 배치 처리를 하도록 개선했다.

이 과정에서 프로젝트의 규모가 커져감을 실감했다. 서버가 기능별로 여러 개로 분리되어 있다 보니, 새로운 기능을 어떤 서버에 붙일지도 중요한 고민거리였다. 단순히 무에서 유를 만드는 것도 어려웠지만, 이미 있는 프로젝트에 기능을 붙이고 키워나가는 게 더 어렵다는 걸 깨달았다.

이렇게 인공지능을 붙이고 최적화 해나가는 과정이 재미있어서 마지막 주차에는 시간이 더 있었으면 하는 생각이 들었다. 인공지능 비용을 절약하기 위한 RAG라는 주제도 발견했는데, 시간이 부족해 도전해보지 못한 게 아쉬움으로 남는다.

느낀 점

이번 인공지능 리팩토링을 통해 기술적 최적화도 중요하지만, 실제 서비스 맥락에서의 의사 선택이 더 중요하다는 것을 깨달았다.

우리의 인공지능 기능을 선보이는 최종 발표 자리에서 다음과 같은 질문을 받았다.

Ask-It의 서비스 목적에 맞게 팀원끼리 실시간 Q&A를 직접 진행해보신 적이 있나요?

부끄럽게도 없었다.

인공지능 기능을 추가하면서 우리가 중점을 둔 건 기술적인 측면과 비용 효율성이었다. 예를 들어 다음과 같이 사용자의 질문을 개선해주는 기능을 만들 때에도 우리의 주된 고민은 '비용을 최소화하면서도 만족스러운 결과물을 낼 수 있으려면 어디까지 보내야 할까?'였다.

맥락 정보를 많이 보낼수록 AI 비용이 증가하기 때문에, 우리는 가장 최근의 개선 맥락만을 보내는 방식을 선택했다.

예를 들어 다음처럼 질문 개선 과정이 있다면

1. 사용자 요청: "python vs JavaScript"
2. AI 개선 결과: "웹 개발 분야에서 Python과 JavaScript를 비교해주세요."
3. 사용자 재요청: "코딩 테스트 분야에 대해서"
4. AI 개선 결과: "코딩 테스트를 볼 때 Python과 JavaScript 중 어느것이 유리한가요?"

3번 요청을 보낼 때 2번의 AI 개선 결과는 제외하고 가장 최근의 맥락만을 포함하는 방식을 택했다.

하지만 최종 발표 자리에서 받은 "Ask-It의 서비스 목적에 맞게 팀원끼리 실시간 Q&A를 직접 진행해보신 적이 있나요?"라는 질문은 우리가 놓치고 있던 중요한 관점을 일깨워주었다. 만약 우리가 서비스를 실제로 사용해봤더라면, 실시간 Q&A의 특성상 빠르게 질문을 올려야 하기 때문에 대화의 맥락이 그리 길어지거나 복잡해지지 않을 것이라는 서비스의 특성을 파악할 수 있었을 것이다.

이러한 점을 회고해보니, 우리가 기술적 최적화에만 집중한 나머지, 실제 서비스 맥락에서의 사용자 경험을 놓쳤다는 걸 깨달을 수 있었다. 이번 경험을 통해 개발자도 결국 서비스의 첫 번째 사용자가 되어야 한다는 점을 배웠다. 아무리 기술적으로 완벽한 최적화를 이뤄냈다 하더라도, 그것이 실제 서비스 맥락에서 의미 있는 선택이었는지는 직접 사용해보기 전까지는 알 수 없기 때문이다. 앞으로는 코드를 작성하기에 앞서, 서비스를 직접 경험하고 이해하는 시간을 더 가져야겠다는 다짐을 하게 되었다.

8개월 동안 얻은 것들

부스트캠프를 통해 기술적인 성장 외에도 많은 것을 배웠다. 특히 근거를 가지는 연습을 했던 게 많은 도움이 되었다. 모든 판단과 결정에 의도적으로 '왜?'라는 질문을 던지고 답하는 연습을 했다. 처음에는 어색했지만, 이제는 자연스러운 흐름으로 정착한 것 같다. 또 이런 사고 훈련이 면접에서 많은 도움이 되었다. 최근에 인턴 면접을 세 개 보았는데, 준비 과정에서 '왜?'에 대한 물음을 열심히 대비했다. 덕분에 면접장에서 생각해봤던 '왜'를 물어봐주실 때 자신있게 대답할 수 있었다.

페어 프로그래밍은 부캠에서 얻은 또 하나의 값진 자산이다. 처음에는 낯설고 어려웠지만, 그룹 프로젝트와 리팩토링 과정에서 꾸준히 페어 프로그래밍을 하면서 기술적 논의를 코드로 옮기는 과정이 자연스러워졌다. 이런 경험은 면접의 라이브 코딩 테스트에서도 도움이 되었다. 면접관분들의 힌트를 이해하고 실시간으로 코드에 반영하는 과정이 마치 페어 프로그래밍의 드라이버 역할과 비슷했기 때문이다.

무엇보다 '완주하는 힘'을 기를 수 있었다. 챌린지 과정의 빡빡한 일정, 학습 스프린트 전반전에서 느낀 무력감과 충격, 많은 팀들이 떠나간 후 조촐해진 인공지능 리팩토링까지. 중간중간 에너지가 떨어지는 순간도 있었지만, 시작한 과정은 모두 완주해냈다. 이는 순전히 내 의지만으로 된 것이 아니다. 함께 걸어준 팀원들이 있었기에 가능했다. 서로가 강한 동기부여가 되어주며 끝까지 걸어올 수 있었다.

또한 캠퍼분들과 함께하며 새로운 도전들을 해볼 수 있었다. 처음으로 데이터베이스 스터디를 열어 스터디를 운영해보는 경험을했다. 아직 많이 미숙했지만, 캠퍼분들의 도움 덕분에 아직까지 잘 운영되어오고 있다. 1월에는 4주 동안 블로그 글쓰기 스터디에 참여했는데, 서로의 글을 꼼꼼히 읽고 피드백하는 과정에서 기술적 지식은 물론 더 나은 글쓰기에 대해서도 배울 수 있었다. 리팩토링 기간에는 매일 아침 10시부터 12시까지 진행된 스터디 덕분에 생활 패턴도 잡히고 하루를 더 도전적으로 시작할 수 있었다. 더불어 스터디 전후로 나누었던 취업 준비 이야기들, 특히 이력서 작성 관련 조언들은 실제 지원 과정에서 큰 도움이 되었다.

이젠 정말 끝!

공식 수료는 12월이었지만, 드디어 완벽히(?) 수료해낸 기분이 든다.

8개월이라는 긴 여정 동안 쌓은 기술적인 역량은 물론, 그 과정에서 얻은 소중한 경험들이 내 자신감의 원천이 되었다. 여기서 배우고 몸소 느낀 지식들, 근거를 가지는 훈련들, 시작한 것에 대해 포기하지 않고 끝까지 완주한 경험들까지. 모든 것이 기반이 되어 앞으로 무엇을 하든 잘 해낼 수 있을 것 같다는 확신이 든다.

사실 부캠을 시작할 때는 '잘 할 수 있을까?' 하는 걱정이 컸는데, 지금은 '할 수 있다'는 생각이 먼저 든다. 물론 이건 순전히 내 힘으로 된 게 아니다. 힘들 때마다 서로 으쌰으쌰 해준 우리 대방인 팀원들이 있었기에 가능했다. 함께 웃고, 고민하고, 성장했던 이 시간이 정말 감사하다.

다음은?

나는 휴학생이고 다시 학교에 돌아가야 한다. 하지만 부캠에서 배운 내용을 바로 실무에 써먹어보고 싶다는 강한 열망이 있었다. 그래서 인턴을 많이 도전했고, 감사히도 인턴 기회를 얻을 수 있게 되었다. 학교로 돌아가기 전까지 이 기회를 통해 실무 경험도 쌓고, 새로운 도전도 해볼 생각이다. 부캠의 자산을 가지고 인턴도 잘 헤쳐나갸야지.