D 프로젝트 1차 회고

프로젝트 개요

  • 일정: 2016년 1월 중순부터 5월 중순까지 약 4개월 진행, 6월부터 2차 진행 중
  • 주요 사용 기술:
    • Backend는  Spring mvc 4 기반 사내 프레임워크. Java8의 Feature들을 적극 사용하려고 노력, 리파지토리는 jOOQ를 사용
    • Frontend는 Angular2 베타에서부터 시작해서 rc.1에 이르면서 1차 마무리. Angular2와 함께 rxjs, 일부 immutablejs 활용 및 라이브러리로 lodash 사용, Angular2 개발언어로 자바스크립트가 아닌 Typescript 사용, 패키징에 Webpack 적용
  • 첫 프로젝트
  • 주로 작업한 내역:
    • 프로젝트 초기 환경셋팅
    • front 앱 템플릿 코드 셋 작성 및 패키징 환경 설정 구성 (Angular2-webpack-starter를 우리 상황에 맞게 변형)
    • D 상세 등록 서버-프론트 부분 작업
    • 프로젝트 내 이벤트 비동기 호출 처리 서비스
    • Angular2를 열심히 파 본 덕에 angular.io 매뉴얼 소소한 2건의 commit 기여

 

느낀 점1: DDD 맛보기

  • 설계 시간이 거의 없어 충분히 고민할 시간이 부족했었음
  • 그래도 욕심을 좀 부려 DDD를 공부하면서 프로젝트에 이를 접목해 보고 싶었음
  • 자료 검색 중 DDD를 맛 보게 해준 자료: 토비님의 “스프링 프레임워크와 DDD
  • 글을 읽고 찾은 적용 포인트 하나! 가능하면 빈약한 도메인 모델은 만들지 말자.
  • 내가 맡은 코드의 서비스 레이어는 애플리케이션의 공통적이고 부가적인 지원성 성격의 기능(로깅, 트랜잭션, 에러처리 등)만 다루고 비즈니스 로직을 도메인에 담아보기로 결정
  • 비즈니스 로직의 8~90%가 CRUD와 Validation이었는데 CRUD 때문에 도메인 클래스 안에 리파지토리를 넣는 코드로 구현하게 됨
  • 하나의 메서드에 여러 개의 리파지토리 구현체를 파라미터로 넘기는 것이 맞는지 의문이 들었음
  • 차라리 도메인 클래스 안에 리파지토리를 멤버로 갖고 있어 복수의 리파지토리를 파라미터로 받지 않는 것이 더 낫지 않을까 생각
  • 그러나 이건 함께 하는 팀원과 상의가 안된 부분이고 뭔가 아닌 것 같아 완전 롤백.
  • 결국 전통적인 방식으로 서비스 레이어가 커지는 스타일로 CRUD 처리.
    • 나중에 알게 되었지만 위와 같은 스타일이 Active Record(활성레코드) 패턴

 

  • 원점에서 DDD는 도대체 어떤식으로 코드를 짜는 건지 샘플이 보고 싶어서 여러 차례 구글링 해봤지만 마땅한 예제 소스를 발견 못함
  • 그러다가 참고할 자료로”엔터프라이즈 애플리케이션 아키텍처 패턴” 책 읽기 시작
  • 트랜잭션 스크립트, 도메인 모델, 활성 레코드 개념을 알게 되고 차이를 이해하게 됨
  • 이어서 도메인 주도 설계 책을 읽기 시작 했으나 개념이 쉽게 이해되지 않고 코드 예가 부족해서 머리에 잘 안들어왔음
  • 다시 원점에서 자료 조사를 하다 발견한 자료: 조영호님의 블로그
  • 그리고 작년에 있었던 KSUG의 세미나 영상
  • 두 개의 영상을 보고 플젝에 DDD를 어떻게 적용할지 정리를 함
  • 결론적으로 트랜잭션 스크립트, 활성레코드 스타일 대신에 가능하면 Validation, 객체 조합 및 생성 등의 비즈니스 로직을 도메인 객체로 이관
  • DDD를 살짝 맛보면서 좋았던 점
    • 서비스레이어에서 비즈니스 로직을 테스트 했으면 스프링 컨텍스트 안에서 돌려야 하니 무거운데 도메인 객체는 POJO로서 테스트 케이스가 가벼워짐
    • 서비스 레이어의 메서드의 길이가 줄고 비즈니스 로직이 메서드로 추출되면서 가독성이 향상 됨

 

