Engineering

리뷰 통합 여행 어때? — 상편

김주엽(Groo) / Android Developer여기어때

2023년 6월 2일

안녕하세요 👋🏻

여기어때 모바일 앱 개발을 담당하는 iOS 개발자 토리, Android 개발자 그루입니다. 오늘은 작년 하반기부터 진행하고 있는 통합리뷰 프로젝트에 대해서 여러분께 소개해 드리려 해요.

여기어때에 더 나은 리뷰 시스템을 만들고자 하는 하나의 목표를 가지고 많은 사람들이 함께 노력하고 있는 통합리뷰 프로젝트. 그럼, 지금부터 시작해 볼까요?

1. 통합리뷰 프로젝트가 무엇인가요?

통합리뷰 프로젝트는 파편화되고 다중화된 리뷰 시스템을 통합 하고 체계적으로 바꾸기 위해 진행한 프로젝트에요. 통합리뷰 프로젝트를 한 문장으로 표현해 보았는데, 이 챕터를 다 읽고나서 다시 보시면 조금 더 이해가 되도록 풀어서 설명해 볼게요. 통합리뷰 프로젝트를 잘 이해하기 위해서는 초기와 현재 여기어때의 홈 화면을 비교해 보면 좋을 것 같아요.

여기어때는 모텔 앱에서 시작했어요. 여기어때에 입점하는 숙소들이 늘어감에 따라 새로운 숙소 유형이 생기고, 액티비티, 공간대여, 해외숙소 등의 서비스를 확장해 나가면서 해당 서비스로 이동하기 위한 카테고리도 늘어났어요. 하나둘 카테고리가 늘어나면서 현재는 10개 이상의 카테고리를 다루고 있습니다.

초기 여기어때 홈은 모텔리스트만 있었어요. 현재는 10개 이상의 카테고리를 가지고 있어요.

숙소를 이용한 후에는 리뷰를 작성 할 수 있어요. 이렇게 작성한 리뷰를 리뷰 리스트에서 볼 수 있죠. 여러 개의 카테고리가 생기면서, 카테고리별로 리뷰 리스트 디자인들이 각각 다르게 구현되었으며, 서비스별로 API 도메인을 관리 해야 했어요. 이렇게 되면 새로운 카테고리가 추가 될 때마다 리뷰를 관리하는 채널이 늘어나 게 되어, 관리가 어려워지는 문제가 생기죠. 또한, 리뷰 리스트마다 디자인이 달라, 통일성이 필요했어요.

카테고리가 몇 개 없을 땐 리뷰 유형별로 디자인이 다르거나, API 도메인이 달라도 관리하기 어렵진 않았어요. 하지만 앞으로 여기어때는 서비스를 늘려갈 것이고, 그때마다 관리해야 하는 리뷰 관련 코드, 운영 채널도 점점 많아질 것이기에, 파편화된 리뷰 채널들을 통합할 필요성이 생겼어요. 이로 인해 리뷰관련 코드를 한 모듈에서 관리할 수 있도록 개발하여 관리 포인트를 통합하는 것도 통합리뷰 개발 목표 중 하나였어요. 이 외에도 리뷰 작성에 관련된 이슈들도 대두되었고, 개발 도중에 통일성이 필요한 부분들도 비즈니스 로직을 적립해 나가면서 개발을 이어 나갔어요. 통합리뷰 프로젝트에서 개선하고자 하는 기능들은 다음과 같이 나타내 볼 수 있어요.

통합리뷰 프로젝트에서 개선하고자 하는 기능들

