harry

카드게임 커뮤니티 개발기

h0ng.jh — Wed, 22 Feb 2023 01:21:20 +0900

개요

당시에 취미로 하던 게임의 관련 정보들을 알아보기위해 커뮤니티 사이트들을 좀 둘러보다 한국 커뮤니티 사이트가 없는걸 알게됐다.

물론 이미 만들어진 해외 사이트를 유용하게 사용할 수 있었지만 광고가 너무 많고, 사이트 속도가 너무 느려서 이용하기가 불편했다.

이런점들과 과거에 했던 게임관련 웹프로젝트가 여러 커뮤니티에서 자생적으로 홍보되어 피드백이나, 의견들을 들을 수 있던것이 생각나 내가 한번 개발해볼까 라는 마음으로 진행해보기로 했다.

❓ 뭘 개발했나

먼저 사이트내에서 다루는 가장 큰 주제인 마블스냅이라는 카드게임에서는 16장의 각기 다른 카드를 하나의 덱(카드뭉치)으로 구성해 경쟁하여 승부하는 게임이다.

쉽게 비유하자면 16마리의 포켓몬들을 카드의 형태로 이용해 싸우는 게임이라고 이해하면 될것같다.

이러한 카드 게임의 특징으로는 어떤 16장의 카드를 조합 하느냐에 따라 전략의 다양성을 늘리는데

경쟁이 이루어지는 만큼 어떤 덱(조합)이 가장 효과적인지, 가장 효과적인덱을 어떻게 대항하는지가 눈치싸움처럼 이루어진다.

그렇기 때문에 짧게는 며칠내에 가장 강한덱이 바뀌고 이런 동향들을 지속적으로 체크해야 조금이라도 더 유리한점이 카드게임의 특징이다.

이러한 덱의 중요성 때문에 자신의 덱을 쉽게 공유할 수 있도록 덱코드라는 일정한 문자열을 입력하면 다른사람의 덱을 복사해올 수 있는 기능도 게임내에 마련되어있다.

하지만 공유하려는 사람이 덱을 공유할때 덱코드를 공유하는것이 아니라 스크린샷을 찍어 올리는것이 더 편하기 때문에 대부분의 유저들은 이런 방법을 자주 사용했고

이용하는 입장에서 덱코드를 입력하는것이 아닌 스크린샷을 보고 16장을 일일히 추가해 만들어야한다는 불편함이 있었다.

그렇기 때문에 사이트의 컨텐츠에서 자동으로 덱코드를 generate하고 버튼을 클릭하면 바로 복사해 올 수 있는 기능을 만들어 덱을 좀 더 편리하게 공유 할 수있도록 하는 기능을 만들었다.

두번째로는 덱의 구성에 대한 부분인데 아무리 좋은 카드의 구성이라해도 내가 갖지못한 카드가 포함되어있다면 쓸모없는 정보에 가까웠다.

게임내에서 카드를 갖는 과정은 특정 레벨에 도달하거나, 랜덤으로 얻어지는 방식인데 이 부분을 게임내에서 확인하기가 굉장히 어려웠다.

이러한점을 해결하기위해 사용자의 데이터를 받아 내 카드 보유 현황을 한눈에 확인하는 기능은 개발을 완료했고, 그로 만들수 있는 덱들을 필터링하는 기능을 만들고 있는 중이다.

이 과정에서 사용자의 데이터를 받기 위한 방법들중 여러가지 방법들을 생각해봤는데 electron 기반의 간단한 데스크탑 애플리케이션을 만들어

로그파일을 읽어 계정과 연동하는 기능도 같이 만들어 제공했다.

electron은 사실 전혀 해보질 않아 생각보다 시간이 많이 소요됐었는데, 그래도 있으면 너무 좋은 기능일것같아 github에 올라와있는 오픈소스들을 참고해가며 만들었었다.

프로젝트 설계

백엔드는 기존에 사용했던 express로 진행하려 했지만 개발 관련 유튜브를 보다 아래 영상을 발견했다.

Pocket Base 에 관해 설명하는 영상인데, 간단히 말해 Go를 기반으로 만든 Sqlite를 이용한 백엔드 플랫폼이다.

데이터베이스를 어드민으로 관리할 수도 있고 테이블의 형태에 따라 API도 자동생성해 주기 때문에 꽤 편리해보여 이용해봤다.

프론트엔드는 Next.js를 이용했는데 pocketbase에서 생성된 API나 코드를 Next의 Serverless function에서 call하는 방식으로 설계했다.

그 이유는 아무래도 pocketbase를 이용하는 코드가 워낙 기존의 fetch, axios와는 이질적인 구조였고 pocketbase를 이용하는 부분을 컴포넌트 구조에서

분리하여 유지보수가 용이하도록 위함이었다.

요약해보자면 Serverless function에서 pocketbase를 이용하게두고 SSR과 CSR에서 이용되는 데이터 fetching 작업은

serverless function에 해당하는 각각의 엔드포인트를 호출하도록 했다.

컴포넌트 폴더 구조는 회사에서 다뤘던 프로젝트나 기존에 진행했던 프로젝트를 atomic 패턴으로 나눴었는데

Molecules과 Organism의 구분이 컴포넌트 작성마다 고민되는 순간들이 굉장히 많았었다.

또한 Atom과 Molecules도 이걸 "가장작은 단위로 봐야하나?" 라는 생각과 "두개 이상의 atom들이 합쳐져 만든 컴포넌트" 인데 이후에 변경되어 Organism으로

옮겨지는등의 수정사항이 생긴다면 전체적인 구조가 흐트러지는 경우가 있었기 때문에 내 나름대로 기준을 다시 잡아 진행해봤다.

물론 회사에서 다루던 코드에 비해서 작은 규모의 프로젝트였다는 점도 폴더 구조 설계에 큰 영향을 끼쳤다

내가 잡은 기준을 짧게 설명해보자면 다음과 같았다.

@atoms : 기초적인 UI 구성의 단위
- atoms 는 기존의 atomic 패턴에서의 atoms와 같은 역할
@molecules : atomic들의 집합이라면 무조건 여기에 해당
- 사실상 기존의 Molecules과 Organism에 해당 하는 컴포넌트들을 모두 합쳐 관리하기로 했다.
@template : Page 단계 이전의 가장 상단에 위치하는 구조로, Page에서 이용되는 레이아웃을 제외하고는 가장 크게 구별되는 단위
@page : 하나의 페이지, next의 pages 디렉토리에 위치한다

상태관리는 기존에 redux를 이용했었는데 이번에는 recoil과 react-query를 이용하여 Server State와 Client State 나눠 관리하는 방식을 이용했다.

기존 프로젝트에서 상태관리를 할때 Client State와 비동기 처리 로직에 관한 코드의 관리를 고민을 했었을 당시 접했던 세미나가 생각나서 였다.

결과적으로 이 부분도 굉장히 만족했는데 우선 react-query를 이용하는 hook들을 따로 useCardList(), usePostList() 처럼 @query 폴더에 나누어 비동기 처리 로직을r 관리 할 수 있었으며, 처리 로직에 관한 코드도 간결하게 작성 할 수 있었다. (캐싱도 때에따라 효과적으로 이용할 수 있었다.)

recoil은 Server State와 분리된 Client내에서 이용하는 State들만을 관리할 수 있었다는점이 같이 이용하면서 느꼈던 장점이라고 생각된다.

어떤 과정을 거쳤나

백엔드에 필요한 데이터들은 이미 존재하던 커뮤니티나 공식 사이트에서 puppteer 이용해 기초 데이터를 수집했고 워낙 pocketbase에서 지원해주는것들이 많아

데이터베이스 관련해서는 수고를 좀 덜 수 있었지만... 아쉬웠던 점도 있었다. (아래 아쉬웠던점에 후술)

이미지의 경우, 빌드시간을 최대한 단축시키고 싶었고 퍼포먼스 최적화를 위해 저장해 놓은 이미지의 사이즈를 보여지는 UI에 따라 동적으로 관리하고 싶었다.

