[SWJungle] 나만의 무기 만들기 개인 회고

무엇을 했나요?

투두리스트와 펫 육성 게임이 혼합된 어플리케이션을 만들었다. 투두를 달성하면서 모은 게임머니와 경험치로 펫을 진화시키거나 아이템을 구매하여 마이룸을 꾸밀 수 있다. 또, 인증샷을 올려서 할일을 확인받고 친구의 룸에 놀러가거나 방명록을 남기는 소셜 기능도 있다.

앱 개발을 위해 크로스플랫폼 개발 프레임위크인 Flutter를 사용했다. 서버는 NestJS, DB는 PostgreSQL 사용했고 ORM은 TypeORM을 썼다. 이외로는 Socket IO, Docker, EC2 가 아키텍처에 포함되었다.

나만무 이전 주특기 기간에 Spring을 했기 때문에 초반에는 하나의 기능에 대해 백, 프론트 모두 코드를 작성했지만 후반부로 갈수록 프론트에만 집중했던 것 같다.

Kakao OAuth 기반 로그인

로그인 같은 기능에 시간 들이지 말라는 경고 아닌 경고를 많이 들었지만.. 초반 코드를 잘못 짜는 바람에 시간 소모가 많았던 것 같다. Flutter를 위한 KakaoSDK로 디바이스와 카카오 서버와의 연결만으로 인증을 처리하도록 했는데, 이 결과 서버와 디바이스 간의 인증 로직이 누락되었다. 이를 해결하기 위해 Redirection 방식으로 인증을 처리하도록 다시 코드를 작성했다.

1. 사용자는 앱에서 카카오 계정 정보를 입력하고 로그인 버튼을 누른다.
2. 카카오 서버로 계정 정보가 전송되고, 로그인이 성공하면 서비스 서버 (우리의 Nest서버)로 인가 코드가 날아온다.
3. 서비스 서버는 인가 코드를 다시 카카오 서버로 보내어 유저를 식별하는 ID값을 전달받는다. 이를 DB에서 조회하여 유저인 경우 JWT 토큰을 발급, DeepLink를 통해 앱으로 리디렉션한다. 유저가 아닌 경우 access denied 메시지를 전달한다.
4. 앱은 전달받은 토큰을 secured storage에 저장한다. access denied일 경우 회원가입 페이지로 이동한다.

이렇게 하면 다음 로그인 시에는 JWT 토큰을 이용해 서비스 서버와 직접 통신할 수 있다. (토큰이 만료되지 않은 경우) 카카오디벨로퍼스에서 두 방법 모두에 대해 상세히 문서를 정리해두고 있어서 코드를 짜는 것 자체는 크게 어렵지 않았는데, 웹에서 앱으로 리디렉션하는 것이나 카카오 서비스 자체를 사용하기 위해 설정해야 하는 키값 등 자잘한 부분에서 미숙한 점이 많아 오래 걸렸던 것 같다.

• 안드로이드의 경우 앱 키를 등록해야 한다. 여러 명이 개발중이라면 모두의 앱 키를 카카오디벨로퍼스의 내 애플리케이션 > 플랫폼 > 안드로이드에 등록해야 정상적으로 사용할 수 있다. (디버그 모드 기준, 릴리즈는 아직 모르겠다.)
• iOS의 경우 번들 아이디 하나를 등록할 수 있다. 그런데 여러 명이 개발할 경우 각각의 번들 아이디가 다르기 떄문에(고유하도록 애플이 제한하고 있다), iOS는 현재까지 나의 판단으로는 한 명만 기능을 테스트할 수 있는 것 같다.
• 딥링크를 이용하기 위해서는 UniLink 라이브러리를 사용할 수 있다. 로그인 페이지가 로드될 때 deeplink listen을 시작하고, 웹에서 앱으로 리디렉션이 완료되면 cancel하는 방식으로 구현했다.

