목차

반응형

개요

람다라는 서비스를 통하여 serverless 구조로 기존의 dedicated 서버 형식 API 또는 백엔드 서버가 없는

본인은 올해로 6년 차 개발자이며, 작년 9월부터 이직했고 회사에 도착해 보니 보통 알고 있던 ec2기반 백엔드 + 프론트 서버의 형태가 아닌 sam(serverless application model) 백엔드 + 클라우드프론트, 앰플리파이를 통한 완전히 aws 서비스만으로 모든 서버의 유지부터 배포를 끝내는 아키텍쳐를 경험했다.
해당 회사에서 지금 4월까지 얼추 6개월정도 해당 아키텍처를 기반으로 신규 프로젝트 구축부터 유지보수를 진행했다.
비록 일시적이지만 게시판, VOD, 회원가입, 결제가 최소한으로 들어간 4개의 프로젝트의 시작부터 종료까지 함께했다.

이 정도면 꽤 실험적이 아닌 실무적으로 aws lambda 서비스를 활용했다고 믿을 수 있지 않을까?
우선 람다는 핵심 서비스의 장기적인 개발 관점에서 탈락이다. 큰 단점이 매우 많이 존재한다.
한번 해볼까? 하는 마음가짐으로 람다를 가볍게 도입하려는 분께는 내가 미리 똥이란 것을 알아넀으니 단호하게 No라고 하겠다.

 

장점

존재하는 모든 API 서버를 한눈에 볼 수 있다.

1. aws에서 콘솔로 관리 : 단순 정보는 조회에 용이

어디에 무엇이 있는지 aws 콘솔에 전부 나와 있기 때문에 알 수 없는 정보란 존재하지 않는다.
말이 어려운데 예를 들자면 프로젝트에 API 서버가 4개가 있고 이를 아무도 모아놓은 docs가 없다고 해보자.
aws에 구축해놓았다면 서비스 콘솔에 모든 정보가 바로 뜨기 때문에 한눈에 서비스를 보기에는 빠르고 쉽다.

 

프로젝트에서 결과로 API로 쓰일 함수만 내보낼 수 있으며 등록한 API는 우측 이미지와 같이 콘솔에 표출된다.

2. 함수형 지향, 기능 구현에 집중 할 수 있음

우리가 API 서버를 구축한다고 하면 정말 많은 것을 고려해야 하지만 sam 방식은 정말로 API로 쓰일 핵심 함수만 구축하면 되기 때문에 기능 구현에 초점 집중 할 수 있다.
나아가 모든 기능을 함수로 제공하는 것을 강제하기 때문에 유저는 자연스럽게 재사용, 함수형 개발을 할 수 있다.

 

lambda의  워크플로

3. 토이 프로젝트로 가볍게 몇개 올리기에는 좋다

위와 마찬가지로 API 서버를 구축하려면 인프라 차원에서 세팅해야 하는 부분이 많다.
하지만 aws lambda를 활용하면 자동으로 git repository 생성부터 자동 배포까지 알아서 해준다.
이는 여러 인프라 세팅 단계를 스킵할 수 있기 때문에 매우 편하다.

 

4. https 설정, 도메인 연동 용이

aws에 붙어 있는 서비스라서 도메인, 거의 자동으로 https 프로토콜 적용이 가능하며 도메인 연동에 용이하다.

 

5. 함수별 호출 에러, 로그 조회 자동으로 상세화

직접 서버를 구축한 경우, 특별히 로깅 시스템을 구축하지 않았다면 에러가 발생했을 시 stacktrace 형식으로 에러가 발생한 부분을 찾을 것이다.
그러다 보면 정확히 원인이 발생한 지점까지 확인하지 못할 수도 있다
lambda는 함수단위로 에러 로그를 조회 할 수 있는 시스템이 기본으로 구축되어 있어 발생한 에러에 대한 파악이 쉽고 빠르다.

 

여기까지 봤을때는 와... 이걸 외 안씀? 이럴 수 있는데 극적 반전을 위해 단점을 아래 배치했다.
나의 한이 서린 원념을 담아서 작성해보겠다. 쭉 읽어보라

 

단점

실제 프로덕트에 쓰기에는 다양한 문제점을 동반

본 글의 요지이자 핵심인데 장점을 초월하는 실제 프로덕트에 쓰기에는 너무 많은 단점이 존재한다.
이는 개발을 어렵게, 불가능하게 만들 뿐더러 결과론적으로 더 오래걸리고 품질이 낮은 서비스가 될 가능성을 높여준다.
실제로 현재 다니고 있는 회사는 API의 dev 서버가 따로 존재하지 않으며, api 서버의 배포를 한 번 하는데 10~15분정도 걸리며, 구체적인 서버 커스터마이징이 불가능하다.

