관리 메뉴

사과하는 제라스

[회고] Apple Developer Academy @ POSTECH 3기 28주차 회고 본문

Apple Developer Academy @ POSTECH

[회고] Apple Developer Academy @ POSTECH 3기 28주차 회고

Xerath(제라스) 2024. 9. 21. 15:45

목차

    728x90
    반응형

    서론

    안녕하세요. 👋🏻 🤖 👋🏻

    후... 써둔 회고가 다 날라가버리고나니 의욕이 뚝 떨어졌다가 마음 잡고 다시 쓰고 있는 멍청쓰 제라스입니다.

    다들 추석은 잘 보내셨나요?? 🍁🍁

    이번주는 토일에 추석 연휴까지 투루룩 있어서 정말 야무지게 쉬었던 한 주였습니다 ㅎㅎㅎ

     

    근데 님들 그거 아심?!?!

     

    내년엔 광기의 휴일이 다가오고 있다는 사실 ㅋㅋㅋㅋㅋㅋㅋ

    상당히 기대가 되는데... 이땐 꼭 취업이 되어있길... 🥲🥲

    (그래야 의미가 있으니까...!!)

     

    이번주도 회고가 쪼금 늦었네요 ㅎㅎㅎ

    지난주엔 뭘 했는지 찾아보니...

    대부분이 Clean Architecture에 대한 고민과 Macro 프로젝트에 대한 생각들 뿐이였던 것 같습니다...!

     

    그럼 한번 가볍게 회고를 시작해보겠습니다!

    음악 디깅이란 주제를 갖고 달린 Macro 2주차

    이번 2주차의 키포인트를 크게 다음 3가지로 꼽아보았습니다!

    1. 우리 팀의 주제는 '음악 디깅'
    2. 음악을 디깅하는 사람들을 인터뷰하기
    3. Problem / Opportunity 도출하기

     

    지난 회고에서 잠시 언급했듯이

    2주차 Team Medio는 '음악 디깅'이란 주제를 정하게 되었습니다.

     

    처음엔 정말 많은 아이디어와 키워드들이 나왔었고,

    이것들을 본 후 각자가 생각나는 주제들을 나열해보았어요!

    키워드 및 아이디어 공유 후 생겨난 주제들

     

    이렇게 20개가 넘는 아이디어들이 뽑아지고나니 더 좁히려는 시도들이 필요했죠.

    그래서 다음과 같이 큰 틀에서 주제들을 모아보았고,

    각 대주제에 대한 Engage Bar를 활용(리니가 제시해준 좋았던 아이디어...!!)해서 표시를 해보았습니다!

    대주제로 모아둔 후 Engage 정도를 표시한 모습.

     

    이후 Engage가 적은 주제들에 대해선 왜 어려운지, 인게이지가 안되는 이유들과 왜 하면 좋겠는지 등의 생각을 공유해보았고,

    최종적으로 유배지들에 보낸 후 최후의 3 주제를 뽑게 되었습니다.

     

    그렇게 뽑힌

    1. 주제가 졸업 전시

    2. 오디오, 레코더, 스피커 기반

    3. 컨텐츠 속도/자막

     

    이때 이 대주제의 선정보다는 각 대주제에 대한 팀원들의 아이디어 공유가 필요했습니다!!

    아무래도 생각을 못해본 대주제일 수 있으니까~~

     

    그래서 각자 주말에 고민을 해왔었고,

    2주차의 시작은 그 아이디어 공유를 진행했습니다!

     

    이렇게 여러 아이디어들을 나열해둔 후 가장 문제 해결 상황이 잘 보이거나 Engage가 잘 되는 주제를 1~3순위를 메겨보았습니다.

    그 결과,두굳굳굳ㄱ두굳구둑ㄷ구두구

     

    응~ 절대 안 좁혀짐...!!

     

    이때, 한톨의 소신 발언...!!

     "나는 지금 나온 모든 주제에 사실 인게이지가 되고 어느 주제에 욕심을 내고싶지는 않기에 무슨 주제든 괜찮아!"

     

    근데, 이때 생각해보니 지금까지 좁히고 좁혀서 뽑아낸 주제라면 충분히 모두 Engage가 되고 있었기에

    고민이 오히려 우리 팀에 시간만 끌고 지치게 할 것 같았어요!!

     

    근데...!! 이게 모두들 그렇게 생각하고 있었던 것...ㅋㅋㅋㅋㅋㅋㅋ

     

    그래서 저희 우유부단 Medio 팀이 선택한 최후의 수단...!!

    욕망의 항아리 개발하신 분 자손대대로 행복하세요~~

     

    그렇게 뽑힌 '음악 디깅'이 저희 팀의 주제가 되었습니다~!!

     

    그럼 이 주제를 가지고 인터뷰이들을 선정을 해야했어요!

    그래서 음악 디깅이란 것을 자주 하는, 자주 할 것 같은 사람들을 위한 인터뷰지를 준비했습니다.

    이때, 집중한 것은 '인터뷰를 통해서 얻을 것은 우리의 유저가 아니라, 우리의 주제를 탐색하기 위함에 있다.' 였습니다.

     

    그렇게 준비한 인터뷰지를 가지고 저희 팀의 지인 2분을 대상으로 인터뷰를 했습니다!

    인터뷰한 내용들을 질문한 주제 포인트에 맞춰서 정리한 형태

     

    그 후 요렇게 디깅하는 사람의 상황에 맞춰서 정리도 해보았습니다.

     

    무지 순조롭게 나아가던 시점...!

    등장한 고민.

     

    '우리가 생각하는 '음악 디깅'이 다른 것 같다...! Align해야겠다!'

     

    역시나 저희 각각이 생각하는 음악 디깅의 범위가 다르더라구요~~

    음악 디깅은...

    - 음악을 검색하는 거야

    - 새로운 음악을 찾기 위해서 하는 거야

    - 기존에 듣던 음악과 비슷한 음악을 찾기 위함이야

    등등...

     

    그래서 팀원들끼리 의견을 나눈 결과, 이 모든 것이 음악 디깅이고 우리가 해야할 것은

    음악디깅을 하는 사람이 음악 디깅하는 과정을 도와주자는 것이었습니다.

     

    그렇게 자연스럽게 저희 팀의 Challenge Statement는 다음과 같이 픽스가 되었습니다~!!

    "음악디깅을 하는 사람이 음악 디깅하는 과정을 도와주자"

     

    🍁🍂 그렇게 맞이하게 된 추석 연휴...! 🍁🍂

     

    저희는 또 회의를 했습니다 ㅋㅋㅋㅋㅋㅋㅋ

    다들 1시간 하기로 했지만 2시간 반을 했다는...ㅎㅎ

     

    이 회의에선 정리된 인터뷰 모음집 중에서는

     

    이전에 각자가 생각하는 Opportunity가 있는 것들은 모두 박싱처리해보았었던 걸 가져와서

    각자가 생각하는 Opportunity들을 얘기해보았습니다!

     

    하지만 이 또한 쉽게 좁히기 어렵다는 생각이 들어서...!

    '그림'의 T다운 방식을 도입 ㅋㅋㅋㅋㅋㅋㅋ

    분 단위로 계산하는 진짜 광기의 T 김그림 ㅋㅋㅋㅋㅋㅋㅋ

     

    그렇게 주말에 각자가 생각하는 것들을 AS IS + TO BE로 나눠서 3:2:2 로 그룹을 나눠서 의견을 모으고 1개 이상의 문제 상황과 해결 방법을 찾아오기로 했습니다!

     

    이후의 과정은 다음주 회고에서 To be continued...!!

    이번주는 사실상 가장 중요했던 Solution Concept까지 정해야했던 시간인지라 회의를 정말 많이 했던 듯...하옵요 ㅠㅠ

     

    저번주에 이어서 이번주도 팀 내 회의 내용을 잘 작성해주고,

    회고도 다같이 해줘서 너무 고마웠던 Team Medio였습니다 ㅎㅎ

    Clean Architecture를 이유있게 작성하는 과정

    저는 지난주에 이어 이번주도 머릿속은 Clean Architecture로 차있었습니다...

    그러다 네이버 부스트캠프 동료 분들과 스터디를 하다가 이에 대한 고민을 던졌었습니다.

     

    '다들 혹시 생각하시는 Clean Architecture의 범위가 어느정도로 보세요??'

     

    지금 생각해보며 정말 무책임한 질문이었던...것...

    이때, '대황'님께서 반문을 해주시더라구요

     

    '동주님이 생각하시는 Clean Architecture는 무엇인데요??'

     

    이때 제가 말한 것은

     

    Testable하게 짜고, 의존성을 줄이게 짜기 위함이란 '목적'

    +

    MVVM과 함께 자주 쓰이는데 이때,

    [ View-ViewModel(Presentation) - UseCase - Repository(Domain) - Data ]

    의 형태를 지키면서 Protocol을 활용한 의존성 역전을 적용하는 '구조와 구현방식'

     

    이렇게 머릿 속에 담긴 것들을 얘기했습니다..!!

     

    그러고선 가장 핵심이었던 질문을 던졌습니다...!

     

    "혹시 Clean Architecture에서 제시된 형태를 웬만하면 모두 담아서 구현하는 것이 좋을까요??"

     

    이에 🤴🏻GOD 대황🤴🏻님께서 예전에 Clean Architecture에 대해서 발표하신 자료를 들고 와주셨습니다...!!!

    Mason은 신이다....! 흐흫흐흫ㅎㅎ

     

    사실 직접 들어도 정말 여러번 곱씹어보고 싶을 정도로 내용이 좋았는데,

    Clean Architecture를 대하는 사람들마다의 태도는 다르다

    이게 가장 큰 핵심이었습니다.

     

    각자의 머릿속에 담긴 클린 아키텍쳐의 범위도 다르고, 구현 범위도 다르고, 도입 이유도 다릅니다.

    그렇기에 크게 정해진 Area는 있어도 정해진 형식은 없고,

    클린 아키텍쳐의 정의를 다르게 본다는 것은 잘못된 것이 아니란 것입니다.

     

    클린 아키텍쳐의 범위는 개발자마다 생각하는 정도가 제각각이다.

     

    각자가 클린 아키텍쳐를 도입할 당시 그 이유도 다르게 생각할 것이고,

    도입하는 상황도 다르고,

    '이것까진 구현해야 클린 아키텍쳐지!', '이것까진 우리 프로젝트엔 필요없지!' 이런 주관도 모두 다르기 때문입니다.

     

    대황님으로부터 너무 좋은 강연?세미나?발표?를 듣고나니 앞으로 제가 도입할 클린 아키텍쳐는 조금 더 주체적으로 적용된 것이면 좋겠다는 생각이 들었습니다.

     

    그래서 이번 Live4Cut에서도, 앞으로 있을 Macro 프로젝트에서도 Clean Architecture에 대해 다같이 의논해보고 적용해봐야겠다는 생각이 들었습니다.

    다음 주의 나에게

    이번주(사실은 지난주...)는 매크로 프로젝트에서는 기획적인 부분에서, 팀을 이끌어나가는 입장에서 시간을 많이 쓴 것 같아요.

    개인적으론 개발도 하면서 Clean Architecture에 대한 고민도 많이 해보았구요 ㅎㅎ

     

    다음주엔 다음과 같은 것들을 해두고자 합니다.

    1. Live4Cut 화면 퍼블리싱 마무리 및 Package 연동
    2. ReactorKit 반영해서 구현해보기
    3. Macro Project에서의 프로젝트 구조를 팀원들과 Align해두기

     

    라고 적어뒀었는데...ㅠㅠㅠ 한 주가 다 지나서 쓰고 있는 라스좌...

    늘 저장저장저장 명심하자...!!

     

    그럼 다음주에도 29주차 회고로 돌아오겠습니다~!!

    728x90
    반응형