UI가 그려지기 이전에 로그인 과정이 수행되고, 로그인 상태에 따라 메인화면, 로그인 화면, 회원가입 화면 등 서로 다른 화면을 그려야 했기에 AuthService라는 ChangeNotifier 상속 클래스를 만들어 사용했다. Provider 라이브러리에서 제공하는 기능인데, 특정값이 변경되면 관련 UI가 모두 재빌드될 수 있도록 notify한다.

MainPage & Navigator

상단 appbar와 하단 navbar로 이루어져 클릭 시 다른 페이지로 내비게이션되는 레이아웃을 만들었다. 처음에는 할일, 상점, 마이룸 등 내비게이션 바를 이루는 각 페이지마다 Scaffold 위젯으로 만들었다. 그러나 이렇게 하면 각 페이지의 입장에서는 '자신이 몇 번째 내비게이션 메뉴인지를 알 수 없기 때문에' 현재 페이지에 해당하는 메뉴의 색을 하이라이팅하지 못하는 문제가 발생했다. 물론, 페이지마다 하이라이팅이 하드코딩된 내비게이션 바를 갖고 있는 방법도 있다. 할일 페이지의 navbar에는 '할일' 아이콘을 하이라이트하고, 마이룸 페이지의 navbar는 '마이룸'을 하이라이트한다던지.

하지만 전역적으로 현재 어떤 페이지를 보여주고 있는지 인덱스값 하나만 가지고 있으면 이를 기준으로 navbar 상태를 관리할 수 있다. 따라서 상단 appbar와 하단 navbar를 두고, 내부 body에 해당하는 페이지만 상태로 관리하며 갈아끼우는 방법을 택했다.

class _MainPageState extends State<MainPage> {

    // ....

    @override
    Widget build(BuildContext context) {
    AppNavigator nav = context.watch<AppNavigator>();
    final List<AppPage> bottoms = nav.BOTTOM_PAGES;
    final List<AppPage> appbars = nav.APPBAR_PAGES;

    final AppPage curr = nav.current;

    // * ==== Trigger Login Event ==== * //
    context.read<UserInfo>().initEvents();

    return Scaffold(
        resizeToAvoidBottomInset: false,
        // * ======= APPBAR ======= * //
        appBar: MyAppBar(
        leading: nav.pushback,
        title: Text(nav.title ?? curr.label),
        actions: appbars
            .map(
                (each) => each.toAppbarWidget(
                // 앱 바 아이콘 클릭시 해당 인덱스로 변경
                onPressed: () => nav.push(each.idx),
                child: each.icon,
                ),
            )
            .toList(),
        ),
        // * ======= BODY ======= * //
        body: Builder(
          // 빌더 함수 콜
          builder: (context) => curr.builder(context),
        ),
        bottomNavigationBar: nav.isBottomSheetPage
            ? // ... navbar 위젯
            : null,
        );
    }
}

메인 페이지의 빌드 메소드는 위와 같다. 각 페이지의 아이콘, 이름, 페이지 빌더 함수를 일종의 메타데이터로 묶어서 내비게이션을 담당하는 상태 관리 클래스가 가지고 있다가, 사용자의 액션에 따라 서로 다른 페이지를 보여주는 방식이다.

final AppPage _todo = AppPage(
    idx: AppRoute.todo,
    label: "할일",
    icon: Icon(Icons.check_box_outlined),
    builder: (context) => TodoPage(),
);

class AppNavigator extends ChangeNotifier {

    AppNavigator() {
        // 초기 내비게이션 상태
        _stack.add(_idx);
    }

    // * ====== navigation status ====== * //
    List<int> _stack = [];
    int _idx = 2; // 홈 페이지

    // 현재 페이지 제목을 지정
    String? _title;
    String? get title => _title;
    set title(String? val) => _title = val;

    AppPage get current => ALL_PAGES[_idx];
    bool get isBottomSheetPage => _idx < 5 && _stack.length < 2;
    int get idx => _idx;