로우쿼리가 매 함수에 들어간다면...?

1. 구조 부재 : 지옥

모든 개발 프로젝트가 동일하지만... 람다라는 서비스는 초심자가 활용하게 된다면 가이드가 없기 때문에 함수형을 가장한 안티패턴이 될 가능성이 높다.
본 회사는 모든 함수에 로우쿼리가 들어가 있어 데이터의 CRUD를 재사용 하지 못하고 있다... ㅠㅠ (사실 모든 함수에 로우쿼리가 존재하는 것에 대한 문제인식이 안되는 것 부터 문제긴 하다.)
람다만이 가질 수 있는 함수형으로 인한 안티 패턴 특성이라 하면 함수 단위 하나가 스스로 돌아가기만 하면 되기 때문에 재사용성을 강요하지 않으면(기본이지만) 정말로 비슷한 함수임에도 불구하고 재사용을 1도 하지 않을 수 있다.
다시말해 일반적인 구조보다 함수마다 완전 다른 형태의 로직과 템플릿을 가질 수 있다.

 

chat gpt도 aws 람다는 로컬 디버깅이 안된다고 하신다.

2. 직접 디버깅 불가, 로깅 불편

치명적인 단점인데 직접 디버깅을 할 수 있는 방법이 없다.
브레이크포인트 찍으면 바로 잡을 문제를 하나씩 전부 로그찍게 만들어서 디버깅을 힘들게 만든다.
심지어 로그도 제대로 안돼서 매번 JSON.stringfy를 써야한다.

 

chat gpt 왈 aws 람다는 api마다 도커로 구동된다고 하신다.

3. 활용 불가능한 로컬 개발 환경

우선 api 서버를 로컬에서 구동하려면 docker가 필수적으로 실행되어 있어야 한다.(이건 딱히 문제가 안될 수 있다.)
그리고 api 주제에 각 api를 컨테이너로 구동하기 때문에 pc 리소스를 많이 잡아먹는다.(이것까지도 딱히 문제가 안될 수 있다.)

가장 크리티컬한 부분은 cold start라서 최초 호출 시 엄청 오래 걸린다.(약 5~10초?)
이는 테스트가 불가능할정도이며 존재하는 모든 문서를 찾아봤는데 현실적으로 방법이 없다.(warm start -> api 개수가 너무 많으면 모든 api를 warm start로 구동하는데 하루종일 걸림)
결국 나도 내 신념을 포기하고 프론트엔드 개발자 분 보고 개발서버로 로컬개발 하듯이 사용하라고 했다.

그동안 어쩔 수 없이 꾹참고 로컬로 테스트 하던 상황이 생각나 너무 화나서 욕좀 한번 박겠다. 병신같은 서버리스 어플리케이션 모델~~
나의 진심어린 분노가 여러분께 전달되어 한분이라도 이 똥을 안찍어먹을 수 있기를 바란다.

 

진행중 48분전 ... -> 지금 48분째 배포하고 있다는 뜻이다. 기네스감 아님?

4. 배포 개느림

아 욕 안할려했는데 저 사진 다시보니까 욕나옴 ㅋㅋ
시발 진짜 급해 뒤지겠는데 언제끝날지도 모르고 뭐할때마다 개오래걸리고 후...

api가 100개정도 넘어가는 시점부터 배포하는데 거의 15분정도 걸린다.
이거 때문에 배포만 빨라도 금방끝내고 퇴근할걸 야근당한적도 몇번 있었다.

 

5. 자료가 많이 없다.

다른 이슈들에 비해 그리 크리티컬하지는 않으나 aws lambda에 대한 개발 자료가 월등히 적다.
초보 개발자라면 굉장히 고통받을 것이다.

 

짤막한 사용 팁

6개월동안 구르면서 직접 터득한 노하우들이다.
간략히라도 쓰려고 했는데 위에 단점쓰면서 화가 너무나서 이 글 게시물 조회수 좀 나오면 후속 게시물로 쓰겠다.

환경변수 자동 세팅

하나의 git 프로젝트에 2개 브랜치로 배포 환경, 실서버, 개발서버 환경 배포 구축

반응형
반응형

움짤 한방으로 전부 설명할 수 있다.

1. 목차 자동 링크 특징

