[울산] 이스케이프탑-젠틀맨(AR)

2018. 9. 27. 17:16

명절에 처가 방문차 가게 된 울산

와이프, 처제와 함께 방탈출을 즐기기로 했다.

지친 몸에 활기를 불어넣어줄 것을 기대하며 찾은 방탈출!


이스케이프탑젠틀맨(AR+)

업체난이도: ★★☆ (5/10)

체감난이도: ★★ (2/5)

스토리: ★ (1/5)

추천도: ★☆ (1.5/5)


Player 참고: 방탈출 경력 20회 부부


feat by. 만능형 처제


Comment: (성공/2 hint)

 Jason: "AR은 그저 꼼수!?"

 Julie: "요원테스트가...음..."


Intro:

딱히 없음 (영화 킹스맨 컨셉인듯..?)


일단 총평은 좀 아쉽달까?

AR에 대해서 한마디 하자면 매우 초보적인 활용이다.

마치 장치 만들기 어려운 부분을 스크린으로 대신한 느낌?

앞으로 AR방은 패스할 것 같다.


그리고 몰입도가 매우 약하다.

Intro가 없고, 스토리도 부실하다.

왜 이 문제를 풀고 있는가 의문이 든다.

나는 왜 요원이 되어야하는 것인가?

미션 수행이 아닌 그저 퀴즈 풀기 놀이 하는 느낌.

내가 기대하는 방탈출은 이런 것이 아니었다...


공간은 3명이서 진행하기에 좁지는 않았다.

무서운 요소 또한 없다.

왜 포스터에는 피같은 것이 튀어있는지...


장치도 여럿 있어 자물쇠 장치 비율 5:5 정도


힌트를 2번 사용했다.

하나는 AR 때문에...

다른 하나는 명확하지 않은 문제 가이드 때문이었다.

어떤 자물쇠에 사용할지도 알겠는데 여튼 모호했다.

더이상의 설명은 비밀유지를 위해 생략한다.


입문단계였다면 재밌을 수 있겠다.

다만 좋은 테마를 많이 경험한 이후라 실망이 컸다.


그리고 사진 찍어주는 서비스도 없다.

탈출을 축하해 주지도 않는다.

(서비스 만족도에 은근 중요한 요소)


아쉬운 점이 많은 방탈출 경험이었다.


3명의 머리라 44분만에 탈출하여 명예의 전당에!?

(45분 안에 탈출하면 올릴 수 있다)


탈출 인증샷



TechTrip 스압없는 소소한 Ep./방탈출

Angular State Management (NGXS) Code

2018. 9. 22. 23:04

오늘은 지난 글에서 소개했던 ngxs의 코드를 살펴보겠습니다.


아래와 같은 순서로 만들어 가게 되는데요.


1. Action 추가 (소비 내역 추가)

2. State 추가 (하루 소비 내역)

3. Select 추가 (component에서 하루 소비 내역 조회)


1. Action 추가


action은 데이터를 변경하는 동작을 말합니다.

소비 내역을 추가하는 action을 정의하였습니다.

(저는 가계부를 만드는 개인 프로젝트 진행중입니다.)

import { Consumption } from "../domain/consumption";

export class AddConsumption {
    static readonly type = '[Budget Page] Add Consumption';
    constructor(public consumption: Consumption) {}
}

지난 번 생성한 Consumption 도메인을 활용합니다.


type에는 어떠한 action인지 설명을 적어줍니다.

ngxs 공식 페이지에서는 아래와 같은 규칙을 권장합니다.

- 명령이 수행되는 맥락 (ex: [User API],[Product Page])

- 행위를 설명하는 동사 (ex: Get, Add, Delete)

- 행위의 대상 Entity (ex: User, Product)


constructor는 추가할 consumption을 인자로 받습니다.


즉, 설명과 Action이 수행될 metadata를 정의해주는 것입니다.


2. State 추가


State의 이름과 기본값, action의 실제 동작을 정의합니다.

ngxs 코드의 가장 핵심 부분이라고 볼 수 있습니다.


State는 @State라는 annotation을 사용하여 정의합니다.

import { Action, State, StateContext } from '@ngxs/store';
import { DailyExpense } from '../domain/dailyExpense';
import { AddConsumption } from './budget.actions';