이를 위해 웹 퍼포먼스 최적화에서 배운 imgix로 이미지 리소스들을 관리하는 방법을 사용해봤는데 확실히 light house에서 감점당하는 요인들을 효과적으로 줄일 수 있었다.

프론트엔드는 최근에 아이패드를 샀기 때문에(?) 반응형도 지원을 하는 방향으로 개발했다.

이 과정에서 페이지마다 이용되는 레이아웃을 몇개정도 피그마나 아이패드에 그려보면서 최대한 css의 미디어 쿼리만으로 바뀔 수 있도록 설계, 구현했다.

next를 이용하는 이유가 검색엔진에 더 잘 노출되도록 하고 싶은것이 가장 큰 이유 였기 때문에 적절한 메타태그와 seo를 배치했다.

그리고 서비스 특성상 특정 기간동안에는 카드의 효과나 스펙이 변하지 않기 때문에 해당 페이지의 cache-control을 알맞게 수정했고

hydration 관련 퍼포먼스 이슈를 최대한 열심히 디버깅해가며 초기 로딩속도를 최대한 빠르게할 수 있도록 했다.

앞서 말했던 덱들을 보여주는 페이지에서는 시효성이 있는 데이터들이기 때문에 무한스크롤로 구현해 첫페이지 진입시 가장 최신의 데이터를 확인 할 수 있도록했다.

여기서 덱에 관한 자세한 정보를 보여주기위해 디테일 페이지로 진입하는 경우 뒤로가기를 했을때 마지막으로 본 지점으로 돌아가야하는 점과 소요시간을 줄이는데 시간을 굉장히 많이 쏟았다.

이점은 언뜻봐서는 사소해 보일 수도 있겠지만 이용자의 UX가 굉장히 저해되고, 사이트를 이탈하는 원인이 될 수 있기 때문에 반드시 해결해야하는 문제였기 때문이다.

처음 생각했던 방식은 디테일 페이지로 이동되기전에 sessionStorage에 스크롤 지점을 저장하고, 뒤로가기로 리스트 페이지에 진입했을때 저장된 지점으로 이동하는 것이었는데

이 방법은 디테일 페이지로 이동하고, 뒤로가기가 아닌 다른 페이지(home)으로 이동했다가 리스트로 진입한다면 스크롤이 복원된다는 문제점이 있었다.

그렇기에 여러가지 방법들을 시도해보며 찾은것이 인스타그램이나 트위터에서 주로 이용하는 Route as Modal이었다.

이를 통해 스크롤 관련 이슈를 깔끔하게 해결 할 수 있었고, shallow routing을 때에따라 이용하며 SEO가 보장된 페이지를 제공 할 수 있었다.

아쉬웠던점

pocketbase에서는 relation 설계가 mysql과는 다른점이나 n-gram search을 못쓰기 때문에 검색하는데도 좀 아쉬웠고 쿼리튜닝을 할려면 Go를 알아야하는데...

내가 보유한 카드의 현황에 따라 덱 리스트를 보여주기 위해서는 쿼리튜닝을 해야할것 같아 좀 알아봐야할것 같다.

이번 프로젝트에서는 번들사이즈를 최대한 낮추기 위해 디자인 라이브러리를 이용하지 않고 진행해봤는데

생각보다 습관적으로 사용하는 css코드들의 중복이 너무 많아 이 부분은 좀 아쉬웠던 점이기에 다음번에는 자주 중복되는 부분들을 토대로 미리 작성해놔야겠다는 생각도 들었다.

그리고 아무래도 현재 사이트내의 컨텐츠를 채우는 과정이 내가 따로 시간을 내서 덱관련 정보들을 수집하고 admin을 통해 등록을 일일히 해야하기 때문에 좀 번거로운데

OpenCV를 통해 스크린샷을 캡처하고 어떤 카드를 의미하는지 알아낼수있다면 주기적으로 컨텐츠를 채워넣을 수 있을거같은데 이 부분이 자동화가 안되어있는 상태라

어떻게 할지 좀 생각해봐야할것같다.

그동안은 자바스크립트로만 프로젝트를 진행했었는데 이번 프로젝트부터 타입스크립트를 사용해보니 확실히 어이없는 실수들이 많이 줄어들었다.

하지만 타입가드나 유틸리티 타입을 좀 능숙하게 사용하진 못하고 있는거 같아 리팩토링을 몇번 거쳐야될것같다.

후기

이번 프로젝트에서는 직장을 나와 공부하는동안 습득한 퍼포먼스 최적화 부분이 좀 유효하게 적용된것 같았다.

퍼포먼스 패널을 보며 했던 최저고하 작업은 가시적인 지표를 확인해가며 점차 나아지는 모습이 내가 하면서도 정말 신기했고 재밌었다.

Link

https://snapsco.net/
https://github.com/jihunhong/marvelsnap-client

로컬라이징 (지역화) 구글 스프레드 시트로 자동화하기

h0ng.jh — Sun, 24 Oct 2021 00:04:23 +0900

로컬라이징 (지역화) 구글 스프레드 시트로 자동화하기

개요

로컬라이징(이하 "지역화")에 드는 소요는 작업의 복잡도와는 별개로 상당히 번거롭고, 소통이 어려운 부분이라 느껴 이글을 작성하게 됐습니다.

다른 프로젝트 혹은 후에 있을 개발상에 비용과 시간을 단축시키기위해 더 나은방법이 있을지 고민해본 점에 관한 글입니다.

개념적으로도 그리 복잡하지 않은 방법이고 구현도 그렇게 어렵지 않기에 프론트엔드 개발자가 아니시더라도 번역과정을 이해하기위해 한번씩 읽어보셨으면 좋겠습니다.

그동안 사용했던 일반적인 방법

현재 진행하고있는 프로젝트에서 이루어지는 지역화는

useTranslate()라는 hook(함수)에 한글 텍스트를 넣어 사용자의 언어 설정에 따라 번역된 텍스트를 리턴하는 함수를 사용합니다.

위의 과정에서 필수적으로 필요한 요소들은 입력받는 텍스트와 매칭되는 각 언어별 텍스트 인데,

이것을 각각의 json (혹은 js에서의 object) 에서 불러오는 방식을 이용하고 있습니다.

en.json

{
    "원본 텍스트" : "번역될 텍스트",
    "커뮤니티" : "Communiy",
    "스토어" : "Store"
}

위의 예시처럼 en.json(영어), jp.json(일본어) 등등이 존재해야 하기 때문에 각각의 json 객체를 생성하는데

(번역해야할 텍스트 * 지원해야할 언어의 갯수) 회 반복해서 Copy-Paste 해야하는 상당한 시간이 들었었습니다.

또한 자동완성의 지원을 받을 수도 없어 실수가 나올 수도 있다는 점이 개발시간을 늘어지게 했습니다.

( 키값을 변수화 시켜 한곳에 저장시키고 변수를 import 받는 방식을 이용했지만 다른 문제점도 있어 이 글에서는 다루지 않겠습니다. )

구상

위에서 언급한 각각의 언어를 담고있는 json을 만들기 위해 제가 참고했던것은 구글 스프레드 시트였는데

이전에 데이터 테이블을 excel로 저장하는 기능을 만들어 봤었던게 기억나

스프레드 시트로부터 한글 문구를 추출해 영, 일, 중 의 json을 만드는건 어렵지 않겠다 싶어 해당 방법을 이용해보기로 했습니다.

준비

먼저 이용중인 스프레드시트에 접근할 수 있는 bot을 만들기 위해 클라우드 콘솔에 접속해야 합니다.

Google Cloud Platform

프로젝트를 생성한뒤 사이드바의 API 및 서비스를 클릭하면 아래와 같은 화면이 나오는데

사용자 인증 정보 만들기에서 서비스 계정을 만드시면 됩니다.

또한 해당 봇의 계정정보를 API 이용시마다 인증받아야 하기 때문에

생성한 서비스 계정의 디테일에 들어가 키추가 - 새 키 만들기 로 저장된 json 파일을 보관해놓도록 합시다.

