[Apple Developer Academy @ POSTECH] #6 - Vision에서 출발한 30일. 팀 Visionable의 여정

🍎 Apple Developer Academy @ POSTECH 4기 : Challenge 4 회고 (2025.06.23 - 08.01)

[Apple Developer Academy @ POSTECH] #5 - 사람공부

 

지금까지 아카데미에서의 챌린지를 돌아보면, 항상 하드 스킬보다는 소프트 스킬을 위주로 성장해왔던 것 같습니다. (물론 하드 스킬 측면에서 얻은 게 없었다는 의미는 아닙니다..!)

아카데미의 열린 사고 방식을 배워가는 과정이었던 첫 번째 팀 챌린지,
타인의 성장을 돕는 것과 나의 성장 사이의 고민거리를 안겨주었던 두번째 개인 챌린지,
팀원에 대한 이해, 사용자에 대한 이해, 그리고 우리 앱에 담게 될 근거들을 떠올리는 과정 자체를 배울 수 있었던 세 번째 팀 챌린지까지.
아카데미가 아닌 다른 곳에서는 쉽게 일어나지 못했을 사고의 확장이 저에게 일어나고 있었습니다.

이번 네번째 팀 챌린지만큼은 이전 챌린지와 다르게 테크니컬 스킬을 향상시키는데 집중했습니다.

솔직하게 아카데미에 대한 오해 아닌 오해(?)로 있는 것이,
기술적으로 성장하기 위해서는 아카데미의 챌린지보다 개인 사이드 프로젝트나 스터디 등을 참여하는 것이 더 도움이 된다더라. 라는 말이 많았기에.
다른 외부에서가 아닌 내부 아카데미의 챌린지에서 이 말이 오해라는 것을 확인해보고 싶었습니다. 챌린지로 하여금 기술 학습을 깊게 해보고 싶었죠.
그리고 아래와 같은 구체적인 목표를 세우고 이번 챌린지에 들어가게 되었습니다.

• 이번 챌린지에서 사용하게 될 기술 (SwiftUI와 Apple Framework 등등..)을 깊게 이해하고 사용하기.
  -> 단순히 사용해보는 것이 목적이 아니라, 스스로 학습하는 과정을 거쳐 기술을 이해하고 사용하는 것을 목적으로 한다는 의미 !
• 여러 명이 개발로 협업했을 때 생산성을 높이기 위한 노력하기.
  -> 읽기 쉽고, 가독성 높은 코드를 짠다는 클린 코드 (Clean Code) 원칙 참고, 정해져 있는 아키텍처가 아니라 프로덕트에 적합한 아키텍처 고민, 코드 통일성을 위한 Lint와 Convention을 활용해보자 !
• 작성한 코드도, 팀의 분위기도, 만든 프로덕트도 너무너무 좋아 30일이 너무 짧고 아쉽게 느껴질 수 있는 챌린지. 그래서 챌린지 이후에도 계속 이어갈 수 있는 팀 만들기.

이런 목표들로 시작했던 아카데미에서의 네 번째 챌린지 회고 지금부터 시작합니다💨

 

#1. 기술에서 출발하는 서비스

많은 아이디어를 기획해보고 그 아이디어들을 실제 동작하는 앱으로도 꽤 많이 만들어봤지만, 그 시작이 기술이었던 적은 없었습니다.

학교 캡스톤, Swift Student Challenge, 사이드 프로젝트, 해커톤 등의 그간 많은 경험에서
사용하고 싶은 기술을 바탕으로 아이데이션을 시작하는 것은 신박한 아이디어를 떠올리는데 있어 장애물로 작용한다는 배움이 있었기 때문이었죠.
그래서 보통은 <일상 속 어려움> <아직 세상 속 해결 못한 문제점> <불편함을 느끼는 사람>을 찾아 아이디어를 떠올린 다음, 서비스의 컨셉을 잡고, 그 컨셉에 적합한 기술을 찾게되는 흐름으로 이어져 왔습니다.

