개발자: '이거 구현 어려운데요' vs 디자이너: '근데 이게 꼭 필요한데...'

개발자: '이거 구현 어려운데요' vs 디자이너: '근데 이게 꼭 필요한데...'

오후 2시, 핸드오프 미팅 회의실에 들어갔다. 개발자 민준씨가 이미 앉아있다. "디자인 공유드립니다." 피그마 화면을 띄웠다. 30초 만에 나왔다. 그 말. "이거 구현 어려운데요." 아직 컴포넌트 설명도 안 했는데. 숨을 참았다. "어떤 부분이요?" "이 인터랙션이요. 스크롤하면서 헤더가 반투명해지면서 블러 들어가고, 동시에 높이도 줄어드는 거. 퍼포먼스 이슈 있어요." 3일 걸렸다. 이 인터랙션 하나에. 레퍼런스 10개 찾고, 프로토타입 5번 만들었다. 대표님 피드백도 3번 반영했다. "근데 이게 꼭 필요한데..." 내 목소리가 작아진다. 매번 그렇다.필요하다는 말의 무게 "왜 필요한데요?" 민준씨가 묻는다. 공격적이지 않다. 진짜 궁금한 거다. 이럴 때 당황한다. "사용자 경험이..." "구체적으로요?" 막힌다. '감각적이니까', '애플도 이렇게 하니까'는 이유가 안 된다. 개발자들한테는. "스크롤할 때 컨텍스트를 유지하면서도 콘텐츠 영역을 확보하려고요. 헤더가 줄어들면 사용자가 어디 있는지 알면서도 더 많은 정보를 볼 수 있잖아요." "그럼 그냥 숨기면 안 돼요? 더 간단한데." 아니지. 그건 아니야. "완전히 숨기면 네비게이션 잃어버려요. 다시 위로 가려고 할 때." "위로 스크롤하면 다시 나타나게 하면 되는데." "그것도 구현 어렵잖아요." 민준씨가 웃는다. "그것도 어렵긴 한데, 블러보단 낫죠."타협의 기술 "블러 빼면 되나요?" "투명도 애니메이션만 남기면 훨씬 가볍죠." 피그마로 돌아갔다. 블러를 뺐다. 30초 만에 끝났다. 3일 걸린 디테일이. "이 정도면?" "이건 할 만해요." 기분이 묘하다. 다 무너진 것 같으면서도, 뭔가 배운 것 같기도 하고. "근데 디자이너님." "네." "이 그라데이션은요. 8개 스탑이 꼭 필요해요? 3개면 안 돼요?" 화면을 봤다. 미묘한 그라데이션이다. 레이어 블렌드 모드도 썼다. Overlay에 Multiply 겹쳤다. "육안으로 구분 안 되는데." 민준씨 말이 맞다. "차이 나는데요." "디자이너님 눈에만요." 할 말이 없다. 맞는 말이니까. "3개로 줄일게요." "색상 코드만 주시면 제가 리니어 그라데이션으로 처리할게요." 또 배운다. 리니어 그라데이션이 퍼포먼스에 좋다는 걸. 피그마에서는 몰랐던 거다.꼭 필요한가 회의가 끝났다. 원래 디자인의 60%쯤 남았다. 블러 없어지고, 그라데이션 단순해지고, 애니메이션 타이밍도 조정했다. 내 방으로 돌아왔다. 피그마를 켰다. '핸드오프_최종.fig'를 '핸드오프_최종_최종.fig'로 저장했다. 원본 파일을 열었다. 블러 있는 버전. 예쁘다. 확실히 예쁘다. 근데 민준씨 말대로, 사용자가 알까. 블러가 있고 없고를. 그라데이션이 8스탑이고 3스탑이고를. 모를 거다. 아마. 그럼 이건 뭐지. 내가 3일 동안 한 건. 자기만족? 아니다. 그건 아니야. 디테일이 쌓여야 전체가 좋아지는 거니까. 근데 구현 안 되면 의미 없는 거니까. 다음 날 아침 슬랙이 왔다. 민준씨: "어제 헤더 구현 완료했어요. 스테이징 서버 확인해보세요." 링크를 눌렀다. 개발 서버가 떴다. 스크롤을 내렸다. 헤더가 줄어든다. 투명해진다. 블러는 없다. 그라데이션도 단순하다. 근데. 나쁘지 않다. 아니, 좋다. 생각보다 훨씬 좋다. 움직임이 부드럽다. 퍼포먼스 때문에 오히려 더 자연스럽다. 피그마에서 볼 때는 몰랐던 거다. 실제 디바이스에서, 실제 콘텐츠에서, 실제로 스크롤하면서 보니까. 민준씨한테 메시지를 보냈다. "좋은데요." "그죠? ㅎㅎ 블러 없어도 괜찮죠?" 괜찮다. 솔직히. "근데요." "네." "스크롤 속도 빠를 때 애니메이션이 좀 끊겨요." "아 그거요. 쓰로틀 걸어서 그래요. 성능 때문에." "디바운스는요?" "디바운스 쓰면 반응이 늦어져요." 또 배운다. 쓰로틀과 디바운스의 차이. "그럼 easing 커브를 조정하면 어떨까요? ease-out 말고 custom cubic-bezier로." "오. 그거 괜찮을 것 같은데. 값 알려주세요." 피그마로 갔다. 모션 섹션을 열었다. cubic-bezier(0.4, 0.0, 0.2, 1) "이거요." "오케이. 적용해볼게요." 3주 후, 배포 기능이 라이브됐다. 사용자 피드백이 들어오기 시작했다. "헤더 애니메이션 부드러워요." "스크롤 경험 좋아졌네요." 블러 얘기는 없다. 그라데이션 스탑 개수도. 당연하다. 애초에 모르니까. 근데 기분이 나쁘지 않다. 이상하게. 민준씨가 slack에 남겼다. "디자이너님, 이번 협업 좋았어요. 다음에도 잘 부탁드려요." "저도요. 많이 배웠어요." 진심이다. 블러 없어도 된다는 걸. 8스탑이 3스탑 돼도 된다는 걸. 완벽한 디자인보다 실제로 작동하는 디자인이 낫다는 걸. 근데. 어제 밤 새 프로젝트를 시작했다. 프로덕트 리스트 페이지. 카드에 hover하면 이미지가 확대되면서 블러가 들어간다. 손이 멈췄다. 민준씨 목소리가 들린다. "이거 구현 어려운데요." 블러를 뺐다. 그냥 scale만 넣었다. 마우스를 올려봤다. 심심하다. 다시 블러를 넣었다. 값을 줄였다. 8px에서 4px로. duration도 줄였다. 400ms에서 250ms로. 테스트했다. 나쁘지 않다. 이 정도면 민준씨도 할 만하다고 할 거다. 아마. 저장했다. '리스트_v1_개발고려.fig' 파일명이 웃긴다. '개발고려'. 예전엔 없던 접미사다. 근데 이제는 자연스럽다. 결국 디자인과 개발 사이. 완벽과 현실 사이. 이상과 타협 사이. 어디선가 만난다. 매번 다른 지점에서. "이거 구현 어려운데요." "근데 이게 꼭 필요한데..." 이 대화는 계속된다. 앞으로도. 근데 이제는 안다. '꼭 필요한 것'의 정의가 계속 바뀐다는 걸. 타협이 포기가 아니라는 걸. 함께 만드는 게 혼자 만드는 것보다 낫다는 걸. 민준씨가 또 메시지를 보냈다. "디자이너님, 다음 주 새 기능 핸드오프 미팅 잡을까요?" "네. 근데 이번엔 제가 먼저 여쭤볼게요." "뭐요?" "구현 가능한지요." "오. 좋은데요. 그럼 초안 공유해주세요. 미리 볼게요." 피그마 링크를 보냈다. 댓글 권한도 줬다. 1시간 뒤, 댓글이 달렸다. "이 부분 구현 어려울 것 같은데, 이렇게 바꾸면 어떨까요?" 대안 제시였다. 비판이 아니라. 클릭했다. 민준씨가 직접 수정한 버전이다. 나쁘지 않다. 오히려 더 나을 수도. "좋은데요. 이걸로 갈게요." "ㅎㅎ 그럼 이번엔 쉽겠네요." 회의실이 아니라 피그마에서 만났다. 싸우기 전에 협력했다. 이게 맞다. 이게. 6개월 전과 지금 6개월 전에는 몰랐다. 개발자가 '어렵다'고 하면 내 디자인을 무시하는 줄 알았다. 내가 '필요하다'고 하면 고집부리는 걸로 보일까 봐 걱정했다. 핸드오프 미팅이 두려웠다. 내 디자인이 깎여나가는 시간이니까. 지금은 안다. '어렵다'는 '불가능하다'가 아니다. '같이 다른 방법 찾자'는 뜻이다. '필요하다'고 말해도 된다. 근거만 있으면. 핸드오프는 협상이 아니다. 협업이다. 민준씨도 변했다. 요즘은 먼저 물어본다. "이거 왜 이렇게 디자인하셨어요?" 궁금해서 묻는 거다. 트집 잡으려는 게 아니라. 나도 묻는다. "이거 구현하려면 뭐가 필요해요?" 알고 싶어서다. 이해하려고. 어제 점심 민준씨랑 같이 밥 먹었다. "요즘 디자인 공유하실 때 구현 난이도 표시해주시잖아요." "네. 도움 돼요?" "많이요. 우선순위 정하기 쉬워요." 빨강, 노랑, 초록으로 표시한다. 빨강: 구현 어려움, 대안 논의 필요 노랑: 구현 가능하나 시간 필요 초록: 쉬움 "근데요." "네?" "가끔 빨강인데 꼭 필요한 거 있잖아요." "그죠." "그거요. 말씀해주세요. 왜 필요한지만 설명해주시면, 방법을 찾아볼게요." 민준씨가 웃는다. "힘들어도요?" "힘든 건 괜찮아요. 의미 있으면." 의미. 그 단어가 좋다. "저도요. 쓸데없는 디테일은 이제 안 넣어요." "쓸데없는 거 없던데요?" "있었어요. 많이." 둘이 웃었다. 지금 이 순간 피그마를 켰다. 새 프로젝트. 빈 캔버스. 마우스가 멈췄다. 예전엔 이랬다. '일단 최고로 예쁘게. 나중에 조정하면 되지.' 지금은 다르다. '실제로 만들어질 디자인. 처음부터 현실적으로.' 근데 타협이 아니다. 더 나은 디자인이다. 구현될 수 있는 디자인. 사용자가 실제로 경험할 디자인. 개발자와 함께 만들어갈 디자인. 컴포넌트를 만들기 시작했다. 이번엔 블러를 넣지 않았다. 처음부터. 대신 색상 대비를 높였다. 타이포그래피에 집중했다. 슬랙이 울렸다. 민준씨: "다음 주 핸드오프 기대되네요." 나도 기대된다. "이거 구현 어려운데요." 그 말이 이제는 반갑다. 함께 풀어갈 문제니까. "근데 이게 꼭 필요한데..." 이 말도 이제는 자신 있다. 이유를 설명할 수 있으니까.타협은 포기가 아니다. 함께 더 나은 답을 찾는 과정이다. 오늘도 핸드오프 미팅에서 배운다.

