라이브채팅 플랫폼 구현기 2탄 : 아키텍처 및 성능 테스트

 

 

앞서 라이브채팅 플랫폼을 구현하기 전 개발언어와 기반기술 조사에 관한 내용을 다뤘는데요.

이번 편에서는 라이브채팅 플랫폼 아키텍처 설계 및 성능 테스트에 대해 다뤄보고자 합니다.

 

아직 '라이브채팅 플랫폼 구현기 1탄 : 개발언어와 기반기술 조사'편을 보지 못하셨다면 아래 글을 클릭해 주세요!

 

▶️ 라이브채팅 플랫폼 구현기 1탄 

라이브채팅 플랫폼 구현기 1탄 : 개발 언어 및 기반기술 조사

 

Jace / Umid / Probe

 

 

[Chapter 2] 아키텍처

 

 

1.  고려사항

라이브채팅 플랫폼 시스템 아키텍처 설계 시 다양한 고려사항이 존재하였고 가장 중요하게 생각했던 것은 다음과 같았습니다.

 

• 대용량 메시지 트래픽 처리
• 채팅은 인증된 사용자만 접속 가능
• 채팅 메시지 송/수신 시 최대 1000ms 이내 수신 가능
• 채팅 관련 지표 실시간 모니터링 
• 수신된 모든 메시지는 영구 저장소에 저장
• 특정 채팅에 대한 채팅 룸은 자동으로 분할/병합 수행
  : 전체 사용자(접속자)가 단일 채팅 룸에서 대화를 하게 되는 경우, 사용자들은 사실상 메시지 확인을 거의 하지 못함
  : 하여 설정된 인원수로 채팅 룸이 자동으로 분할/병합되어야 함
• 전달된 메시지는 실시간으로 금칙어 포함 여부 체크
• 관리자는 채팅 전체/특정 룸/특정 사용자를 대상으로 다양한 제재를 실시간으로 처리

 

 

2. 처리방식 

위 고려사항을 만족하기 위한 아키텍처 설계 시 가장 먼저 고려되어야 할 사항은 메시지 처리 방식이었습니다.

1️⃣ Synchronous

 

  메시지 수신 이후 저장 및 전달까지 동기식으로 처리

장점	단점
◽️ 구현이 비교적 쉽고 설계가 간단함 ◽️ 메시지 처리를 위한 적은 수의 Eco system      : 적은 수의 인원(개발자)이 채팅 핵심 기능에 몰두할 수 있음	◽️ 메시지 수신 이후 발생하는 다양한 처리를 동기식으로 처리하여 서버 부하 가중 ◽️ 특정 처리 구간의 부하가 전체적인 처리 성능 감소시키고 전면 장애로 이어짐

2️⃣ Asynchronous

 메시지 수신 이후 저장 및 전달까지 비동기식으로 처리

장점	단점
◽️ 메시지 수신 이후 발생하는 다양한 처리를 비동기로 처리하여 서버 부하 감소 ◽️ 특정 처리 구간의 부하를 고립시켜 전면 장애 회피 가능	◽️ 설계/구현이 복잡함 (디버깅이 어려움) ◽️ 메시지 처리를 위해 다양한 Eco system 필요함      : 적은 수의 인원(개발자)이 다양한 Eco system을 관리해야 하므로 운영 Risk 증가

이 외에도 두 방식의 다양한 특성들에 대해 비교 검토하였고 저희는 Asynchronous를 최종 처리 방식으로 결정하였으며 주된 이유는 다음과 같습니다.

 

✔️ 대용량 메시지 처리 시 동기식보단 비동기식 처리가 조금 더 서버 리소스를 효율적으로 사용 가능 
✔️ 특정 처리 구간의 부하(장애)로 인한 전면 장애 회피 
✔️ 메시지 수신 이후 다양한 처리 로직을 효과적으로 배치 또는 추가하기에 동기식은 변경에 의한 Side Effect가 너무 크다고 판단 
✔️ 비동기식 구조로 개발 시 메시지 처리를 위한 다양한 기능 개발을 각 개발자 간 최소한의 접점으로 진행 가능 

 

