Dev Story of Sungdoo

SungdooYoo

2020년은 제 인생의 전환점이 될 만한 사건들이 많이 일어났습니다. 결혼을 했고, 뱅크샐러드로 이직을 했습니다. 그 과정에서 정말 많은 것들을 배우고 또 한 단계 도약한 해였습니다.
결혼
결혼하기 전에는 두려움이 많았습니다. 내가 결혼이란 걸 해도 될까. 내가 남편이 될 수 있을까. 내가 어른이 될 수 있을까. 많은 망설임과 고민이 있었습니다. 하지만 결론적으로, 아니 아직 결론을 내기에는 너무나 이른 시기이지만 그래도 지금까지, 결혼은 제가 인생에서 한 여러 선택들 중 가장 탁월한 선택이었습니다. 매일 아침 눈을 뜰 때마다 행복하니까요. 
결혼과정에 대한 회고는, 사실 지라를 활용해 결혼 준비하며 배운 것 이란 글로 갈음해도 될 것 같습니다. 애자일 방식으로 결혼이란 프로젝트를 어떻게 관리했는지를 정리한 글인데, 자연스럽게 회고의 내용들이 녹아들어가 있더라고요.
다만 결혼생활 자체는 아직까지 애자일 방식으로 관리하지 못하고 있었다는 것을 이번에 연말 회고를 준비하며 깨달았습니다. 아내와는 가사일을 iOS의 “미리알림” 앱으로 정리해서 관리하고 있는데, 하루 이틀 안에 끝날 일들, 또는 매일/매주 루틴으로 해야 하는 일들은 이런 체크리스트 형태의 앱으로도 관리가 될 수 있지만, 장기적인 프로젝트들은 제대로 관리하기 어렵다는 것을 깨닫고 있습니다.
예컨대 “주택 마련하기” 라던지, “집들이 준비하기”(이제는 못하게 되었지만요 ㅠㅠ)라던지, “체력 단련”등과 같이, 가정에서도 장기간에 걸쳐 진행해야 할 프로젝트들이 있습니다. 이런 프로젝트들을 이번에는 노션을 통해 애자일 방식으로 관리하고 매주 부부간 회고도 해보는 시간을 가져보려 합니다. 매일 많은 대화를 나누고는 있지만, 역시 의식적으로 우리가 어디로 가고 있고 무엇을 개선해야 할지에 대해 이야기를 나누는 것은 꼭 필요한 일인 것 같아요.
블로그
꽤 오랜 기간, 제 트위터 소개 문구에는 “매주 서평 또는 기술 관련 글을 씁니다”라는 식으로 쓰여져 있었습니다. 그렇게 매주 글을 쓰던 때도 있었지요. 사실 저는 2주에 한 번 서평을 쓰는 모임을 나가고 있기 때문에, “최소 2주에 한 번은 무조건 서평을 쓸테고, 그러면 2주에 한 번 기술 관련 글을 쓰면 되는 것이니 충분히 가능한 목표겠다”라고 생각했습니다. 
하지만 그 예상은 보기좋게 빗나갔습니다. 일단 서평모임 자체가 2020년에 존폐의 위기를 맞았어요. 코로나로 인해 만날 수가 없으니 모임이라는 것 자체가 어려워진 것이지요. 심지어 모임의 구성원들도 코로나의 영향을 받아 일자리가 어려워지는 경우도 생겨서 더더욱 모임은 어려워 졌습니다. 그러다보니 올해는 서평을 많이 올리지 못했고, 여기에 결혼식 준비까지 겹치면서 블로그에 글을 쓴 주보다는 그렇지 않은 주가 더 많게 되었습니다.
그래도 다행히(?) 워드프레스닷컴에다 적지 않은 비용을 내면서 블로그를 운영하고 있어서인지 어떻게 해서든 글은 쓰게 되더라고요. 역시 돈이 무섭습니다. 공백인 기간도 종종 있었지만, 그래도 대부분의 기간동안 2~3주에 한 번은 글을 쓸 수 있었던 것 같습니다. 그래도 지금은 트위터 소개 문구는 조금 수정했어요.   
매주는 아니더라도, 나름 꾸준하게 글을 쓴 덕분인지, 블로그에 점점 많은 분들이 찾아주셨습니다. 기본적으로 글 쓰는 일일 즐거워 하는 블로그이긴 하지만, 아무래도 더 많은 분들이 읽어주시게 되니까 계속 더 글을 쓰게 되는 원동력이 되는 것 같습니다. 