- 우측에서 플로팅으로 따라다님
- 게시물 내 h2태그 기준 목차 자동으로 추출
- 목차 클릭 시 해당 목차에 해당하는 영역으로 자동 이동
- 게시물에서 수정하거나 삽입 할 필요 없이 javascript로 후처리 하여 간편한 사용
- 만드는데 3시간 정도 걸렸음. 이걸 자기가 만든 것 처럼 무단배포 하는 착한 사람이 있으면 내가 이런 꿀정보를 공유 못함.

 

2. 적용 방법

본인은 square 스킨을 사용 중, 다른 스킨을 사용하면 HTML 코드 구조가 다를 수 있으니 유의!

 

꾸미기 > 스킨 편집

 

html 편집

 

이후 아래 3개의 코드를 적절한 위치에 추가해주면 된다.
이미지를 참고하여 위치를 확인 후 코드를 복사해서 넣어주자.

 

 

- HTML 코드(1)

<div id="floating-banner">
    <h3>목차</h3>
    <ul id="items">
    </ul>
</div>

 

- HTML 코드(2)

<script>
$(document).ready(function () {
	initFloatingBanner();
});

function initFloatingBanner()
{
	var tmp = parseInt($("#floating-banner").css('top'));
 
	$(window).scroll(function () {
			var scrollTop = $(window).scrollTop();
			var obj_position = scrollTop + tmp + "px";

			$("#floating-banner").stop().animate({
					"top": obj_position
			}, 500);

	}).scroll();

	document.querySelectorAll('#body.entry h2').forEach((element, index) => {
		console.log(element.innerText)
		if(!isStringOnlySpaces(element.innerText))
		{
			element.setAttribute('id', `h2_${index+1}`);
			addFloatingBannerItem(index+1, element.innerText)
		}
	});
}

function isStringOnlySpaces(str) {
  return /^\s*$/.test(str);
}

function addFloatingBannerItem(index, text) {
  const ul = document.getElementById("items");
  const li = document.createElement("li");
  const a = document.createElement("a");
  const linkText = document.createTextNode(text);
  
  a.setAttribute("href", `#h2_${index}`);
  a.appendChild(linkText);
  li.appendChild(a);
  ul.appendChild(li);
}

</script>

 

- CSS 코드

/*
	따라다니는 배너
*/
#floating-banner {
			position: absolute;
			width: 200px;
			right: -200px;
			border-radius: 5px;
			top: 250px;
			border: 3px solid #dddddd;
			padding: 5px;
			font-size: 150%;
			line-height: 1.2em;
	}

#floating-banner a {
			color: blue;
	}

 

반응형
반응형

1. 개요

2. 현재 상황

3. 진행 사항

4. 추가 탐구 필요한 부분

 

 

 

 

1. 개요

본인은 SI 업체에서 코드 몽키 생활을 2년 정도 하다가 유니티 클라이언트로 2년 정도 하면서 어느 정도 개발에 대한 이해가 조금씩 생기기 시작했다.

백엔드 및 전반적인 서비스 구축에 대한 능력은 소규모, 사이드 프로젝트 경험밖에 없기 때문에 선진 개발 문화 경험이 부족하다.

스스로도 많이 부족함을 느끼고 있지만 당연히 의지가 부족한지라 별도로 스킬업을 할 생각은 못하고 있었다. 

 

그러던 찰나...

 

대표님께서 잘 알고 계시는 대기업 출신 개발자 한분을 모셨다. 처음에는 풀 스택 개발자라길래 좀 걱정됐다.

만나서 몇번 얘기해보니까 정말 믿고 따라갈만한 분인 것을 느꼈다. 

 

 

오자마자 회사의 파트별 리드 개발자들과의 미팅을 하셨고 현재 회사의 상태로는 목표 달성이 힘들 것이라고 말씀하셨다.

이것저것 뜯어 고쳐야하는 부분이 많고 기존 팀원들도 새로 배우고 적용해야 하는 것이 많다고 하셨다.

또한 팀이 전반적으로 '근본 없음'을 지적하셨고 '근본 탑재'를 위해서 노력하겠다고 하셨다.

 

이 시리즈는 근본 없는 개발자가 근본 있는 개발자가 되는 과정을 담아내기 위한 시리즈다.

해당 시리즈에서 앞으로 합류하신 개발자님을 그분 이라고 호칭하겠다. 

 

이 기회에 잘 배워두고 잘 기록해두면 나중에 분명 스타트업같이 맨땅에서 시작할 때 크게 도움이 될 것이라고 생각한다.

 

2. 현재 상황

현재 팀의 상황은 다음과 같다.