통합리뷰 프로젝트는 전체적으로 리뷰 구조를 통일하는 프로젝트에요. 그렇기 때문에 모듈화한 리뷰 모듈을 따로 생성하여 각기 다른 에러 처리를 위해 각 상황별로 규격을 통일하고, 통일된 디자인 컴포넌트와 Writing Tone Of Voice를 적용하였어요. 신규 기능 중에는 운영 리소스 최소화를 위한 기능들도 있어요. 리뷰 조치 프로세스 재정립하여 법적 리스크를 제거해서, 안정적인 리뷰 운영 체계 수립하는 작업을 진행하였어요. 이 작업은 운영자의 수작업 처리 과정을 자동화하여(블라인드 처리, 메일 발송 등) 운영 업무 효율성 증대시켰어요. 이런 이슈들과 요구사항들을 해결하겠다는 목표를 가지고 통합리뷰 프로젝트를 2022년 8월부터 시작했어요.

여기서 어떤 작업이 되었고, 개발 과정에서 어떤 이슈를 어떻게 해결해 나갔는지 궁금하지 않나요? 이제부터 하나씩 소개해 드릴게요.

2. 지금까지 어떤 변화가 있었나요?

리뷰 관련 영역을 한 번에 통합하고 개편해서 사용자들에게 빠르게 제공할 수 있으면 좋겠지만 현실적으로는 이전 히스토리 파악과 더불어 많은 작업, 그리고 다양한 팀들 간의 협업이 필요했어요. 또한, 사용자들의 피드백과 반응을 지속해서 확인하는 것도 중요했죠.

그래서 저희는 이번 프로젝트를 각각의 Phase로 구분 지어 작업하고 여러 버전에 나누어서 배포하기로 했어요.

Phase 1

먼저 Phase 1에서는 기존에 카테고리별로 나뉘어 있었던 리뷰 리스트, 작성화면을 앞으로 통일해서 사용하기 위해 통합리뷰 리스트, 작성화면을 신규로 개발했어요. 추후에 기존 카테고리들을 통합리뷰로 전환하면 해당 화면을 사용할 것이므로 확장성 있게 구조를 설계하는 것이 중요했죠. 저희가 설계한 상세한 구조는 조금 있다가 챕터3에서 자세히 다뤄볼게요.

이렇게 통합리뷰 리스트, 작성화면을 먼저 구축한 후 저희는 이를 공간대여 카테고리에 가장 먼저 적용했어요. 공간대여는 기존에 리뷰 시스템이 존재하지 않아 다른 카테고리들보다 통합리뷰를 연동하는데 수월했기 때문이에요.

또한, 리뷰 작성 시 이전에 작성하셨던 내용을 저장해 두는 기능을 추가했어요. 다시 접속했을 때 이어서 작성할 수 있어서 꼭 리뷰를 한 번에 작성해야 한다는 부담감을 덜었어요. 다른 사용자들이 나중에 숙소를 이용할 때 도움이 될 만한 내용을 천천히 고민해서 작성해 주세요 😉

Phase 2

회색 모자이크는 제휴점, 사용자 정보 노출로 인해 모자이크 처리를 한 것으로 마스킹 처리와는 무관합니다.

스토어 정책 수준이 높아지면서 리뷰 시스템을 제공하는 앱에서는 리뷰 신고, 숨김 등의 기능 제공을 권장하고 있어요.

그래서 저희는 Phase 2에서 통합리뷰를 고도화해 리뷰 신고, 숨김 기능을 제공하기로 했어요. 또한, 자체 CMS(Content Management System)도 함께 구축하여 기준에 맞지 않는 리뷰나 사진을 관리자가 판단하여 블라인드 처리하고, 리뷰 작성자에게 삭제 또는 수정 요청을 하도록 하는 시스템을 도입했어요. 위 기능들은 평소에는 거의 사용하지 않겠지만, 여러분이 믿을 수 있고 숙소 선택에 도움이 되는 리뷰 시스템을 제공하도록 저희가 더 노력할게요.

Phase 3

