[애플디벨로퍼아카데미] Challenge 3

밀린 회고 작성 시작!

유저 이해하기

 두 번째 챌린지가 끝나고 본격적인 팀 챌린지인 C3가 시작되었다. C3의 주제는 유저를 이해하고, 단 한 사람을 위한 앱을 만드는 것이었다. 그동안 나는 주어진 기획과 디자인을 바탕으로 개발만 해왔기 때문에, '유저를 이해한다'는 관점은 나에게 꽤 낯설고도 신선하게 다가왔다. 단순히 개발하는 것을 넘어, 실제로 사용할 사람의 상황과 필요를 깊이 고민해야 한다는 점에서 새로운 도전이자 배움의 기회였다.

 

C3 목표

기술보다는 유저를 이해하는 것에 집중하기

 

 아카데미에서 C2까지 진행하면서, 사이드 프로젝트나 개인 학습을 제외하면 본격적인 개발 경험은 많지 않았다. C3는 본격적인 팀 프로젝트 답게 챌린지 기간도 길고 볼륨도 있으니 기술적으로 성장할 기회가 되겠다는 기대가 있었다. 하지만 막상 주제를 확인해 보니, C3는 개발보다 유저를 이해하는 것에 초점이 맞춰져 있었다. 처음에는 아쉬움도 있었지만, C4가 테크 챌린지라는 것을 알게 되었고, 이번에는 기술보다는 C3 주제와 목표에 맞게 유저를 깊이 이해하는 경험에 집중하기로 했다.

 

유저 이해하기

X의 어떤 경험을 더 낫게 만들자!

 

 궁극적으로 C2에서는 X의 어떤 경험을 더 낫게 만드는 앱을 만드는 것이고, 그러기 위해서는 유저를 이해해야했다. 유저를 이해하기 위해 우리는 먼저 관찰 조사를 통해 인사이트를 도출했고, 이를 바탕으로 리서치 플랜을 수립하여 실제 사용자를 인터뷰하고 페르소나를 작성하는 과정을 거쳤다. 하지만 막상 해보니 유저를 이해한다는 것이 생각보다 훨씬 어려웠다. '페르소나'라는 개념조차 처음 접했고, 리서치 플랜을 구체적으로 세우는 일도 쉽지 않았다. 리서치를 진행하면서 단순히 질문을 던지는 것이 아니라, 상대방의 감정을 이해하고 공감하는 태도가 필요했다. 또, 인터뷰 일정을 조율해야 하고, 유도 질문을 피하며, 주제를 곧이곧대로 묻지 않고 자연스럽게 대화를 이끌어야 한다는 점 등 고려해야 할 부분이 많았다. 이런 과정 속에서 나는 유저 리서치가 단순한 절차가 아니라, 세심한 준비와 태도를 요구하는 과정임을 경험할 수 있었다. 

 

나에게는 쉽지 않았던 C3

 돌아보면 나에게 C3는 결코 쉽지 않은 챌린지였다. 팀원 간의 소통에서 어려움이 있었고, 각자 목표와 열정의 방향이 조금씩 달랐던 점도 영향을 주었다. 무엇보다도 주제가 세 번이나 바뀌는 과정을 겪으면서 자연스럽게 다른 팀들과 진행 속도에 차이가 나기 시작했고, 그로 인해 조급함과 부담감을 느끼기도 했다. 이런 상황 속에서 계획을 다시 세우고 팀의 방향성을 맞춰과는 과정은 쉽지 않았지만, 그만큼 많은 고민과 성찰, 성장을 하게 된 챌린지였다.

 

그래서! 이번 챌린지를 통해 경험한 과정을 바탕으로, 내가 배운 점과 느낀 점을 간단히 정리해보려 한다..!

 