저희는 비동기 방식으로 결정하고 난 후 자연스럽게 비동기 프로그래밍 방식에 대한 고민이 이어졌고, 사전에 결정한 개발언어(Kotlin)를 토대로 우리가 고민할 수 있는 선택지는 다음과 같았습니다.

 

Java/Kotlin의 Thread/비동기 API(Future, Callable)	Kotlin의 Coroutin
◽️ 개발자 모두 경험이 있었으나 구현의 난이도가 높음	◽️ 개발자 모두 경험은 없으나 구현의 난이도가 낮음

 비동기 프로그래밍은 어떤 방식이던 디버깅이 어려운 동일한 문제를 가지고 있기 때문에 상대적으로 구현의 난이도가 낮고, 이번 프로젝트를 통해 배울 기회가 될 수 있다는 Needs 때문에 Coroutine 기반으로 선택하게 되었습니다.

 

 

 

3. 메시지 처리 구조

메시지 처리 구조는 아키텍처를 설계하면서 가장 고민을 많이 했던 영역이었습니다. 라이브채팅은 사용자가 전송한 메시지가 동일 룸에 속해 있는 N명의 사용자에게 전달되어야 하는 단순하면서 명확한 요구사항이 존재합니다. 클라이언트(사용자)는 채팅 서버에 접속 시 WebSocket 프로토콜을 사용하여 서버에 접속하게 되며 정상적으로 접속된 클라이언트는 서버와의 연결이 유지됩니다. 이렇게 연결된 클라이언트는 논리적으로 특정 룸에 속하게 되고 클라이언트가 전송한 메시지는 룸 내 다른 N개의 클라이언트에게 전달되게 됩니다. 
분산환경에서 연결된 클라이언트를 특정 룸으로 관리하기 위해선 크게 두 가지 방식이 존재합니다.

 

 

1️⃣ '룸'을 동일 서버에 배치 

 

장점	단점
◽️ 수신된 메시지를 별도의 Message Broker없이 동일 룸의 N개의 클라이언트에 전달하므로 속도가 빠름	◽️ 서버별로 룸 정보를 별도로 관리 해야함  ◽️ 룸의 메시지 송/수신 트래픽 편차 때문에 고르지 못한 서버 리소스 사용율 (즉, 어떤 서버는 부하가 심하고 반대로 어떤 서버는 놀고 있을 수 있음)

2️⃣ '룸'을 분산된 N대의 서버 배치 

 

장점	단점
◽️ 서버별 룸 정보를 별도로 관리할 필요가 없음 ◽️ 고른 서버 리소스 사용율	◽️ 별도의 메시지 전달 체계가 필요함 ◽️ 복잡한 처리 구조

위 두 가지 방식에서 저희가 선택한 건 '룸을 분산된 N대의 서버에 배치'입니다.

 주요 선정 이유는 룸을 동일 서버에 배치하는 방식의 경우, 서버 리소스의 비효율적인 사용과 서버별 룸 정보를 관리해야 한다는 점이었으며 또한 메시지 수신 후 다양한 후처리(금칙어, 도배 등) 이후 메시지를 다른 클라이언트에게 전달해야 하므로 이 과정을 채팅 서버가 담당해야 하는 경우 부하로 인한 성능 저하가 예상되었기 때문입니다. 

* 채팅 서버의 경우, 클라이언트와 연결이 유지되어야 하고 대량의 메시지를 WebSocket을 통해서 송/수신해야 하기 때문에 전형적으로 CPU사용이 높은 애플리케이션임.