    String? _argument;
    String? get arg => _argument;
    set arg(String? val) {
        _argument = val;
        notifyListeners();
    }


    // * ====== navigator methods ====== * //
    void navigate(AppRoute route, {String? argument, String? title}) {
        _argument = argument;
        _title = title;

        if (route.index != _idx) {
            _stack = [];
            _idx = route.index;
            _stack.add(route.index);
        }
        notifyListeners();
    }

    void push(AppRoute route, {String? argument, String? title}) {
        _argument = argument;
        _title = title;

        if (route.index != _idx) {
            _idx = route.index;
            _stack.add(route.index);
        }
        notifyListeners();
    }

    void pop({String? argument, String? title}) {
        _stack.removeLast();
        _idx = _stack.isEmpty ? 2 : _stack.last;
        _argument = argument;
        _title = title;
        notifyListeners();
    }
}

단순히 이동만 하는 페이지도 있었던 반면, 뒤로가기 버튼을 누르면 이전 페이지가 나와야 하는 경우도 있었다. 이를 위해 stack을 두어서 push, pop 메소드를 사용할 수 있도록 했다. 다만 사용자가 이동할 수 있는 케이스를 많이 테스트해본 것은 아니라서.. 과연 현재 코드로 모든 내비게이션을 구현할 수 있는지, 또 처리되지 못한 예외 케이스들은 없는지 충분히 알기 어려웠다는 아쉬움이 있다. 시간적 여유만 있다면 push, pop에 해당하는 UI 모션까지도 구현해 보고 싶은 부분이기도 하다. (+ Navigator 2.0)

App Event Service

사용자의 액션에 따라 이벤트를 발생시키고, 스트림을 통해 순차적으로 처리하는 이벤트 관리자 클래스를 구현했다. 앱 실행 시 하나만 있으면 될 것이라는 판단으로 static 클래스로 구현했고, 백그라운드에서 지속적으로 이벤트 발생을 구독하고 있어야 하므로 stream을 활용했다. 처음에는 ChangeNotifier + List<Event> 으로도 구현할까 싶었는데, 스트림이 메인 UI 로직과 이벤트 로직을 분리할 수 있어 코드 작성이 더 편했기 때문에 이 방법을 택했다. 또, 나중에는 소켓으로 오는 알림에 대한 이벤트 역시 이곳에서 처리되도록 구현했기 때문에 스트림이 적절했다고 생각한다.

초반에 이벤트 관리자 클래스를 구현했던 것은 뷰모델과 뷰모델 간의 통신을 조금 더 쉽게 하기 위해서였다. (비록 그렇게 사용되지는 않았다.) 할일 하나를 체크하면 다음과 같은 일이 벌어진다.

1. 서버로 할일 체크 api를 보낸다.
2. 서버는 해당 할일의 todo_done 필드를 true로 바꾸고, 체크된 할일이 오늘의 첫 할일인지 확인한다. 첫 할일인 경우 유저의 캐시를 100 올리고, 그렇지 않으면 10 올린다. 변경된 유저의 캐시 상태를 응답으로 반환한다.
3. 앱의 TodoViewModel은 응답을 받아 List<Todo>의 해당 Todo 객체의 todoDone값을 변경하고 notifyListeners();를 호출하여 관련 위젯을 재빌드한다. 그리고 사용자 정보를 담고 있는 상태관리 클래스인 UserInfo의 userCash 필드를 업데이트한다.

이 과정 중 TodoViewModel과 UserInfo간의 통신이 이벤트를 통해 이루어질 수 있지 않을까? 라는 생각이 있었다. UserInfo 역시 사실상 유저 정보를 담고 있는 뷰모델로도 볼 수 있기 때문에 각 클래스가 생성될 시 이벤트 스트림을 구독시켜두고 통신하면 될 것 같았다. 하지만 뷰모델끼리의 결합도가 증가하고, MVVM 아키텍처 원칙상 뷰모델과 뷰모델 간의 직접적인 통신은 지양하고 있기 때문에 결국 하위 뷰에 해당하는 TodoPage에서 양쪽의 메소드를 호출하는 쪽으로 코드를 수정했다.