- 전체 인원 200명급의 모회사 

- 자회사 인원 7명 ( 디자이너 3, 개발자 3, CEO )

- 블록체인 서비스를 구현하는 것이 목표

- 개발자는 나, 동료, 그분 이렇게 3명

- 인원은 충원중이지만 너무 적다 보니 분야를 가리지 않고 개발해야 함 

 

3. 진행 사항

그분이 오셔서 바로 요청한 작업 사항이다.

 

개인 레포 > 팀 Git 레포 생성 및 취합

기존에는 각자 개발하던 부분을 개인 레포에 올려놓고 공유하는 방식이었는데 이를 팀 레포를 생성해서 한 곳에서 볼 수 있도록 환경을 구축하였다. 

그리고 개인 레포를 전부 팀 레포로 올렸다.

 

또한 거의 혼자 개발하다보니 기능별 커밋을 하지 않고 무분별하게 커밋을 하였는데 앞으로는 기능 단위로 커밋하기로 하였고 추후에는 코드 리뷰까지 도입하겠다고 했다.

 

 

TS 프로젝트 -> JS 프로젝트 컨버팅

본인은 개발하면서 TS로 프로젝트를 개발하고 있었는데 아직까지는 JS에 더 익숙하기 때문에 바닐라 JS로 다시 컨버팅해서 초기에는 JS로 개발하기로 하였다.

바닐라 JS보다 TS가 협업, 유지보수 측면에서 좋지만 러닝 커브가 있기 때문에 추후 TS 프로젝트로 다시 전환하자고 하셨다.

 

run.sh 쉘 스크립트 작성

프로젝트마다 run.sh 스크립트를 실행하면 최대한 환경에 구애받지 않도록 모든 디펜던시를 설치해주고 자동으로 도커 이미지까지 생성, 도커에 올려주는 쉘 스크립트를 짜도록 지시하였다.

쉘 스크립트도 간단히 짜봤고 도커에 대한 공부도 하였다. 

이렇게 해야 추후에 다른 개발자가 합류해도 누군가의 도움 없이 혼자서 빠르게 환경 구축이 가능하기 때문에 이 부분은 선택이 아닌 필수라고 하였다.

 

도커라이징

모든 프로젝트는 도커 환경에서 구동 가능하도록 세팅을 해야 한다고 하셨다.

추후 실 서비스를 호스트 기반 배포로 갈지, 도커 기반으로 갈지는 고민 중이지만 적어도 개발 환경은 도커 기반으로 간다고 하셨다.

이에 따라 프로젝트를 도커에서 구동 가능하도록 Dockerfile 생성, 도커 이미지 빌드, 도커 구동 테스트를 해보았다.

 

리드미 작성

리드미를 작성하지 않았는데 어느 정도 리드미를 작성해야 한다고 하셨다.

환경변수, API 설명, 명령어 정보를 적어둬야 한다.

 

 

4. 추가 탐구 필요한 부분

터미놀로지

터미놀로지라는 용어를 사용하셨는데 뭔지 몰라서 찾아봤다.

이는 조직 내 무언가를 지칭하는 용어를 말한다. 다만 용어가 불분명하여 혼선이 없도록 해야 한다.

 

도커와 VMware 차이

도커와 Vmware는 엄청난 차이가 있다고 하였는데 이 정도는 알아야 할 것 같다. 간단히 찾아봤는데 쉽지 않다 조금 더 심층적으로 탐구해봐야겠다.

반응형
반응형

윈도우 11을 쓰다보면 익스플로러가 진짜 속이 미어터지도록 느려진다.

정뚝떨!

 

구글링 해보니까 나만 그런게 아니라 많은 사람들이 윈도우 11로 업그레이드 하고나서 익스플로러 렉이 엄청 심해졌다는 불만이 많다.

 

해결방법을 찾았다. 윈도우 11의 상태에서 익스플로러만 다시 예전의 윈도우 10의 익스플로러로 바꾸는 방법이다.

 

WinaeroTweaker-1.33.0.0-setup.exe
2.51MB

위 파일을 다운받아서 설치한다.

 

설치한 프로그램을 시작하고 Windows 11 > Enable Ribbon > Enablef the Ribbon UI in File Explorer를 활성화 해준다.

그러면 아래 Explorer 재시작 요청이 뜨는데 수락해주면 된다.

 

그러면 익스플로러가 예전 형태로 돌아오는데

속도도 다시 빨라졌다!

반응형
반응형

증상