룸을 분산된 N대의 서버에 배치하는 방식은 메시지를 수신한 특정 서버가 동일 룸을 보유하고 있는 다른 서버로 메시지를 전달하기 위해선 전달 체계가 필요하게 되며 일반적으로 이 전달 체계는 Message Broker라 프로그램 모듈이 필요하게 됩니다.

Message Broker의 경우 앞선 기반기술 조사 부분에서 소개된 Kafka를 사용하였으며, 클라이언트로부터 전달된 메시지 송/수신 및 금칙어/도배 체크, 메시지 저장, 채팅 지표 추출을 위한 전체적인 아키텍처 다이어그램은 다음과 같습니다.

 

라이브채팅 플랫폼 전체 아키텍처 다이어그램

 

위 아키텍처에서 사용된 기술 Set의 용도를 조금 더 살펴보도록 하겠습니다.

 

• Kafka : 분산된 채팅 서버 간 메시지 전달을 위해 사용되며 클라이언트가 전달한 모든 메시지뿐만 아니라 관리자가 클라이언트 제어를 위한 Command 및 Event 메시지 또한 처리
• Kafka Streams : Kafka로 전달된 메시지를 분산된 채팅 서버로 전달하기 전 금칙어, 도배 여부 판단을 stream processing을 통해서 처리
• Redis : 채팅방에 대한 메타정보, 룸별 유저의 접속 정보, 최근 전달된 메시지 등과 같이 빈번하게 조회되는 데이터들에 대해 캐시 용도로 사용
• Sink : 수신된 메시지 데이터는 Kafka에 1차적으로 저장되어 있지만, 저장 주기가 길지 않기 때문에 메시지를 영구 저장소(MongoDB)로 저장하기 위해서 Sink Processor를 사용하여 비동기로 MongoDB 및 지표 측정을 위한 Elastic Search에 저장

 

 

 

 

 

[Chapter 3] 성능 테스트

 

 

라이브 채팅 플랫폼은 서비스 특성상 짧은 시간에 수많은 사용자가 몰려 대량의 트래픽을 발생시킵니다. 순간적인 대량의 트래픽을 감당하지 못해 채팅 메시지 전달 지연이 발생하는 경우 채팅이라는 서비스 특성상 사용자 경험을 크게 저하하게 합니다. 이런 성능 관련 문제를 사전에 발견 및 예방하기 위해 개발 단계에서부터 성능 테스트를 병행하며 개발을 진행하였습니다.

1. 테스트 도구 선택

 라이브 채팅 플랫폼은 일반적인 HTTP request/response 형식의 API 서버와는 달라서 서비스 특성에 맞는 적절한 테스트 도구 선택이 중요하였고 다음의 고려 사항을 토대로 테스트 도구를 선택하게 되었습니다.

 

• WebSocket 지원 : 라이브 채팅 플랫폼은 WebSocket으로 대부분의 트래픽을 감당하게 됩니다. WebSocket 테스트 가능 여부는 필수 사항이며 WebSocket 테스트를 원활히 할 수 있는지도 고려해야 합니다.
• 부하 가중 능력 : 라이브 채팅 플랫폼은 아주 높은 트래픽을 받을 것으로 예상하고 있습니다. 단일 인스턴스 기준으로 얼마까지 부하를 가중시킬 수 있는지를 고려해야 합니다.
• 분산 로드 테스팅(Distributed Load Testing) 지원 : 테스트 도구가 효율적이고 인스턴스가 아무리 성능이 좋더라도 단일 인스턴스만으로는 가중시킬 수 있는 부하의 한계가 있습니다. 분산 로드 테스팅이라 불리는 기능을 통해 다중 인스턴스에서 대량의 부하를 일으킬 수 있는지, 다중 인스턴스에서 일으킨 부하를 취합해서 리포팅할 수 있는지 고려해야 합니다.
• 적절한 비용 : 테스트 환경 직접 구축 시 서버 사용료를 고려해야 하며, 유료 플랫폼을 고려할 경우 플랫폼 비용이 적절한지에 대한 고민이 필요합니다.
• 사용 편의성 : 테스트 시나리오 작성의 편의성을 고려해야 합니다.
• 의미 있는 결과 확인 용이 : 실시간 모니터링, 결과 그래프 지원, 정확하고 의미 있는 결과 확인 가능 여부 등을 고려해야 합니다. 

 위와 같은 고려 사항을 토대로 테스트 러너와 테스트 플랫폼으로 나누어 도구들을 비교하게 되었습니다.

 

 