Phase 1, 2에서 통합리뷰의 기반을 잘 구축한 덕분에 이제는 본격적으로 기존에 리뷰 시스템이 존재했던 카테고리들도 통합리뷰로 전환을 할 수 있게 되었어요. 그 중에서도 해외숙소 카테고리를 Phase 3에서 먼저 전환하기로 했어요. Phase 1 당시에 미리 만들어 두었던 리스트, 작성 화면을 활용하면 되어서 신규로 개발해야 하는 화면은 없었고 통합리뷰 시스템에 잘 연동만 해주면 되었어요. 이 부분이 바로 Phase 1 당시에 저희가 확장성을 중요하게 생각했던 이유예요.

이렇게 통합리뷰 시스템으로 연동을 마친 후 저희는 기존에 해외숙소 전용 리뷰 관련 코드를 모두 제거했어요. 이처럼 저희는 카테고리를 하나씩 통합리뷰로 전환하면서 레거시 코드를 제거하고 있어요. 앞으로 리뷰 관련 코드를 일원화하여 관리하겠다는 목표에 한 걸음 더 다가갔어요.

3. 어떤 고민을 하면서 개발했나요?

이번 통합리뷰 프로젝트는 다양한 카테고리의 리뷰 시스템을 하나로 통합하는 작업이기에, 어떻게 잘 통합할까를 고민하면서 개발을 진행했어요. 이번 챕터에서는 저희가 어떤 생각을 가지고 작업했고 또 그 결과는 어땠는지 다뤄보려고 해요.

모듈화

모듈화가 무엇일까요? Android, iOS에서 모듈화는 같은 유형의 코드 조각을 따로 분리하여 관리하는 것을 뜻해요. 이를 통해 코드를 쉽게 관리하고 유지보수할 수 있어요. 특히, 코드의 재사용성과 앱의 성능을 높일 수 있는 장점이 있어 모듈화 기법을 많이 채택하고 있어요.

모듈화를 이해하기 위한 예시

위의 사진은 간식 선반이에요. 하나 둘 씩 간식을 쌓을 때는 내가 어디에 어떤 간식을 두었는지 기억할 수 있어요. 하지만 시간이 지나서 선반에 많은 간식이 쌓이고 여러 사람이 간식 선반을 함께 사용한다면 어떤 간식이 어디에 있는지 찾기 어려울 거에요. 그러나 바구니를 활용하여 종류별로 간식을 분류하면 똑같은 간식을 다시 사지 않게 되고 자신이 원하는 간식을 쉽고 빠르게 가져올 수 있어요.

프로그램에서는 모듈을 하나의 바구니로, 특정 소스코드는 그 안의 간식으로 비유할 수 있어요. 여러 사람이 함께 작업하는 프로젝트에서는 이런 구조가 퍼포먼스 향상에 많은 도움이 돼요. 그래서 이번 통합리뷰도 하나의 모듈로 따로 관리하기로 했답니다.

Android 모듈화

Android는 GBS(Gradle Build System)을 사용하여 모듈화를 진행했어요. GBS는 애플리케이션, 라이브러리, 동적 기능 모듈 등 다양한 유형을 지원해요. 즉, 아래처럼 다른 모듈에서 통합리뷰 모듈을 의존하도록 설계했어요.

이로써 여기어때의 통합리뷰 관련 코드는 통합리뷰 모듈 한 곳에서 관리를 할 수 있게 되었어요. 다른 모듈에서는 통합리뷰 모듈에 구현된 리뷰 관련 코드를 참조만 하면 되었죠.

iOS 모듈화

iOS 파트도 Android 파트와 마찬가지로 모듈화된 프로젝트에서 개발하고 있어요. iOS에서 모듈화는 CocoaPods와 Carthage, Swift Pakcage Manager 등의 패키지 관리 도구를 사용하여 구현해요. CocoaPods와 Carthage, Swift Package Manager는 외부 라이브러리를 가져오는 데 사용되고, 프로젝트에서 작성한 코드를 모듈로 분리하는 것은 Xcode의 Target 및 Framework 기능을 사용하여 구현해요.

