이메일 인프라 제품 개발 프로세스의 5대 과제

이메일 인프라는 전자 메시지의 전송, 수신 및 저장을 가능하게 하는 상호 연결된 시스템입니다. 이처럼 B2B든 B2C든 정보 교환을 촉진하는 데 중요한 역할을 합니다.

그런 점에서 Radicati Group Inc.는 2027년에는 전송된 총 이메일 수가 4000억 개에 육박할 것으로 추정합니다. 그리고 전 세계 사용자 수는 같은 해에 50억 명에 이를 것으로 예상됩니다.

이메일 트래픽의 양이 계속 증가함에 따라 강력하고 안정적인 이메일 인프라를 갖추는 것이 중요하다는 사실을 부인하기 어렵습니다.

그러나 신뢰할 수 있는 이메일 인프라를 개발하고 유지하는 데 문제가 없는 것은 아닙니다. 이 기사에서는 조직이 이메일 인프라 제품 개발 프로세스에서 직면하는 상위 5가지 과제에 대해 논의하고 이를 극복하기 위한 실용적인 솔루션을 제공합니다.

1: 확장성

도전

트래픽이 계속 증가하기 때문에 이메일 인프라가 로드를 처리하는 데 어려움을 겪을 수 있습니다. 기업은 성장을 수용하고 서비스 중단을 방지하기 위해 선제적 조치를 취해야 합니다.

개념 개발과 병행하여 조치를 브레인스토밍하는 것이 유리합니다. 그렇지 않은 경우 개발자는 MVP 릴리스와 함께 이를 수행해야 합니다. 그렇지 않으면 다음과 같은 위험이 있습니다.

• 생산성 손실
• 고객 만족도 감소
• 잠재적인 재정적 손실
• 도메인 기관 등급 하락
• 발신자 평판 하락

솔루션:

• 클라우드 기반 인프라
• 부하 분산

클라우드 기반 인프라 사용

클라우드 기반 인프라를 통해 개발자는 타사 이메일 서비스의 확장성과 안정성을 활용합니다. 또한 증가하는 고객 요구 사항을 해결하는 데 필요한 리소스를 확보합니다.

유망해 보이지만 실제로는 어떻게 작동합니까?

타사 이메일 서비스는 대규모 중앙 집중식 데이터 센터를 사용하여 데이터를 저장하고 처리합니다. 따라서 소프트웨어 개발 회사는 자체 투자 없이 최신 기술과 리소스를 활용할 수 있습니다. 그리고 그것은 하나의 돌로 두 마리의 새를 죽이는 데 도움이 됩니다.

1. 이 접근 방식은 운영 비용을 크게 줄입니다.
2. 또한 증가하는 요구 사항을 충족할 수 있는 확장 가능한 솔루션을 조직에 제공합니다.

여기서 강조해야 할 중요한 점은 클라우드 기반 인프라를 한 번에 한 단계씩 개발해야 한다는 것입니다. 즉, 클라우드에서 일부 작업 실행을 시작한 다음 현재 부하(이 경우 이메일 또는 사용자 요청의 양)에 따라 작업 자체를 확장하는 것이 가장 좋습니다.

그러나 클라우드 기반 작업은 임시로 확장되어서는 안 되며, 각각의 제품 개발 전략을 결정하는 것이 중요합니다. 더 중요한 것은 이와 관련된 문제 및 병목 현상이 있는지 알아야 한다는 것입니다.

부하 분산 구현

좀 더 깊이 들어가기 전에 클라우드 기반 인프라와 함께 로드 밸런싱을 구현해야 한다는 점을 명심하십시오. 기껏해야 하나의 제품 개발 단계 내에서.

이제 로드 밸런싱은 여러 클라우드 내 아키텍처 및 작업에 걸쳐 워크로드를 분산하는 것을 의미합니다. 주요 이점은 기존 제품이 최대 트래픽에서도 증가된 볼륨을 처리할 수 있다는 것입니다.

워크로드가 여러 서버에 분산되어 있으므로 단일 서버가 이메일 트래픽 양에 의해 제한되지 않습니다. 따라서 서비스 중단 및 병목 현상의 가능성이 훨씬 낮습니다.