대표님이 말씀하신 '애플처럼 해주세요'를 들었을 때의 심정

대표님이 말씀하신 '애플처럼 해주세요'를 들었을 때의 심정

그 말이 나왔다 회의실에 들어갔다. 대표님, 기획자, 개발팀장, 나. "이번 리뉴얼인데요, 우리 앱을 좀 더... 애플처럼 만들어주세요." 숟가락 떨어지는 소리가 들렸다. 내 손에서."네... 애플처럼요." 대답은 했다. 근데 머릿속은 벌써 난리다. 애플의 뭘 말하는 거지? 미니멀? 여백? 타이포? 애니메이션? 아니면 그냥 '깔끔한 거'? "그죠, 깔끔하고 세련되게요. 애플 보면 정말 심플하잖아요." 나왔다. '심플'. 디자이너가 제일 듣기 싫은 단어 3위 안에 드는 그 단어. 심플의 무게 회의 끝나고 자리 돌아왔다. 피그마 켰다. 심플. 깔끔. 애플처럼. 이 세 단어를 화면에 구현하려면 뭐가 필요한가.타이포 시스템: 웨이트 4단계, 사이즈 8단계, 라인하이트 조정 컬러 시스템: 메인 3색, 서브 5색, 그레이스케일 10단계, 각각 다크모드 대응 스페이싱: 4px 기준, 8px, 12px, 16px, 24px, 32px... 일관성 아이콘: 240개 전부 2px 스트로크로 통일 애니메이션: 이징 커브, 타이밍, 딜레이 다 계산애플은 이걸 100명이 1년 동안 만든다. 우리는 나 혼자 2주. 심플해 보이는 건 복잡함을 숨긴 결과다. 복잡함을 정리하는 시간은 안 숨겨진다. 벤치마킹과 모방의 차이 점심 먹으면서 생각했다. 애플을 레퍼런스 삼는 건 좋다. 당연히 좋다.정보 위계가 명확하다 여백 사용이 과감하다 인터랙션이 의미 있다 일관성이 미친 수준이다근데 '애플처럼'은 다르다. 애플의 결과물을 보고 '저렇게'를 원하는 거다. 과정은 관심 없다. 벤치마킹: "애플은 왜 이 버튼을 여기 배치했을까?" 모방: "이 버튼 저기 있으니까 우리도 저기 놔." 벤치마킹: "저 여백은 어떤 호흡을 만드나?" 모방: "여백 많이 넣으면 되겠네." 벤치마킹은 원리를 배운다. 모방은 껍데기를 따른다.우리는 애플이 아니다 오후 3시. 개발팀장한테 슬랙 왔다. "디자인 언제 나와요? 다음 주 스프린트 들어가는데." 한숨 쉬었다. 애플이 할 수 있는 것:버튼 하나에 10가지 버전 테스트 A/B 테스트 위한 인프라 전담 모션 디자이너 3명 유저 리서치에 한 달 "이거 아닌 것 같은데" 하면 갈아엎기우리가 할 수 있는 것:버튼 2가지 버전 만들어서 사내 투표 구글 애널리틱스 숫자 보면서 추측 모션은 개발자가 CSS로 유저 리서치는 주변 사람들한테 물어보기 "이거 아닌 것 같은데" 하면 "일단 내보내고 수정해요"맥락이 다르다. 리소스가 다르다. 목표가 다르다. 애플은 아이폰을 판다. 우리는 SaaS 구독을 판다. 애플 유저는 프리미엄을 기대한다. 우리 유저는 가성비를 본다. 애플은 통제된 생태계다. 우리는 웹뷰 반응형이다. 4시에 다시 회의 "시안 나온 거 좀 보여주세요." 피그마 화면 공유했다. 대표님이 스크롤을 내렸다. 5초 침묵. "음... 좋긴 한데, 뭔가 좀 밋밋한 것 같지 않아요?" 왔다. 심플하게 하래서 심플하게 했더니 밋밋하다. "애플은 심플한데 임팩트가 있잖아요. 우리 거는 좀..." 참았다. 3초 참았다. "애플의 임팩트는 여백에서 나옵니다. 여백을 살리려면 정보량을 줄여야 하는데, 지금 이 화면에 들어가야 하는 정보가 23개예요. 애플은 3개 넣습니다." "아, 그래도 다 중요한 정보라서..." "그럼 임팩트는 어렵습니다." 5초 침묵. "일단 이대로 가고, 나중에 조정하죠." 회의 끝. 애플처럼의 진짜 의미 퇴근길 지하철. 생각해봤다. 대표님이 나쁜 건 아니다. '애플처럼'은 사실 이런 뜻이다: "우리 서비스가 고급스러워 보였으면 좋겠어요." "유저가 쓰기 편했으면 좋겠어요." "경쟁사보다 나아 보였으면 좋겠어요." 근데 그걸 말로 설명 못 하니까 '애플'이라는 단어로 압축한 거다. 문제는 애플이 너무 크다는 것. 애플은 디자인이 아니라 철학이다. 시스템이다. 문화다. "Think Different"를 외치는 회사가 만든 결과물을 "저거 따라해"로 접근하면 모순이다. 그래서 뭘 하나 집 와서 맥주 땄다. 현실은 이렇다:'애플처럼' 요청은 계속 들어온다 거기 담긴 기대는 정당하다 근데 조건은 안 맞다 그래도 해야 한다그럼 어떻게?번역한다 "애플처럼 = 정보 위계 명확 + 여백 활용 + 일관성"으로 풀어서 설명한다.우선순위를 정한다 전부 애플처럼 못 한다. 핵심 3개 화면만 집중한다.단계를 나눈다 1차: 구조 정리, 2차: 디테일 개선, 3차: 폴리싱. 한 번에 안 된다.레퍼런스를 구체화한다 "애플 앱스토어 상세페이지에서 '스크린샷 캐러셀' 인터랙션"처럼 콕 집어서 이야기한다.기대치를 조정한다 "애플 수준은 어렵지만, 이 정도 개선은 가능합니다" 대안을 제시한다.금요일 오후 일주일 지났다. 수정 7번 거쳤다. 최종 시안 발표했다. "오, 훨씬 나아졌네요. 깔끔하고 좋아요." 대표님이 웃었다. 애플처럼은 아니다. 근데 우리답긴 하다. 정보 위계는 잡혔다. 여백은 전보다 과감하다. 일관성도 생겼다. 완벽하진 않다. 그래도 2주 전보단 훨씬 낫다. 퇴근하면서 아이폰 홈 화면 봤다. 애플 앱들 보다가 우리 앱 눌렀다. 나쁘지 않다. 진짜로. '애플처럼'은 목표가 아니라 방향이다. 거기서 배운 걸 우리 상황에 맞게 적용하는 게 내 일이다. 대표님은 계속 '애플처럼'이라고 말할 거다. 나는 계속 그걸 번역할 거다. 그게 디자이너다.내일 월요일이면 또 '구글처럼'이 나올지도 모른다.

