🧶 Experiences

현재 재직중인 회사의 프로젝트 PoC의 전체적인 개발을 진행했습니다. React.js 기반의 Frontend는 익숙했지만 MySQL DB 사용부터 Flask를 사용하는 API Server 구현은 주변 분들의 도움을 많이 받고도 중간 과정에서 잡음이 참 많았습니다. 물론 지금은 정말, 제가 최대한 꼼꼼하게 확인한 범위 내에서는, 잘 동작하고 있으니 다행입니다.

Flask using SQLAlchemy

저번 주에는 Python과 PyMySQL을 사용해 DB에 정보를 직접 보냈다면, 이번 주에는 SQL을 생성하는 ORM 중 하나인 SQLAlchemy를 사용해 DB에서 정보를 가져왔습니다. DB의 설계를 입력하면 Query를 직접 작성하지 않아도 된다는 점이 좋았지만, 정상적으로 작동하게 하기 위해선 Query를 포함해 ORM 라이브러리에 대한 이해가 선행이 필수라는 것을 배웠습니다. 만약 그런 것들이 없다면, 저처럼 요청부터 응답까지 5초 가량 걸리도록 코드를 작성하는 실수를 범해놓고 감히 ORM을 의심할 테니까요.

그리고 비록 단 하나였지만 API를 설계하고 Postman에 기록하는 과정도 경험했습니다. 그 과정에서 Postman과 같은 프로그램으로 API의 동작을 테스트하는 것이, 브라우저에 직접 요청을 보내는 것보다 몇 배는 더 편하다는 것을 깨달았습니다.

React.js with Grid.js

Grid.js라는 라이브러리를 이용해 API로 받은 데이터를 표로 보여주는 React.js 웹 어플리케이션을 만들었습니다. 빠른 개발이 필요했으므로 Create React App을 이용해 초기화를 진행했고, API를 사용해 데이터를 가져오는 로직을 작성했습니다. 더불어서 스타일링을 위해 오랜만에 SCSS를 사용하기도 했습니다.

사실, 이전에 진행했던 다른 프로젝트에서 배웠던 것들을 적용할 수 있었던 좋은 기회였기도 했습니다. 특히 API 요청을 너무 빈번하게 보내지 않도록 Lodash의 Debounce를 React.js에서 사용하는 방법에 대해 고민했습니다.

Deploying with NGINX and Gunicorn

이미 준비된 VM 서버에 제가 제작한 결과물들을 배포하는 과정도 경험했습니다. 이를 위해 Flask 프로그램이 API Server 프로젝트를 인식할 수 있도록 구조를 변경했고, NGINX 관련 설정도 짧게나마 작성했습니다. Front 프로젝트의 Build도 진행했습니다. 배포 과정이 우아하지 못했던 것은 아쉽지만, 이는 앞으로 개선해나갈 수 있는 부분이라 생각합니다.

✏️ Lessons

Directory structure of Flask project

• Flask를 사용하는 프로젝트라면 flask run 명령어로 간편하게 실행할 수 있다. 이 경우 코드 내의 Flask 객체를 인수로 넘겨주거나 Flask가 알아서 탐색할 수 있도록 프로젝트 구조를 변경해야 한다. 이 때 Module을 올바르게 import하고 있는 지 살펴보아야 한다.

• 나의 경우, 그냥 python 으로 실행할 때는 오류 없이 잘 동작했었던 코드를 Flask와 Gunicorn이 인식할 수 있도록 하는 과정에서 모든 import 문을 절대경로로 변경했다. 사견이지만, 절대경로를 사용하는 것이 개발자에게도 프로그램에게도 혼란스러움이 없는 것 같다. Python에도 경로 Alias 같은 것이 있으면 좋겠다는 생각이 드는 경험이었다.

Gunicorn

• Server를 실행하는 프로그램이다. 가볍기 때문에 상용 환경에서 실사용하기에는 무리가 있다고들 하지만, 개발 환경에서는 적절하다고 한다. 명령어를 통해 daemon 프로세스로 실행하는 것이 가능하고, worker의 개수 또한 설정할 수 있다. 즉, Background로 실행할 수 있다는 말이다.

NGINX