더 좋은 점은 로드 밸런싱 알고리즘을 사용하여 일반적으로 두 가지 요인을 기반으로 워크로드 분포를 동적으로 조정할 수 있다는 것입니다.

1. 요청 수입니다.
2. 각 서버의 처리 능력.

지옥 같은 숙박 플랫폼 구축

2012년에 Airbnb의 제품 개발 프로세스는 중추적인 단계에 있었습니다.

그들은 전체 플랫폼을 확장하면서 대상 청중의 머리를 바로 쳤습니다. 그러나 사용자 피드백을 통해 변경 요청, 분쟁 및 환불과 관련된 극단적인 사례가 놀라울 정도로 많이 나타났습니다. 당시 이 모든 작업은 요청 처리를 지원하는 백엔드 없이 이메일을 통해 수동으로 처리되었으므로 비즈니스 확장에 상당한 부담이 되었습니다.

Airbnb는 위험한 선택에 직면해 있었습니다. 1년 안에 1000명 이상을 고용하거나 극단적인 경우를 처리하기 위한 자동화된 프레임워크를 구축하는 것입니다.

예, 그들은 후자를 선택했습니다.

당시 에어비앤비 제품 매니저인 조나단 골든은 무자비하게 우선순위를 정해야 했습니다. 주요 목표는 엣지 케이스를 처리하고 분류할 자동화된 클라우드 솔루션(백엔드 프레임워크)에 대한 계획을 세우는 것이었습니다.

프레임워크를 갖춘 Airbnb는 빠르게 차단을 해제하고 연간 300%에서 600%로 확장을 계속했습니다. 이 비율은 Airbnb의 초기 기하급수적 성장을 나타냅니다.

그러나 모든 것을 클라우드로 이동하고 워크플로를 자동화하는 것보다 이 예에서 더 많은 제품 개발 관련 정보를 얻을 수 있습니다.

• 먼저 기술적 문제를 수동으로 처리하는 것이 중요합니다. 그렇지 않으면 개발자가 근본적인 문제를 잘 인식하지 못할 수 있습니다.
• 회사는 스케일링 자동화, 로드 밸런싱 등을 적용하기 전에 너무 오래 기다리면 안 됩니다. 제 시간에 하지 않으면 문제가 너무 커져서 극복하기가 훨씬 더 어려워질 수 있습니다.
• 항상 제품 로드맵의 다른 문제에 적용할 수 있는 솔루션이나 프레임워크를 만들려고 노력하십시오. 그렇게 하면 팀이 훨씬 더 민첩해집니다.

2: 보안

도전

이메일 인프라 보안 또는 보안 부족은 조직이 잠재 고객과 효과적으로 커뮤니케이션하는 능력에 직접적인 영향을 미치기 때문에 매우 중요합니다.

제품 개발 팀은 최소 실행 가능한 제품이 나오기 훨씬 전인 초기 단계에서 이 문제를 해결해야 합니다. 하지만 거기서 멈추지 않습니다. 완제품을 다루는 경우에도 정기적인 보안 감사가 우선되어야 합니다.

기밀 정보는 종종 이메일을 통해 교환되기 때문에 보안 침해로 인해 민감한 정보가 노출될 수 있습니다. 이는 평판 손상, 고객 신뢰 상실 및 잠재적인 법적 영향을 포함하여 조직에 심각한 결과를 초래할 수 있습니다.

또한 모든 팀이 잠재적인 보안 위험을 이해하여 암호화 및 보안 프로토콜을 우회할 수 있는 위반을 방지하는 것이 중요합니다. 이러한 위험 중 하나는 사회 공학이지만 다음 섹션 중 하나에서 이에 대해 자세히 설명합니다.

솔루션:

• 암호화
• 보안 프로토콜
• 정기 보안 조치 업데이트

SSL 및 TLS와 같은 보안 프로토콜은 전송 중인 이메일 데이터에 대한 암호화 및 인증 서비스를 제공합니다. 이로 인해 이메일 인프라 제품 로드맵에서 첫 번째 방어선으로 간주될 수 있습니다. 또한 조직은 내부 보안 조치를 정기적으로 검토하고 업데이트해야 합니다.

