iOS 개발 공부를 시작하고 참여한 두 번째 컨퍼런스였다. 컨퍼런스에 가면 다른 사람들과의 네트워킹 뿐만 아니라 연사를 통한 개발이야기를 들을 수 있는 기회라 늘 설레고 두근거리는 것 같다.

메인 부스	컨퍼런스장 외부	컨퍼런스장 내부

근처 커피빈에서 커피를 테이크아웃 해서 가져갔는데 물 이외 취식금지라 앞에서 원샷하고 가느라 세션 중간에 들어가야 했다...(커피까진 너무 한거 아닙니까ㅠ)

무신사 테크 굿즈	패널 토크

Session 1 - 무신사

• 우리 회사를 하나의 잣대로 평가할 수 있을까요?

  • 당신은 어떤 회사에 가고 싶나요?

    • 꼭 쟁취하고 싶은 것

    • 포기할 수 있는 것

      ⇒ 이 두가지 기준으로 회사를 생각해보기

• 어떤 동료가 되고 싶은 지?

  • “내가 앞으로 프로젝트를 진행하면서 같이 하고 싶은가”에 대한 질문
  • 업무와 업무 사이의 영역을 채운다(그레이 영역, 리드미?)

• 본인이 생각했을 때 좋은 리더란 무엇인지

  • 내가 일할 때 즐겁고 뿌듯할 지

    ⇒ 리더란? 다른 사람을 일을 하게 하는 사람, 그 일을 진행할 때 즐겁고 뿌듯하게 만들어주는 사람

    ⇒ 하나의 자리가 아닌, 능동적인 역할

Session 2 - 뱅크샐러드

• 어쩌다 보니 개발자가 됐어요, 어떻게 나답게 성장해야 할까요?
  • 기획자 → 개발자
  • 서류 탈락 → 이력서가 아닌 방법으로 나를 알려야겠다
    • 홍보를 위한 웹사이트 개발(프로필을 볼 수 있는 뷰 구성)
    • 테스트 코드 작성
  • 개발자로서 재미를 느낄 때?
    • 내가 만든 서비스의 비중이 높아질 때(서비스 목표에 공감이 될 때)
    • 협업을 진행할 때
  • 이력서로 보여주기 어려운 부분을 서비스로 보여주고 싶을 때
    • 개발자로서 보여줄 수 있는 본인의 모습
    • 뉴비여도 적용할 수 있는 기술의 적용, 좋은 코드, 이슈에 대한 트러블 슈팅
    • 회사는 1등을 가르는 곳이 아닌, 개개인의 장점을 드러내야 하는 곳
  • 기획과 개발 직군을 모두 접하게 되면서 장점은?
    • 기획과 협업에 용이
    • 개발을 할 때 효율적인 마일스톤으로 진행 가능

Session 3 - 강남언니

• 도망쳐서 도착한 곳에 낙원이란 있을 수 없다.

  • 커리어를 운에 맡길 수 없다.

• 왜 나만 이렇게 정체되어 있을까?

  • 내 스킬셋에 대한 고민, 이직에 관한 불안함

  • 주변 환경의 변화, 미래에 관한 불안함

  • 우울감과 무기력함

    ⇒ 정체성의 확립 : 동기부여 및 원동력

    ⇒ 목표 수립

    ⇒ 행동 변화와 목표 실행

    위 세가지의 반복

• 동료들에게 내 장점을 각인

• 주도적으로 살면서 시간 계획을 세우고 삶의 즐거움을 움켜줘야 한다.

  ⇒ 그냥 무언가를 수행했다는 것을 면죄부로 여겨서는 안된다.

• 연차가 낮을 때 성장방법

  • 기술스택을 쌓는 시간을 투자하기 어렵다.
  • 멘토가 있으면 좋다.

• 작은 개발 조직에 있는 경우 성장방법

  • 다양한 일을 마주하게 된다.

    ⇒ 다양한 경험을 할 수 있는 큰 기회

    ⇒ 그 과정에서 내가 좋아하는 분야를 찾고 구체화 해라

