저는 Developer가 아닙니다

 

안녕하세요 한끼족보 Android Lead 개발자 박동민입니다.

오늘은 다소 생뚱맞은 제목과 함께 찾아왔습니다.

 

Android Lead 개발자라고 첫 줄에서부터 소개하고 있는데 Developer가 아니라는 제목에 놀라셨겠지만 저는 Developer가 되는 것을 지양하고 있습니다.

 

그 이야기를 한끼족보와 함께 해보려고 합니다.

 

 

 

👨‍💻 Developer가 뭐가 어때서? 

제 개발자로서의 가치관은 "Coder가 되지말고 Develoer가 되자" 였습니다.

 

 

다른사람이 작성한 코드를 단순히 따라 치는게 아니라, 제가 작성하는 모든 코드에 이유를 담고 좋은 코드를 작성하고 싶었습니다.

또한 성능상으로 우수하고 다른사람이 읽어도 본인이 짠 코드처럼 수월하게 읽히는 코드를 작성하고 싶다는 욕심이 생겼습니다.

 

그래서 아키텍쳐에 대해서 공부하고 Kotlin에 대해서 공부하며 Compose라는 프레임워크에 대해서도 깊게 공부를 하고있습니다.

이렇게 공부를 하고 코드를 작성하다보니 이전과는 확연히 다른게 느껴지기 시작했습니다.

성능상으로도 고려를 하고 가독성도 고려하다보니 더욱 고도화된 코드가 만들어지고 있다는 생각이 들었고 꽤나 잘 한다는 생각이 들기 시작했습니다. 그래서 추가적으로 고려를 하기 시작한 것이 안정성 입니다. 

 

성능도 좋고, 가독성도 좋다면 이제 메모리적으로도 완벽하고 사이드이펙트가 발생하지 않는 안전한 앱을 만들어보자는 생각이 들었고, throw를 활용하며 try-catch, runCatching 등을 적재적소에 활용하며 안전한 개발을 하고자 노력했습니다.

그렇게 현재 제가 알고있는 수준에서 대부분의 코드를 마음에 들게 수정했습니다.

 

 

이제 다음 단계에서는 뭘 해야할까 고민을 했고, 컴포넌트에 미쳐보기로 했습니다.

컴포넌트를 잘 만드는 것이야 말로 가독성을 높이고 코드를 효율적으로 만드는 정말 중요한 작업입니다.

그렇기 때문에 Compose의 Slot API, State Hoisting 등을 공부하며 컴포넌트를 잘 만드는 방법을 익히고자 노력했습니다.

공부하고 혼자 적용해보고 이해했다는 생각이 들었을 때 제가 속한 SOPT라는 동아리에서 미니 세미나를 진행하며 완벽히 체화하고자 했습니다. 

 

 

 

그렇게 좋은 Developer. 즉 좋은 개발자가 되기위해 한걸음 한걸음 나아가고 있습니다.

 

 

 

 

 

근데 왜 Developer가 되기 싫어?

열심히 개발을 하던 어느순간 의문점이 들었습니다.

 

왜 내가 어려운 기술을 쓰면서 개발을 하고있지?
내가 이렇게 해도 사용자들은 알아줄까?

 

 

이 사실에 매몰되었고 점점 더 개발에 생각이 많아지기 시작했습니다.

 

물론 유지보수 라는 마법의 단어가 있습니다. 뭐만하면 "유지보수때문에~", "유지보수에 좋으니까~" 라는 이유가 붙습니다.

그런데 제가 제대로된 유지보수를 해봤나 고민했더니 단 한번도 해본적이 없었습니다.

 

이런 상황에서 유지보수라는 단어를 핑계로 어려운 기술, 복잡한 기술을 도입하는게 맞는걸까? 라는생각이 들었고, 이는 제가 경계하던 Corder의 모습이 아닐까 라는 생각을 하게되었습니다.

그래서 이런 고민을 SOPT makers라는 곳에 합류하며 해결하고자 했고, 미약하나마 유지보수를 경험해보며 기술적인 장점과 실제 경험상의 장점을 비교해보며 깨달을 수 있었습니다.

 

하지만 제가 내린 결론은 어려운 기술은 개발자들의 협업에 도움을 주는 것이지 사용자에게 영향을 끼치지는 않는다는 것이었습니다.