어떻게?

예를 들어, 소프트웨어를 개발하는 회사는 코드 베이스, git 등에 대한 액세스를 제한하기 위해 엔지니어 및 기타 이해 관계자를 위한 내부 정책을 수립해야 합니다. 액세스 권한.

개발 팀은 일반적으로 목록 권한 원칙을 사용하여 더 높은 수준의 보안을 달성합니다. 즉, 필요에 따라 더 많은 액세스 권한이 부여되며 모든 것에 액세스할 수 있는 사람은 거의 없습니다.

이전에 이동 데이터(전송 중인 데이터)를 암호화하는 SSL 및 TLS에 대해 언급했습니다. 그러나 회사는 유휴 상태의 데이터 암호화를 고려하고 해당 데이터에 대한 다양한 액세스 수준을 설정해야 합니다.

"Pinky 약속, 우리는 당신을 해킹하지 않을 것입니다!"

이것은 다소 부정적인 비즈니스 사례이지만 보안에는 항상 소프트웨어와 사람이라는 두 가지 측면이 있음을 분명히 보여줍니다.

2023년 1월, Mailchimp는 133개 고객의 민감한 데이터를 노출하는 보안 침해(12개월 내 세 번째)를 겪었습니다. 그리고 사회 공학은 사기꾼들이 민감한 정보에 접근하기 위해 사용하는 전략이었습니다.

기본적으로 이는 온라인 사기꾼이 순진하고 경험이 없는 Mailchimp 직원을 사용하여 보호된 데이터에 액세스할 수 있음을 의미합니다. 사기꾼들은 자격 증명을 위해 직원을 피싱하여 시스템 자체가 아닌 사람을 해킹했습니다. 그럼에도 불구하고 약 133명의 클라이언트에 대한 민감한 정보가 노출되었습니다.

결론은 보안의 기술적 측면이 완벽해야 한다는 것입니다. 그러나 동시에 회사는 피싱이나 다른 종류의 온라인 피해자가 되지 않도록 절차를 수립하고 직원을 교육해야 합니다.

3: 신뢰성

도전

신뢰성은 시스템이 시간이 지남에 따라 정확하고 일관되게 작동하는 능력을 결정합니다. 따라서 신제품 개발 프로세스의 다양한 반복 중에 가장 큰 장애물 중 하나입니다.

왜?

안정성이 없으면 사용자는 이메일이 예상대로 전달 및 수신되는지 확신할 수 없으므로 궁극적으로 가치 제안을 파괴합니다. 물론 이것은 이메일 인프라의 경우이지만 여기에는 더 큰 그림이 있습니다.

SaaS에서 최종 제품의 신뢰성은 브랜드의 명성과 전달 능력에 직접적인 영향을 미칩니다. MVP이든 이미 성공한 제품이든 RAM 사용 증가, 사용자 요청 급증, 예기치 않은 인프라 로드 등과 같은 다양한 유형의 장애를 견뎌야 합니다.

해결책:

• 이중화 및 백업 시스템 구현
• 정기 인프라 모니터링

중복성은 서로 다른 위치에 저장된 동일한 데이터의 여러 복사본을 포함합니다. 따라서 하나의 시스템이 실패하면 사용할 백업이 있습니다. 이를 가능하게 하는 기술이 몇 가지 있는데, 특히 로드 밸런싱은 전자 메일이 여러 서버에 분산되어 오류 위험을 줄입니다.

그런 다음 정기적인 인프라 모니터링은 개발자가 실제 문제가 되기 전에 문제를 감지하고 해결할 수 있는 지표를 제공합니다. 이는 모니터링 도구와 정기적인 시스템 검사를 통해 수행할 수 있습니다. 또는 때로는 개발 팀이 개념 테스트 중에 SWOT 분석을 적용하여 최상의 접근 방식을 결정할 수 있습니다.

모니터링에 대해 말하자면 개발자가 모니터링 위에 알람을 구축하는 것이 가장 좋습니다. 예를 들어 다음과 같은 상황에 대해 알람을 설정해야 합니다.