그러면 iOS 파트에서는 어떤 관리 도구들을 이용해서 모듈화하고 있을까요?

Tuist

저희는 Tuist 를 이용해서 모듈들을 관리하고 있어요. Tuist는 소스파일을 기반으로 실행파일을 생성, 관리하는 방식으로, 모듈/파일의 버전을 간편하게 관리하기 위해 이번 연도부터 도입한 실행 관리 툴이에요. Tuist는 여러 버전을 간편하게 관리하도록 도와주기도 하고, 추가로 간편하게 모듈화할 수 있는 기능을 가지고 있어요.

Tuist는 CocoaPod을 지원하지 않고 애플이 지원하는 Swift Package Manager를 사용해야 하기에, 여기어때 프로젝트에서는 Swift Package Manager를 사용하고 있어요. Tuist설정 파일을 열고 몇 가지 설정만 해주면 간편하게 모듈을 생성할 수 있어요. 이 툴을 이용해서 리뷰 모듈을 간편하게 생성해서 사용하고 있답니다. 현재는 공간대여, 해외숙소에서 통합리뷰 모듈을 사용하고 있어요.

코드 최신화

통합리뷰 프로젝트 이전까지는 여기어때 앱의 리뷰 영역에 큰 변화가 없었는데요. 그러다 보니 Android, iOS 모두 초기에 작성해 둔 코드가 지금까지 그대로 유지되어 왔어요. 그래서 이번 기회에 코드도 최신화해서 작성하려고 노력했어요.

Android 코드 최신화

이 프로젝트는 작년에 시작하였고, 전체적인 UI는 XML로 이미 구현한 상황이었어요. 그런데 Android 파트에서는 올해부터 Compose와 MVI 패턴을 도입해 신규화면을 개발하기 시작했고, 이전에 XML로 작성된 UI도 조금씩 전환하고 있어요. 특히 공통으로 사용하는 일부 UI 컴포넌트는 AbstractComposeView를 활용하여 기존의 XML과 혼합하여 사용할 수 있도록 변경했어요.

/**
 * XML이 Compose로 모두 전환되면 GCRecommendView 클래스는 제거하고
 * 아래의 RecommendView 컴포저블만 활용합니다.
 */
class GCRecommendView @JvmOverloads constructor(
    context: Context,
    attrs: AttributeSet? = null,
    defStyleAttr: Int = 0,
) : AbstractComposeView(context, attrs, defStyleAttr) {

    @Composable
    override fun Content() {
        GCTheme {
            RecommendView()
        }
    }

    ...
}

@Composable
fun RecommendView() {
    ...
}

처음에는 XML 베이스 코드에 Compose가 잘 녹여질 수 있을까 고민을 했었지만, 큰 문제 없이 통합리뷰도 Compose에 첫발을 내디딜 수 있었어요.

Android 파트에서는 지금처럼 공통으로 사용할 수 있는 UI 컴포넌트를 먼저 Compose로 전환하면서 기존 XML 방식의 UI를 Compose로 모두 전환하는 것을 목표하고 있어요.

iOS 코드 최신화

여기어때 과거 — 현재 기술스택

iOS 파트에서는 현재 ReactorKit을 이용해서 MVVM패턴으로 개발하고 있고, UI는 SnapKit이라는 프레임워크 이용해서 Autolayout을 잡아주고 있어요. 그러나, 과거 코드들은 MVC패턴을 사용하고 있고, Autolayout도 Frame 기반의 프로그래밍 방식(Frame-Based Layout)을 이용해서 조정해 주는 곳이 많았어요. 기존 리뷰에 있는 코드들도 과거의 기술스택을 사용하여, MVC패턴과 Frame기반으로 Autolayout을 잡아주고 있었어요. 그래서 ReactorKit을 이용해서 MVVM패턴으로 리팩토링 해주고, SnapKit을 이용해서 Autolayout을 잡아주는 리팩토링을 진행하였어요.