• 공부하다 지쳤을 때

  • 절박감, 간절함
  • 내가 나의 컨텍스트와 이유를 찾고 그에 맞는 정체성을 주입

Session 4 - AWS

• AWS를 시작하는 개발자를 위한 Service 추천

Session 5 - 패널 토크

1부 : 커리어

• 개발자의 성장을 부스트하는 다양한 방법과 경험적 레슨 - 함께 더 성장하기
  • 실패가 많다 → 시도가 많다 / 우울감에 빠지지 마라
  • 대체 불가능한 전문성을 갖기()
• M&A에 성공하는 방법
  • “내가 진정으로 다른 사람을 도와주고 있나”에 대해 고민해보기

2부 : 실패사례

• 웹 서비스를 중단한 이유
  • 하나의 팀으로써의 성장이 중요! → 백엔드 없이 Firebase 도입 과정으로 이어짐
  • 모두가 모든 코드에 기여
• 모닥불 프로젝트
  • 내가 겪은 문제는 다른 사람도 겪었을 것이다.
    • 노하우 / 경험적인 지식의 전달
    • 액션이 없을 때는 자체적인 장작 넣기(일명 스파이) → 자연스러운 참여 유도

전 프로젝트에서 팀장을 맡으면서 해커톤에 대한 공지를 놓치며 낙동강 오리알이 되었다.

남은 팀이 한 팀 밖에 없었는데 다행히 전에 실습하면서 정말 잘 맞았던 팀원이 있어 얼른 신청을 했다.

그런데, 인원 미달로 아이디어가 폐지되며 오도가도 못하는 상황이 되었다.

그때 마침 다른 아이디어 제안자한테 연락이 와서 가까스로 팀에 합류하게 되었다.(!=NO 고마워🥹)

이렇게 시작부터 다이나믹 했던 해커톤! 그 대서사에 대한 회고를 해보고자 한다.

일단, 프로젝트 주제는 "주변 바틀샵에 대한 정보 및 예약/픽업 서비스를 제공하는 플랫폼"이다.

'주류의 통신판매에 대한 명령위임 고시'에 따라 주류제조업면허자만 인터넷 상에서 주류 판매를 할 수 있기 때문에 우리 프로젝트는 바틀샵과 소비자 간의 중간다리 역할을 하는 플랫폼으로 ADS를 구축했다.

프로젝트 주제처럼 메인 뷰에서 MapKit을 통해 위치 정보를 보여주고 바틀샵 별로 마커를 띄워 샵과 상품에 대한 정보를 제공해주었다.

또한, 메인 뷰에서 키워드 검색과 내 주변 반경 5km 이내 바틀샵을 보여주는 기능을 구현하여 사용자의 편의를 도모했다.

스플래시뷰	메인 뷰

디테일뷰에서는 서브뷰로 메인화면 위에 정보를 띄워주고 TabView를 활용하여 앱 서비스의 카테고리 별로 구분하였다.

마커 디테일뷰	좋아요한 상품 뷰	내 정보 뷰

해커톤을 진행하면서 정말 시간가는 줄 모르고 개발에 몰두했었다.

오전 9시에 시작해서 정신차려보니 자정이었으니...

저녁도 대충 라면을 끓여 먹으면서 개발했다.

이후 새벽 6시까지 팀원 모두 잠을 잊은 채 개발에 몰두했다.

팀원 모두 많이 지쳐보였지만 어떻게 해서든지 시간 내에 기능을 구현하려고 노력하는 모습이 너무 대단했고 큰 동기부여가 됐다.

(마지막까지 우릴 괴롭혔던 보라돌이...너는 최종프로젝트 때 보자...)

결국 다음 날 오후 3시까지 장장 30시간의 무수면 코딩이 이어졌고 한 팀 씩 해커톤 결과물에 대해 발표를 했다.

우수팀 수상 또한 있다고 했지만, 내심 기대하는 마음 반 에이 설마하는 마음 반이었다.

그런데 이게 왠걸...? 대상 발표를 하는데 우리 팀이 선정됐다...!