1️⃣ 테스트 러너 비교

 

테스트 러너	특징	장점	단점
Apache JMeter	◽️ 테스트 시나리오 작성을 위한 GUI 클라이언트 프로그램 제공	◽️ Apache 정식 프로젝트 ◽️ 전통적으로 많이 사용되던 도구 ◽️ WebSocket 포함 다양한 프로토콜 지원 ◽️ 다양한 기능 지원	◽️ 쓰레드 기반 (하나의 호출 당 하나의 쓰레드가 점유하여 I/O 결과가 올 때까지 쓰레드 블럭킹) ◽️ 기본 프로그램만 사용 시 결과 리포트 확인 불편 ◽️ GUI로 작성하는 테스트 시나리오가 경우에 따라 불편할 수 있음 ◽️ 테스트 수행 완료까지 결과 기다려야 하며, 보통 Taurus와 조합하여 이런 불편을 해소
Grinder	◽️ Java 기반	◽️ nGrinder 플랫폼을 통해 국내에서 널리 사용됨 ◽️ Jython 으로 코드 기반 시나리오 작성 가능	◽️ 쓰레드 기반 (하나의 호출 당 하나의 쓰레드가 점유하여 I/O 결과가 올 때까지 쓰레드 블럭킹) ◽️ WebSocket 네이티브 지원하지 않음   - 블럭킹 호출로 각 WebSocket 명령을 감싸서 하나의 메소드를 만들고 그 메소드 호출/완료 결과를 측정   - WebSocket 의 호출의 다양한 정보 확인 불가능
Gatling	◽️ Netty와 Akka기반    - 오픈 소스 버전과 유료 버전이 분리되어 있음	◽️ 논 블럭킹 비동기 호출로 속도 빠름 ◽️ Java, kotlin, Groovy 로 코드 기반 시나리오 작성 가능 ◽️ 기본 그래프 리포트 제공 ◽️ 강력한 WebSocket 테스트 지원	◽️ 오픈 소스 사용 시 Distributed Load Testing 지원 취약함   - Distributed Performance Testing with Gatling | Baeldung   - Scaling Out ◽️ 오픈 소스 사용 시 테스트 리포트 데이터 연동 지원 취약   - Graphite Documentation — Graphite 1.2.0 documentation 연동만 지원
k6	◽️ Go 기반    - 오픈 소스 버전과 유료 버전이 분리되어 있음. Grafana Labs 에 인수(21년 7월)되고 관리되는 프로젝트	◽️ 논 블럭킹 비동기 호출로 속도 빠름 ◽️ JavaScript 로 코드 기반 시나리오 작성 ◽️ 훌륭한 문서화, 훌륭한 커뮤니티 ◽️ 오픈 소스 사용 시에도 Distributed Load Testing 구축 지원  - Running distributed k6 tests on Kubernetes ◽️ 리포트 데이터 연동 기능 강력   - 다음 플랫폼/도구들과 연동 가능     ◾ Amazon CloudWatch     ◾ Apache Kafka     ◾ Datadog     ◾ InfluxDB + Grafana     ◾ New Relic     ◾ Prometheus     ◾ TimescaleDB     ◾ StatsD ◽️ 컨버터, IDE 등 다양한 연동 기능 제공	◽️ 깃헙 오픈 이슈 비율 높음   - 318 Open / 980 Closed (2022년 기준) ◽️ 기본 그래프 리포트 미제공

 

 

