안녕하세요. 저희는 Ecole 42 Seoul Campus의 Cadet입니다. 4 Weeks동안 재미있고 의미있는 소프트웨어를 만드는 캠퍼스 이벤트, Program 42에 참여하며 모이게 되었습니다. 많은 분들이 좋게 봐주신 덕에 2등이라는 영광을 차지하게 되었고, 이렇게 개발기를 작성하여 공개할 기회도 얻게 되었습니다.
1. 팀 소개
42Mate 팀은 배경지식과 개발 경험이 풍부한 jaejeon, 클린한 코드와 커뮤니케이션이 강점인 iwoo, 그리고 프로젝트 매니징과 UX기획 경험이 풍부한 eunhkim으로 구성되어 있습니다.
42mate 팀은 단순히 프로젝트를 완성해서 제출하는 것보다 프로젝트를 완성하는 과정에서 학습하여 성장하는 것을 목표로 하였습니다. 때문에 프론트엔드, 백엔드로 역할을 나누는 보편적인 방식과 다른 방식을 택했습니다.
이 프로젝트는 트렐로와 슬랙을 통해 약 3.5주간 밀도 있는 페어코딩으로 진행되었습니다. 100% 팀원 상호리뷰와 리팩토링을 거쳤으며, 그 중 절반 이상의 코드들이 처음부터 페어코딩에 의해 초기 구현되거나 디벨롭되었습니다.
2. 문제의식
아는 사람이 없어 외롭게 밥을 먹거나, 팀 프로젝트를 하지 못하거나, 에러를 몇 시간째 혼자 붙잡고 있거나, 고민을 나누는 인간적인 관계가 필요하거나, 그 밖에 어떤 깊이와 방향으로든 관계 자산을 더 늘리고 싶어하는 42서울 유저들이 많다는 것에 문제의식을 느꼈습니다.
우리는 분명 함께할 때 42에서 더 많이 배우고, 성장하고, 또 행복할 수 있겠지만 사실 이 ‘함께한다’는 것부터가 어려운 일이죠. 관계 자산을 쌓기 위해 평가 시간 15분 동안 개인적인 관계를 쌓거나, 학습 공간인 클러스터에서 다른 사람에게 무작정 말을 거는 것은 분명 어려운 일입니다. 관계 자산을 쉽게 쌓을 수 있는 맥락이나 계기가 필요한 상황이라고 여겨졌습니다.
3. 솔루션
저희 팀이 만든 관계 솔루션, 42Mate는 네트워킹 슬랙 앱(Networking Slack Application)으로, 하루에 42Mate 앱에 등록된 1명의 다른 유저와 42분간 네트워킹의 기회를 제공합니다. 메이트와 식사, 커피, 대화, 페어코딩, 스터디 등 무엇을 할지는 유저들이 자유롭게 결정합니다.
4. 기술구조
42Mate는 네트워킹 슬랙 앱(Networking Slack Application)입니다. 때문에 Slack API 를 활용해서 개발이 되어야 합니다. Slack API 를 이용할 때 사용할 수 있는 언어는 여러가지가 있지만 그 중에서 대표적인 언어가 Python입니다. Python Framework 중에서 Flask가 가볍고 간단한 어플리케이션 서비스를 만드는 데에 효과적이고, 참고할 자료가 많아 선택했습니다. 유저 정보, 매칭 정보와 같은 데이터를 관리하기 위해 Flask 와 자주 사용 되는 Sqlalchemy 라는 ORM을 통해 PostgreSQL Database 를 사용했습니다.
위와 같은 기술들을 사용하여 만들어진 우리의 42Mate는 Database와 서버 외에는 별 다른 컴퓨팅 자원을 소비하지 않기 때문에 비교적 배포가 쉽고 간단한 클라우드 서비스인 Heroku를 통해 배포 되었습니다.
프로젝트를 진행하는 동안 모든 소스 코드는 Github을 통해 관리 되었으며, 팀원 모두의 리뷰를 받은 Pull Request 만이 develop 브렌치에 merge 되고, 사전에 정의 했던 버전에 맞게 master 브렌치에 merge 됐습니다. Heroku에서 master 브렌치를 자동 배포 브렌치로 설정했기 때문에, master 브렌치가 갱신 되면 자동으로 배포가 되어 새로운 버전의 42Mate를 사용할 수 있게 되어있습니다.
5. UI 기획
42서울이 슬랙을 주요 커뮤니케이션 수단으로 사용하기 때문에, 슬랙 어플리케이션을 만들기로 협의하는 것까지는 쉬웠습니다. 이어서 UI에 대한 고민을 했는데, 처음에는 명령어 기반의 구현을 생각했습니다. ‘/42mate register’라고 입력하면 등록이 되고, ‘/42mate join’으로 입력하면 다음 날 메이트 매칭에 참여하게 되고, 인자로 명령어를 넘겨주는 구조였죠. 하지만 사용자 경험에 대한 고려 끝에 기술적으로 더 어렵지만, UI는 버튼 뷰 방식으로 구현하기로 했습니다.
어느 채널에서든 채팅창에 /42mate를 입력하기만 하면, 이용자는 다이렉트 앱 메시지를 받습니다. 버튼 뷰가 뜨고, 내일 만나기 버튼을 누른 뒤 기다리면 밤 12시에 Mate와의 DM이 자동으로 만들어지는 구조입니다.
6. UX 기획
버튼 뷰로 인터페이스를 구현하는 것을 결정한 뒤에는, 사용자 경험의 플로우를 명확하게 기획해야 했습니다. 핵심 기능은 유저 매칭이고, 자정에 서로 1:1 대화를 주고받을 수 있는 다이렉트 채널이 만들어지도록 하는 것이 무엇보다 중요했습니다. 이를 위해 23시 42분까지 다음 날 매칭에 참여할 수 있게끔 했습니다. 여기까지가 MVP의 UX이고, 여건이 된다면 오후 6시에 매칭에 대한 참여 제안 메시지 발송, 다음 날 오전 10시에 전일의 매칭 경험에 대한 평가 제안 메시지 발송 등의 경험을 추가적으로 구현하기로 했습니다.
7. 데이터 모델링
이 소프트웨어는 원격으로 모든 코드가 작성되었고, 오프라인으로 만난 것은 킥오프 미팅이 다였습니다. 그런데 돌아보면 원격으로 프로젝트가 문제없이 잘 진행될 수 있었던 것은 그 한 번의 오프라인 미팅을 잘 진행했기 때문인 것 같습니다.
42메이트 팀은 킥오프 미팅에서 데이터 모델링을 무엇보다 먼저 진행했습니다. 이 프로젝트에 있어서 핵심이 되는 클래스가 무엇일까. 매칭 앱이니까 사람(User)과 만남(Match)이 가장 우선적으로 정의되어야 하고, 이후 개발 여건이 된다면 만남에 대한 평가(Evaluation)까지도 만들어야 한다고 봤습니다.
활동(Activity)의 경우 따로 클래스를 만들 것이 아니라 이용자에게 맡겨야 하는 영역입니다. 그러나 개발 당시 코로나 기간이었기에 리모트 네트워킹 액티비티를 제공해야 한다는 협의가 있었고, 또 오프라인에서 진행되더라도 아이스 브레이킹 액티비티는 있는 편이 좋다고 판단해 추가된 클래스입니다.
8. 프로젝트 플래닝
본격적인 개발에 들어가기 전에 모든 feature를 트렐로에 카드 단위로 쪼갰습니다. 카드 리스트는 Not started, Not Re-started, Progress, Complete, QA, QA Complete의 6단계로 구현하고 상황에 따라 각 feature 카드를 적절한 단계로 옮길 수 있도록 했습니다.
각 카드에는 구체적으로 아래와 같은 항목들을 포함시켰습니다.
- 기능 이름(feature)
- 항목의 구분(front/back/qa)
- front/back 카드의 경우 포함될 버전(1.0, 1.1, 1.2, refactor…)
- 항목에 대한 설명(description)
- 잘 구현되었음을 어떻게 평가할 수 있는지(to-be)
- 세부 task들에 대한 체크 리스트(check-list)
- 누가 개발하는지(assign)
9. 어플리케이션 구조 작성
42mate 어플리케이션은 Flask 프레임워크를 이용하여 만들어졌고, 프레임워크에 따라오는 기본적인 파일들을 제외하면 주요 소스 파일은 10개 정도로 분할했습니다. 우선 가장 밑에는 class가 정의된 models.py 파일이 있고, 데이터들은 SQLalchemy를 이용해 db_manage.py 파일에 작성한 코드들로만 접근했습니다.
사실상의 메인 파일들은 유저의 요청에 응답하는 app.py와, 시간에 따라 매칭, 평가, 초대 등 스케쥴링된 액션들을 실행하는 scheduled_action.py입니다. 이 두 파일에서 다른 파일의 함수들을 유틸로 사용해 유저에게 메시지를 보내고, 메시지에 대한 유저의 응답은 command_callback_message.py 파일에서 처리되는 구조입니다.
그 과정에서 따로 소개할만한 것은 ‘block’ 이라는 개념인데, 슬랙에서 API를 업데이트하면서 유저에게 보내는 것을 단순히 메시지가 아니라 ‘block’이라는 개념으로 바라보게 되었습니다. 메시지, 버튼, 이미지 등 하나하나의 요소들을 조립하여 블록을 만들고 그 블록을 전송하는 개념입니다. 42메이트 팀도 처음에는 이런 기술적 변화를 인지하지 못하고 메시지로 발송하다가, 알게 되면서 block.py라는 파일을 설계하고 모든 메시지를 블록으로 조립하여 보내는 것으로 변경했습니다.
10. user 모델 구현
42mate의 유저는 primary key로 쓰이는 index를 제외하면 다섯 가지 필드를 가집니다. slack_id, intra_id, register, joined, match_count 입니다. 각 필드의 역할 명세는 다음과 같습니다.
- slack_id : user의 slack id
- intra_id : user의 42 intranet id
- register : 어플리케이션에 대한 등록 여부
- joined : 내일 다른 유저와 매칭을 희망하는지 여부
- match_count : 다른 유저와 몇 번 매칭을 진행했는지의 수
처음에는 ‘어떻게 하면 더 좋은 매칭을 성사시킬 수 있을까?’라는 가치를 더 실현하기 위해 user에 대한 정보가 하나라도 더 많아야 한다고 생각했습니다. 그래서 어플리케이션에 자신을 등록할 때 많은 정보를 물어보고, 대답을 받아서 저장하고 싶었습니다. 하지만 그럴수록 user는 더 귀찮아지고, 이용자의 감소로 이어질 것이 뻔하게 여겨져 과감하게 다 쳐냈습니다. 소프트웨어가 운용되는데 필수적인 다섯 개의 필드만 남겼고, 이것도 이용자가 입력해야 되는 것들이 아닙니다.
먼저 slack_id는 유저에게 메시지를 보내고, 매칭된 유저들끼리 1:1 DM 채널을 만들기 위해 꼭 필요한 기능적 정보입니다. intra_id의 경우 메시지 내용 안에서 우리가 user의 이름을 언급하고, 매칭시 서로를 소개시켜주기 위해 경험적으로 꼭 필요한 정보이지요. 매칭을 희망하는지 여부를 파악하기 위해 joined 역시 반드시 필요한 정보였고, register의 경우 매칭에 대한 참여제안 메시지를 유저가 비활성화할 수 있도록 하기 위해 구현했습니다. 마지막으로 match_count는 알고리즘 상 매칭 성공 확률 및 상대 선정에 있어서 신규 유저를 배려하기 위해 만들어진 정보입니다.
11. match 구현
매치는 42mate의 핵심 기능입니다. 매일 밤 자정에 42mate에 등록된 ‘매치 의사’를 밝힌 유저들을 2명씩 매칭시키고, 두 유저가 1:1 대화를 나눌 수 있도록 채팅방을 만들어 서로가 각자 ‘그 날의 메이트’임을 알렸습니다. 이 때 두 유저가 자연스레 라포를 생성할 수 있도록 ‘액티비티’도 함께 전달하였습니다.
‘두 유저간에 매치를 생성하는 방식’은 처음에는 무작위로 선택된 유저간에 매치가 생성되도록 단순 구현하여 MVP에 적용시키고, 이후 목적에 맞게 정교화해나가기로 했습니다. 현재 버전에서는 유저가 최대한 다양한 유저들을 만나볼 수 있도록 하기 위해, 한번도 매치된 적이 없었던 유저간에 우선적으로 매치가 생성되도록 구현되어있습니다.
만약 ‘매치 의사’를 밝혔음에도 ‘매치 의사’를 밝힌 유저 수가 홀수여서 매치가 생성되지 않은 유저에게는 유감이라는 메세지와 꿀팁(사실 홍보 유도😉)을 전달했습니다.
구체적인 방식은 다음과 같습니다.
- 아직 매치가 생성되지 않은 유저를 찾아 unmatched_users 리스트를 만든다.
- unmatched_users에 포함된 유저를 한명 골라서 한번도 만난 적이 없는 유저를 탐색한다.
- 만약 한번도 만난적이 없는 유저를 찾아냈다면 그 유저와, 끝까지 탐색했는데도 한번도 만난적이 없는 유저가 없다면 마지막으로 찾아낸 유저와 매치를 생성한 후 unmatched_users 리스트에서 제외시킨다.
2번은 브루트포스로 심플하게 구현했습니다. 사실 더 효율적인 방법이 많지만, 초반에는 유저가 최대 200명 이하라는 점(42seoul 1기 1차생이 200명이 안됩니다.), 개발기간은 촉박하고 구현할 기능은 많다는 점을 감안하여 비효율이 문제가 될 때 개선하는 게 좋다고 판단했습니다.
매치는 매일 자정에 생성되도록 세팅해야 했습니다. 이를 위해 heroku에서 자체 제공하는 addon인 heroku job schedular와 ‘scheduled_action.py’ 파일을 연동시키고, 이 파일에 매치를 생성하는 함수를 위치시켰습니다.
12. 초대 및 평가 기능 구현
42mate의 유저 경험은 편리성에 대한 UX를 제외하면 ‘다른 유저와의 만남이 좋았는지’에 의해 결정됩니다. 저희 팀은 논의 끝에 긍정적 유저 경험, 즉 ‘좋은 만남’은 다른 유저를 알아갈 의지가 있고, 매너가 좋은 유저와 만나는 경험이라고 협의했습니다. 반면 ‘나쁜 만남’은 매칭된 유저가 정작 만날 의지가 없어서 연락이 되지 않거나 다른 사정으로 만나지 못하는 경우라고 판단했습니다. 또한 매너가 좋지 않은 등 불유쾌한 경험을 주는 유저와 매칭된 경우도 이에 속한다고 봤습니다.
MVP 모델에서 구현된 초대와 평가는 유저들의 ‘나쁜 만남’을 줄이기 위해 구현한 기능입니다.
12-1. 초대(invitation) 구현
42mate에 등록한 유저이더라도 계속 다른 유저와 만날 수 있는 의지와 상태라고 보장할 수 없습니다. 다른 유저와 만날 의지가 충만한지, 다른 사정이 있는지 여부를 확인하는 방법을 고민했습니다. 다양한 방법이 있겠지만 매칭 전에 유저에게 직접 물어보고 승낙받는 것이 가장 확실하고 직관적이라 생각했습니다. 이 때 너무 빈번하게 물어보면*(마치 스팸처럼!)* 유저경험을 해칠 것이고, 너무 뜸하게 물어보면*(ex 한달에 한번)* 매칭 전에 유저의 상태를 적절히 반영하지 못할 것이 우려되었습니다.
결과적으로 매일 오후 18시에 다음날에 만남을 가질지 여부(참가 여부)를 물어보는 메세지를 전달하는 기능을 구현했습니다.
구체적인 구현은 다음과 같습니다.
먼저 초대 블록을 생성한 후, DB에서 42mate에 등록되어있지만 다음날 만날지 여부를 밝히지 않은 유저 목록을 불러와 listing합니다. 그리고 이 list에 속한 유저에게 초대 블록을 함수를 구현했습니다.
마지막으로 이 함수를 매일 특정시간에 반복실행시키기 위해 매치구현시 활용했던 heroku job schedular에 연동된 ‘scheduled_action.py’ 파일에 위치시켰습니다.
만약 전달한 초대블록에서 ‘응! 만나고 싶어.’ 라는 버튼을 클릭하면 해당 유저의 정보DB가 업데이트되고, 추후 매칭대상에 속하게 됩니다.
12-2. 평가(evaluation) 구현
불유쾌한 경험을 주는 유저(이하 block/deny user)를 줄이기 위한 구체적인 정책을 정하지는 않았지만, 우선 ‘block/deny user’임을 확인하기 위해 유저간의 ‘만남에 대한 만족도’를 수집하기로 했습니다. 이를 위해 평가 메세지를 매치가 있었던 다음날 오전 10시에 전달하였습니다.
이 때 평가정보를 저장하기 위해 DB에 Evaluation model을 추가했습니다. 매치와 매치에 속한 유저들의 정보와 평가정보를 어떻게 연결할지 고민했습니다. 유저에게 평가메세지를 보내는 시점에 평가를 생성하면 DB에서 해당 유저와 유저가 속한 매치의 정보를 불러오는 비용이 추가로 들고 흐름도 자연스럽지 않다고 판단했습니다.
결과적으로 매치를 생성시킬 때마다, 매치에 속한 유저가 번갈아가며 평가자, 피평가자로 설정된 평가를 두 개씩 함께 생성시켜 Evaluation model에 row로 추가시켰습니다.
이후 해당 row와 연결된 평가 메세지가 발송되고, 받은 응답을 바탕으로 row에 값이 기록되도록 하였습니다. 마찬가지로 매일 특정시간에 반복실행되는 기능이므로 매치구현시 활용했던 heroku job schedular에 연동된 ‘scheduled_action.py’ 파일에 위치시켰습니다.
13. 액티비티 구현
액티비티는 처음에 없었던 기능입니다. 우리는 42서울의 유저들이 42분간 무엇을 하든 상관이 없었고, 무엇을 할지에 대해서 유저들이 스스로 결정할 수 있는 권한을 남겨두고 싶었기 때문입니다. 하지만 코로나가 심화되면서 리모트로만 학습을 진행하게 되고, 원격으로는 함께 할 수 있는 활동이 제약되고 어색함이 커지기 때문에 액티비티를 넣자는 목소리가 커졌습니다.
또 주객이 전도되어 관계의 주요 활동이 액티비티가 되어서는 안 되겠지만, 그게 무엇이 되었든 서로 함께하고 싶은 활동을 하기 위해 어색함을 풀어주는 아이스 브레이킹은 있으면 좋겠다는 얘기도 있었습니다. 그래서 만들어진 것이 액티비티입니다.
시범적으로 5개 정도의 리모트 액티비티를 추가했습니다. 처음에는 하나의 활동 안에서 할애해야 하는 시간이 더 길었습니다. ‘5개의 공통점 찾기’가 아니라 ’20개의 공통점 찾기’ 같은 식이었습니다. 하지만 앞서 얘기한 것처럼 액티비티가 메인 활동이 되면 안 되고, 이 기능이 서비스에서 맡는 역할을 생각했을 때에는 5분에서 10분 안에 끝날 수 있게 더 축소시키는 게 맞다고 판단해서 간소화했습니다.
14. 테스트
시작에는 42 프로그램 챌린지라는 이벤트가 있었지만, 쓰이지 않는 소프트웨어는 가치가 없다는 것에 대한 팀원들의 생각이 일치했습니다. 우리가 만든 소프트웨어를 사람들이 얼마나 원할까? 좋아할까? 어떤 점들을 불편해할까? 이런 궁금증을 가지고 자연스럽게 사용자 테스트를 진행했습니다.
약 일주일 정도 테스트를 진행했고, 작은 규모이지만 10건이 넘는 매칭이 일어났습니다. 표본이 매우 적어서 큰 의미가 있는 데이터라고 볼 수는 없어도, 그래도 사용자 테스트를 통해 다음과 같은 지점들을 생각해 볼 수 있었습니다.
- 초대 기능의 효과(초대 제안 응답을 통해 매칭에 참여한 유저 비율)
- 명령어 입력을 통해 매칭에 참여하는 시간대
- 평가 메시지에 대한 유저 응답 비율
- 평가 응답율과 만족도의 상관관계
- 액티비티 항목과 만족도의 상관관계
실제로 사용한 사례입니다. iwoo님과 chlim님은 일면식이 없었지만, 42mate 덕분에 궁금한 점을 좀 더 편하게 물어볼 수 있는 관계가 되었답니다😎
15. 주요 문제 회고
iwoo: DB를 구현, 관리하는 것이 어려웠습니다. 42메이트는 MVP부터 구현한다음 버전업시키며 기능을 추가로 구현했습니다. MVP에서는 모델별로 최소한의 컬럼과 모델만 존재했지만, 이후 버전에는 컬럼이 추가되고 평가 모델이 새로 생성되는 식이었지요.
문제는 모두 DB관련 지식이 부족하다보니 모두가 DB를 변경할 권한을 가지고, 각자 필요에 따라 DB 마음껏 변경해가며 개발을 진행했다는 것입니다. merge 시킬 때 git이 충돌나거나, 충돌을 해결하더라도 서비스가 제대로 실행되지 않는 등 좌충우돌 우여곡절이 많았네요..
eunhkim: 시간을 다루는 이슈가 특히 어려웠어요. 42메이트는 시간과 관련된 이슈가 많은 어플리케이션입니다. 오후 6시에 초대 메시지가 발송되고, 당일 오후 11시 42분까지 다음 날 만남에 대한 등록이 가능하며, 11시 42분부터 12시까지는 유저의 접근이 차단됩니다. 자정이 되면 매칭이 진행되고, 오전 10시에는 전날 만남에 대한 평가 메시지가 발송되지요.
UTC와 Asia/Seoul 중 어느 시간대로 처리할 것인지 결정하는 것도 우여곡절이 많았지만, 결정하고 나서도 서버와 DB에 저장되는 시간대가 다르다거나, 특정 시점에서 한국 시간으로 날짜를 판단해야 하거나, 시간을 한 쪽에서 다른 한 쪽으로 변환하거나 하는 과정에서 많은 어려움을 겪었어요. 국내를 서비스 영역으로 삼아도 이런 시행착오들이 있었는데, 글로벌 서비스를 개발할 때에는 어떨까 생각하니 아찔하더라고요.
jaejeon: 데이터베이스와 시간 이슈 모두 어려웠지만, 저는 협업이 가장 어려웠던 것 같아요. 지금 까지는 계속 혼자 개발하고 프로젝트를 진행했고, 같이 개발을 할 때에도 서로 다른 파트를 맡아서 각자의 기능을 만든 뒤 합치는 방식으로 협업을 했기 때문에 큰 어려움이 없었어요. 하지만 42Mate 프로젝트를 두 분과 같이 진행하면서 각자 기능별로 분배해서 코드를 작성하는 것이 아니라 모두가 페어 프로그래밍을 하면서 개발했기 때문에 그 사이에서 변수/함수 네이밍이나 용어 인식에 대한 차이 등이 발생할 수 밖에 없었고 항상 혼자서 개발하던 저는 이러한 부분들이 제일 어려웠어요. 하지만 팀원 모두가 각자의 생각을 끝까지 들어주고 서로를 이해하며 협업했기 때문에 끝까지 문제 없이 잘 진행할 수 있었어요. 다음에 협업을 하게 된다면 더욱 잘 할 수 있겠다는 자신감까지 얻게 되었어요.
16. 통합 회고
iwoo : 실제로 사람들이 쓸 수 있는 서비스를 직접 구현해서 배포한 것은 처음입니다. 훌륭한 동료들 덕분에 기대했던 것보다 성장에 도움이되는 경험을 많이한 것 같아 뿌듯합니다.
실제로 돌아가는 서비스를 만들기 위해 기술외적인 부분(프로젝트 매니징, 기획, UX 등등)에서도 깊은 고민이 필요한 것을 새삼 실감했습니다. 팀원들이 태도가 좋으셔서 토론이 즐거웠네요 🙂
기술적인 부분에서도 정말 많이 배웠습니다. 처음 쓰는 기술들을 빠르게 학습하고 적용하는 것이 막막했지만, hustle하며 도와주신 동료분들 덕분에 결국에는 해냈네요! (UTC는 절대 잊지 않겠다..ㅎㅎ)
C언어만 깊게 파느라 객체지향에 대한 이해가 없었는데, 다음에는 객체지향개념도 적극 활용해보고 싶네요! 😉
eunhkim : 항상 슬랙을 쓰는 조직에, 커뮤니티에 있었기 때문에 슬랙이 얼마나 가치있는 툴인지 알아요. 하지만 슬랙앱을 만들 역량은 없어서 항상 아쉬웠죠. 그래서 슬랙 어플리케이션을 만드는 프로젝트에 참여한 것 자체가 의미있었던 것 같습니다. 정말 거의 모든 기술이 처음이었어요. 짧은 시간 안에 Flask, SQLalchemy, Postico, Slack API 같은 새로운 기술들을 학습하면서 어플리케이션을 만든다는 게 쉽지 않았지만, 쉽지 않은 걸 결국 어떻게든 해내게 되서 보람을 느낍니다.
jaejeon : 내가 사용하고 싶은 서비스를 직접 만들 수 있는 경험을 한 것이 가장 소중했던 것 같습니다. 42 서울이라는 곳에는 정말 다양한 사람들의 다채로운 경험들이 모여 있는데, 그 것을 알아 갈 수 있는 경험이 더욱 많았으면 좋겠다고 생각하고 있던 와중에 42Mate 프로젝트에 참여하게 되어서 좋았습니다.
추가적으로 Slack api를 이용하면서 slacker라는 오픈 소스 라이브러리를 사용하게 되었는데, 사소하지만 우리에게는 치명적인 버그를 발견하게 되어 수정한 코드를 pull request 보내 오픈 소스에 기여하는 경험을 하게 되었습니다. 하지만 몇 달이 지나도 merge가 되지 않아 좀 더 살펴보니 아쉽게도 그 몇 주 전에 다른 사람이 동일한 이슈로 pull request를 만들었고 merge된 흔적이 있더라고요. 내가 수정한 코드가 반영 되었으면 하는 바람이 있었지만 그래도 좋은 경험을 했다고 생각해요! 42Mate 프로젝트를 함께 하지 않았더라면 아마 오픈 소스에 기여하는 방법을 아직 까지도 모르고 있었을 것 같아요.