C3 회고 | 차가운 디자이너, 뜨거운 개발자

2025-06-19

C3 회고 | 차가운 디자이너, 뜨거운 개발자

Challenge 3는 이전의 챌린지들보다 기간도 훨씬 길었고, 실제로 프로덕트를 제작하는 프로젝트였다.기록을 하려고 마음을 먹으니 막막하기 시작하네. 몇 번을 해도 적응되지 않는 회고다. 그래도 일단 시작하고 나면 손은 멈추지 않을테니… 써본다.

1. 컨디션 난조, 팀 자동배정

늘 그렇다. 긴장이 풀리면 아프다. 정신적인 이유도 있을 것이고 실제로 브릿지 기간에 식습관이나 수면습관이 엉망이 돼서 그렇기도 하다. 챌린지 시작 전에 할머니의 큰 수술과 어머니의 교통사고 등 다양한 사건들이 있었고 가족들을 케어하는 과정에서 적절한 휴식을 취하지 못했다. 이로 인해… 챌린지 첫 날 결석을 하게 된다. 병원에서 엉덩이 주사를 맞고 나오는 길, 팀즈 메시지가 왔다.

Go는 저희 팀에 자동 배정되었습니다!

주제는 “지방에서 입시미술을 하는 학생의 정보불균형, 이로 인한 서러움” 에 대한 것이었다. 공교롭게도 나만 미대입시를 경험했던 사람이었다. 그래서 주제를 보자마자 숨이 턱 막혔다. ‘이거 못 할 것 같은데…?’ 하는 생각들에 머리가 복잡해졌다.

팀원들은 좋은 사람들 같았다. 나쁜 사람이라는 게 있겠냐만은… 안 맞는 사람은 분명 있으니까. 나름 잘 맞는 사람들을 팀원으로 만났다고 정정한다. 초반 기억이 벌써 흐릿하기는 한데… 팀 빌딩부터 진행했다. 각자 C3에서 얻어가고 싶은 것들에 대해 나누었고, 팀플을 하며 추구하고 싶은 문화나 가치 등에 대해서도 적고 나누는 시간을 가졌다.

합의가 된 부분들을 팀 규칙으로 잡았다. 그 중 재미있던 건 매일 팀 활동을 시작할 때 단체사진을 찍는 것이었다. 겉으로는 왜 굳이 이런걸 하냐, 귀찮다는 식의 표정을 지었지만 속으로는 내심 좋았던 것 같다. 아무래도 한 사진에 담기다 보면 정이 드니까.

우리에게 가장 급한 과제는 챌린지 주제를 명확히 하는 일이었다. “지방에서 입시미술을 하는 학생의 정보불균형”이라는 문제를 해결하려면 플랫폼을 만들거나, 법을 바꿔야 한다. 문화, 토양 자체를 뒤집는 일이기에 분명 가치가 있겠지만 4주라는 짧은 시간동안 수행하기엔 제한이 있다고 생각했다.

대상은 이미 정해졌고, “미대입시”라는 큰 틀은 변하지 않을 것 같았다. 4주 안에 쓸만한 솔루션을 내야 하기에 빠르게 인터뷰 날짜를 잡았다.

2. 주제 잡기

이번 챌린지의 주제는 “Understanding User” 사용자를 이해하는 것.

(아 지금 쓰다보니까 막 설명을 해야 할 것 같은데 그러면 정상적으로 회고 마무리 못한다. 시간도 부족한데…내가 느낀 점 위주로 써보겠다.)

인터뷰를 하는 이유는 당사자를 이해하고, 정말 필요한 솔루션을 제공해주기 위함이다. 이를 위한 다양한 기법들이 존재하지만 가장 중요한 건 명확한 목적성이라고 생각한다. 목적성 없이 기법만 적용하면 말 그대로 “하라는 대로 했는데 왜 안되죠?” 가 되고 만다. 팀 내에서 최대한 흐름을 따라가려고 했고 다만 이 한가지만 계속해서 강조했다. 우리가 뭘 하고 있는지, 왜 이 과정을 거쳐야 하는지에 대해 말이다.

아무튼, 인터뷰를 해보니 우리의 유저 “망고”에 대해 얕게나마 파악할 수 있게 되었다. 체리의 여동생이고, INFP, 외유내강형 인간이었다. 미대입시 중에서 기초조형이라는 분야를 준비하고 있고 목표는 국민대학교 디자인학부 입학. 여러 질문과 답변이 오갔다.

내가 느꼈던 건 “더 깊은 내면을 보기 위해서는 인터뷰만으로는 어렵다” 였다. 물론 인터뷰를 통해 어느정도는 틀을 잡을 수 있겠지. 하지만 사람은 자신에게 정말 필요한 게 무엇인지 잘 알지 못한다. 눈을 감고 모래속에 숨겨진 구슬을 찾아내듯 더듬 더듬 주제를 잡아갔다. 우리가 망고를 위해 주기로 한 솔루션은 “잘 준비되고 있다고 느껴지게 하기” → ”이를 위해 과정에 대한 기록 도구를 제공하기” 였다. 그런데 함정이 있다.