느낀점 2: Java8

  • 플젝 이전의 경험은 간단한 형태의 filter나 predicate 후 collect하는 수준
  • 플젝하면서 좀 더 적극적으로 Java8의 기능을 적용해 보려고 했음

 

  • 첫 욕심: Optional을 쓰자, 쥬니어다운 “예외가 없는 프로그램이 완벽하지!”  설익은 발상으로 리파지토리의 인터페이스 반환 값을 모두 Optional로 감싸자고 제안
  • 무식하게 모델 단 건 뿐아니라  Collection까지 다 Optional로 묶음
  • Optional 변수 네이밍을 고민하다 구글링 끝에 가장 마음에 드는 것으로 maybeXX를 결정하고 네이밍
  • Optional을 쓰고 보니 모든 코드에 다음과 같은 스타일의 코드가 붙음

  • 리파지토리 조회 코드에 모두 저런 식의 코드가 붙다보니 나중에 귀찮아서 그냥 maybeXXX.get()을 바로 해서 사용하는 경우가 생겨 Optional 사용의미가 떨어짐
  • 불편함을 느낀 와중에 Collection 타입의 반환은 빈 Collection을 주면 될 것을 뒤늦게 깨닫고 Collection 반환시에는 Optional을 걷어 냄
  • 이런 경험을 하고 나서 그럼 Optional은 어떨때 사용하면 좋은지 찾아보니 주로 라이브러리 개발 등 타인에게 API 제공 시 활용하면 좋다고 함
  • jOOQ와 함께 쓰면 단 건 모델의 경우 다음과 같이 코드를 짤 수가 있어서 Optional활용이 편해짐

  • 두번 째 욕심: Java8의 꽃은 역시 스트림이지 하면서 가능한 for문에 스트림 적용
  • 다만 일부 케이스에서 오히려 스트림이 로직을 한번에 이해하기 어려웠음
  • 한 예로 복수의 데이터를 사용자로부터 입력 받아 DB에 있는 데이터와 비교해서 입력된 데이터에서 빠진 것은 삭제하고 신규로 추가된 것은 insert하는 코드
  • 여러 번의 코드 리팩토링과 스트림 내의 다른 연산을 통해서 조금 더 가독성 확보

 

  • 스트림을 쓰면서 좋은 점 중 하나인 parallelStream!
  • 독립된 복수 연산이나 API 콜 및 db insert/update에 적용
  • 혹시나 하는 마음에 parallelStream과 관련해서 조사 중 다음과 같은 글들 발견
  • 내용 골자는 parallelStream이 공통의 스레드 풀을 사용한다는 것. 그래서 Hang이 걸릴 수 있는 부분에는 별도의 스레드 풀로 돌려야 함.
  • 그래서 API 콜 및 db insert/update 부분에서 parallelStream을 쓴 경우에는 ForkJoin으로 감싸서 처리

 

느낀점 3:  jOOQ

  • 리파지토리에 JPA를 적용해 볼 수도 있으나, 기존 db 스키마를 고려했을 때 JPA보단 직접 쿼리를 짜는 것에 대한 오너십이 필요하다고 생각
  • 그렇다고 if~ else 분기처리를 포함한 쿼리 템플릿을 xml에 담아서 마이바티스를 쓰는 것은 지양하고 싶다는 것이 팀원간의 공통된 의견
  • 그래서 jOOQ를 쓰기로 함.
  • jOOQ는 queryDSL과 유사하지만 좀 더 쿼리 키워드와 가까운 메서드로 쿼리를 읽는 것 같은 코드를 작성하게 해주는 라이브러리임
  • 예를 들면, insert나 select 코드는 다음과 같은 모양을 갖고 있음

  • 위의 코드와 같이 메서드 자체가 쿼리 키워드와 동일하고, 실제 생성되는 쿼리도 메서드와 동일함
  • 사전에 테이블 스키마를 클래스로 자동 생성해 주어 insert 하거나 select 할 때 바인딩할 값들은 반드시 테이블의 컬럼 타입과 동일해야 함.
  • 즉 컴파일 타임에 db에 넣는 값의 타입 안정성 보장
  • 단점이라고 한다면 쿼리를 코드로 짜다보니 큰 실수를 하기 쉬움.
  • where 절을 빼서 전체 테이블을 업데이트 했던 아찔한 순간이 있었음
  • 나중에 파트장님이  jOOQ에서 제공하는 쿼리 실행 전후 리스너에 where절이 없을 경우 쿼리 실행을 막도로 추가해 줬음

 

