관성적 일상에서 나와 차리는 일상으로 바꾸기
베터코드 인사이트의 부활
<반가운 댓글이 만든 작은 파문을 차려서 행동하기>를 쓴 영향으로 관성적으로 대하던 일 처리를 차려서 행하는 시도를 합니다.
관성적 업무 실행하는 나를 돌아보기
구체적인 업무 정의를 하기 전에 다행히도 생각만 기록하고 멈춘 일이 있었습니다.
관성적으로 조회수 따위가 있어야 한다고 생각하는 것이죠. 그것으로 어떤 가치를 만들 것인지에 대한 고려는 없었습니다. <Tidy First?> 번역으로 알게 된 <소프트웨어는 두 가지 방식으로 가치를 만든다>를 사실을 알았으니 이를 적용해야죠. 해당 기능을 넣는다고 당장 매출이 나는 것도 아니고, 판매 가능성을 높이는 지도 불분명합니다.
일단 하면서 아이디어를 얻기
경험상 뚜렷한 아이디어가 없을 때는 (다른 일로 전환하거나) 무엇이라도 하다 보면 아이디어가 생겨납니다. 그래서 익숙한 브런치를 살펴보았습니다. 통계 메뉴를 눌러 보니 조회 수와 더불어 댓글 수가 나타났습니다. 그러고 나서 고개를 돌렸더니 '인기글'이라는 표기가 눈에 띄었습니다.
그랬더니 우리 시스템과 비교과 되었습니다. 일단 우리는 CMS(콘텐츠 관리 시스템)의 코드 기반을 수정해서 커뮤니티 관리 기능을 만들고 있습니다. 구현을 위한 전략 즉, CMS 코드 활용은 개발자인 동료에게 위임했습니다. 제가 할 일이 아니고, 그가 할 일이니 당연한 수순입니다.
반면에 제품의 정의하는 일은 제가 할 일입니다. 사용자 경험 관점에서 CMS 틀에 두려는 것은 아니었습니다. 그렇더라도 필요 이상 투자(코드 수정)할 필요는 없어서 꼭 필요한 수정만 했습니다. 그래서 cms라는 URL을 우리 내부적으로는 Community Management System으로 부르는 것으로 투입 공수를 0으로 만들었습니다.
단어를 사용한 바탕을 차려 보자
여기서부터는 <말의 바탕치와 짜임새를 살펴보는 일>의 응용입니다. 꾸준히 묻따풀 활동을 했던 것은 비단 한국말 쓰기뿐 아니라 프로덕트 정의나 관리 업무에도 응용하여 효과를 낼 수 있습니다. '어떻게?'에 대한 답변이 이 글을 기록으로 남기는 이유입니다.
의미가 차려지지 않으면 개발자는 간편한 방법으로 개발할 수 있습니다. 제가 개발 업무를 할 때, '사회적 가치' 같은 말을 개발자들 앞에서 의도적으로 사용하고 회사 개발 업무도 모두 'OKR'로 연결한 이유가 이를 막기 위한 장치입니다. 개발을 왜 하는지 목적과 실무를 연결하고 싶어서죠.
그런 부분을 고려하지 않으면 발행 글과 임시 글은 발행 여부라는 하나의 구분자 값을 DBMS 컬럼으로 만들고 그를 통해 구분하는 단순한 기능일 뿐입니다. 그거 말고 뭐가 있나구요? 구현 자체를 어떻게 할지는 개발자가 판단할 몫입니다. 다만, 개발자와 회사의 다른 동료들 사이에 어떤 말을 쓰느냐가 어쩌면 굉장히 중요할 수 있습니다. 그런 말들이 비전과 목표를 잘 담아낸다면 의사소통이 굉장히 효과적일 테니까요.
정보 자원의 속성을 되짚어 보기
이 글은 '그걸 어떻게?'에 대해서 답을 찾아보려는 시도의 하나입니다. 암튼, 모든 글이 이제 둘로 나눠졌습니다. 탭으로 구분한 화면에서 데이터의 차이가 생겼습니다. 임시 글 목록에는 '발행일시'라는 컬럼은 없습니다.
당연하죠. 발행을 하지 않았으니까요. 그런데 개발자의 머릿속이 DBMS 스키미와 SQL로 꽉 차 있다면 이런 단순한 사실(발행을 했다 혹은 안 했다)이 부등호 하나의 문제로 취급될 수 있습니다. 그런 문제가 되지 않으려면 개발자에게 태도를 바꾸라고 말할 수도 있지만, 저는 이를 팀워크나 조직의 정렬의 문제로 다룹니다.
그래서, 동료에게 발행일시가 앞에 보이게 해 달라고 요청합니다. 발행은 한번 하고 나면 바꿀 수 없습니다. 물론, 이후에 다시 변경을 허용하면 사실상 재발행인데, 이걸 어떻게 해야 하는 지와 같은 구체적인 결정이 필요합니다. 하지만, 이 글에서 제가 하고자 하는 말은 발행 글과 임시 글을 다르게 다뤄야 하는 사용자의 맥락을 개발자가 이해하게 해야 한다는 사실입니다.[1]
이제 개발 비용이 들어가는 업무는 아주 작은 범위에서 마쳤습니다. 일단 뭔가 해 보다가(exploring) 얻어 낸 효과는 불필요한 개발을 막게 하면서 개념과 단어 정립을 하고 소통할 필요성을 깨닫게 해 주었습니다. 마지막으로 혼자 약간의 시간을 더 써서 생각할 문제가 남았습니다.
레코드, 목록, 메뉴, 정보 자산
목록의 이름이 인기글이면, 정렬 순서가 '랭킹'이 된다는 점입니다. 기업용 응용 프로그램 개발을 업으로 다룬 긴 세월은 나도 모르게 테이블을 보면 특정 컬럼 단위로 정렬을 필요하다는 생각을 합니다.[2] 그런 충동을 차단하고, 보면 목록을 보는 목적이 메뉴가 되면 좋다는 생각을 합니다.
메뉴는 일단 리모컨의 메뉴 같은 것입니다. 사용자가 무엇을 하고 싶다고 명령을 내리는 것이죠. 그때 욕구가 보편적으로 다수의 레코드를 보는 목록 보기 형태일 수 있습니다. 이때, 목록 자체가 아니라 개념적으로 유의미한 단위를 정보 자산이라고 부르기로 합니다. 개발자라면 Entity와 같은 말로 보아도 좋습니다.
이왕 차리는 김에 사전 풀이도 찾아볼까요? 자산(資産)은 재물 자(資)와 낳을 산(産)자를 합친 말입니다. 네 갈래의 뜻이 있는데 아래 두 가지 중에 기호에 맞는 것을 응용해서 쓸 수 있을 듯합니다.
「1」 『경제』 개인이나 법인이 소유하고 있는 경제적 가치가 있는 유형ㆍ무형의 재산. 유동 자산과 고정 자산으로 대별된다. ≒자재.
「4」 개인이나 집단이 미래에 성공하거나 발전할 수 있는 바탕이 될 만한 것을 비유적으로 이르는 말.
데이터를 조합해서 경제적 가치를 만든다고 생각하면 자재와 유사하니 첫 번째도 좋습니다. 하지만 프로그램 특성상 미래 가치로 초점이 가기 마련이라 4번 풀이가 저에게는 더 와닿네요.
정보 자산을 개별 메뉴와 연결하는 UX 제공하기
암튼, 브런치 메뉴를 둘러보며 얻은 영감을 더해 그린 그림을 공개합니다. 그리고 보니 MSA와 같은 기술적 어휘가 아니라 쓰임새 관점 혹은 사업자 관점으로 프로그램 모양을 바꾸어 보는 시도네요. 이하는 각론이라 여러 가지 사례에 적용해 보고 싶은 욕망이 들지만, 일단 기록만 남기고 기회가 왔을 때 여기서 얻은 영감을 설계에 적용하기로 합니다.
주석
[1] 이때, 말에 담아 소통을 탄탄하고 효율적으로 만드는 아이디어가 Ubiquitous Language라고 할 수 있습니다.
[2] '그리드'라는 말까지 쓰기 시작하면 더 심한데, 퇴행적 UX를 만드는 계기가 되곤 합니다.