• Web Server를 실행하는 프로그램이다. 단순히 특정 Port를 listen해서 응답하는 것을 넘어, 특정 url을 받을 시 다른 Port로 Forward하는 것도 가능하다. 서버로 사용할 컴퓨터에 NGINX를 설치한 후 /var/etc/nginx/* 에서 관리할 수 있다.

Grid.js

• 웹에서 데이터를 받아와 표로 표현하기 위해 사용할 수 있는 라이브러리 중 하나다. Pagination을 알아서 처리해준다는 건 분명히 좋지만, 단순 포함 검색이 아닌 상세 조건 검색 기능을 제공하지 않았기 때문에 이는 직접 구현이 필요했다.

Debounce

• 상술한 상세 조건 검색 기능을 구현하기 위해 Grid.js 객체에 전달하는 URL의 Parameter를 변경하는 방식이었는데, 이때 React.js의 state를 사용했기 때문에 값이 변경되면 Grid.js의 표까지 다시 Render하며 API를 호출해버린다. 이렇듯 Input의 값이 하나씩 변할 때마다 빈번하게 호출하는 것을 막기 위해선 Lodash 라이브러리의 Debounce라는 기능이 필요했다.

• 단, React.js와 같이 사용할 경우 useEffect의 Callback의 반환값으로 cancel 메소드를 호출해줘야 한다. 컴포넌트가 unmount될 경우 debounced된 함수가 남아있는 케이스를 대응하는 것이다.

Query Tunning

• API 호출이 너무 오래 걸린다면 Query에 문제가 있을 가능성이 있다. EXPLAIN 으로 Query를 어떻게 DB가 연산할 것인지를 확인하는 것이 가능하다.

• 데이터의 추가와 삭제 및 수정보다 탐색이 상대적으로 빈번하다면 Index를 설정하는 것도 속도를 올릴 수 있는 방법 중 하나다. Index에 설정할 Column의 기준 중 하나는 값의 고유성이며, 이는 여러 Column을 엮어 Index를 생성할 때 이들의 순서를 정할 때에도 영향을 미친다.

Environment Variable

• 개발 및 사용 환경의 프로그램은 서로 달라야 하므로, 노출되면 위험한 정보들은 OS의 환경 변수로 설정하는 편이 안전하다. Build 및 실행할 때 어떤 환경을 사용할 것인지를 인수로 넘겨주면 해당 값만 변경되며 실행할 수 있게끔 프로그램을 구성하여야 한다.

Cache when build in Create React App

• React.js에서 build를 할 경우 정적 파일의 파일 이름에 날짜가 추가되므로, 브라우저와 Proxy가 이것을 보고 새로 캐시하기 때문에 사용자에게 캐시 관련 문제가 발생할 확률이 적다.

Plan

• 본질을 놓치지 않아야 한다. 그러기 위해선 계획을 세우고 행동해야 한다. 그래야 일을 모두 처리한 이후 계획에 대한 피드백도 가능하다.

Communication

• 약속한 데드라인을 준수하지 못할 것 같다면 차라리 도움을 요청하며 일찍 이야기를 하는 것이 낫다.

웃어 넘기지 말 걸 그랬다. 😂

42 SEOUL에서는 교육생, 이하 카뎃들을 위한 여러 행사가 진행되곤 한다. 카뎃들이 자발적으로 여는 게임 대회부터 연말에는 스태프분들이 주최하는 백일장까지 그 종류는 다양하다. 그런 최근에 열렸던 이벤트들 중 가장 규모가 대단했던 것을 꼽자면 단연 해커톤일 것이다.

참여해본 경험이 전혀 없었던 나는 처음 공지가 올라온 때부터 기대 반 두려움 반을 가졌다. 행사의 취지 뿐만 아니라 필요한 기기를 대여해주는 환경 자체가 매력적이었지만, 만진 적 없는 iOS 및 라즈베리파이의 활용이 권장되고 있었기 때문이다. 하지만 난 선발 과정인 La Piscine도 통과한 카뎃이 아닌가. 난 두려움을 떨쳐내기로 했다.

세 명이서 조를 이뤄야 참가할 수 있었는데, 인원 모집이 마감되는 와중에도 아직 같이 진행할 동료들을 구하지 못했던 나는 슬랙에서 급하게 공개 구직(?)을 했다. 다행히 잠시 후 연락이 왔고, 덕분에 무언가 좋은 것을 만들어낼 수 있을 것이란 기대감은 더욱 커져만 갔다.

그렇게 해커톤 개최가 선언된 첫 날, 이노베이션 아카데미 소속의 멘토님께서 하신 말씀이 하나 있었다. 해커톤에서 아무리 기획이 좋아도 대부분 실제 구현은 로그인까지만 만들고 끝나더라는 말씀. 그 때는 모두가 그 말을 웃고 넘겼다. 나도 그랬다. 기대를 버리더라도 그 이상으로 만들 수 있지 않을까 하는 생각이 있었으니까.

하지만, 돌이켜보면 그게 우리 이야기였을 줄은 몰랐다.

설마가 사람을 잡는다. 🐴

생각해보면 우린 첫 단추부터 부실했다.

해커톤이 진행되는 온라인 화상 통화방에는 여러 조들의 고군분투하는 모습이 보였다. 대부분 세 명이서 노트북을 갖고 방에 모여 이야기를 하고 키보드를 두들기고 있었다. 두 조가 한 장소를 빌려 사용하는 진풍경도 펼쳐졌다. 그래, 모두 '실제로 모여' 있었다.

언택트 시대인데 모이는 걸 권장하는 것이 옳냐고 말할 수도 있겠다. 하지만 중요한 건 그것이 아니다. 핵심은 해커톤에서 조를 구성하고 진행하기 전부터 함께 여러가지를 의논하고 궁리한 흔적들이 보였다는 것이다. 기획이 튼튼한 것도, 장소를 섭외할 수 있었던 것도 그런 까닭이었으리라.

반면에 우리 조는 말 그대로 조를 결성하지 못하다가 급하게 모인 경우에 속했기 때문에, 해커톤 전날부터 무엇을 만들고 어떻게 진행할 지에 대한 의논이 단 한 마디도 없었다. 돌이켜보면 조금 더 적극적으로 움직였어야 했는데 말이다.

모두 다 같이 온라인으로 모였으면 좋았을 것이라 이야기하며, 무엇을 만들 지 회의를 급히 시작했다. 결국 논의된 것은 라즈베리파이도 iOS를 구동하는 아이패드도 사용하지 않는, 비교적 평범한 아이디어였다. 식사를 하고 싶은 카뎃이 식사 모임을 만들 수 있고, 다른 카뎃들은 그 모임에 참가할 수 있으며, 식사 이후에는 식사에 대한 평가도 할 수 있는 모바일 어플리케이션 말이다.

이대로 개발이 계속 순탄했으면 정말 좋았겠지만.

연락처 공유는 중대 사항이다.

첫 날 오후 저녁 여덟시에 모여 향후 개발 방향을 논의하기로 약속을 잡았었다. 시간이 되기 전부터 슬랙 창과 디스코드 둘 모두를 켜두고 기다렸지만 사십분이 되도록 두 곳 모두 아무런 말이 없었다. 불안해서 슬슬 대화를 하려고 할 때 쯤 다른 조원이 다들 계시냐는 메세지를 올리셨다. 가까스로 다행이라 생각하며 그렇게 이야기를 나누던 도중이었다.

"저기, 혹시 다른 분 연락 안 되시나요?"

우리 조에서 적극적으로 의견을 개진하며 이끄시던 위치에 있으신 분이 어째 보이시질 않는 걸 걱정하시는 것이었다. 나는 부탁을 받고 슬랙 콜과 디스코드 통화 둘 모두를 시도해봤지만 묵묵부답이셨고, 연락처를 구하기 위해 인트라넷에 접속해도 찾을 수 있는 것은 하나도 없었다. 주무시는 걸까 싶어 몇 시간이고 기다린 후에도 나타나질 않으셨기 때문에, 결국 밤을 새서 개발을 진행해보려는, 그리고 오프라인으로 진행할 장소를 같이 협의하기로 했던 우리의 계획에는 차질이 생겼다.

정신을 반 쯤 놓았다가 차려보니 벌써 다음 날 아침 여덟시였다. 불안한 나는 42 SEOUL의 스태프분께, 지금까지 모습을 나타내지 않는 동료가 있는데 어떻게 해야 좋냐는 질문을 드렸다. 내 말을 들으신 스태프분이 연락을 취해보겠다고 한 지 몇 분 뒤였다. 다행히도, 늦게나마 모습을 드러내신 동료 분께서는 '갑자기 잠에 들었고 지금 연락을 받고 깼다'라고 해명하셨다.

무단으로 모습을 드러내시지 않은 것이 개인적으로 야속했지만 그 분 탓만 할 수는 없는 노릇이다. 어쨌든 조원 셋 모두 연락처를 서로 공유하지 않은 책임이 있지 않던가. 이런 준비는 미리 누군가가 제안을 해서 진행했어야 하는 부분이라 생각한다. 앞으로 다른 작업을 공동으로 진행할 때는 연락처를 기본으로 공유해야겠다는 결심을 했다.

안 접해본 기술은 절대 쉽게 보지 말자.

다른 조들이 첫 날 저녁부터 진행했던 것과 달리, 우리 조는 해커톤 두 번째 날이 되어서야 본격적인 개발을 시작했다. 우리는 기획을 구현하기 위한 스택을 다음과 같이 정했다.

• 플랫폼은 iOS 혹은 안드로이드.
• API 서버는 AWS의 EC2.
• 데이터베이스는 AWS의 DynamoDB.

역할 분담은 조금 특이하게 됐다. 나는 La Piscine도 합격했으니 무엇이든 배우면 되겠다는 생각으로, 웹 프론트엔드만을 경험해왔던 내가 백엔드를 하기로 결정했다. 난 이 때만 해도 AWS를 사용하는 것이 닷홈 무료 호스팅을 설정하는 것처럼 쉬울 줄만 알았다. 내 기대하곤 다르게 설정해줘야 하는 부분이 많았기 때문에, 콘솔에 접속해서 서버를 개설하는 것부터가 쉬운 일은 아니었다. 일단 급한 대로 생활코딩 강좌와 Node.js 및 Express 튜토리얼 유튜브 동영상을 빠르게 훑은 나는 인스턴스를 생성하고 웹 서버를 만드는 데까지 성공했다.

한편 내가 이러는 동안 데이터베이스를 맡으신 분도 우여곡절을 겪으시기는 마찬가지였다. 첫날부터 MongoDB를 비롯한 비관계형 데이터베이스를 처음 접하신 채로, DynamoDB를 사용하기 위한 서버를 설정하는 부분에서 시간을 많이 소모하셨다. 결국 우리는 설정 도중, 계획을 변경해 DynamoDB에서 MySQL을 사용하기로 했다. MySQL을 이용하기 위해 RDS 서비스를 이용해야 했는데, 인스턴스를 생성하는 것뿐만 아니라 이를 우리가 가진 EC2 인스턴스와 연결하는 것도 또 다른 차원의 문제였다. 결국 보안 그룹 설정에 대한 개념을 알고 나서야 이를 해결할 수 있었다.

그렇게, 우리의 계획은 천천히 변하고 있었다. 모바일 어플리케이션으로 구현하는 부분을 맡으신 분도 결국 웹으로 플랫폼을 변경하자고 제안하셨다. 결국 스택은 다시 아래와 같이 바뀌었다.

• 플랫폼은 웹.
• API 서버는 AWS의 EC2.
• 데이터베이스는 AWS의 RDS, MySQL.

새로운 것을 배우는 것은 언제나 즐거운 일이다. 하지만 단 삼일 안에 완성품을 만들어야 하는 환경이라면 이야기가 달라진다는 걸 우리는 잊고 있었다. 물론 학습이 주된 목적이라면 아무래도 괜찮다는 생각도 들지만, 핵심은 배우기에 만만한 것은 없다는 것이다.

이렇게 계획이 자주 바뀐 개발이, 후술하듯 순탄할 리가 없다.

그래, 순탄한 것이 단 하나도 없었다. 💦

우리 프로젝트의 형태가 이렇게 웹 어플리케이션으로 변경된 것은 아마 둘째날 저녁이었을 것이다. 내가 처음으로 Passport 라이브러리를 사용해 로그인의 기본 구조를 만들기 위해 git push를 여러 번 명령하며 일일이 수동으로 배포하여 테스트를 진행하는 동안, 데이터 스키마는 정리되었어도 API에 대해 협의된 것은 단 하나도 없었다. 화면의 구성도도 공유된 것이 하나도 없는 채로 개발은 계속 진행됐다. 슬슬 반쯤 포기하고 싶었지만, 역으로 오기가 생겨버린 나는 로그인 만큼은 구현에 성공하리라 결심하고 편의점에서 몬스터 몇 캔을 사와 마시곤 다시 의자에 앉았다.

그렇게 셋째 마지막 날의 새벽 다섯 시가 되고 나서야, 데이터베이스 Workbench 프로그램에 방금 로그인한 내 42 인트라 계정의 아이디가 표시되는 것을 보고는 기뻐 소리쳤다. 팀원들끼리 모여 있던 슬랙에 내 성과를 알렸지만, 이미 다들 잠에 빠져버린 상태였다. 그 때서야 알았다. 이거 망했구나. 그것도 아주 철저하게.

열심히 싸웠지만 졌다! 악! 💥

셋째 날, 다른 조들이 공들인 발표 자료와 함께 시연 영상까지 깔끔하게 편집해서 모두에게 보여줄 때, 우리는 어떠한 시연도 없이 우리들의 실패한 광경을 담백하게 보여줄 수 밖에 없었다. 발표는 내가 맡았는데, 발표 마지막 즈음에 갑자기 감정이 차올라 울 뻔 한 것은 비밀이다. 진행자분께선 안타까운 마음에 발표가 모두 끝난 이후 내게 박수를 쳐주셨다.

아래 있는 동영상은 해커톤 일정이 종료된 이후, 주최 측에서 시연 영상이 필요하다고 하길래 데이터베이스 Workbench 프로그램을 띄워둔 채로 컴퓨터 화면을 촬영한 후 편집한 것이다. 지금 봐도 매우 초라하다. 클릭하면 재생할 수 있다.

이 날 이후로 모든 것을 할 수 없을 것만 같았고, 자신감이 아주 바닥이었다. 모두 뭔가 하나 씩은 해내는데 왜 나만 그러지 못하는 걸까? 내가 아무것도 못한다는 것을 모두에게 증명해버리다니. 가뜩이나 마음 속 깊은 곳에 자리 잡고 있던 자괴감이 해커톤이 끝난 이후로 더 심해졌다.

하지만 지금은 괜찮다. 다음과 같은 것을 깨달았기 때문이다: 이렇게 쫄딱 망했는데 생각해보면 나도 누군가도 피해를 입은 게 단 하나도 없잖아? 이런 게 바로 학생의 특권 아닐까?

아니, 졌지만 열심히 싸웠다! ✨

돌이켜보면 해커톤의 결과물은 없다고 쳐도 얻은 성과 자체는 굉장히 많다. 나 개인으로 한정해놓고 봐도, 프론트엔드 전문으로 하던 웹 개발자가 백엔드를 직접 경험할 수 있었으니까. 다른 팀원분들도 마찬가지였다. 데이터베이스를 담당하던 분께선 웹에 흥미를 느껴 웹 프론트엔드부터 공부하기로 결심하셨고, 다른 조원 분께서도 새로운 기술의 도입을 조심스러워해야 할 때가 있다는 사실을 깨달으셨다고 이야기해주셨다.

그리고 가장 중요한 것, 우리 모두 공통으로 깨달은 것이 있다. 바로 이상적인 협업이라는 건 매우 실현하기 어렵기 때문에 절대로 만만하게 봐선 안 된단 사실. 적절한 역할 분배, 효율적인 스케줄 관리, 기본적인 연락처 공유와 같은 프로그래밍 실력 외적인 것이, 실제론 어플리케이션 개발 진행과 완성 여부에 중요한 역할을 하고 있다는 것을 뼈저리게 느꼈다. 멘토님께서는 내가 정말 좋은 경험을 했다고 해주셨는데, 글을 적는 지금 생각해보면 그 말에 깊이 공감할 수 있다.

그래서, 그 다음은? 🤔

이번에 배운 교훈들은 다음에 협업할 기회가 생긴다고 해서 반드시 효율적으로 써먹을 수 있을 것이란 보장은 할 수 없을 것 같다. 세상엔 정말 많은 팀들이 각자의 문화와 분위기, 그리고 다양한 형태를 갖고 있기 때문에 꼭 어느 것 하나가 정답으로 통하리란 생각은 위험할 테니까.

하지만 적어도 누군가와 함께 일을 한다는 것의 소중함과 위대함을 깨달았으니, 조금은 더 조심스럽게 접근할 수 있을 것 같다. 더불어서, 물론 하나만 잘 하기도 힘들지만, 기본적인 CRUD를 할 수 있을 정도로 백엔드 실력을 키운다면 좀 더 좋은 개발자가 될 수 있을 것이라 생각한다. 그래, 아쉬운 것이 없도록 뭐든 최선을 다하자.

그래서 코드는? 💻

코드는 아래에서 확인할 수 있다.

• 🔗 https://github.com/O-Kreator/foodmate42_archive

블로그를 만든 지 채 십 분도 되지 않아 첫 포스팅을 할 생각을 하니 머리 속이 새하얗다. 어떤 흐름으로 작성해야 좋을까, 어떻게 글을 써내려가야 이상하지 않을까? 백지에서 새로운 것을 쌓아나간다는 것은 여간 어려운 일이 아니다. 내 첫 이력서를 쓸 때에도 마찬가지였다.

사실 난 이 나이가 되도록 이력서가 없었다. 웹 디자이너를 양성하는 국비 교육을 받고 급하게 써내려간 것이 있긴 했지만 오 년이 넘은 것이라 의미가 없었다. 웹 프론트엔드 개발자로 새로운 커리어를 만들어가려면 내용을 갈아 엎을 필요가 있었기도 하고 말이다.

이런 상황을 42 SEOUL의 멘토님이 아시더니 멘토링을 마칠 때 과제를 떡하니 내주셨다. 바로 이력서 작성!

언제나 준비된 인재가 되어 있어야 기회를 잡을 수 있다고까지 말씀해주시는 것을 듣고는 반성했다. 나는 준비된 인재인가? 행운 같은 순간도 물처럼 떠내려 보낼 수 밖에 없는 게으른 인생이 아니었나? 그래도 괜찮다고 생각했다. 난 신입이니까 이제부터 준비하면 되겠지.

본 포스팅은 좌충우돌 이력서 작성기를 자랑하는 것과 더불어, 멘토님께서 말씀하신 신입 개발자 이력서를 작성할 때 주의해야 할 점을 공유하고 싶어서 작성했다. 물론, 독자 여러분들께서 이견이 있다면 덧글로 친절히 짚어주시면 다른 분들께도 도움이 될 것이라는 생각이 든다.

본격적으로 이력서를 작성해보자. 🧾

처음에는 정말 아무것도 몰랐다.

멘토님께서 주신 이력서 양식은 정말 기본을 튼튼하게 갖춘 것이었다. 전형적인 것이지만 튀지 않아서 나쁠 것은 없다는 생각이 들어, 일단 양식을 바꾸지 않은 채로 항목 별로 무엇을 적을 수 있을 지 고민하기 시작했다.

당시의 나는 자신감이 바닥이었던 터라, 정말 확실한 것만 콕 짚어서 적으려고 노력했다. 더불어 난 디자인과 개발을 동시에 하고 있었기 때문에 핵심 역량에 디자이너 등 타 부서와의 소통이 원활하다는 것도 적었다. 정장을 차려 입은 차렷 자세의 증명 사진도 첨부했다. 그렇게 하루만에 완성된 이력서는 내게는 보기엔 휑하다는 것을 빼면 좋아보였다. 휑해보였던 것은 한 줄 씩 간략하게 적은 프로젝트들이 겨우 세 개에 불과했기 때문일 것이니 앞으로 채우면 된다고 생각하며 멘토님께 첨삭을 부탁드렸다.

지금 와서 돌이켜보면 내가 얼마나 잘못 알고 있었나 싶다.

신입 개발자로서 중요한 것을 잊지 말자.

멘토님께서는 제출된 이력서를 보시더니 꼼꼼하게 많은 양의 첨삭을 해주셨다. 개선할 점이 그만큼 많았다는 것인데, 이들을 정리하자면 아래와 같았다. 어디까지나 멘토님의 의견이니 이견이 있다면 덧글로 알려주시면 좋을 것 같다.

사진은 경직되지 않은 것이 좋다.

• 대기업에 들어갈 것이 아니라면 (지금의 나는 대기업에 들어갈 실력은 아니니) 너무 경직된 사진보다는 자연스러운 것이 좋다고 말씀하셨다.
• 아무래도 핵심은 '경직된 것'은 좋지 않다는 것이겠지.

정성적인 것보다는 정량할 수 있는 것을.

• 쉽게 이야기하자면 '소통 능력 원활' 같은 추상적인 것은 증명하기 어려우니 적지 말라는 것이다. 면접에서 이런 이야기가 나오면 불리해지기 마련이다.
• 차라리 특정 프레임워크나 라이브러리를 사용한 경험이 있다는 것을 관련 프로젝트와 함께 적는 것이 더 확실하다는 말씀이셨다.

진행한 프로젝트는 최대한 구체적으로.

• 진행한 프로젝트가 있다면, 어떤 것을 배우고 어떻게 활용해서 어떤 것을 만들었는 지를 구체적으로 적으라는 말씀도 해주셨다. 어차피 신입에게 중요한 건 배운 경험일테니.
• 기존에 멘토님께서 주신 이력서는 경력자 위주로 작성되었기 때문에 생긴 문제라 생각된다.

적당한 MSG는 나쁘지 않다.

• 이력서를 작성하기 전 내 이전 경험들에 대해 여쭈신 상태에서 하신 말씀이다. 한게 많은데 그에 비해서 이력서는 반도 작성이 안 됐다는 것이었다.
• 말씀을 듣고 이력서에는 자신감 있는 태도가 필요하기 마련이다. 그렇다면 경험한 것이면 자신 있게 할 수 있다고 적는 것이 나를 나타내는 데에 더 좋지 않을까? 라는 생각이 들었다.
• 물론, 면접에서 제대로 답변은 할 수 있어야겠지. 하지만 신입이 모든 것에 대답하는 것을 바라진 않는다는 것도 첨언해주셨다. 중요한 건 어디까지나 태도.

이력서에 첨부된 자기소개서는 간결하게.

• 자기소개서의 구구절절한 이야기는 빼는 게 좋다고도 말씀해주셨다. 핵심만 간결하게.
• 세세한 이야기는 면접에서 자연스럽게 푸는 것이 좋다는 의미셨으리라 생각된다.

이력서 작성, 정말로 오래 걸리더라. ✍

위와 같은 피드백들을 듣고 수정만 여러 번을 거쳤다. 전술했듯 백지에서 쌓아올리는 일은 여간 어려운 일이 아니다. 그런 만큼 시간도 오래 걸렸다. 워드프로세서 프로그램의 'PDF로 저장하기' 버튼을 얼마나 눌렀는 지 기억이 나질 않는다. 계획표에 하루만에 끝내기로 했던 이력서 작성 일정은 이틀, 사흘, 나흘로 계속 늘어나기만 했다.

이때서야 내 게으름과 오만함을 깨달았다. 내 자신을 포장하고 가꾼 상태로 보여주는 일은 한 번에 이루어지지 않는구나. 멘토님께서는 자신의 이력서를 작성하는 데에 세 달이 걸렸다고 하셨다. 내가 여타 다른 일을 할 동안 누군가는 자신의 커리어를 정리하는 데에 시간을 투자했다고 생각하니 부끄러웠다.

그리고 마침내, 이력서 완성! 🎉

멘토님께 많이 좋아졌다는 말씀을 들은 것은, 정말 있는 경험 없는 경험부터 영혼까지 끌어모아서 적었을 때였다. 면접에서 모두 답변할 수 있겠느냐는 질문에 (모두 팩트에 근거한 것들만 적긴 했어도) 자신 있게 답을 하지는 못했지만, 이제 서류 자체는 통과인 셈이다! 물론, 멘토님께서는 반 정도 밖에 못 쓴 것이라고 해주셨지만. 악! 😭

이후에도 변경점은 조금 있었다. 항목들의 순서를 살짝 바꾸거나, 디자인을 조금 바꾸거나 하는 식으로 말이다. 보기 좋은 떡이 먹기도 좋다고, 아름다운 디자인의 이력서는 나를 나타내고 꾸며주기에 적합하다고 판단했기 때문이다. 그렇게 해서 완성된 이력서는 아래와 같다.

앞의 두 페이지만 발췌했고, 모두 모자이크로 검열되어 있긴 하지만 그래도 깔끔하다는 건 느껴질 것이라 생각한다. 디지털로 볼 경우 링크된 텍스트로 포트폴리오나 연락처에 바로 연결되도록 해두었다.

이제, 그 다음은? 🤔

현재 이력서를 구직 사이트에 공개로 업로드한 상태고, 글을 쓰는 도중에도 두 곳에서 연락이 왔다. 자신감이 생기는 경험이었다. 이 자리를 빌어 좋은 경험을 할 수 있도록 올바르게 이끌어주신 멘토님께 감사의 말씀을 드립니다.

하지만 앞으로 내가 잘 해내느냐 마느냐는 오로지 내 노력에 달린 셈이다. 특히나 자신 없어 했던 기술 면접을 준비하며, 개인 혹은 팀 프로젝트들로 이력서에 추가할 것들을 실천해나가는 것은 내 몫이겠지.

앞으로 이 곳에서 제 공부와 경험을 기록하고 공유하고자 합니다. 잘 부탁드려요!