@State({
    name: 'dailyExpense',
    defaults: {
        datetime: new Date(),
        consumptions: [],
    }
})
export class DailyExpenseState {
    @Action(AddConsumption)
    addConsumption(context: StateContext, action:AddConsumption){
        const state = context.getState();
        context.setState({
            ...state,
            consumptions: [
                ...state.consumptions,
                // this is the new consumption instance that we add
                action.consumption,
            ],
        });
    }
}

name은 Store에서 State를 구분하는 역할을 합니다.

따라서 유일(Unique)한 이름을 부여해야만 합니다.


기본값은 날짜와 소비내역 배열로 하였습니다.


State class에는 action과 dependency를 정의합니다.

저는 아직 dependency는 정의하지 않았구요.

action만 정의하였습니다.


Action 추가에서 action의 class를 만들었죠.

실제 수행되는 코드는 State안에 있습니다.

@Action annotation을 사용합니다.

context와 action을 인자로 받는 method를 만듭니다.

context에는 ngxs Store에 저장된 State가 담겨있습니다.

그것을 가져와서 action을 수행합니다.


3. Select 활용


이제 실제로 Component에서 State를 활용해보겠습니다.

먼저 app.module.ts에 import를 해주어야합니다.

...
import { NgxsModule } from '@ngxs/store';
import { DailyExpenseState } from './budget/budget.state';

@NgModule({
  declarations: [
    ...
  ],
  imports: [
    ...
    NgxsModule.forRoot([
      DailyExpenseState
    ])
  ],
  bootstrap: [AppComponent]
})
export class AppModule { }

ngxs 모듈에 정의한 State를 넣어주었습니다.


다음은 State를 사용할 Component의 코드를 보겠습니다.

...
import { Store, Select } from "@ngxs/store";
import { Observable } from 'rxjs';

@Component({
    ...
})
export class BudgetComponent implements OnInit {
    ...
    // ngxs select
    @Select(state => state.dailyExpense) dailyExpense$: Observable<DailyExpense>;

    // ngxs store dependency injection
    constructor(private store: Store) { }

    ngOnInit() {
        this.balance = this.budget;
        this.date = new FormControl(new Date());

        this.dailyExpense$.subscribe((dailyExpense) => {
            // using state data
            ...
        })
    }

    // using ngxs action 
    addConsumption(consumption: Consumption) {
        this.store
            .dispatch(new AddConsumption(consumption));;
    }
}

State를 조회하기 위해 @Select annotation을 사용합니다.

State중 가져올 값을 lambda 형태로 정의해주면 됩니다.

그리고 저장할 변수값을 정하죠. 

보통 $를 붙여서 state임을 표시합니다. 


타입을 보면 아시겠지만 state는 rxjs의 Observable 입니다.

따라서 subscribe하면 값이 화면에 동적으로 반영되죠.


state를 변경할 때는 설명드린바와 같이 action을 사용합니다.

action을 사용할 때에는 생성자에 주입한 Store를 이용합니다.

Store에 action 객체를 생성하여 dispatch하는 형태입니다.


복잡해보이지만 천천히 살펴보시면 쉽게 이해가 되실 겁니다.

지난 포스팅의 ngxs의 개념이 도움이 되실거에요.