MapKit과 여러 소셜로그인 기능을 구현하고 늦게까지 개발에 몰두하는 모습이 좋은 점수를 받았다고 한다.

이전까지만 해도 정말 너무 지쳐서 쓰러지기 일보 직전이었는데 수상 발표 이후 너무 기쁜 나머지 피로마저 다 가시는 기분이었다.

졸음과의 사투, 치열했던 해커톤 현장...(+ 뒤에 있던 메가커피 두잔)

이번 해커톤을 진행하면서 나는 정말 인복이 많다는 생각이 들었다.

어쩌면 합류하지 못할 뻔 했던 팀에 운 좋게 들어왔던 점과 중간중간 지칠 때마다 장난치며 텐션을 올려보고자 노력했던 우리 팀원들과 함께할 수 있었던 점 모두 그렇기 때문이다.

우리 "Bottles" 너무 고생했고 대상 정말 축하하고 최종 프로젝트도 힘내보자구!👍

총 85명 남짓 되는 인원이 A, B, C 총 세 팀으로 나누어 대규모 프로젝트에 투입되었다.

나는 프로젝트 B팀으로 배치 받았는데 운영진 측의 어떠한 기준(?)으로 팀장으로 뽑혔다.

사실 전주에 독감에 걸리면서 컨디션이 완전 바닥인 상태라 팀장이라는 자리가 조금 무겁게 다가왔다.

프로젝트 주제는 쇼핑몰 앱(소비자 + 관리자)이었고 나는 관리자 앱으로 들어갔다.

주제만 정해져있고 기획, 디자인, 개발까지 일주일 정도 되는 기간 안에 완성시켜야 했다.

초기 기획은 피그잼을 활용하여 앱의 전반적인 기능들과 데이터구조를 정리했다.

이후 피그마를 활용하여 앱의 뷰 별 디자인 및 구성요소에 대한 기획을 진행했다.

우리는 관리자(판매자) 전용 앱으로써 iPad 전용으로 구현하기로 했다.

iPhone 개발만 해오다가 iPad 개발을 해보니 또 다른 느낌이었다. (개인적인 생각으로 SwiftUI는 iPad 개발 시 더 빛을 바라는 것 같다.)

기획 이후 개발 단계 전까진 팀장으로서 책임과 역할이 그렇게 크지 않아서 '걱정했던 것보다 할 만 한데...?'라는 오만을 했다.

개발이 시작되자 여기저기서 기획과 디자인에 대한 수정사안이 나왔고, 기능들에 대한 구현방법, 에러 발생 대처법 등등...

나도 팀장이라는 자리가 처음이라 어떻게 기획안을 발전시키고 대처해야할 지 몰라서 좀 막막했다.

그래서 팀원들의 의견을 듣고 최대한 반영하고자 했는데, 문제는 개발이 점점 진행될 수록 이러한 방법이 개발 속도를 늦추고 있다는 것이다.

따라서, 최대한 팀원들의 의견을 듣되 최대한 내가 빠른 결정과 결단을 내려야 한다는 것을 깨달았다.

팀장이라는 직책을 맡으며 정말 많이 성장할 수 있었다.

일주일 정도 되는 기간동안 기획부터 개발, 그리고 중간중간 발생한 이슈해결, 마지막으로 팀장회의까지...

이번 프로젝트는 일주일이 정말 어떻게 흘러간 지 모를 정도로 정신 없게 진행되었는데, 전에는 개발에만 몰두하며 기능 구현과 트러블슈팅에 매몰되어 숲을 보지 못하고 나무만 보는 경우가 많았다.

하지만, 이번 프로젝트를 통해 개발 프로세스의 전반적인 흐름을 보고 우선순위를 정해 기간 내에 완성할 수 있게 하는 힘이 생긴 것 같다.

미숙한 팀장 아래서 정말 높은 퀄리티의 결과물을 만들어 준 팀원들께 무한한 감사를 표한다🤗🙏

해커톤 주제를 최종 프로젝트로 이어서 진행을 하면서 기존 기획에 대한 디테일한 부분들을 전면 수정하였다.

그러면서 도입하게 된 네이버 지도 API!