하지만 이번 챌린지만큼은 다른 흐름으로 시작하게 됩니다.
흥미있는 기술을 먼저 선택하고, 그 기술을 찰떡같이 녹일 수 있는 아이디어를 떠올려본 것이죠. 당연하게도 우려되는 지점이 많았습니다.

---

하지만 항상 아카데미가 그랬던 것처럼 우려는 우려에 불과했습니다.
오히려 그동안 기술을 바탕으로 아이데이션을 진행했을 때 왜 생각이 갇히게 되었는지에 대한 원인과 과정들을 되돌아볼 수 있었습니다.

왜 그 기술을 사용하고 싶은지에 대한 뚜렷한 목적도 없었고 (보통 그냥 재밌어보여서 & 신기하니까 & 트렌드가 되는 기술이니까가 전부였습니다).
기술에 대한 이해와 학습의 깊이 또한 얕았기 때문에 많은 발산이 이루어질 수 없었다고 생각합니다.
생각보다 기술은 우리에게 많은 것을 제공해주고 있었고,
사용할 우리들은 기술에 대한 깊은 이해와 목적을 갖기만 한다면 우리 삶 속 어려움을 찾는 것보다 어쩌면 더 넓게 아이데이션을 확장시킬 수 있다는 것을 알게 되었습니다.

우리 팀의 기술 주제였던 Computer Vision에 대한 깊이를 갖기 위해 팀원 전체가 Vision 프레임워크 학습을 깊게 진행했죠 !

문제는 그 깊이를 팀원들과 어느 수준까지 함께 가져갈 것인가였습니다.

개발을 담당하는 테크 러너들이야 직접 기술을 활용하고 구현해야하는 입장에서 깊게 공부하면 할수록 더 도움이 되겠지만,
디자이너나 기획자의 입장에서 깊게 학습하기에는 활용도와 난이도 면에서 어려운 점이 많을 것이기 때문이죠.

이번의 경우, 프로젝트의 목적 자체가 기술 챌린지였기에 그래도 어느정도까지는 깊이 있는 학습을 함께 가져갈 수 있었습니다.
재밌는 여러 애플의 기술 중에서 저는 시각적인 요소를 활용해 볼 수 있는 카메라나 인공지능의 컴퓨터 비전 분야를 선택했고, 그중 Vision이라는 애플의 프레임워크를 깊게 공부하게 되었습니다.
우선 Vision이라는 프레임워크에서 애플이 제공하고 있는 33개의 API를 크게 카테고리화했고, (얼굴 및 신체 감지, 텍스트 감지, 객체 추적 등..)
각각의 API가 어떻게 요청을 보내고, 어떤 결과값을 제공해주는지. 그리고 이 결과값을 바탕으로 실제 프로덕트에는 어떻게 활용할 수 있는지 등을 공통의 템플릿으로 만들어 팀원 전체가 같은 싱크 (sync)로 학습하는데 도움이 되도록 했습니다.

*어떻게 해야지 팀원 전체가 깊이 있게 공부해보면서 Vision에 대한 흥미도 갖게 하고, 너무 어렵지 않게 학습할지 고민을 많이 했습니다.
이후 회고를 하면서 팀원들이 이 순간이 이번 챌린지에서 의미있는 학습의 순간이었다고 말해주는 게 되게 고마웠어요 ...^__^

---

여기서 한 단계 더 들어가보죠.

이번 팀에서 처음 Vision이라는 기술을 이해할 때 인상 깊었던 점은
Computer Vision이 인간의 "눈"을 바탕으로 만들어진 기술이고, 이번 챌린지에서는 어떤 눈으로써 Vision 기술을 활용할 것인지 고민했던 부분입니다. (프교수님이 산발적으로 발산되고 있는 과정에서 중간에 딱 이렇게 정리를 해주셨어요😊)

