(포스팅에 사용된 일부 이미지와 동영상은 내부 컨펌을 받고 첨부하였습니다.)

배경

사내에서 디자인 QA 를 진행할 때 마다 디자인,개발팀 간에 자주 발생하는 상황이 있었다.

👩‍🎨 : 텍스트 간격이 가이드랑 안맞는 것 같아요 😭 1dp 줄일 수 있을까요~?
👨‍💻 : 🤔 가이드 대로 작업한 수치입니다!                              
👩‍🎨 : ???
👨‍💻 : ???

이는 스케치 - 제플린으로 제공된 가이드 수치를 기준으로 작업을 진행해도 텍스트 관련 간격이 가이드와 실제 기기 사이에서 미묘하게 일치하지 않는 이슈 였다. 관련하여 리서치해보니 다음과 같은 원인이 있을 수 있었다.

• 디자인 팀 내에서는 스케치를 이용하여 작업을 진행하는데, 스케치 상에서 다루는 텍스트의 행간과 안드로이드 XML 에서 다루는 행간의 수치가 다르다.
• 폰트마다 가지고 있는 행간이 다르다.

이러한 이유로 인해 디자이너 분이 스케치에서 제공하는 텍스트 컴포넌트를 기준으로 가이드를 잡아도 실제 기기에서는 조금씩 다르게 표현되게 되었던 것이다.

해당 이슈 때문에 텍스트와 연관된 디자인이 있을 때마다 양 팀간에 추가적인 커뮤니케이션이 고정적으로 발생했고 이로인한 피로감이 상당했기 때문에 이를 개선할 수 있는 방법이 없을까 고민하다가 텍스트 사이즈를 확인할 수 있는 QA 앱을 제작해보기로 마음먹었다.

프로토 타입

QA 앱이 도움을 줄 수 있을 거라 생각한 부분은 다음과 같다.

• 스케치의 텍스트 컴포넌트의 간격과 기기에 적용된 텍스트 컴포넌트 간격의 오차를 줄이기 위해 ‘앱기준’의 정확한 수치를 제공해 줄 것 (XML 기반)
• 텍스트 수치가 잘못 적용이 된 경우 구조의 간격이 틀어지는 경우가 빈번한데, 틀어짐의 원인을 쉽게 파악할 수 있도록 도와줄 것

위 내용을 바탕으로 폰트 크기, 행간, 스타일 등을 조절할 수 있는 있는 간단한 형태의 앱이 떠올랐고 MVP 를 만족하는 프로토 타입을 만들었다.

나름의 목적을 가지고 제작했으나.. 순수하게 개발자의 시선에서 만든 것이기 때문에 디자이너분들의 실제 니즈와는 부합하지 않을 수도 있으므로 피드백을 받아 개선해 나가는 것을 2차 목표로 삼고 디자인 팀에 프로토 타입을 전달드렸다.

당시에 전달드렸떤 프로토 타입의 모습은 다음과 같았다.

시간이 흐른 후 의미있는 피드백들과 함께 실제 디자인 프로세스 내에서 활용할 수 있을 것 같다는 답변을 주셨다(!) 주 피드백 내용은 다음과 같았다.

• 텍스트 사이즈, 행간 별로 텍스트 set 을 만들어 스케치에서 비교하는 과정이 필요한데 이러한 코스트가 드는 것을 원치 않는 사람도 있을 것 같다.
• 2개 이상의 텍스트 set 을 만들어서 확인해볼 수 있으면 좋을 것 같다.
• 기존에 디자인되었던 케이스와 직접 비교해볼 수 있으면 좋겠다. (실제 앱과의 비교)

개선 버전

프로토 타입의 경우 테스트를 위한 별도 화면이 있었는데, 이러한 구조를 버리고 아예 앱 위에 테스트용 텍스트를 띄울 수 있다면 피드백 대부분을 만족할 수 있을 것 같았다. 기술적인 검토를 통해 오버레이 윈도우 를 활용하면 가능하다는 결론이 나왔고 대대적인 개선 작업을 진행했다.

사용성 및 디자인 개선을 거듭하여 다음과 같은 결과물이 나왔다. (디자이너분의 엄청난 서포트로 모양도 다시 태어났다. 🙇‍♂️)