느낀점 4: 예외처리는 힘들어

  • 첫 프로젝트이다 보니 RunTimeException을 어떻게 처리할 것인가 고민이 많았음
  • 기본적으로 Controller를 통해서 유저뷰까지 예외를 내리고, UI에서 해당 예외를 적절하게 처리하는 것이 옳다고 생각함
  • 다만 비즈니스 로직 상 예측 가능한  NPE 같은 것들까지 일일이 UI애서 처리하기 보다 에러코드로 추상화해서 UI로 내려주는 것으로 결론을 지음
  • 사용자가 쓰는 서비스이다 보니 에러 발생 시 원인 파악을 위해서 에러코드를 관리하는 것이 더 좋을 것 같다고 판단했음
  • 그럼에도 불구하고 예외를 어떻게 관리하고 처리할 것인가는 고민이 필요한 이슈
  • 다행히 사내 기술 공유 메일에서 이와 관련된 논의가 있어서 참고하고 통찰을 얻을 수 있었음
    • 간단한 형태의 비즈니스 로직을 예외로 던지면 스택 트레이스 오버헤드 등 있을 수 있음
    • 비즈니스 로직 중 간단하게 처리하기 어려운 경우에 한해서 예외로 던지는 것은 의미가 있음 등

 

느낀점 5: UI 개발은 어려워

  • 어드민 성격이지만 사용자가 쓰는 서비스이기에 UI쪽 공수가 많은 프로젝트
  • UI에 어떤 기술을 쓸지 상당히 중요한 요소 였음
  • 종래와 같이 jQuery로 할 경우 코드가 장황하게 나열될 위험이 높아 향후 유지보수의 어려움이 따를 것 같아 프레임워크를 쓰기로 했고 다소 과감하지만 Angular2를 사용하기로 함
  • 사용자가 쓰는 서비스다보니 다소 강도높은 QA를 하면서 실제 개발 시간의 70%가 UI개발에 쓰인 것 같음
  • Angular2 학습 비용도 있었지만, Typescript, ECMA6, rxjs등 다른 내용에 대한 적응도 필요 했음

 

느낀점 6: 애플리케이션과 SPA

  • Angluar2를 쓰면서 SPA(Single Page Application)에 대해서 다시 생각해 보게 됨
  • SPA에 대한 기존의 이해도는 하나의 페이지 안에서 원하는 모든 것을 다 할 수 있는 것 정도.
  • gmail을 이미 익숙하게 써왔으니 이정도로만 생각
  • 하지만 이번 플젝하면서 SPA는 일반적인 웹페이지와 철학 자체가 다르고 따라서 개발도 기존의 웹앱을 개발하는 방식의 관점으로 접근하면 안된다는 것을 깨달음.
  • 먼저, 이해한 바를 바탕으로 개념을 분리할 필요를 느낌
    • 홈페이지, 웹사이트 등은 하나의 큰 주제를 공유하는 웹페이지들이 고정된 URL을 가지고 있는 것
    • SPA은 하나의 서비스 또는 일련의 목적을 달성하기 위한 기능들의 묶음으로 이루어진 애플리케이션이고 다만 구동되는 호스트가 브라우저 임
    • 웹 애플리케이션은 SPA나 홈페이지, 웹사이트등 브라우저를 호스트로 해서 구동하는 애플리케이션을 말함
  • 위와 같은 개념으로 볼 때 이번 플젝의 결과물은 이론의 여지 없이 SPA임
  • 따라서 UI개발을 웹페이지 개발방식으로 접근하면 안되고 델파이나  C++(MFC)로 만드는 기존의 데스크톱 애플리케이션 관점으로 접근하는 것이 더 적합하다고 생각
  • 정작 데스크톱 앱은 Java(Swing)을 이용해 본 경험이 전부였음
  • 그래도 컴포넌트 기반 Angular2의 아키텍쳐를 보면서 컴포넌트 기반 개발 방법론에 대한 이해도를 얻을 수 있었음
  • 부트스트랩이나  angular material등의 css 프레임워크가 뜨고 있는 것도 위와 같은 맥락 안에서 웹용 UI컴포넌트로서 인기를 얻는 것이라고 볼 수도 있음
  • 즉, 현재 애플리케이션의 흐름이 기존의 OS에서 직접 구동되는 네이티브 애플리케이션에서 브라우저 위에서 동작하는 웹 애플리케이션으로 변화되었고 이러한 배경하에 SPA가 나온 것임
  • 물론 SPA가 나오기 위해서 ajax 기술 부터 Shadow dom, Web Component까지 html의 스펙도 진화한 것임
  • 거기다 최근에는 오히려 웹앱개발의 언어가 네이티브와 모바일에서까지 동작하게 만드는 추세로 발전한 것임(Electron, React Native)