네이버 지도 공식문서 상 CocoaPods만 있고 SPM은 존재하지 않아 아쉬웠다. (비공식 네이버 지도 SPM이 있긴 하던데 뭔가 불안해서...)

내가 네이버 지도 API 적용할 뷰를 맡아 혼자 진행할 때는 나름(?) 잘 구현이 되었는데 문제는 깃헙에 업로드하는 과정과 협업 과정에서 발생하였다.

첫번째 이슈 - Github

Github에 푸시하는 과정에서 네이버지도 API 용량이 100MB를 초과하여 업로드가 되지 않았다.

아래는 구글링을 통해 시도해본 방법들이다.

1. Git-lfs 활용

1. git lfs 설치
$ git lfs install

2. 100MB 이상 파일 추적
(확장자) 부분에는 파일의 확장자를 적으면 된다.
$ git lfs track "*.(확장자)"
$ git add .gitattributes

3. 기존 커밋 푸쉬 작업 진행
$ git add .
$ git commit -m "메시지"
$ git push origin main

2. BFG Repo-Cleaner 활용

먼저, https://rtyley.github.io/bfg-repo-cleaner/ 로 가서 .jar 파일을 다운로드 받아 명령어를 실행할 위치에 넣어준다.

java -jar bfg-1.14.0.jar --strip-blobs-bigger-than 100M
git pull      // github repository에 있는 파일 로드하기
git add *     // 변경 파일 추가
git commit -m "커밋내용"    // commit 하기
git push -u origin main        // main branch에 push 하기

위 두 방법을 통해 대용량 문제는 해결되었으나, 갑자기

fatal: The remote end hung up unexpectedly

라는 에러가 발생했다.

이 에러는 단일 파일당 최대 용량이 1MB로 설정되어있는데 그것을 초과했기 때문이라고 한다.

따라서, 아래 방법으로 postBuffer에 대한 용량을 늘려주었다.

git config --local http.postBuffer = 2048M
git config --local http.maxRequestBuffer.= 2048M

git config --local pack.deltaCacheSize = 2048M
git config --local pack.packSizeLimit = 2048M
git config --local pack.windowMemory = 2048M

git config --local core.packedGitLimit - 2048m
git config --local core.packedGitWindowSize - 2048m
git config --local core.compression - 9

git config --local ssh.postBuffer = 2048M
git config --local ssh.maxRequestBuffer = 2048M

하지만, 이렇게 하면 다시 대용량 이슈가 생기면서 뫼비우스띠 마냥 해결이 되지 않았다.

그래서, 그냥 github 레포 안에서 .gitignore처리를 해주기로 했다🥲

두번째 이슈 - CocoaPods

github 레포 안에서 .gitignore처리를 해서 팀원들이 pull을 받은 이후 pod install을 진행해야 했었는데 여기서도 정말 다양한 오류들이 발생했다...

1. CocoaPods 버전 이슈

pod --version으로 확인 결과 1.5.3으로 현재 github에 배포된 버전(1.11.3)과 달라 pod install이 실행되지 않았다.

따라서, 아래와 같이 CocoaPods 재설치를 진행했다.

$ sudo gem list cocoapods
$ sudo gem uninstall cocoapods
$ sudo gem install cocoapods

이후, CocoaPods 버전을 확인해봤는데 경로가 잘못 되었는 지 버전 업데이트가 되지 않았다.

따라서, 로컬에 있는 CocoaPods를 제거 후 재설치하니 해결되었다.

// 설치된 코코아팟 버전 리스트 확인
$ sudo gem list cocoapods

// 개발자 도구 업데이트
$ xcode-select --install                                 

// 코코아팟 설치
$ brew install cocoapods

2. CocoaPods 경로 이슈

또 다른 팀원의 이슈는 CocoaPods의 다운로드 경로가 맞지 않아 발생한 이슈였다.

구글링 결과 이는 최신 MacOS에서 자주 발생하는 오류라고 한다.

따라서, 아래 코드와 같이 개발자 도구를 업데이트한 후,

// 개발자 도구 업데이트
$ xcode-select --install