1. 볼 수 없는 사람을 위한 눈 (시각적 접근이 어려운 사람들을 돕기 위한 대체 감각 도구로써 Vision을 활용하는 방법)
2. 볼 수 없는 위치에 대한 눈 (사람이 직접 볼 수 없는 사각지대나 아주 먼 거리, 위험한 곳의 정보를 파악하기 위해 Vision을 활용하는 방법)
3. 인간의 또 다른 눈 (사람이 볼 수 있지만 피로하거나 놓칠 수 있는 정보를 파악하는데 도움을 주도록 Vision을 활용하는 방법)
4. 제 3자의 눈 (행동, 사물, 움직임 등을 지속적으로 감시하거나, 분석하는데 관찰자로서 Vision을 활용하는 방법)

이 이후는 취향의 영역이었습니다.

기술에 대한 팀원들의 흥미도를 바탕으로 카테고리를 좁혀나가고,
여러 기술별 그리고 도메인별 (교육, 예술, 건강, 생산성 등등..) 아이디어 발산 과정과 구체화, 수렴 과정을 반복해 우리 팀의 서비스 솔루션 컨셉을 정할 수 있었죠.

그리고 아래와 같은 한 문장으로 우리 팀의 이번 챌린지 솔루션 컨셉을 정하게 됩니다.

Computer Vision 기술을 활용해,
카메라로 텍스트 정보를 인식 (RecognizeTextRequest)하고 사용자가 찾고자 하는 특정 대상을 빠르고 정확하게 찾게 해주자.

 

 

#2. Challenge 3에서 배웠던 "사람 공부" 업그레이드 ver.

지난 세 번째 챌린지 회고 글에서는 팀원 모두가 백 퍼센트 만족하는 하나의 솔루션을 정하는 것은 (거의) 불가능에 가깝다고 적었는데요. 
이번 챌린지의 결과물을 보면 여섯 명의 팀원이 꽤 높은 만족도로 함께 앱을 만들어나갔고, 완성해 앱스토어 릴리즈까지 끝냈습니다.

거의 불가능에 가깝다고 말한 것을 스스로 뒤집어버린 셈인데요.

지난 Challenge 3의 사람 공부와 이번 Challenge 4의 사람 공부는 어떤 점에서 더 발전되었는지. 어떤 점을 다르게 가져갔는지. 되돌아보고자 합니다.
일단 하나의 솔루션 컨셉을 정하기까지의 과정이 위에 적은 것처럼 그리 원활하게만 진행된 것은 아니었다는 점 !
*각자의 관심사나 만들고 싶은 결과물을 다르게 그리기도 했구요. 모두가 납득되지 않았는데 일단 진행하려고 했던 저의 미숙한 포인트도 있었구요. 확정한 컨셉을 뒤엎고 다시 앞으로 되돌아가기도 했구요.

---

일단, 명확한 목표를 세우는 것이 중요하다는 점을 다시 초반에 놓쳤던 것 같습니다.

팀이 처음에 결성되고 팀 빌딩 (Team Building)이라는 과정을 거치며, 팀 규칙 (Norms)이나 개인 목표 (Goals)를 나누는 시간을 갖습니다.
보통 이 기간에 가장 많이 나오는 말들이 있습니다. 저희 팀도 그렀고요.

이번 챌린지에서 성장하고 싶어요! / 재미있게 챌린지 기간 보내고 싶어요! / 많이 배우고 싶습니다!

"성장", "재미", "배움"이라는 단어는 새로운 시작의 목표로 설정하기에 충분히 납득가능합니다.
하지만 이 단어 자체로만 목표를 세우는 것은 어딘가 명확하지 않고 불충분할 수 있습니다.
처음에는 몰랐지만, 챌린지를 진행하면서 같은 단어이기에 같은 목표로 달려가고 있다 생각했던 것이 / 알고 보니깐 미세하게 우리의 목표는 달랐다는 것을 느낄 수 있었거든요.