그리고 과거에 UITableView는 DataSource 또는 RxDataSource를 이용해 구성하고 있었어요. iOS 파트에서는 새로운 피쳐가 생길 때 애플에서 권장하고 있는 UITableViewDiffableDataSource를 사용하고 있기 때문에 RxDataSource를 사용하는 부분을 없애고, UITableViewDiffableDataSource를 이용해서 리스트를 업데이트 해 주었어요.

이렇게 코드를 최신화하면서 기존 코드와 통일성을 맞추는 작업을 진행했어요. 코드를 최신화 하면서 RxDataSource를 사용하다가 UITableViewDiffableDataSource를 처음 이용해 보았는데, 파트분들에게 모르는 부분을 공유하고 해결해 가는 과정이 좋았어요.

앞으로는 구조가 간단한 화면의 경우 swiftUI를 도입하여 기존 코드를 리팩토링하거나, 개발해 볼 예정이에요.

다이얼로그

다이얼로그는 여기어때에서 자주 보이는 창이에요. 해당 창에서 사용자는 여러 버튼을 선택할 수 있어요. 이번에 통합리뷰에서 사용하는 다이얼로그에는 특히 버튼이 많았는데요. 리뷰 신고, 수정, 삭제 등 앱에서 지원하는 기능이 많아지다 보니 저절로 다이얼로그 내 버튼의 수도 그에 맞게 늘어났어요. 또한, 다이얼로그는 여러 화면에서 공통으로 사용되다 보니 중복 코드도 많이 만들어질 수 있었죠. 그래서 Android, iOS 모두 이를 신경 써서 개발하기로 했어요.

Android 다이얼로그

Android는 여러 화면에서 공통으로 사용하는 다이얼로그가 있다면 싱글톤 클래스인 DialogManager에 해당 다이얼로그를 구현하는 메서드를 만들어 두고 각 화면에서 이 메서드를 호출하는 구조로 되어 있어요. 해당 메서드에서는 다이얼로그 구현에 필요한 정보들을 파라미터로 전달받은 후 데이터의 상태에 따라서 특정 버튼을 추가 할지 말지 결정해요.

override fun showReviewDialog(
    context: ComponentActivity,
    status: Status?,
    isOwner: Boolean,
    isEditable: Boolean,
    onClickReport: () -> Unit,
    onClickEdit: () -> Unit,
    ...
) {
    GlobalDialog.Builder(context).apply {
        // 리뷰 신고
        if (isOwner.not() && status == Status.ACTIVE && isHidden.not()) {
            addPositiveButton(R.string.review_report_toolbar_title, onClickReport)
        }

        // 리뷰 수정
        if (isOwner && isEditable) {
            addPositiveButton(R.string.review_modify, onClickEdit)
        }
        
        ...
        
    }.show()
}

위 같은 구조 덕분에 다이얼로그를 호출하는 곳에서는 현재 상황에서 어떤 버튼을 추가해야할 지에 대한 고민을 덜 수 있게 되었고 중복 코드도 많이 제거할 수 있었어요.

dialogManager.showReviewDialog(
    context = this,
    status = status,
    isOwner = isOwner,
    isEditable = isEditable,
    onClickReport = {
        viewModel.getReviewReportability(reviewId)
    },
    onClickEdit = {
        ReviewWriteActivity.startActivityForModify(this, serviceKey, reviewId)
    }
    ...
)

iOS 다이얼로그

iOS는 다이얼로그를 ReviewDialogManager 클래스를 만들어서 관리하도록 했어요.

public protocol ReviewDialogInterface {
    static var shared: ReviewDialogInterface { get }
    func showModifyReviewDialog(modifyHandler: (() -> Void)?,
                                deleteHandler: (() -> Void)?,
                                cancelHandler: (() -> Void)?)
     ...
}