다운로드 경로를 직접 설정하여 CocoaPods를 설치하니 해결되었다.

$ brew install ruby
$ sudo gem install -n /usr/local/bin cocoapods

이 모든 작업 이후에 대용량 파일 다운을 위한 git-lfs 설치하고, pod install을 진행해주면 끝.

// 로컬 디렉토리
$ brew install git-lfs

// 해당 프로젝트 디렉토리
$ git lfs install

// pod 설치
$ pod install

이렇게 CocoaPods와의 전쟁은 일단 정리되었다.

나도 당시 CocoaPods에 대해 완벽하게 숙지하지 못했던 부분이 많았는데, 팀원들 이슈를 도와주며 해결해나가는 과정에서 정말 많이 배울 수 있었다.

이에 따라, MapKit으로 구현해야 하는 뷰가 메인으로 들어가게 되었는데 여기서 SwiftUI의 한계가 정말 크게 느껴졌다.

Apple 공식 문서로 확인해봐도 MapKit과 관련된 부분에서 SwiftUI는 Map, UIKit은 MKMap으로 제공하고 있다.

문제는 아직 MKMap의 기능들의 일부만 Map으로 이전되었고 여전히 주된 기능들은 UIKit의 MKMap으로 개발을 진행해야한다는 것이다.

무수한 보라돌이의 요청...다시봐도 어질어질하다...

이러한 오류를 해결하고자 방법을 열심히 찾아보았지만 아직 SwiftUI에서 MapKit의 기능들이 불안정해서 발생하는 오류라는 답만 존재했다.

따라서, 이번 프로젝트는 SwiftUI로 진행하고 있었기에 과감하게 UIViewRepresentable로 다시 구현해보기로 했다.

UIViewRepresentable이란?

우선, UIViewRepresentable을 사용하려면 프로토콜을 준수하기 위해 아래 2가지 함수를 필수적으로 추가해햐한다.

// UIView를 생성하고 초기화하여 SwiftUI에서 사용할 컴포넌트(UIView)를 리턴
// SwiftUI의 View 라이프 사이클동안 "한번" 호출된다.
makeUIView(context:) -> UIView

// UIView 업데이트가 필요할 때 호출하는 메소드
// @Binding을 이용하여 SwiftUI의 데이터가 UIKit 컴포넌트의 데이터로 바인딩.(단, read only)
updateUIView(:context:)

// UIKit -> SwiftUI로의 데이터 전달 (= delegate 역할)
// @Bidning property는 SwiftUI -> UIkit으로의 데이터 전달
// UIkit의 데이터가 SwiftUI의 데이터로 바인딩 → Binding<> 타입으로 선언된 값을 통해 연결, 해당 커스텀 클래스 컴포넌트 이니셜라이즈 시 프로퍼티로 전달된 값

func makeCoordinator() -> Self.Coordinator

주요 기능에 대한 이론은 위와 같다.

하지만, 이론에 대한 이해가 어느정도 되었을 때, 시간의 압박이 있는 해커톤 프로젝트라 UIViewRepresentable로 MapKit을 구현하지 못했다.

다음 최종프로젝트로 진행할 때 제대로 활용해보고 싶다.

UIViewRepresentable...To be continue...🤯

OPGG 사옥 입구	adiOS 2022 포스터

일단 결론부터 말하자면 신선한 충격의 연속이었다.

이렇게 다양한 개발자들과 소통하며 많은 동기부여가 되었으며 현재 개발을 공부하며 취업을 준비하는 내 입장에서는 현업에서 어떻게 일하고 소통하는 지 알 수 있었다.

이를 통해, 앞으로 내가 어떤 방향으로 공부를 하고 준비를 해야하는 지 명확해졌다.

또한, 이 날 진행되었던 컨퍼런스 주제들이 아래와 같이 너무 어렵거나 무거운 내용이 아니였기에 많이 이해하고 공감할 수 있었다.

adiOS Something 2022 발표 주제
1. 커뮤니티 활동과 떠나간 2022
2. '완전 자율 문화'를 위한 이별
3. 회사와 헤어질 결심
4. UIKit을 떠나보내기 위해 시도한 것들