매듭 짓기

  • Backend 개발을 하면서는 모델링의 중요성과 DDD를 어떻게 하면 잘 적용할 수 잇을지에 대한 경험을 쌓을 수 있었음
  • Frontend 개발을 하면서는 Typescript 덕분에 ECMA6를 다뤘던 점이 좋았고, 웹기술의 변천사의 흐름을 이해할 수 있었음

Ch 1: A Tour of Computer Systems 요약

1. A Tour of Computer Systems

 

1.1 Information Is Bits + Context

  • 모든 프로그램은 source file에서 시작한다. 예) hello.c
  • source file은 ASCII코드에 따라 숫자로 변환 되고, 숫자는 다시 binary로 표현할 수 있다.
  • 이 binary이 나열이 hello.c에 파일로 저장된 것
  • 컴퓨터에서 표현되는 정수와 실수는 실제의 수와 정확히 대응하지 못하므로 프로그래머로서 숫자가 어떻게 기계식으로 표현되는지 이해가 필요하다

1.2 Programs Are Translated by Other Programs into Different Forms

  • Preprocessing phase
  • Compilation phase
  • Assembly phase
  • Linking phase

1.3 It Pays to Understand How Compiliation Systems Work

  • Optimizing program performance
  • Understanding link-time errors
  • Avoiding security holes

1.4 Processors Read and Interpret Instructions Stored in Memory

의도적 수련 맛보기 정도?

회사생활은 올해가 처음이니 분명 신입이긴 하지만 나이는 신입같지 않은 내가
입사 후 7~8개월 동안 공부의 방향과 목표가 세워진 후 많은 통찰을 얻었다.

그런데 딱 요즈음 벌써부터 뭔가 개발 업무의 정형화된 패턴에 약간 지루(?)함이 느껴지던 차에
아주 우연하게 발견한 글: 당신이 제자리 걸음인 이유 : 지루하거나 불안하거나

바로 이거다 싶어 지금 하는 업무에 살짝 맛보기를 도입해 보기로 결정했다.
우리 회사는 현재 JIRA를 가지고 이슈를 등록/해결하고 있는데 JIRA에 자신의 작업 예상 시간 및 작업 내역의 로그를 남기는 기능이 있어 이 것도 함께 활용하기로 했다.

그래서 매번 하나의 이슈를 받을 때마다 다음과 같은 작업대로 진행한다.

  1. 작업 분석 & 작업 예상 소요시간 분석 / 로그
  2. 테스트 계획 수립
  3. 개발 전략 수립
  4. 개발
  5. 테스트 및 검증

간단한 일이지만 내가 해결하는 이슈에 조금 더 제약 조건을 걸고 개발업무 시간을 측정하면서
집중도를 높이고 생산성을 높이는 것을 목표로 잡은 것이다.

이틀 간 해본 결과 일단 작업기록 남기는 재미가 있다.
지속적으로 시도해 보면서 나의 업무시의 느낌을 계속 따라가 보자