node 백엔드에서 구글 클라우드 스토리지 서비스를 사용하여 파일을 업로드하려고 했으나 자꾸 아래와 같이 접근 권한 오류 발생했다.

storage-service-account@******.iam.gserviceaccount.com does not have storage.objects.create access to the Google Cloud Storage object.

 

원인

구글 스토리지 서비스 계정에 권한을 부여하지 않아서 그렇다.

 

스토리지니까 대충 저거 부여하면 되는 줄 알았더니 아니다.

더 정확히 찾아봐야 한다.

 

아래 링크에서 본인이 사용하려고 하는 명령어는 어떤 권한이 필요한지 확인해보고 부여하도록 하자.

https://cloud.google.com/iam/docs/understanding-roles

 

역할 이해  |  Cloud IAM 문서  |  Google Cloud

역할에는 Google Cloud 리소스에서 특정 작업을 수행할 수 있는 일련의 권한이 포함되어 있습니다. 사용자, 그룹, 서비스 계정을 포함하여 주 구성원에게 권한을 제공하려면 주 구성원에게 역할을

cloud.google.com

 

해결방법

이렇게 3개의 관리자 권한을 주면 대체로 해결된다.

 

본인은 권한을 제대로 부여했는데 작동하지 않아서 구글 커맨드라인 콘솔에서 특정 계정에 부여된 권한 부여 및 조회하는 명령어도 찾아봤다.

 

구글 서비스 계정 양식

cloud-storage-service@******.iam.gserviceaccount.com

 

권한 부여

gcloud projects add-iam-policy-binding cloud-storage-service --member "serviceAccount:cloud-storage-service@******.iam.gserviceaccount.com" --role "roles/storage.objectViewer"

gcloud projects add-iam-policy-binding x-*** --member=serviceAccount:cloud-storage-service@******.iam.gserviceaccount.com --role=roles/storage.admin

gcloud projects add-iam-policy-binding x-*** --member=serviceAccount:cloud-storage-service@******.iam.gserviceaccount.com --role=roles/storage.objectCreator

 

권한 조회

gcloud projects get-iam-policy x-*** --flatten="bindings[].members" --format="table(bindings.role)" --filter="bindings.members:cloud-storage-service@******.iam.gserviceaccount.com"

권한을 조회하면 위와 같이 현재 계정에 부여된 권한이 나온다.

 

본인은 그냥 버킷 이름을 제대로 안 써서 계속 권한이 없다고 나온 것이었다.

반응형
반응형

크롤링을 하는 당신

특정 요청에 대한 결과값을 받고 싶으나 302 redirect로 인하여 요청한 결과가 아니라 redirect한 결과를 받을 것이다.

 

이를 이미지로 도식화하자면 위와 같다.

내가 원하는 건 A요청에 대한 응답이지만 B응답이 와버리는 것이다. 필요 없는데...

 

그런 경우는 본인이 사용하는 http request에 분명 redirect를 제한하는 기능이 있을 것이다.

해당 기능을 비활성화하여 강제로 redirect를 하지 않도록 하면 된다.

그로 인하여 요청의 결과값이 error로 떨어지는 경우도 있으나 머 그건 알아서 하자.

 

node axios의 경우는 request option에 maxRedirects:0 이라고 설정하면 알아서 해당 요청의 redirect가 비활성화된다.

 

그러면 다음과 같이 원하는 A응답에 대한 결과를 받을 수 있다.

굿!

반응형
반응형

1. 개요

빠른 본론.
본인은 거의 4개 정도의 역할을 하고 있다.
대학교 재학, 온라인 쇼핑몰 CEO, 2개 프로젝트의 개발 및 PM 역할
단순 회사원일때는 많아봐야 맡는 역할이 2개 정도라서 상관없는데 많아지니까 우선순위와 놓치게 되는 일정, 태스크가 굉장히 많아져서 곤란해졌다.
이에 따라 일정을 관리하는 방법을 찾아보다가 굉장히 만족스럽게 활용하고 있는 나의 구글 캘린더 활용 방법을 소개하겠다.

 

2. 캘린더 세팅

먼저 활용할 구글캘린더 계정을 선택하고 당신이 맡은 역할별로 캘린더를 생성해야 한다.
나로 예를 들자면 맡고 있는 프로젝트 2개, 대학교, 쇼핑몰 이렇게 4개의 캘린더를 생성했다.

 

좌측 하단의 + 버튼을 누른다.

 

Create new calendar을 한다.

 

name에 본인이 할당하고자 하는 역할의 이름을 정한다.

 