학교 기말고사랑 기간이 겹친 주말이라 컨퍼런스 시작 시간보다 늦게 도착해서 앞 부분을 놓쳤다😥

그래도 2번 주제부터는 제대로 들을 수 있었는데 "OP.GG"의 사내문화와 관련된 내용이었다. 내가 만약 게임을 좋아했으면 정말 가고싶은 회사 1순위였을 것 같다는 생각이 들었다.

‘완전 자율 문화’를 위한 이별

• 성장을 통해 기여할 수 있도록 구성원 모두가 이용 가능한 지원 제도
• 가장 효율적이고 커뮤니케이션 왜곡이 없는 논거 기반의 커뮤니케이션 문화
• 인재상 : 세상 모든 서비스에 관심이 많은 ‘예비 기업가’

3번 주제는 이번 컨퍼런스에서 정말 많이 배웠던 부분이었다. 면접 꿀팁과 회사와 내가 맞는 지 구별하는 방법 등 알찬 내용이 가득했다.

회사와 헤어질 결심

• 좋은 동료 + 개발 문화가 좋았다. 근데 왜?

  ⇒ SI 회사 특성 상 성장에 대해 고민할 시간이 없다.

  ⇒ B2B 회사 이직, 마음 맞는 동료가 있었지만 주인의식 부재, 애정을 가진 서비스를 출시하고 싶다는 생각

• 이직

  • 우선순위 - 복지, 동료, 서비스, 성장, 문화 등등

• 면접

  • 서로 얼굴을 마주 보고 만나 봄

  • 내가 가고 싶은 회사인지 판단하는 자리

  • 어떻게 하면 잘 보일 지에 대한 고민 → 막상 들어가면 작아보인다.

    ⇒ 질문을 하자! - 우선순위를 판단할 수 있는 질문들

    ex) 팀원들 중 야구를 좋아하는 팀원이 있나요?(팀원에 대한 관심, 소통 파악)

    회사 자랑해주세요(회사의 우선순위와 나의 우선순위가 맞는 지 판단)

마지막 주제는 평소 SwiftUI로 개발을 하면서 정말 많이 공감되었던 내용이다. SwiftUI와 UIKit...정말 떼고 싶지만 뗄 수 없는 관계...개발 속도와 신기술 도입 측면에서는 SwiftUI가 압승이지만 아직 UIKit 베이스로 만들어진 코드나 메서드들도 많기에 양쪽 모두 알아둬야 하는 것은 분명하다.

UIKit 을 떠나보내기 위해 시도한 것들

• UIKit의 단점
  • 명령형 : UI 구현 시, 상대적으로 많은 양의 코드
  • 상대적을 높은 난이도 : 수 많은 View, 다양한 아키텍처
• UIKit에서 SwiftUI로의 전환
• 근데 왜 아직 UIKit?
  • 한계 1 : 부족한 기능(ex: 화면 이동)
  • 한계 2 : 높은 최소 지원 버전
  • 한계 3 : UIViewRepresentable의 불편함
  • 한계 4 : UIKit에 비해 적은 리소스
• UIKit을 떠나보내며 얻은 장점
  • 개발 속도
  • 최신 기술
  • 재미
• UIKit을 떠나보내며 얻은 단점
  • 버그
  • 레퍼런스
  • 취준생

⇒ 간단한 UI를 구현해야 하면 떠나보내자!

컨퍼런스의 마지막 순서인 Open Session과 네트워킹 시간!

Open Session은 일반 참가자들이 정해진 주제에 대해 서로의 경험을 발표하는 시간이다.

나는 내 UIKit 기반 개인프로젝트를 SwiftUI로 리팩토링하는 과정에서 github 조작 미숙으로 프로젝트를 다 날린 가슴 아픈 썰을 풀었다...

그후 각성해서 github 준 마스터 해버렸다.

그리고 발표 부상으로 받은 OP.GG 마우스 패드 굿즈🤙

Open Session 주제	OP.GG 굿즈	발표 사진🤣