망고가 기록에 대한 니즈를 느끼고 있다는 근거는 우리의 질문에서 비롯된 것이었다. → 유도질문이었다.

하지만 돌이켜보면 어쩔 수 없던 부분도 있다. 이 대목에서 흐린눈을 시전하지 않았다? 더 미궁으로 빠졌을 것 같다. 그리고 어느정도는 이러한 방식의 결론 도출이 최선이 아니었을까 하는 생각도 들었다. 미대입시라는 주제 자체가 창의성을 펼쳐나가기는 참 어렵더라…(이조차도 자기합리화일 수 있음) 챌린지의 진행 흐름 자체가 타이트하기도 했고. 아무튼 이렇게 주제를 잡았더라도 “잘 만들면” 좋은 결과물이 될 것이라 생각했다. 그리고 그건 절반의 정답이었다.

3. 기획, 디자인

결론부터 말해본다. 솔직하게 이야기하면 UX/UI 관점에서 정말 아쉽다. 앱을 구석구석 분석하는 글을 쓰고 싶지만 공수가 너무 많이 들 듯 하고, 간략하게만 적어보면

UX Writing의 일관성이 전혀 없다

프로젝트 카테고리 추가 부분에서의 혼란

앱 자체가 내용이 별로 없음

왜 이랬을까? 흠… 오늘 회고 쓰면서 계속 생각해보고 점심 밀면 먹으면서도 계속 생각해봤다. 나의 짤막한 결론은, 차갑게 일했지만 체계가 부족했기 때문이라는 것. 이게 무슨 말이냐면…

뜨겁게 일하면 체계가 부족해도 좋은 결과가 나오기도 한다.

체계가 갖춰져있다면 차갑게 일해도 좋은 결과가 나올 수 있다.

나는 디자이너로서는 이번 챌린지에 차갑게 임했다. 초과근무를 지양했고, 모여서 무언가 하기보다는 각자 해오거나 세션 시간을 최대한 활용해 작업했다. 그렇게 일해도 잘 될거라고 생각했던 것이다. 하지만 착오가 있었다. 체계가 없는 상황에서 이렇게 일하니 목표했던 지점까지 가지 못하고, 최소한의 기준만 충족하면 다음으로 넘어가는 방식의 일을 한 것이다. (역설적으로 개발자로서는 이번 챌린지에 매우 뜨겁게 임했던 것 같다.)

그렇다면 체계란 무엇일까? 결국 PM 또는 그에 준하는 역할이라고 생각한다. 일정 관리, 업무 분배보다도 중요한 “기준”을 제시하는 사람 또는 약속이 필요했다. 이번 챌린지에서는 그러한 체계가 부족했다는 생각이 든다. 기획과 디자인에서 가장 최우선으로 지켜야 할 가치가 무엇인지에 대해 더 세밀하게 정했어야 했다. 마진이 몇이고 컴포넌트는 어떤 심볼을 가져다 쓰는지보다도…기획 단에서 더 세심하게 생각했어야 했다.

한편으로는 챌린지 자체에 대해서도 생각이 많았다. T자형 인재상을 추구하는 애플 디벨로퍼 아카데미이기에 솔루션을 도출하고 lo-fi를 만드는 과정까지는 모든 인원이 참여하는 편인데, 기획이라는 게 사람이 많다고 수월해지는 게 아니기에 어려움이 있었다. 모두가 원하는 그림이 다르고 얻어가고 싶은 게 다르기에 싱크를 잘 맞춰야 했고, 이 부분에 있어서는 꽤 잘 했던 것 같다. 하지만 모두의 교집합을 도출하다 보니 중요한 본질에서도 손실이 적지 않게 있었던 것도 사실이다. 협업을 잘한다는 게 그런 손실을 최소화하는 능력이 아닐까 싶다.

기획이 어느정도 된 후에 디자인을 하면서도 생각이 많았다. 세 명이서 디자인을 파트별로 나눠서 했는데, 사실 그렇게 나눠서 할 분량이 아니었다. 공정하게 나눠서 하려다 보니 세 개의 작업물을 맞추는 과정이 되레 오래 걸리기도 했다. 파트별로 나누는 것보다는 디자인 안에서도 UX설계, 브랜딩, 프로토타이핑 등 다양한 분야가 있는데 이에 따라 나누는 것이 좋지 않을까 생각해본다. 아무래도 다음에 만날 팀과 협의를 해봐야겠지.

누군가는 이 상황에서 컨텍스트 메뉴를, 누군가는 액션시트를 사용하는 게 맞다고 생각한다면 어떻게 결정해야 할까? 두 의견 모두 근거가 있고 적절하다면?

누군가는 토스의 디자인을 좋아하고 누구는 그렇지 않다. 누군가는 애플의 다이나믹 아일랜드에 감격하고 누군가는 펀치홀이 훨씬 좋다고 이야기한다. 사람의 생각은 전부 다르기에 이러한 의견 조정에 너무 많은 시간을 쓰기보다는 더 큰 그림에서 “좋은 경험”을 이끌어낼 수 있도록 설계하는 연습을 해야겠다는 생각을 많이 했다. 알맹이가 있는 디자인을 하자는 말이다. 알맹이가 먼저고, 디테일이 나중인데 디테일에 시간을 많이 쏟지 않았나 싶다.

