반복되는 크롤링 작업을 Spring Batch로 해결해보자

나는 하루에 책을 얼마나 읽었는지 기록하고 이를 그래프로 나타내는 서비스를 개발하고 있다.

따라서 책 정보가 필수인데 책 검색 API를 사용하기보다 크롤링을 통해 우리 서비스에서 필요한 정보만 저장하기로 결정, 크롤링을 통해 정보를 저장중이었다.

기존 크롤링 방법

1. 모든 카테고리를 순회하면서 각 카테고리 별로 20권씩 크롤링

2. 매 탐색마다 책 정보를 DB에 바로 저장

3. 원하는 정보가 누락되어 있거나 탐색 중 에러가 발생한다면 해당 책은 스킵

딱 1000권만 크롤링 할 목적으로 코드를 작성했기 때문에 위 방법으로 진행해도 문제가 없었다.

하지만 신간도서 관련 기능이 추가되면서 반복적으로 크롤링을 해야 하는 상황이 벌어지니 문제가 발생했다.

문제

1. 이전에 진행한 크롤링으로 저장된 책이 다음 크롤링에서 다시 저장되는 책 중복 발생

2. 매 탐색마다 책 정보를 바로 저장하다보니 총 1000번의 쿼리 발생

3. 크롤링이 중간에 멈추게 된다면 중단된 시점까지의 책 정보가 그대로 저장

4. 기능 확장으로인해 Elasticsearh 추가, 데이터를 ES로도 전송해야함

크롤링으로 인한 문제와 추가된 기능들로 인해 기존 서비스 구조로는 문제를 해결할 수 없다고 생각했고 내가 필요한 기능들이 모두 갖추어진 Spring Batch를 사용해서 이 문제를 해결하기로 했다.

Spring Batch를 사용하는 이유

1. 크롤링, DB에 저장과 같은 반복적인 작업의 자동화

2. 대용량 데이터의 안전하고 빠른 처리

3. 작업 실패 시 기존 상태로 복구

데이터 처리 과정

1. 크롤링 정보 1차 저장

   • 크롤링 한 정보를 List로 만들어 저장한다. 그 후 크롤링이 끝나면 MongoDB에 List를 저장한다.

   • 이 때 책 정보를 List에 저장하면서 동시에 책 URL을 Map에 저장한다. 이는 이후 Redis에 저장된다.

   • 1차적으로 MongoDB에 저장하는 이유

     1. 백업

     2. Monstache를 사용해서 ES에 동기화시키기 위함

     3. 크롤링 시 책 필드 변경이 용이

1. 크롤링 정보 2차 저장

   • MongoDB에 저장한 정보를 실제 서비스에서 사용할 MySQL에 저장

   • TransactionManager를 사용해 에러 발생 시 chunk size 만큼 rollback

3,4. Collection 변경 감지, 변경된 상태 적용

• Monstache를 사용해서 변경된 상태대로 ES 동기화

• Spring Batch의 step으로 저장하지 않고 Monstache 사용

  • ES는 rollback, transaction을 지원하지 않기 때문

    

  • 굳이 step으로 처리할 필요 없이 Monstache로 관리하는 것이 좋다고 판단

1. 중복 확인용 책 링크 저장

   • 1에서 저장한 Map을 Redis에 저장한다.

   • MongoDB보다 비교적 빠른 Redis를 사용해서 빠르게 중복된 책인지 확인

   • 가장 마지막에 Key값을 저장하기 때문에 이전 step이 실패해도 문제 x

적용 후

위 순서로 데이터를 저장하는 Spring Batch Application을 Docker image로 만들어 EC2에서 실행중이다.매주 월요일마다 크롤링을 진행하고 안전하게 저장되는 것을 보니 적용하는데 까지 오래 걸렸지만 이제 크롤링에 신경쓰지 않아도 되니 마음이 편해졌다.

[RememberPlus] 리더로 활동하면서 어떻게 성장했을까? 2번째 부트캠프를 마치며.

오랜만입니다! 이번엔 부트캠프에 리더로 참여하면서 어떤 일들이 있었는지 약 42일간의 여정을 담아 낸 글을 가져와 보았습니다.

많은 일들이 있었고, 그 동안 성장했던 부분들의 성과를 알 수 있는 좋은 경험이었습니다.

반려동물 혈당 데이터 기반 맞춤 사료 추천 서비스, Fit-A-Pet

우리 귀여운 강아지, 고양이 등 반려동물이 당뇨로 꽤나 고생을 하고있다는 사실 알고계신가요??

동물친구들은 사람에게 아프다고 말을 할 수가 없기 때문에, 당뇨를 예방하기란 정말 까다로운 일이에요 ㅠㅠ

그래서 저희는 반려동물에게 혈당센서를 착용시키면,
혈당 데이터를 차트로 시각화하여 당뇨를 빠르게 발견해 예방하고
맞춤형 사료를 추천하여 혈당 정상화를 도와주는 프로젝트를 만들어보았습니다!

주요 기능

1. FreeStyle Libre를 통해 획득한 혈당 데이터를 Selenium로 자동화 후, Scheduler로 4시간에 한 번씩 자동으로 저장

2. 저장된 혈당 데이터를 차트로 일, 주, 월 단위로 시각화

3. 반려동물 정보, 혈당 데이터를 기반으로 맞춤형 사료 추천

시스템 아키텍쳐

데모 영상

Github

Medium

팀원
@임지훈 @전서진 @양소연 @조승연 @이경은

Redis Cluster 를 파헤쳐 보았다

Redis Cache세션 및 Clustering 테커톡을 준비하며 자료를 조사하다 보니, 생각보다 자세하게 설명된 자료가 많이 없었습니다.
Redis Cluster에서의 노드 간 통신, 장애 감지와 Failover 등에 대해 깊게 다뤄보았습니다.
정말이지 이렇게까지 깊게 들어갈 생각은 없었는데(...), 어느새 Redis 코드까지 뒤지고 있는 저를 발견했습니다.

이왕 깊게 들어간 거, 이해하기 쉽게 글로 남겨보았습니다.
😁

Graphy, 프로젝트를 기록하다

개발자를 준비하다 보면, 좋은 프로젝트에 대한 고민이 많아진다.

하지만 처음부터 좋은 프로젝트를 개발하는 것은 어렵기에 대부분 프로젝트 레퍼런스를 참고하거나, 주변에 평가를 받아 개선하기도 한다.

Graphy는 이를 도와줄 수 있는 프로젝트 공유 플랫폼이다.

개발자로 취업 준비 중인 사용자를 타겟팅한 포트폴리오 기록 사이트로, 사람들이 보다 좋은 프로젝트를 개발할 수 있도록 도와주는 것을 목표로 하고 있다.

👀 Graphy 메인 페이지

👀 Graphy 프로젝트 공유글 작성 페이지

👀 Graphy 프로젝트 공유글 검색 및 상세 페이지

👀 Graphy 프로젝트 공유글 검색 및 상세 페이지

⚠️ Graphy가 겪은 이슈

❗️ 댓글 API 개선기 (Backend)

댓글은 계층형으로 구현하고 경우에 따라 삭제되더라도 “삭제된 댓글입니다.” 형태로 화면에 보이도록 했다.

초기에 설계했던 댓글 삭제의 비지니스 로직이다. 댓글의 경우 답글의 유무에 따라 삭제 처리가 달랐고, 반대로 답글의 경우 화면에서 바로 지우지만, 추가로 원댓글에 대한 삭제 로직이 존재했다.

해당 로직을 다중 IF문을 사용해 구현했었으나, 이 방법은 서버에 부담이 될 수 있고, 응답 속도 저하로 사용자의 부정적인 경험을 유발할 것이라고 예상해 두 가지의 개선안을 생각했다.

1. 이전과 달리 댓글 답글 모두 삭제 처리, 조회 시 쿼리문을 이용한 삭제된 댓글 마스킹
2. 서버에서 처리했던 로직은 최대한 쿼리문으로 처리

하지만, 또 다른 문제가 발생했다. 조회 시 모든 댓글과 답글을 불러오기 때문에 다수의 댓글이 저장된 경우 지연이 발생할 수 있었다.

이 문제는 유튜브 댓글 방식으로 해결했다.

유튜브는 답글의 개수만 보여주고, 클릭을 해야 조회가 이루어진다. 기존의 전체 조회가 아닌 이 방식을 적용해 성능을 개선했다.

🔅 성능 개선 결과

 댓글 9,000개를 기준으로 각각 삭제에 있어 각각 44%, 75%의 개선 효과

❗️ QUILL 에디터 이미지 처리 (Frontend)

프로젝트를 작성하고 공유하는 저희 프로젝트 특성상 텍스트 에디터가 필요했기에 Desktop/Moblie 지원이 가능하고 한글 입력이 가능한 Quill 에디터를 선택하였다.

Quill 에디터를 활용하여 글 작성 기능을 개발하였고, 직접 사용해보면서 글을 작성하는 데 오랜 시간이 소요되는 것을 알게 되었다.

여러 시도를 해보면서 이미지를 넣은 글이 글만 있는 게시글보다 훨씬 작성 시간이 오래 걸린다는 것을 발견했다.

이 문제점에 대한 정보를 찾아보니 Quill 에디터는 기본적으로 이미지를 BASE64로 인코딩 해서 업로드 한다는 것을 알게 되었다. 기존의 이미지 처리방식은 프론트에서 이미지를 서버로 넘기고 그 이미지를 S3로 넘기는 방식인데, 8비트를 6비트로 표현하려는 Base64의 특성 때문에 33%의 용량 증가가 발생하며 이 증가한 용량과 긴 문자열을 다시 이미지로 표현할 때 걸리는 시간 때문에 로딩 시간이 결국 증가하게 된 것이다.

이를 해결하기 위해 프론트에서 S3로 바로 이미지를 업로드 시킨 뒤, 서버에 URL만 보내는 대안을 생각했다.