성장하기 싫고, 재미있기 싫고, 배우기 싫은 사람이 어디있을까요? 

중간 <대토론회> 시간을 가지고, 아이디어를 갈아엎기 전 우리 팀의 목표를 다시 정리해봤습니다.

단순한 성장, 재미, 배움이라는 단어와 함께 아래와 같은 질문을 바탕으로 목표를 세웠을 때 우리 팀의 목표는 더욱 명확해질 수 있었습니다.

• 나는 어떤 성장을 하고 싶은 것일까? 
  : 난이도가 있는 기술을 많이 두루두루 사용해보는 것인지. 하나의 기술을 깊게 파보는 경험을 하고 싶은 것인지. 아예 그동안 해본적 없던 새로운 것을 시도해보는 것인지. 원래 하던 분야를 더 발전시키는 것인지.
  
  
• 우리 팀이 원하는 재미의 방향은 어느 쪽이지?
  : 정말 아이템 자체가 신박하고 들어본 적 없는 웃긴 것을 만들고 싶은지. 팀의 분위기가 재미있고 싶은 것인지. 배움의 과정에서 오는 재미를 말하는 것인지. 일단 빠르게 만들고 이후에 앱을 발전시켜나가면서 얻는 재미인 것인지. 출시 자체가 재미인건지.

---

 

그리고 그 기준을 세웠다면, 이후에는 흔들리지 않을 팀원 서로간의 신뢰가 필요했습니다.

☑️ 정했다고 생각했던 내용을 파기하고 다시 앞으로 돌아갈 수 있는 것도 -> 앞으로 돌아가는 것이 나중을 생각할 때 오히려 더 빠른 길이라는 믿음이 있었고. 예전에 정했던 것보다는 더 나은 아이디어를 발산할 수 있을 것이라는 신뢰가 있었기에.

☑️ 현재까지 진행된 내용에서 스스로에게 납득되지 않는 점이 있다고 팀원들에게 말할 수 있는 것도 -> 내가 이 내용에 대해 브레이크를 걸더라도 우리 팀원들은 이를 이해해주고 우리 팀 플로우에 내 의견이 반영될 수 있다는 확신이 생겼기에. 

☑️ 질문과 논의를 거쳐 다른 팀에 비해 속도가 느린 것 같아도 -> 결국 시간 내에 프로덕트를 만들어낼 수 있는 역량을 가진 팀원들이 있다는 신뢰가 있었기에. 혹은 완성하지 못하더라도 이 과정에서 배운 점이 분명히 있을 거라는 신뢰가 있었기에.
근본적으로는 우리 팀이 걸어가고 있는 길이 예전보다 더 나은 길이라는 것은 분명히 모두가 알고 있었기에.

사용자에 대한 이해보다, 팀원 서로 간의 이해에 더 집중했던 이번 Challenge 4의 사람 공부였습니다.
Challenge 3에서 느꼈던 팀 분위기 바꾸기, 팀 내부의 납득, 솔루션 컨셉에 대한 확신 역시 함께 더 발전해서 가져가기도 했었구요. 아무튼 그렇습니다. 확실하게 배운 점이 있었습니다.

 

 

#3. 찰떡같이 기술을 사용하기 위한 우리의 노력, 겉으로 보여지는

다시 돌아와서 기술 얘기를 더 이어가보도록 하겠습니다.

위에서 기술에 대한 얘기를 이미 했지만, 구체적으로 이것을 어떻게 활용할지에 대한 수준은 나름대로 세 가지 깊이가 있다고 생각합니다.
이 세 가지 깊이 중에서 이번 챌린지의 목적이,
단순히 기술을 사용해보는 것을 넘어서 깊게 학습하고 / 이를 찰떡같이 앱에 녹여본다는 점에서 2단계 학습과 3단계 응용에 있다고 이해했죠.