public class ReviewDialogManager: ReviewDialogInterface {
    public static let shared: ReviewDialogInterface = ReviewDialogManager()
    
    public func showModifyReviewDialog(modifyHandler: (() -> Void)?,
                                       deleteHandler: (() -> Void)?,
                                       cancelHandler: (() -> Void)?) {
        
        GlobalDialog(title: dialogTitle,
                     buttons: dialogButtons,
                     isHardVertical: true)
        { [weak self] index in
           if index == 0 {
                modifyHandler?()
           } else if index == 1 {
                deleteHandler?()
           } else if index == 2 {
               cancelHandler?()
           } 
        }.showDialog()
    }

    ...
}

ReviewDialogManager는 여러 다이얼로그를 모아두고, 다이얼로그 인터페이스를 채택한 클래스예요. ReviewDialogInterface라는 프로토콜이 정의되어 있으며, ReviewDialogManager 클래스가 이 프로토콜을 준수하도록 구현했어요. ReviewDialogManager에서는 상황에 맞는 다이얼로그를 미리 만들어 두고, 버튼을 눌렀을 때 동작을 해당 페이지에서 받도록 했어요. 핸들러를 전달받도록 했는데, 전달받은 핸들러로 상황에 맞는 행동을 취할 수 있도록 한 거에요.

ReviewDialogManager는 싱글턴 패턴으로 구현하여 모든 객체에서 이 인스턴스에 접근할 수 있도록 했어요.

ReviewDialogManager.shared.showModifyReviewDialog(modifyHandler: { [weak self] in
                                          self?.modifyReview()
                                       },
                                       deleteHandler: { [weak self] in
                                          self?.deleteReview()
                                       },
                                       cancelHandler: { [weak self] in
                                          self?.cancelDialog()
                                       })

그래서 위 코드처럼 shared를 이용해서 여러 모듈의 파일들에서 사용할 수 있어요. 이 ReviewDialogManager 클래스를 시작으로, 다른 다이얼로그들도 모아둔 모듈을 만들어서 간편하게 사용할 수 있도록 만들어 보고 싶네요.

리뷰 셀

통합리뷰 셀은 리뷰 내용과 작성자를 표시해 줘요. 현재까지 작업 된 공간대여, 해외숙소의 통합리뷰 셀이 동일한 UI이면 좋겠지만 해외숙소 플랫폼에서 유입되는 리뷰인 경우 해당 포맷에 맞게 UI를 구성해야 했어요. 해외숙소의 리뷰가 그것이에요. 해외숙소 고객들에게 맞는 UI가 필요했어요.

하단의 두 셀은 각각 공간대여/해외숙소에서 볼 수 있는 여기어때 자체 리뷰와 해외숙소에서 볼 수 있는 파트너 리뷰에요.

그래서 여기어때의 통합리뷰는 두 가지 종류로 나뉘게 되었는데요. 하나는 좌측의 여기어때 자체 리뷰 그리고 또 다른 하나는 우측의 파트너 리뷰입니다. 통합리뷰 셀인 만큼 두 종류의 셀이 크게 다른 부분이 없도록 디자인 되어있어요. 이 셀들을 구성하는 사진과 라벨들은 받는 데이터에 따라 노출 여부가 달라지기도 해요. 닉네임 하단의 리뷰 작성 정보, 리뷰 제목과 번역 보기 기능 등 한 쪽에서만 제공하는 기능이 있어요.

이 두 종류의 리뷰 형태는 supplierKey라는 키값을 이용해서 구분 짓고 있어요. Android에서는 두 종류의 리뷰 셀을 각각 구현했어요. 이 supplierKey에 따라서 리뷰 셀을 구별해서 보일 수 있도록 했어요. iOS에서는 셀을 따로 나누지 않고, 통합리뷰 셀에서 supplierKey를 받아 따라 일부 UI 설정을 바꾸어 주도록 했어요.