결혼 반지를 맞췄네

블로그가 뜸했던 이유 아닌 이유 중 하나는 결혼준비로 정신이 없었기 때문이다.

뭔가 부한 느낌보다는 커플링 느낌과 심플함을 추구하며 여기저기 찾아보고 발품을 살짝 팔아 본 결과 아는 지인이 맞춘 홍대 인근의 샵 스위티 스푼 반지 디자인이 가장 마음에 들어 여기서 하기로 결정

스위티 스푼 인터넷 사이트에서 봤을 때 가장 마음에 들었던 건 “코티 커플링

wedding_ring_3

(홍보해 드리는데 사진 퍼와도 괜찮겠지요? ㅎㅎ url 가져왔습니다.)

코딩할 때 나의 손가락의 부담을 주지 않으면서도 유부남임을 인증할 수 있는 조건을 충분히 갖춘 반지임을 한 눈에 알 수 있어 마음에 쏙 들었다.

인터넷에서 확인한 후 한번 직접 가서 봐도 마음에 들어 두 번째 가서 결정하고 반지를 구매했다.

반지를 맡기기 전에 진열된 녀석으로 사진도 찍어주시네.

무엇보다 흔한 디자인 같지 않아 마음에 든다.

찍어주신 사진으로 봐도 마음에 든다.

곧 찾으러 가자

wedding_ring_3

 

wedding_ring_2

wedding_ring_1

 

 

Java ME 8 & Raspberry Pi 관련 자료 목록

Oracle Java ME 가이드 및 설치파일 (Java ME Embedded and SDK)
http://www.oracle.com/technetwork/java/embedded/javame/index.html

설치가이드 8.0
http://docs.oracle.com/javame/8.0/get-started-rpi/toc.htm

설치가이드 8.1
http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/RaspberryPi_Setup/RaspberryPi_Setup.html?cid=8489&ssid=0#overview

JDK8 & Java ME8 SDK & NetBeans 8.0.1 & NetBeans Plugin 설치

문서
http://docs.oracle.com/javame/developer/developer.html
http://docs.oracle.com/javame/8.0/javame-dev-tool.htm
http://docs.oracle.com/javame/8.0/sdk-dev-guide/toc.htm
http://docs.oracle.com/javame/embedded/embedded.html

넷빈즈 튜토리얼
https://netbeans.org/kb/trails/mobility.html

https://netbeans.org/kb/docs/javame/nb_me8_screencast.html
https://netbeans.org/kb/docs/javame/nb_me_plugins_screencast.html

영상
Webcast: Introduction into Java Micro Edition (ME) 8

Be an Embedded Developer in Minutes Using Java ME Embedded 8

Getting Started with Oracle Java ME Embedded and Raspberry Pi

Raspberry Pi: Developing with Java Embedded Technology

IoT + Java Embedded + Java Card (PlayList)

(참고)
Java SE Embedded Development Made Easy – Part 1 of 2

Java SE Embedded Development Made Easy – Part 2 of 2

관련자료
http://www.i-programmer.info/news/80-java/7268-java-me-8-released-with-a-big-slice-of-raspberry-pi.html
http://electronicdesign.com/embedded/coffee-dessert-java-and-raspberry-pi
http://marioosh.5dots.pl/2014/04/17/installing-java-me-embedded-8-on-the-raspberry-pi.html
http://pi4j.com/

드림팀의 악몽 애자일로 뒤엎기 리뷰

한빛리더스 8기 4번째 미션도서로 선택한 책  “드림티의 악몽 애자일로 뒤엎기“에 대한 리뷰입니다.

14395177215_1993b93173_z

제목에서 알 수 있듯이 기본적으로 “애자일”을 다루는 책입니다. 그동안 피상적으로 애자일에 대해서 들어만 보았을 뿐 자세한 내용을 모르기도 하고, 아직 학생의 신분이기에 프로젝트의 프로세스를 제대로 경험해 본 적이 없는 상태에서 이 책을 읽었습니다.