🥹 스스로 만들어본 기술 활용의 3단계 깊이

1단계 (구현). 이번 프로젝트에서 어려운 00 기술을 사용해봤습니다. 그 과정에서 이런 트러블 슈팅이 있었고, 해당 과정을 거쳐 앱에서는 이렇게 저렇게 문제없이 동작하도록 구현을 했죠!
2단계 (학습). 기술을 깊게 파봤습니다. 단순히 기술을 사용하는 것에서 목적을 두는 것이 아니라, 그 기술의 내부 원리나 발전 과정, 한계점 등을 함께 학습하는 것을 목적으로 두었습니다.
3단계 (응용). 기술의 목적을 바탕으로 우리 서비스에 녹여봤습니다. 단순히 사용했기에 앱에서 동작합니다 수준 x. 이 기술을 사용하고자 만들어낸 서비스가 아니라, 서비스에 이 기술이 응용됨으로써 확실하게 어떤 포인트에 개선이 일어난 수준 o)

그렇기에 단순히 이런 기술이 있다 정도를 넘어서, "왜 애플은 이런 API를 개발자들에게 새롭게 지원한 것일까?" 를 알아가려고 노력했습니다.

한 예시로 애플은 WWDC25에서 Vision의 DetectLensSmudgeRequest라는 새로운 API를 소개했습니다.
해당 API는 카메라 렌즈에 지문, 먼지, 물방울 등으로 인한 얼룩(스머지) 이 있는지를 자동으로 감지해서 confidence 값을 제공해주는 녀석이었는데요.

왜 이런 API를 애플이 새롭게 지원했을까를 생각해보면,
1차적으로는 카메라 촬영시에 보다 사용자가 정확하고 깨끗한 이미지를 촬영할 수 있도록 도와준다의 목적을 떠올렸습니다. (이미지의 미적 품질을 정량화된 점수로 뽑아주는 CalculateImageAestheticsScoresRequest와 같은 맥락으로 제공된 것이 아닐까?)
여기서 한걸음 더 나아가 생각해보면, 결국은 이미지나 영상을 분석해주는 Vision 프레임워크에 있어 그 이미지가 깨끗하지 않다면 = 분석이 불가능할 정도로 얼룩이 묻어있는 이미지인 경우에 Vision 성능을 기대조차 할 수 없다는 점에서 Vision 성능의 최소점을 제공해준다의 목적을 떠올릴 수 있었습니다.

-> 즉! Vision을 사용하는 경우 어쩌면 default로 해당 API를 통해 촬영된 이미지를 필터링하는 역할로 해당 API를 사용할 수 있겠다! 라는 흐름을 가져올 수 있었죠.
이런 방향에서는 "인공지능을 우리 앱에 사용했어! 대단하지?"의 사고가 아니라 "이런 식으로 인공지능을 앱에 녹여봤어! 도움이 되지?"의 사고로 이어갈 수 있었던 것 같습니다.

Vision이 우리 팀의 기술 주제였지만, 이를 잘 녹이기 위해서는 Swift Concurrency에 대한 활용이 필수적이었습니다.

같은 맥락에서 Vision이라는 기술을 활용하기 위해 함께 활용했어야 하는 기술로 Swift Concurrency를 선택했습니다.
머신러닝 프레임워크를 요청하는 API는 앱 백그라운드에서 비동기로 처리되어야 하고 -> 비동기 처리에서 발생할 수 있는 Data Race 문제를 보호할 필요가 있었고 -> 이 Data Race를 방지하는 개념에서 사용된 actor나 Swift 6를 적극적으로 도입하게 된 흐름으로 이어졌습니다.

---

Vision 외에 겉으로 보여지는 기술도 많이 활용하기도 했습니다.

