미리보기
기본 정보
안녕하세요. 3년차 소프트웨어 엔지니어입니다. 프로덕트를 만드는 프로세스 전반에 두루 관심이 있어, 풀스택 개발을 하고 있습니다. 프론트엔드는 React, NextJs로, 백엔드는 NestJs로 개발하며, 주로 AWS 클라우드 환경에 배포해왔습니다. 또한, 현 직장에서는 컨트랙 개발 직군을 맡고 있어 솔리디티로 스마트 컨트랙을 개발할 수 있습니다.
기술 스택
JavaScript, react.js, Next.js, NestJS, Prisma, aws-ec2
경력
주식회사메셔(MesherInc.)
컨트랙 개발자 | 개발팀 | 재직 중
2022.06. ~ 재직 중 (2년 5개월)
- 스테이킹 플랫폼인 '타임캡슐(timecapsule.mesher.io)' 서비스의 프론트엔드 개발
- 마블렉스에서 서비스하는 스왑 프로토콜인 'MBX Swap(swap.marblex.io)'의 프론트엔드 개발
- 위메이드에서 서비스하는 '위퍼블릭(wepublic.com)'의 컨트랙 개발
티맥스소프트(주)
개발연구원
2020.12. ~ 2022.03. (1년 4개월)
- 슈퍼앱 프론트엔드 개발
제이투씨(J2C)
풀스택 개발자 | 개발팀
2019.09. ~ 2020.06. (10개월)
- 대학생들을 타겟으로 한 협업툴인 마밀라 풀스택 개발
- 여객수단 조회 서비스인 막타 풀스택 개발
프로젝트
woobuntu.review
개인
2024.01. ~ 진행 중
출퇴근 시간에 지하철에서 자기계발을 하고자 만든 복습앱입니다.
메인 화면에서 복습 버튼을 누르면 제가 노션에 정리한 자료 중 무작위로 선택된 자료의 링크를 반환합니다.
여기서 무작위란 완전 무작위는 아니고, 복습 횟수, 복습 오답률, 복습 기간 각각을 가중평균하여 가장 복습 횟수가 적고, 복습 오답률이 높으며, 복습한지 오래된 자료부터 반환하는 것입니다.
처음에는 EC2 서버에 프론트엔드 애플리케이션과 백엔드 애플리케이션을 모두 배포하였습니다.
그런데 생각보다 비용이 많이 나오게 되어 비용 절감 방안을 모색한 결과 백엔드 애플리케이션은 Lambda와 API gateway의 조합으로, 프론트엔드 애플리케이션은 S3와 CloudFront의 조합으로 배포하였고, 상당 부분 비용을 절감할 수 있었습니다.
woobuntu.finance
개인
진행 중
이전에 회계 공부를 했던 경험을 살려 가계부를 복식 부기로 작성하는 앱을 개발하였습니다.
처음에는 EC2 서버에 프론트엔드 애플리케이션과 백엔드 애플리케이션을 모두 배포하였습니다.
그런데 생각보다 비용이 많이 나오게 되어 비용 절감 방안을 모색한 결과 백엔드 애플리케이션은 Lambda와 API gateway의 조합으로, 프론트엔드 애플리케이션은 S3와 CloudFront의 조합으로 배포하였고, 상당 부분 비용을 절감할 수 있었습니다.
코로나 알리미 & 마스크 알리미
기타
2020.02. ~ 2020.11.
코로나 알리미는 Django 풀스택으로, 마스크 알리미는 Vue.js와 Express.js의 조합으로 개발하였고, 저는 두 서비스의 서버 운영을 담당하였습니다. (서버는 aws의 ec2를 이용하였습니다)
대규모 사용자가 이용하는 서버를 운영해본 경험이 없었기에 코로나 알리미의 운영 때는 서버가 내려가는 일이 자주 발생했습니다. 이를 반성하여 마스크 알리미의 운영 때는 프론트엔드 서버와 백엔드 서버 각각에 로드 밸런싱을 적용하였습니다. 그 중 프론트엔드 서버의 로드밸런싱에서 문제가 발생했는데, 브라우저에서 일정 확률로 ‘unexpected token’에러가 발생하는 것이었습니다.
이는 당시 웹펙이 캐싱을 위해 번들링된 파일명에 해시값을 포함시킨다는 것을 모른 채로 로드 밸런싱을 적용시켰기에 발생했던 문제였습니다. A서버에서 받아온 html파일의 js, css파일의 요청이 B서버로 전달되고, 해당 해시값을 포함하는 파일을 찾지 못한 B서버는 제가 nginx에 설정한 대로 index.html파일을 반환했습니다. Js, css파일을 요청했는데 html파일을 받았기에 브라우저가 unexpected token 에러를 반환했던 것입니다. Aws의 로드 밸런서를 사용했었기에 sticky session설정으로 간단하게 해결할 수 있는 문제였으나 당시에는 그러한 지식이 없었습니다. 각 서버에서 번들링된 파일의 해시값이 다른 것을 문제의 원인으로 생각했기에, 로컬에서 번들링하여 번들링된 결과물을 각 서버에 공유하는 것으로 임기응변하였습니다.
lazy-student
개인
2020.03. ~ 2020.06.
중문과 재학 시절, 중국어 문장 암기를 위해 제가 하던 반복 작업이 있습니다. 제가 암기 하기 용이한 포맷으로 정리하기 위해서는 각 문장별로 구글 번역, 카카오 번역, 네이버 번역 페이지를 순회하면서 발음 기호(병음)와 각 서비스별 번역 내용을 모아 재구성하는 작업이었습니다.
이를 자동화하기 위해 중국어 문단을 입력값으로 넣으면, 구두점을 기준으로 문장들을 분리하고, 각 번역 서비스별로 요청을 보내 병음과 번역 내용을 받아와 정리된 형태로 출력하도록 구현하였습니다.
해당 프로젝트를 통해서 중국어 문장 암기를 위한 준비 작업에 사용되던 시간을 줄여 실제로 문장을 암기하는 작업에 더 많은 시간을 할애할 수 있었습니다.