(http://dschci.tistory.com/111)


아래는 ngxs를 기반으로 동작하는 화면입니다.


ngxs를 활용한 화면 예제


다음에는 동작화면의 Material Form에 대해 알아볼게요.

진행하는 작업은 github에서 보실 수 있습니다.


소스주소: https://github.com/jsrho1023/account-book

'IT Tech > Angular' 카테고리의 다른 글

Angular Forms (Validation)  (0) 2018.10.14
Angular Forms (Simple)  (0) 2018.10.07
Angular State Management (NGXS)  (0) 2018.09.15
Npm 거슬리는 pacakge-lock.json?  (2) 2018.09.02
Angular 업데이트(Update from 5 to 6)  (0) 2018.05.19

TechTrip IT Tech/Angular

Angular State Management (NGXS)

2018. 9. 15. 22:57

지난 번에는 Service를 만들어 비즈니스 로직을 분리해봤습니다.


원래 Service에 RxJS를 더해 직접 구현하려다가

(Angular 기본접근법은 그렇습니다) 

조금 변경하여 State Management 라이브러리를 도입하기로 하였습니다.

Application 복잡도는 낮지만 배움과 재미를 위한 개발이라서요.


라이브러리는 많은 선배 개발자들의 고민을 바탕으로 하고 있습니다.

그렇게 만들어진 좋은 구조를 익혀가는 것도 의미가 있다고 생각되었어요.


Angular의 State Management를 생각하면 먼저 떠오르는 것은 ngrx입니다.

하지만 저는 ngxs를 써보려고 합니다.


그 이유는 ngxs가 더 Angular 답기 때문입니다.


ngrx의 출발은 Angular가 아닌 React입니다.

React는 Redux라는 State Management 라이브러리를 가지고 있습니다. 

 ※ React는 Facebook에서 만든 Front-End Library

Redux를 Angular로 가져온 것이 바로 ngrx 입니다.

잘 사용하려면 먼저 Redux를 이해할 필요가 있습니다.

Redux를 이해하려면 React의 라이프사이클에 익숙해야하죠.

즉, Learning Curve가 높을 수 있습니다.


그에 반해 ngxs는 ngrx보다는 새로운 angular 전용 라이브러리입니다.


오늘은 ngxs의 간단한 소개를 할까 합니다.

ngxs는 4가지 중요한 개념이 있습니다.

(다른 State Management 라이브러리도 비슷한 개념을 가집니다.)


먼저 doc site의 설명을 그대로 가져오면 아래와 같습니다.

State: state를 정의하는 class

Action: 수행하는 action과 metadata에 대한 정보가 담긴 class 

Selects: Store에서 state의 일부를 가져오는 function

Store: state의 저장소이자, action, select를 관리하는 전역 객체


네 이해 안되실거에요. 저도 그렇습니다.


제가 작업하면서 개념적으로 이해한 것은 아래와 같습니다.

State: Angular Component가 화면에 보여줘야하는 데이터

Action: 서버와 통신(비동기)하고 데이터를 변경하는 역할

Selects: 데이터를 Angular Component에게 가져오는 역할

Store: State를 저장, action과 select를 관리/참조하는 중심


저는 머리 속에 아래 그림처럼 정리하였습니다.

사실 많은 부분을 생략하여 그린 그림입니다.

이해를 돕는 차원에서 봐주시면 될 것 같아요.


ngxs 중요 개념 (많은 부분 생략)


그래서 ngxs 라이브러리를 사용하면 좋은 점은 무엇일까요?

스스로 개발해야했던 부분이 이미 상당부분 구현되어있습니다.

아마도 제가 스스로 만드는 것보다 훨씬 잘 만들어져있겠죠.


서버와의 통신 부분이 구조화/모듈화될 수 있습니다.

코드 관리가 더 수월해지는 장점이 있습니다.


다음 포스팅에서는 실제 코드로 작성된 부분을 공유해볼게요.


정보출처:

ngxs document site - https://ngxs.gitbook.io/ngxs


'IT Tech > Angular' 카테고리의 다른 글

Angular Forms (Simple)  (0) 2018.10.07
Angular State Management (NGXS) Code  (0) 2018.09.22
Npm 거슬리는 pacakge-lock.json?  (2) 2018.09.02
Angular 업데이트(Update from 5 to 6)  (0) 2018.05.19
Angular Service 만들기  (2) 2018.05.13

TechTrip IT Tech/Angular

Tomcat 8 에서 WildFly(JBoss) 13 로...

2018. 9. 9. 15:58

Spring Boot 어플리케이션을 Tomcat에 배포하여 사용중이었습니다.

화면은 Vue.js로 개발하였고, Spring Boot는 API Server의 역할이었죠.


Tomcat에 war로 배포하여 사용하다가 WildFly로 이동하게 되었습니다.

이유는 기술 지원 그룹 분들이 WildFly가 익숙하기 때문이었습니다.

Tomcat이나 WildFly나 그게 그거라는 말씀만 덜컥 믿었죠.

시간상 기술적으로 충분히 검토될 수 없었습니다.


From Tomcat to WildFly


그러다보니 2가지 알 수 없는 에러에 부딪쳤습니다.


첫 번째 문제는 java.lang.ClassCastException 입니다.

Tomcat에서는 발생하지 않던 문제였고, WildFly로 옮기자 발생하였습니다.

org.apache.tomcat.websocket.server.WsServerContainer 

cannot be cast to io.undertow.websockets.jsr.ServerWebSocketContainer


이 문제는 Spring Boot의 dependency 설정을 변경해줘야 합니다.

Spring Boot의 내장 톰캣을 제외합니다.

그리고 undertow를 provided scope에 추가합니다.

<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-web</artifactid>
    <exclusions>
	<exclusion>
	    <groupid>org.springframework.boot</groupid>
	    <artifactid>spring-boot-starter-tomcat</artifactid>
	</exclusion>
    </exclusions>
</dependency>
<dependency>
    <groupid>org.springframework.boot</groupid>
    <artifactid>spring-boot-starter-undertow</artifactid>
    <version>2.0.4.RELEASE</version>
    <scope>provided</scope>
</dependency>


두 번째 문제는 multipart/form-data 였습니다.

화면단 Vue.js에 API 서버로 파일을 전송하는 로직이 있습니다.

multipart/form-data를 이용하여 파일을 전송하죠.

매우 일반적인 상황입니다.


그러나 파일이 없는 multipart/form-data 요청시 문제가 발생하였습니다.

Create가 아닌 Update의 경우에도 같은 API를 사용합니다.

파일의 변경이 없을 경우가 바로 그런 경우입니다.

이 역시 Tomcat에서는 문제가 없었던 로직이죠.


이 문제는 파일 저장 API를 분리하여 해결하였습니다.

파일의 변경이 없는 경우에는 API를 호출하지 않도록 화면을 수정했죠.


Tomcat과 Wildfly(JBoss)는 비슷한듯 하지만 엄연히 다른 WAS 입니다.

어떤 이유에서든 기술적인 검토를 충분히 해야했습니다. 

아마 앞으로 어떤 문제가 더 생길지... 막연한 두려움이 생기네요.

TechTrip IT Tech

베란다에서 레몬 바질 키우기

2018. 9. 9. 14:58

지난 4월 레몬 바질 씨앗을 사서 남는 화분에 심었습니다.

베란다에 두고 물주면서 편하게 키우는데 잘 자라더군요.


오늘은 키워보면서 느끼고 깨달은 점을 소소하게 공유할까 합니다.

아래는 베란다에 심은 바질이 자라온 모습이에요.


레몬 바질 생장 속도


1. 생장속도


주워 듣기로는 바질은 생장속도가 굉장히 빠르다 했습니다.

그러나... 본잎이 나기까지 꽤나 오랜시간이 걸렸습니다.

무려 50일... 한 달이 넘었죠.


아무래도 생장 속도가 빠르다는건 본잎이 난 이후인가 봅니다.

본잎이 나고 50일 만에 훌쩍 자랐으니까요.


2. 생장조건

2000원 짜리 씨앗을 구매하면 약 200개 정도의 씨앗이 들어있습니다.
여러 화분에 나눠 심었죠.
햇볕이 잘드는 자리에 있던 화분은 알아서 쑥쑥 잘 자랍니다.
그러나 상대적으로 햇볕이 잘 안드는 자리의 화분은 그렇지 못했네요.
햇볕이 상당히 중요한 역할을 하는 것 같습니다.

그리고 영양제를 꼽아줬던 바질 화분의 줄기가 더 튼튼합니다.
영양이 충분히 공급되어야 줄기가 튼튼하게 자라나봐요. 

물은 일주일에 1번 정도 줬습니다.
부족함 없이 잘 자라는 것 같아요.

주기적으로 환기를 시키면서 통풍은 잘 된것 같구요.
딱히 바질을 위해 따로 창을 열지는 않았습니다.

바질 올린 스파게티


손으로 툭툭 치면 향이 많이 나고 좋아요.

역시 허브입니다.

스파게티에 올려 먹어보니 색감도 좋고 향도 잘 나네요.


앞으로 쑥쑥 자라면 바질페스토도 만들어볼까.. 생각중입니다.

바질 키우기는 다른 식물보다 쉬운 편인 것 같아요.

노는 화분이 있다면 씨앗 사서 키우는 재미를 느껴보세요.


TechTrip 놀면서 배우기.

Npm 거슬리는 pacakge-lock.json?

2018. 9. 2. 15:18

저는 Angular CLI를 이용해서 Angular 앱개발을 시작했습니다.

그러면 자연히 npm(Node Package Manager)을 사용한다는 말이 되죠.

얼마전 GitHub에 아래와 같은 경고 메시지가 등장합니다. 


github 리파지토리 경고 메시지


package-lock.json이라는 녀석은 저의 작업 파일도 아닙니다.

대체 저 녀석은 무엇일까요?

오늘은 그것을 알아보도록 하겠습니다.


1. package-lock.json 이란?


npm 5.x.x 버젼 이상을 사용할 때 생겨나는 파일입니다.

이 파일이 생겨나는 시점은 npm install 입니다.

npm install 명령은 package.json을 보고 node_modules 폴더를 생성합니다.

그 폴더 안에 package.json에 명시된 의존성 패키지들을 설치하죠.

생성된 node_modules 폴더의 정보를 pacakge-lock.json에 담습니다.


동일한 package.json은 동일한 node_modules를 만들어내야합니다.

그래야 의존하는 앱이 정상적으로 동작을 할테니까요.


그러나 동일한 package.json이라도 서로 다른 node_modules를 만들게 되는 경우가 생깁니다.

  1) npm의 버젼이 다른 경우

  2) 의존성을 가진 패키지의 버젼이 업그레이드 되는 경우

  3) 의존성을 가진 패키지가 의존하는 패키지의 버젼이 업그레이드 되는 경우