그러면 좌측 하단에 본인의 역할이 생성된다. 그러면 ...을 눌러서 해당 역할의 색상을 원하는 색으로 변경해주자.
일단 본인의 경우는 추후에 일정에 대한 성공, 실패 여부를 파란색 빨간색으로 지정하기 때문에 빨간색, 파란색 계열의 색상은 피해서 설정했다.

 

그러면 캘린더 아무 곳을 선택하고 테스트로 업무를 생성해보자.


제목 : 일정의 이름
시간 : 일정의 시간이 정해져 있지 않으면 All day(종일)로 설정하자
설명 : 일정에 대한 설명이나 메모를 적어놓도록 하자
역할 : 할당된 일정을 선택하자

 

 

당신의 첫 일정이 성공적으로 등록됐다.

 

3. 업무 상태 관리

본인의 업무 상태를 관리하는 방법은 다음과 같다.
일정을 지키고 마무리하면 해당 일정을 우클릭하고 색상을 파란색으로 바꾼다.
만약에 일정을 지키지 못한 경우에는 내일 가능할 것 같으면 내일로 미루고 이번 주에 어차피 계속 질질 끌다가 진행을 못할 것 같으면 과감하게 빨간색 처리를 해버린다.

 

왼쪽 이미지는 아직 마무리되지 않은 이번 주 캘린더이고 오른쪽 이미지는 지난주의 일정 캘린더다.

이런 식으로 본인이 일정에 대한 상태값을 지정해서 관리하면 굉장히 편하다.

 

4. 핸드폰과 연동

 

당연히 핸드폰과 해당 캘린더 연동이 가능하다. 꼭 해놓자

 

구글 캘린더 앱을 업데이트, 설치하고 본인이 사용하는 계정과 연동하자

 

 

이런식으로 위젯으로 빼서 사용 가능하다. 마찬가지로 굉장히 편리하다.

 

 

5. 일정 관리 팁

이것은 본인이 구글 캘린더로 일정관리를 하면서 터득한 팁이다.

 

예상치 못한 업무가 너무 많이 추가돼서 숨을 못 쉬겠습니다. 항상 일정에 빨간색이 가득하고 뭔가 하기 싫습니다.

본인도 초기에는 욕심을 담아 일주일 일정을 빡빡하게 배정했다. 그러다가 점차 생각지 못한 일정이 항상 추가되면서 일정을 다음날로 미루다 가장 힘들고 피로한 금요일에 일정이 폭발해버리는 것을 자주 겪었다.
어차피 할 수 있는 업무는 한정되어 있는데 캘린더에 빨간색만 쌓이고 정말 일하기 싫은 상황의 연속이었다.
그러다가 한 가지 좋은 방법을 찾았다.

 

금요일에는 오전 업무만 하고 퇴근한다는 느낌으로 일부러 일정을 엄청 비워놓는 것이다.
그러면 업무가 밀리면서 금요일에도 결국 정상근무를 하게 되고 무사히 일주일의 업무를 마칠 수 있게 된다.

 

이번 주의 일정 세팅은 지난주에 하자

다음 주에 할 일을 이번 주에 세팅하자는 것이다.
이미 일주일이 시작된 상태에서 일정을 짜기보다는 한 주가 시작되기 전에 여유로운 마음으로 일정을 짜는 것이 더 차분하고 멀리 볼 수 있어서 좋았다.

 

일정이 너무 많고 어려워서 시작할 엄두가 안 나요

캘린더를 활용하다 보면 몇몇 일정은 자꾸 손도 안 대고 다음날로 밀리는 일정이 생길 것이다.
본인도 아직 그런 상황이 많다.
그런 경우는 일을 더 쪼개서 본인이 해당 업무에 대한 시작을 할 수 있도록 스스로를 장려하도록 하자
항상 모든 스케줄은 시작이 반이다. 시작이 힘들면 쪼개서 나에게 작은 성공을 주도록 하자!

 

캘린더는 공적인 계정, 회사 계정과 분리하도록 하자

당연하지만 귀찮다고 회사 계정으로 이걸 하다가 원하지 않는 정보를 타인에게 보여줘 버리는 불상사가 발생할 수 있으니 반드시 계정을 분리하도록 하자.

 

구글 캘린더 활용 팁

구글 캘린더를 더욱 편리하게 활용할 수 있는 팁은 따로 게시물을 만들어서 올릴 예정이다.
해당 부분도 꼭 참고하도록 하자.

 

 

같이보면 좋은 글

일정 관리 방법 - 구글 캘린더 활용 이렇게만 하면 쓰리잡 쌉가능

