슈퍼 엔지니어와 일하며 배운 기술 외 중요한 것
들어가며
운이 좋겠도 저는 지금, 지금까지 만난 엔지니어 중에서 가장 대단하다 느낀 사람과 함께 일하고 있습니다.
지금 회사를 다녀 즐거운 마음으로 매일 감사하며, 같이 일하며 많은 것을 배우고 있습니다.
그래서 슬슬 아웃풋해야해!(사명감)을 느껴 글을 씁니다.
이번은 기술 외적으로 배운 것, 중요하다 느낀 것에 대해 쓰겠습니다.
(글에서는 슈퍼 엔지니어를 T씨라 하겠습니다.)
(어느 정도로 대단한지 쓰고 싶지만, 글의 목적에서 벗어나므로 생략하겠습니다...)
("대단한 엔지니어"라는 말로 표현하고 싶지 않을 정도로 대단한 엔지니어님입니다...)
도메인지식, 업무지식의 중요함
지금 자신이 참가하고 있는 프로젝트에서는 T씨가 업무요건 정리, 청취, 시스템 설계, DB 설계를 하고 있습니다만,
도메인 지식이라하는 업무지식의 깊이가 굉장해, 업무요건에 대한 청취, 시스템 설계, UI 설계, DB 설계 등등에 묻어납니다.
현장과 같은 수준으로 지식이 있어서 현장에서 어떠한 것이 힘들고, 어떤 것을 바라는가를 T씨는 알고 있습니다.
시스템 개선안이나 이런 기능 있으면 좋을텐데 제안 등도 명확하고 업무 지식이나 도메인 지식을 깊이 알고 있으으로 사용하기 편리한 시스템 개발로 이어진다는 것을 몸으로 알았습니다.
지금까지 저는 코드 적는 방법이거나, 프레임워크 사용방법, 설계 같이 기술적인 부분에 중점을 두고 봤습니다만, 이번 프로젝트를 통해 도메인 지식이나 업무 지식을 깊이 알아야한다는 중요함을 배웠습니다.
(그래서, 근래 입에 오르고 있는 모 기업의의 1년반 현장 연수도 조금 널널하네 느낄 정도로 꽤 깊이 이해할 수 있었습니다.)
사용하기 편함을 추구하는 자세
T씨에게
"생각없이도 조작할 수 있는 UI가 아니면 안 돼. 수면부족 상태여도 조작 실수하지 않도록 하는, 그런 UI여야한다"
"다른 제품을 미뤄두고서 사용하고 싶다 생각하는가 어떤가"
이런 말을 들은 것을 선명히 기억합니다.
스스로 개발하면서도 그냥 쓰고, 그냥 움직이면 되지 않나 생각한 경우가 아마 있을 것입니다만, 이 말을 듣고나서는 정신차리게 되었습니다.
지금은 제 안에서 좋은 UI는 어떤 것인가 기준이 되고 있습니다.
그리고 T씨님, 평소부터
"어느 쪽이 유저가 좋아할까?"
"어떻게 해야 유저가 기뻐할까?"
"이런식이면 유저가 좋아할 것 같아서!"
"이게 있으면 유저가 좋아할거야~"
이런 말이 자연스럽게 입에서부터 나오고, 철저하게 시스템을 사용하는 사람 시선으로 생각하는 것을 당연하게 생각하기에, 정말 존경합니다.
저도 유저가 가장 기뻐하는 형태를 추구, 제공하고 싶기 때문입니다.
그리고 T씨의 말 중에 가장 인상에 남는 것이 하나 더 있는데,
"이용자가 되어보고, 연기하며, 고통을 겪어본다."
입니다.
이용자가 되서, 시스템을 다뤄보고, 이용자와 같은 고통을 겪음으로 개선점이 보이고, 빨랑 고치지 않으면, 개선하지 않으면 안된다! 마음이 생깁니다.
진정한 의미로 자기것으로 시스템을 만들기 위해 필요한 자세라 생각합니다.
몇 번이라도 같은 걸 물어도 좋아, 몇 번이라도 대답할테니
이건 너무나도 고마운 일이었습니다.
T씨는 프로젝트 첫 만남부터
"몇 번이더라도, 혹 같은 질문이라 하더라도 몇 번이든 괜찮아!"
이 말로 걸어줘서, 덕분에 질문하는 심리적 벽이 낮아져 눈치보지 않고 질문할 수 있었습니다.
지금 팀에서는 Gather를 사용해서 텍스트 뿐만이 아니라 직접 대면하는 느낌으로 질문할 수 있는 환경이므로, 자연스레 질문할 수 있었습니다.
그리고 +α로 주변 지식 이야기나 더 이렇게 하면 좋다는 이야기까지 들을 수 있어 공부가 되었습니다. 감사하게도요.
(T씨는 텍스트 질문보다 직접 질문하는 게 빠르고 전달하기 쉽으니까... 이런 사람이어서, 더욱 감사합니다.)
이렇게되니 팀 내에서는 T씨 외에도, 저에게도 질문해도 될까요? 이런 커뮤니케이션을 하거나, T씨 외에의 멤버에게 질문하러 가는, 질문하기 편한 환경이 만들어졌는데, T씨 정책 덕분이라 느꼈습니다.
이런 환경 만드는 것은 스크럼마스터(@YUM_3)가 좋은 팀 만들기에 힘 써든 덕도 무척 큽니다.)
만약 T씨가 "질문은 텍스트만, 같은 질문은 하지 않도록 해주세요" 이런 사람이었다면 지금 팀의 질문하기 편안한 환경은 없었을 것이라 생각하고, 개발 효율도 떨어졌을 것이라 생각합니다.
저도 후배가 생긴다면, T씨와 같은 정책으로 접근해보자 생각하고 있습니다.
(질문하기 편안한 분위기 만드는 것 중요)
설계는 배려가 중요
이건 조금 기술적인 이야기이기도 합니다. 사용하기 편함을 추구하는 자세 이야기와 가까운데, T씨 코드나 행동 등을 보고있으면 배려가 굉장히 중요하다 느낍니다.
예를 들어 코드를 적을 때도
"다른 사람이 읽으면 어떻게 되지? 읽기 편한가?"
"이 기능을 수정하면 어떻게 해야 수정하기 쉽지?"
이런 식으로 상대를 생각하느냐 아니냐에 따라 코드를 아름다움이나 질이 달라진다 생각합니다.
T씨가 쓴 코드는 무척 수정하기 쉬웠습니다.
issue 타이틀 뿐만 보면 어려워보이는데, 수정하다보면 어라? 여기만 수정하면 끝? 이렇게 됩니다.
이런 체험은, 개발중에 다른 사람이 자기 코드를 수정하는 모습까지 생각할 때 나오는구나 느꼈습니다.
배려에 대해 UI를 생각할 때도 중요합니다.
그 시스템이나 기능이 사용되는 컨텍스트를 제대로 고려하고 시스템을 사용하는 사람을 상상해,
이런 기능이 있으면 좋으려나?
이런 문구가 있으면 이해하기 쉬우려나?
이런 스테이더스에서 검색할 수 있으면 좋겠지
등등 이런 것까지도 생각하고 있는가 어쩐가에 따라 사용하기 편한 시스템이 되느냐 안 되느냐가 결정된다해도 과언이 아니라 봅니다.
맺으며
글을 쓰며 느꼈습니디만, T씨의 현장에서 사용하는 사람이 되어 보는 힘이 굉장하구나 느낍니다.
(기본적으로 도메인 지식, 업무지식, 기술력이 굉장한 건 당연하구요...)
시스템 설계를 할 때는 시스템을 사용하는 사람이 되어보고, 코드를 쓸 때는 다른 개발자가 되어 보고, 이렇게 되면 좋겠네, 이렇게 하면 좀 그러네 생각할 수 있는 것이, T씨가 압도적으로 가치제공을 할 수 있는 요인중 하나려나 싶습니다.
그리고 시스템을 사용하는 사람이 되기위해서는, 도메인 지식이나 업무지식이 필요하므로, 기술력 뿐만으로는 좋은 시스템은 만들 수 없구나를 프로젝트를 통해 체화할 수 있어 굉장히 좋은 경험이었습니다.
저도 T씨 같이, 글에 적힌 것을 매일 의식하며, 진심으로 사용하기 편한 시스템을 만드는 엔지니어가 되도록 살겠습니다.
지금까지, 글을 읽어주셔서 감사합니다!