바꾼 이미지 처리 방식에서는 프론트에서 직접 S3로 이미지를 업로드 시키기 때문에 그 과정에서 서버를 경유하지 않아도 된다. 이미지 파일이 아닌 URL만 백엔드 서버로 전송하면서 용량 문제도 해결했다. 추가로 사용자가 이미지를 요청할 경우에도 서버에서 반환한 URL을 바로 사용해 이미지를 보여줄 수 있어, 로딩속도까지 감소하게 된다.

🔅 성능 개선 결과

이전과 비교하여 로딩 시간 약 38% 개선

〽️ 추후 고도화 계획

🧠 AI 고도화 계획 추천 기능

사용자가 공유한 프로젝트에서 사용한 기술, 구현한 프로젝트&기능, 관심있는 고도화 계획을 입력받아 chatGPT를 이용하여 추후 고도화 계획을 추천해주는 기능을 개발할 예정이다.

사용자 편의에 맞춘 성능 개선 뿐만 아니라, 사용자가 필요로 하는 기능을 추가해 더 나은 서비스를 제공할 예정이다.

Graphy는 창의적인 아이디어를 공유하고, 발전 방향을 제시함으로써 개발자의 성장을 지원한다.

지금 여기 날씨, 지금 우리 스타일 - FashionCloud

⛅프로젝트 주제 선정

프로젝트 주제를 선정할 때 고려한 점들이 있었다.

추천받은 몇 가지 키워드 중에서 마음에 드는 키워드를 골라 그에 알맞는 프로젝트 주제를 선정하고자 했다.

1. 첫째, 시시각각 변하는 유동적인 데이터 사용하기

2. 둘째, 공공데이터를 주기적으로 끌고 와서 사용하기

따라서 시시각각 변하는 공공데이터인 도로교통정보나 항공정보 등 여러 후보 중에서 고민하다가 날씨 정보를 이용하게 됐다.

날씨가 비슷한 다른 지역의 사용자들과

데일리룩을 공유하는 SNS ☂️

”집에서 나갈 때마다 남들은 이런 날씨에 무슨 옷을 입었는지 참고할 수 있다면?”

이런 생각에서, 위와 같은 프로젝트 주제가 탄생했다.

⛅ 날씨 공공데이터 사용하기

날씨 데이터를 사용하는 것은 꽤나 어려운 과정이었다.

openAPI 문서는 친절하지 않았고, 열심히 해석해서 활용해야 했다.

☂️ 세 가지 예보 타입 ☂️

초단기실황은 ‘가장 최근에 만들어진, 10분 간격으로 업데이트되는 실황 데이터 ’를 사용하는 것이고

초단기예보는 ‘10분 간격으로 업데이트되는 가장 가까운 예보 데이터 ’를 사용하는 것이므로

초단기실황 데이터가 초단기예보 데이터보다 더 정확할 것이라 판단했다.

이에 따라 최대한 많은 날씨 데이터를 초단기실황에서 뽑아 쓰고, 초단기실황에서 제공하지 않는 정보는 초단기예보에서 가져와 쓰기로 했다.

예보별 사용하는 데이터

1. 초단기실황 — 기온, 1시간 강수량, 습도, 강수형태, 풍속 데이터

2. 초단기예보 — 하늘상태 데이터

3. 단기예보 — 최저/최고 기온 데이터

하늘상태 데이터와 최저/최고 기온 데이터는 초단기실황 예보로 제공되지 않으므로, 초단기예보와 단기예보까지 세 가지 예보 데이터를 적절히 사용하여 현재 날씨 데이터를 만들었다.

(정확히 말하자면, 하늘상태는 실황값이 아니고 가까운 예보값이므로 현재 날씨라고 보기는 어렵다.)

⛅ ‘날씨가 비슷한’의 기준 ❔

처음 구상했을 땐 기온과 하늘상태, 강수형태를 가지고 파악하려고 했다.

그러나 적절한 옷차림을 파악하는 데에 중요한 것은 실제 기온보다는 체감기온이라고 생각하여,

절대적인 기온 대신 체감온도로 비슷한 날씨를 파악하기로 했다.

1. 체감온도

사람마다 기온 차이를 인지하는 것은 차이가 있지만, 일반적으로 1도~3도부터 차이를 인지하기 시작한다고 한다.

따라서 기온이 +-1도 차이나는 경우를 날씨가 비슷한 경우라고 판단했다.

2. 하늘상태

맑음에 해당하는 경우는 하늘코드(0) 뿐이다.

흐린 경우는 구름많음(3), 흐림(4) 두 가지 모두 해당된다고 생각하여, 두 경우를 비슷한 날씨로 정했다.

3. 강수형태

강수형태는 딱 나누기에 애매한 부분이 있었다.

기상청에서 제공하는 날씨 정보가 비/눈이거나 빗방울눈날림인 경우는 비로 구분할지 눈으로 구분할지 애매했다.

그래서 이런 날씨는 눈과 비 모두에 해당되는 것으로 정했다.

❄️‘눈’에 해당하는 날씨 = 눈 + 비/눈 + 빗방울눈날림 + 눈날림

🌧️‘비’에 해당하는 날씨 = 비 + 비/눈 + 빗방울 + 빗방울눈날림

🟥 캐싱

우리는 백엔드 서버를 거쳐 기상청으로부터 날씨 데이터를 받아오므로, 사실상 api호출은 두 번 일어나는 셈이다.

클라이언트에서 날씨 정보를 요청하면 그 때마다 외부 기상청 서버로 날씨 데이터를 또 요청해야 한다.

이에 따른 병목 문제를 해결하기 위해 날씨 정보를 캐시에 저장하기로 했다.

사용자의 위치를 Key로, 그 위치의 날씨 정보를 Value로 하여 key-value store인 Redis에 저장한다.

하지만 날씨 정보를 요청하는 위치마다 모두 위경도를 캐시에 저장하는 것은 불가능하다고 생각했다.

우리나라는 동경 124도와 132도 사이 / 북위 33도와 43도 사이에 위치하며

위경도는 소수점 아래 여섯 자리까지 표시하므로, 위치 데이터로 가능한 경우의 수가 약 33만개로 엄청나게 많아지기 때문이다.

이렇게 되면 캐시 데이터가 지나치게 많아지는 캐시 폭증 문제가 발생할 수 있고, 캐시 메모리를 낭비하게 된다.

또한 이렇게 세밀한 단위로 캐싱하게 되면 hit ratio가 낮아져 캐싱의 의미가 없을 것이라 생각했다.

🗺️ 위경도가 아닌 격자점을 Key로 하기

이에 대한 해결책으로, 위경도가 아닌 격자점 단위로 key값을 저장하기로 했다.

기상청은 위경도를 XY 격자좌표로 변환하여 날씨 정보를 요청하도록 하고 있다.

어차피 같은 격자점 내에서는 같은 날씨를 응답하므로, 캐시 데이터를 줄이고 hit ratio를 증가시키기 위해 격자점 단위로 저장하는 것이다.

X축 격자점 수는 149개, Y축 격자점 수는 253개이므로 경우의 수가 약 3.8만가지다.

위경도로 계산할 때보다 key값이 될 수 있는 경우의 수가 90퍼센트가량 감소된다.

🚨 날씨 정보 불일치 문제

날씨 정보를 캐싱하는 것은 좋은 방법이라고 생각한다. 그러나 캐시에 저장된 정보가 실제 날씨 정보와 다르면 아무 의미가 없어진다.

날씨 정보는 계속해서 업데이트되므로 캐시에 저장된 날씨도 이에 맞게 업데이트해줘야 한다.

최저/최고기온은 당일 새벽 2시에 생성된 데이터를 사용하면 되지만,

나머지 모든 날씨 정보들은 10분 간격으로 업데이트된다.

캐시 불일치 문제를 막으려면 날씨 데이터 업데이트 시간마다 캐시가 초기화되거나, 그 시간마다 캐시 업데이트가 일어나야 한다.

💚 스케줄러로 캐시 업데이트

이런 캐시 일관성 문제를 해결하기 위해 기상청의 날씨 정보 업데이트 시간마다 캐시의 날씨 정보를 업데이트하기로 했다.

key로 저장된 격자점 좌표를 가지고 기상청 서버로 날씨 데이터를 재요청하여 날씨 정보를 업데이트한다.

🔃 캐시된 모든 데이터를 업데이트?

원래는 격자점의 개수를 잘못 계산하여, 캐시된 모든 날씨 정보를 업데이트하는 데에 무리가 있다고 생각했다.

따라서 API호출횟수가 많은 지역만 캐시 업데이트를 스케줄러로 자동화하고, 그렇지 않은 지역들은 매 10분 단위로 캐시 삭제하려고 했다.

(이 때 10분 단위라는 것은, 저장된 후 10분이 아니고 n시 10분, 20분, 30분,,과 같은 절대적인 단위다)

(잘못된 정보로 발표했던 자료다.😅😅)

그러나 생각보다 격자점 개수는 많지 않았다. 캐시된 모든 격자점의 날씨 정보를 업데이트하는 것에 무리가 있을지 현재로서는 잘 모르겠다.

이는 개발하면서 문제가 생기면 개선해나가는 방식으로 해결할 계획이다.

➕ 앞으로 개발할 추가 기능

1. 👗 인스타그램으로 데일리룩 공유하기

나의 데일리룩 사진에다가 현재 날씨에 알맞는 배경을 추가하고, 현재 날씨를 적어 인스타그램 스토리로 공유하는 기능을 개발할 계획이다.

2. 🩱 적합한 옷차림 추천해주기

사용자가 데일리룩을 업로드할 때, 옷 카테고리 태그와 함께 옷을 입었을 때의 후기를 업로드한다.

이에 따라 ’어떤 날씨에 어느 옷을 입었을 때 어땠는지’ 에 대한 데이터를 수집하고 통계를 내서 적합한 옷차림을 추천해주는 기능을 개발할 계획이다.

[Project : HQRoutine] 테커인의 낮, 즐거웠던 POC 중간발표의 날

최근 4월 30일 테커인의 낮 행사에 다녀온 후 발표했던 내용을 공유하고자 글을 작성했습니다. 글을 올리는 지금(5월 11일)을 생각해보면 시간이 꽤 지난 것 같기도 하네요.