2️⃣ 테스트 플랫폼 비교

 

테스트 플랫폼	특징	장점	단점
nGrinder	◽️ grinder의 wrapper로 Distributed Load Testing 기능과 웹 접근 도구 등을 제공	◽️ 오픈 소스 ◽️ Distributed Load Testing 기능 제공 ◽️ 국내에서 널리 사용 ◽️ 테스트 결과 확인 용이	◽️ Grinder 의 단점을 그대로 가지고 감 쓰레드 기반 ◽️ WebSocket 지원 취약 * 현재 기준(2022년) 활발하지 않은 커뮤니티
Taurus	◽️ JMeter 또는 Gatling 등 다양한 테스트 러너를 래핑하여 도움을 주는 플랫폼	◽️ 오픈 소스 ◽️ 실시간 테스트 시각화 제공	◽️ JMeter 외에 다른 테스트 러너 지원은 취약 ◽️ Distributed Load Testing 기능 지원하지 않음
Distributed Load Testing on AWS	◽️ AWS 솔루션 라이브러리로 Taurus, JMeter 조합을 다중 인스턴스에서 AWS 인프라를 사용하여 수행하게 해줌	◽️ 오픈 소스 ◽️ Distributed Load Testing 기능 제공 ◽️ CloudFormation 탬플릿을 제공하여 클릭 몇번으로 쉽게 구축 가능	◽️ JMeter 만 지원 ◽️ 결과 확인 기능 취약 ◽️ AWS 인프라에서만 구축 가능
RedLine13	◽️ AWS 마켓플레이스를 통해 쉽게 사용할 수 있는 SaaS 플랫폼	◽️ JMeter 나 Gatling 등 다양한 테스트 러너 연동 제공 ◽️ 다중 인스턴스 부하를 쉽게 줄 수 있음 ◽️ 유료지만 요금이 저렴한 편	◽️ 다른 유료 플랫폼 대비 기능이 단순 ◽️ 멀티리전 부하테스트 기능 취약
Gatling 엔터프라이즈	◽️ Gatling wrapper SaaS 플랫폼	◽️ 기능 풍부 ◽️ 거의 모든 요금제에서 Virtual User 수 무제한	◽️ 요금이 비싼 편
k6 Cloud	◽️ k6 wrapper SaaS 플랫폼	◽️ 기능 풍부	◽️ 요금이 비싼 편 ◽️ Virtual User 수에 따라 요금이 급격히 증가

 

 

최종적으로 저희가 선택한 테스트 러너는 오픈 소스인 k6이며, 테스트 플랫폼은 유료인 k6 Cloud를 사용하는 대신 저희가 직접 k8s 위에 k6 테스트 플랫폼을 구축하기로 하였습니다. 다행히 k6는 k8s 위에 분산 로드테스트 환경을 구축하는 예제와 코드를 제공하고 있었으며 저희가 구축할 당시만 하더라도 문서와 코드에 많은 오류가 있었으나 최근에는 많이 안정화되어 누구나 쉽게 k8s에 k6 테스트 플랫폼을 구축할 수 있습니다. 개발 초기에는 AWS EKS 위에 분산 로드테스트 환경을 구축하고 CloudWatch와 연동하여 테스트 결과를 확인하였으며, 대량의 테스트가 필요했던 개발 마무리 단계에서는 Google Cloud GKE로 분산 로드테스트 환경을 옮겨와 테스트를 진행하였습니다.

 

2. 테스트 과정과 결과

 

 저희는 Performance Driven Development를 추구하였습니다. 이를 위해 저희가 달성해야 할 성능적 목표를 먼저 설정하였습니다. 'k8s 환경에서 특정 사양을 가진 Pod (cpu: 4, memory: 8 GiB) 하나당 동시접속 2천 명을 감당하며 1000ms(1초) 안에 메시지를 주고받을 수 있도록 한다.' 이렇게 목표를 설정하고 성능 개선을 위해 끊임없이 관련된 기술 리서치를 진행하였습니다. 그리고 코드나 플랫폼을 변경할 때마다 성능 테스트를 진행하여 각 변경이 성능에 어떤 영향을 주는지 확인을 하였습니다. 이러한 과정에서 저희가 부딪히고 해결했던 주요 이슈는 다음과 같습니다.