1. 프로세스가 더 많은 메모리를 소비하기 시작하는 경우.
2. 특정 데이터 처리/컴퓨팅 문제가 있는 경우.
3. 500 코드 응답의 경우.

이러한 경보는 사내 아키텍처 지원 및 대기 제품 관리와 관련됩니다. 둘 다 소프트웨어 개발 프로세스 중에 또는 소프트 제품 출시와 함께 설정되어야 합니다.

평이한 영어로 관련 이벤트에 의해 트리거된 알람이 있는 경우 엔지니어는 한밤중에도 바로 그 알람으로 이동해야 합니다.

거인들은 어떻게 했는가

Google 자체는 초기에 안정성 문제를 성공적으로 극복한 제품 디자인 전략의 좋은 예입니다. 인프라는 여러 수준의 중복성을 제공하도록 설계되었습니다. 이를 통해 거대 검색 엔진은 내부 오류가 발생하더라도 사용자 이메일이 예상대로 전달되고 수신되도록 할 수 있습니다.

또 다른 예는 로드 밸런싱 및 백업 시스템을 사용하여 매우 안정적인 이메일 인프라를 구현한 Microsoft입니다. 이러한 조치는 Microsoft가 상당한 성장과 수요 증가에도 불구하고 전자 메일 서비스의 안정성을 높게 유지하는 데 도움이 되었습니다.

하지만 안타깝게도 더 이상 그렇지 않습니다. 제품 수명 주기 동안 Microsoft가 적절한 시장 조사 및 경쟁사 분석을 실행하지 못한 몇 가지 변곡점이 있었습니다. 이에 대한 자세한 내용은 성능 기대치 관리 섹션을 참조하십시오.

4: 상호 운용성

도전

상호 운용성은 이메일 인프라 또는 SaaS 서비스가 다른 애플리케이션과 잘 통합되고 작동할 수 있는 능력을 나타냅니다.

일반적으로 통합에는 다음이 포함되어야 합니다.

1. 고객 관계 관리(CRM)
2. 전사적 자원 관리(ERP)
3. 데이터 저장고

이점은 무엇입니까?

서로 다른 애플리케이션 간에 원활하게 정보를 교환할 수 있는 기능은 회사가 정보에 입각한 데이터 기반 의사 결정을 내리는 데 도움이 됩니다. 또한 제품 관련 프로세스를 간소화할 수 있습니다. 보너스는 높은 상호 운용성 또한 훨씬 더 나은 사용자 경험을 제공한다는 것입니다.

제품 개념을 브레인스토밍할 때 이 측면을 다루어야 한다는 점에 유의하십시오. 그리고 대상 시장에서 사용할 수 있는 것과 통합 옵션을 비교하는 것이 좋습니다.

해결책:

• 개방형 표준
• 플랫폼 간 호환성

개방형 표준은 서로 다른 시스템이 함께 작동할 수 있도록 공개적으로 사용 가능한 사양입니다.

이메일 인프라의 주요 공개 표준에는 SMTP(Simple Mail Transfer Protocol), POP3(Post Office Protocol version 3) 및 IMAP(Internet Message Access Protocol)가 포함됩니다.

호환성과 관련하여 이메일 인프라는 다양한 운영 체제(Windows, macOS 및 Linux)와 다양한 웹 브라우저(Google Chrome, Mozilla Firefox, Safari 등)에서 작동하도록 설계되어야 합니다.

그러나 개방형 표준을 통합하고 플랫폼 간 호환성을 확보하는 것은 어려운 일이 아닙니다. 예를 들어 SMTP를 사용하면 개발자는 종종 특정 조정을 해야 하며 암호화를 추가해야 할 수도 있습니다. 이 수정 사항과 기타 제품별 수정 사항을 쉽게 달성하려면 AWS와 같은 상호 연결된 플랫폼을 사용하는 것이 좋습니다.

마지막으로 개발팀은 소프트웨어가 타사 통합과 원활하게 작동하도록 하는 것과 관련하여 서명, 스팸 솔루션, DNS 레코드 등에 세심한 주의를 기울여야 합니다.

간단히 말해서 이것은 제품 개발 프로세스의 각 단계에서 표준 형식과 프로토콜을 따르는 것으로 귀결됩니다. 그런 다음 엔지니어는 필요한 경우 백엔드 워크플로와 프런트 엔드를 사용자 정의할 수 있습니다.