이후 스프레드시트에서 해당 서비스 계정을 추가하시면 API 이용시 해당 봇으로 접근해 데이터를 가져오는 방식입니다.

spreadsheet-sync.js

const fs = require('fs');
const path = require('path');
const { GoogleSpreadsheet } = require('google-spreadsheet');
const creds = require(서비스 계정 인증정보 json);

const doc = new GoogleSpreadsheet(스프레드 시트의 아이디값);

(async () => {
  await doc.useServiceAccountAuth(creds);
  await doc.loadInfo();
  const sheet = doc.sheetsByTitle[이용할 시트의 이름];
  // 참조할 시트의 제목 ( sheetsByIndex 등으로도 가능합니다 )
  const rows = await sheet.getRows();
  console.log(rows);
  const en = {};
  const jp = {};
  const cn = {};
  const tw = {};
  for (const row of rows) {
    en[row['한']] = row['영'];
        // 선택한 시트의 컬럼 이름을 이용
    jp[row['한']] = row['일'];
    cn[row['한']] = row['중(간)'];
    tw[row['한']] = row['중(번)'];
  }
  // fs.writeFileSync('../en.json', JSON.stringify(en, null, 4));
})();

위의 샘플 예제를 참고해 모듈을 작성을 완료하셨으면

이후 배포가 이루어지는 빌드 스크립트에 해당 스크립트를 먼저 실행 시킨후 빌드 스크립트를 실행시키면 완성입니다.

develop 할점

빌드가 이루어질때마다 해당 json을 생성하기 때문에 하루에도 몇번씩 해당 스크립트가 실행될겁니다.
- 이를 방지 하기위해 dev 버전에서 테스트할때 한번 실행시킨 후, 테스트 버전으로 push, merge 할때는 .gitignore 파일을 조정하여 테스트 버전에서는 실행되지 않도록, release 시점에서 다시 한번만 실행시켜도 될듯하네여
번역될 텍스트가 없을 경우 for문을 아래처럼 optional chainning 으로 파파고 API 혹은 구글 API 로 번역 텍스트를 가져올 수 있도록 하면 될듯 하네여 (이 경우에는 한번 더 검증하기위해 로깅이 필요하겠네요)

for (const row of rows) {
    en[row['한']] = row['영'] || fetchFromPapago(row['한'], 'en');
        // 선택한 시트의 컬럼 이름을 이용
    jp[row['한']] = row['일'] || fetchFromPapago(row['한'], 'jp');
    cn[row['한']] = row['중(간)'] || fetchFromPapago(row['한'], 'cn');
    tw[row['한']] = row['중(번)'] || fetchFromPapago(row['한'], 'tw');
  }

다시 취업을 했다.

h0ng.jh — Thu, 12 Mar 2020 23:36:44 +0900

2019년 후기를 적고 이틀후인 2020년 1월7일에 원티드를 통해 한 스타트업의 채용공고를 접하게 되어

2020년 2월3일 부터 첫 사회생활을 시작하게 되었다.

사실 면접을 봤을때만 해도 대답을 잘못한것 같아서 별 기대를 안했는데 블로그나 깃허브를 좋게 봤다고 하셨다.

작년에 참가했던 부스트 캠프에서

기본적인 지식을 쌓았고, 남는 기간동안 Express 와 React를 이용해 작은 프로젝트를 하나 했었는데

조금씩 관리해왔던 github 와 프로젝트를 좋게 봐주셨던것 같다.

직군은 JS 를 다루는 주니어 웹개발자로 취업하게 되었고,

현재 회사에서는 백엔드와 프론트를 모두 조금씩 경험해보고 있는 중이다.

사실 이 글을 쓰게 된 이유는..

한달정도 회사를 다니면서 생각해보니 19년 후기에 적었던 것들을 대부분 못지키고 있었다.

취업 후 4주간 주말이나, 퇴근후에 아무것도 하지않고 누워만 있는 시간이 너무 많다고 생각해서

다시 마음을 잡아보고자 블로그에 글을 써봤다.

취업 이전에는 그래도 매일 프로젝트나, 따로 공부를 해보면서 개발자가 되기 위해 노력했었는데,

취업을 하고나니 거기에 만족해 자기 발전을 등한시한 것 같았다.

앞으로는 개인 프로젝트 외에도 회사에서 한것들도 따로 정리 해놓는것이 좋겠다. 예전처럼. 허허

2019년 후기

h0ng.jh — Sun, 5 Jan 2020 17:01:00 +0900

✒️ 개요

자주 눈여겨보는 velog나 페이스북, 블로그들에서 본 2019년 회고를 접하고 나도 써보려고 한다.

8월 이후로는 블로그에 글을 전혀 쓰질 않아서 후기를 쓰며 뒤숭숭한 현재 마음가짐을 다잡고 싶은 마음이 있기도 하고

19년을 돌이켜보면 이제껏 살아온 해 중 가장 다사다난하고 행복한 날 우울한 날도 많은 해였던 것 같다.

독학사부터 취업, 퇴사

상반기를 돌이켜보면 독학사에 합격하고 2월 에 학위수여를 받았다.

독학사 후기에서도 언급했었지만 합격했을 때만 해도

내 노력으로 무언가를 이뤘다는 것이 참 뿌듯했었고, 자신감에 차있던 시기였다.

시험을 준비하고 합격발표를 통지받은 기간 동안 진행했었던 프로젝트에서도 생각했던 것보다

많은 격려와 피드백들을 들을 수 있어서

조금은 편안한 마음가짐으로 취업준비 활동에 매진했던 것 같다.

그렇게 3월과 4월 을 보내며 처음으로 지원한 회사에 운 좋게도 한번에 합격할 수 있었다.

실제로 배포와 서비스를 해본 프로젝트가 있었다는 것에 많은 점수를 받을 수 있었지 않았나 싶다.

하지만 취업을 하고 나서 이수하는 신입사원 교육과정에서 느낀점 들이

바로 취업한 것이 너무 섣부른 결정은 아니었는지 같은 생각들을 들게했다.

결국 고민 끝에 교육과정이 한 달 남은 시점에서 퇴사를 결정하게 했고 7월 부터 부스트 캠프 2019 에 참여했다.

⏲ 부스트 캠프

부스트 캠프에 참여하게 된 계기는 취업한 회사가 마음에 안 들어서도 있었지만

지속 가능한 개발자를 목표를 한다는 점이 내 마음을 움직여서 였다.

이렇게 참여한 부스트 캠프에서는 정말로 많은것들을 경험할수 있는 기회였다.

이 얘기는 후기에서 다뤘으니 생략하고 그 이후에 대해 돌이켜보자면

8월 9일 프로젝트 시연까지 마치고 나서 남긴 후기가

페이스북의 초보 개발 모임에 노출돼서 감사한 마음으로

멤버십 과정에 참여하기 위한 합격발표를 기다렸었지만 아쉽게도 선정되지 못해버렸다.

부스트 캠프 활동이 막바지에 다다르며 기간 동안 수행했던 미션들을 잘 수행하지 못했었기 때문에

막연하게 멤버십에 선정되지 못할것이란걸 어렴풋이 알고는 있었다.

하지만 그때의 심정을 솔직하게 말해보자면 상실감이 대단히 컸었다.

막상 현실로 돌아와 그런 상황들을 맞닥뜨리다 보니 이제 어떡하나? 라는 생각과 함께

취업준비를 다시 해보자고 마음을 잡아보면서도 한숨만 나오는 상황이었다.

☀️ 하반기부터 현재까지

그나마 위안이 됐었던 것은 퇴사했던 신입사원 교육 부터 지속해오던 일일커밋 이었다.

그래프에 보이는 모든 칸을 꽉 채우면 일일커밋 후기를 적어봐야겠다

일일커밋 은 이전의 신입사원 교육에 참여했을 때 평일에는 스터디 시간에 github를 이용했었고 주말에만 따로 시간을 내서 공부하면 일일커밋을 지속할 수 있었기 때문에 그때부터 시작했었다.