1️⃣ Redis Pub/Sub 성능 이슈
대규모 트래픽 부하 테스트 시 Redis Pub/Sub의 이슈를 발견하게 되었고, 기반기술 조사 - 5. Message Broker 항목에서 자세히 기술하였습니다. 이 이슈로 Message Broker를 스트림(Stream)으로 전환하게 되었습니다.

2️⃣ Google Cloud Pub/Sub 성능 이슈
스트림 도구로 첫 선택은 Google Cloud에서 제공하는 Cloud Pub/Sub이었습니다. 그런데 성능 테스트를 진행하다 보니 Cloud Pub/Sub 자체에서 소모하는 시간이 많다는 걸 발견하게 되었습니다. 그래서 Kafka와 Latency 비교를 진행하게 되었고, 그 결과를 기반기술 조사 - 5.Message Broker : 2) 메시지 전달 속도(Lagency) 항목에 기재하였습니다.

3️⃣ 로드밸런서 성능 이슈
Pod을 여러 개 띄우고 부하를 줬을 때 로드밸런서가 각 Pod에 적절하게 요청을 분배하지 못하는 현상을 발견하였습니다. Google Cloud에서 기본적으로 제공하는 로드밸런서는 Round Robin 방식인데, WebSocket 사용 시 일반적인 HTTP request/response 형식과 다르게 즉시 응답을 주지 않고 연결을 물고 있어 로드밸런서가 부하 분산을 적절하게 수행하지 못하였습니다. WebSocket 사용 시 트래픽이 전달될 서버를 직접 선택할 수 있도록 해야 했고, 저희는 Round Robin 방식 대신 Consistent Hashing 방식을 채택하게 되었습니다. Consistent Hashing 방식은 클라이언트마다 특정 정보를 해싱하여 부하가 전달될 인스턴스를 선택하는 방식이며 이를 통해 WebSocket 통신 방식과 상관없이 각 인스턴스에 고르게 부하가 분산될 수 있도록 하였습니다.

 

이와 같은 지속적인 성능 테스트와 튜닝들을 거쳐 최종적으로 저희가 목표한 성능을 달성할 수 있게 되었습니다.

 

 

 

 

[Charpter 4] 아쉬움..

 

 

성공적인 프로젝트라 자부하지만, 그럼에도 아쉬운 점은 늘 있기 마련인데요.

라이브채팅 프로젝트를 진행하면서 아쉬웠던 것은 무엇이었는지 공유하려고 합니다. 

 

1. 도배 및 광고 방지 구현

채팅 중 특정 문구를 지속해서 입력하여 채팅 참여자들의 피로를 유발하는 일부 사용자들이 있습니다. 이를 '도배'라고 표현을 하는데 현재 라이브채팅 플랫폼에는 단순히 '똑같은 문구를 일정 시간 내에 N회 이상 입력 시 도배이다'라는 조건으로 감지하는 것은 구현이 되어 있지만, 도배 감지에 요구되는 사항은 좀 더 고도화된 기능입니다. 같은 문구를 여러 번 입력하더라도 도배를 위한 글인지 단순 감탄사인지를 구분하거나, 문구를 조금씩 바꾸어 입력하더라도 도배로 판정할 수 있는 등의 요구 사항이 있습니다. 이를 위해 단순히 같은 입력 횟수를 카운팅 할 뿐만 아니라 유사어 감지, 감탄사와 구분 등 자연어 처리를 통해서 판단하는 구현이 필요하지만, 현재는 구현되어 있지 않기에 아쉬움으로 남는 부분이나 향 후 개선 과제로 선정하여 진행 예정에 있습니다.