이후 네트워킹 세션에서 현업, 취준, 이직에 대한 더 깊고 진솔한 대화를 나눌 수 있었다.

언제 어디서 어떻게 만나게 될 지 모르겠지만 다음 adiOS 컨퍼런스에 참가할 때는 현재보다 더 성장해서 다시 대화해보고 싶다.

다들 내년에 또 봐요✌️

세상에 쉬운 일은 없다는 것을 다시 한번 깨닫는다...

메모장에서 List를 사용해서 저장된 메모를 뿌려주려고 하다가 우연히 토글(목록 숨기기)기능을 알게 되었다.

토글 펼치기(목록화)	토글 숨기기

원래 나중에 구현해보려고 생각한 기능이었는데 VStack을 사용해서 이리저리 옮기다보니 구현되어 있었다. 그 원인은 아래와 같이 List가 VStack으로 감싸지면서 자동으로 생긴 것이었다.

VStack {
                List {
                    // 즐겨찾기 상단고정 섹션 생성
                    Section(header: Text("즐겨찾기")){
                        Text("")
                    }
                    Section(header: Text("Memo")) {
                        ForEach (0 ..< memoData.memoData.count, id: \.self) { index in
                            HStack {

                                NavigationLink(destination: MemoDetailView(memoData: memoData)) {

                                    VStack(alignment: .leading, spacing: 4) {
                                        // 메모 제목이 있다면 제목을 보여주고, 제목이 없다면 content의 내용의 앞부분을 미리보기 해준다.
                                        Text(memoData.memoData[index].title ?? memoData.memoData[index].content)
                                            .font(.title3)
                                            .bold()
                                        Text(memoData.memoData[index].content)
                                        Text(memoData.memoData[index].createdAt)
                                            .foregroundColor(.gray)
                                    }
                                }
                            }
                        }
                    }
                }
                .navigationTitle("Memo")
            }

이후 Swift 공식문서를 참고해보니 .listStyle(SidebarListStyle)을 통해서도 토글 기능을 활성화할 수 있었다.

위 코드의 사용법은 아래와 같다.

VStack {
                List {
                    // 즐겨찾기 상단고정 섹션 생성
                    Section(header: Text("즐겨찾기")){
                        Text("")
                    }
                    Section(header: Text("Memo")) {
                        ForEach (0 ..< memoData.memoData.count, id: \.self) { index in
                            HStack {

                                NavigationLink(destination: MemoDetailView(memoData: memoData)) {

                                    VStack(alignment: .leading, spacing: 4) {
                                        // 메모 제목이 있다면 제목을 보여주고, 제목이 없다면 content의 내용의 앞부분을 미리보기 해준다.
                                        Text(memoData.memoData[index].title ?? memoData.memoData[index].content)
                                            .font(.title3)
                                            .bold()
                                        Text(memoData.memoData[index].content)
                                        Text(memoData.memoData[index].createdAt)
                                            .foregroundColor(.gray)
                                    }
                                }
                            }
                        }
                    }
                }
                // 토글(목록접기 버튼 활성화)
                .listStyle(SidebarListStyle())
                .navigationTitle("Memo")
            }

ListStyle 프로토콜에는 SidebarListStyle 외에 다양한 기능을 제공하고 있으니 한번씩 숙지해보고 다음에 리스트를 활용할 때 이용해봐야 겠다.

이미지 저장 후 Assets에 추가해서 이미지 이름 지정 후 불러오는 것보다 훨씬 간편하고 효율적인 방법인 것 같다.

아래가 기본 코드이지만 placeholder와 ProgressView()까지 활용한다면 조금 더 디테일하게 이미지를 불러올 수 있다.

AsyncImage(url: URL(string: "String"))
    .frame(width: CGFloat, 
           height: CGFloat, 
           alignment: Alignment)

placeholder와 ProgressView()를 활용한 코드

아래 코드를 이용하면 로딩기능 또한 사용자에게 보여줄 수 있어 유용할 듯 하다.

AsyncImage(url: URL(string: "String")) { image in
    image.resizable()
    } placeholder: {
        ProgressView()
}