학습에 대한 욕심이 있었던 것도 사실이었지만,
이 중에서 "그저 사용해보고 싶어서" 사용한 기술은 단 하나도 없었고. 기술 하나하나 모두 "사용이 필요한 목적성"을 갖고 앱에서 활용했습니다.

• 시각적으로 불편한 분들에게 우리 앱이 확장되어 도움이 될 수 있지 않을까? 라는 고민 포인트
  -> VoiceOver 지원해보자 + Speech를 사용해 키보드를 치지 못하더라도 원하는 내용을 입력할 수 있도록 해주자
• 시각적으로 불편한 분들이 음성 검색까지 접근하는 과정을 한 단계 빠르게 만들 수는 없을까? 라는 고민 포인트 -> Widget을 지원하면 하나의 Depth가 줄어 조금이라도 쉽게 접근할 수 있지 않을까!
• 외국인들이 우리나라의 지하철 노선도 or 우리나라 사람이 외국에 나가서 버스 정류장을 찾는 시나리오로 확장할 수 있지 않을까? -> Localization을 지원해야겠다는 생각! (단, 모든 언어를 지원하기에는 Vision이 갖는 역할이 많아져 발열 문제로 이어질 수 있으니. 일단 검증된 한국어와 영어만 우선 지원)

앱을 시연할 때, 라이트/다크, 보이스오버, 한국어/영어, 위젯까지 지원할 수 있는 다양함을 모두 보여주고자 했습니다.

 

 

#4. 찰떡같이 기술을 사용하기 위한 우리의 노력, 겉으로 드러나지 않는

위의 내용은 겉으로 드러나는 기술을 활용한 내용입니다.
하지만 이것 말고도 이번 기술 챌린지에서는 사용자에게 보이지 않는 부분의 기술 활용도 함께 고민했습니다. 아래 말 때문이었죠.

"협업해서 개발하는 것이 혼자 개발하는 것보다 어떤 점에서 더 낫다고 말하는지 모르겠다"

누구에게는 일정 부분 공감되는 말일 것입니다.

사실 협업해서 개발하면 혼자일 때는 크게 신경쓰지 않아도 되는 지점을 신경써야 하는건 사실이니까요.
원래 자신의 코드 스타일을 잠깐 뒤로한 채 팀의 코드 스타일을 맞춰야 하는 부분. PR이나 코드 리뷰로 내 코드/다른 사람의 코드를 자세하게 설명해야 하는 부분. 다른 사람이 짠 코드를 이해하고 있어야 하는 부분 등 골칫거리가 한두 개가 아닙니다.

그럼에도 불구하고, 협업 개발이 가져오는 장점 또한 분명한 것은 사실입니다.
그리고 1인 개발자가 목표가 아니라면 혼자 개발하게 될 일은 아마도 거의 없을테니까요!

이왕이면 다홍치마라고 어차피 여러 명이서 함께 협업해야 한다면, 단점보다는 장점을 극대화할 수 있는 방향을 이번 챌린지에서 유도하고자 노력했습니다.

---

하나의 방법은 팀에서 코드 리뷰를 적극 활용하는 것이었습니다.

한 명의 개발자가 모든 내용에 다 전문적일 수는 없기에 / 각자의 전문 분야를 이 코드 리뷰 문화로 잘 표현할 수 있었다고 생각합니다.

누군가는 코드 재사용성을 신경쓰도록 코드 리뷰를 통해 확인할 수도 있었고요.
또 누군가는 성능이나 메모리 누수, 더 나은 방법의 구현 방법을 코드 리뷰로 알려줄 수도 있었고요.
모르는 내용을 질문하거나 발견하지 못했던 버그, 심지어는 스스로 확인하지 못한 오타까지 더블 체크로 확인할 수 있기에. 코드 리뷰는 여러 개발자들의 싱크 (sync)를 맞춰나가고, 함께 공부해 나가기에 좋은 방법이었습니다.