슬랙을 줄여주세요

Slack이 우리의 협업 방식을 재창조했다고 믿는다면 틀린 말은 아닐 것입니다. 그러나 문제는 그들이 어떻게 했느냐입니다.

Slack이 출시 단계에서 안정적인 솔루션을 가지고 있었다는 사실을 무시합시다. 그리고 좌절한 IT 근로자 무리를 전환시키는 데 성공한 재치 있는 마케팅 전략은 잊어버리자. 여기서 중요한 것은 전환 후 발생하는 일입니다.

우선 슬랙에 들어가기 위한 기준이 매우 낮다. 그러나 상상할 수 있는 대부분의 사용 사례를 다룹니다. 그런 다음 팀을 Slack으로 마이그레이션하는 것은 매우 간단합니다. 사용자 관리는 번거롭지 않으며 통합 목록은 계속 이어집니다…

비즈니스의 규모와 범위에 따라 Jira, Notion, Coda, Google 앱 등을 연결하여 모든 알림 및 데이터 채널을 한 지붕 아래에 둘 수 있습니다. 이 모든 것이 며칠 또는 몇 시간 안에 이루어집니다.

가장 인상적인 점은 Slack 상호 운용성이 거의 설정하고 잊어버린다는 것입니다. 필요한 모든 것을 통합하고 나면 항상 클릭 한 번으로 데이터 또는 통신 소스를 사용할 수 있습니다. 그리고 그 사용자 경험은 경쟁하기 어렵습니다.

5: 성능 기대치 관리

도전

성능 기대치를 관리하는 문제는 제품이 최종 사용자의 요구 사항과 요구 사항을 충족하는지 확인하는 것입니다. 그 때문에 특히 SaaS를 개발할 때 성능 기대치를 사용자 기대치와 동일시하는 것이 안전합니다.

명확하게 말하면 이메일 인프라 제품 또는 모든 SaaS의 성공은 최종 사용자와 대상 고객이 이를 얼마나 잘 인식하는지에 크게 좌우됩니다. 즉, 제품이 사용자 성능 기대치를 얼마나 잘 충족시키는가입니다.

이메일에 대한 의존도가 높아짐에 따라 사용자는 인프라가 안전하고 빠르며 신뢰할 수 있기를 기대합니다. 또한 사용자는 다음을 원합니다.

• 사용하기 쉬운
• 여러 장치에서 액세스 가능
• 이메일 트래픽을 대규모로 처리할 수 있어야 합니다.

해결책:

• 테스트
• 최적화
• 명확한 커뮤니케이션
• 피드백 루프

당연한 이야기지만 정기적인 테스트와 최적화는 모든 제품 개발 프로세스의 필수적인 부분이 되어야 합니다. 사용자 피드백을 수집하기 위한 설문조사, 포커스 그룹, A/B 테스트 수행 등이 포함될 수 있습니다.

명확한 의사 소통은 신뢰와 투명성을 구축하는 데 도움이 되므로 테스트와 밀접한 관련이 있습니다. 종종 통신에는 개발 프로세스에 대한 정기적인 공개 업데이트가 포함되어 사용자에게 인프라 변경 사항을 알리고 사용자가 생성한 성능 문제를 해결합니다.

모든 커뮤니케이션과 테스트는 개발자에게 자격을 갖춘 고객 피드백을 제공하여 개발자의 요구와 기대를 충족하는 데 도움이 됩니다. 여기서 중요한 단계는 주어진 피드백을 제품 개발 프로세스에 통합하는 것입니다.

간단히 말해서 이것은 시스템의 모든 단점을 경계하는 것을 의미합니다. 상품화를 해치지 않고 제품을 개선하는 데 어떤 방법론을 적용해야 하는지 더 잘 이해하기 위해 비즈니스 분석을 수행할 수도 있습니다.

그런 다음 중요한 단계는 모든 결과를 실행 가능한 작업 및 업데이트로 변환하여 소프트웨어를 더욱 간소화하는 것입니다.