구글 캘린더 활용 팁

반응형
반응형

일주의 시작을 월요일로 세팅하는 방법

기본적으로 일주일의 시작이 일요일로 되어있어서 불편하다.

 

우측 상단의 설정 페이지에 들어간다.

 

일반 설정 페이지에서 내려가 보면 일주일의 시작 요일을 바꾸는 부분이 있다.

 

월요일로 바꾸도록 하자.

 

일정 생성할때 캘린더 기본값 바꾸는 방법

캘린더가 여러개 있을 때 특정 캘린더의 일정을 생성할 때마다 자꾸 캘린더를 바꿔줘야 하는 번거로움이 있다.

 

"대학교 강의 일정" 캘린더에 일정을 추가하고 싶으나 기본값으로 "개인일정"의 일정이 생성돼서 바꿔줘야 한다.

 

그럴 때는 원하는 캘린더가 체크된 캘린더 중에 가장 위에 위치하도록 설정을 해주면 된다.

 

"개인일정" 캘린더의 체크를 풀면 자동으로 "대학교 강의 일정" 캘린더에 일정이 생성된다.

 

 

일정 설명 값에 텍스트 붙여 넣기 하는 경우 개행이 안될 때

메모장에 왼쪽 이미지와 같이 텍스트를 입력하고 이후 복사해서 구글 캘린더의 설명에다가 붙여 넣기를 하면 개행 문자가 전부 사라져서 가독성이 안 좋게 바뀐다.

 

어떻게 하면 개행 문자를 인식할 수 있을지 엄청 찾아봤는데 못 찾았다.

이를 해결할 수 있는 편법을 소개한다.

 

https://chrome.google.com/webstore/detail/checker-plus-for-google-c/hkhggnncdpfibdhinjiegagmopldibha

 

Checker Plus for Google Calendar™

See your next events, get meeting notifications and snooze events without opening the Google Calendar page!

chrome.google.com

Checker Plus for Google Calendar라는 구글 확장 프로그램을 사용하여 일정을 등록할 때 설명란에 붙여 넣기를 하면 개행 문자를 제대로 인식한다.

 

 

 

편리한 구글 캘린더 단축키

우측 상단에 단축키를 보는 곳이 있다. 그 외에도 자주 쓰이는 단축키를 소개하겠다.

D : 캘린더 일 단위 조회

W : 캘린더 주 단위 조회

M : 캘린더 달 단위 조회

T : 오늘 날짜 조회

/ : 검색

J, K : 이전 페이지, 다음 페이지 이동

 

시간 설정 편히 하는 방법

일정의 시간을 마우스로 설정하려면 굉장히 불편하다.

 

2가지 쉽게 일정의 시간을 설정하는 방법을 알려주겠다.

 

1. 일정의 이름에 시간 명시

15:00-17:00 일정이름

일정의 이름을 위와 같이 지정하면 알아서 15:00~17:00의 시간이 지정된 일정이 생성된다.

 

2. 마우스 드래그로 일정 시간 지정

드래깅을 통하여 쉽고 빠르게 일정 시간 설정이 가능하다.

 

날짜 상단 누르면 자동 allday, 하단 누르면 자동 시간

본인은 대부분 하루종일(allday) 일정을 생성하는데 일정을 생성할때마다 해당 체크박스를 선택할 필요 없다.

 

위 이미지에서 상단 빨간색 부분을 눌러서 일정을 생성하면 자동으로 하루종일(allday) 형태의 일정이 생성되고 아래 초록색 부분을 선택하면 시간이 지정된 일정이 생성된다.

 

 

같이보면 좋은 글

일정 관리 방법 - 구글 캘린더 활용 이렇게만 하면 쓰리잡 쌉가능

구글 캘린더 활용 팁

 

반응형
반응형

개요

인맥을 넓히기 위해서 IT 연합동아리를 들어가려고 했다.

어디가 좋을까 찾아보다가 9월 첫 주부터 모집을 시작하는 SOPT라는 동아리를 한번 지원해보기로 했다.

주요 키워드는 지식, 적극성, 창업이었다. 본인과 연관이 깊어서 회사도 4년 정도 다녀봐서 충분히 비벼볼 만하지 않을까? 생각하였다.

 

자기소개서, 서류면접을 준비해야 한다.

질문은 아래와 같다.

 

공통 질문

1. 협업 시 팀원이 지원자에 대해 표현한 말 중 가장 인상 깊었던 말이 있나요?
그때의 상황과 인상 깊었던 이유를 구체적으로 설명해주세요. (700자)