1) 은 쉽게 이해가 가는 내용이구요.

2), 3)의 경우, 아래와 같은 package.json을 예를 들어 보겠습니다.

{
  "name": "myApp",
  "version": "0.1.0",
  "dependencies": {
    "1st_depth": "^1.0.0"
  }
}

myApp은 1st_depth라는 패키지에 의존성을 가지고 있습니다.

1st_depth 패키지는 아래와 같은 package.json을 가집니다. 

{
  "name": "1st_depth",
  "version": "1.0.0",
  "dependencies": {
    "2nd_depth": "^1.0.0"
  }
}

1st_depth은 2nd_depth라는 패키지에 의존성을 가지고 있구요.

2nd_depth의 package.json은 아래와 같습니다.

{
  "name": "2nd_depth",
  "version": "1.0.0"
}

위와 같은 설정에서 node_modules는 아래와 같은 구조가 되겠지요.

myApp@0.1.0
`-- 1st_depth@1.0.0
    `-- 2nd_depth@1.0.0


이런 상황에서 위의 2), 3)번은 아래와 같이 발생하게 됩니다.


2) 의존성을 가진 패키지의 버젼이 업그레이드 되는 경우

myApp@0.1.0
`-- 1st_depth@1.0.1
    `-- 2nd_depth@1.0.0