이 책은 소설의 형식을 빌려서 애자일이 어떻게 프로젝트를 변화시키는지를 보여줍니다. “애자일은 이런 것이다. 스프린트는 무엇이고 스크럼 마스터의 역할은 무엇이다. “와 같은 전달 방식이 아니라 하나의 이야기의 흐름 속에서 자연스럽게 애자일의 개념을 익히도록 도와주는 서술적인 구조입니다.

책의 두께는 조금 있는 듯 하지만, 여유로운 편집으로 넓은 문장 여백을 갖고 있어 출퇴근시  하루 1-2시간 오고가면서 읽으면 1-2일이면 “애자일”스럽게 “애자일”에 대해서 알 수 있습니다.

구체적인 내용은, 애자일을 적용해 왔지만 점점 이상한 방향으로 프로젝트가 흘러가는 “드림팀”이라는 가상의 팀을 두고 “짐”이라는 컨설턴트가 5일 동안 코칭하는 과정을 담고 있습니다.

읽기 시작하면 한 꼭지가 끝날 때마다 “모험은 XX페이지에서 계속”이라는 문구를 만나게 됩니다. 그렇습니다. 이 책은 순차적으로 읽는 책이 아니라 그 때 그 때 상황적 판단에 따라 내용이 여러 갈래로 나뉘어집니다.  저는 처음에 그런 줄도 모르고 읽다가 여러번 “끝”을 만나 다시 돌아가서 다른 선택으로 여정을 계속해 나갔습니다. 혹시라도 잘못된 선택으로 “끝”을 만나더라도 당황하지 말고 다시 돌아가면 “끝”;;

image

책을 다 읽고 나서 뒤 표지를 보니 책의 주제와 구성을 아주 효과적으로 압축해 놓으셨더군요. 저는 뒤 표지를 안 보았더니 중간에 갈림길이 있는 것도 모르고 당황을 했었습니다. 지금까지 본 많은 책의 뒤 표지 중에서 책을 아주 명쾌하게 요약설명해 주는 것 같습니다.

드림팀의 악몽 애자일로 기뒤엎기

이 책은 뒤쪽에 총 4개의 부록을 제공합니다. 첫 번째 부록은 책에서 등장하는 인물의 역할을 설명해주는 Who’s Who인데요. 저도 읽으면서 벤, 로저, 카산드라,  등등 익숙치 않은 영미식 이름의 여러 인물들이 나오니까 자꾸 헷갈려서 다시 돌아가서 누가 누구였는지 확인 했었는데요. 이렇게 명쾌하게 정리된 부록이 있다는 것은 책을 다 읽고 나서 알았습니다.

두 번째 부록은 책에서 코칭을 담당하는 컨설턴트 “짐”이라는 가상의 인물의 링크드인 프로필을 제공하고, 세 번째는 책에서 언급된 애자일 관련 전문 용어 설명이 있습니다.

그리고 이 책의 마지막 네 번째 부록은 깊게 애자일에 대해서 알아보고 싶은 분들을 위한 참고목록을 제공합니다.

책의 구성부터 부록까지 깔끔하고, 충실하게 애자일을 부담없이 입문할 수 있게 해주는 좋은 길라잡이라는 느낌을 받았습니다.

정리하면,
애자일이 무엇인지, 애자일을 프로젝트에 적용하면 무엇을 하고 , 어떤 변화가 생길 수 있는지 알고 싶은 개발자나 기획자 혹은 이런 호기심을 갖고 있는 사람들은 가볍게 읽을 수 있는 책입니다.

통일을 바라는 마음

자려다가 갑자기 감정이 또 폭발을…

대선을 앞두고 있다 보니 북한문제에 대해서도 여러 이야기들이 타임라인을 통해 오고가는 것을 보았습니다. 그런데 조금 안타까운 마음이 드는 글들이 자주 올라와 몇자 적습니다.
nike air max ltd 2
지지하는 후보와 상관없이 한 사람의 부족한 그리스도인으로서,

북한의 인권과 지하교회 성도들의 탄압문제는 공의로서 분명히 적절한 방법으로 북한에 끊임없이 목소리를 낼 필요가 있다고 생각합니다.

다만, 통일 문제에 있어서는 일부 지나치게 앞서가시는 분들이 있어 걱정이 됩니다.

