마지막으로 글을 쓴 게 2월인데, 이 글은 7월이 다 되어서야 쓰고 있습니다. 복학하니 너무 바빴네요. 본격적인 활동을 한 지는 1년이나 지나버렸지만, 최대한 기억을 더듬어 작성해보겠습니다. 오히려 오래 지나서까지 기억에 남은 것들이야말로 정말 중요한 것들이 아닐까 싶습니다.
개발은 프로젝트마다 워낙 다르니 깊게는 다루지 않겠습니다. 대신 대부분의 경우에 유용하게 활용할 수 있는 요소들 위주로 작성해보겠습니다.
번외: 온라인 진행의 경우
번외로 말씀드리자면, 저희 팀은 아이디어 구체화 이후 프로젝트 대부분을 온라인으로 진행했습니다. 지방에 사시는 팀원분이 종강 후 서울에서 자취를 하시겠다고 팀 빌딩 때 말씀하셨지만, 집을 선릉으로 잡아버리셔서 살인적인 월세로 비명횡사하신 불상사가 발생하는 바람에 말이지요. 날이 갈수록 야위어지시기에 위약금 내고 내려보내드린 후 온라인으로 전환했습니다. 아직도 가끔씩 집 보러 간다 하셨을 때 신림이나 건대 근처로 잡으라 말할걸 하는 생각이 듭니다만, 결과적으로는 각자 집에서 편하게 일하면서 결과도 잘 나왔으니 잘 된 것 아닌가 싶습니다.
기획과 디자인은 의사소통 필요량이 많아서 최대한 대면으로 진행하는 것이 좋습니다. 실시간으로 팀원들에게 화면을 보여주면서 이야기할 것들이 많거든요. 그러나 기획만 잘 잡혀있다면 개발은 비대면으로 진행해도 큰 문제가 없습니다. 기획이 잘 되어있다면 기능과 요구사항이 명확히 정의되어 있을 것이고, 그에 맞추어서 개발만 하면 되니까요.
성공적인 온라인 진행을 위해서는 몇 가지 요소들을 고려해야 합니다. 먼저 코어타임을 정하는 것이 중요합니다. 온라인으로 시간을 유연하게 운영한다고 해도 일을 하는 시간대는 정해두는 것이 좋습니다. 뭔가 문제가 있을 때 바로 서로에게 물어볼 수 있어야 하거든요.
협업 방법에 대한 글에서 언급한 데일리 스크럼은 온라인 진행에서 특히 중요합니다. 대면으로 못 보기 때문에 서로의 작업 진행 상황을 알기 힘들고, 때문에 나태해지기 쉽습니다. 매일 오전 딱 세 가지만 말하고 작업을 시작하면 됩니다. 어제 뭘 했는지, 오늘 뭘 할 건지, 작업 중에 막힌 게 있는지. 이를 통해 나태해짐을 방지할 수 있습니다.
소통이 어려운 만큼 체계적인 일정 관리가 더욱 중요해집니다. 이전 글들에서 언급한 협업 및 기획 방법론은 온라인 진행에서 특히 더 중요해집니다.
멘토링은 계속된다
기획 구체화 이후 본격적인 개발을 위한 멘토링이 시작됩니다. EasterAd 프로젝트는 크게 백엔드, 프론트엔드, Unity 플러그인(클라이언트)로 구성되었습니다. 이들 중 프론트엔드와 Unity 플러그인의 경우 담당자가 주도해서 전체 구조를 짜둔 후 담당자와 예비 인원이 기능 구현을 진행하는 것으로 많은 경우 충분했습니다. 그러나 백엔드와 클라우드 인프라, 데이터베이스 설계의 경우 고려할 사항이 많고 비즈니스 로직에 대한 이해가 필요하며, 이후 수정하기도 어렵기 때문에 멘토링을 통해 초반에 설계를 확실히 잡아두고 진행하는 것이 크게 도움이 되었습니다.
EasterAd는 여러 요소에서 멘토링의 큰 도움을 받았습니다. 우선 고가용성 요구사항을 충족하기 위한 MSA 설계에서 많은 도움을 받았습니다. EasterAd 서비스에 가입하고 대시보드를 활용하기 위한 기본적인 서비스와, 잦은 빈도의 광고 송출을 담당하는 서비스를 분리하여 MSA로 설계했습니다.
또한 읽기/쓰기 요구량에 따른 적절한 데이터베이스 선택에 대해서도 많은 도움을 받았습니다. EasterAd는 읽기보다 쓰기가 빈번하게 일어나는 서비스였기에 MongoDB를 선택했습니다. VPC 및 서브넷 구성, CloudFront를 활용한 캐싱 등 일반적인 클라우드 인프라 설계에 대해서도 멘토링을 받았습니다. 데이터베이스와 각 AWS 기능들의 특징은 해당 분야에 대한 풍부한 경험이 없으면 고려하기 어려운 부분들이 많은데, 이러한 부분들을 멘토링을 통해 많이 보충할 수 있었습니다.
계좌번호 저장 등 법적 요구사항을 충족하기 위한 구현 방법도 배웠습니다. 사실 계좌번호를 암호화해서 저장해야 한다는 사실 자체를 멘토링하면서 처음 알았습니다. MongoDB Atlas를 사용하였기에 CSFLE 기능을 활용하여 암호화를 진행했습니다.
Datadog을 활용한 백엔드 및 랜딩페이지 모니터링도 멘토링을 통해 배운 중요한 요소였습니다. Observability를 고려하여 Datadog을 활용한 모니터링을 진행했습니다. AWS Marketplace를 통해 쉽고 빠르게 Datadog을 설치할 수 있었습니다. 가장 알차게 활용한 부분은 RUM이었습니다. 랜딩페이지를 사용자들이 어떻게 활용했는지 데이터를 수집하고 분석할 수 있었습니다. 세션 리플레이 기능을 통해 사용자가 랜딩페이지를 어떻게 활용했는지 그대로 확인할 수 있었으며, Scroll map과 Click map을 통해 사용자가 랜딩페이지에서 어떤 부분을 클릭하고 어디까지 스크롤했는지 확인하여 광고 효과를 분석할 수 있었습니다.
광고 송출을 위한 세션 관리 전략 등 비즈니스 요구사항 충족을 위한 설계도 중요한 멘토링 주제였습니다. 광고 송출을 위해 언제 세션을 시작할지, 그 안에서 광고 인벤토리와 광고 애셋의 매칭은 어떻게 수행할 것인지 등 비즈니스 로직에 대한 이해가 필요했습니다. Ad-Tech 분야 자체가 처음이었기에 멘토링이 없었다면 어려움이 많았을 것입니다.
EasterAd 아키텍처는 아니고, CloudCraft 홈페이지에 있는 예시입니다. 아키텍처를 그리면 이를 운용하기 위한 비용을 예측할 수 있습니다.
그리고 모든 클라우드 구성에 있어서 비용에 대한 고려를 도와주신 것도 큰 도움이 되었습니다. 경험이 부족한 주니어의 입장에서 클라우드 인프라를 운용하기 위한 비용을 예측하거나 적절한 인스턴스를 선택하는 것이 어려웠는데, 이러한 부분들을 멘토링을 통해 많이 보충할 수 있었습니다. 특히 CloudCraft를 활용하여 아키텍처를 시각화하고 예상 비용을 계산하는 방법을 배웠는데, 이는 앞으로도 유용하게 활용할 수 있는 도구인 것 같습니다.
권한 설정(AWS IAM)
대부분의 경우 AWS에서 작업을 진행하게 되니 IAM을 활용하여 권한을 관리하게 됩니다. 저희는 각 팀원마다 IAM User를 생성하고, 개개인은 IAM User로 로그인하며 root 계정으로는 로그인하지 않도록 했습니다. Root 계정은 팀장인 제가 MFA를 통해서만 접근할 수 있도록 설정했습니다.
원래대로라면 최소 권한 원칙을 따라 각 팀원에게 필요한 권한만 부여했어야 했으나, AWS에 익숙하지 않아서 권한을 부여하는 것조차 어려웠습니다. 그래서 팀원들에게는 관리자 권한을 부여했습니다. 하지만 각 AWS 리소스에 대해서는 최소 권한 원칙을 적용하여 최소한의 보안을 유지했습니다.
AWS IAM에 대해서는 AWS에 다니시는 멘토님이 진행하시는 자유 멘토링에 참여해서 많이 배울 수 있었습니다. 다양한 분야에 대한 멘토링이 이루어지니 들을 수 있는 한 최대한 멘토링을 들으시는 걸 추천드립니다. 꼭 프로젝트에서 당장 활용하지 않을 것 같더라도, 언제 어디서 필요할지는 모르니까요.
빌드 및 런타임 환경 구성
저는 Dev, Release, Production으로 빌드 및 런타임 환경을 나누어 개발하였는데, 이런 3단계 환경 분리가 많은 경우 유용하게 활용될 것 같습니다. 특히 Unity 플러그인 개발에서 이러한 환경 분리가 매우 유용하게 동작했습니다.
Dev
개발 환경에서는 주로 로컬에서 개발을 진행하며, 최대한 많은 정보를 로그에 남기거나 출력합니다. Unity 플러그인 개발의 경우, Editor 콘솔 창에 상세 로그를 출력하거나 필요하다면 화면에 Gizmo를 그려서 시각적으로 프로그램 동작을 확인할 수 있도록 했습니다.
아래는 광고 유효 시청을 평가하는 모듈의 일부 기능의 작동을 Gizmo로 시각화한 예시입니다. Frustum에 포함될 가능성이 있는 광고판에 대해 이들이 실제로 화면 내에 보이는지 여부를 시각적으로 확인할 수 있도록 Gizmo를 그려서 표시했습니다.
화면에 노출되는 부분은 초록색으로, 다른 물체에 가려지거나 화면 밖으로 나간 부분은 붉은 색으로 표시되는 것을 확인할 수 있습니다.
또한 개발을 편하게 수행하기 위한 자동화 스크립트 등을 포함시키기도 했습니다.
Release
Release 환경 역시 Dev처럼 개발 과정에서만 사용되는 환경이지만, 여기에서는 개발 환경에서의 로그를 최소화하고 실제로 배포할 때와 유사한 환경을 구성합니다. 개발 중 최종 테스트가 진행되는 환경이라고 생각하시면 됩니다.
Unity 플러그인의 경우 Release 빌드를 진행하면 대부분의 로그 및 기즈모 표시를 제거하고, 플러그인이 최종적으로 사용되는 환경과 거의 동일하게 동작합니다. 그러나 API 엔드포인트 등 외부 리소스에 대한 접근은 Dev 환경과 동일하게 유지합니다. 테스트 진행 과정에서 쌓인 로그들이 프로덕션 환경에 영향을 주어서는 안 되기 때문입니다.
Production
Production 환경은 실제로 서비스가 운영되는 환경입니다. 이 환경에서는 로그를 최소화하고, 성능을 최대한 끌어올리기 위해 최적화된 빌드를 사용합니다. Unity 플러그인의 경우, Production 빌드를 진행하면 최적화된 코드로 빌드되며, API 엔드포인트는 실제 서비스가 운영되는 환경으로 설정됩니다.
MSA
MSA는 비싸고 복잡하기 때문에 고가용성이 꼭 요구되는 것이 아니라면 굳이 일찍 도입할 필요는 없습니다. 솔직히 창업을 한다면 처음부터 MSA로 구현하는 것은 절대 하지 않을 것 같습니다. 초기에 그 비싼 서버비를 감당할 여력이 없거든요. EasterAd도 사용자 하나 없는 상태에서 development, production 두 서버 환경만 운영했는데 월 30만원 전후의 비용이 나왔습니다. 만약 소마가 끝나고 서비스를 유지할 계획이 있다면 소마 활동이 끝난 후의 서버비가 상당히 부담스러울 수 있어요.
다만 MSA로 구현하면 중간평가 및 최종평가에서 기술적 완성도를 높게 인정받을 수 있습니다. 그러나 EasterAd는 가용성에 대한 요구사항이 있었기에 이게 먹힌 것이지, 필요도 없는 기술을 억지로 도입할 필요는 전혀 없습니다.
AWS Bedrock
LLM 챗봇을 만들어야 한다면 AWS Bedrock을 강력히 추천합니다. 이번 프로젝트에는 시간의 문제로 적용하지 못했지만, AWS Bedrock은 LLM을 활용한 챗봇 개발에 매우 유용합니다. 특히 고객 응대를 위한 챗봇 기능을 제공해야 하는 경우에는 더욱 그렇습니다.
개발 문서를 제공하기 위해 많은 경우 Markdown 문서를 HTML로 변환해주는 도구를 사용하게 될 텐데, 저희는 C# 프로젝트를 위한 docfx를 사용했습니다. 이런 도구들은 PDF 변환 역시 지원하는 경우가 많습니다.
저희의 경우 멘토님의 지도 아래 RAG가 적용된 LLM 챗봇 기능을 1시간 만에 구현할 수 있었습니다. AWS Bedrock에 MongoDB Atlas를 연동하고, PDF 문서를 업로드하면 벡터 임베딩이 자동으로 이루어져 데이터베이스에 저장됩니다. 이후 LLM 챗봇을 생성하고, MongoDB Atlas를 데이터 소스로 설정하면 챗봇이 개발 문서를 기반으로 질문에 답변할 수 있게 됩니다.
마무리
사실 EasterAd에서 기술적으로 특이한 부분들, 특히 제가 담당한 부분들은 거의 이 글에 쓰지 못했습니다. 왜냐하면 제가 담당한 파트가 Unity 플러그인 개발이었는데, 이 부분은 소마를 진행하시는 대부분의 분들이 필요로 하지 않을 부분이기 때문입니다. Unity 플러그인 개발에 대한 글은 추후에, 소마 이후에 알게 된 팁들까지 합쳐서 따로 작성해보겠습니다.