1st_depth가 1.0.1로 업데이트 되었다고 가정해봅시다.

그러면 npm install시 1.0.1 버젼의 1st_depth를 받아오게 됩니다.

사실 이는 myApp의 package.json에서 B 버젼을 완전히 고정하면 해결됩니다.


그러나 3)의 경우는 좀 더 복잡합니다.

3) 의존성을 가진 패키지가 의존하는 패키지의 버젼이 업그레이드 되는 경우

myApp@0.1.0
`-- 1st_depth@1.0.0
    `-- 2nd_depth@1.0.1

2nd_depth가 1.0.1로 업데이트 되었다고 가정해봅시다.

그러면 npm install시 1.0.1버젼의 2nd_depth를 받아오게 됩니다.

1st_depth의 개발자는 보통 myApp 개발자와 다를 확률이 높습니다.

따라서 우리는 1st_depth 개발자의 package.json을 수정할 수 없습니다.


이런 상황이 package-lock.json의 필요성이 대두되는 순간입니다.

package locks 혹은 lockfiles로 불리우며 package.json의 약점을 보완합니다.

myApp 개발자의 node_modules 폴더의 스냅샷을 저장하는 방식으로 말이지요.


2. package-lock.json이 존재하는 경우 npm install


package-lock.json이 존재하는 경우 npm install의 동작이 조금 달라집니다.

npm install시 더이상 package.json을 계산하지 않습니다.

package-lock.json에 명시된 의존 패키지들을 통해 node_modules를 만들어내죠.

pacakge-lock.json이 생겨난 이유를 생각하면 당연합니다.


3. package-lock.json의 변경


따로 사용하는 방법이 있는 것은 아닙니다.

package.json 변경 후 npm 명령어를 수행하면 됩니다.

package.json의 변경은 package-lock.json보다 우선시됩니다.

npm install, npm rm, npm update는 개발자의 node_modules를 변경시키게 됩니다.

그러면 자연스럽게 package-lock.json이 변경됩니다.