빨간색을 더 빨갛게 해달라는 요청이 들어왔을 때

빨간색을 더 빨갛게 해달라는 요청이 들어왔을 때

빨간색을 더 빨갛게 해달라는 요청출근했다. 슬랙을 열었다. 메시지가 4개. 첫 번째는 기획자: "홈 배너 컬러 한 번 봐주세요." 두 번째는 개발자: "이거 언제쯤 나와요?" 세 번째는 대표님: "피그마 확인해주세요." 네 번째는 마케팅: "빨간색을 좀 더 빨갛게 해주세요." 손가락이 움직였다. Figma를 켰다. 컬러 코드를 확인했다. #D63031. 이미 충분히 빨갛다. Red 채도는 최대다. 명도도 조정했다. 이게 더 빨갛게 된다는 건... 아, 알겠다. 이건 색상 문제가 아니라는 걸 안다. 추상적 피드백의 정체 회의실에 앉았다. 마케팅 이사가 말했다. "이 빨강이 좀 약한 것 같아요. 더 강렬해야 할 것 같은데..." "강렬한 느낌이면 채도를 올리거나 명도를 내려야 하는데, 지금 상태에서는 둘 다 최대예요. 어떤 느낌을 원하시는지..." "아, 그냥 좀 더 빨갛게요." 여기가 멘탈이 부서지는 지점이다. '빨갛게'는 색상이 아니다. 감정이다. 정확히는, 내가 당신의 감정을 코드로 번역해야 한다는 요청이다. 보통 이런 피드백은 이렇게 분류된다: 1. 실제로는 다른 걸 원하는 경우 "빨강이 약해 보여요" = 실제로 원하는 건 명도가 높은 다른 색상이거나, 배경색과의 대비를 원할 수도 있다. 때론 사이즈 문제일 수도. 2. 감정적 이상향을 색상으로 표현한 경우 "더 선명하게" "더 힘있게" "더 신뢰감 있게" 같은 요청들. 색상이 아니라 심리다. 3. 진짜로 컬러를 모르는 경우 "더 빨갛게 해줄 수 있어?"라고 묻는데 #FF0000에서 더 갈 데가 없을 때. 이건 답답함의 영역이다. 4. 나는 다른 걸 봤는데 당신이 잘못 만든 거 아니야? 같은 불신 가장 심각한 피드백. 내 디자인이 아니라 내 능력을 의심받는 느낌.내가 했던 대응은 보통 이렇다: 먼저 심호흡을 한다. 3초. 화면에 안 보이게. 그 다음 몇 가지를 확인한다. 첫째, 내가 정말 #FF0000을 썼는가. (안 썼다면 업그레이드.) 둘째, 그 색상이 배경이나 주변 요소와 어떻게 조화되는가. 셋째, 내 모니터 색감이 표준인가. (사실 대부분 그렇지 않다.) 그 다음에는 질문을 한다. 부드럽게. "더 강렬해야 한다는 건 화면에서 더 먼저 눈에 띄어야 한다는 뜻인가요? 아니면 폰에서 봤을 때 느낌이 다르게 보이나요?" 90% 확률로 이렇게 온다: "아, 모니터에서 봤을 때는 다르게 보이더라." 이제부터가 프로페셔널 대응이다. 추상적 피드백을 번역하기 사실 가장 위험한 순간은 피드백을 받는 게 아니라, 그걸 어떻게 받아들이냐는 거다. 첫 번째 실수: 그걸 개인 공격으로 받는 것 "내 디자인이 못났다는 뜻인가" → "아니다, 커뮤니케이션이 안 됐다는 뜻이다." 프로젝트 초반에 색상 시스템을 설명할 때, 나는 이제 이런 식으로 말한다: "메인 빨강은 #D63031로 잡겠습니다. 이건 모바일과 PC에서 일관성 있게 보이도록 맞춘 값이고, 배경이 밝으면 더 선명하게, 어두우면 부드럽게 느껴질 수 있습니다. 만약 더 극적인 느낌이 필요하면 #FF0000도 옵션으로 두겠습니다." 이렇게 하면? 피드백이 달라진다. 대표님: "아, #FF0000 한번 봐봐." 끝. 3초 만에 답이 나온다. 두 번째 실수: 바로 수정하려고 하는 것 "빨강을 더 빨갛게" 들었을 때, 나는 더 이상 그냥 건너뛴다. "화면 공유해서 함께 봐도 괜찮을까요?" 대부분 동의한다. 그리고 공유하는 순간, 상대방도 본다. "아, 이건 빨강이 문제가 아니라 버튼 크기가..." "실제로 봤을 땐 더 밝아 보여야 할 것 같고..." "어? 이건 예상과 다른데..." 추상적 피드백은 구체적인 맥락이 없을 때만 추상적이다.멘탈 지키면서 일하기 솔직히 말하면, 6년을 해도 이런 피드백은 짜증난다. 다만, 짜증나는 방식이 바뀌었다. 1년차 때: 마음이 부서진다. "내가 디자인을 잘 못하는 건가?" 3년차 때: 상대를 무시한다. "색상을 모르는 거네." 6년차 때: 아, 이건 내 문제가 아니고 대화 문제다. 라고 생각한다. 이제 내가 하는 일은: 첫째, 피드백을 받을 때 추측하지 않기. "더 밝게"는 명도인가 채도인가 톤인가. 묻는다. 둘째, 나는 색상 전문가라는 걸 은연중에 드러내기. 디자인팀 회의 때 "색상은 명도, 채도, 톤 세 가지 차원이 있고..." 같은 교육을 슬쩍 끼워넣는다. 그럼 다음부턴 피드백이 조금 더 구체적이다. 셋째, 결정권자와 1대1로 확인하기. 회의실에서 여러 명이 있을 땐 피드백이 아니라 의견 중복이다. "혹시 따로 5분만 시간 내실래요?" 하면 대부분 오케이. 넷째, 대안을 항상 3개 준비하기. "더 빨갛게"라는 피드백 오면, 나는 벌써 3가지를 준비했다.채도 높은 빨강 (#FF0000) 명도 낮은 빨강 (#A00000) 따뜻한 톤의 빨강 (#E85D3F)"어떤 방향이 더 맞는 것 같으신데요?" 하면서 보여준다. 그럼 상대는 선택만 하면 된다. 다섯째, 일정과 피드백은 동시에 관리하지 않기. "마감이 오늘 오후인데 색상도 봐주세요"는 절대 금지. 일정이 있으면 피드백 기간을 길게 잡는다. 재검토할 시간이 있으면 피드백도 깊어진다. 그래도 힘들 때 지금 내 모니터 옆엔 포스트잇 하나가 붙어있다. "The client doesn't know what they want. That's why they hired you." 정말인지 아닌지는 모르겠다. 하지만 때론 이 문장이 필요하다. "빨강을 더 빨갛게"는 피드백이 아니다. 그건 신호다. 신호가 뭔가? 대부분은 "난 만족 못 해"가 아니라 "난 뭘 원하는지 모르겠어"다. 그리고 그 뭔가를 찾는 게 내 일이다. 색상 코드를 아는 것보다, 그 신호를 읽는 게 훨씬 중요하다.결국 디자인 문제가 아니라 디자이너와 클라이언트가 같은 언어를 쓰는지의 문제다. 나는 지금도 배우고 있다. 매일.