이 글에는 행사에서 발표했던 프로젝트와 관련된 내용을 담았습니다.

POC까지 무사히 마쳤는데 그 이후의 목표가 무엇인들 못해낼까요?

마지막까지 원하는 목표를 완수해 낼 수 있으면 좋겠습니다.

[Project : HQRoutine] 테커인의 낮, 즐거웠던 POC 중간발표의 날

2023 Series [ 2023 ] CheckPoint, 2023년 2023년 동안 작성했던 의미있다고 생각하는 포스팅들을 모아 둔 게시글입니다 이 글은 2023년이 끝날 때까지 계속해서 업데이트 해 나갈 예정입니다 [ January ] - 변화의 시작, 1월 더보기 [2022WinterBoo time-map-installer.tistory.com 들어가며 프로젝트의 첫 번째 분기점인 POC 단계가 모두 끝난 이후에 약 60여 명의 네트워킹 시간을 통해 진행상황을 공유하는 행사를 진행했습니다. "테커인의 낮"이라는 이름의 이 행사를 통해 그동안 비대면으로만 봐 왔던 팀원분들과 다른 여러 개발자분들, 그리고 여러 스타트업과 기업에서 대표로 방문해 주신 분들을 만나 뵈었고, 그분들과 함께 이야기를 하며 더..

https://time-map-installer.tistory.com/212

두 번째 부트캠프 도전기, 프로젝트 POISON 회고록

2년 전, 개발을 시작해보고자 무작정 지원하여 하게된 부트캠프에서 리액트를 사용해 프론트엔드 개발을 시작한 것이 저의 개발자로서의 첫 발걸음이었습니다.

결과는 비록 제대로 완성되진 못했지만 팀원들과 무언가를 개발하여 결과물을 낸다는 것에 크게 흥미를 느꼈고, 그 이후부터 꾸준하게 공부와 프로젝트를 하며 이번 두번 째 부트캠프에 다시 도전하게 되었습니다.

그 과정속에서 겪었던 경험과 이슈들을 공유해보고자 합니다🙂

이번에는 팀 리더로서 활동하게 되었습니다.

잘할 수 있을까 걱정에 앞서 짧은 기간동안 아이디어 기획, 디자인, 개발까지 완료해야 하기 때문에 이전 부트캠프 경험을 살려 빠르게 아이디어 선정부터 해서 POC까지 진행하였습니다.

그렇게해서 최종적으로 선정된 아이디어가 독초 판별 웹서비스 POISON🥀 입니다

이번 프로젝트에서 기능 자체는 심플하게 가져가면서, 적용해보고 싶은 기술 스택들을 최대한 활용해보자 하는 마음으로 진행했습니다. 그 중에서 제가 처음 접해본 기술과 경험 위주로 공유해보도록 하겠습니다.

프론트엔드 에러 로그 트래킹 시스템 Sentry

클라이언트에서 발생하는 오류를 파악하는 가장 확실한 방법은 오류가 나는 해당 브라우저의 개발자 도구에서 오류 내용을 파악하는 것입니다.

하지만 개발 과정에서 오류가 발생할 때 마다 오류를 공유하기 위해 에러가 일어나는 유저의 화면을 공유하고 내용을 확인하기는 매우 번거로운 일입니다.

따라서 프론트엔드 단에서 에러 로그를 트래킹할 수 있는 Sentry를 도입하였습니다. 🙂

Sentry를 사용함으로써 저희 팀은 아래와 같은 이점을 얻을 수 있을 것이라고 판단하였습니다.

• 에러를 더 쉽게 찾을 수 있다
• 다른 사람이랑 줌으로 연결해서 이렇게 해라 저렇게 해라 하면서 오류 재현을 하지 않아도 됨
• 사용자가 오류를 리폿할 땐 이미 그 오류가 센트리에 잘 꽂혀있음
• 다른 팀원에게 물어봤어야 할 부분도 직접 먼저 캐치해서 알잘딱깔센하게 담당자한테 알려줄 수 있음
• 자주 나는 오류를 찾기도 더욱 편리함
• 플랫폼별 차이로 인해 발생하는 에러
• 예시: 익스플로러 환경에서는 호환되지 않는 코드
• API 연동 오류로 인해 발생하는 에러
• 예시: 꽃 유형 중 하나에 일부 데이터가 누락된 걸 찾을 수 있음

이번 프로젝트에는 무료버전으로 적용했지만 프로젝트 규모가 커진다면 충분히 유료버전으로 결제할만한 가치가 있다고 생각이 들었습니다 🙂

생산적인 FE개발, MSW

이번 부트캠프 팀들 중 저희팀은 다른팀보다 월등히 빠른 개발 속도를 자랑했습니다.

저는 빠르게 개발을 진행할 수 있었던 일등공신이 바로 MSW였다고 생각합니다.

프론트엔드 개발을 진행하면서, 필연적으로 백엔드와의 API통신은 이루어집니다.

하지만 아직 백엔드쪽에서 API 개발이 완성되지 않았다면?

그렇다면 프론트엔드는 더미데이터를 만들어 임시로 보여주거나 해당 부분은 배제하고 UI부터 개발하게 되고, API 개발이 완료된 후 API 통신 코드로 리팩토링하여 진행하게 될 것입니다.

이번 부트캠프 특성상 짧은 기간내에 개발을 완성해야 하기 때문에 백엔드에 의존적이지 않게 Mocking API를 만들어 개발할 수 있는 MSW를 도입하게 되었습니다.

MSW는 브라우저에서 일어나는 네트워크 요청을 가로채어 실제 서버가 아닌 클라이언트 사이드에 있는 MSW 라이브러리에 전달되어 등록된 핸들러를 통해 Response를 브라우저에 응답하는 방식으로 작동합니다.

따라서 실제 Mock 서버를 구현하지 않고도 네트워크 수준에서 API를 Mocking할 수 있는 환경을 제공할 수 있습니다!

작성된 API명세서를 토대로 프론트엔드 측에서 테스트할 API를 만들어 백엔드에 의존적이지 않게 개발할 수 있었고 API 개발이 완료되었다면 Request URL만 바꿔주면 되니 개발속도를 엄청나게 단축시킬 수 있었습니다!

Docker Compose와 Github Actions, 서비스 배포

Docker Compose와 Github Actions는 이전에도 사용을 해봤지만 Docker Compose 환경의 애플리케이션을 AWS EC2에 배포하고 CI/CD를 적용해 본 적은 이번이 처음이었습니다.

❓frontend 컨테이너와 nginx 컨테이너간에 정적 파일을 어떻게 매핑할까?

각각 컨테이너로 분리되어 있기 때문에 frontend의 정적 파일을 nginx 컨테이너에 어떻게 넘겨줄까 고민이었습니다.

멘토님들과 다양한 레퍼런스를 찾아본 결과 volumes를 통해 컨테이너간 파일을 매핑할 수 있었습니다.

build_folder라는 볼륨을 만들고 frontend의 정적파일과 매핑한 후, nginx 설정파일에서 지정한 정적파일을 읽는 경로와 다시 매핑시켜 nginx에서 frontend의 빌드 결과물을 읽을 수 있도록 하였습니다.

❓CI/CD 파이프라인을 어떤 방식으로 구축해야 할까?

docker compose 애플리케이션에서 CI/CD를 적용하기 위한 깃허브 액션의 workflow는 크게 두가지로 나눠볼 수 있었는데

1. compose파일을 Image로 만들고 Docker hub에 배포 후 EC2에서 이미지를 받아 compose up 하기
2. EC2에서 깃허브 레파지토리를 pull받아 compose up하기

1번 방식을 적용하기에는 우리 프로젝트에 맞는 레퍼런스를 찾기 어려웠습니다.

멘토님의 추천으로 비교적 간단하게 작성할 수 있는 2번 방식을 채택하여 workflow를 작성하고, 동작할 스크립트를 작성해 주었습니다.

물론 더 효율적인 방법이 있었겠지만 개발 기간이 짧았기 때문에 이대로 진행하게 되었습니다.

마치며..

회고에는 담지 못했지만 비동기 분산 처리를 위한 프론트엔드의 polling 적용, useInfiniteQuery훅을 사용한 무한스크롤 구현, Storybook을 사용한 UI 인터렉팅 테스트 등 이번 부트캠프 프로젝트에서 다양하게 많은 기술들을 접목하여 개발해보는 경험을 가졌습니다.

다양한 기술을 써보는것에 초점을 맞추어 개발하다보니 서비스 기능의 단순함과 UI 부분이 살짝 아쉬웠습니다.

힘들었던것과 별개로 5주동안 팀원들과 밤새 같이 개발하고 고민하는 시간이 너무 즐거웠고 잊지 못할 추억으로 남아있습니다.

부족한 리더를 잘 따라와준 팀원들 덕분에 무사히 프로젝트를 완성할 수 있었습니다. (팀원분들 감사해요 👍)



프로젝트에 더 궁금한 내용이 있다면 편하게 커피챗 걸어주셔도 좋습니다! ☕️

감사합니다 🙇‍♂️

심슨 너가 왜 거기서 나와..? - 심슨필름 프로젝트 회고

어디선가 본 얼굴이 나왔네요😁

우선, MZ세대를 저격한 심슨필름 프로젝트에 대한 소개를 하겠습니다.

사용자가 업로드한 사진을 AI가 옷을 분석해서 심슨에게 같은 옷을 입혀주고 폴라로이드 사진을 남겨주는 플랫폼입니다. 심슨필름을 사용하여 나만의 심슨을 만들고, 만든 이미지를 SNS에 공유할 수 있습니다.

인스타그램으로 공유를 해봤는데, 반응이 좋았어요~

심슨필름은 Techeer 부트캠프에서 진행한 프로젝트입니다.

이번 프로젝트에서 경험한 내용과 이슈, 해결 과정을 공유해보려 합니다.

프로젝트 개발 경험

이번 프로젝트에서 어쩌다 보니 프론트엔드 개발 리더를 맡아서 진행 했습니다. 개발 경험이 많지 않아서 처음엔 부담스러웠지만 잘 이끌어 보려 노력했습니다. 그런 과정에 많은 경험을 했는데 일부분 공유 해보겠습니다.

프론트엔드 디자인도 잘해야한다..?

프로젝트 인원중에 디자이너가 없었습니다.. 따라서 디자인은 주로 프론트가 진행하게 되었고, 디자인 하면 금방 하겠지 했지만.. 생각보다 많이 어려웠습니다😅 또한, 만들고 보니 개발자 입장에서 디자인을 하고 있었습니다. 개발하기 편한 쪽으로 말이죠. 앞으로 프론트 개발을 하면서 디자이너가 구현한 대로 개발을 해나가야 하는데, 만약 디자이너가 원하는대로 구현하지 못 하겠다면 어쩌나..? 싶었습니다. 이 과정에서 두 가지 생각이 들었습니다.

첫째, 뭐든지 해내는 실력으로 만들자!

둘째, 해내지 못하는 이유를 타당하게 말하고 고쳐달라 하자!

저의 생각은 첫 번째로 정리 했습니다. 생각해보면 디자인도 제품에 큰 영향을 준다고 생각했기 때문입니다. 따라서, 디자인을 시각화 하는 코드를 짜는데 집중을 하고 있습니다.

프론트라고 프론트만 알면 고생한다..

백엔드에 대한 지식이 많지 않던 저에게 백엔드와의 소통을 쉽지 않았습니다😅 프론트 개발을 하다 보면 백엔드에게 부탁을 해야할 일이 여러모로 많은 것 같습니다. 이러한 상황이 나타난건 API 명세서 작성 과정이였습니다. API 명세서는 보통 백엔드가 맡아서 진행하는 걸로 알고 있었습니다. 신경 안쓰고 개발을 하다가 나중에 확인을 해보니 프론트에서 필요한 데이터가 없거나, 불필요한 데이터가 있거나, 형식이 이상하거나 등등 추가적으로 소통을 해야하는 상황이 있었습니다. 이렇게 진행되다 보니 프론트도 백엔드도 다시 시간을 투자해야하는 상황이 발생했습니다. 따라서, 프론트라고 프론트만 하는게 아닌 백엔드에도 어느정도의 관심을 가지고 개발을 해나가야 원활한 프로젝트 진행이 될 수 있다는 것을 느꼈습니다. 덕분에 현재 진행중인 다른 프로젝트에서는 백엔드와 API 명세서를 같이 작성하며 진행하고 있습니다😆

이번 심슨필름 프로젝트를 통해 개발 전반적인 경험에 대해 알 수 있었던 좋은 경험이였습니다🥹 이어서 개발하면서 있었던 이슈와 해결 과정에 대해서 얘기해보겠습니다.

이슈 및 해결과정

#이슈1

⛔️ AI 분석 결과를 동기적으로 데이터 받아서 사용자의 대기 시간이 길어져 사용자 경험 감소

⛔️ 짧은 주기의 API 요청으로 트래픽 발생

해결

•  Polling 개념 적용
• AI 분석 평균 속도 결과를 Polling 요청 간격에 적용

성과

•  Polling을 구현하여 주기적인 요청으로 사용자의 대기시간 감소, 사용자 경험 증가
• AI 분석 평균 결과를 Polling 방식 요청에 반영하여 API 요청 트래픽 감소

#이슈2

⛔️ 페이지네이션 구현중에 불필요한 API 요청( 같은 요청 ) 트래픽 발생

해결

•  React-Query 라이브러리 적용하여 캐싱 기능 활용

성과

• React-Query 캐싱 기능을 이용해 불필요한 API 요청 트래픽 감소
• 클라이언트와 서버 데이터 분리하여 관리
• 기존 코드보다 깔금한 에러 핸들링

정리한 생각

이번 프로젝트를 통해, 개발자로서의 역량을 크게 향상시킬 수 있었습니다. 특히, 프론트엔드 개발에 대한 이해도를 높이고, React와 React-Query를 활용하여 소스 코드를 효율적으로 작성하는 방법을 익힐 수 있었습니다. 또한, 다른 개발자들과 함께 일하면서, 협업과 코드 리뷰의 중요성을 깨닫게 되었습니다. 앞으로도 이러한 경험을 바탕으로, 더 나은 개발자로 성장할 수 있도록 노력할겁니다✋

[Project : HQRoutine] 6차 스프린트 회고

이번 주는 4월 치고는 유독 추웠던 한 주가 아니었나 싶습니다

시험기간도 오고 프로젝트 POC 기간도 다가오고 점점 바빠지고 있는 요즘, 한 가지 특이점이 발생하고 있는데 저는 그걸 활용하고 있습니다

시험기간의 특징이 무엇 일까요? 바로 시험 빼고 모든 것들이 다 재밌다는 것입니다

그래서 그런지 프로젝트 개발이 평소보다 더 재밌게 느껴지는 것 같습니다

아무튼 이제 곧 시험날이 다가오는데, 다들 좋은 결과가 있기를 바랍니다

[Project : HQRoutine] 6차 스프린트 회고

2023 Series [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 더보기 [2022WinterBootcamp] 0~1주차 회고 개발자가 time-map-installer.tistory.com 본문 이번 주에는 POC 기능에 대한 대부분의 마무리를 진행하는 주인 것 같다. 회고나 블로그를 쓰면서 느끼는 것이 평소에 캡처를 해두는 습관이 중요하다는 것을 깨달은 주인 것 같다 그래서 이번 주에는 많이 사진들을 모아두어서 보는 맛이 있는 그런 글이 되지 않을까 싶다 이제, 시작하도록 하겠다 어디선가 보던 것들을 개발해 내었다는 그 성취감 위에 ..

https://time-map-installer.tistory.com/188

TECST - 개발자 모의 면접 서비스 1차 회고

현재 진행하고 있는 컴퓨터공학과 졸업작품으로 기존 팀이 사정상 해체되어 4월 초 프로젝트 중간부터 참여하게 되었다.

TECST - 개발자 모의 면접 서비스?

문제 풀이 형식으로 기술 면접 준비를 돕는다. 답변을 음성으로 말하고, 말한 내용을 텍스트로 변환해 답변에 틀린 내용이나 어색한 부분을 확인할 수 있다. 마지막으로 Chat GPT를 통해 사용자가 작성한 답변을 분석하고 피드백을 제공한다.

이미 주제가 정해진지 오래이며, 개발이 진행된 상태라 굉장히 걱정이었지만, 이 프로젝트에서 내가 할 수 있는 일을 찾고자 했다.

첫번째, Git-Flow 및 PR 방식 수정이다.

기존에도 기능별로 이슈 발행해 브랜치를 나누어 작업하고 PR을 보내는 방식으로 하곤 있었지만 중심이 되는 브랜치가 main 하나였다는 점, PR시 코드 리뷰나 테스트를 거치지 않은 상태로 Merge하는 등 중간중간 빈틈이 보였다. 그로 인해 몇몇 팀원이 코드가 실행이 되지 않아 테스트도 못한채로 개발에 이어서 하는 등 문제가 많았다. 그래서 여러 프로젝트와 과거 백엔드 개발자 인턴으로 일했던 경험을 바탕으로, 팀원을 불러 모아 Git-Flow 및 PR에 대해 설명을 해주었다. 프로젝트를 처음 해보는 팀원이 대부분이기에 적용해볼 수 있을 만큼 팀 노션에 규칙을 정리하여 프로젝트를 진행하기로 결정했다.

두번째, 코드 리팩토링이다.

기존 레거시에 다 다른 스타일로 짜여진 코드, 클래스 매서드 내에 지나치게 많은 기능이 들어가 있는 등 내가 알고 있는 선에서 보이던 문제점들이 보이기 시작했다. 그래서 보이는 문제를 해결하기로 결심했다.

1) BaseEntity를 통한 공통 필드 관리 및 Entity 리팩토링

공통되는 필드인 id, created_at, updated_at, deleted_at을 묶어서 관리하고자했다. 작업 도중 더 급한 Task가 있어 잠시 중단하게 되었다.

2) Question 도메인 CRUD REST API 개발 및 리팩토링