Q & A


 Q1. pacakge-lock.json은 형상관리에 포함시켜야하나?

  당연히 포함시켜야합니다.

  모든 개발자가 같은 node_modules를 가지고 작업하기 위해 필수입니다.


 Q2. package-lcok.json이 충돌하게 되는 경우 어떻게 하나요?

  여러 명의 개발자가 각각 다른 장비에서 npm install을 하다보면 발생하는 현상입니다.

  5.7.0 버젼 이후로는 package.json을 수정하여 npm install을 하여 해결합니다.

  --package-lock-only 라는 옵션을 통해 node_modules 수정 없이 해결도 가능합니다.

  귀찮다면 npm-merge-driver라는 툴을 사용하면 됩니다.


 Q3. package-lock.json이 자꾸 변경되는데 막을 수 있나요?

  npm install 관련하여 --no-package-lock이라는 옵션을 사용할 수 있습니다.

  npm install로 변경되는 node_modules의 변경사항을 저장하지 않는 방법이죠.


GitHub에서 package-lock.json에 대해 신경쓰이는 경고를 날려주는 바람에 공부했네요.

도움이 되실까하여 공유드립니다. 


정보출처:

https://docs.npmjs.com/files/package-locks

https://medium.com/coinmonks/everything-you-wanted-to-know-about-package-lock-json-b81911aa8ab8

'IT Tech > Angular' 카테고리의 다른 글

Angular State Management (NGXS) Code  (0) 2018.09.22
Angular State Management (NGXS)  (0) 2018.09.15
Angular 업데이트(Update from 5 to 6)  (0) 2018.05.19
Angular Service 만들기  (2) 2018.05.13
Angular Domain Model  (0) 2018.04.24

TechTrip IT Tech/Angular

개발자 추천 폰트(feat. Ligature)

2018. 8. 15. 16:11

요즘 개인 프로젝트(Angular)는 거의 중지 상태입니다...

여행 + 바쁜 회사 업무로 진도가 안나가네요.


그리고 사실 화면(Angular)으로만 진행하기는 한계가 왔어요.

그리하여 mongo + nodejs + express로 간단한 서버 구성 중입니다.


현황 공유는 여기까지.

서버 구성 코딩 하면서 얻은 정보하나 짧게 공유할까 합니다.


바로 개발하기에 좋은 폰트!

저는 사실 MS의 consolas 팬이었습니다.

여전히 좋아하고 주로 쓰는 폰트에요.


하지만 consolas에는 없는 Ligature라는 것을 알게 되었습니다.

Liagature(합자)의 의미는 아래와 같습니다.

손 글씨나 타이포그래피에서 두 개 이상의 문자를 합쳐서 하나로 형성하는 것.


그래서 실질적으로 무엇에 유용할까요?

개발자가 자주 쓰는 대,소비교 구문들이 읽기 쉬워집니다.

a>=b, a<=b, a === b, a!=b 와 같은 것들이 아래처럼 표기됩니다.


    with Ligature(합자)


편리하죠? 

Ligature를 지원하는 폰트가 있습니다.

바로 Naver의 D2Coding 폰트. 네이버 칭찬해~~!

https://github.com/naver/d2codingfont


물론 호불호가 갈리긴 합니다.

그래서 그런지 최신 버전에서는 Ligature 폰트를 분리했네요.


제가 자주 쓰는 IDE Visual Studio Code에도 설정 가능합니다.


1. D2 Coding 폰트를 다운로드 후 설치

2. Visual Studio Code 설정에 아래와 같이 추가

   

   File>Preferences>Setting (Ctrl+,)


Ligature의 매력에 D2Coding 활용해볼까해요.

특히 Pair Programming을 하면 가독성이 중요한데 그 때 써보려구요.

끌리시는 분들은 한 번 사용해보시길 권장합니다.

TechTrip 놀면서 배우기.

[신촌] 룸익스케이프 화이트점-신비로운 호빗의 집

2018. 8. 15. 14:09

광복절 휴일을 맞아 오랜만에 방탈출을 즐겼다.

거의 2달여 만에 도전.. 머리가 굳었을까 염려하며 신촌으로!


오늘 방문한 곳은 룸익스케이프 화이트점

장치 비율이 높기로 유명한 곳이다.

방탈출 20회 이하의 경험치로 많은 장치를 경험해보진 못해 기대 반 두려움 반~


우리가 도전한 곳은 바로!


룸익스케이프 화이트점신비로운 호빗의 집

업체난이도: Normal (Normal/Hard 중)

체감난이도: ★★★ (3/5)

스토리: ★★★★ (4/5) 

추천도: ★★★★★ (5/5)


Player 참고: 방탈출 경력 19회 부부


Comment: (성공/0 hint)

 Jason: "아기자기한 게임 속의 집 같은 곳"

 Julie: "간달프가 이런 기분 이었을까?"