코드 리뷰를 잘 활용했던 사례는 예전 토스터 프로젝트에서도 자세하게 써두었으니 이쯤에서 마무리하도록 할게요.

팀에서 적극적으로 PR과 코드 리뷰를 달고 함께 싱크를 맞춰나가기 위해 노력했습니다.

또 하나는 클린 코드 (Clean Code)라던지, 프로젝트에 적합한 아키텍처를 함께 얘기해나갈 수 있었다는 점입니다.

클린 코드 같은 경우에는 어차피 코드 스타일을 통일해서 컨벤션으로 가져가야 한다면,
이 시기에 팀의 코드 스타일이 익숙해질 것이고 -> 팀의 코드 스타일을 클린 코드 (Clean Code) 원칙을 준수하기 위해 노력하기로 한다면 -> 평소 코드 스타일도 클린 코드, 즉 가독성 좋은 코드를 짜기 위해 노력하는 것이 습관화될 수 있다는 기대였습니다.

아키텍처 같은 경우에는 답을 정해두고 이야기하지 않았습니다.
그니까 MVVM이라던지, 클린 아키텍처라던지, TCA라던지 우리 이거 써보자라고 이야기하고 시작한 것이 아니라 팀에 적합한 파일 구조를 분리하면서 팀 규모에 적합한 아키텍처를 만들어나갔습니다.

왼쪽과 같은 논의 내용이 있었고, View-Mediator-Model-Service로 이어지는 우리 팀의 아키텍처를 만들 수 있었습니다.

혼자였다면 이정도로 생각을 확장하지 못했을 것입니다.

무엇보다 내가 제시하는 의견에 동의 혹은 반박해 줄 다른 개발자가 있다는 것.
그리고 정답이 없는 문제에서 함께 정답을 찾아가기 위해 고민할 수 있다는 것. 그 자체가 큰 배움이었고 이번 챌린지의 많은 동기가 되었습니다.

 

 

#5. 그리고 남은 우리 팀.

30일이 어떻게 보면 지금까지 했던 챌린지 중 가장 긴 기간이었는데도 불과하고, 눈 깜빡했는데 지나갔습니다.

늦게까지 회의도 많이 했습니다. 일도 많았고.
매주 하루는 꼭 추억 쌓으러 이곳저곳 돌아다니기도 했고요. 그 우리의 30일 추억을 너무도 고맙게 프로 유튜버 쪼이가 유튜브로 담아주기까지 했어요 ☺️
Hi-fi 갤러리 워크와 마지막 기술 박람회까지 많은 관심과 좋은 피드백도 받아 앱스토어에 최소 기능을 담아 출시도 했습니다.
그리고 부족하지만 예창패도 지원해 봤어요..!

이번에 출시한 FF!p (Fast-Find item picker, 삡)은 여기서 멈추지 않고 앞으로 계속 이어나갈 예정입니다.
구현하면서 공부했던 기술적 내용, 그리고 아이디어적인 내용들은 차차 블로그 글로 이어나가보겠습니다 ! 앱스토어 다운받아줄거죠 ?

[iOS] FF!p (Fast-Find item picker) 삡 - 단어로 위치 탐색

처음부터 어벤저스(?)로 모인 팀이었지만, 같이 일하면서 더더욱 어벤저스라고 느껴졌던 이번 팀원들이었습니다.

누구하나 할 것 없이 정말 높은 engage와 열정으로 끝까지 함께해줘서,
맡은 바 누구하나 포기하지 않고 책임있게 네 번의 스프린트 완수해줘서, 이런 멋진 결과물이 나올 수 있었다고 생각해요 !
여니, 노우, 쪼이, 잼, 후랑크 누구 하나할 것 없이 부족한 저랑 같은 팀해줘서 너무너무 감사했습니다🙇🏻 마지막 챌린지가서도 C4 잊지말자...? 

길었던 삡 회고는 여기까지 !

참 행복했던 30일 이었다 ~