기능상 서비스에서 '기본으로 제공하는 면접 질문'과 '사용자 개인이 등록한 면접 질문'으로 모의 면접이 가능하다.

기존에 '기본 제공 면접 질문 도메인'과 '개인 등록 면접 질문 도메인'이 따로 존재해, 칼럼이 거의 동일한 DB 테이블이 2개가 생기게 되었고 겹치는 코드 또한, 많이 발생하게 되었다. 이를 해결하고자 유저에 Role을 두고 유저와 질문을 1:N 관계로 관리자가 등록한 질문을 '기본 제공 면접 질문'으로 등록되도록 변경하여 추후에 면접 질문 관리까지 가능하도록 하였다. 그 결과, 도메인을 병합하고 코드 재사용성을 높혔다.

세번째, 기능 및 배포 프로세스 추가이다.

1) ChatGPT API 이용한 사용자 면접 답변 피드백 기능 구현

원래 기존에 팀원이 구현하고 있던 API였지만, Key 관련 오류로 인해 함께 작업하게 되었다. 다행히 문제가 해결되어 구현이 완료된 상태이다.

2) Prometheus와 Grafana를 통한 모니터링 환경 구축

추후 있을 배포를 위해, 모니터링 환경을 구축하게 되었다.

3) Docker 세팅 및 Github Action을 사용한 CI/CD 파이프라인 구축

기존 레거시를 바탕으로 파이프라인을 구축하여 테스트를 진행하였고 각종 세팅과 테스트 때문에 시간이 좀 걸린 거 외엔 큰 문제 없이 배포가 되었다. 추후 학교측으로 AWS 크레딧을 받아 Blue-Green 방식으로 무중단 배포까지 구현하는 게 목표이다.

---

프로젝트를 진행하면서 개발 이외에도 기능적으로 바뀌었으면 하는 부분을 이런 식으로 그림을 그려 설명도 하고

좀 부끄럽다