Intro:

잃어버린 풍요의 마법.

신비로운 호빗의 집에서 

풍요의 마법을 되찾아 

호빗들에게 알려주자!


모처럼의 휴일을 맞아 호빗들에게 광복의 기쁨을 알리기 위해... 죄송합니다.

인테리어는 마치 우리가 거인이 된 듯한 느낌을 주는 정돈된 호빗의 집

전체적으로 깔끔하게 꾸며져 있었고, 호빗의 집 치고는 넓다.

3명 정도는 충분히 같이 할 수 있을만한 공간.


전혀 어둡지 않고, 무서운 것(징그러운 것)은 1도 없다.

주로 장치로 되어있기에 소리에 놀라는 건(Julie.. ㅋㅋ) 어쩔 수 없...

장치가 90% 이상에 자물쇠 몇 개 추가? 이런 구성이다.

마법이라는 컨셉인 만큼 게임하는 느낌으로 진행할 수 있다.


방탈출 경험이 짧아 이런 말 하긴 좀 뭐하지만..

장치의 구성과 활용이 참 뛰어나다는 생각이 든다.


힌트는 명확한 편이나 관찰력이 필요하다.

문제를 풀면서 방의 변화를 잘 눈치채야 한다.

이 이상은 비밀유지 서명을 한 사람으로써 생략한다.


더 빨리 풀 수 있었는데 힌트를 잘못된 곳에서 찾아 헤매다가...

19분을 남기고 힌트 없이 탈출을 성공!

마치고나서 "아~ 재밌었다" 라는 말을 반복했다

강추하는 테마~


인증샷은 마법사의 옷을 입고 찍었다. -0-


탈출 인증샷



TechTrip 스압없는 소소한 Ep./방탈출

[범계] 룸즈에이-안개꽃

2018. 8. 5. 23:22

지난 5월에 다녀온 방탈출 카페인데...

게을러져서 미루다보니 이제서야 작성하게 된다.

그렇다고 재미가 없었던 건 아니다.


룸즈에이안개꽃

업체난이도: ★★★★☆ (4.5/5)

체감난이도: ★★★ (3/5)

스토리: ★★★★ (4/5) 

추천도: ★★★☆ (3.5/5)


Player 참고: 방탈출 경력 17회 부부


Comment: (성공/2 hint)

 Jason: "도슨트와 함께하는 그림 전시회 + 알파"

 Julie: "역시 소문대로... 기대하던대로..."


Intro:

화가인 그가 내게서 떠나간지 어느덧 한 달, 

나는 여전히 그와의 시간 속에 머물러 있다. 

그리움과 원망을 가득 안고 골목길을 걷던 어느 날, 

밤공기를 들이마시며 한 걸음씩 내딛던 나는 

작은 골목길과는 어울리지 않는 전시관을 보게 되었다. 

처음 보는 전시관이었지만 어디선가 그의 향기가 흘러나오는 듯 했고, 

그 추억 속의 향기에 이끌려 전시회장 안으로 들어서게 되었다.


얼마나 재밌길래 범계까지??

사실 볼 일이 있어서 갔고, 서울에 다른 지점도 있다. (대학로)

그리고 당시 할인이 진행 중 이었다. (범계점은 상시 할인 중)


일단 역시나 감성테마답게 인테리어 아름답다.

은둔 화가의 그림 전시실에 온 것 같은 느낌?

문제를 풀기 위해 그림을 더욱 자세히 관찰하게 된다.

그러면서 그림의 분위기와 느낌을 음미하게 되는 점이 좋았다.


장치의 비중이 높은 편이며, 가이드는 명확한 편이다.

적절히 생각하게 만드는 문제들이 많다.

사실 '읭?' 하는 부분이 한,두 문제 정도 있었지만 뭐~

문제가 순서대로 진행되니 시작점을 찾는 것이 중요하다.


방은 밝고 공포도는 1도 없다.

(삑.딱.쿵으로 창조 공포 만들어내는 Julie는 소리에 놀라긴 함)

나의 담력은 언제 빛을 발할 것인가...


다소 아쉬웠던 점은 서비스 마인드(?)

범계점이 원래 그런 것인지 아니면 점원의 실수인지는 불명확하다.

탈출 성공! 이라는 마침표 느낌이 없었다.

마음가는데로 꾸미는 칠판도 없고 사진 찰칵~ 안녕히가세요...