1. 내가 생각하는 좋은 팀원이란 무엇일까?

 내가 생각하는 좋은 팀원이란 단순히 개발을 잘하거나, 디자인을 잘하거나, 재밌는 팀원만을 의미하지 않는다. 물론 그런 능력과 역할도 중요하지만, 가장 좋은 팀원은 서로 소통이 원활하게 되고, 함께 성장하고자 하는 열정을 가진 팀원이라고 생각한다. 기술이나 역량은 시간이 지나면서 충분히 채워나갈 수 있지만, 소통과 열정은 팀의 방향성과 분위기를 결정짓는 핵심이 되기 때문이다.

 

 함께 목표를 향해 나아가면서 어려운 상황이 오더라도 솔직하게 이야기하고, 상대의 입장을 이해하려 노력하며, 작은 성취에도 같이 기뻐할 수 있는 팀원. 내가 생각하는 좋은 팀원이란 결국 함께 있을 때 더 나은 내가 되도록 만들어주는 사람이라고 생각한다.

 

❓ 그래서 나는 좋은 팀원이었을까?

 아마 누군가에게는 좋은 팀원이었을 수도 있고, 또 누군가에게는 그렇지 않았을 수도 있다. 나를 돌아보면, 상대의 입장을 이해하려는 노력이 충분했는지에 대해서도 아쉬움이 남는다. 나는 기본적으로 정해진 규칙은 반드시 지켜야 한다고 생각하는 사람이다. 시간 약속이나 기본적인 규율은 당연히 지켜야 한다는 태도인데, 이런 모습이 누군가에게는 책임감 있게 보였을지 몰라도, 또 다른 누군가에게는 융통성이 부족하게 느껴졌을 수도 있다. 특히 내가 중요하게 여기는 기준을 상대방이 다르게 받아들일 때, 그것을 충분히 이해하거나 유연하게 대처하지 못했던 것 같아 아쉬움이 남는다. 

 

2. 쿠션어 멈춰!

 나는 평소에 쿠션어가 참 많다. 해야 할 말을 끝내 하지 못하고, '이렇게 말하면 상대방이 기분 나빠하지 않을까?'하는 내적 갈등 속에서 내 의견을 솔직하게 이야기하지 못하는 경우가 많다. 물론 배려라는 측면에서 나쁜 습관만은 아니지만, 중요한 결정을 내려야 할 때조차 내 의견을 충분히 드러내지 못하는 경향이 있었다. 그래서 이번 C3에서는 의식적으로 쿠션어를 줄이려고 노력했고, 실제로 이전보다 훨씬 솔직하게 말할 수 있었다고 생각한다. 

 

3. 드라이버는 쉽지 않았다

 팀 프로젝트를 하면서 누군가는 팀의 방향을 이끌어나가는 드라이버 역할을 맡아야 했다. 내가 느끼기에는, 나를 포함해 우리 팀원 모두가 드라이버로서의 역량은 아직 부족했다. 하지만 부족했기에 성장하기 위해 우리가 아카데미에 모였다고 생각한다. 팀원들이 어떻게 느꼈을지는 알 수 없지만, 적어도 나 자신은 드라이버 역할을 했다고 느낀다. 먼저 나서서 팀 활동을 이끌고, 내부적인 갈등이 생길 때는 팀원들의 의견을 하나하나 들어가며 조율하려고 노력했다.

 

 그렇다고 해서 내가 좋은 드라이버였던 것은 아니다. 때로는 감정적으로 판단한 순간도 있었고, 때로는 갈등을 정면으로 해결하기보다는 방관하며 시간이 해결해주길 바란 적도 있었다. 드라이버라면 더 단호하게 방향을 잡아야 할 때도 있었지만, 그런 순간마다 미흡한 부분도 분명히 많았다. 다만 이 과정을 통해 드라이버라는 역할이 단순히 앞장서는 것이 아니라, 팀의 흐름을 읽고 균형을 잡으며 모두가 같은 방향을 바라보도록 만드는 책임임을 알 수 있었다.

 

디발자

 이번 C3에서는 개발에만 집중할 줄 알았지만, 팀의 상황상 어쩔 수 없이 디자인까지 맡게 되었다. 다행히 C2 때 피그마를 다뤄본 경험이 있어서, 일단 할 수 있는 데까지는 해보기로 했다. 하지만 나는 디자인 감각이 거의 없기 때문에 무에서 유를 창조할 만큼의 역량은 없었다. 그래서 다른 레퍼런스를 참고해가며, 거의 베끼듯이 시작한 뒤 조금씩 수정하고 보완하는 방식으로 디자인을 진행했다. 

 

 C2 때는 피그마로 간단하게 화면을 그릴 줄 아는 정도에 불과했다면, C3를 통해서는 컴포넌트, 디자인 시스템, 레이아웃 가이드, 펜툴, 플러그인, 오토레이아웃 등 피그마의 다양한 기능들을 다룰 수 있게 되었다. 아직 전문적인 수준은 아니지만, 간단한 디자인 작업은 스스로 해낼 수 있을만큼은 성장했다고 느낀다.

 