추후 서비스 확장을 생각해 기능도 재정립하는 등 많은 의견을 던졌던 것 같다. (다 들어주신 팀원들감사합니다 🥲)

프로젝트 중간에 참여가 처음인만큼 고민도 많았다. 예를 들면, 한정된 시간속에 어디까지 리팩토링을 할 것인가? 새로 개발하는 것보다 레거시를 리팩토링하는 게 더 어렵고 오래걸린다고 생각한다. 처음에는 내가 아는 선에서 보이는 문제를 모두 해결할 생각이었지만, 하루 온종일 이 프로젝트만 붙잡고 있을 수 없고 더군다나 프로젝트는 혼자하는 게 아니다. 그래서 지금 당장 바꾸지 않는다면 추후에 더욱 변경이 어려워지는 (ex. Entity) 부분을 위주로 개선하고 구현이 되어야만 어느정도 기능 확장을 생각해볼 수 있는 부분까지를 마지노선이라 생각하고 구현하게 되었다. 앞으로 더 프로젝트를 진행해보며 생각이 정리되지 않을까싶다.

추가로 학회에 논문을 투고하기 위해 열심히 논문을 쓰고 있다. 덕분에 기술적으로 놓쳤던 부분까지 공부하는 중이다. 논문 첫 도전인지라, 난관이 많지만 팀원 도움으로 진전이 되어가고 있다는 점이 굉장히 고맙고 재밌다. 아무쪼록 좋은 결과가 있길 바란다.

23년 1분기 회고 - 많은 변화가 있었던 시기

전에 써놨던 글을 테커 클럽에 올리고 싶어서 이렇게 올립니다 ..!! 😆

3번째 부트캠프

Techeer에서 진행되는 실리콘밸리 부트캠프를 어느덧 세 번째 참여하게 되었다. 첫 번째 부트캠프 때는 모든 것이 다 처음이라 따라가기 바빴었고, 두 번째 부트캠프 때는 그래도 한 번 경험해 본 후라, 아직 많이 부족했지만, 같은 백엔드 개발을 맡은 분들을 리드하고, 어떻게 해야 더 좋은 프로젝트를 완성시킬 수 있을 지에 대한 고민도 할 수 있었다.

세 번째 부트캠프는 학교 졸업작품 개발로 참여하게 되었다. “실리콘밸리 한 달 살기” 프로그램으로 참여가 어렵던 팀원도 있어서 프론트 개발자 1명, 나 포함 백엔드 개발자 2명이 거의 총 3명이 개발을 진행했었다. 다른 팀보다 적은 인원, 그리고 Spring boot를 이용한 프로젝트 개발이라 개발 속도가 느리다고 생각해서 항상 쫓기듯이 개발 해왔지만, 그만큼 프로젝트에 몰두하여 개발할 수 있는 기간이었다.

오히려 좋았다

아무래도 팀원이 적다보니, 커뮤니케이션이 더욱 활발했다. 사소한 것 하나라도 모든 팀원들이 적극적으로 의견을 내며, 어떻게 개발하는 것이 효율적인지 열띤 토론을 나누는 것이 일상이었다. 그 과정에서 어떻게 하면 내 의견을 가감없이 정확히 전달할 수 있는지, 서로 이해하는 것이 다르지 않도록 내용을 정확하게 전달하고 정리하는 방법에 대해 많은 고민을 할 수 있었고, 발전할 수 있었다.

또한, 2명의 백엔드 개발자가 ‘티키타카’가 잘 이뤄졌다. 코드를 작성하다 고민이 생기면 질문하고, 함께 고민하고, 해결하는 순간들이 정말 많았다. 이를 통해 팀원에게도 기술적으로, 기술 외적으로도 많이 배울 수 있는 기회였고, 협업의 즐거움 또한 다시 한 번 알게 되었다.

새로운 도전, 미국에서 한 달 살기

Techeer 실리콘밸리 한 달 살기 7기로 참여하게 되었다. 걱정도 많고, 겁도 많았던 나로서는 주변 사람이 다들 놀랄 만큼 ‘실리콘밸리 한 달 살기’란 정말 큰 결정이었다.

한 달 살기 프로그램 참여자를 모집했을 당시에는 부트캠프도 쉼없이 두 번 연속으로 막 끝낸 상황이라, 내가 이걸 두 번이나 해냈다는 성취감, 그리고 죽을 듯이 하면 나도 할 수 있다는 자신감으로 차 있었다. 이렇게 큰 성장을 이뤄낸 후의 다음 step이 앞으로의 성장을 좌지우지 할 정도로 중요하다는 것을 알았기 떄문에 앞으로의 계획을 고민하던 찰나에 실리콘밸리 한 달 살기가 나에게 기회로 찾아왔다. 앞뒤 생각하지 않고, 나에게 온 그 기회를 잡았다.

사람에게 배우다

오직 화면을 통해 이야기를 나눌 수 있었던 Andrew님과 직접 만나 뵙고 이야기할 수 있었다. 실리콘밸리 개발자까지 오며 겪었던 경험들, 이를 기반으로 평소 하시는 생각들도 들을 수 있었다. 이 기회가 아니었다면, 못 들어봤을 여러 이야기를 들으며, 시야가 넓어졌다. 또, 어떤 걸 개선하고, 성장시켜야 나에게 유리한 지, 아직 많이 부족한 나에게 계속 조언해주셨다. 고민이 많던 시기였는데, 고민을 따로 말씀드리지 않아도 해결책이 되는 이야기들을 툭툭 던져주셨다.

실리콘밸리 한 달 살기는 멤버가 모두 한 집에서 합숙을 하게 된다. 아무래도 한 집에서 같이 살면, 누구보다도 가까이 보고 들으며, 관찰할 수 있다. 함께 7기로 온 멤버들은 정말 각각 다른 면에서 배울 점이 너무나도 많았고, 나는 그 배울 점을 관찰하고 따라하며 내 것으로 만드려고 노력했다.

매 회의마다 커뮤니케이션 스킬을 항상 본 받고 싶었던, 같은 프로젝트를 진행하던 멤버가 있었는데, 직접 옆에서 같이 회의를 진행하며 정말 많이 배웠다. 또한, 멤버 대부분이 부트캠프 팀 리더였고, 한 달 중 첫 1~2주 동안은 부트캠프 기간이라 다양한 형태의 리더십을 보며 좋은 점을 닮으려고 노력했다.

세상은 넓다

그랜드캐년과 요세미티 투어를 통해 다양한 사람과 함께 했다. 이미 성공한 삶을 살고 있거나 성공하기 위해 열심히 달리는 삶을 살고 있는 사람들과 식사도 하고, 대화도 나누며 깨닫게 된 것은 여태 살아 온 내 삶에는 경험이 부족했고, 다양하지 않았다는 것이다. 경험 없이는 앞으로 있을 선택을 잘할 수 없다. 그래서 생각이 많아도 기회가 온다면 놓치지 않으려고 항상 다짐하고 노력 중이다.

정말 넓은 세상을 보며, 내가 살고 있는 한국, 더 들어가 내가 생각하는 사회, 내가 다니고 있는 학교가 정말 정말 작다는 것을 느꼈다. 우물에서 탈출한 줄 알았지만, 아직 우물 안 개구리였던 것 같아 반성하게 되었다.

변화가 오는 시점

미국을 다녀오고 난 후로, 정말 많이 바뀌려고 노력했고, 나 스스로도 많이 바뀌었다는 걸 느꼈다.

리더로서의 나

학교에서 진행되는 졸업작품에서 팀장을 맡아 진행하고 있었지만, 아무래도 대부분 알고 있었던 사람들이라 제대로 된 리더 경험이라고는 생각되지 않았다. 이번에 정말 감사하게도 Techeer 내에서 프로젝트 리더를 할 수 있는 기회가 주어졌다.

팀원으로 참여했던 나를 되돌아보며, 어떤 리더가 필요했었는지 생각해보았다. 아무리 질문과 의견을 적극적으로 내는 것은 본인의 역량이라고도 하지만, 나는 리더의 역량도 있다고 생각했다. 팀원이 자유롭게 이야기할 수 있는 분위기를 리더가 만들어 주어야 한다고 생각했다. 따라서 첫 회의때부터 라이트하게 자기소개를 진행하고, 가벼운 농담도 던지며 최대한 편안한 분위기를 만들고자 했다.

리더는 뻣뻣해도 안되지만, 그렇다고 너무 유해도 안된다. 그 중간 쯤을 지켜야 하는데, 이게 사실 가장 어렵다고 느꼈고, 아직도 고민하고 있는 부분이다. 단호함이 필요하다고 생각될 때는 단호하게 말하려고 했고, 그 외에는 좋은 점을 말하려 하고, 항상 긍정적인 에너지를 내려고 노력했다. 또, 항상 팀원들을 믿고 있다는 것을 보여주려 했다. 아직 진행 중인 프로젝트지만 잘 마쳐서 한 층 더 성장한 리더가 되었으면 하는 바람이다.

개발자로서의 나

책을 많이 읽으려고 노력했다. 부트캠프를 연속 3번이나 참여하며 얻게 된 경험을 더욱 탄탄하게 하기 위해 이론 지식이 필요하다는 것을 절실히 느꼈다. 그래서 낸 결론은 책을 많이 읽는 것이었다.

미국을 갔다온 3월 이후로 한 달 동안 책을 열심히 읽었다. 학교도 다니고, 프로젝트 개발도 진행하다보니 책 읽을 시간을 아무리 쪼개서 내도 부족했지만, 목표치 독서량은 달성하였다.