2. 로드밸런싱 개선

현재 클라이언트가 전달한 특정 정보를 해싱하여 부하가 전달될 인스턴스를 선택하도록 하고 있습니다. 해싱 알고리즘이 고정되어 있기 때문에 클라이언트가 전달한 정보가 같다면 항상 동일한 인스턴스로 트래픽을 전달합니다. 그러나 클라이언트가 전달한 정보에 의존적이지 않고 서버 쪽에서 로드밸런싱을 더 세밀히 조정할 수 있다면 성능 개선에 도움이 될 수 있습니다. zookeeper 등을 활용하여 서버 상황에 따라 트래픽이 전달될 인스턴스를 서비스에서 직접 선택할 수 있으면 하는 아쉬움이 있고 이 또한 언젠가 도입하려고 하고 있습니다.

3. 성능 테스트 개선

Performance Driven Development를 추구하여 코드와 기반 플랫폼 변경이 있을 때마다 성능 테스트를 수행하였지만, 성능 테스트는 항상 수동으로 진행하였습니다. CI 단계에서 성능 테스트를 자동으로 수행하고 리포팅할 수 있게 한다면 더 좋지 않았을까 생각합니다. 또한, AWS에 구축했을 때는 테스트 결과에 대한 Visualization을 구축하였지만, Google Cloud로 테스트 플랫폼을 이전하고서는 구축하지 못했습니다. 테스트 결과에 대한 Visualization이 구축되고 이 또한 CI 리포팅과 연동할 수 있다면 좋지 않을까 생각합니다.

 

 

 

 

 

[Final] 마치며..

 

 

라이브채팅 구현 프로젝트는 채팅 플랫폼을 구현도, 운영도 해본 경험이 없는 3명의 개발자가 단기간 내 목표를 달성해야 하는 상당히 도전적인 프로젝트였습니다. (Google Cloud에 대한 리서치 및 학습, 시스템 설계 및 검증, 운영에 필요한 다양한 시스템 구축 등..)

 

그럼에도 불구하고 우리 팀은 목표를 달성하기 위해 다음의 규칙을 정의하고 따랐습니다.

 

1️⃣ 그 어떤 아이디어, 문제라도 자유롭게 제시하고 토의를 통해서 결정한다. 
2️⃣ 단, 해결책(대안)이 없는 문제 제기는 하지 않는다.
3️⃣ 결정된 안은 최대한 빠르게 검증하고 적용한다.

 

물론 규칙대로 결정된 사항일지라도 시행착오가 없던 것은 아니었습니다.
하지만 시행착오를 단지 시간의 소비로만 생각하지 않았고, 이를 통해서 다른 대안을 모색하고 배울 수 있는 기회로 삼고 그 어떤 프로젝트에서도 경험할 수 없는 값진 지식을 얻을 수 있었습니다.

 

이 프로젝트를 성공하게 하는 데에는 여러 가지 요소들이 있었지만,

가장 중요한 건(꺾이지 않는 마음..?)

팀원 모두가 이 프로젝트를 성공하려는 열망과 노력이 가장 컸다고 생각합니다.

라이브채팅 플랫폼은 MMA2022를 위해 시작되었지만, 설계 초기 단계부터 사내 모든 서비스/플랫폼에 적용할 수 있는 범용성을 염두에 두고 설계/구현되었고, 곧 새로운 서비스에 적용을 앞두고 있습니다.

우리의 라이브채팅 구현 여정은 아직도 현재 진행 중입니다. 
앞으로도 많은 도전적인 과제와 문제들을 맞닥뜨리게 되겠지만…

 

We will find a way. We always have.
우린 답을 찾을 것이다. 늘 그랬듯이.

 

 

 

 

 

📷 photo by. Selian 

---