1. UX Writing

 위의 작업은 내가 디자인한 온보딩 화면이다. 화면을 그리는 작업 자체는 레퍼런스를 참고해 만들 수 있었기 때문에 크게 어렵지 않았다. 하지만 진짜 어려운 부분은 UX Writing이었다. 어떻게 하면 사용자가 쉽게 이해할 수 있을지, 또 짧은 문장 안에서 필요한 메세지를 정확하게 전달할 수 있을지를 고민하는 과정이 생각보다 훨씬 까다로웠다.

 

2. 디발자

 개발자로서 피그마를 다룰 줄 알고, 기본적인 디자인 개념을 이해하고 있는 것은 앞으로 큰 도움이 될 것이라 생각한다. 특히 디자이너와 협업할 때, 디자이너가 어떤 과정을 거쳐 결과물을 만드는지, 그 과정에서 어떤 고충을 겪는지를 조금이나마 이해할 수 있기 때문이다. 단순히 결과물만 받아 개발하는 것이 아니라, 디자인 의도를 파악하고 필요할 때는 함께 고민하며 더 나은 방향을 제안할 수 있다는 점에서 이번 경험은 의미가 컸다.

 

Tech! Tech!

1. SwiftLint

 이번 챌린지에서는 SwiftLint를 도입해 간단한 룰셋을 적용했다. 이전까지는 단순히 팀원이 미리 설정해둔 룰셋을 따라 사용하기만 했는데, 이번에는 직접 개발자들과 이야기를 나누며 어떤 룰을 적용할지 함께 정하고 세팅하는 경험을 해보았다. 생각보다 훨씬 많은 룰이 있었고, 세부적으로 커스텀까지 가능하다는 점이 흥미로웠다. 잘만 활용하면 코드 컨벤션을 자연스럽게 맞출 수 있고, 팀 전체의 코드 품질을 일정하게 유지하는 데 큰 도움이 될것이라 느꼈다.

 

 가장 아쉬운 점은, 개발 일정에 차질이 생겨 결국 데드라인 안에 개발을 맞추지 못할 것 같다는 압박이 생겼고, 그 과정에서 어쩔 수 없이 몇몇 룰을 어기며 개발을 진행했다는 것이다. 규칙을 지키는 것이 코드 품질을 높여준다는 걸 알면서도, 눈앞의 일정에 쫓기다 보니 우선순위가 밀려난 순간들이 있었다. 이 경험을 통해, 단순히 린트를 적용하는 것에서 끝나는 게 아니라 일정 관리와 코드 품질 사이에서 균형을 잡는 것 또한 팀에게 중요한 과제임을 깨달았다.

 

 또, 어떤 팀원은 린트에 대해 부정적인 시각을 가지고 있었다. “굳이 경고를 띄울 필요가 있을까? 오히려 거슬리기만 한다”라는 의견이 있었고, 결국 린트를 제외하고 개발한 팀원도 있었다. 그 모습을 보며 나 역시 간단한 프로젝트라면 과연 린트가 꼭 필요할까? 하는 생각이 잠시 들기도 했다. 하지만 아카데미에서의 이번 챌린지는 단순히 결과물을 내는 데 목적이 있는 것이 아니라, 성장을 위한 경험을 쌓는 과정이기에 우리가 린트를 도입한 것이라고 생각한다. 결과물의 완성도뿐만 아니라 협업 방식과 코드 습관을 함께 배우는 것이 더 중요했기 때문이다.

 