또한 제가 좋은 아키텍처를 적용하고 고급 기술들을 적용한다고 해도 좋은 코드를 만드는 것이지 사용자에게 좋은 프로덕트를 제공해주지는 않는다는 것을 깨달았습니다.

 

 

그래서 저는 Developer가 아닌 Maker를 꿈꾸게 되었습니다.

 

 

 

 

Maker는 뭐가 달라?

 

Maker를 해석하자면 말 그대로 "만드는 사람"입니다.

코드를 개발하는게 아닌 프로덕트를 만드는 사람이 되고 싶습니다.

 

 

좋은 프로덕트라는게 뭘까 고민을 했지만 그 정답은 생각보다 가까이 있었습니다.

위 고민에 있던 그 텍스트. "사용자들은 알아줄까?"

 

 

어차피 존재하는 모든 프로덕트는 사용자들을 기준으로 만들어져야만 합니다.

프로덕트의 존재 의의는 사용자들이 사용해주는 것이니까요.

 

 

그래서 좋은 프로덕트란 사용자들에게 좋은 프로덕트가 아닐까 라는 결론을 지었습니다.

 

 

그렇다면 사용자에게 좋은 프로덕트란 무엇일까요?

 

첫 번째로 예쁜 프로덕트가 있겠죠.

아무리 성능이 좋더라도 디자인적으로 좋지 않다면 사용하지 않는 것이 현실입니다.

하지만 이 부분은 제가 해결하기 보다는 디자이너님들의 역할이라 생각합니다.

 

 

그럼 두번째로는 사용자가 사용하기 편리한 프로덕트가 있다고 생각합니다.

한 단어로 좋은 UX(User Experience)를 가진 프로덕트 입니다.

 

개발자가 사용자에게 가장 큰 영향을 끼칠 수 있는 부분이라 생각했고, 저는 이 부분에 집중하기로 했습니다. 

 

 

 

좋은 UX를 어떻게 제공해줄 수 있을까?

저는 좋은 UX는 사용자가 몰라줘야 한다고 생각합니다.

정말 당연하게 동작하듯, 너무 익숙해서 못알아차리는 그런 동작들이야말로 좋은 UX라고 생각합니다

그래서 UX를 개선하고자 노력했고, 정말 간단한 것 부터 시작됩니다.

첫번째 화면에서 좌측 상단의 "전체"와 하단을 가리키는 화살표가 있습니다.

이 버튼을 누른다면 두번째의 대학교를 선택하는 화면으로 이동됩니다.

 

이때 "버튼을 누르면 화면이 이동된다"는 것에 집중한다면 아래를 가리키는 화살표에 클릭 이벤트를 감지하는 역할을 넣을 수 있겠죠.

하지만 사용자에게 더 익숙한 것 은 "전체" 라는 글자와 "화살표 아이콘" 근처의 그 어딘가를 누르는 것입니다.

즉, 아이콘에만 클릭 리스너를 넣을 경우 사용자는 터치가 잘 되지 않는다는 생각을 하게 될 것입니다.

 

그래서 저희는 텍스트부터 아이콘까지 해당하는 레이어 전체를 클릭 영역으로 잡아 사용자의 터치가 허공을 헤매는 일이 없도록 하였습니다

HankkiHeadTopBar(
    content = {
        Row( // Row 공간 자체에 클릭 리스터 연결
            modifier = Modifier.noRippleClickable(navigateToUniversitySelection),
            verticalAlignment = Alignment.CenterVertically
        ) {
            Spacer(modifier = Modifier.padding(start = 22.dp))
            Text(
                text = universityName,
                style = HankkiTheme.typography.suitSub1,
                color = Gray900
            )
            Icon(
                painter = painterResource(id = R.drawable.ic_dropdown_btn),
                contentDescription = "button",
                tint = Gray300
            )
        }
    },
    modifier = Modifier.background(White)
)

 

이런 사소한 디테일 하나하나가 좋은 프로덕트를 가른다고 생각합니다.

 

 

위 경우 너무 익숙한, 당연한거 아니냐 라는 생각이 들 수 있어요. 그럼 아래와 같은 화면에서는 어떻게 해야할까요?

 