퇴사를 결정하고 부스트 캠프를 마칠 때까지도 지속하고 있었는데

상실감을 잊기 위해 부스트캠프에서 배운 자바스크립트를 이용한 프로젝트를 진행해보면서 아쉬운 마음을 달래보려 했었다.

부족한 실력 탓에 기획했던 모습에는 아직도 많이 모자란 상태지만

그렇게 하반기를 맞이하며 상반기의 취업준비를 하던 것과 마찬가지로

몇개의 기업에 서류를 넣어봤으나 안타깝게도 기회를 잡지 못했다.

신입임에도 불구하고 첫 취업을 너무 운좋게 해버렸던 탓일까?

요즘은 너무 만만하게 생각한 것은 아닌지 하는 생각이 든다.

일일커밋을 지속해오며 나름대로 노력하고 있다고는 생각했는데,

커밋수에 비해서 진행했었던 프로젝트의 완성도가 따라주지 못한다는 생각이 들었다.

2020년에는 지속하고 있는 일일커밋 이외에도 좀 더 주도적인 노력을 해보려고 한다.

TIL

첫 번째로는 TIL(Today I Learned)을 한동안 적다가 말았는데 올해부터는 이걸 좀 더 해볼 생각이다.

TIL을 적으며 정리해오던 것에 비해서 공부했었던 것들을 다시 검색하는 경우가 잦았기 때문이다.

또한 github.io 도메인으로 만든 블로그를 티스토리 블로그와는 별개로 TIL이나 가벼운 내용을 포스팅하는

아카이브로 사용하려고 했었는데 이것도 잘 안 지켜졌다.

이점도 TIL과 더불어 신경 써야겠다.

강의

두 번째로는 참고할 자료를 글 이외에 다른 매체에서도 찾아보려고 한다.

MERN 스택에 관해 찾아보다가 우연히 해외 유튜버가 올린 영상들을 봤는데

영어임에도 실제로 작성되는 코드와 영어 자막을 함께 활용하니 생각보다 도움이 많이 되는것 같았다.

프로젝트

세 번째로는 즉흥적? 계획 없이 진행되던 프로젝트를 좀 더 계획적으로 하고 싶다.

커밋한 횟수에 비해서 프로젝트의 완성도가 따라주지 못한 것은 기한이나 제약사항이 없었기 때문에 너무 늘어진 것 같다.

소감

이 외에도 많은 일들이 있었지만 회고의 성격을 담은 글에 너무 많은 내용이 들어가는 것 같아

다른 내용은 많이 생략했습니다.

새해를 맞아 기분전환겸 회고를 써봤는데 글 내용이 중구난방이네요

너그러운 마음으로 가볍게 읽어주셨으면 좋겠습니다

부스트 캠프 2019 참여 후기

h0ng.jh — Fri, 9 Aug 2019 22:46:51 +0900

✒️ 개요

지난달 19.07.15 부터 커넥트 재단에서 담당하는 부스트 캠프에 참여했고

4주간의 챌린지 과정을 거쳐 지난주 금요일 수료식을 마쳤다.

사실 주마다 했던 회고 외에도 일기를 썼었는데 부스트 캠프에서의 활동이 즐거웠던 탓인지

수료식을 마치고도 아쉽다는 생각이 많이 나서 좋은 추억으로 남기기 위해 후기를 적어보려고 한다.

❓ 계기

올해 초? 상반기에는 독학사를 통해 학사학위를 받고 취업을 했다.

이후 이전에 쓰던 블로그에서 취업을 했다라는 글을 남기며

4월 22일부터 8월 21일까지 진행되는 신입사원 교육에 참여하고 있었다.

신입 사원 교육에 참여하면서 느낀 바로는 내가 생각하던 곳과는 많이 다른 회사였다는걸 느꼈다.

솔직히 말하면 재미없었다.

사회생활을 처음 시작하는 처지에서 이런 소릴 하는 게 건방지다고 생각할 분들도 있을 것 같다.

하지만 정말 재미없었다 여러모로.

납득이 안되는 점도 너무 많아 너무 성급하게 이 회사를 선택한 건 아닌지 후회스럽기도 했다.

이런 생각을 하던 와중에 우연히 접하게 된 부스트 캠프 는 내 궁금증을 유발했고

'재밌겠다' 라는 생각으로 지원한 것이 합격까지 이어졌다.

부스트 캠프 선발 과정은 지원서 -> 온라인 코딩테스트 -> 오프라인 코딩 테스트 순 이었는데

오프라인 코딩테스트가 10일 수요일에 치러졌는데 합격을 통보 받은것은 11일 목요일이었다.

각각의 과정들의 일 처리가 굉장히 빨라서 감탄했던 기억이 난다.

최종합격 통보는 11일 목요일 신입사원 교육 스터디 시간에 받았다.

내가 합격할지 정말 몰랐다. 합격 통보를 받고 집에와서 그날밤 내내 밤을 새워 고민했다.

취업을 하고 교육이 한 달 남은 시점에서 여태까지 해온 것들을 포기하고 새로운 도전을 해보는 것 과
그냥 없던 일로 치고 회사에 다니는 것

금요일까지 입과 신청서를 제출하고 회사에 통보해야 됐기에 이날 밤은 잠을 한숨도 못 자며 고민했었다.

최종적으로 부스트 캠프를 가기로 결정했고 계기는 간단했다.

재밌을 것 같았다. 또 자유로울 것 같았다. 수업이나 강의가 아닌 지속 가능한 개발자를 목표로 한다는 문구에 마음이 움직여서 였다.

느낀점

부스트 캠프 는 대표적으로 3개의 활동으로 진행됐다.

오전 동안 진행되는 피어세션 오후 동안 진행되는 미션 금요일마다 진행되는 릴레이 프로젝트

첫 주차에 처음으로 느낀 점은 오길 잘했다는것 이었다.

구성된 교육 프로그램들의 일정들이나 내용이 빈틈없이 준비 돼 있는 상태였다.

두 번째로 좋은 동료분들이 많이 모였다고 생각했다.

내가 대학생이었던 시절과 비교해서 아니 현재와 비교해도 뛰어나신 분들이 정말 많아서 도움을 많이 받았다.

왜 최고의 동료들과 함께한다는 건지 그 의미를 알 수 있었다.

부스트 캠프를 가기로 결정하고 다짐했던 것이 있었다.

부스트캠프에서는 동료와의 협업, 커뮤니케이션이 강조되는 문구가 많았다.

멤버십에 가기 위해? 도 있었지만 나 자신을 바꾸고 싶었다.

내향적인 성격이나 소극적인 태도를 이번 기회를 통해서 바꾸고 싶었다.

이 생각으로 첫날부터 옆사람이나 같은조 분들과 재밌는 분위기로 협업하려고 노력했다.

개발자들끼리만 모였으니 케미도 더 잘맞는것 같았다 ㅎㅎ

조가 바뀔 때마다 다른 건 몰라도 재밌었다고 말씀해주신 게 너무 감사했다.

걱정했던 만큼 티가 나진 않았나 보다 다행이었다 :)

⏲ 미션

미션 은 최소한의 배경지식이 키워드로 제공되며 CS 지식과 웹 프로그래밍의 기초를

다시 한 번 공부해보며 해결해보는 시간이었다.

내가 느낀 바로는 제한시간 이 걸려있다는 점이 상당히 어려웠다.

4주차부터는 매일 9시까지 남아서 했음에도 불구하고 해결하지 못한 미션들이 많았다.

팀원들이나 같이 참여하는 동료들과 대화를 하며 알고리즘 을 꾸준히 공부해오신 분들이 많다는 걸 알았는데

꾸준히 하신 분들은 대부분 미션에서도 뛰어난 모습을 보였다.

4주차부터는 하루하루 마다 기초 CS 지식과 알고리즘이 얼마나 부족했는지 다시 한 번 깨닫게 해주었다

피어세션

피어세션 은 IT기업들이 왜 코드리뷰를 하는지 알 수 있었던 시간이었다.