다른 룸즈에이는 가더라도 범계점은 다시 갈지 모르겠다.

멀기도 하고..


탈출인증샷



TechTrip 스압없는 소소한 Ep./방탈출

[강남] 서울이스케이프룸-탈출하라1998

2018. 7. 22. 14:17

기본적으로 어렵다는 평이 있는 서울이스케이프룸

방탈출에 어느정도 익숙해지고 가야 즐길 수 있다는데...

난이도가 5점 만점에 4 이하가 없어!

 

그래도 워낙 평이 좋은 곳이라 직접 가보고 싶었다.

 

서울이스케이프룸탈출하라1988

업체난이도: ★★★☆ (4.5/5)

체감난이도: ★★★ (4/5)

스토리: ★★★ (4/5) 

추천도: ★★★ (3.5/5)

 

Player 참고: 방탈출 경력 18회 부부

 

Comment: (성공/2 hint)

 Jason "추억의 물품들이 가득한 옛날 집 (기억도 안나는 4살때!?)"

 Julie "반갑다 친구야" 

 

Intro:

시간여행을 연구하던 아버지가 의문의 사고로 돌아가신지 약 30년..

어려서 아버지를 잃은 당신은 아버지의 길을 따라 평생을 타임머신 개발에 바쳐왔다.

그리고 드디어 타임머신 개발에 성공한 당신은,

‘시간여행자의 실험실’에서의 사건으로 인해 아버지의 자취를 따라

과거로 돌아가서 아버지를 직접 만나보기로 마음을 먹는다.

 

때는 약 30년전.. 바로 서울이 세계의 중심이 되어 올림픽을 개최했던 1988년!

과연 아버지를 만날 수 있을까? 아니, 만나도 되는 것일까?

1988년의 서울은 대체 어떤 모습이었을까?

한껏 부푼 기대를 안고 타임머신을 가동시켜

아버지의 좁은 자취방에 도착한 당신은 텅 빈 방안을 보고 실망한다.

아버지를 기다리며 길거리로 나가볼까 했으나,

이내 당신은 이 방이 안팎으로 잠겨 있다는 사실을 깨닫는다.

아버지는 아마도 방문을 걸어잠근체 이 안에서 타임머신 개발에 매진해왔던 듯 하다.

그런데 도대체 안팎으로 문을 잠궈놓고 어디로 간걸까 ?

당신은 텅 빈 방 안에서 실종된 아버지를 찾기 위해 단서를 찾기 시작하는데..

 

시즌2의 시간 여행자의 실험실 테마를 합쳐 넣었다고 한다.

Intro에서 볼 수 있듯이 1988년의 모습으로 꾸며진 방이다.

그 시절을 추억할 수 있는 소품들도 많아 몰입을 도와준다.

그리고 그 소품들을 더 자세히 관찰해야 하는 점이 재미를 더한다.


힌트를 얻는 방법도 독특하다.

CCTV를 보며 다같이 춤을 춰야한다...

그러면 직원이 지켜보고 스크린에 텍스트로 힌트를 준다.

궁금한 부분을 자세히 소통할 수 없어 좀 불편한 것 같다.


공간은 좀 좁은 느낌이 든다.(두 명 정도가 적당)

그리고 방 사이 이동시 치마는 불편해 보인다.


자물쇠와 장치가 반반 정도? 

이과 + 공대생인 Jason에게 힌트 없이도 풀 수 있는 그런 문제들이 좀 있었다.

고딩시절 열심히 외운 암기법이 자연스레 떠오를 것이다.

해보면 안다. ㅋㅋ 

그래도 순서 헷갈리지 않게 힌트를 바탕으로 푸는게...

기본지식 없어도 풀 수 있게 힌트들이 마련 되어 있다.

 

개인적으로는 가이드가 부족해보이는 문제가 하나 있었다.

거기서 힌트를 2개나 사용하게 되어 좀 아쉬운 감이 있다.

너무 친절해서도 안되고, 그렇지만 이유를 몰라서도 안되는...

문제 고안하기 어렵긴 하겠다...

 

그리고 다른 방탈출에서는 못본 신박한 장치가 하나...

엄청 신기해요는 아니지만 색다르게 재밌었다. 

 

게다가 서울이스케이프룸은 여러 방들이 하나의 커다란 스토리로 이어진다.

그 스토리의 시작점으로써 더할 나위 없는 방이었다.

 

탈출인증샷


TechTrip 스압없는 소소한 Ep./방탈출