이 외의 통합리뷰 셀들은 공간대여, 해외숙소의 여기어때 리뷰에 사용하고 있고, 숙박에도 사용할 예정이에요.

리뷰 리스트, 작성 화면

통합리뷰는 하나의 화면을 다양한 카테고리에서 함께 사용할 것이기 때문에 확장성이 매우 중요하다고 앞에서도 여러 번 강조했어요.

그래서 저희는 앱에서의 하드코딩을 최소화하고 사용자에게 보이는 화면의 정보는 최대한 서버로부터 동적으로 전달 받아 보이도록 했어요. 카테고리별로 문구 또는 사진을 유동적으로 다르게 노출하고 싶다는 요구사항이 생기더라도 이를 바로 대응할 수 있기 때문이죠.

{
    "code": 200,
    "data": {
        ...
        "text": {
            "pointTooltip": "사진 첨부하고 800P 더 받아가세요!",
            "nudgingTitle": "공간 리뷰를 남겨주세요.",
            "textPlaceholder": "다른 게스트들이 공간을 이용할 때 도움이 될 수 있도록 느낀 점을 적어주세요.",
            "abusingNotice": "이용한 공간과 상관없는 사진이나 리뷰는 안내 없이 삭제하거나 포인트를 회수할 수 있어요.",
            "uploadingImageGuide": "공간의 분위기를 느낄 수 있도록\n여러 각도에서 찍은 사진을 올려주세요."
        },
    }
    ...
}

또한, 아래처럼 각 화면 별 스택 구조로 UI 셀을 구분 지어 관리했어요.

위 같은 구조 덕분에 디자인 수정이나 신규 셀을 추가해달라는 요구사항이 오더라도 수정이 필요한 셀의 코드만 최소한으로 변경하여 그 이외의 셀에는 영향을 주지 않은 채 쉽고 빠르게 대응할 수 있어요.

디자인 시스템, UX Writing

올해 초부터 여기어때에서는 디자인 시스템을 점진적으로 도입하고 있어요. 저희는 이를 YDS(Yeogi Design System)라고 부릅니다. YDS에는 Foundation 영역의 Typography, Color를 시작으로 Components 영역의 Badge, Button 등 앱 내 다양한 UI 요소를 시스템화하고 있어요.

여기어때 디자인 시스템

통합리뷰도 역시 YDS를 기반으로 개발하였어요. Android, iOS 모두 Typography, Color 같은 경우 해당 값들을 상수로 정의해 두어 필요한 곳에서 쉽게 접근하여 사용할 수 있도록 했어요.

또한, 그동안 리뷰 관련 화면들이 여러 영역으로 나뉘어 있었다 보니 Writing Tone Of Voice도 규칙적이지 못했어요. 그런데 이번에 UX 라이터, UX 디자이너, PO 분들께서 사용자에게 더 친화적이고 이해하기 쉬운 문구가 무엇일지 지속적으로 고민하고 논의해 주신 덕분에 이번 프로젝트에서 이 부분도 함께 개선될 수 있었어요.

이번 글에서는 통합리뷰 프로젝트를

왜 진행했는지
어떤 기능이 추가되었는지
어떤 고민을 하면서 개발했는지

다뤄봤어요.

프로젝트를 진행하면서는 지속해서 커뮤니케이션해야 하고, 그 과정에서 여러 고민을 하게 돼요. 통합리뷰 프로젝트 도중에도 여러 협의 사항이 생겼었는데요. 통합 리뷰프로젝트에서는 어떤 커뮤니케이션이 일어났고, 어떤 이슈들을 해결해 나갔을까요? 다음 편에서 계속됩니다!

리뷰 통합 여행 어때? — 하편

이전 글에서는 통합리뷰 프로젝트가 어떤 것인지, 어떤 고민을 해서 통합리뷰프로젝트를 개발했는지 살펴봤어요.techblog.gccompany.co.kr