오른쪽 화살표를 통해 클릭하면 화면이 이동된다는 것을 보여주고 있습니다.

이때, 정말 오른쪽 화살표에만 클릭 리스너를 연결하면 어떻게 될까요?

 

사용자는 글자, 글자와 화살표 사이 등을 클릭하며 왜 페이지 이동이 안되는지 의아해하고 있을 것입니다.

그렇기 때문에 글자부터 화살표까지 전부 다 클릭영역으로 설정해야 합니다.

 

당연해보이지만 이런것들이 적용되어있지 않은 앱들이 생각보다 많이 존재하고 있습니다.

 

 

 

 

정말 당연하게 느껴지지만, 코드로는 당연하지 않은.

없어도 되지만, 있으면 정말 조금 편해지는. 그런 문제를 해결하고 싶었습니다.

이 화면에서 "메뉴 추가하기"버튼을 누른다면 메뉴와 가격을 입력하는 칸이 하나 늘어날 것이라 예상하게 됩니다.

물론 실제로도 그런 기능이 맞구요.

 

 

그럼 여기서 개선할 수 있는 것이 뭐가 있을까요?

 

위의 gif를 본다면 메뉴가 추가되고 화면이 가만히 있습니다. 그 후 사용자가 직접 내려줘야 하죠.

만약 메뉴가 추가될 때 자동으로 스크롤이 아래로 내려간다면 사용자가 직접 내리지 않아도 되니 한층 편해지네요.

 

그리고 가격까지 입력을 마쳤을 때 메뉴 추가하기 버튼을 누른다면 자동으로 포커스가 이동한다면 직접 포커스를 이동하지 않아도 됩니다.

정말 사소하지만 사용자의 드래그 한번, 터치 한번을 줄여줄 수 있습니다.

그것 하나로 사용자의 편리함은 달라질 수 있다고 믿습니다.

 

 

 

 

이 외에도 안드로이드 개발자라면 추가적으로 신경써야 하는 부분이 있습니다.

이 부분에서 어색한 부분이 뭘까요?

아마 아이폰을 사용하시는 분들이라면 어색한 부분을 못느끼셨을 겁니다.

하지만 안드로이드를 사용하는 사용자에게는 치명적인 문제점이 하나 있어요.

 

 

바로 안드로이드 사용자는 좌우 슬라이드를 통한 옵션이 생기는 것이 생소합니다.

 

안드로이드 진영에서 더욱 익숙한 것은 꾹 눌렀을 때 알림이 뜨는 것이 익숙합니다.

 

만약 안드로이드 사용자에게 좌우 슬라이드 기능을, 아이폰 사용자에게 꾹 누르는 사용경험을 제공한다면 사용자들은 특정 기능을 쓰기 위해 여러번 시도를 하거나, 급기야 찾지 못하는 경우가 발생할 수 도있습니다. 사용자에게 익숙한 경험을 제공해주는 것이야 말로 UX에서 중요한 부분입니다.

 

그렇기 때문에 디자인이 만약 아이폰스럽게 되어있다면 안드로이드스럽게 수정해달라 요청하는 것 또한 안드로이드 개발자의 중요한 역할 중 하나에요.

 

 

 

이런건 UX관련한 사람들이 해야하는거 아냐?

좋은 회사에 가게되면 이런 부분을 담당으로 하시는 분들이 있을수도 있어요. 디자이너님들이 전부 다 가이드라인을 제공해주고 있을 수도 있죠. 하지만, 그러면 개발자는 디자이너가 준 피그마를 코드로 구현하기만 하는 사람일까요?

 

앞서 말했듯 저는 Corder보다는 Developer를, Developer보다는 Maker가 되고싶어 합니다.

만약 디자이너가 준 화면을 그대로 그려내기만 한다면 Corder겠죠. 거기에 성능과 유지보수성 등 코드적인걸 고려하며 나만의 코드를 작성한다면 Developer가 됩니다. 거기서 한발짝 더 나아가 사용자 경험을 생각하고, 디자이너님 혹은 UX가이드라인에 이의를 제기하고 더 좋은 사용자 경험에 대해서 고민한다면 그때 Maker가 된다고 생각합니다.

 

 

 

 

아직은 많이 부족하지만, 지금까지 한끼족보 Android Lead Maker 박동민이었습니다.