‘Graphy’ 라는 프로젝트 공유 웹사이트 프로젝트를 진행하며, 최대한 모든 것을 문서화하려고 노력했다. 부트캠프로 진행되었던 프로젝트는 아무래도 시간이 없다보니, 문서화할 시간도 없었고, 따로 개인적으로 개발 블로그를 작성할 시간도 없었다. 이러니 프로젝트를 돌아볼 때 왜 이러한 선택을 했는지, 왜 이때 이런 문제가 발생했는 지 한 번에 떠올릴 수 없었다. 이를 방지하기 위해 팀 노션에 개발 블로그를 작성할 수 있는 페이지를 만들었고, 팀원끼리도 각자 맡은 태스크에 대해 자세히 작성하게 되니, 팀원 모두가 높은 프로젝트 이해도를 가질 수 있었다. 또, 왜 이런 기술을 썼고, 코드를 작성했는 지에 대해 생각하며 작성하다보니 공부하는 데 더욱 도움이 되었다.

현재 동시에 프로젝트 3개를 진행하고 있는 상황에 코테 준비, 그리고 개인 공부까지 이렇게 동시에 여러 개를 진행해 본 적이 거의 없어, 어떻게하면 최대의 효율을 뽑아낼 수 있을지 고민이 많았다.

고민한 결과로는 첫째, 잠은 무조건 6시간 이상 자지 않았다. 전날에 무리했어도 다음 날 잠을 몰아서 자는 일 없이 항상 하루에 사용할 수 있는 시간을 일정하게 유지하려고 노력했다. 둘째, 오로지 내가 하는 일에만 집중하려 했다. 남들이 어떻게 공부하고, 취업 준비를 하는지 듣다보면 나도 괜히 조바심이 생겨 하던 일에 집중하지 못하고 계속 계획을 바꿔가며 오히려 방향성을 잃게 되었다. 내게 주어진 일을 하나씩 해내며 내 속도에 맞춰 나아가려 했다.

앞으로

• 2분기 때에는 조금이라도 늦지 않았을 때 다양한 경험을 할 수 있도록 겁 없이 도전해볼 예정이다. 그 경험을 바탕으로 자신감을 얻어, 성장에 속도를 내보자
• 주변에 같이 공부하는 너무나 멋진 사람들이 많다. 가까이에서 보고 배우며 내 것으로 만들 예정이며, 나도 주변에 이렇게 좋은 자극과 영향을 줄 수 있는 사람이 되는 것이 목표이다.

프로젝트 [Find Spot] 에서 어떤 이슈가 있었나?

여행을 위한 새로운 컨텐츠를 만들어 보고자 시작한 졸업 프로젝트입니다. 어쩌다 보니 졸업 프로젝트지만 대부분 혼자 작업했습니다. 작업 중에 일도 하고, 미국도 갔다오고, 있었던 크고 작은 일이 하나 하나 이슈 같다는 생각도 듭니다.

Find Spot은 미션 사진의 포토스팟을 찾아가서 같은 구도로 촬영한 사진을 이미지 유사도 분석을 통해 인증하는 챌린지 서비스입니다.

오랜기간 야금야금 얇고 길게 개발하면서, 비슷한 케이스에 도움이 되길바라며, 기억에 남는 이슈와 해결 과정을 모아봤습니다.

이슈 4 #리팩토링 #QueryDSL #N+1이슈

⚠️ 데이터베이스에서 Soft Delete 정책을 사용하였기에, 대부분의 쿼리에서 ORM의 순정 쿼리를 사용하기에 문제가 있었다.

⚠️ 3개의 테이블을 join해서 데이터를 가져오는 복잡한 쿼리를 JPQL을 통해 처리하였는데, 유지보수 측면에서 코드 관리에 용이하지 않았다.

해결

• QueryDSL을 도입하여 기존의 쿼리를 유지보수에 용이하도록 리팩토링했다.
• Soft Delete 정책을 사용하게 되면, 삭제 여부를 나타내는 칼럼의 값에 따라 조회 여부가 갈리기 때문에, 모든 조회 ORM을 새로 정의해서 사용해야 했다.
• 특히 쿼리에 힘을 주어 데이터 처리 로직을 가볍게 만드는 방법에 관심이 많았기 때문에, JPQL로 정의된 복잡한 쿼리가 많았다.
• 이러한 쿼리를 관리하기에 QueryDSL이 적합하다는 기술 블로그 글을 보고 채택하게 되었다.
• 추가적으로 QueryDSL의 기능을 사용하면 N+1 이슈를 해결하기도 쉬웠기 때문에 적용해보고 싶었다.

성과

• 기존보다 더 복잡한 쿼리를 편리하게 사용할 수 있어서, 서버에서의 후처리를 대폭 줄일 수 있었다.
• .fetchjoin() 으로 한번에 필요한 데이터를 모두 불러오거나 Projection.constructor 를 통해 쿼리 결과를 DTO에 바로 맵핑하는 방법으로 쉽게 N+1 문제를 해결할 수 있었다.
• 상당 수의 코드를 재사용하여 유지보수가 편리해졌다.

이슈 3 #React #Hook

⚠️ 페이지를 빠르게 새로고침할 때, 일부 리소스가 비어있거나, 중복으로 표시되거나, 표시 위치가 섞이는 문제가 발견되었다.

해결

• setState를 통해 데이터를 저장 직후 state를 사용하던 부분을 직접 대입하는 방식으로 변경했다.
• 원인을 분석하다 각 코드의 동작 방식을 알아보기 시작했다.
• React hook에 대해 알아보다가 setState를 통해 state에 데이터를 저장하는 것이 비동기 적이므로, 순차적으로 실행되는 것이 보장할 수 없다는 것을 알게되었다.

const [mission, setMission] = useState(0);
const getSuccess (id) => {/* ... */};

setMission(1);
getSuccess(mission);

• 해당 부분을 원인으로 판단하고 테스트 해본 결과 원인이 맞았다.

성과

• 앞서 언급했던 페이지의 이상 현상을 해결할 수 있었다.
• React Hook의 동작 방식을 이해하게 되었다.

이슈 2 #리팩토링 #Code-Convention

⚠️ 백엔드를 공부하던 초기부터 개발한 프로젝트였기 때문에, 개발하면서 코딩 스타일과 설계 방법이 달라져서 도메인 마다 코드가 중구난방이 되었다. 따라서 생산성이 점차 떨어지기 시작했다.

해결

• 기능 개발 스프린트를 멈추고, 리팩토링 스프린트를 할당하여 작성 방식을 통일하는 작업을 수행했다.
• 개발 초기에 코드 컨벤션의 중요성을 간과했기에 작성한 코드는 나중에 작업한 코드와 비교하여 코드 작성 규칙이 너무 달랐다.
• 따라서 개발 과정에 다른 도메인의 코드를 다시 분석해야 하는 일이 많았다.
• 앞으로 길게 개발하기 위해 내실을 다질 필요가 있다고 판단했다.

성과

• 리팩토링을 한 이후로 개발이 편해졌다.
• 코드 작성 규칙을 정리하였다.
• 인터페이스 분리, 컨벤션 통일, 설계 통일을 통해 코드 생산 속도가 더 빨라졌다.
• 장기적으로 개발할 것을 생각했을 때 탁월한 판단이었던것 같다.

이슈 1 #설계

⚠️ 스프링부트 메인 서버와 플라스크 AI 서버간에 통신을 어떻게 할지 고민이 있었다.

해결

• 단계적으로 개선하도록 계획했다. 1차적으로 Rest Template으로 요청을 보내고, 이후에 RabbitMQ를 통해 의존성을 낮추는 계획을 했다.
• http, gRPC, MQ 중 고민을 했었다.
• 속도가 빠른 gRPC를 사용하는 것을 고려하였으나, 유사도 분석 과정의 속도가 느리기 때문에 Non-Blocking으로 의존성을 낮추고, 별도의 Scale out이 가능하게 되는 것이 적절하다고 판단했다.
• 그래서 MQ를 통한 의존성 분리를 적용하는 것을 최종 목표로 하고, 시간상 임시로 http 를 사용하기로 했다.

현황

• 현재 http로 요청을 보내게 구현을 해둔 상태로, 다음 개발 기간에 MQ 적용 예정이다.

앞으로 계획

데이터 엔지니어링을 공부하는 입장에서 적용하고 싶은 고도화 플랜이 많은데, 현재 진행중인 프로젝트가 끝난다면 한 부분씩 고도화 해볼 계획입니다. GPT를 활용하여 기존에 갖고있던 데이터에 쉽게 새로운 인사이트를 +@를 해서 예상치 못한 다른 인사이트를 제공할 수 있을것 같아 가장 기대가 됩니다.

[Project : HQRoutine] 5차 스프린트 회고

POC 완성 기한이 20일 정도 남은 오늘, 5차 스프린트도 거의 끝나가고 있습니다

이번 스프린트가 진행 되면서도 많은 배움과 성장, 코드 작성 등이 있었습니다

비도 많이 오고 기온이 낮아지며 컨디션 관리의 중요성이 점점 커지고 있는 요즘입니다.

시작이 좋으면 끝맺음도 좋아야 하듯이 정신을 끝까지 붙잡고 해나가야겠습니다

느린 전진은 있어도 후퇴는 없어야 하니까요!

[Project : HQRoutine] 5차 스프린트 회고