2. 코드 리뷰

 나는 코드 리뷰를 굉장히 좋아한다. 다른 사람의 코드를 보면서 배울 점도 많고, 내가 미처 생각하지 못했던 부분을 다른 시각으로 바라볼 수 있기 때문이다. 그래서 이번에도 우리 팀은 “코드 리뷰를 적극적으로 하자”라는 팀 규칙을 정하고 개발을 시작했다. 초반에는 코드 리뷰가 활발하게 이루어졌고, 서로의 코드를 보며 작은 개선점들을 나누는 과정이 즐겁고 유익했다.

 

 하지만 시간이 지날수록 상황이 달라졌다. 프로젝트가 진행되면서 데드라인의 압박이 커졌고, 결국 코드 리뷰 역시 린트와 마찬가지로 우선순위에서 밀려나게 되었다. 빠르게 기능을 완성하는 것이 더 중요해지면서 리뷰 과정이 간소화되거나 아예 생략되는 경우도 생겼다. 이 경험을 통해 코드 리뷰가 단순히 “좋으면 하는 것”이 아니라, 일정 안에서 어떻게든 체계적으로 자리를 잡아야 유지할 수 있는 문화라는 점을 깨달았다.

 

3. SwiftUI에서 View를 정의하는 방법에 대한 고민

 나는 SwiftUI에서 뷰를 정의하는 방식에 대해 많은 고민을 했다. 같은 팀원이었던 Hong과도 이 주제로 여러 번 이야기를 나누며 함께 고민했다. 아카데미에는 자체적인 컨벤션이 존재했는데, 거기서는 "모든 뷰를 Struct로 정의하고, @ViewBuilder 함수나 computed property로 정의하는 것은 지양한다"는 원칙을 권장하고 있었다.

 

 하지만 나와 Hong의 생각은 조금 달랐다. 나는 특히 computed property를 어디까지 허용할 것인가에 대해 많은 고민을 했다. 내가 computed property를 사용하는 기준은 다음과 같다.

 

1. 다른 곳에서 재사용하지 않을 경우

2. 상태(state, binding)나 조건 분기 등의 로직이 없을 경우

3. 빠르게 프로토타이핑하거나 임시 UI를 구성할 경우

 

 이러한 조건을 만족한다면 굳이 별도의 Struct로 분리하기보다는 computed property로 정의하는 편이 더 효율적이라고 생각했다.

 

computed property를 쓰는 이유는 명확하다.

✅ 불필요하게 Struct를 만들 필요 없이 간단히 선언해서 빠르게 사용할 수 있다. (가볍고 간결함)

✅ 하나의 View 파일 안에서 body와 관련된 뷰를 한눈에 볼 수 있어 가독성이 좋아진다.

 

즉, 나는 computed property가 가볍고 간단한 UI 분리에는 오히려 유리하다고 생각했다. 그래서 단순히 “지양하라”는 권장사항을 곧이곧대로 따르기보다는, 상황에 따라 효율적인 선택을 하는 것이 더 합리적이라고 판단해 computed property를 활용했다.

 

 이 부분에 대해서 멘토분들에게도 여러 차례 조언을 구했다. 돌아온 답변은 대부분 비슷했다. "컨벤션적인 부분이기 때문에 팀의 스타일에 맞게 정하면 된다." 결국 정답이 있는 문제라기보다는, 팀이 어떤 방식을 일관성 있게 선택하느냐가 더 중요하다는 것이다.

 

마무리!

 길고 길었던 C3가 드디어 마무리되었다. 힘들지 않았다고 하면 거짓말일 것이다. 진행 당시에는 정말 지치고 마음고생도 많았지만, 되돌아보면 그만큼 많은 성장을 이끌어낸 챌린지였다. 유저 이해부터 디자인 역량, 팀원과의 갈등 해결, 협업 스킬, 그리고 개발 스킬까지 정말 다양한 영역에서 부딪히고 배우며 성장할 수 있었다.

 

 C3는 나에게 단순한 챌린지가 아니라, 개발 외에도 팀워크와 사용자 중심 사고가 얼마나 중요한지 몸소 느끼게 해준 경험이었다. 물론 아쉬움도 남지만, 이 경험을 밑거름 삼아 다음 챌린지에서는 더 나은 모습을 보여주고 싶다. 다가올 C4는 기술 중심의 챌린지이기 때문에, 이번에는 정말 개발에 온전히 집중하며 성장하고 싶다. C3에서 쌓은 경험을 발판으로 삼아, 더 깊이 있는 개발 역량을 키워나가는 것이 나의 다음 목표다!!