23년 3분기 회고
항상 한 분기가 끝나면, 회고록을 작성하려고 합니다.
회고록을 작성하는 이유
회고록은 정말 여러 곳에서 작성을 하라고 강조를 하더군요. 그래서 저도 회고록은 놓치지 않고 작성하려고 하고 있습니다.
회고록을 작성하는 이유는 여러가지 이유가 있습니다. 가장 중요한 이유는 과거를 회고하면서 미래를 발전시킬 방법을 찾는 것입니다.
또 시간이 지난 후 내가 이때 무슨 생각을 했고, 어떤 일을 했는지 돌아본다면, 앞으로 무엇을 할 지에 대해서도 더 고민해볼 수 있습니다.
회고록을 작성할 때, KPT 회고법을 사용하면 좋다고 합니다.
- Keep: 현재 만족하고 있는 부분, 계속 이어나가고 싶은 부분, 잘한 부분을 회고합니다
- Problem: 불편했던 부분, 개선이 필요하다고 느끼는 부분을 회고합니다
- Try: Problem의 해결책을 고민해봅니다.
명시적으로 KPT 회고를 지켜나갈 이유는 없겠으나, 그래도 스스로 다음 회고에서 더 나은 모습을 만들기 위해서 이러한 KPT 과정을 끊임없이 반복하는 과정이 필요할 것입니다.
사실 이렇게 말은 해도, 막상 이번 분기는 한 일이 많지 않아서 쓸 말이 없답니다.
토익 봤다
토익 봤습니다.
840점 나왔습니다. 난 카투사 갈 겁니다. 화이팅.
블로그
요새 블로그를 쓰는 게 참 재미있답니다. 블로그를 꾸미고, 글을 채워나가는 게 참 재미있어요.
그리고 스킨도 새롭게 적용했습니다. 한눈에 라는 스킨인데, 글의 본문의 h1, h2, h3 CSS 속성은 제가 살짝 커스텀해서 사용하는 중입니다.
어느덧 블로그 게시물 숫자도 60여 개가 넘었습니다.
어느덧 누적 방문수도 6천 회를 넘겼습니다. 기분이 좋습니다.
인기글 순위입니다. 역시 1순위는 단순 에러로 검색해서 들어오는 분들이 많습니다.
저 1등 에러 글은, 블로그 초반부터 지금까지 꾸준한 조회수를 책임져주고 있는 글입니다. 단순한 글이 저렇게 위에 있다는 게 사실 기분이 묘합니다. 열심히 쓴 글들은 한참 아래에 있거든요.
블로그도 일종의 포트폴리오라고 생각합니다. 그래서 최대한 보기 좋게 꾸미는 게 좋겠죠.
하지만 포트폴리오를 관리한다고 의무적으로 작성하고 있지는 않습니다. 그냥 블로그를 하나씩 채워나가는 게 재밌어서 하고 있답니다. 더 일찍 시작할 걸 그랬어요. 1학년 때부터 바로 블로그를 채워나갔으면 어땠을까 합니다.
블로그를 쓰면서 이런 저런 원칙도 세웠습니다.
- 글은 최대한 남들에게 설명을 하는 식으로 작성하자
- 나만 보기 위한 글이 아닌, 남들이 봐도 이해할 수 있는 주제로 작성하자.
- 최근 글들이 '한다' 체보다는 '합니다’ 체로 작성되어 있는 이유도 그렇습니다.
- 단, 단순 회고의 경우는 ‘~한다’ 체를 허용합니다.
- 하나의 토픽에 대해서는 글 하나로 종결하자
- 글을 일부러 길게 쓰려고는 하지 않지만, 최대한 글 안에 기승전결을 담습니다.
- 그러나 가독성을 위해서, 혹은 하나의 토픽 안에 서브 토픽이 전환되는 경우에는 글을 분리합니다.
- 단순한 정보 전달보다는, 정보를 가공하고 나의 정보를 추가하자
- 단순히 여러 블로그 글, 혹은 위키피디아나 강의에 있는 정보를 복붙하는 것은 의미가 없습니다.
- 여러 정보를 취합해서 하나의 글로 재가공하거나, 혹은 정보를 저의 생각과 방법대로 재가공하여 전달합니다.
- 그러나 정보의 출처는 확실히 밝힙니다.
- 출처 표기 원칙
- 출처는 단순 링크의 경우 제목과 저자만, 그리고 책, 혹은 저명한 웹 저널의 경우 Chicago 출처 표기법을 따릅니다.
- 출처는 글을 작성하기 위해 참조된 모든 사이트들을 밝힙니다.
기숙사에 들어갔다
홍대에서 자취해본 반 년
지난 3월부터 홍대에서 자취를 시작했습니다. 솔직히 좋긴 했습니다. 홍대 바로 앞, 투룸이었습니다. 수업 듣고서 바로 자취방 가서 쉴 수 있다는 게 정말 좋았답니다.
또한 나만의 공간이 있다는 것, 그리고 통금따윈 없는 자유로운 공간이 있다는 게 자취의 매력이죠.
그리고 다른 자취방도 아니고, 홍대 한복판이여서 더 좋았답니다. 술자리에서 ‘아 집가서 쉬어야지’ 생각하면 집이 5분 거리에 있었거든요.
또 홍대라는 지리적인 요건이 아주 잘 맞는 사람에게는 정말 잘 맞을 것입니다. 홍대 거리가 내 집 앞이라니.
기숙사에 들어간 이유
하지만 자취에 대한 로망은 불과 한 달 만에 깨졌답니다.
일단 요리가 가장 문제였는데, 요리가 이리 힘든 일인 줄은 몰랐답니다. 사실 요리가 귀찮고 힘들 것이라는 건 알았지만, 제 예상보다 더 귀찮음이 빠르게 왔답니다. 그래서 최대한 조리 위주로 음식을 먹다 보니깐, 먹는 식단이 문제가 생겼답니다.
그리고 자취방이 혼자 살기에는 좀 컸습니다. 자취방 놀러온 분들이 자취방을 볼 때마다 혼자 사는 거냐고 묻더군요. 꽤 넓은 공간이었습니다.
문제는 이 넓은 공간을 제가 청소하고 관리해야 하니깐, 그게 너무 귀찮았답니다. 그리고 집 안 자체에서 무언가 냄새가 났는데, 그 냄새의 원인을 결국 못 찾았습니다(하수구, 싱크대, 화장실 등을 다 청소를 했는데도). 그래서 방 뺄 때까지 냄새가 났습니다.
무엇보다 비용이 가장 큰 문제였는데, 저같은 경우에 단기로 집을 구했고, 홍대 바로 앞이고, 적당히 방이 컸기에 100만 원이라는, 결코 작지 않은 월세를 냈어야 했습니다. 이런저런 관리비로 빠져나가는 것도 있고, 솔직히 100만 원이라는 돈을 매달 주고서 자취를 유지하고 싶지는 않았습니다.
그래서 기숙사에 들어갔답니다.
B612 2기의 시작
가장 큰 이슈로는, B612가 2기의 모습으로 새롭게 단장하였습니다.
6월 달부터 B612는 2기를 준비하고 있었고, 7월 달에 본격적으로 모집을 진행했답니다.
B612 2기는 지난 1기와 다르게 세션의 수가 확 늘어났습니다. 인원이 늘어난 만큼 세션을 정규 세션과 사이드 세션으로 구분하고, 더 개발 위주의 단체로 성격을 강화하는데 초점을 맞추었습니다.
백엔드 세션, 프론트엔드 세션에 추가로 모바일 세션, 자유 세션을 추가로 개설하였고, 기존에 있던 모각글과 알고리즘은 사이드 세션으로 옮겼습니다.
백엔드, 프론트엔드, 모바일 세션에는 리드를 추가로 영입하여 전문성을 더 강화하였고, 자유 세션을 새롭게 신설하여 보다 자유로운 선택권을 주고자 하였습니다. 다만 자유 세션의 경우 어쩌다보니깐 결국 일반적인 웹 커리큘럼을 따라가게 되더라구요.
아니 왜 파란색 빔 프로젝터를 끌 생각을 안 했을까요…
리드 구하기
리드를 구하는 작업이 가장 어려운 작업이었습니다.
그냥 말 그대로 보이는 모든 사람들에게 이메일/디스코드 등을 통해서 컨택을 모두 시도했습니다.
솔직히 성공률은 절망적이었는데, 그럼에도 불구하고 몇몇 분들에게 컨택이 성공해서 리드를 모집하는 데 성공했습니다.
스페셜 멘토
이번에 B612에서 스페셜 멘토를 섭외하여, 정기적인 멘토링을 부탁했습니다.
그 첫 활동으로, Q&A 기반의 연사를 부탁했습니다. 위의 사진은 그때의 사진입니다.
스페셜 멘토를 섭외하는 것도 마찬가지입니다. 그냥 한 번 이메일로 컨택해봤는데, 성공했습니다.
이전에 GDSC 데브톡에서 뵈었던 분이신데, 학생들을 멘토링하는 데 있어 많은 관심을 갖는 분이라고 자신을 소개해주던 기억이 나서, 한 번 시도해봤는데, 흔쾌히 AC 해주셨습니다.
앞으로 본격적으로 프로젝트 공모전을 열게 된다면, 주기적으로 프로젝트가 제대로 진행될 수 있도록, 멘토링을 해주실 것을 부탁드릴 예정입니다.
DevOps & Cloud 스터디에서 크레딧 관련한 사고가 일어나다
외부 인원들에게도 공개되는 스터디를 하면서 가장 많이 걱정을 하였던, 크레딧 관련 사고가 발생하고 말았습니다.
신청을 해놓고서 등록을 안 하고 있거나, 혹은 신청조차 안 한 분들이, 등록을 너무 늦게 하여서(8월 달에 등록), 이전 달(7월)에 사용한 클라우드 내역에 대해서 금전적인 청구 비용이 발생했습니다.
근데 그 금액이 좀 큽니다. 적게는 8만 원에서부터 많게는 50만 원까지 청구되었습니다.
스터디를 진행하다가 스터디원들에게 이 비용이 발생한 거라서, 이를 어떻게 처리해야 할 지 정말 난감했습니다. 학회비는 택도 없고, 제가 개인 사비로 내야 하는 건 아닌지, 이거에 대해서 문제를 제기하는 사람들이 나오지는 않을 지 걱정했습니다.
정말 다행히도, 실제 금전적 비용이 청구된 분들이 ‘뭐 내 잘못이니깐 어쩔 수 없죠 ㅎㅎ’ 하고 수용했습니다.
50만 원 그까이꺼 사소해~ 하는 마인드에 박수를 멈출 수가 없었습니다.
암튼… 이번 일을 계기로 다음 두 가지를 반성했습니다.
- 가이드라인은 확실하게, 세세하게 적자
- 크레딧 신청을 내가 직접 관리하자
1번의 경우, 가이드라인을 다시 검토해보니, 많은 부분에서, 불친절한 설명들이 느껴졌습니다. 온갖 정보들은 많은데, 읽는 이로 하여금 필요한 정보와, 그냥 홍보차 있는 정보를 구분하기 어려웠습니다.
그래서 이를 개선시키고, 크레딧을 요청하는 방법을 단계 별로 서술했습니다. 그리고 이를 계기로, 문서화와 문서 관리의 필요성을 강하게 느끼게 됩니다.
2번의 경우, 기존에는 구글폼을 제출하고, 곧바로 크레딧을 신청할 수 있도록 링크를 공개했습니다.
그러나 제출된 폼을 다시 검토하면서, 정말 많은 사람들이 폼을 잘못 제출하고 있었다는 것을 확인했습니다.
특히 왜 B612 외부 사람들이면서 왜 세션 내부 사람들로 체크를 한 사람들이 많은지 모르겠습니다.
이 사항들은 전부 OT, 그리고 여러 번 스터디를 진행하면서 반복적으로 주지시키던 내용이었습니다. 그러나 제대로 지켜지지 않고 있었습니다.
그래서 그냥, 사람들을 믿지 말고, 안전 장치가 갖추어진 시스템을 믿기로 했습니다. 기존의 크레딧 신청 시스템은 안전 장치가 갖추어지지 않은 시스템이었습니다.
그래서 크레딧 신청 방식을 개선했습니다. 구글폼이 제출되면, 저에게 알람이 오고, 제가 직접 구글폼과 크레딧 사용 계획, 후기 등을 검토한 후에 실제 크레딧 신청 링크를 줄 지 말 지 결정하기로 했습니다. 이렇게 해서 잘못된 크레딧 신청을 막는데 집중하기로 했습니다.
동아리의 운영 시스템을 개선하기 위한 노력
중구난방으로 운영되던 1기 시스템을 개선하기 위해서 지난 7, 8월 동안 정말 많은 노력을 했습니다.
사실, 1기에서 운영 방식과 시스템은 HIBL에서 이루어지던 시스템을 그대로 차용했습니다. 그러나 냉정히 생각해보면 애초에 HIBL의 운영 시스템은 그렇게 좋은 편이 아니었고, 단순히 적은 수의 열심히, 그리고 잘 하는 사람들에 의해서 겨우 돌아가던 시스템이었습니다. 일의 능률이 좋은 사람들이 시스템을 유지하고 있을 때는 문제가 보이지 않지만, 결국 구성원들의 일의 능률이 떨어지게 되는 순간 시스템은 그대로 무너지게 됩니다.
그래서 B612의 시스템을 개선하기 위해서 정말 많은 노력을 기울였고, 현재도 엄청난 노력을 기울이는 중입니다. 저의 2기 목표는 안정적인 시스템을 구축하고, 이 시스템에 대한 운영 경험과 데이터를 2기 기간 동안 구축하여 체계화시킨 뒤에, 이를 3기에 물려주고 (군대로) 떠나는 것입니다.
그러기 위해서 HIBL과 B612를 운영한 경험, 다수의 스터디를 만들고 운영했던 경험을 되돌아볼 필요가 있었고, 다른 학회와 동아리, 회사의 운영 스타일을 참고하여 모범 사례를 만들 필요가 있었습니다.
이 내용은 일반 회고록에 쓸 만한 내용은 아닌 것 같습니다. 또한, 지금 현재도 변화는 이루어지는 중이고, 아직 변화의 초반 단계이기에, 그 효과를 평가하기도 힘듭니다.
추후에 별도의 글로 분리해서, 학회를 어떻게 개선시키는 중인지 기록하겠습니다.
하지만 7, 8월 현재 B612에서 이룬 큰 변화 두 가지가 있습니다. 이에 대해서 간략히 소개합니다.
업무 시스템
가장 큰 변화는 업무 시스템입니다. 모두가 업무 진행 상황과 내용을 볼 수 있도록 노션 페이지를 구성했습니다. 그리고 이 시스템을 통해서 업무를 분배하고 지시합니다.
이 방식의 장점은 일종의 문서화가 자동으로 이루어진다는 점입니다. 각 업무에 대해서 그 안에 진행 상황과 결과를 기록함으로써, 굳이 회의 때 업무 진행 상황과 결과를 보고하느라 시간을 허비할 필요도, 그리고 보고서를 따로 작성하느라 시간을 쏟을 이유도 없습니다.
문서화를 위한 노력
다양한 학회, 그리고 구글 등의 기업, 기타 성공적인 개발 조직의 사례를 참고하면서, 공통적으로 문서화의 중요성을 강조한다는 것을 알았습니다. 문서화는 그만큼 중요합니다.
그래서 문서화를 하기 위해서 많은 노력을 기울였습니다. 업무 페이지에서 업무 내용과 결과를 적는 것도 일종의 문서화이고, 그 외에 여러 B612의 사항들을 문서로 정리하는 작업 중에 있습니다. 가이드라인, 운영진과 리드의 역할을 정리한 문서, 온보딩 문서, 회의록, 교육 보고 등등 모든 B612 내부의 사항들을 구두가 아닌 문서로 정리하게끔 바꾸어가고 있습니다.
앞으로 남은 과제
하지만 아직 변화의 초기 단계이고, 앞으로 남은 과제가 한참 남았습니다.
가장 중요한 과제는, 운영진들이 새로운 시스템을 납득하고 적응할 수 있도록 노력해야 합니다. 조직의 운영 방식의 변화는 단순히 체계와 형식이 바뀐다고 해서, 근본적인 시스템이 바뀌지는 않습니다. 모든 운영진들이 이러한 시스템이 왜 이렇게 되어 있는지 납득해야 하고, 이에 적응할 줄 알아야 합니다.
그리고 사실 학회를 운영하는데 가장 중요한 것은 학회 자체를 위한 업무를 재개하는 것이겠죠. 운영 시스템을 변화시키는 업무는 사실 학회원들 입장에서는 보이지 않는, 운영진 내부의 변화니깐요. 이 일은 개발로 따지면 새로운 기능을 개발하는 것이 아니라, 리팩토링에 가까운 일입니다. 외부에서는 보이지 않는 변화입니다.
그래서 7, 8월 달은 한동안 조직적 차원에서의 리팩토링을 진행했고, 9월 달인 지금도 조금씩 진행하는 중입니다.
세미나에 열심히 갔다 왔다
Google I/O Extended Seoul
지난 7월 29일에는 Google I/O Extended Seoul에 참여헀습니다. 이에 대한 후기는 여기에서 보실 수 있습니다.
여기에 참여해서 Google I/O 티셔츠도 선물받았습니다.
이전에 선물받은 GDSC 모자가 있는데, 여기에 티셔츠까지 해서, 저는 이제 구글 관련 굿즈가 두 개가 되었답니다.
나중에 GDSC Hongik 개강총회 때 GDSC 모자 + Google I/O 티셔츠까지 세트로 입고서 나갈 예정임.
홍익대학교 컴퓨터공학과 연합 DevTalk Seminar
이에 대한 후기는 여기에서 확인해보실 수 있습니다.
프로젝트는 없어졌다
슬픕니다. HIBL PFP 프로젝트와 악보앱 프로젝트 둘 다 엎어졌습니다.
일단 HIBL PFP 프로젝트는, 여러가지 발생되는 사소한 문제점을 해결하지 못 했습니다.
제 생각에는, 진작에 Klaytn을 사용할 것이였으면 Klaytn에 맞는 Contract를 개발했어야 했나 봅니다. 그러나 여전히 어느 곳에서 문제점이 발생하는 지 모릅니다. 저의 경우에는 기본적인 API 따는 것도 오류가 해결되지 않았습니다. 암튼 이 문제때문에 한동안 굉장히 우울했습니다.
악보앱같은 경우는, 솔직히 말해서 기획이 너무 부실해서, 더 진행되기 전에 바로 엎었습니다.
제가 기획한 것도 아니니 스스로 기획을 더 정교하게 다듬거나 완성시키기도 어려웠고, 기획자 역할을 하는 분 역시 기획을 완성시키거나 다듬으려는 의지가 크지 않았습니다.
기획이 없는 프로젝트는 안 하는 게 더 낫다는 판단 하에, 그냥 엎었습니다.
그리고 제일 결정적으로, 아마 기획과 디자인이 제대로 되었다 할 지라도 실제로 이를 구현하는 건 어려웠을 것입니다. Flutter에서 musicXML을 다룰 수 있는 라이브러리 생태계가 그리 갖춰지지 않았었습니다. 제가 직접 만들었어야 했는데, 그러기에는 현실적으로 저 혼자 musicXML 라이브러리를 파싱해서 악보로 렌더링하는 엔진을 만드는 작업을 수행하기에는 제 실력도, 시간도, 의지도 부족했습니다. 인력을 더 늘리던가 했어야 합니다. 그 무엇도 제대로 이루어지지 않았기 때문에, 엎는 게 맞았던 것 같습니다.
개강했다
개강을 했답니다. 벌써 2학년 2학기가 되었습니다.
수강 신청 잘 하시나요. 저는 이번에도 올클했답니다. 게다가 금공강입니다.
올클을 하도 잘 해서, 주위에서 한 분이 대리 수강 신청을 부탁했습니다. 그래서 그 분꺼 대리 신청했는데, 그것도 올클했습니다. 아주 좋습니다. 하지만 개강은 싫습니다.
이번에 수강신청하면서 한 가지 알게 된 게 있는데, 우리 학교에는 장학금 필터라는 게 있습니다. 해당 학기에 학과에서 지정한 과목 중에 4개 이상을 수강해야, 장학금을 받을 수 있다는 요건입니다.
예를 들어 2학년 2학기 과목 중에 장학금 요건에 들어가는 A, B, C, D, E, F 과목이 있으면, 이중 4과목을 들어야 장학금을 받을 수 있습니다.
사실 기본적인 학과의 커리큘럼을 따라간다면, 장학금 필터는 굳이 신경쓰지 않아도 됩니다. 어차피 알아서 채워집니다. 그러나 문제는 저의 경우는 제가 원하는 대로 커리큘럼을 꼬아서 듣느라, 장학금 필터링이 꼬였습니다.
그래서 이번 학기에 ‘기초데이터베이스’라는 3학년 과목을 지금 땡겨 듣고 싶었는데, 장학금 필터링 문제가 있었습니다.
이미 저는 이번 학기에 들어야 할 ‘자료구조와프로그래밍’을 1학년 때 들어버린 상태였고, 그래서 장학금 요건을 채우기 위해서는 반드시 다른 듣기 싫은 과목(데이터통신)을 수강해야 하는 입장이었습니다.
근데? 수강신청 대리해준 선배가 말하기를, 3학년이 2학년 과목을 듣는 건 필터링 적용이 안 되는데, 2학년이 3학년 과목을 땡겨 듣는 건 장학금 요건에 들어간답니다.
그니깐 다음과 같은 장학금 요건 과목이 있을 때
- 2학년: A, B, C, D
- 3학년: E, F, G, H
3학년이 필터링을 채우기 위해서 2학년 과목인 A, B를 듣는 건 허용되지 않습니다(수강 신청은 가능한데, 장학금 요건에 적용되지 않습니다).
그러나 2학년이 3학년 장학금 요건 과목인 E를 듣는 건, 필터링에 적용된다고 합니다. 이번에 새로 알았습니다.
그래서 바로 듣기 싫은 데이터통신 과목 수강철회하고, 냅다 남는 기초데이터베이스 과목 한 자리 주웠습니다. 앗싸.
수업 들어보니깐 재밌습니다. 이게 컴공이지.