최근에는 사내의 글쓰기 모임은 뱅글(뱅크샐러드 글쓰는 모임)에 가입해서 글을 쓰고 있습니다. 뱅글은 2주에 한 번 서로의 블로그 글을 공유하고, 2주동안 글을 쓰지 못한 회원에게서는 벌금(!)을 받아가는 무서운(?) 모임입니다.  벌금제도 자체도 많은 동기부여가 되지만, 꾸준히 좋은 글을 쓰는 동료들을 보는 것이 더 많은 의지를 샘솟게 합니다.
뱅샐 앱의 모듈화 진행
몇 년동안 하나의 프로그램으로 관리되어온 프로젝트를 여러 개의 작은 프로그램으로 쪼개는 일은 쉽지 않은 일이었지만, 동시에 꼭 필요한 일이기도 했습니다. 여러 소프트웨어 설계 원칙 차원에서도 필요한 일이기도 했지만, 당장 어마어마했던 빌드타임을 줄이기 위해서라도 꼭 필요했습니다. 제가 뱅샐에 합류하기 전 부터도 기나긴 빌드시간이 문제가 되어서 많은 분들이 여러 노력을 체계적으로 기울여 조금씩 빌드시간을 줄이고는 있었지만, 결국 궁극적인 해결책은 앱 자체를 병렬빌드가 가능한 형태로 만드는 것 뿐이었습니다.  (참조:Building Faster in Xcode)
하지만 기존에 서비스되는 앱을 여러개로 쪼개는 일은, 아무리 안정적으로 가더라도 결국 수많은 파일에 수정사항을 가하는 일이 될 수밖에 없는 일이었습니다. 대부분의 수정사항은 실제 코드레벨에서의 수정은 아니었지만, 결국에 파일의 위치가 바뀌게 되기 때문에 최종적으로 수십만 라인의 코드체인지가 일어나게 되었습니다. 
아마 당시 잠시 뱅샐에 합류해 도움을 주셨던 사룡님의 도움이 없었더라면 쉽게 엄두내지 못했을 대작업이었습니다. 특히 막판에는 뱅샐에서 쓰이는 보안모듈과의 알 수 없는 충돌 때문에 릴리즈 빌드에서만 문제가 발생해서 정말 속이 썩어가기도 했었죠.
이 때의 문제는 결론적으로 Xcode의 BuildSetting에 잔존하던 불필요한 설정이 원인이었던 것으로 밝혀졌습니다. 그 때의 교훈을 바탕으로 Xcode BuildSetting 제대로 관리하기 라는 글을 썼고, 사내에서도 이를 제대로 관리 할 수 있는 다양한 프로세스를 만들기도 했죠. 아마 이 때만큼이나 저를 힘들게 했던 디버깅은 앞으로도 전무후무하지 않을까 합니다. 제발 그랬으면 좋겠네요. 
다행히 그 이후로 뱅샐 앱의 모듈화에는 속도가 붙어서, 특히 새로 만들어지는 서비스들은 모두 기본적으로 별도의 프레임워크로 만들어지고 있습니다. 덕분에 기존에는 “분 단위”였던 빌드시간이 이제는 “초 단위”로 바뀌게 되었습니다. 아직도 더 모듈화의 여지가 많은 만큼, 뱅샐의 빌드속도는 앞으로도 훨씬 빨라질 예정입니다. 
BPL, 그리고 접근성
뱅크샐러드에 2020년에 합류한 것은 정말 행운이었습니다. BPL이라는 프로젝트를 밑바닥부터 만들어올린 경험은 정말 다른 어디에서도 얻을 수 없었을 귀중한 경험이었습니다. 지금은 많이 생소하지만, 앞으로는 점차 업계 표준이 될 “프로덕트 랭귀지”라는 개념을 접하고 이해하고 만들어낸 경험은 앞으로도 꽤 오랜시간 제 자랑이 될 것 같습니다.
BPL이 탁월한 것은 일차적으로 기획자-디자이너-개발자 사이의 커뮤니케이션 비용을 0에 수렴하도록 줄였다는 점입니다. 그리고 이렇게 커뮤니케이션 비용을 줄이는 도구를 만들기 위해서, BPL을 만드는 디자이너/개발자들은 정말 많은 커뮤니케이션 비용을 써야 했습니다. 미래의 구성원들이 지불할 커뮤니케이션 비용을 선불로 일시불로 결제하는 느낌이었죠. 그 어려움을 어떻게 극복했는지 궁금하신 분들은, 뱅크샐러드 기술블로그를 참고해 주세요!
하지만 뭐니뭐니해도 BPL의 가장 자랑스러운 부분은, BPL로 인해 뱅크샐러드 앱의 전체적인 접근성이 비약적으로 향상되었다는 점입니다. 모든 BPL 컴퍼넌트가 접근성을 염두에두고 개발되었기 때문에 자연스럽게 그 BPL을 활용해 구성된 화면은 모두 보이스오버 및 다이나믹 타입과 같은 접근성 지원이 원활하게 되었습니다. 설령 BPL을 활용해 실제 서비스를 구성하는 개발자가 접근성 지원에 익숙하지 않더라도 일정 수준 이상의 사용자 경험을 모든 고객에게 제공할 수 있게 된 것입니다. 
이렇게 처음에는, “BPL을 활용하면 서비스 개발자가 접근성 지원에 크게 신경 쓰지 않아도 된다”는 것을 BPL의 강점으로 내세우긴 했지만, 이제는 조금씩 “BPL을 활용하는 서비스 개발자도, 접근성 지원에 대해 더 많이 인식하고, 테스트하고 신경을 써야한다”는 취지의 목소리를 더 많이 내고 있습니다. BPL에서 아무리 많은 고려를 한다고 해도, 결국 만들어지는 최종 제품 차원에서 접근성 지원이 고려가 되지 않으면 분명 누락되는 부분이 생길 수 밖에 없다는 것을 몇 번의 버그를 통해 알게 되었거든요. 
특히 아차 싶었던 것은, 어떤 구성원들은 그런 “버그”를 통해 우리 앱이 “손쉬운 사용 옵션에 대응하고 있다”는 사실을 처음 접하게 될 수도 있다는 점을 간과했다는 점이었습니다. 예컨대 다이나믹 타입으로 인해 글씨 크기가 너무 커져서 버튼이 가려지는 버그를 만나고 나서야, 우리 앱의 글씨가 커질 수도 있다는 사실을 처음으로 알게 되는 구성원들이 생긴거죠. 사실 그런 종류의 버그는, 다이나믹 타입이 아니더라도 더 작은 화면을 지닌 기기가 나오면 재발 할 수도 있는 버그지만, 이런 “버그”를 통해 처음으로 “손쉬운 사용”의 세계를 만나게 된다면, “손쉬운 사용”에 대응하려는 노력을 “버그를 유발 할 수도 있는 옵션을 열어 놓는 일”로 여길 수도 있겠다는 생각이 들었습니다. 그리고 제가 먼저 나서서 “손쉬운 사용” 옵션들이 어떤 것이고 우리가 어떻게 왜 여기에 대응하고 있는지를 널리 알리지 않으면, 그런 버그가 놓쳐질 확률도 높아질 뿐더러, 그에 따라 접근성 지원에 부정적인 인상을 지니는 구성원들이 점차 늘어날 것이라고 생각했죠. 
그래서 iOS팀원들은 물론, 기획 및 디자인, 고객감동팀등 다양한 파트의 여러 분들과 티타임을 가지며 우리가 회사 차원에서 접근성 지원을 어떻게 왜 해야하는지를 설득하러 다니기 시작했습니다. 다행히 그런 노력들이 조금씩 효과를 보여서, 이제는 점점 더 많은 곳에서 어떻게 접근성 지원을 챙겨야 할지에 대해 논의하는 모습들이 많이 보이고 있습니다. 정말 놀랍고 뿌듯하고 또 자랑스럽습니다. 사실 아무리 접근성 지원이 중요한 일이라고 제가 말하고 다닌다고 한들, 조직 구성원들이 귀를 닫고 무시했다면 저부터도 의욕을 잃고 많은 것들이 흐지부지 되었을 수도 있습니다. 하지만, “사회에 선한 영향력을 미치는 자랑스러운 제품을 만든다”는 모토를 중심으로 모인 사람들이어서 그런지, 접근성 지원을 해야한다는 목소리가 생각보다도 더 빠른 시간안에 퍼지고 있는 것 같습니다. 
아직까지도 뱅크샐러드의 접근성 지원은 갈 길이 멉니다. 개선해야 할 부분들의 목록은 아주 깁니다. 부정적으로 보일 수도 있겠지만, 저는 바로 이 부분이 올해의 가장 큰 쾌거라고 생각합니다. 저희는 접근성 지원에 대해 고려하지 않던 상태에서, 접근성 지원에 부족한 부분들의 “목록”을 지닌 상태가 되었습니다. 문제를 해결하는 것은 쉽습니다. 어려운 것은 문제를 문제라고 인식하는 것이 제일 어렵습니다. 이제 문제라고 인식한 이상, 그것들을 가차없이 해결해 나갈 겁니다.
총평
2020년엔 마음대로 되는 것들이 없었지만, 그래도 가만 돌아보면 꼭 해야겠다고 한 일들 대부분을 해냈습니다. 부족하고 아쉬운 부분도 많았지만, 그래도 그 이상으로 행운이 함께한 한 해였습니다. 인생 가장 큰 행운인 아내를 만났고, 제 목소리를 잘 들어주는 능력있는 동료들을 만났으니, 더 이상 뭘 바랄 필요가 없네요. 하지만 제발 내년에는 어떻게든 코로나가 종식되었으면 좋겠습니다. ㅠㅠ
The post 2020년 회고: 결혼, 모듈화, BPL, 접근성 appeared first on Dev Story of Sungdoo.

2020년 회고: 결혼, 모듈화, BPL, 접근성

댓글