나에게 힘을 주는 응원 주접
글
내 삶의 불편함을 해결한 앱 토큰 메모를 만든 이야기
더 보기 편한 링크는 이곳 을 눌러주세요. 살면서 아주 작은 불편함들이 있습니다. 개선하기도 애매하고 그렇다고 적응하기에도 애매한 불편함입니다. iOS 개발자가 되고나서 가장 처음 만들었던 앱을 2년 반이나 지난 후에야 다시 돌아보며 개선했습니다. 한 달에 하나씩은 내가 만들었던 앱을 되돌아 보거나, 아니면 더 개선해 나가지 않으면 개발자로 계속 성장하기 어려울 것 같아서 시작하게 된 프로젝트 먼슬리 리이오입니다. 제가 만들었던 앱이 어떤 불편함 때문에 만들어졌는지 그리고 어떤 편함을 가져왔는지 앞으로 얼마나 더 편함을 가져다 줄 수 있을지 정리해보려고 합니다. 토큰메모의 시작 생활을 하다보면, 많은 정보들을 기록하게 됩니다. 그리고 기록한 정보들은 대부분 다시 검색되어서 끄집어 내어집니다. 스스로의 삶을 돌아봤을 때, 항상 카카오톡 내가 나에게 쓴 메모장을 쓰거나, 아이폰의 기본 메모앱을 사용했습니다. 처음에는 별 문제 없다가도 기록이 흘러가 버리거나 쌓이면, 찾기가 너무 어려워지는 문제가 발생했습니다. 그래서 처음 개선을 한 것이 일반 메모장과 같은 메모장 이지만, 누르면 바로 클립보드에 복사가 되는 메모장을 만들었습니다. 그리고 거기서 끝이났습니다 2년 반 이후 무엇이 바뀌었는가? 여전히 스스로를 위해서 만든 앱을 사용하고는 있었습니다. 하지만 더 편할 방법을 고민했고, 내가 써보지 않은 기술을 공부하는 도구로 사용하기 위해서 2가지를 했습니다 UIKit을 다 버리고 SwiftUI로 만들어 버리는 것 안 써본 기술을 써보는 것 Custom keyboard extension 그리고 이전에 문제를 더 편하게 해결할 수 있는 방법을 고민했고 새로운 토큰 메모를 만들어 냈습니다. 새로운 메모를 만들고, 메모를 클릭하면 복사가 되는 것은 여전히 가능합니다. 하지만, 새로운 토큰 메모는 키보드를 추가해서 내가 만든 메모까지 들어가서 누르지 않아도 값을 불러올 수 있습니다. 개선은 아주 작게 시작하기 나의 불편함으로 부터 시작
심리적 안정감이 주는 힘
더 보기 편한 링크는 이곳 을 눌러주세요. 어딘가에 속해서 발전을 해 나가면서 무언가를 이루고 성취감을 맛 보는 것은 직업이 줄 수 있는 큰 즐거움이자 그 직업을 유지하고싶은 마음이 들게하는 요소중 하나입니다. 만약 그렇지 못하다면, 그룹안에서 어떤 불안감을 가지고 있는지 돌아보고 개선할 수 있는 방법을 찾아보는 것은 어떤가요? 사이콜로지컬 세이프티란? 번역하면 심리적 안전입니다. 이 글에서 말하는 심리적 안전은 내가 어딘가의 그룹에 속해있는 상태에서 누릴 수 있는 안전한 느낌을 말합니다. 회의중에 질문을 하거나 업무중에 실수를 해도 내가 조롱을 당하거나 굴욕을 당하지 않을 것 이라는 믿음입니다. 이러한 느낌은 나 자신이 그룹에서의 구성원으로 가치있음을 확인하고, 불이익이나 부당한 대우를 받지 않을 것이라는 인식을 하게 해줍니다. Amy Edmondson이 이 용어( Psychological Safety)를 만들어냈고 검색해 보시면 영상을 확인할 수 있습니다. 왜 챙겨야 할까요? 사이콜로지컬 세이프티의 유, 무를 비교해서 생각해보면 간단합니다. 내가 속한 그룹에서 무언가를 제안하고 실제 실행이 되었을 때, 좋은 결과가 있었을 때에는 문제가 없겠지만 나쁜 결과가 있을 때 누군가 책임을 지고 그게 내가될 수 있다면, 새로운 도전이나 아이디어를 제안하는 것이 매우 힘들 것 입니다. 그렇기 때문에 빠르게 발전하고 이루는 것을 목표로 하는 조직이 되려면 구성원들이 이러한 불안감을 느끼지 않도록 고민하는 것이 필요합니다 어떤 것 들이 있을까요? 크게 4단계로 이루어져 있습니다. 가장 하위의 안전이 만족되었을 때 그 보다 위의 안전이 보장됩니다. 맨 아래에 소속의 안전을 시작으로 그 위에 배움의 안전, 기여의 안전, 도전의 안전순으로 쌓여나갑니다. 아랫 단계의 안전이 보장되지 않는다면 그 윗단계의 안전은 보장되기 쉽지 않습니다. 각 단계의 안전이 어떤 것들을 의미하는지 그리고 언제 깨질 수 있는지 알아보겠습니다. 소속의 안전 가장 기본적인 안전함의
“실패해도 괜찮아” 라고 말하지 않기로 했습니다
더 보기 편한 링크 는 이 곳을 눌러주세요 개발의 끝에 마주한 평가 개발을 하는 것을 옆에서 지켜볼 때면, 가장 많이 받는 요구 중에 하나가 바로 “이 정도면 충분한지” 입니다. “리이오 이정도로 코드를 짜면 괜찮을까요?”, “이정도면 완성이라고 볼 수 있는 건가요?” 그리고 저 역시도 이러한 질문에는 항상 비슷한 대답을 할 수 밖에 없었습니다. “이 부분은 고민을 정말 많이 한 흔적이 보여서 좋아요.”, “여기는 좀 더 고민하면 좋아지겠는데요?” 그리고 그들은 저의 대답에서 둘 중의 하나의 경험을 합니다. 바로 “합격” 아니면 “불합격” 입니다. 평가가 아닌 실험 사실 합격과 불합격은 시험이나 평가 뒤에 따라오는 행위입니다. 배우는 사람은 스스로를 평가할 필요는 있지만, 남에게 평가받아야만 배움이 남는 것은 아닙니다. 그래서 이제부터는 다르게 질문하고 다른 질문을 요구하려고합니다. “이 정도 코드를 짜면서 무엇을 배웠어요?” “다음에 또 이걸 한다면 다르게 해 볼 수 있는 부분은 어떤게 있어 보여요?” “본인이 느끼기에 최선을 다했나요?” 사실 위의 질문들은 회고의 질문들과도 맞닿아 있습니다. 마찬가지로 회고에서도 한 프로젝트의 평가를 하지 않도록 가이드 해야겠다는 생각을 했습니다. 새로운 방향성 결국 배움의 과정에서 평가를 하지 않고 개선을 생각하게 함으로 그들은 그들의 배움에 실험을 계획할 수 있고, 그 실험에서 자신이 무엇을 배웠는지를 인지하고 무엇을 배우지 못했는지도 인지할 수 있습니다. 이 모든 일은 “실패해도 괜찮아.”, “지금 마음껏 실패해.”라는 말이 실패해도 괜찮은 분위기와 문화를 만들 수 있을 것 이라는 믿음이 부서지면서 생긴 의문에서 출발한 탐구였습니다. 왜 실패 해도 괜찮다고 했는데, 기를 쓰고 성공하려는 걸까? 실패해도 괜찮다고 느끼게 하려면 어떤 것들을 제공해야할까? 애시당초 실패해도 괜찮은게 맞기는 한건가? 이러한 질문들의 결과는 “실패는 해도 괜찮아는 동작하지 않는다” 이고, 그래서 배우는 사