대신, 모달을 띄우기 위해 이벤트 클래스를 사용했다. 만약 첫 할일을 달성한 경우 위 과정이 마무리되고 난 후 '첫 할일 달성!' 모달이 떠야 했다. 이를 TodoPage의 뷰에서 담당할 수도 있지만, 만약 그 사이에 사용자가 다른 페이지로 넘어가면 모달이 뜨지 않게 된다. 효과적으로 처리하기 위해, 유저 캐시를 업데이트 한 후 UserInfo 쪽에서 FirstTodoDone 이벤트를 발행하고, 이를 MainPage 클래스에서 구독하고 있다가 모달을 띄우도록 처리했다.

class _MainPageState extends State<MainPage> {

    StreamSubscription<Event>? sub;
    final Queue<Event> _eventq = Queue<Event>();
    bool _waiting = false;

    @override
    void initState() {
        super.initState();
        requestNotificationPermission();

        // * ==== Event Listener ==== * //
        sub = EventService.stream.listen((event) async {
            String? message = event.message;
            EventType type = event.type;

            if (type.target == 'socket') {
                // 소켓의 경우 즉시
                type.run(context, message: message);
            } else if (type.target == 'ui') {
                // UI라면 큐에 쌓기
                _eventq.add(event);
                if (!_waiting) {
                    await _nextEvent();
                }
            }
        });
    }

    Future<void> _nextEvent() async {
        while (_eventq.isNotEmpty) {
            _waiting = true;
            Event event = _eventq.removeFirst();
            String? message = event.message;
            EventType type = event.type;

            bool? completed = await type.show(context, message: message) as bool?;
            await Future.delayed(Duration(seconds: 1)); // 이벤트 사이 간격 조정
            _waiting = false;
        }
    }

    @override
    void dispose() {
        if (sub != null) sub!.cancel();
        super.dispose();
    }
}

// user_info.viewmodel.dart
// 첫 투두 체크 이벤트
void _onTodoReward(int prevUserCash) {
    int reward = _userCash - prevUserCash;
    if (reward == RewardService.FIRST_TODO_REWARD) {
        EventService.publish(Event(
            type: EventType.onFirstTodoDone,
        ));
    }
}

실제로 이벤트를 run, show 하는 부분은 enum 클래스인 EventType의 extension을 만들어 처리했는데, Event 객체 안에 Future<bool> 타입으로 실행될 함수를 넣어 두었으면 (AppPage 객체 안에 빌더 함수를 넣어 둔 것처럼) 조금 더 깔끔한 코드 작성이 되었을 것 같다. 플러터, 앱개발, MVVM 모두 미숙한 부분이 많아 변수명이나 폴더구조가 비일관적인 부분도 많고, 불필요한 코드도 많았다. 조금 더 꼼꼼하게 생각하고 테스트해보면서 코드를 짜 보자.

무엇을 느꼈나요?

Frontend & App