프로토 타입 대비 변경된 점은

1. 화면 최상단에 테스트용 텍스트를 띄울 수 있음 → 텍스트 set 을 만들지 않고 실제 앱의 텍스트와 수치를 비교 가능
2. 2개 이상의 테스트용 텍스트를 다룰 수 있음.
3. 텍스트 영역이 실제로 차지하고 있는 영역 (padding)을 시각적으로 구분할 수 있음.

해당 앱을 이용했을 때 기대하는 시나리오는 다음과 같았다.

• 디자이너가 앱의 결과물을 활용하여 실 기기에 적용되는 값을 기반으로 디자인 가이드를 작성, 이를 개발자가 그대로 적용하여 차이가 없도록 함.

• 만약 결과물이 디자인 가이드와 다를 경우 디자이너가 QA 앱으로 비교해보며 원인을 정확하게 파악하여 개발자에게 전달할 수 있기 때문에 추가적인 커뮤니케이션 발생 X

  ex) Font 앱으로 비교했을 때 행간이 1dp 높아요. 줄여주세요!

QA 앱 배포 당시 많은 분들이 감사함을 표현해주셨고, 아직까지는 디자인 / QA 시 유용하게 사용하신다는 이야기를 전달주시는 것으로 보아 초기에 목표했던 것을 어느정도 달성한 것 같아 기뻤다.

(바쁜 업무중에도 많은 도움을 주신 디자이너 새솔님, 재옥님 감사합니다!)

기술적인 이슈

오버레이 윈도우를 처음 사용하다보니 몇몇 기술적인 이슈에 직면했는데, 가장 기억에 남는건 포커스에 대한 내용이었다.

오버레이 윈도우는 기본적으로 최상위 레벨의 윈도우 인데, 아무런 설정을 하지 않을 경우 하위 레벨 윈도우에서 키 입력을 할 수 없었다. 즉, QA 앱을 구동할 경우 밑에 깔려있는 앱에서는 키보드를 입력할 수가 없다.

이를 방지하기 위해 WindowManager.LayoutParams 는 FLAG_NOT_FOCUSABLE 라는 플래그를 제공하고 있다. 따라서 QA 앱에서 텍스트를 입력할 때는 flag 를 초기화 해주고 입력이 끝나면 FLAG_NOT_FOCUSABLE 를 세팅해주는 작업이 추가로 들어가야 했다. 작업 자체는 어렵지 않지만 윈도우에 대한 배경지식이 적어 당황했었던 이슈였다.

내가 바꿀 수 있는 것부터 하자

회사 업무를 진행하다보면 그 과정속에 크고 작은 불편함과 아쉬움이 공존한다. 그리고 이러한 불편함에 대한 가장 쉬운 대응은 책임을 다른 곳으로 돌리는 것이다. 그 사람이 문제인거야. 그 팀이 문제인거야. 그 툴이 문제인거야…

하지만 불편함 뒤에 숨겨진 히스토리를 잘 알지 못하므로 그게 원인일 확률이 낮을뿐더러, 설령 그게 원인이라 할지라도 불평하는 것만으로는 아무것도 달라지는 것이 없다. (내가 원인일 수 있다는 생각은 잘 하지 않는다. 😂) 이러한 대응은 안좋은 감정이 쌓이기 쉽다. 모든 사람이 이런 대응을 선택하지는 않겠으나, 입사 초기에 나는 딱 이러한 부류의 사람이었다.

이러한 상황에 대해 생각이 바뀐 것은 최근인데, 잠정적으로 내린 결론은 ‘내가 바꿀 수 있는 영역부터 집중하고 시도하자’는 것이었다. 내가 당장 영향을 발휘할 수 없는 영역에 쏟는 에너지를 변화시킬 수 있는 영역에 쏟는 것이다. QA 앱도 이러한 생각에서 출발하게 되었다. 반복적으로 불편한 지점이 존재했고, 작지만 기술적으로 서포트할 수 있는 지점이 보여 이를 실천했다.

이는 꼭 개발자에 국한된 얘기는 아닐 것이다. 각자의 포지션에서 내가 기여할 수 있는 부분이 분명히 있다고 생각한다. 지금도 어딘가에 내가 바꿔나갈 수 있는 개선점들이 기다리고 있지 않을까.