다만 사람이 좋았다. 이견이 있어도 적절하게 조정이 되었고, 감정적으로 크게 번지는 일이 없었다는 것 자체가 감사한 일이다. 그래도 깊이있게 디자인에 대해 토론할 수 있는 시간을 가졌다면 더 좋았긴 했을 거다.

4. 개발, 마무리

C2에서 거의 처음으로 깃허브를 사용해봤다. (2년 전엔가 조코딩 유튜브를 보며 따라한 적이 한 번 있었다.) 레포지토리 만들고 커밋하고 푸시하는 과정이 참 신기했다. 디자이너들의 일하는 방식(적어도 나의 관점에서는)과는 완전히 다른 개발자의 일하는 방식…개인적으로는 나와 잘 맞는다고 느끼기도 했고. 좋았다.

C3에서는 깃허브를 이용한 협업을 경험할 수 있었다. 솔찬히 말해서 막막하고 무서워서 안 하려고 했다. 나는 디자이너니까 개발은 정말 필요할 때만 하겠다고 이야기하기도 했더랬다. 사실 그게 나의 회피방식이었던 것 같다. 차갑게(?) 디자인을 하는 동안 개발자 3명은 깃허브 세팅을 하고 템플릿도 만들고 프로젝트 구조도 짜고 하는 걸 멀찍이 지켜봤다. 그러다가 개발기간 중반쯤 Finn의 떠먹여주는 깃허브 강의를 들으며 [각성] 하게 된다.

이거 해볼만한데?

왜 이러한 과정을 거치는지에 대해 자세히 설명을 듣고 나니 어렵고 막막해보였던 과정들, 지켜야 하는 컨벤션들이 수많은 선배 개발자들의 시행착오의 결실임을 느낄 수 있었다. 일을 잘 할 수밖에 없게 만드는 환경이라는 생각도 들었다.

처음엔 이미 발행된 이슈를 하나씩 나에게 Assign해서 해결해보고, Finn에게 “이렇게 하는 거 맞아요?” 물어보고 하는 식으로 진행하다가, 조금 감이 왔을 때부터는 큼직한 이슈도 파서 해보고…점점 일에 매료됐던 것 같다. 코드가 현실에 구현된다는 게 벅차기도 하고, 예전에는 마냥 어려워 보였던 일을 내가 하고 있다는 게 가슴이 웅장해진 것도 있다.

이슈를 하나씩 하나씩 쳐내다보니 주말이 왔고 주말동안에도 하나씩 하나씩 하다보니 새벽까지 코딩을 하고 있는 스스로를 발견했다. 줄 단위로 코드에 대해 리뷰를 달기에 실전 경험과 공부가 동시에 되기도 했다. 다만 아직까지는 철저히 패턴을 지켜야 한다는 것에 대해서는 와닿지 않는 것 같다. 워낙 성격 자체가 필요성을 느껴야 따르는 스타일이라 그런 것도 있겠지.

나의 ios 첫 프로젝트는 한 파일에 모든 뷰와 로직이 합쳐져 있었다. 하지만 수정도 점점 번잡해지고 뷰가 너무 커지면 타입 추론 에러가 자주 나면서부터 뷰, 모델을 쪼개기 시작했던 것 같다. 이걸 MVVM이라고 하는 것 같은데, 이번 프로젝트는 MVC 패턴으로 코드를 짰다. 아기 개발자라 의문 제기는 하지 않고 철저히 따라갔는데, 여전히 이 방식이 좋은지는…잘 모르겠다.

아! 글이 너무 길어졌다. 매듭을 지어야 하는데 말이다. 개발을 잘 끝내고 발표에 이르기까지 좋은 사람들과 함께할 수 있어 감사했다.

남겨진 질문들, 생각 조각들

1인 개발자를 지향해야 할까?

한 사람에 대해 극도로 깊이 이해하려 노력하면, 이는 수많은 이들에게도 필요한 좋은 제품이 된다.

나는 좋은 팀원이었을까?

오늘의 한마디 모음 (매일 쓰진 못했다)

자세히 들여다보면 당연한 게 당연한 게 아니게 된다.

막혀도 그냥 이것저것 해보다보면 길이 나오기도 한다.

팀 텐션이 낮을때, 누군가 나서서 분위기를 띄워주면 개선됨을 경험했다.

잘 보여주기 위해 버릴 건 과감히 버릴 필요가 있다.

의도적으로 대충 할 필요가 있다.

영어실력 좀 늘었다.

누구나 자신의 서사가 있다.

팀플은 Sync가 중요하다.

좋은 팀원들을 만나서 고맙다.

급할수록 돌아가자.

이제 진짜 시작이다.

쉬었다가 다시 보면 또 다르다.

실제 크기로 확인해보자.