2023 Series [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 더보기 [2022WinterBootcamp] 0~1주차 회고 개발자가 time-map-installer.tistory.com 본문 항상 그랬듯이 쓰다보면 기억 날 이번 주 활동들 그동안 회고를 써오면서 공통적으로 겪었던 경험이 있다 바로 회고를 쓰기 전까지 "내가 뭘 한게 있었나? 일주일 동안 할 수 있는 게 그렇게 많아보이지는 않네?" 라는 생각을 하다가 막상 또 쓰면 아얘 한 건 없는 건 아니고 그런 것 같다 그래서 "아, 나는 생각보다 열심히 살고 있는건가"라는 그런..

https://time-map-installer.tistory.com/185

[Project : HQRoutine] 4차 스프린트 회고

4월이 시작되고 벚꽃도 피고, 드디어 프로젝트의 컴포넌트들도 피어나기 시작했습니다!

이번 회고에서는 스프린트를 진행하면서 개발했던 컴포넌트에 대한 간단한 느낀점을 담았습니다

이제 슬슬 분위기에 휩쓸려서 긴장을 놓는 순간이 다가오고 있는데,

이 점만 주의한다면 좋은 개발자로 거듭날 수 있을 것이라 믿고 있습니다

즐거운 4월을 기대하며 글을 마칩니다

[Project : HQRoutine] 4차 스프린트 회고

2023 Series [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 [2022WinterBootcamp] 0~1주차 회고 개발자가 되기로 time-map-installer.tistory.com 본문 이번 주 동안에는 무엇을 진행했을까? 벌써 4차 스프린트 회고를 쓰는 날이 왔다. 이 말인 즉슨 프로젝트를 시작한 지 1달이 되었다는 소리이다 이번 주에는 무엇을 했을까를 돌아보는 시간을 가지며 생각을 정리해 보았다 달력 만들기, 코딩테스트 조금씩 연습하기, 인적성 검사 보기 등등 쓰다보면 더 많은 것들이 나오지 않을까 싶었다 첫 번째 돌아보기..

https://time-map-installer.tistory.com/183

[Project : HQRoutine] 3차 스프린트 회고

드디어 프로젝트 3차 스프린트가 완료되었습니다

이번 주에는 무언가 한 것이 없는 것 같으면서도 많았던 것 같습니다

프로젝트 개발 시작부터 시작해서, 깃허브 꾸미기를 포함한 여러 활동들 까지..

기록하며 돌아보니 무의미 했던 시간은 아니었던 것 같네요

이래서 기록을 끊임없이 해야하는 건가 싶었습니다

이번 프로젝트는 모든 팀원분들께서 많은 노력과 열정을 쏟고 있는 만큼 저 또한 이에 상응하는 노력과 성과를 낼 수 있기위해 시간을 투자 해야겠습니다

본격적으로 개발에 들어가는 다음주에는 바쁘다고 못했다는 핑계를 대는 저를 만들지 않기 위해 다시 한 번 마인드셋을 점검하고 가는 시기가 되겠습니다

+ 다음 주 부터 디스콰이엇 프로덕트가 올라오고 관련 프로덕트에 함께 태그되며 업데이트될 예정입니다

[Project : HQRoutine] 3차 스프린트 회고

2023 Series [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 [2022WinterBootcamp] 0~1주차 회고 개발자가 되기로 time-map-installer.tistory.com 본문 드디어 사전조사를 마치고 개발에 들어간 3차 스프린트이다 이번 주에는 흥미로운 일들이 있었다 GPT에 대한 간단한 고찰 여러 사전조사를 하고, 페이지 퍼블리싱을 하면서 많은 고난과 역경의 수준을 조금 낮춰 준 도구가 바로 Chat GPT가 아닌가 싶었다 그래서 많은 활용 끝에 어떠한 특이점을 발견하였고, 이를 정리한 탐구 글을 하나 작성했다 [..

https://time-map-installer.tistory.com/180

[Project : HQRoutine] 1~2차 스프린트 회고

모든 것이 새로이 시작되는 3월 입니다

새학기, 새 팀원들, 새 프로젝트 까지...

많은 변화가 일어나고 있는 3월에 시작 한 프로젝트에 관련된 회고를 작성해 나가려고 합니다

이번에는 여러 일정들을 관리해 나가며 일정을 관리하고 공유하는 서비스를 만들게 되었네요

기대하는 만큼 좋은 결과가 나왔으면 좋겠습니다

[Project : HQRoutine] 1~2차 스프린트 회고

2023 Series [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 [2022WinterBootcamp] 0~1주차 회고 개발자가 되기로 time-map-installer.tistory.com 본문 팀이 배정된 이후 주 3회의 회의 일정(월, 목 23시 / 토 21시)을 정하고 2주 동안의 스프린트를 진행해 왔다 혼자 상상하다가 출발했던 아이디어 아이디어는 생각보다 금방 정해졌던 것 같다 그런 말이 있지 않던가, 상상을 글로 적으면 현실이 된다고 아래에 있을 사진에서 볼 수 있듯이 개인 프로젝트용으로 준비 중이었던 아이디어를 여럿이서 더 ..

https://time-map-installer.tistory.com/178

실리콘밸리 한달살기 6기 회고

(2022.12 ~ 2023. 01)

Techeer 실리콘밸리 한달살기 6기로 참여한 이정우입니다. 

저번에는 저희 한 달 살기 6기 일정을 대략 작성해보았고 오늘은 제가 한 달 살기를 통해 어떤 것을 깊이 느꼈는지 공유해보고자 합니다.

시간을 소중히, 실천 경험의 중요성

불과 한 달 만에 이렇게 많은 경험을 할 수 있다는 것을 실제로 제가 겪고 보니 놀라웠습니다. 1년으로 볼 때는 짧다고 느껴진 한 달이라는 시간이 이렇게 소중했다는 것을 깨달았고 하루하루 의미 있게 내 자신을 성장해나가야겠다는 생각을 하였습니다. 

또 크게 느꼈던 점은 실전 경험의 중요성입니다. 더 많은 실전 경험을 위해 현재는 초안 이력서를 완성 후 무작정 인턴 지원 중에 있습니다. 완벽하게 준비되어 있는 사람은 없으며, 가능성 하나를 잡기 위해서는 수없이 많은 도전이 필연적임을 깨달았고 이 도전들 또한 저의 소중한 경험으로 쌓일 것입니다.

기회가 빨리 온다면 더없이 좋겠지만, 아직 오지 않은 그 기회를 놓치지 않기 위해 오늘도 도전을 하고 있습니다.

이들을 따라기만 해도 벅차다

스탠포드 대학교를 돌아다니면서 많은 또래 친구들이 지나가고 여유롭게 앉아서 이야기하는 것을 보면 비슷한 나이에서 세계적으로 유명한 대학교를 다니는 것이 너무 멋있었고 경이로웠습니다. 동시에 내가 과연 이들을 따라갈 수 있을까? 라는 의문을 가지게 되었습니다.

또 구글에 방문했을 때 관계자분이 말씀하시기로, 미국 기업은 원하는 실적과 결과를 내지 않으면 바로 퇴사되기 때문에 퇴사되지 않겠다는 마음으로 항상 열심히 일한다고 합니다. 그 말을 듣고 이미 누가봐도 성공한 기업에서 일하는 사람들도 열심히 살고 있는데 저 또한 현재에 안주하지 않고 열심히 노력해서 그들을 따라가야겠다고 생각이 들었습니다.

자연은 위대하다

다른 세계임을 느낄 수 있었던 장소 중 하나는 그랜드케니언이었습니다. 광활한 대자연을 마주하며 다른 세계로 온 듯한 기분이 들었습니다. 그랜드캐니언과 대평야를 보며 가장 크게 느낀 것은 '인간은 자연에 비해 너무 작다'는 것이었습니다. 이 대자연 앞에 저는 한낱 작은 개미와 같은 존재일 뿐이었습니다.

하지만 작은 개미들도 대자연 속에서 살아남기 위해 협업하며 각종 위협에서 생존하고 진화해 나갑니다. 이를 통해 '글로벌 시대 속의 우리는 어떻게 살아가야 함께 성장하며 나아갈 수 있을까'에 대해 고찰하는 계기가 되었습니다.

매사를 긍정적으로

제가 경험한 또 다른 대자연은 요세미티였습니다. 저희는 폭설로 인하여 1박2일의 요세미티 투어를 하루로 압축하여 진행했습니다. 이때 요세미티 가이드님이 해주신 말씀이 너무 인상적이었습니다.

"마인드를 어떻게 가지냐에 따라 얻어가는 만족감도 다르다. 가령 '날씨가 안 좋아서 요세미티를 하루밖에 못봤네'와 '그래도 하루라도 날씨가 괜찮아서 다행이네'를 두고 비교하였을 때 어떤 생각을 가지는 것이 좋을까?"라는 말이었는데, 하루밖에 오세미티 풍경을 둘러보지 못했지만 눈이 온 직후의 그 풍경은 제 머리속에 평생 기억될 만큼 너무나 아름다웠습니다.

더해, 이튿날에는 와인 테스팅과 박물관 투어로 변경되며 요세미티 풍경뿐만 아니라 더 다양한 장소를 경험할 수 있었습니다.

이를 통해 저는 다시 한번 '오히려 좋아' 같은 긍정의 힘이 얼마나 중요한지 깨닫고, 앞으로 잘 실천해야겠다고 생각했습니다.

나만의 장점을 가진 사람이 되자

요새미티 투어 이튿날, 샌프란시스코의 한 와인 테스팅 바에서 만난 직원분이 있었습니다. 그 분은 저희를 매우 신사적으로 대해주셨는데, 그 젠틀한 말 몇 마디와 행동으로도 사람을 기분 좋게 만들 수 있었습니다. 이것은 그 분께서 가진 고유의 장점이었습니다.

와인 테스팅 바를 나서며 신사적으로 남을 대하는 것은 그 분의 장점이니, 저도 제 자신만의 장점을 찾아 성장해 나가야겠다는 다짐을 하게 되었습니다.

항상 겸손한 자세를 가지자

대자연을 경험하고, 다양한 장소에서 다양한 사람들과 소통하며 저 자신이 겸손해짐을 느낄 수 있었습니다. 제 주변에서는 얼마 되지 않는 것을 자랑해서 자기 자신을 자랑거리 수준으로 낮추고, 한계를 드러내는 것을 많이 보았습니다. 자신이 가진 것 만으로 자신을 설명하고 증명해야 하는 사람이 되는 것은 어리석은 것이었습니다.

가지고 있는 사람들은 자신을 구태여 일부로 드러내지 않았습니다.

타인과 끊임없이 비교하며 남들보다 조금 더 가졌음으로 자만하고, 남들보다 조금 더 못 가졌음으로 자격지심과 패배 의식에 휩싸일 필요가 없었음을 깨달으며 내적인 성장을 하게 되었습니다.

과거의 나는 항상 최선의 선택을 했다

실리콘밸리 한달 살기를 하며 숙소에서는 재밌는 이야기, 진지한 이야기를 6기 동기들과 함께 나누면서 서로 많은 경험과 생각을 공유했습니다. 과거를 회상하며 훨씬 좋은 선택이 있었을텐데 아쉽다는 제 말을 듣고 한 친구가 해준 말이 제 뇌리에 꽂혔습니다.

바로 "과거를 후회하는 것이 아니라 이를 통해 '무언가를 배웠다'라고 생각하자. 좋은 것이든 나쁜 것이든 그 경험들을 통해 지금의 내가 만들어진 것이다." 라는 말입니다. 이를 통해 저는 과거를 둘러보는 시간도 중요하지만, 과거를 후회할 시간에 과거의 경험을 토대로 앞으로의 저 자신을 더 발전시켜야겠다는 마음가짐을 얻었습니다.

마무리하며

이 한 달 살기를 통해서 저는 더 넓은 세상을 볼 수 있었으며 다양한 기업, 다양한 장소를 방문한 경험 하나하나가 저의 피와 살이 되는 좋은 경험이었습니다. 무엇보다 이 소중한 경험을 같은 목표를 가지는 열정적인 친구들과 함께했던 것이 너무 좋았습니다.

이런 기회가 없었다면 저는 미국 땅을 밟아보겠다는 생각 자체도 하지 못했을 것이고, 우물 안의 개구리처럼 좁은 시야를 가진 채 평생 살아갔을 것입니다.

한 달 동안 사용한 천 만원이 아깝냐고 물어본다면, 저는 자신 있게 그 이상도 낼 수 있다고 말할 수 있을 것입니다. 매우 뛰어난 엔지니어들이 모인 실리콘밸리를 방문한 것 만으로도 저는 이미 천 만원 이상의 가치를 했다고 생각합니다. 더군다나 방학 기간에 다녀와서 제일 유익하고 알차게 방학을 보낸 것 같습니다.

이런 좋은 경험을 함께 한 너무 멋있고 소중한 우리 6기 친구들과 부족한 저희들을 항상 이끌어주시고 쓴 소리도 마다하지 않는 우리의 아버지 @Andrew Park 님께 항상 감사드립니다.

sv 6기

@이정우 @고원준 @김유림 @박희경 @정길연 @최세연 @박수현 @오현택

[Good Night Hackathon]

Techeer 내에서 약 30시간 동안 진행했던 해커톤입니다

처음 하는 체계적인 백엔드 미니 프로젝트였기에 초심자인 저에게는 굉장히 어렵게 느껴졌습니다

하지만 어렵다고 눈과 귀를 닫아버린다면 얻어가는 것이 없이 시간만 소모할 것 같아 보이고 들렸던 모든 것에서 배울 점을 찾아 적어두었습니다

정리까지 해 두고 다른 활동을 하다가 돌아보면 이를 이해 할 날이 오지 않을까요?

단기간 집중형 Spring Boot Hackathon에 대한 회고를 작성 해보았습니다

[Good Night Hackathon] SpringBoot! 맛 좀 보자!

2023 Serieses [ 2023 ] CheckPoint, 2023년 2023년동안 작성했던 회고록들을 모아 둔 게시글이다 2023년 동안 작성한 회고들을 계속해서 업데이트 해 나갈 예정이다 [ January ] - 변화의 시작, 1월 [2022WinterBootcamp] 0~1주차 회고 개발자가 되기로 time-map-installer.tistory.com [Good Night Hackathon] (2023/02/25/22:00 ~ 2023/02/27/02:50) 규모 : 약 50명 요약 : 팀 단위 Spring Boot API 과제 해결 프로그램, 팀원과 함께하지만 개인이 코드를 작성해야하며, 제출도 각자 하는 해커톤 당신이 알고있는 모든 사람들에게 Good Night를 외칠 수 있는 해커톤! 오..

https://time-map-installer.tistory.com/175

실리콘밸리 한달살기 6기 요약

(2022.12 ~ 2023. 01)

Techeer 실리콘밸리 한달살기 6기로 참여한 이정우입니다. 

개발자들의 성지, 혁신의 진원지라고 불리는 실리콘밸리에서 한 달 동안의 소중한 경험을 하면서 메모장에 적어본 것을 공유해보자 간단하게 요약해보았습니다.

한달 일정동안 경험한 일이 많았고, 이 과정에서 깨달은 부분도 많아서 두 가지 주제로 나누어서 기록할 예정입니다. 오늘은 제가 어떻게 한달살기를 신청하게 되었고 미국에서 어떤 일정이 있었는지 설명해보고자 합니다.

[한달살기를 신청하게 된 계기]

앤드류님이 미팅에서 항상 해주신 말씀입니다.

"루프 탑 같은 높은곳에서도 식사해보고, 실리콘밸리도 와보면서 다른 세계가 있다는 것을 느껴라."

이 말씀을 듣고 저는 바로 실리콘밸리 한달살기를 결정했습니다. 그리고 설레는 마음으로 실리콘밸리의 모습을 경험하고 느끼기 위해 6기 친구들과 함께 미국으로 떠났습니다.

[샌프란 시스코에서]

저희 숙소는 미국에서 제일 행복한 도시로 선정된 '써니 베일'에 있었습니다. 안전한 도시라 자주 산책하였는데 다들 너무 평화롭게 시간을 보내는 모습이 매우 인상적이었습니다. 우리나라에서는 볼 수 없는 여유가 느껴졌습니다. 

그리고 미국에서의 첫 크리스마스를 친구들과 보내었고 앤드류님 집에서 바베큐 파티와 신년 파티도 같이 보내면서 많은 이야기를 들었습니다.

실제로 한 사람 한 사람 보면서 말씀하시다보니 비대면으로 이야기를 듣는 거보다 몇배는 더 유익했습니다. 

또 앤드류님과 등산도 했었는데 등산을 하면서 마주친 사람들이 반갑게 인사해주는 것을 보니 사람의 따뜻한 정이 느껴졌습니다.

이 주에 구글 본사, 구글 신사옥을 방문하였는데 항상 말로만 들었던 세계적인 대기업에 방문하고 보고나니 내가 이런 데를 진짜 방문했다는 게 믿기지 않았습니다. 소위 말하는 성공한 사람들의 모습이 너무 멋있기만 했고 미래에 성장한 모습으로 다시 한번 방문하고 싶어졌습니다.

세계에서 유명한 학교 중 하나인 스탠포드 대학도 방문하였는데 우리 나이와 비슷한 또래 친구들이 이런 대학을 다니면서 생활을 하는 것을 보고 내가 이들을 따라가려고만 해도 몇 배 이상의 노력을 해야겠다고 깨달았습니다. 지금에 안주해있지 말고 앞으로 꾸준히 나아갈 것입니다.

추가로 피어 39, 골든 게이트 브릿지, 페리 빌딩 등 샌프란시스코에서 무조건 가야 된다는 관광명소는 다 둘러보고 왔으며 미국의 3대 국립공원 중 하나인 요세미티 국립공원도 다녀왔습니다. 여름의 요세미티와 겨울의 요세미티가 또 다르다고 하는데 저희는 눈 온 직후에 가다 보니 눈이 많이 쌓여 더 예뻤던 것 같습니다.

<스탠포드 대학교>

<구글 신사옥>

[라스베이거스에서]

저희는 운 좋게 CES을 참관할 수 있는 자격을 얻게 되어서 라스베이거스로 출발하였습니다. 세계적으로 유명한 행사답게 매우 컸고 규모는 호텔 몇 대를 빌려 여는 곳이다 보니 이틀을 다녀왔는데도 전부 자세하게는 둘러볼 수 없었습니다. 그래도 각 나라와 유명한 기업들이 한 곳에 다 모인 자리였고 이 세계적인 박람회에 참가하고 볼 수 있었다는 것이 엄청나게 의미있는 경험이었던 것 같습니다.

특히 LG가 엄청 인상 깊었는데 엄청 많은 커브드 디스플레이를 전시하여 벽면에 전시해놓은 것을 보고 가슴이 웅장해졌습니다. 그리고 이를 구경하기 위해서 다양한 사람들이 온 것을 보고 우리나라가 세계적으로 영향력이 있다는 것을 깨달았습니다.

저도 이렇게 영향력이 있는 사람이 되어서 우리나라를 자랑하고 싶다는 생각이 들었습니다.

CES 일정 이후 저희는 그랜드캐니언을 1박 2일 다녀왔습니다. 브라이스 캐니언부터 엔탈롭 캐니언까지 6대 협곡을 다 구경하였는데 사진을 많이 찍었어도 사진에 다 들어가지 않은 대자연이었습니다. 

<CES>

<브라이스 캐니언>

[LA에서]

LA는 짧게 2박 3일로 다녀왔는데 큰 일정으로는 유니버셜 스튜디오와 할리우드 사인을 방문하였습니다. 유니버셜 스튜디오를 찾아보았을 때는 호불호가 많이 있었는데 개인적으로 저는 단순히 스릴만 요구하는 우리나라의 놀이기구와는 달리 심슨, 해리포터 등 많이 즐겨보던 영화나 애니메이션에서 스토리를 풀어내 놀이기구로 만들어놓다보니 우리나라에서는 느낄 수 없었던 감동이 있었습니다.

다른 친구들도 같은 의견이었고 저희는 그 하루를 알차게 보냈던 것 같습니다. 할리우드 사인 또한 인상적이었는데 항상 사진이나 영상으로 보던 것을 실제로 보고 오니 느낌이 새로웠습니다. 지금은 내가 이걸 실제로 봤다 정도라면 나중에는 내가 이 곳을 방문했다라는 느낌을 새겨주고 싶습니다.

<산타모니카>

<유니버셜 스튜디오>

이 모든 일이 불과 한 달 사이에 겪었던 일들이고, 심지어 후반 3주는 부트캠프도 병행하면서 하였습니다. 5,6시간정도밖에 자지 않고 정신없고 돌아다녔지만 그만큼 많이 보고 체험했던 것 같습니다 ㅎㅎ

다음에는 한달 살기를 통해 제가 어떤 것을 깊이 느꼈는지 정리해서 올려보도록 하겠습니다.

sv 6기

@이정우 @고원준 @김유림 @박희경 @정길연 @최세연 @박수현 @오현택