그러나 애플리케이션을 테스트하고 모니터링할 때 염두에 두어야 할 사항이 있습니다. 예를 들어 스트레스 테스트는 코드가 느리게 실행되는지 확인합니다. 그러나 어떤 것이 느리게 실행되고 있다는 사실이 업데이트를 필요로 하지 않습니다. 개발 팀은 어떤 업데이트가 성능에 중요한지, 최적의 리소스 사용을 위해 우선 순위를 낮출 수 있는지 확실하게 이해해야 합니다.

거인의 전투

앞서 언급했듯이 이 섹션에서는 Microsoft가 성능 기대치에 실패했을 가능성이 있는 영역을 탐색하여 경쟁업체가 번창할 수 있는 길을 열어줍니다. 여기에는 Apple과 Google이 관련된 약간의 이야기가 있습니다.

2021년 9월 MPP(Mail Privacy Protection)를 출시했을 때 Apple은 이미 이메일 클라이언트 시장 점유율에서 Google을 이겼습니다. 당시 애플의 점유율은 59%에 가까웠고, 구글은 28% 정도였지만 마이크로소프트의 아웃룩은 5% 정도로 훨씬 뒤처졌다.

이제 Microsoft가 펀치를 맞은 이유는 무엇일까요?

답을 찾으려면 과거를 조금 더 들여다봐야 합니다.

Google은 거의 20년 전인 4월 1일에 Gmail을 출시했습니다. 그리고 그것이 만우절 농담이 아니라는 것을 마이크로소프트가 깨닫는 데는 그리 오래 걸리지 않았습니다. Windows의 아버지는 약 10년 동안 우위를 유지하기 위해 열심히 노력했습니다. 그러나 Gmail이 2015년에 시장을 장악하자 Outlook은 대체로 하향세를 보였습니다.

하지만 왜?

그 이유는 실패한 성능 기대라고 주장하는 것이 안전합니다. 기본적으로 Gmail은 더 빠르고 사용하기 쉬웠으며 훨씬 더 간소화된 인터페이스를 제공했습니다. 더 많은 기능과 훨씬 더 큰 저장 공간(당시 Outlook보다 1GB – 500배 더 많음)과 함께 Gmail이 승리한 것은 놀라운 일이 아닙니다.

오늘날로 돌아가 보면 Google이 10년 전의 Microsoft와 유사한 상황에 처할 수 있다는 것은 분명합니다. 이제 실패한 주요 성능 기대치는 추적입니다. 인바운드 이메일의 수가 주어지면 마케팅이든 거래이든 사람들은 이메일 이벤트를 숨기는 것을 선호합니다.

물론 오픈율, 지리적 위치 및 장치를 추적하는 것이 점점 더 어려워지고 있다는 사실은 마케터에게 속쓰림을 안겨줍니다. 그러나 통계에 따르면 이것이 바로 사용자가 기대하는 바입니다.

Apple의 이메일 개발 팀은 초기에 이러한 추세를 알아차렸고 이메일 노이즈를 최소한으로 유지하기 위한 실행 가능한 솔루션을 제공한 최초의 팀 중 하나였습니다. 이러한 종류의 성능 기대치, 모니터링 및 업데이트로 인해 Apple은 가까운 미래에 이메일 클라이언트 공간을 지배할 수 있습니다.

좋은 제품 만들기

지금쯤이면 제품 개발 프로세스의 중요한 문제에 대해 확실하게 이해하셨을 것입니다. 강조하자면 어떤 유형의 제품을 개발하고 있는지는 중요하지 않습니다.

설명된 과제는 틈새 시장과 대체로 제품 개발 주기에 구애받지 않습니다. 아이디어 단계에 있더라도 제품이 안전하고 신뢰할 수 있으며 확장 가능하기를 원할 것입니다. 그런 다음 시작 단계에 도달하면 제품 아이디어 심사 및 검증에서 멈추지 마십시오.

마지막으로, 제품 개발 프로세스에는 모든 단계에서 많은 연구, 분석 및 구현 계획이 필요하다는 점을 기억하는 것이 중요합니다. 좋은 소식은 이 기사가 견고한 로드맵과 집중해야 할 핵심 영역을 제공했다는 것입니다.