북한통일에 대한 시나리오는 큰 범주로 북한 급변사태에 의한 통일과 점진적 방식의 통일이 있습니다.
Oakley sunglasses Italy
북한 주민들이 받고 있는 인권탄압과 고통을 깊이 공감하시는 분들은 하루라도 빨리 이러한 상태로부터의 회복을 기대하시며 북한 정권이 급변사태에 의해서 무너지기를 위해 기도하시고 계시는 것을 알고 있고 또한 어떠한 의도로 기도하시는 지 충분히 이해합니다.

그러나, 북한의 내부사정(북한의 경제력, 북한 주민들의 생각 등)과 국제정세를 조금만 객관적으로 확인해 보시면 급변사태에 의한 통일이 오히려 일어나지 않기를 위해 기도해야 한다는 것을 알 수 있습니다.
ray ban new wayfarer
물론 역사의 주관자 되시는 하나님께서 어떠한 방법으로 통일을 이루어 가실지 알 수 없기에 두 가지 시나리오 모두에 대해서 대비할 필요가 있다고 생각합니다. 그러나 통일을 준비하는 기본적 자세는 급변사태에 의한 통일이 되어서는 안 될 것입니다.

독일 통일에 있어서, 서독의 그리스도인들이 동독에 들어가 동독의 회복을 위해 많은 역할을 했다고 합니다. 현 독일의 메르켈 총리의 아버지도 서독 출신의 목회자로서 가족들과 함께 통일 후 동독에 들어가 헌신했다고 하구요.
ray ban sunglasses Low Price
우리 남한 그리스도인들 역시 하나님의 때를 기다리며, 샬롬으로서 남북간의 하나 됨을 허락하실 때에 하나님의 심정으로 북녘으로 나아가 그 땅에 하나님의 나라를 선포하고 섬기는 일을 꿈꾸었으면 좋겠습니다.

하나님보다 앞서 나가기 보다, 지금 고통받고 있는 북한 주민들을 위해 애통하는 마음으로 기도하며 우리에게 허락하실 때를 바라보는 믿음을 가집시다.
nike air jordan retro 4
우리 안에 다툼과 분열을 조장하는 것에 휘둘리지 않고 남한 그리스도인들이 한 마음으로 통일을 열망하고 함께 기도하는 간절한 바람을 갖고… 저는 이제 잠을 잡니다. ㅎ

Tie a yellow ribbon round the old oak tree

개인적으로 얼마 전에 공모전을 준비하면서 알게 된 노래이다. 한 재소자가 형기를 다 마쳐갈 즈음 사랑하는 연인에게 자신이 형을 다 마치고 돌아갈 때 자신을 용서해 줄 수 있겠느냐며 편지를 보낸다.  만약 용서해 준다면 그가 들어가는 마을 참나무의 용서의 표시로 노란 리본을 묶어 달라는 내용의 노래이다.
womens ray ban sunglasses

준비했던공모전의 주제는 “한국형 수형자 사회복귀 시스템과 사회인식 변화”였기 때문에 재소자 분들에 대한 사회 인식 변화와 관련된 해외 사례를 찾던 중 싱가폴의 Yellow Ribbon 프로젝트를 알게 되었고 결국 이 노래까지 듣게 되었다. 분명 들어본 적 있는 멜로디. 그런데 이 음악 속에 담긴 내용을 이제서야 알았다.
oakley monster dog sunglasses
우리 사회에도 재소자들에 대한 사회인식 변화가 많이 필요하다. 물론 피해자들을 고려하면, 뭐라 이야기 하기가 참 어려운 부분이다. 그러나 재소자분들만을 위해서가 우리 사회의 안전을 위해서도 재소자들의 인권보호가 필요하다. 우리나라의 범죄율은 미국이나 영국과 같은 국가들과 비교한다면 높은 편은 아니지만, 복지로 유명한 북유럽 국가와 비교하면 높다고도 할 수 있다. 단순히 범죄율을 떠나서 재범을 막고 결국 그들도 우리 사회로 돌아올 이웃이라는 생각이 필요하지 않을까?

화해와 용서의 상징 노란 리본. 우리 마음에 하나쯤 달아두는 관용이 필요한 세상이다.
ray ban sunglasses uk