피어세션때 코드를 보여주면서 하다보니 변수명이나 함수명 코드의 가독성에도 이전보다 많이 신경쓰게 되고 남의 코드를 읽는것도 느는 느낌이었다.

또 같은 문제를 다른 방식으로 푸는 것을 보면서 어떤 것이 더 나은가에 관해 토론하거나

이 부분은 이렇게 하는 것이 좋구나를 스스로 느낄 수 있고 다음 미션때 적용해보면서 굉장히 많은 도움이 되었다.

릴레이 프로젝트

릴레이 프로젝트에서 기억나는 점은

첫주에 시작했던 기획이 다들 처음 해보는 방식이라 분위기도 조심스러웠던 것 같다.

조별과제 1주차가 생각났다ㅎㅎ

"생각나는 걸 전부 말해보자"로 시작해 각자 아이디어를 말해보면서 무사히 마칠 수 있었다.

마스터님이 재밌게 하는것을 강조해주셔서 이날 만큼은 편안한 분위기로 재밌게 할 수 있었다 :)

또다른 기억에 남는 주는 3주차 활동 이었다.

같은 팀이 되어본 적이 있는 분들이 많이 모이게 돼서 다른때보다 더 재밌게 했다.

실제 프로젝트에서는 디자인 프레임워크를 써보려는 시도가 있었지만 실패했었다.

기존 코드에 관한 이해가 떨어졌었고, 평소에 프로젝트 하던 방식과 비슷하게 하려다 보니 시간이 너무 부족했다.

돌이켜 생각해보면 너무 만만하게 생각했던 것도 있었다.

다음 주에 그 프로젝트를 담당하게 될 팀원분들에게 너무 미안해서 주말 동안 완성시켰었는데

코드리뷰와는 색다른 느낌이었다. 주말에 연락하기가 실례일것 같아

작성했던 코드를 보며 동작 원리를 이해해보거나 유추해봤는데 이 과정도 나름 재밌었다.

코드를 읽어보고 의마하는 바가 뭔지를 맞춰보는 것도 색다른 경험이었던 것 같다.

소감

챌린지에서는 JS 에 관한 중요 개념을 익히고 개발자로 살며 필요한 컴퓨터 기초지식을 구현해보는 시간을 보냈다.

이 과정을 진행하면서 이 세상에 잘하는 사람이 얼마나 많은지를 뼈저리게 느꼈다.

또한 협업이 얼마나 중요한 의미를 갖는지, 동료들이 얼마나 중요한지도 충분히 체감할 수 있었다.

4주간 참가했던 부스트 캠프 모든 과정의 시작은 처음부터 내 인생 최대의 고민으로 거쳐 시작했었다.

모든 과정을 마치고 수료식까지 마친 지금 내가 느꼈던 지난날들은 4주라고 하기엔 너무나도 짧게 느껴질 만큼 즐거운 추억으로 남게 되었다.

개발자로서의 성장도 4주라고 하기엔 너무나도 많은 것들을 접한것 같다.

기초적인 것들만 알고 있던 4주전의 내가 node.js로 프로젝트를 진행해보려는 생각을 하고 있으니 말이다.

이 글을 마치게 되는 12시가 지난 19.08.13에는 멤버쉽 과정에 참여하게 될 인원이 발표된다.

꼭 좋은 결과가 있었으면 좋겠다 :)

음원차트 파싱 프로젝트

h0ng.jh — Mon, 22 Jul 2019 11:32:24 +0900

github

음원차트 파싱 프로젝트

Preview

✒️ 개요

기존의 음원 플랫폼은 지니를 사용하다가

유튜브 레드의 오프라인 저장 기능을 사용해보고 싶어서

3개월 체험권을 받아 이번달 부터 이용해보다가 불편한점이 생겼다.

기존의 음원 플랫폼들에서는 음원 차트가 있어서

신곡이 나오면 들어보고 추가하는게 쉬웠는데

유튜브 레드의 차트는 변동이 심하지 않고 기존곡들 위주로 나오기 때문에

음원 사이트에서 차트를 보고 노래를 추가하는게 너무 번거로웠다.

그래서 지난 프로젝트에서 맛보기로 사용해봤던 JSOUP를 이용해

대표적인 음원사이트들의 차트 정보를 파싱해와서

유튜브 링크를 달아주는 사이트를 개발해보고자 주말동안 프로젝트를 진행해봤다.

프로젝트 설계

과거에 진행했었던 프로젝트에서 배운것들과

교육기간동안 배운것들을 합쳐 프로젝트를 진행해봤는데

음원사이트 파싱은 Jsoup를 이용해 차트에 존재하는 필요한 DOM을 가져와서

ArrayList<음악 정보>의 형태로 리스트 객체로 만들어서 View에 전달해주는 방식으로 설계했다.

처음에는 익숙한 HashMap으로 HashMap<제목, 가수이름>의 형태로 테스트 코드를 만들었었는데

Thymeleaf에서 HashMap 사용법이 잘 기억 안나기도 했고 ( 주말동안 성과를 내고 싶었다. )

제목:가수이름 (key:value) 의 형태로 만들기에는 HashMap 구조를 사용하는 목적과 맞지 않는다는 점과

제목, 가수 이름 외에도 나중에 추가될 Field들에 대한

리팩토링이 어려워 질것이라고 생각해서 ArrayList로 만들었다.

Weekend Commit Preview

19.05.19 첫째 주

생각난 아이디어를 해커톤처럼 빠르게 프로젝트로 진행해본게 이번이 두번째다.

첫번째는 작년 8월 일주일간 진행했었는데

확실히 실력적으로 많이 성장했던것이 느껴졌었다.

과거에 해왔었던 프로젝트에서 쓴 코드가 많은 것도 있지만

교육기간 동안 배운 내용이 중간중간 생각나서 코드를 고치기도 했었고
( generic을 사용한게 익숙해진 느낌? )

지난번 프로젝트들보다 설계에 대한 생각이 빠르게 이루어져서 수월하게 했다.

이번에는 기초 설계를 해보며 테스트 코드를 작성해봤는데

"이래서 테스트 코드를 쓰는거구나" 하는 생각도 조금은? 느낄 수 있었다

19.05.26 둘째 주

두번째 주는 유튜브 검색 모듈을 서비스단에 따로 만들어 보았다.

강의내용에서 강조했던 3-Layer의 분리를 진행해 봤는데

View단에서 요청을 통해 유튜브 모듈을 이용할지 아니면

컨트롤러단에서 부터 파싱할때 해당 정보를 한번에 검색해서 넣어줄지가 고민이다.

금요일에 Jenkin를 통한 CI를 배웠는데 tomcat을 실습 예제로 사용해서

Nginx 예제를 보며 따라해볼 생각이었으나 시간이 너무 없어 이번주에는 진행하질 못했다.

ul list 태그로 테이블을 만드는게 처음이어서 그런가 정렬에 생각보다 시간이 많이걸렸다.

19.06.02 셋째 주

이번주도 역시 평가 과제와 팀별 스터디 떄문에 시간이 너무 없어서

Modal Ajax 구현 외에는 별다른곳에 손댄곳이 없었다.

차트 데이트를 받아 유튜브에 검색하는 버튼을 modal과 연결시켜 사용했으나

검색 결과 데이터를 불러오는 Ajax보다 먼저 실행되어서 데이터 호출 Ajax와

Modal 표시 스크립트에 관한 조정이 필요할것 같다.

원래는 Modal 내부에 플레이리스트 추가 버튼을 만들 계획이었는데

차트에서 바로 추가가 가능하도록 해야겠다.

19.06.09 넷째 주

 팀별 스터디 자료 준비 때문에 시간이 없어서 진행하지 못했다.

19.06.16 다섯번째 주

