회고 #1
2022년 1분기
Swift UI
Swift UI를 이용해서 iOS 네이티브 앱을 개발했다. socket.io를 통한 채팅 앱이었는데, 소켓 연결의 관리에 많은 어려움이 있었다. 다만 UI를 개발하는데에 있어 Storyboard보단 탁월한 장점을 보인다는 것은 완벽하게 체감했다. 그럴 일은 없길 바라겠지만 네이티브로 iOS앱을 만들어야 할 경우가 생긴다면 그때도 어김없이 Swift UI를 사용할 것이다.
Knowledge Graph
Neo4j를 이용해 지식그래프를 구현했다. 제품, 기업, 국가의 도메인이 있었으며 생산, 수입, 수출의 관계가 있었다. 어느 정도 모양은 나왔는데, 퍼포먼스가 너무 낮았다.
GCP Cloud Function
매우 간단하다. AWS의 lambda와 같은 기능이다. 편리하게 사용했지만 테스트를 하는 방법을 몰라 불편했다. 하지만 GCP 역시 다시는 쓸 일이 거의 없을 것 같아서 다행이다.
GCP Natural Language API
요소 추출과 텍스트 분류를 진행했다. 정확도는 역시 구글답게 꽤 높지만 필요로 하는 데이터를 만들기가 많이 불편했다. 크롤링을 통해 필요한 데이터를 가져오는 것은 문제가 되지 않음에도 불구하고 해당 API에서 요구하는 포맷으로 텍스트를 라벨링하는데 많은 공수가 들었다. 만약 룰베이스로 그것이 가능하다면 그런 방법으로 다시 시도해보고 싶다.
퇴사
약 11개월간 재직하던 회사를 떠났다. 참 좋은 결정이었다.
세 번째 직원으로 합류했던 그 회사는 CEO의 인맥을 통한 확실한 비즈니스 모델이 있었지만, 돌이켜 생각해보면 커리어를 쌓는 데에는 아주 극악의 환경이었다. 회사의 첫 개발자로 입사해(파이썬 백엔드) 미친듯이 굴렀다. 인력 보충은 되지 않았으며 연관 없는 업무의 연속이었다. Koa.js로 백엔드를 개발했고, Vue.js를 통해 PC 웹의 대시보드를 만들었다. 그리고 피벗.
웹뷰로 채팅 앱을 개발했지만, 또 한 번의 피벗으로 네이티브 앱까지 개발했다.
기사 노릇도 했다. 서울의 꽤 유명한 호텔에 어떤 제품을 납품할 때 담당자를 태우고 내 개인 소유의 차로 다녀오는 일들이 종종 있었다. 회사 소유 창고로 제품이 들어오면 용달 아저씨와 함께 제품을 쌓았다.
정치도 경험했다. 이 스타트업은 성공할거라는 생각에 나는 내게 주어진 모든 업무에 No!를 하지 않고 미친듯이 일했다. 당연히 CEO와 가까워질 수 밖에 없었고, 우리 둘 사이를 질투하던 사번 2번 직원과 마찰이 잦았다.
HR, 경리 등의 업무를 맡던 그 직원에 의해 나, 내 친구가 피해를 입었고 참을 수 없었다.
마지막까지 뱀같은 그 직원의 혀에 당해 쫓겨나듯 퇴사해 백수로 지냈다.
2022년 2분기
입사 지원
참 많은 회사에 지원했다. 네카라쿠배당토 중 한 곳 부터 작은 스타트업까지. 면접을 엄청나게 보면서 많은 팁과 좋은 회사를 고르는 방법을 터득했다. 이 방법을 미리 알았다면 참 좋았을 텐데... 하는 아쉬움도 많이 남았다. 하지만 결론적으로 먼저 나의 능력이 선행되어야 한다. 모 기업의 코딩테스트, 면접, 라이브 코딩을 진행하며 참 많이 부족하구나 느꼈다.
결론적으로 3곳에 최종합격했다.
입사
세 회사는 각각 다른 특징을 가지고 있었다.
회사 N
- NLP, CV관련 일을 하는 팀과 함께 일할 수 있다.
- 회사가 지방에 존재한다.
- 서울과 지방의 연봉 체계는 다르다며 연봉 삭감을 요청했다.
회사 A
- 인지도가 많이 높은 편이다.
- 가장 높은 연봉을 제시했고, 비포괄임금제를 운영한다.
- 식비 무제한 등 복지가 잘 되어있다.
- 면접 경험이 부정적이었다.
회사 P
- 연봉이 애매하다.
- 정시 출퇴근에 대한 강박이 비교적 적다.
- 면접 경험이 긍정적이었다.
결론적으로 회사 A와 P를 고민하던 중 P를 선택했다.
면접 때 나의 20대 목표에 대해 공유했다. 그 이야기를 들은 면접관께서 충분히 회사가 도움을 줄 수 있고 함께 성장했으면 좋겠다는 메시지를 너무 잘 전달받았다.
그리고 현재 약 6개월간 아주 행복하게 일을 하고 있다. 야호!
GraphQL
현재 내가 맡고 있는 프로젝트는 GraphQL로 서버와 클라이언트가 통신한다. 지금까지의 경험과 읽어본 레퍼런스, 사람들과 나눈 이야기를 통해 내린 나의 결론은 다음과 같다.
장단점이 너무나도 명확하다.
GraphQL로 얻는 이점은 있으나 분명 잃는 것도 있다. 그 때 상황에 맞춰가며 잘 결정해야 할 것 같다.
DDD
DDD에 대해서는 친구 덕분에 처음 알게 되었다. 단순 도메인에 따라 분리하는 거 아닌가? 라고 생각했었지만, 이 회사에서 직접 느껴보며 '아 괜히 DDD가 유행하는 것은 아니구나.'라고 느꼈다. 아직 부족하지만 도메인과 레이어를 명확한 설계에 의해 아름답게 분리하고 그 위에 코드를 짜고 싶다.
배포
배포 브랜치에 머지를 하면 CodeBuild에 의해 자동으로 배포가 이루어진다.
너무 행복하다... 동료에 의하면 Github Action을 통해 배포를 하는 것이 개인적으로 조금 더 재밌다던데. 지금 진행하는 프로젝트에 적용해볼까 한다.
비동기 처리와 스케쥴링
내가 주로 사용하는 언어인 파이썬은 기본적으로 동기로 동작한다.
그리고Celery라는 라이브러리가 그 문제를 해결하기 위해 존재한다.
Celery와 Celery Beat를 사용하면서 신세계를 경험했다.
하지만 ...
Github Action을 추천해준 동료가 AWS Batch와 AWS lambda가 더 효율적인 것 같다는 의견을 제시해서 내 세상이 조금 무너졌다.
한 회사 면접을 볼 때 스케쥴링에 대한 질문이 있었다. 그때 나는 lambda와 cloudwatch를 떠올렸지만, 지금 생각해보니 그때 정답은 아마 celery beat였지 싶다.
Test
테스트케이스는 정말 너무 중요하다..............
맺음말
전 회사를 다닌 11개월보다 4월부터 6월까지 성장의 폭이 더 크다.
과거의 나는 분명 노력했지만...
환경탓을 과거의 나는 정말 싫어했다.
가치도 없는 핑계라고 생각했지만,
좋은 환경을 경험해보니 환경탓은 분명 존재한다.
야호!