2. 인생에서 가장 기억에 남는 도전은 무엇인가요?
도전 계기와 도전 과정의 어려움 및 극복 과정을 구체적으로 설명해주세요. (700자)


3. 자신만의 의사소통 방식을 제시하고, 해당 방식이 가장 효과적으로 발휘되었던 경험을 구체적으로 설명해주세요. (700자)
제 의사소통은 솔직함, 두괄식, 수평적이라는 크게 3개의 특성이 있습니다.


4. 지식이나 경험을 공유받고 자신의 것으로 체화해본 경험이 있나요?
이를 바탕으로 무언가를 배울 때의 자신만의 가치관이나 마음가짐을 구체적으로 설명해주세요. (700자)

 

 

파트 질문

1. WE SOPT 서버 파트에 지원한 이유와 지원하기까지의 노력에 대해 구체적으로 알려주세요. (600자)


2. 개발 공부를 하면서 개인적으로 어려움을 겪었던 경험을 이야기해주시고, 그 어려움을 어떻게 극복하였는지 설명해주세요.
(꼭 서버 관련 공부가 아니어도 괜찮습니다.) (800자)


3. 협업을 진행하며 함께 성장한 경험에 대해 이야기해주세요.
자신이 팀 내에서 맡았던 역할과 협업 과정을 통해 배우고 느낀 점에 대해 구체적으로 설명해주세요.
서버 개발 경험이 아니어도 좋습니다. (800자)

 


4. 지원자가 사용해본 언어/프레임워크 중에서 가장 자신 있는 것을 하나 들어 자신의 이해도를 이야기해 주세요.
또한 선택한 언어/프레임 워크 중에서 개념 또는 키워드를 포함해서 설명해주세요. (700자)

 


5. 위 내용과 결과물에 대한 링크가 있다면 첨부해주세요.

 

결과, 후기

일단 본인은 서류 탈락했다. 탈락한 이유는 알려줄 의무는 없지만 정확한 이유가 무엇인지 궁금해서 담당자한테 물어봤으나 정확한 답변을 듣지는 못했다.

아무리 생각해도 객관적으로 내 스펙이 부족해서는 아닌 것 같고, 본인의 소개서와 동아리 측에서 원하는 가치관 및 태도가 초점이 안 맞아서 그런 것이라 생각이 든다.

흠... 충분히 자세를 낮추고 썼거늘... 어쩔 수 없지 다른 IT 연합 동아리나 지원해봐야겠다.

불평하나 하자면 서류 질문 양이 너무 많은 것 같다.

반응형
반응형

 

1. 개요

2. 자주 쓰는 기능

3. 추천 설정 옵션

 

 

 

 

 

1. 개요

생각보다 윈도우 기본 내장인 캡처 도구를 사용하는 사람이 많다. 하지만 나는 오래전부터 픽픽이라는 프로그램을 사용하였는데 정말 편하다. 지금 캡처 도구를 사용하고 있는 사람이라면 한번 사용해보는 것을 강력 추천한다.

 

 

2. 자주쓰는 기능

활성화된 윈도우 캡처하기(Alt + PrintScreen)

윈도우 컨틀로 캡처하기(Ctrl + PrintScreen)

영역을 지정하여 캡처하기(Shift + PrintScreen)

전체선택(Ctrl + A)

이미지 크기 변경(Ctrl + R)

캔버스 크기 변경(Ctrl + E)

 

스탬프

스탬프는 이미지 상에서 순차적인 설명이 필요할 때 굉장히 편리하다.

 

1. Today Headline은 .... 입니다.

2. 색채의 시각적 효과는 ... 입니다.

3. 색채탐방은 ... 입니다.

6주 Color quiz는 ... 입니다.

이런 식으로 설명할 때 굉장히 편리하다.

 

편리한 도형 그리기

무언가 설명할 때 빨간색 박스를 그려야 하는 경우가 굉장히 많다.

그럴 때도 픽픽을 사용하여 박스를 그리고 색을 넣어주면 빠르게 원하는 결과물을 얻을 수 있다.

 

모자이크

1. 모자이크 영역 선택

2. 모자이크 클릭

3. 모자이크 비율 설정

 

모든 파일 저장

1. 다른 이름으로 저장

2. 모든 파일 저장

 

3. 추천 설정 옵션

자꾸 무언가 수정하고 선택할 때마다 수정한 요소를 이미지와 합칠지 물어보는 것을 비활성화하는 것인데 나는 자동으로 합쳐지는 게 편해서 위 설정을 사용해놓고 사용한다.

반응형