스프링부트 시큐리티 + OAuth2 구현을 위해 [처음 배우는 스프링부트2](http://www.hanbit.co.kr/store/books/look.php?p_code=B4458049183) 를 참고해

스프링 부트의 1.5버전에서 OAuth2를 구현한 후 2.0버전 으로 리팩토링하는 실습을 진행해봤다. [Repository](https://github.com/jihunhong/Google_OAuth2.0_Example)

Spring Secuity에 관한 내용과 Filter에 관한 내용정리가 필요해보이고

OAuth2 로그인을 통해 플레이리스트 추가 기능을 구현하려고 했다.

19.06.23 여섯번째 주 구글 OAuth2.0을 이용한 사용자의 계정에 존재하는 유튜브 플레이리스트를 받아오는 기능을 작성해봤다

처음에는 지난주에 구현한 스프링부트 시큐리티 + OAuth2 를 이용한 부분에서 받아올 수 있을거라고 생각해서

많이 해맸는데 GoogleAuthorizationCodeFlow 객체를 통해 구현 할 수 있었다.

현재 로컬에서는 작동 되지만 redirect되는 도메인 설정시 아이피가 아닌 도메인을 입력해야되서

플레이리스트를 조작하는 기능은 후순위로 매겼다.

19.06.30 일곱번째 주 강의에서 프론트에 대한 부분을 많이 배우기도 했고

몰랐던 부분을 많이 알게되면서 다른 사이트에서 보고 적용해보고 싶었던 

패턴들을 많이 적용해보면서 프론트적인 부분을 많이 고쳤다.

bootstrap에 grid를 완전히 이해한것같아 반응형 디자인에 관한 부분도 구현했는데

하고나니 다시 욕심이 생겨 사이트 디자인을 한번 갈아 엎었다.

아쉬웠던점

19.05.19 첫째 주 처음 프로젝트를 설계했을때 생각했던 기능을 못넣은게 많아서 아쉬운점도 있다.

대표적으로는 각각의 차트 항목의 정보를 받아 해당하는 유튜브 영상을

링크해서 추가할 수 있게 하려고 했었는데

금요일 퇴근후 부터 현재까지 너무 달려서 지쳐버렸다.  

네이버 클라우드 플랫폼 (NCP)를 뉴스 기사에서 보고

도메인 구입과 NCP에 업로드까지 하려고 했는데 다음주나 시간되면 진행해야 겠다.

또한 일정이 촉박하다는 생각이 자꾸 들어서

View단의 리소스를 구하는데 시간을 많이 들이지 못해

프로젝트 View단의 퀄리티가 만족할만큼 나오지 않아서 조금 아쉬웠다.

19.05.26 둘째 주

이번주는 본격적인 스프링 진도에 나가면서 `TIL` 포스팅도 조금씩 미뤄지고

프로젝트도 만족할 만큼 진도를 못나갔다.

호기롭게 시작한 토이 프로젝트였었는데 배운 내용을 토대로 설계 해보자니

생각이 많아져서 시간이 오래걸린 것 같다.

다음주 부터는 이슈탭을 적극적으로 이용해 봐야겠다.

19.06.02 셋째 주

이틀동안 할당된 API 할당량을 전부 사용해버려서 할당량 추가 신청 폼을 작성했다.

API 요청 할당량에 관한 생각은 못하고 테스트 코드를 작성해버려서

너무 많은 데이터를 호출하는 것으로 코딩하다 보니

한번 테스트 코드를 실행할때마다 약 150번의 호출이 이루어져버렸다.

스터디를 진행하면서 이번에 단위테스트와 Mock에 관한 내용을 읽었는데 이부분을 중점적으로

테스트코드를 리팩토링 해봐야겠다.

19.06.09 넷째 주

 팀별 스터디 자료 준비 때문에 시간이 없어서 진행하지 못했다.

19.06.16 다섯번째 주

 OAuth2를 구현해보며 Security에 관한 상세 내용이나

 OAuth2 dependency에 관한 내용, OAuth2를 테스트하기 위한 테스트 작성에 대해

 TIL에 정리해보며 업로드할 생각이다.

19.06.23 여섯번째 주

OAuth2.0 API 호출시 리다이렉션 되는 URL을 도메인 네임으로 정해야되서

본격적인 구현이 밀려 버렸다.

AWS 에서는 같은 플랫폼안에 도메인 등록부터 관리 까지 붙어있어서 연동하기가 쉬웠는데

NCP 에서는 도메인 등록은 지원하질 않아서 쪼오금 아쉬웠다.

19.06.30 일곱번째 주

배운 내용을 가지고 HTML CSS 코드를 많이 건드렸는데

바뀐 뷰에 따라 보여줄 데이터가 좀 추가되서 관련 메서드를 작성하는데

시간이 없어 너무 대충 작성했다.

컨트롤러 단에서 급하게 붙인 코드나 정렬 알고리즘 구현에 사용된 메서드가

테스트 과정을 거치지 않아서 조금 불안정한게 고쳐야할 점이었다.

사용해본것들

Spring Boot
Thymeleaf
YouTube Data API
JSOUP
Mp3agic
MDB

네오플 오픈 API를 이용한 프로젝트

h0ng.jh — Mon, 22 Jul 2019 11:31:59 +0900

github

✒️ 개요

먼저 프로젝트 주제를 정하게 된 과정을 적어보자면,

내가 처음 Spring으로 진행했던 프로젝트는 블로그 였는데

글쓰는 것에 대한 막연한 동경이 있다는 점도 있었지만,

[개발자가 블로그를 운영해야 할 이유] 를 감명깊게 봐서였다.

하지만 블로그 특성상 시스템적인 부분외에는 참고할 피드백이나, 의견을 얻기가 어려웠기 때문에

다음 프로젝트에서는 서비스를 만들어 보고 싶다는 생각을 가지고있었다.

그러던 와중 그 당시에 하던 게임에서 오픈 API를 제공 한다는 소식을 접했고
"게임중에 느꼈던 불편한 점들을 해결해준다면 이게 서비스가 아닐까?"라는 생각에 시작하게 됐다.

❓ 뭘 개발했나?

힘 +100 짜리 무기가 있다고 치자, 이 무기의 능력치를 더해주는 시스템을 마법부여라고 한다.

마법부여를 하기 위해서는 카드가 필요한데 예시를 한번 살펴보자.

+15 만큼의 성능을 내는 1500만원의 카드 A가 있다.
+10 만큼의 성능을 내는 50만원의 카드 B가 있다.

데미지가 산출 되는 단위가 % 연산으로 계산되어 억에서 조단위까지 차이나기 때문에

초보자의 입장에서는 +5만큼의 성능을 위해 A를 골라 1450만원을 더 투자하기란 쉽지 않은 이야기다.

결국, 합리적인 소비를 위해 각 아이템의 가격을 보며 가치를 따져보기 위해서는

엄청나게 많은 상품의 가격을 일일히 검색해보며 비교해봐야 하는 문제점이 존재했고,

같은 옵션이라도 장비의 종류, 옵션의 수치에 따라 각각 다른 카드가 필요하다

이 점을 해결하기위해 부위별 해당하는 모든 옵션들과 수치들을 담고있는 테이블을 만들어,

사용자의 선택을 통해 선택된 특정 부위에 특정 옵션을 가진

무기 > 힘 : 무기에 힘을 + 해주는 카드들을 보여준다.

카드들을 보여주고 현재 경매장에 올라와있는 가격을 확인 할 수 있는 기능을 만들었다.

어떤 과정을 거쳤나.

처음 기능에 대한 아이디어를 떠올렸을때는 정리되지 않은 아이디어를

어떻게 구현할까에 대한 고민들을 많이했다.

블로그는 단순히 분류하자면 글쓰기, 글목록 표시, 글 내용 부분정도만 들어갔었지만,

이번 프로젝트에서는 사용자의 선택지를 전달받아 또다른 선택지를 띄워주고, 결과를 반환하는 기능 뿐만아니라

커뮤니티를 위한 게시판, 게임과 관련된 콘텐츠도 직접 제작해보며 시간을 보냈다.

마법부여 기능의 선택지를 받아야하는데

생각보다 적당한 방식이 떠오르지 않아 네이버 검색탭을 보고

<ul>태그와 <li>태그를 통해 선택지를 나열하고 현재 선택된 요소에

border-bottom으로 색깔을 표시해주는것으로 구현해봤다.

실시간 가격의 경우 네오플 오픈 API에서 제공해준 경매장 API를 통해 해결했다.

아이템ID나 아이템 이름을 파라미터에 붙여주면 최저가, 평균가도 한번에 제공 받을수 있어

이부분은 크게 무리없이 구현했다.

문제는 아이템 파라미터였는데, 처음에는 경매장 API에 접근하기 위해서는 아이템 이름만으로

해당 아이템의 최저가와, 평균가를 얻을수 있을것이라고 생각했었기 때문에

아이템 테이블에는 이름만 존재했었다.

문제는 비슷한 이름의 아이템이 존재하기 때문에 경매장에 'ABCD'라는 아이템의 매물이 없을 경우

비슷한 이름인 'ABCE'라는 다른 아이템의 가격이 검색되어 표시되는것이었다.

이 때문에 결국 아이템ID를 포함해 테이블을 새로 만들어야 하나 했지만,

다행히도 이름으로 ID를 검색해내는 API도 제공해줘서 관련 메서드를 하나 더 작성하고 손쉽게 테이블을 수정할 수 있었다

앞서 말했다시피 DB 설계를 주의깊게 하지 않은 탓에, 다른 문제점들이 많았다.

데이터를 추가하는 순서는 무기 - 상의 - 하의 - ... 메뉴 순으로 추가를 했는데,

앞 순서에 속한 카드들은 옵션이 두개라서 컬럼을 두개만 배정해서

아이템 이름	첫번째 옵션	두번째 옵션	첫번째 옵션 값	두번째 옵션 값
`해리 카드`	`힘`	`속도`	`+15`	`3%`

이런식으로 만들었다.

문제는 마지막 순서인 귀걸이에서 나왔는데 아이템 옵션이 4개라서 몹시 당황 했던 기억이 있다.

지금 생각해보면 기획이나 설계에 관한 시간을 안보내서 벌어진 일이었는데

이 후 진행할 프로젝트에서 얼마나 중요할지 체감하는 순간이었다.

마침 이 프로젝트를 진행할때가 산업기사와 병행하며 공부했을때였는데,

정규화에 대한 이론적인 공부와 함께

이 프로젝트의 DB를 정규화 해보면서 정규화에 대해 더 깊은 이해가 생긴것 같아 아직도 많이 기억에 남는다.
(많은 단계를 거치진 않았지만 )

얻게 된것

블로그를 진행했을때와는 확실히 달랐다. 피드백의 속도나 질적인 측면에서 유저들이 남겨준 코멘트들을 받을 수 있다는것이 상당히 새로웠다.
로컬에서 RUN해보고 거기서 끝났던 것과는 다르게 이번에는 AWS의 몇몇 서비스들을 이용해봤다. ROUTE53에서 도메인을 구매해 EC2 서버에서 실행시키기도 해봤기 때문에 좀더 본격적(?)으로 진행한 기분이라 웹 개발자가 되어보는 간접적인 경험을 한것 같다.

아쉬웠던 점

지금 생각해보면 기능 구현이나 UI에 집착하면서 시간을 너무 많이 소모했었다.

그 당시에는 알지 못했던 로그 관리나 서버관리, 코드 작성을 어떻게 해야할지 같은 점들이 아쉬웠지만

공부를 해보며 아 이때는 이런걸 쓰는게 좋았겠구나!라는 생각이 떠오르게 하는점도 있어

아쉽지만 훗날있을 일들을 위해 좋은 경험이었다고 생각한다.

마치며

DUNPIC.NET 게임에 관한 주제이다 보니 항상 게임내 정보들을 머리에 담고 있어야했고

개발자로서의 고민보다 게임내 컨텐츠를 제공하는 포스팅을 위해 더 많은 시간을 쓰는

내 모습을 보면서 현재는 개발자로서의 역량을 쌓기 위해 더이상의 업데이트는 하고있지 않다.

또한 AWS 프리티어도 끝나고 도메인도 만료되며 게임에 대한 흥미도 잃어버렸기 때문에

서버 운영도 더이상은 하고있지 않은 상태이다.

처음 프로젝트 시작했을때가 떠오른다.

게임 커뮤니티에 사이트를 소개하는 글을 적을때부터

많은 분들이 댓글로 좋은 반응을 남겨주거나, 쪽지로 편하게 할수있어서 너무 좋다는 의견을 접하면서

그 마음에 보답하고자 더 사이트내 요소들에 대해 고민하는 시간들을 보내던 와중

게임 사이트 메인에도 소개 링크가 개제되어어 그날 방문자가 7천명을 기록하기도 했었다.

프로젝트를 시작할때 기대했던것보다 더 큰호응을 받게되어서 너무 좋은 경험을 한것 같다 :)

독학사 후기

h0ng.jh — Mon, 22 Jul 2019 11:23:57 +0900

독학사 시험 결과가 합격으로 나와 지난번 썼던 독학사 후기를 다시 읽어보는데

내용이 마음에 안들어 합격후기로 다시 써보려고 한다.

먼저, 독학사 후기를 적게된 이유는 독학사 준비 기간동안

6개의 과목을 공부했는데 힘들때마다 합격후기를 읽으며 마음을 다시 잡을수 있게 해주던

선배님들처럼 나도 후기를 적어보고싶었다.

사실 합격발표전에는

독학사를 준비하는 분들께 조금이라도 도움을 주고 싶다는 마음이 있었지만

결과확신을 나도 못하던때라 조심스러운 마음에 정보에 대한 내용보다는 후기에 가까운 글을 썼었다.

다행히 바로 어제인 11월 26일 합격 소식을 확인했고, 이전 글 보다는 덜 부담스러운 마음가짐으로 글을 써보려고 한다.

❓ '독학사'에 대해

혹시 독학사에 대해 모르는 분들이 있을수 있기에 설명해보자면

독학학위제는 독학자에게 학사 학위 취득의 기회를 부여하기 위해 국가가 시험에 합격한 사람에게 학사 학위를 수여하는 제도이다. - 위키백과

한마디로 4년제 학사학위를 딸수있는 국가 검정 시험이다.

고등학교 졸업학력을 규정하는 국가 검정 시험인 검정고시와 비슷하다.

독학사 시험은 1년에 4단계의 시험이 있고 각 단계를 모두 통과해야

학사 학위를 취득하게 된다.

내 경우에는 3년제 전문대를 졸업했기때문에 3단계 까지의 시험이 면제되고

4단계만 통과하면 학사학위를 얻을수 있는것.

4단계 시험은 총 6과목으로 구성되는데

나는 교양과목인 국어 영어 2개를 선택했고

전공과목은 컴퓨터시스템구조 네트워크 자료구조 운영체제 4개로 모든사람이 동일하다.

시험준비에 어려웠던점

독학사 시험을 준비하며 가장 힘들었던 점은 지난 시험에 나왔던 기출문제가 없다는 점이었다.

문제은행 방식이 아니기 때문에 개념에 대한 기본적인 이해를 필수로 다소 지엽적이라고 할 수 있는 문제들이 시험에 나올수 있다는 것이다.

그렇기 때문에 지엽적인 문제의 내용이 처음보는 내용인 경우도 있어 만점을 맞기에는 상당히 어려운 시험이었다.

특히 문제 출제의 범위와 예시문제를 통해 공부해야될 내용을 판단하는점이 어려웠다.

처음에는 이 문제로 걱정을 많이 했었지만 시험을 치른 입장에서는 합격에는 아무 문제 없다는 생각이다.

합격 불합격은 6과목의 총점이 360점 즉 평균 60점만 넘기면 되기 때문인데

느낀바로는 iMBC 교재의 기본적인 개념이나 iMBC 모의고사 문제 분석 만으로도 각 과목당 60점은 충분하다.

✏️ 어떤식으로 공부했는지

내가 공부 했던 경험으로 말해보자면

프로젝트와 산업기사 시험을 치르고 본격적인 독학사 공부는 9월부터 시작했다.

(졸업 후 독학사 시험을 치기위해 틈틈히 공부한것들을 제외하고)

9월부터 시험일인 10월 28일까지의 기간동안 준비를 한셈인데

인강같은 것들은 전혀 수강하지 않았다.

iMBC기준으로 4단계 강의료만해도 90만원인데

집안사정이 90만원이나 쓰기에는 여유롭지가 않아서

지금생각하면 무슨 자신감인지 모르겠지만 모든 과목을 독학으로 공부했다.

교재는 iMBC 컴퓨터 과학과 4단계 책 6권을 파이널 모의고사 문제까지 포함해 모두 구매했다.

시험 공부를 시작할때 대략적인 계획을 9월동안 6권 모두 학습하고, 10월 14일까지 모든 문제 풀이

28일까지 총복습으로 지금보면 좀 무식하게 세웠었다.

계획을 세울때부터 모든 일정이 밀리면 안되고, 그날 그날 할당량을 모두 소화하기 위해

하루마다 공부량을 체크해서 페이지와 남은 퍼센트를 다이어리에 기록했는데 이 방법이 그래도 꽤 효과적이었다.

가끔 일기도 적었다

모든 내용을 끝내기에 한달이란 시간은 사실 부족하기도 했지만

그날그날의 할당량은 무조건 소화한다는 마음으로 공부에 임했고 실제로 90퍼센트는 지켰다.

2달간의 시험 준비를 정리해보면 이렇다.

6과목 전부 노트에 쓰면서 공부 -> 문제 풀이 -> 오답 전부 다시 쓰기, 총정리

버릴건 버리자

공부할때마다 평가원의 출제방향, 출제 범위를 고려해 벗어나는 내용들은 모두 배제하면서 공부했다.

예를들면 국어의 높임말, 고어같은 내용들은 외운 내용들이 문제로 안나올 가능성이 있다고 생각했다.

평가원에서 시험출제시 iMBC책의 내용만을 참조해서 출제하는것이 아니기 때문이었다.

또한, 독학사 시험에서는 출제 문항수가 정확히 정해져있다.

과연 위에서 말한 국어의 높임말, 고어 같은 내용들이 다른 단원들과 같은 문항수로 나올까?

심지어 평가원에서 제공하는 12문제들 중 1문제도 없곸 보기에도 안나온다.

시조나 가사 내용들도 주요내용이나 특징들을 밑에서 같이 짧막하게 정리만 하고 넘어갔다.

✔️️️ 고대가요 - 공무도하가 - 죽음의 이미지, 공후인, 여성의 목소리

평가원 예시 문제를 완벽히 숙지하자

시험을 치른 입장에서 생각해보면 평가원에서 나온 문제들이 똑같이 출제된 문제들이 몇개 있었다.

심지어 주관식 문제도 똑같이 나온게 있었는데 변형된 방식이 이랬다.

평가원 문제가 이런식이라면

전송 메시지 M(X)=X^3+X+1 와 생성 다항식 G(X)=X+1 로부터 나머지 R(X)와 실제 전송될 부호화된 메시지 F(X)를 구하면? (객관식)

시험에서는 이렇게 나왔다.

M(X)=X^3+x+1 와 G(X)=X+1 로부터 나머지 R(X)를 구하고 부호화된 메시지 F(X)를 풀이과정과 함께 구해라.

풀이과정이 추가된 것처럼 "평가원 문제에서 출제한 주요 개념을 확실히 이해하고있는가?" 의 방향으로 생각해 공부하면 될것같다.

주관식

주관식 문제들은 각 시험마다 4문제씩 10점 총 40점을 차지하기 때문에 굉장히 중요하다.

앞서 얘기한것 처럼 기출문제가 없기 때문에 주관식 대비 문제를 예상하기 어려워서 부담을 많이 가졌었다.

서술형인지, 빈칸 채우기인지, 단답식인지 걱정도 많이했는데

내가 치른 시험에서는 다양한 유형들이 나왔었지만

주관식이라는 문제의 특성으로 인해 난이도가 올라간 경우는 거의 없었다.

서술형도 내 기억으로는 네트워크의 한 문항 정도였고 나머지는 대부분 빈칸 채우기였다.

생각해보면 주관식의 체감 난이도가 생각보다 낮았는데, 대부분을 차지한 빈칸 채우기 문제들의 지문이

헷갈리지 않게 대답을 유도하는 식으로 구성되어 있었고, 채워야하는 빈칸의 <보기>도 제공되는 문제들도 있었기 때문에 점수따기 좋았다.

그러니까 주관식 문제들은 부분점수가 있기 때문에 절대 비우지 말고 뭐라도 채우자. 문제내에 힌트도 많다!

아쉬웠던 점이나 느낀점

개요에서는 독학사 시험을 "4단계의 시험만 통과하면 학사학위를 얻을수 있는것." 이라고 언급했었지만

사실 시험에 대한 두려움이 정말 컸다.

내 경우는 1개의 시험만 통과하면 학위를 따는것이지만,

"내가 정말 할수 있을까?"

"불합격하면 내년까지 시험 못보는데 그땐 어쩌지?"

"졸업 후 취업이 아닌 독학사를 준비하는게 정말 맞는 선택일까?"

"불합격하게 된다면 내가 올해 한 공부들은 뭐가되는건가?"

"인강도 안보고 독학으로 합격하는게 정말 가능할까?"

라는 생각들로 정말 많은 갈등을 했었지만 그럴때마다 독학사 합격 후기를 보며 마음을 다잡았다.

결과적으로는 합격을 했지만 "내 인생에서 이렇게 열심히 공부해본적이 있을까?" 라는 생각이 들정도로 필사적으로 임했다.

요즘은 합격의 기쁨도 있지만, 내가 한 노력으로 뭔가를 이뤘다는 것에서 업된 기분이다.

부모님이 많이 좋아하시기도 하고

독학사에 대한 개인적인 생각

독학사 제도 자체에 대한 의의는 제쳐두고

느낀 개인적인 생각으로는 공부하면 합격할수 있는 시험이라고 생각한다.

문제의 지문이나, 보기들이 소위 말하는 함정 문제가 매우 드물다고 생각한다.

내 기준에서는 시험전에 걱정하던 부분보다는 생전 처음보는 개념이나 문제가 나와서 당황한것 외에는 평이했다.

내 입장에서 독학사라는 제도 자체는 정말 이점이 많은 제도였다.

결과적으로 돌이켜 보면 학교를 졸업하고 산업기사 시험을 준비하거나 해보고 싶었던 프로젝트를 하면서 시험을 준비하는 과정들의

끝이 독학사 시험을 합격한것이 되어서 4년제 학교를 다닌것과 같은 셈이 된것같다.

harry

카드게임 커뮤니티 개발기

개요

❓ 뭘 개발했나

프로젝트 설계

어떤 과정을 거쳤나

아쉬웠던점

후기

Link

로컬라이징 (지역화) 구글 스프레드 시트로 자동화하기

로컬라이징 (지역화) 구글 스프레드 시트로 자동화하기

개요

그동안 사용했던 일반적인 방법

구상

준비

develop 할점

다시 취업을 했다.

2019년 후기

✒️ 개요

독학사부터 취업, 퇴사

⏲ 부스트 캠프

☀️ 하반기부터 현재까지

TIL

강의

프로젝트

소감

부스트 캠프 2019 참여 후기

✒️ 개요

❓ 계기

느낀점

⏲ 미션

피어세션

릴레이 프로젝트

소감

음원차트 파싱 프로젝트

github

Preview

✒️ 개요

프로젝트 설계

Weekend Commit Preview

아쉬웠던점

사용해본것들

Links

네오플 오픈 API를 이용한 프로젝트

✒️ 개요

❓ 뭘 개발했나?

어떤 과정을 거쳤나.

얻게 된것

아쉬웠던 점

마치며

독학사 후기

❓ '독학사'에 대해

시험준비에 어려웠던점

✏️ 어떤식으로 공부했는지

버릴건 버리자

평가원 예시 문제를 완벽히 숙지하자

주관식

아쉬웠던 점이나 느낀점

독학사에 대한 개인적인 생각