• 아키텍처를 미리 적용하지 말자. 정글 이전 했었던 코틀린 개발에서 MVVM을 시도했다가 어려움을 겪은 적이 있었다. 이번에는 잘 써보고 싶단 욕심에 초기에 너무 커다란 아키텍처를 염두에 두고 개발을 시작한 것이 나뿐만 아니라 팀의 생산성을 도리어 저하시키는 요인이 되지 않았나 싶다. 이것저것 필요하겠지 싶어 클래스를 미리 만들어두었는데, 실제로는 그사이에 요구사항이 변경되거나, 더 좋은 방법을 찾아 쓰지 않게 된 경우가 많았다. 미리 짜두지 말자. 우선 가장 간단하고 쉬운 방식으로 기능을 개발하고, 천천히 붙여나가는 것이 좋다. 이번 프로젝트 같은 경우에는, 화면의 UI빌드를 담당하는 뷰, 전역 상태관리가 필요한 경우에 한해 ChangeNotifier 상속한 별도 뷰모델, 서버 API 전송시 URI, Header값 관리를 담당하는 static class, 데이터 타입을 담는 Model 정도면 좋았던 것 같다.
• 앱개발과 모바일 UI/UX에 대해 조금 더 공부해보자. 개발 과정에서 의외였던 부분은 프론트 개발이 재미있다는 점이었다. 웹이 아니라 앱이라서 더욱 그랬던 것 같다. 어떻게 기능을 중앙에서 관리할 것인지, 코드를 잘 짤 것인지에 대한 고민도 재미있었고, 사용자에게 편한 경험을 어떻게 구현할 것인지 생각하는 과정도 그랬다. UI/UX 레퍼런스를 찾기 위해 여러 앱을 찾아보았는데, 모바일은 웹 대비 화면의 다양성이 더 적은 것 같다고 느꼈다. 아무래도 화면 자체가 작다보니 한번에 보여지는 정보의 단위가 훨씬 작았다. 회원가입만 해도 웹에서는 한번에 보여지는 화면이, 모바일에서는 '다음'/'이전' 버튼을 통해 여러 단계의 화면으로 구성된다. 또 상단 appbar나 하단 navbar, 좌우 drawer 등과 같이 모바일 사용자에게 이미 관습처럼 자리잡은 UI/UX들이 있기 때문이 이것을 잘 알고 적재적소에 활용하는 것이 중요하단 생각이 들었다.

Backend

• 자원을 썼으면! 반환하자! 핀토스 OOM때도 메모리 누수 관련해서 이미 한바닥 반성문을 적었었는데 이번에도 비슷한 실수를 하고 말았다. 트랜잭션을 위해 TypeORM api 중 queryRunner를 사용했는데, 명시적으로 commit, rollback, release를 해야 했다. 그런데 try ... catch 문 안에서 예외를 던지면서 release 없이 처리한 것이 문제가 되었다. 함수가 정상적으로 리턴되는 경우 뿐만 아니라 예외로 빠져나가는 경우에 특히 자원 반환을 잘 하자고 이미 9주전에 적었었는데 여전히 쉽지 않은 부분.. 다행히 서버에 요청 로그가 찍히도록 팀원분께서 미리 세팅을 해 두셔서, 내 코드가 문제를 일으킨다는 것을 빠르게 찾아낼 수 있었다. 이렇게 로그나 트레이스를 남기는 것의 중요성도 알게 된 경험이었다. 구현하신 팀원분의 말씀에 따르면 실제 업무에서는 이미 팀이 사용하고 있는 로그나 공통적인 모듈이 다 있는 상태에서 합류하는 경우가 많기 때문에 이런 사전작업을 해보고 싶다고 하셨다. 그 말에 따르면 아마 이런 부분을 직접 구현하게 될 일은 크게 없을 수도 있겠지만, 그래서 더욱 이게 중요하고 실무와 맞닿아 있다는 것을 알고 가야 할 것 같다.
• 예외처리를 5개 했으면 5개 테스트 다 해보는 게 당연하다. 위와도 맞닿아 있는 이야기인데, 만약 예외를 발생시켜보고, 문제 상황을 더 빨리 인지할 수 있었다면 좋았을 것이다. 나름 테스트를 한다고는 했지만 모든 케이스를 다 꼼꼼히 테스트하지 않고 main에 merge 했던 것이 치명적인 실수였던 것 같다. 테스트를 할 때는 먼저 케이스에 넘버링하고, postman에서 요청, 응답을 저장해서 테스트 리포트를 준비해두자. 기록하지 않으면 테스트 된 코드인지 아닌지도 잊어버리기 마련이다. 특히 백엔드 개발자는 꼼꼼함과 기록이 필수적인 역량인 것 같다.
• 의미 없는 값 쓰지 말자. 특히 숫자 같은 것은 enum으로 뺄 수 있으면 빼자. 보는 사람의 입장에서는 이게 무슨 값인지 알기 어렵다.

Cooperation

• 다른 사람의 코드는 건드리지 말자. 건드려야 할 경우 일단 물어보고, 부탁하자. 프론트 코드에 기능을 달 일이 있었는데, 별도 함수로 분리되어 있지 않은 코드를 분리할 경우 내 입장에서 더 편하게 코드를 쓸 수 있었다. 아무 생각 없이 분리해서 재작성했는데 그 후로 상태 갱신이 되지 않는 문제가 발생했다. 작성되어 있는 코드가 어느 정도까지의 기능 완성을 커버하고 있는지 원작자 외의 사람은 알기 어렵다. 그런 상황에서 내가 편하자고 코드를 수정하면 1. 코드를 작성한 사람도, 수정한 사람도 온전히 알지 못하는 구역이 만들어지고 2. 오류가 발생해 개발 속도가 더뎌질 가능성이 높아진다. 이번 나만무 프로젝트를 통틀어 가장 크게 반성하고 배웠던 점이 아닐까 싶다. 앞으로는 절대 해서는 안 될 행동이니 조심하자.
• 구두로 요청하기보다는 협업툴을 통하자. 매일 스크럼을 진행했는데, 급한 마음에 나도 모르게 이것저것 말로 요청하거나 물어봤던 경우가 많았다. 실제 팀이 구두로 요청하기로 규칙을 정했다면 모를까, jira, notion, slack이 버젓이 있는 상황에서 구두 요청까지 듣는 일은 상대방의 입장에서 신경 쓸 채널을 하나 더 늘리는 것이다. 내 마음 급하다고 규칙 거스르지 말고, jira 쓰는 법에도 더 익숙해지자.

앞으로 뭘 할건가요?

프로젝트에서 수정하고 싶은 부분이 많은데, 보완할 수 있는 기회가 된다면 좋을 것 같다. 개인적으로는, 이번 개발과 동일한 아키텍처로 기능은 많이 축소해서 플러터 앱개발, nestJS 서버개발을 진행해보고 싶다. 특히 플러터는 궁금했던 만큼 다 못 써 본게 많다. provider 라이브러리도 좀 공부해보고싶고. 앱개발에 관심이 많이 생긴 것 같다.

---

짧다면 짧고 길다면 긴 나만의 무기 만들기가 끝났다. 발표 때 화면 연결 문제가 있었던 것만 빼면 마무리도 잘 되었고. 제대로 된 팀 프로젝트 경험도 없었던 내게는 정말 큰 도움이 되었던 것 같다. 정글에 들어오게 된 이유가 두 가지가 있었는데, 하나는 부족한 C언어와 OS 채우기였고 두 번째는 팀 프로젝트 경험을 쌓는 것이었다. 두 번째 목표 역시 잘 채운 것 같다. 좋은 팀을 만나 앱개발, Jira 쓰기, 서버개발 .. 모두 경험해볼 수 있었고, 팀원분들로부터 배운 점도 많았다. 완성되어있는 팀에 예상치 못하게 합류하게 되어 초반엔 걱정도 조금 있었는데 다행스럽게도 프로젝트 시작하고 나서부터는 원팀으로 개발에만 몰두했던 것 같다. 성급한 마음에 실수가 많았지만 팀원분들이 많이 이해해주셔서 미안하고, 또 감사하고. 앞으로 더 발전하자는 마음으로 노력해야겠다. 힘들고 지치기도 했지만, 그 이상으로 행복했고 재미있었던 나만무 회고 끝 🍀