복's

[ With Claude ] 콘서트 티켓팅 시스템(Phase 1)

나복이 — Sun, 5 Apr 2026 16:10:24 +0900

[ With Claude ] 콘서트 티켓팅 시스템 — Phase 1 회고 (Spring Boot + JPA + TDD)

Overview

목표: 백엔드 아키텍처 학습 프로젝트 Phase 1을 마치며, 설계 결정과 마주한 문제들을 정리한다.
환경:
- Java 21 / Spring Boot 3.x
- JPA + PostgreSQL + Flyway
- JUnit5 + Mockito + TestContainers
사전 준비: Spring Boot 프로젝트 초기 세팅, PostgreSQL 로컬 환경

무엇을 만들려 했는가

나는 백엔드 아키텍처를 단계적으로 학습하기 위한 프로젝트로 콘서트 티켓팅 시스템을 선택했다.
Phase 1의 목표는 기술 스택의 화려함보다 구조를 올바르게 잡는 것이었다.

구현 대상은 6개 도메인, 21개의 유스케이스였다.

도메인	유스케이스
공연장 (Venue)	등록 / 수정 / 삭제 / 조회
공연 시리즈 (ConcertSeries)	등록 / 수정 / 삭제
아티스트 (Artist)	등록 / 수정 / 삭제
공연 (Concert)	등록 / 수정 / 취소 / 목록 조회 / 상세 조회
좌석 (SeatType + Seat)	등급 설정 및 자동 생성 / 목록 조회
사용자 (User)	가입 / 조회 / 수정 / 탈퇴

기능 자체는 복잡하지 않다. 중요한 건 레이어 의존성을 어떻게 잡느냐였다.

Architecture

Presentation → Application → Domain ← Infrastructure

Domain은 Spring, JPA 등 외부 프레임워크에 의존하지 않는다.
Infrastructure가 Domain의 Repository 인터페이스를 구현한다.
역방향 의존은 발생 즉시 수정한다.

domain/
  user/          ← 순수 Java, 프레임워크 의존 없음
  venue/
  concert/       ← ConcertSeries 포함
  seat/          ← SeatType, SeatGrade, Seat

application/
  concert/facade/   ← 멀티 도메인 오케스트레이션
  seat/facade/

infra/
  user/repository/impl/
  venue/repository/impl/
  concert/entity/ repository/
  seat/entity/ repository/

api/
  concert/controller/ request/ response/
  seat/controller/ request/ response/
  ...

설계하면서 내린 결정들

Info 패턴 도입

나는 초기에 Service, Controller에서 JPA Entity를 직접 반환했다.
문제는 곧 드러났다. Entity를 상위 레이어가 직접 참조하면 JPA 어노테이션, 프록시 객체, 지연 로딩 등 Infrastructure 계층의 관심사가 Domain 위로 올라온다.

해결책으로 Info record 패턴을 도입했다.

// Infrastructure 레이어에서만 toInfo() 호출
public ConcertInfo toInfo() {
    return new ConcertInfo(id, title, status, venueId, ...);
}

// Domain/Application 레이어는 Info만 다룸
public ConcertInfo findById(Long id) {
    return concertRepository.findById(id)
                            .orElseThrow(() -> new EntityNotFoundException(CONCERT_NOT_FOUND));
}

Entity는 Infrastructure 안에 갇히고, 상위 레이어는 순수한 Java record인 Info만 본다.

Facade 패턴 도입

Concert 등록 시 Venue 존재 여부, Artist 유효성, 날짜 순서 등 여러 도메인을 조합해야 했다.
이 로직을 어디에 둘 것인가가 문제였다.

Controller에 두면 비즈니스 로직이 Presentation 레이어로 올라간다.
ConcertService에 VenueService, ArtistService를 주입하면 도메인 간 결합이 생긴다.

나는 application/{feature}/facade/ 레이어를 만들고, 멀티 도메인 오케스트레이션은 Facade가 담당하도록 했다.

단일 도메인 CRUD:   Controller → Service (직접)
멀티 도메인 조합:   Controller → Facade → Service들

ConcertSeries 패키지 이동

나는 초기에 ConcertSeries를 독립 도메인으로 설계했다.
구현 중 Concert에 종속되는 개념임이 명확해져 domain/concert/ 하위로 이동했다.
설계는 코드를 짜면서 바뀐다는 것을 체감한 순간이었다.

만났던 문제들

문제 1 — IDENTITY 전략 + orphanRemoval 스냅샷 불일치

Phase 1에서 가장 골치 아픈 버그였다.

증상: Update.success() 통합 테스트 실패. 아티스트를 교체했는데 기존 아티스트가 삭제되지 않고 2건이 남았다.

Expected size: 1 but was: 2 in:
[ConcertArtistInfo[artistId=4, artistName=BTS, role=MAIN],
 ConcertArtistInfo[artistId=5, artistName=IU, role=FEAT]]

같은 트랜잭션 내에서 create() → update() 순서로 호출했을 때 발생했다.

관련 코드 구조

ConcertEntity
  @OneToMany(mappedBy = "concert", cascade = ALL, orphanRemoval = true)
  List<ConcertArtistEntity> concertArtists

ConcertArtistEntity
  @ManyToOne(fetch = LAZY)
  @JoinColumn(name = "concert_id")
  ConcertEntity concert

ConcertEntity.replaceArtists()
  this.concertArtists.clear()   // 기존 아티스트 제거
  this.concertArtists.add(...)  // 신규 아티스트 추가

원인: PersistentBag 스냅샷 + IDENTITY 즉시 INSERT 충돌

Hibernate는 orphanRemoval을 처리할 때 PersistentBag의 스냅샷을 기준으로 삭제 대상을 판별한다.

flush 시: snapshot에 있고 current에 없는 엔티티 → DELETE

문제는 GenerationType.IDENTITY에 있었다.
IDENTITY 전략은 DB의 auto_increment를 사용하기 때문에 INSERT를 실행해야만 PK를 알 수 있다.
그래서 Hibernate는 em.persist() 호출 즉시 INSERT SQL을 실행한다 — full flush 없이.

1. create() 호출
   - em.persist(concert) → INSERT concerts (즉시 실행)
   - concertArtists = PersistentBag(snapshot=[], bag=[])
   - replaceArtists([BTS]):
     - clear() → no-op
     - add(BTS) → cascade PERSIST → INSERT concert_artists(BTS) 즉시 실행
     - bag=[BTS], snapshot=[] ← 스냅샷 갱신 없음 (full flush 아님)

2. update() 호출
   - findById() → L1 캐시에서 동일 엔티티 반환
   - concertArtists는 이미 초기화된 PersistentBag(bag=[BTS], snapshot=[])
   - replaceArtists([IU]):
     - clear() → bag=[], snapshot=[] (여전히 비어있음)
     - add(IU) → cascade PERSIST → INSERT concert_artists(IU) 즉시 실행

3. em.flush() 호출
   - orphan 판별: snapshot=[] vs current=[IU]
   - snapshot이 비어있어 "제거된 orphan 없음" 판정
   - BTS에 대한 DELETE 미발생

4. em.clear() 후 findById()
   - SELECT concert_artists → BTS(MAIN), IU(FEAT) 2건 반환

상태 변화를 표로 정리하면 더 명확하다.

시점	snapshot	bag	DB
create() 후	`[]`	`[BTS]`	BTS 존재
update() clear() 후	`[]`	`[]`	BTS 존재
update() add(IU) 후	`[]`	`[IU]`	BTS, IU 존재
em.flush() 후	`[]`	`[IU]`	BTS, IU 존재 ← 버그

BTS는 full flush 없이 IDENTITY로 즉시 INSERT되었기 때문에 스냅샷에 한 번도 포함된 적이 없었다.
clear() 시점에 snapshot이 비어있으므로 orphan removal은 BTS를 삭제 대상으로 인식하지 못한다.

버그 발생 시 실제 실행된 SQL

INSERT INTO concerts (...)                              -- create()
INSERT INTO concert_artists (BTS, MAIN)                 -- create() IDENTITY 즉시 INSERT
INSERT INTO artists (IU)                                -- artistService.create()
INSERT INTO concert_artists (IU, FEAT)                  -- update() IDENTITY 즉시 INSERT
UPDATE concerts SET title=?, description=? WHERE id=?   -- em.flush()
-- DELETE concert_artists WHERE id=? 없음!!!
SELECT * FROM concert_artists WHERE concert_id=?        -- [BTS, IU] 2건 반환

⚠️ 잘못된 접근: 단방향 @OneToMany + @JoinColumn으로 변경하면 해결될 거라 생각했지만, 근본 원인인 스냅샷 불일치는 동일하게 존재한다. 오히려 단방향은 자식 INSERT 시 FK 없이 먼저 INSERT하고 이후 UPDATE로 FK를 세팅하는 비효율이 추가된다.
-- 단방향으로 변경 시 INSERT 방식
INSERT INTO concert_artists (artist_id, role) VALUES (?, ?)  -- concert_id 없이
UPDATE concert_artists SET concert_id=? WHERE id=?            -- FK 뒤늦게 설정

해결책: update 경로에서 명시적 삭제

orphanRemoval에 의존하는 대신, update 경로에서 기존 아티스트를 직접 삭제했다.

public interface ConcertArtistJpaRepository extends JpaRepository<ConcertArtistEntity, Long> {
    void deleteAllByConcert(ConcertEntity concert);
}

Spring Data JPA의 deleteAllByConcert()는 다음 순서로 동작한다.

SELECT * FROM concert_artists WHERE concert_id=? — 대상 엔티티 로드
em.remove() 개별 호출 — L1 캐시 상태를 DELETED로 갱신하고 DELETE 예약

@Override
public ConcertInfo update(UpdateConcertCommand command) {
    ConcertEntity concert = concertJpaRepository.findById(command.concertId())
            .orElseThrow(() -> new EntityNotFoundException(CONCERT_NOT_FOUND));
    List<ArtistEntity> artists = resolveArtists(command.artists());
    concert.update(command.title(), command.description(), command.seriesId(),
            command.concertDate(), command.bookingStartAt(), command.bookingEndAt());

    // orphanRemoval 스냅샷 문제 우회: 기존 아티스트 명시적 삭제 후 교체
    concertArtistJpaRepository.deleteAllByConcert(concert);  // em.remove() 개별 호출
    concert.getConcertArtists().clear();                     // 인메모리 컬렉션 동기화
    concert.replaceArtists(command.artists(), artists);      // 신규 아티스트 추가
    return concert.toInfo();
}

수정 후 SQL 실행 순서는 다음과 같다.

INSERT INTO concerts (...)                              -- create()
INSERT INTO concert_artists (BTS, MAIN)                 -- create()
INSERT INTO artists (IU)                                -- artistService.create()
-- update() 진입
SELECT * FROM concert_artists WHERE concert_id=?        -- deleteAllByConcert 내부 SELECT
INSERT INTO concert_artists (IU, FEAT)                  -- replaceArtists() IDENTITY 즉시 INSERT
-- em.flush()
DELETE FROM concert_artists WHERE id=? (BTS)            -- deleteAllByConcert em.remove() 실행
UPDATE concerts SET title=?, description=? WHERE id=?
-- SELECT 후 [IU] 1건만 반환 → 테스트 통과

orphanRemoval = true는 그대로 유지했다. 공연 삭제 시 cascade = ALL과 함께 concert_artists가 자동 삭제되는 동작은 보존해야 하기 때문이다.
update 경로에서만 명시적 삭제로 우회하는 방식이다.

문제 2 — Flyway 마이그레이션과 엔티티 불일치

증상: 통합 테스트 전체 실패.

SchemaManagementException: Schema-validation: missing column [created_at] in table [concert_seat_grades]

원인: V7(concert_seat_grades) 마이그레이션 SQL에 created_at, updated_at, deleted_at 컬럼을 빠뜨렸다. V8(seats)에는 seat_type 컬럼을 누락했다.

BaseEntity를 상속하면 자동으로 세 컬럼이 따라온다는 사실을 SQL 작성 시 놓쳤다.

// BaseEntity
private LocalDateTime createdAt;
private LocalDateTime updatedAt;
private LocalDateTime deletedAt;   // soft delete

⚠️ 교훈: 엔티티가 BaseEntity를 상속할 때 Flyway SQL에 반드시 created_at, updated_at, deleted_at을 포함해야 한다. SQL 작성 직후 엔티티 필드와 대조하는 습관이 필요하다.

코드 룰로 정착된 것들

문제를 겪으면서 개인 룰이 하나씩 생겼다.

Enum 비교는 ask-style 메소드로

// Bad
if (concert.status() == CANCELLED || concert.status() == ENDED) { ... }

// Good
if (!concert.isCancellable()) { ... }

Enum에 의미 있는 boolean 메소드를 정의하고, 호출부는 그것을 그대로 쓴다.

메소드 체이닝은 dot 정렬

// Bad
return venueService.findAll().stream()
        .map(VenueResponse::from)
        .toList();

// Good
return ApiResponse.ok(venueService.findAll()
                                  .stream()
                                  .map(VenueResponse::from)
                                  .toList());

선언 / 검증 / 반환 사이 빈 줄

ConcertInfo concert = concertService.findById(id);

if (!concert.isCancellable()) {
    throw new IllegalArgumentException(...);
}

return concertService.cancel(id);

Wrap-up

What I learned:
- GenerationType.IDENTITY와 orphanRemoval을 함께 쓸 때는 스냅샷 불일치를 반드시 고려해야 한다. 컬렉션 전체 교체 로직은 명시적 삭제가 안전하다.
- Flyway SQL 작성 시 BaseEntity 상속 여부를 항상 확인해야 한다.
- 설계는 코드를 짜면서 바뀐다. ConcertSeries 이동처럼, 처음부터 완벽한 설계를 기대하지 않는 것이 오히려 건강한 접근이다.
- Info 패턴과 Facade 패턴은 레이어 의존성을 강제로 지키게 만드는 실용적인 도구였다.
What's next: Phase 2 — 이 구조 위에 Spring Security + JWT + Redis 인증을 얹는다. 지금 만들어진 레이어 분리가 새 기술 스택을 얼마나 깔끔하게 수용하는지가 진짜 검증 지점이다.

[ Life-Log ] 서버 설정 - 도메인 붙이기

나복이 — Wed, 19 Nov 2025 16:14:10 +0900

이전 프로젝트에서 구성해놓은 세팅이 있는데, 새롭게 도메인 하나 더 구매해서 연결하기로 했다.

젠킨스는 이미 설치되어있기 때문에 젠킨스 설치는 패스하고, 새롭게 github 프로젝트 하나 만들어서 초기 스프링부트 프로젝트 하나 올려서 CI/CD 가 제대로 동작 하는지 확인 해야겠다.

443 (https) 는 이전에 Let's Encrypt 이용해서 설정 해놨으니까 이 부분도 패스하고, 프로젝트 세팅 위주로 가야겠다.

                  (외부)
           https://inbok.shop
           https://nabok.shop
                   │
                   ▼
             ┌─────────────┐
             │   NGINX     │   ← Reverse Proxy (80/443 listen)
             └─────┬───────┘
                   │
                   ▼
       ┌─────────────────────────┐
       │ localhost:81 (서비스 A)   │
       │ localhost:82 (서비스 B)   │
       └─────────────────────────┘

[ 프로젝트 생성 ]

일단 새롭게 구매한 도메인이랑 연결할 프로젝트 확인할 수 있게 루트 url 핸들러 가볍게 하나 만들어주고, 서버로 프로젝트 이동 시긴다.

@GetMapping("/")
public String Home() {
    log.info(LocalDateTime.now().toString());

    return "Hello Home !!!" + LocalDateTime.now();
}

로컬에 있는 프로젝트를 내 서버로 옮겨주고

scp 이동할_프로젝트.jar 서버계정@서버IP:서버로이동할경로/파일명.jar

프로젝트 실행

java -jar 파일명.jar

스프링 서버를 올렸는데 접속이 안된다... 잘 생각 해보니 nginx 설정을 안했다.

[ 도메인 연결 ]

기존 도메인(inbok) 은 이미 인증서를 발급 했었는데, 새로운 도메인은 안했으니까 인증서를 발급 해준다.

(나는 sudo 권한을 해놓았음)

certbot --nginx -d nabok.shop

nginx site-available 에 새로운 도메인 서버 설정 추가 (80, 443 포트 서버 블록들 정리)

사실 이렇게만 해줬으면 끝날줄 알았는데....

접속이 안된다...

nslookup inbok.shop

[ 결과 ]
Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
*** Can't find nabok.shop: No answer

확인 해보니까 DNS 가 내 서버를 보고있지 않았는데, 생각을 해보니까 가비아에서 구매하고 바로 적용되는게 아니라서 복싱장에 운동하러 갔다왔다.

2 Hours Later...

이제 nslookup 으로 확인 해보니까 제대로 되어있는걸 확인 했다.

그런데 nabok(새로운 도메인) 으로 접속을 시도해도 inbok(기존에 등록한 도메인) 으로 요청이 들어가는 현상이 발생했다...(???)

sites-enabled 에 새로운 도메인 심링크가 없는 상태여서 nginx 로 nabok.shop 으로 접속해도 443 포트로 등록된게 inbok.shop 밖에 없어서 inbok.shop 으로 계속 이동되는 문제였다.

심링크를 생성하고 나니까 문제가 해결 되었다.

[ ⚠️ 웹 브라우저 접속시 문제점 ]

연결이 비공개로 설정되어 있지 않습니다.
공격자가 www.inbok.shop에서 사용자의 정보를 도용하려고 시도할 수 있습니다(예: 비밀번호, 메시지, 신용카드 정보). 이 경고에 대해 자세히 알아보기 net::ERR_CERT_COMMON_NAME_INVALID

사용자 접속 url 은 www.inbok.shop 인데 nginx 에 server_name 에는 inbok.shop 만 작성 해놓음 (인증서가 호스트를 커버하지 못하고 있음)

server_name inbok.shop www.inbok.shop

이런 형태로 변경하니까 해결되었다.

[ Life-Log ] 홈 서버 세팅

나복이 — Mon, 17 Nov 2025 18:04:45 +0900

사실 이전에 리눅스 공부도 하고, 서버로 사용하려고 미니PC 를 구입한 했었는데, 시간이 지나면서 사용하지 않고 있었다.

https://nashs789.tistory.com/138

홈 서버 구축하기 (Home Server)

서버 PC 구매하기인텔 N100 칩, 램 16, 저장장치 512, 4코어 4스레드 PC 입니다.뭐 공부하려고 이것 저것 하기 위해서 샀는데 윈도우 11이 설치되어 있어서 먼저 OS 부터 밀어줘야 하겠습니다. 부

nashs789.tistory.com

공유기에 할당되는 공인 IP 가 매번 달라지는데 이전에 설정할 때는 DDNS 설정을 하지 않아서 결국 IP 가 변경되서 이전 저장했던 정보랑은 달라져서 접속이 불가능했다.

[ DDNS(Dynamic DNS) 설정 ]

DNS 서버에 IP 가 변경되면 자동으로 업데이트 해주는 역할을 해주는 no-ip 를 이용하기로 했다.

단 한개 DDNS 서비스를 무료로 이용할 수 있기 때문에 서버 한 개만 돌리는 나에게는 딱 필요한 서비스였다.

먼저, 공인 IP 로 외부에서 접근할 수 있도록 포트 포워딩을 진행한다.

포트 포워딩 설정

KT 공유기를 사용하기 때문에 KT 홈 서버에 접속해서 로그인 해주면 되는데, 처음 접속하는 사람들은 기본 ID/PW 가 있는데, 나는 이전에 접속해서 변경했기 때문에 기억이 나지 않는다...

http://172.30.1.254:8899/login.asp

[ IP 주소 - 공인 IP ]

들어가면 바로 공인 IP 확인이 가능하다.

[ 장치 설정 - 트래픽 관리 - 포트 포워딩 설정 ]

확인한 공인 IP 를 적어주고, 외부에서 접근할 포트는 알아서 적고, ssh 접근을 위한 22 포트로 적으면 된다.

ssh 아이디@공인IP

이렇게 먼저 접근해서 확인 해봐도 되고, 키 기반으로 인증을 진행하는 사람은 키 생성, 등록해서 접속 확인해도 괜찮다.

no-ip DDNS 서비스 설정

가입 후 공인 IP 를 등록만 해주면 된다.

[ no-ip ]

Host: 본인이 사용할 호스트 이름 (아무거나)
IPv4: 공인 IP

[ 장치 설정 - 부가 기능 - DDNS 설정 ]

DDNS 서버: noip.com
사용자 ID: no-ip 계정
비밀번호: no-ip 비밀번호
URL: no-ip 에서 설정한 Host

이렇게 설정 해주면 끝이고, 이제 리눅스 서버에서 no-ip 클라이언트 설치 해주면 된다. (난 GPT 도움을 많이 받음)

도메인 달기

매번 공인 IP 를 치고 들어갈 수는 없으니까 도메인 하나 사야서 달아준다.

지금까지 가비아에서 산 500원 짜리 도메인이 몇 개 째인지...

(이벤트로 구매할 수 있는 500원 짜리 도메인 구매까지는 설명이 없어도 누구나 가능할 것 같고)

[ 도메인 관리 - DNS 정보 ]

도메인 연결에서 설정 눌러서 설정 페이지로 넘어가서 레코드에 공인 IP 를 넣고 추가 해주면 된다.

[ DNS 설정 - 레코드 추가 ]

어떻게 확인 할까?

ssh 아이디@도메인

명령어를 통해서 연결해도 괜찮고

Host myhome
	HostName 도메인
	User 서버 아이디
	Port 22
	IdentityFile ~/.ssh/id_rsa

나는 이렇게 rsa 키를 양쪽에 등록하고 ssh myhome 명령어로 간단히 접속 한다.

[ Life-Log ] 프로젝트 소개

나복이 — Mon, 17 Nov 2025 16:17:20 +0900

취미로 복싱장을 다니는데 복싱장 형님들과 디스코드에 매번 운동 일지를 작성하기로 했다.

매번 일지를 작성하는데 복싱 뿐만 아니라 러닝이나 다른 운동도 하고, 매번 다르게 작성하거나 필요한 템플릿을 복사해서 붙여넣는게 귀찮아지기 시작하면서 좋은 방법이 없을까 생각 하다가 집에 마침 놀고있는 홈 서버 전용으로 구매했었던 미니 PC 가 생각나서 시작하게 되었다.

나는 운동이 끝나면 바로바로 작성하고 싶어서 모바일로 보이는 모습도 중요했기 때문에 처음에는 Flutter 나 React Native 도 생각 했었는데, 당장 사용할 기능을 만드는게 먼저인데 MVP 달성을 고려했을 때 러닝 커브가 심해서 할 줄 아는 JSP 를 사용했다. (필요하면 PWA 로 말아서...)

개발기간: 2025.10.22 ~ 2025.11.16
Backend
- Java 17
- Spring MVC
- JPA(Hibernate)
- PostgreSQL
- Swagger
- JUnit5, Mockito
- Docker(Test DB)
Frontend
- JSP
- jQuery
- DataTables
- marked.js
DevOps / Infra
- Jenkins CI/CD
- Home Server Deployment
- GitHub push → Jenkins → Build → Deploy
- Docker(Test Environment)

[ 로그인 - OAuth2 ]

로그인은 Google 만 OAuth2 만 적용 했는데, 모든 방법이 당장 필요하지는 않아서 일단은 `로그인` 이라는 기능에 집중했다.

로그인을 안해도 메세지는 보낼 수 있지만 템플릿을 저장해서 사용하고 싶고, 이력도 모으면 데이터를 가질 수 있어서 가볍게 로그인 기능도 붙여놨다.

[ 로그인 - 모바일 ]

[ 로그인 - PC ]

[ 메인 기능 - 메세지 전송 ]

js 라이브러리 마크다운 파서를 이용해서 메세지를 미리볼 수 있도록 했다.

`$` 파라미터 기점으로보고 input 창을 만들고, 반복되는 파라미터는 저장해서 사용할 수 있도록 하였다.

ex) 나는 복싱 운동하기 전에 줄넘기를 항상 3 세트 하니까 3을 저장한다.

Slack, Discord 채널에 웹훅을 만들고, url 입력해서 버튼 클릭하면 해당 메세지 채널로 보내는 기능이다.

나는 복싱이랑 조깅을 주로 하는데 템플릿을 저장해서 사용하고 있다.

[ 메인 대시보드 - PC ]

[ 메인 대시보드 - 모바일(1) ]

[ 메인 대시보드 - 모바일(2) ]

아래처럼 같이 운동하는 형님들과 어떤 운동을 했는지 작성해서 공유하고 있다.

[ 게시판 ]

기본적인 CRUD 는 필요하다고 생가했고, 내가 만든 템플릿을 공유하면 좋겠다고 생각되어서 만들었는데, 지금 와서 돌아보면 단순히 템플릿을 복사하는 기능이 아니라 템플릿을 가져오는 방법으로 만들었으면 더 좋았을거 같다. (사용은 이게 더 편할듯)

[ 게시판 - PC ]

[ 게시글 - PC ]

댓글이랑 대댓글은 내가 해본적 없는 기능이라서 같이 넣었고, 조회수는 정책을 어떻게 해야하는지 감을 못잡아서 아직은 작업하지 않았다.

마찬가지로 좋아요 같은 기능도 아직은 하지 않았다.

[ 게시판 - 모바일 ]

[ 게시글 - 모바일 ]

[ 이력조회 ]

아직 검색 조건이 적용되도록 하지는 않았는데 일단 가볍게 기존 이력들을 볼 수 있는 페이지도 붙여놨다.

기획이 따로 없다보니까 하다보면 하나씩 생각나서 붙이다 보니까 새삼 기획의 중요성을 느낀다.

[ 마치며... ]

나와 내 주변사람들이 루틴처럼 하는 일을 조금 더 편하게 하자는 의미로 시작 했는데, 마치고 나니까 프로젝트에 내가 신경썼던 부분들을 하나씩 기록 해놓는게 좋을거 같아서 프로젝트 세팅부터해서 하나씩 챕터로 만들어서 기록해갈 예정이다.

다른 프로젝트를 시작하기 전에 기록을 해둬야 까먹지 않을 것 같고, 그 다음 프로젝트 세팅할 때에도 조금 더 편할거 같다.

https://github.com/nashs789/daily-log

GitHub - nashs789/daily-log

Contribute to nashs789/daily-log development by creating an account on GitHub.

github.com

[ 후기 ] 급류

나복이 — Tue, 29 Jul 2025 16:50:40 +0900

[ 급류 - 정대건 ]

※ 책에대한 스포가 있을 수 있습니다.

※ 주관적인 생각 입니다.

[ 서론... ]

이번년도에 들어서 국내 작가들의 소설들을 여러권 읽었는데 좋은 책들이 많이 있다는걸 다시금 느꼈다.

뭐... 한국이 싫어서 외국 도서만 골라서 읽었던건 아니지만 맨 처음 접한 책이 외국 도서이고 가장 좋아하는 작가가 외국인이니 자연스럽게 그렇게 된 것 같다.

'급류' 라는 책 제목만 보면 내용이 짐작은 안가지만 막상 읽기 시작하니 페이지가 술술 넘어갈 정도로 재밋었다.

다 읽고난 지금 제목을 다시 생각해보면 함축적 의미를 담고 있는 단어인 것 같다.

국산 소설이 좋은점은 배경과 인물을 소개할 때 쉽게 연상되어 좀 더 입체적인 등장인물이 자연스럽게 내 머릿속에 만들어지고 그래서 몰입이 더 잘되는 느낌은 있었다.

[ 기억나는 장면... ]

해솔과 도담이 창석과 미영을 찾아 산을 올라가는 장면에서 나오는 갈등이 나는 개인적으로 재밋었다.

[ 도담 ]

이성 통제 불가능
배신감
창석은 아내가 있음

엄마가 병실에 누워있는 상황에서 아빠의 행동에 배신감을 느끼고 창석이 그 댓가를 치뤄야 한다고 생각함

[ 해솔 ]

이성적
두려움
미영은 남편이 없음
상황을 회피하고 싶음
도담이랑 멀어지고 싶지 않음

해솔 입장에서는 남편을 잃은 미영이 안타깝고, 창석을 잘 따르고 좋아함

[ 나 ]

처음에는 창석도 상황이 힘들고 새로운 만남에 그럴만하다고 생각 했으나 나라고 생각하고 읽으니 창석이 상당히 못되고 괘씸함을 느낌

처음에는 해솔의 입장을 이해되는듯 했지만 제 3자가 아닌 입장에서 보니까 이성을 붙잡기 힘들었다.

이렇게 처해진 입장에 따라서 급변하는 이 책을 읽는 내 스탠스가 재미었다.

[ 여러 생각을 하게 만들어주는 글들... ]

해솔의 시계는 멈춰 버렸다.
기계처럼 수업에 출석하고 암기를 하고 시험을 보고 학점을 채우며 아무것도 느끼지 못하는 동안에도 세상은 흘러갔다.

사람이 항상 열심히 살아갈 수 있을까?

모든 사람들이 연인과의 결별이 아니어도 시계가 멈춰본적 있지 않을까?

남자들은 일단 군생활 하면서 자신의 시계가 멈춘적 있을 것이다.

그래도 국방부의 시계는 움직인다고 말할 정도로 개개인의 시간은 멈춘듯이 정말 천천히 간다.

'무언가의 상실이 의욕을 잃게 만들게 되는걸까?' 라는 생각이 불현듯 스쳐 지나가서 다시 한 번 생각하게 되었다.

상실이 삶의 목표와 방향성을 잃게해 망망대해 속에서 그저 떠다니는 상황이 되는게 아닐까 싶었던게 목표를 위해서 노력하다보면 시간이 지나가는줄도 모르고 몰두하게 되는데, 확실히 목표 없는 삶은 항상 지루하고 무력해졌던 것 같다.

해솔이 또한 이러한 시간을 겪으면서 해야하는 것 이외에는 전혀 하지 않고 시간만 보내는 그 시간이 무력한 상황이 제대로 전달 되었다.

나중에 도담가 첫 재회할 때 해솔은 잃어버린 시간이 모두 돌아오는듯한 보상을 받는 기분을 느낀다.

자신이 겪은 일과 비교하며 남의 상처를 가볍게 치부하는 냉소적인 태도는 20대 내내 도담이 극복하려 했던 것이다.

다른 사람들도 자신에게 극복해야하는 태도나 성격을 인지하고 극복하기 위해서 노력하고 있을까 궁금해졌다.

나 또한 이제 30대로서 많은 실수들을 범해왔고 후회와 눈물로 시간을 보냈던 시간이 적지는 않았다.

특히나 고치고 싶었던 중에서

하지 않아도 될 말은 하지말것(침묵을 지키는 방법)
겉모습만보고 상대를 판단하지말것

물론 무수히 많은 안좋은 습관들을 가지고 있지만 당장 기억해서 작성하려고 하니까 기억이 나지 않는다.

특히나 필요하지도 않을 말을 뱉어서 후회한적은 정말 많았고, 아직도 완전하게 통제되지는 않는다.

통제를 해야한다는 강박증은 아니고, 돌이켜보면 해도 상관은 없는 말인데 굳이 말하고나면 뒤늦게 이런말도 했어야했나 싶기는 하다.

[ 책에서 벗어났을 때 내 생각... ]

소설을 몰입해서 읽으면서 주인공 두 사람의 애절한 사랑 이야기에 둘의 인연이자 악연은 지독한 족쇄와 같다고 생각하면서 세상의 주인공은 이 둘이라는 생각을 했었다.

하지만 다른 사람들의 입장인 승우, 선화(도담과 해솔이 재회 했을 때 옆에 있던 연인들) 입장에서 보면 도담과 해솔은 세상의 지뢰같은 사람들 아닌가 싶다.

몇 년을 함께해도 머릿속은 항상 다른 사람으로 가득한데 바로 옆에있는 사람에게는 못할짓이 아닌가 싶어 별로 만나고 싶은 사람은 아닌거 같다.

소설을 읽는 독자들 입장에서야 사연있는 두 사람이지 세상에 사연없는 무덤이 어디 있을까...?

그리고 이제 나이를 먹어서 그런가....

20대 초반에 두 사람이 재회했을 때 술과 담배에 찌들고 손목에 자해 흔적과 클럽을 전전하는 회피형인간인 도담을 약대 다니는 해솔이가 고작 어렸을 때 인연이라는 이유로... 아름다웠던 추억 하나로 그 상황을 다 감내하면서 같이 있는게 바보같아 보였다.

이건 그냥 현대 사회에서 조건부터 보는 찌들은 나의 생각이다...

[ 이 책을 추천하나요...? ]

결론은 엄청 재밋게 읽었다.

나름의 반전들도 있었고, 다음 내용이나 숨겨진 이유를 추측하는 재미도 없지 않았다.

300 페이지의 짧은 내용으로 가볍게 읽기도 좋고, 문체가 담백해서 그런가 읽는데 부담이 하나도 안되었다.

(이유는 모름...이공계라 그런가... 왜 잘 읽혔지)

[ 후기 ] 위버멘쉬

나복이 — Wed, 25 Jun 2025 01:00:11 +0900

[ 위버멘쉬 ]

※ 책에대한 스포가 있을 수 있습니다.

※ 주관적인 생각 입니다.

[ 서론... ]

übermensch 도대체 어떤 단어일까 궁금해서 검색 해봤다.

GD 의 앨범이 나와서 이게 뭔 상관이지 했었는데 가운데 하얗게 쓰여진 `위버멘쉬` !!

위키에 정의된 위버멘쉬의 뜻은 아래와 같이 결국 시련을 이겨내고 성장하는 사람 이라는 것 아닐까 싶다.

위버멘쉬(독일어: Übermensch / 영어: Overman) 는 프리드리히 니체가 삶의 목표로 제시한 인간상이다.
있는 그대로의 모든 것을 긍정할 줄 알아서 고통마저도 자신을 성장시켜 나가는 기회로 받아들이며 외부의 힘이나 절대자에게 의존하기보다 자신의 삶에 집중하며 스스로의 가치를 창조해 내는 자.

책을 읽기 전 부터 자기 개발이 중심이 되는 책이라는 예상이 자연스럽게 된다.

여타 자기개발서와 같이 너무 진부한 내용만 있지는 않기를 바라며 책을 읽기 시작한다.

https://namu.wiki/w/%EC%9C%84%EB%B2%84%EB%A9%98%EC%89%AC

위버멘쉬

파일:friedr_nietzsche.jpg 베르너 호르바스(Werner Horvath) 그림 Friedrich Ni

namu.wiki

[ 여러 생각을 하게 만들어주는 글들... ]

진정 강한 사람은 위로를 기다리지 않는다.
스스로 위로가 될 수 있는 사람이다.

나는 스스로가 위로될 수 있는 사람일까?
항상 자신감 넘치는 모습으로 살아가는 내게 힘든 시련 앞에서 나라는 존재 자체가 위로되며 살아왔나 되돌아보게 된다.

다른 사람이 바라보는 내 모습과는 다르게 나는 생각보다 여리고 감정적인 사람이라고 지금까지도 생각하며 살아오고 있다.
그저 상처가 커지지 않는 법을 익혀서 남들보다 강해 보이고, 자신감 있어 보이는 게 아닐지 생각하고 있다.

나는 지금까지 살아오면서 나 자신을 내가 싫어하는 상황에 밀어 넣고는 했다.
예를 들자면 나는 발표를 정말 못 했고, 지금도 여전히 싫어하기는 한다.
남들 앞에서 발표하면 말이 떨리고, 긴장해서 배가 아프고, 다리가 떨려서 제대로 서 있기도 힘들었던 20대 초반의 시기가 있었다.
그래서 내가 선택한 방법은 적극적으로 발표할 상황을 만드는 것이었다.
자발적으로 손을 들어서 발표할 상황을 만들어서 불편한 상황을 만들어 익숙해지는 것이었다.
지금도 이런 습관이 몸에 배서 불편한 상황이 있으면 극복하기 위해서 그런 상황으로 의도적으로 만들고는 한다.

이런 과정을 거치고 나니 결과적으로 모든 일에 대한 해결책은 나 자신 이었고, 해결책은 내 안에 있다는 사실이 스스로가 위로될 수 있지 않았을까 추측한다.
지금까지 생각은 안 해봤었지만 되돌아보니 이런 과정들이 쌓여서 지금의 결과가 만들어진 게 아닌가 생각하는 좋은 계기가 되었다.

지쳤다면 다시 쉬어도 된다.

진짜 특별한 미사여구 없이 담백한 한마디였지만 오랜만에 큰 위로를 받았다.
사실 요즘 개발자로서 내가 잘하고 있는지 의문이 들던 상황이었고, 그러한 의문들이 쌓이고 괴롭히다 보니 문뜩 다 포기하고 떠나고 싶은 생각이 조금은 들었다.

나는 개발도 좋아하는 것 같은데 내가 여기서 도망가야 할까, 고민 많이 했었고, 이런 생각들의 뿌리는 강박적으로 성장하고자 하는 나의 행동들에서 나왔다는 생각이 들었다.
내 결론은 2~3 개월 공부 하지 않고 그냥 쉬자는 것이었고, 덕분에 나는 하던 것 전부 손에서 내려놓고 아무 목표 없이 푹 쉬었다.

주변 그 누구도 쉬어도 된다는 말은 먼저 해주지 않고, 내 인생을 책임질 수 없다.
그렇지만 나는 이런 담백한 말 한마디가 필요했던 것 같다.

비교로 성장하는게 아니라 비교를 넘어서는 것

가슴이 아리는 한 문장이다.
나는 어릴 때부터 질투심이 정말 많았고, 많은 상황에서 독이 되었다.
질투는 사람을 시기하게 했고, 원치 않았지만, 어느새 내 눈앞에는 색안경이 쓰여서 다른 시선으로 사람들을 바라보게 되었다.
다행인 것은 어느 기점을 지나서 남들과의 비교를 통한 열등감들이 내 성장 동력이 되어서 나를 더 나은 사람으로 만들어 주는 밑거름이 되었다.

하지만 나는 비교를 넘어서는 것 자체는 생각을 해본 적이 없었다.
이미 밑거름을 잘 작용하고 있었기 때문에 더 넘어서는 것에 대한 필요성을 느끼지는 못했었고, 결국 남들과 함께 할 때는 항상 비교가 따라왔고, 비교의 결과는 내 강박적인 성장으로 돌아왔었다.

강박적인 이런 마음들은 가파른 성장 곡선을 그리기에는 정말 좋지만 알게 모르게 사람의 마음을 파먹고 곪게 만든다.
오랫동안 통제하고 성장의 발판으로 이용하고 있었다고 생각했지만 갑자기는 나를 좀먹는 암 같은 존재가 되었었는데 비교를 넘어선다는 이 문장을 곱씹어 봐야겠다.

최근에 사회 풍자 유튜브에 아이에게 식당에서 직원에게 감사 인사를 가르치는 장면이 나오는데 아이는 돈 내고 서비스 받는 입장에서 뭐가 감사한지 이해를 하지 못한다.
아마도 최근 들어서 사람들이 감사에 더 인색해지는 사회를 풍자하기 위한 스토리인 것 같은데 어떻게 보면 또 틀린 말은 아니다.

사람마다 다르겠지만 나는 아직도 아파트 주민들과 인사를 하고 다니고, 아파트 대부분의 이웃들의 얼굴을 알고 있다.
딱히 반가워서 인사 하냐고 하면 그건 아니고, 어릴 때부터 인사하는 게 습관이 되어서 지금까지도 마주치면 빠짐없이 인사를 주고받는다.

반가움 뿐만 아니라 사과, 감사 모든 상황에 대해서 인사를 하게 된다.
나는 가정 교육을 이렇게 받았기 때문에 이게 당연한 행동인 줄 알아 왔었는데, 유튜브를 보면서 가정 환경에 따라서 누군가에게는 간단한 인사말 하나도 이해하지 못하는 행동이라는걸 다시 한번 깨닫게 되면서 내가 살아가는 세상이 세상의 전부가 아니라는 생각을 하게 된다.

복수를 준비 한다는건 상대의 무덤을 파는 동시에 내 무덤도 동시에 함께 파는 일이다.

복수로 타인을 짓밟는게 아니라 감정을 극복해 내면의 힘으로 바꾸어 자유로워 지는게 중요하다.

복수하지 않는건 약해서가 아니라 강한 사람이 가능한 결정이다.

정말 너무 어려운 주제 복수 이다....

탈리오 법칙
하무라비 법전 - 눈에는 눈, 이에는 이

이 말들에 대해서는 전적으로 동의하지만, 용서 하기에는 충분히 강한 사람이 아니라서 나는 반드시 복수를 해야겠다.
상대 무덤과 같이 내 무덤을 파는 게 나쁜 일인가?
복수 뒤에 잠시의 후련한 뒤에 공허함만 남는 건 누구나 공공연하게 아는 사실이다.
그럼에도 나는 나에게 일어난 비극적인 일들이 없었던 것처럼 살아가기에는 한없이 작은 사람이다.

사람들은 누구나 안다.
효를 중시하고, 속세를 멀리하고, 인의를 실천하고, 예를 중시하는 등 지켜야 할 일들을 잘 지켜주면 누구나 공자나 맹자가 될 수 있는데도 누구도 쉽게 실천하지는 못한다.
아는 것과 행하는 건 다른 일이기 때문에 다는 복수라는 것을 알고 있지만, 언젠가 복수할 일이 생긴다면 반드시 행하고 그 뒤 공허함을 온몸으로 맞이하는 결과를 초래할 것 같다.

이러한 생각들은 현대 한국 사회에서 죄를 제대로 심판하지 못하는 사법 체계에 대한 반발심 때문인지는 모르겠는데 언젠가부터 나에게는 이런 사적인 제재가 더 낫다는 생각이 자리 잡게 되었다.

죄짓는 게 더 유리한 사회가 되었는데도 성실함과 정직함이 미덕인 집에서 교육받은 나에게 한순간 30년 인생을 등지고 범죄자가 되는 건 어렵지만 시선만큼은 이미 지금의 사회 체계를 부정적으로 바라보고 있다.

[ 이 책을 추천하나요...? ]

아무래도 니체의 사상을 베이스로 현대적으로 재해석한 책이기 때문에 좋은 인용구들이 많이 있었습니다.
엄청 진부하지는 않지만 조금은 과하다는 생각도 조금 들었지만, 자기계발서의 본질을 생각했을 때 살아가면서 놓치고 잘 실천하지 못하는 부분들을 다시 한번 생각 해볼 수 있는 시간을 갖기에는 더없이 좋은 책이라고 생각됩니다.

블로그에 전부 적지는 않았지만, 위에 인용한 문장 말고도 좋은 말들이 많았지만 다 적는 건 조금 많아서 마음에 드는 것들로 선별해서 작성했습니다.

어제의 '당연함' 이 오늘의 '꼰대 마인드' 로 불리기도 한다.

읽다 보면 해석하기에 따라서 조금은 올드한 꼰대 같다는 생각도 찾아올 수 있다고 생각은 되었지만 그 정도는 읽는 사람이 시대적 배경을 고려해서 읽으면 크게 문제가 될 건 아니라고 생각이 됩니다.

다른 관점으로 보면 그런 올드함조차 누군가에게는 큰 깨달음을 줄 수도 있을 것 같다는 생각도 갑자기 드네요.
꼭 읽어야 한다고 생각은 안 되는데 자기개발서를 찾고 있다고 하면 이 책이 좋은 선택이 될 수 있을 것 같습니다.

[ 후기 ] 모순

나복이 — Tue, 3 Jun 2025 01:17:29 +0900

[ 모순 - 양귀자 ]

※ 책에대한 스포가 있을 수 있습니다.

※ 주관적인 생각 입니다.

[ 서론... ]

나는 이 책을 10 년 전에 한 번 읽었었다.

읽은걸 기억 못 하는 책도 많지만 이 책은 기억하고 있는게 20살이 되고 내일로 기차여행을 떠날 때 기차 안에서 읽을 책으로 이 책을 선택 했었다.

그 때 당시에는 나는 책의 'ㅊ' 도 몰랐고, 우연히 어떤 유튜버가 읽어주는 줄거리 내용을 통해서 이 책을 읽기로 결심하게 되었다.

그 유튜버의 목소리가 정말 이뻤다고 기억하는데 당연히 누군지 기억은 나지 않는다.

나는 이 책을 여행하는 동안 이동할 때 마다 그리고 숙소에서 읽었고, 내 기억으로는 책을 읽다가 눈물을 흘리면서 몰입했던 기억이 있다.

그런 기억 덕분에 이번에 읽을 때에는 왜 울었을까 생각 하면서 읽을 수 있었던게 또 하나의 재미 포인트였다.

[ 여러 생각을 하게 만들어주는 글들... ]

수치스러운 기억이 누군가에게는 재미있는 추억으로 남아있다는 것

나이를 먹고 나서는 조금은 무섭게 다가오는 말 이었다.

나의 우스꽝스러운 모습이 누군가에게 웃음 거리가되고 추억이 되는게 당연할 수 있다.

하지만 자연스러운 상황이 아니라 누군가에 입에서 부터 시작하는 인위적인 상황이 상대에게 상처를 입을 수 있다는 당연한 이치를 나는 너무 늦게 깨달아 버렸던 것 같다.

알게 모르게 의도하지 않고도 내가 상처 주었던 사람들이 있음을 나중에 알고 나서는 조심하게 되었지만 아직도 조심하고 있는지 확신 하지는 못하고 있다...

소설에 나오는 안진진 어머니와 이모는 소설의 끝 까지 계속해서 비교 당하며 어머니의 처량한 모습이 이모에게는 그저 순수한 재미가 되는데, 그 사이에 안진진도 그리고 비교 당하는 어머니도 내가 글을 읽는 동안 편치는 않았다.

이 사랑을 멈추라고 통고하지 않았기 때문에 내게는 대답의 의무가 있었다.

안진진의 남자친구 중 한 명인 나영규가 청혼 했을 때 안진진의 생각 이었다.

내가 놀랐던 건 두 명의 남자친구를 사귀는 안진진이 생각보다 진지하고 책임감 있다는 것이었다.

물론 두 명의 남자친구부터... 생각은 해봐야 하는 부분인데 나는 개인적으로는 10년 전 이 책을 읽을 때나 지금 읽을 때나 크게 안진진의 양다리에 불편함은 못 느꼈다. (물론 때려 죽여도 모자라지만)

일단 소설이기도 하고 그 당시 배경을 생각 했을 때 지금보다 사생활에 대해서 개방적이지 않았기 때문에 저런 상황이 많지 않았을까 하는 생각을 하니 크게 불편하지는 않았다. (물론 절대 반대지만 소설로만 보자면)

그리고 책 자체가 읽기 편해서 그런지 내용 자체가 거북하지 않았다.

다른 책과 비교 해보자면 `채식주의자 - 한강` 에서 영혜와 형부 사이가 훨씬 더 읽기 불편 했었다.

여튼 문제가 생겼을 때 회피하지 않고 하나씩 해결해가는 안진진 그리고 안진진 어머니가 삶을 대하는 태도 자체가 마음에 들었던 것 같다.

추억 속의 아버지를 사랑하는 마음이 절정에 다다랐을 때
현실 속의 내 아버지는 가장 장인한 방법으로 내 추억을 희롱했다.

떠돌아 다니던 아버지가 중풍과 치매로 다시 집에 돌아왔을 때 안진진의 생각 이었다.

내가 10년 전 읽었을 때에는 나에게 누군가가 내 추억을 희롱했다라고 말할만한 기억이 없었는데 이제는 있어서 조금 새로웠다.

관계는 끊겼었지만 같이 있었을 때 정말 좋은 기억들을 만들어준 사람이 다시 연락 해왔을 때 연락을 무시하지 않았었고, 같은 이유로 다시 그 사람을 밀어냈을 때 나는 이와 같이 생각 했었다.

떠나 보낼 때 좋았던 추억들이 이제는 더 이상 좋은 추억으로 간직하지 못 할거 같다고 문자로 전달했던 기억이 난다.

좋은 기억마저도 시간이 지난 후 누군가에 의해서 사라질 수 있다는 신기한 경험 이었다.

안진진과 이모의 각별한 사이는 소설속에서 계속해서 묘사된다.

자기 자식을 더 사랑하는게 당연한 것인데도 불구하고 진심으로 미안해하는 이모의 말이 가슴 아팠고, 그 말에 눈물 흘리는 안진진이 가여웠다.

이모에게 가장 필요 했던 안진진과 가끔은 이모가 엄마였으면 하는 안진진에 대해서 생각할 수 있는 부분이었다.

'네가 좋아하는 이모' 라는 정도는 향기를 담을 줄 아는 사람이 이모였다.

이 부분 또한 이모와 안진진의 사이에 대해서 생각할 수 있는 부분 이었는데

마지막 순간에도 남편도 자식도 아닌 안진진에게 장문의 편지를 남기는 이모와 고작 편지의 시작에서 글에도 작은 향기를 담을 줄 아는 이모의 모습이 보이지 않아서 고민하는 안진진의 모습이 나는 애틋하게 느껴졌다.

[ 그 외...? ]

나와 이모

나는 이모에게 나를 투영 하면서 책을 읽어 나갔다.

이모가 흔히들 말하는 대가리 꽃 밭 같이 철 없는 스타일의 인물로 나오는데 이모부와의 결혼 생활이 나는 새장 속 새라는 생각이 많이 들었다.

나는 새장 속 새와 같은 상황은 아니지만 이모의 숨 막히는 결혼 생활을 공감할 수 있었기 때문에 이모에게 조금 더 마음이 갔었던 것 같다.

그래서 나는 이모의 선택을 이해할 수 있었고 어느정도 예상 했었기 때문에 마지막 반전에 대해서는 크게 놀라지는 않았다.

가난

우리집도 크게 부유하지 않았고 내 기억 속에서는 사실 가난 했다고 생각하며 자랐다.

다만 가난함을 덮을 정도의 부모님의 성실함 덕분에 가난을 모르고 자란게 아닌가 지금까지 생각 하면서 답은 못 내고 있었다.

그런 이유 때문에 안진진 가족의 끝 없는 가난의 늪이 마음을 힘들게 했었다.

심지어 성실함을 갖춘 안진진과 어머니를 끝 없이 방해하는 아버지와 안진모(동생) 덕분에 타의적인 가난함에서 벗어나지 못하고 가족이 서로의 족쇄가 되는 모습에 나는 숨이 막혔다.

[ 이 책을 추천하나요...? ]

책을 읽으면서 모순이라는 단어에 대해서 계속해서 생각 했었는데 모순이라고 말할만한 내용이 책 속에 정말 많이 녹아있었다.

그래서 내린 결론은 그냥 '삶' 그 자체가 모순이라는 말을 하고 싶지 않았을까 싶다.

어쩌면 책의 제목은 이 책을 쓴 다음나중에 짓지 않았을까 라는 생각도 했었다.

책 자체는 정말 술술 읽혀서 페이지 넘기는지도 모르고 읽었다.

내용 자체도 크게 자극적이지 않으나 다음 내용이 궁금하고, 기승전결이 나는 완벽하다고 생각했다.

아무것도 모르는 나도 책 완성도 자체가 높다는 생각을 많이 했다.

내가 마지막으로 읽은게 10년 전인데 아직도 이 책이 사람들에게 읽히고 있는걸 보면 다른 사람들에게도 좋은 책으로 소개되고 있는게 아닐까?

[ 후기 ] 침묵을 배우는 시간

나복이 — Wed, 2 Apr 2025 01:35:41 +0900

[ 침묵을 배우는 시간 - 코르넬리아 토프 ]

※ 책에대한 스포가 있을 수 있습니다.

※ 주관적인 생각 입니다.

[ 서론... ]

책 제목만으로 끌린건 정말 오랜만이다.

특히 독서 모임에서는 좋은 책만 소개하려고 하다 보니까 베스트 셀러 위주로 혹은 화재를 몰고 왔던 책으로 선정 했었는데, 오랜만에 내가 마음 가는 책으로 선정 했고, 반응도 나쁘지 않았다. (휴.. 다행)

나는 말이 정말 많았고, 사실 아직도 투머치 토커일 때가 많다.

다만 이제는 듣는 역할도 자처해서 할 수 있는 수준이 되었지만 아직도 침묵을 잘 이용 하는게 쉽지 않다고 생각되었는데 마침 이 책을 읽게 되었다.

첫 사회에 나왔을 때에는 말하지 않아도 될 정보도 다 말해서 난처했던 적이 나는 많았고, 그럴 때 마다 집에와서 뜬 눈으로 누워서 후회 하고는 했었던 기억들이 떠올르는 책 이름이라 선택 했을지도...

[ 여러 생각을 하게 만들어주는 글들... ]

누군가에게 동기를 부여하고 싶을 때 우리는 열심히 떠든다.
제아무리 좋은 말로 떠들어봐도 외부에서 온 동기는 효력이 약할 수 밖에 없고, 지속력도 약하다.

누구나 한 번은 경험했을만한 내용 아닌가?

나는 부모님의 걱정 섞인 조언이 잔소리로 들렸던 경험이 생각 났다.

경험에서 나온 조언들이 그 당시에는 나에게 귀찮은 소음 이었고, "내가 알아서 해" 라는 말은 민망할 정도로 아무것도 알아서 하지 못 하고 후회한 경험이 있는 나는 있다.

또 강한 동기부여는 어디서 왔을까?
나는 군 입대 전에는 독서는 해본적 없었고, 공부하는 습관 또한 있지 않았지만 이제는 항상 책을 끼고 살고 있으며, 퇴근 후에도 꾸준히 공부하는 습관이 생겨 버렸다.

이런 습관들은 누군가가 나에게 강요해서 생겼을까?

아니다 내가 필요성을 느끼고 스스로 시작했다.

물론 침묵이 무슨 상관일까 싶지만 이런 중요한 결정들은 보통은 충분한 생각을 갖을 수 있었던 침묵 뒤에 왔었다고 생각한다.

자네가 팀장이고 내가 자네와 같은 실수를 했다면 나에게 뭐라고 하겠나

나는 신입 때 부터 항상 궁금했던 부분이 아래 사람을 대하는 태도였다.

윗 사람을 대하는건 내 기준에서는 항상 쉬웠던게 고등 학생 때도, 대학생 때에도, 군일 일 때도 항상 존중해야할 윗 사람은 언제나 존재했다.

물론 아랫 사람도 항상 있었지만 아랫 사람에 대한 예절 같은건 배운적 없었다.

그리고 이렇게 입장을 바꾸어 하급자의 생각을 묻는 것 자체가 상대방에 입장을 헤어려주면서 존중을 보여주는 모습이 아닌가 싶다.

누군가를 몰아 세우기 보다는 내 과거를 생각하며 잠시의 침묵과 함께 내 입장을 정리할 시간을 갖을 수 있는 사람이 되고 싶다.

당신이 아는 것은 중요하다
하지만 당신이 모르는 것은 더 중요하다

예측 불가능한 일은 내게 없는 지식으로부터 온다.

이미 내가 아는 것은 내가 갖고있는 지식으로 대처가 가능하다는 말이다.

침묵하는 시간 없이 장광하게 떠드는 사람은 새로운 지식에 대한 기회를 놓치기 쉽다.

결과적으로 외부 변화에 다른 사람들 보다 취약하게 된다.

내 지식을 남들에게 나눠주는 시간도 좋지만 침묵을 통해서 남들의 지식을 얻는 시간도 중요하다.

인간 사회도 항상 말만하는 사람보다 들어주는 사람의 중요성에 대해서 강조하는 이유도 이러한 이유도 있지 않을까?

항상 두려움은 무지에서 왔던 것 같다.

첫 경험은 무서웠지만 두 번째는 이미 왔던 길이라 쉬웠고, 그 뒤로는 익숙해진 길을 편하게 걸어왔던 것 같다.

본능대로 행동한다면 동물과 다를 바 없다

외부 자극에 침묵 없이 즉각적인 반응으로 응수 한다면 이성이 아닌 본능을 따르는 결과를 갖는다.

내가 가장 심각하게 고민 했던 부분인데 즉각적인 반응으로 이득을 취한적은 단 한번도 없었던 것 같다.

나의 전형적인 '지나고 나서 후회한다' 패턴이었다.

많이 고쳐지긴 했지만 아직 갈 길은 멀었다.

여전히 욱하는 성격은 다 죽이지 못해서 살아있어 이성적인 판단을 마비 시키는 순간이 한 두번이 아니다.

이제는 항상 즉각적인 반응을 하지는 않는데, 요즘은 가끔 바로 반응이 오지 않으니 재미가 없다는 말도 가끔씩 듣는다.

속으로 생각하는 내 모습이 무반응한 모습으로 보이는 것 같다.

말을 배우는데 2년, 침묵을 배우는데는 평생

어니스트 허밍웨이의 명언이 책에서도 나온다.

내가 처음 침묵을 인지한 순간부터 지금까지 침묵을 잘 이용 하려고 해봤지만 아직도 침묵은 나의 무기가 되지 못했다.

아직 까지도 이성적인 판단 보다 행동과 반응이 먼저 나가는 나에게는 침묵을 지키는 건 평생의 숙제로 느껴져서 이 명언이 남 일 같지 않게 느껴졌다.

나는 어디로?

정적을 피해서 도망다닌 대가로 정체성을 잃었다.

시끄러운 세상 속에서 우리는 감정을 잃었다.

행복은 논리적인 이성이 아닌 감정이다.

행복은 인지 하는게 핵심이 아닌 정서를 느끼는데서 시작하기 때문이다.

나의 경우에 이제는 밥을 먹을 때 유튜브를 틀어놓지 않으면 심심해서 버티질 못하고, 조용한 공간에서도 노래라도 틀어 놓는다.

어떠한 소리도 없는 공간에서 조용함 그 자체를 느꼈던 기억이 이제는 가물가물하다.

내가 살고있는 시끄러운 이 세계에서 한 발자국 떨어져서 침묵 속에서 지켜보는 것 만으로도 많은걸 느낄 수 있지 않을까 하는 마음에 적어본다.

불평은 목표를 달성할 때까지 멈추지 않는다

나는 침묵만의 문제는 아니라고 생각 하는데 불평에 대한 이 말은 극히 공감하기 때문에 적어본다.

어떻게 보면 비언어적인 표정과 제스처가 문제일 수 있고, 말하는 화법이 문제일 수 있다.

하지만 내 생각에는 이게 과연 해결책일까 싶다.

왜냐...? 나는 받아주지 않기 때문에.. 솔직히 이제는 너무 피곤하다.

나는 이 채워지지 않는 욕망의 끝이 정해져 있다는 것에 공감해서 이야기 해보고 싶었다.

[ 이 책을 추천하나요...? ]

당연히 책을 읽는다고 바로 대화를 잘 하는 사람이 될 수도 없고

욱하는 성질을 줄일 수 없고

극적인 상황에서 갑자기 이성적인 사고회로로 상황을 급변하게 만들 수는 없다.

하지만 중요한 것은 침묵에 대한 인지이고, 언젠가 한 번은 대화중에 혹은 필요한 상황에 생각나서 침묵을 통해서 조금 더 괜찮은 결과를 만들어 낼 수 있는 가능성이 생긴게 아닐까?

침묵은 내가 사회 생활을 시작한 이례로 인생을 살면서 얻고 싶었던 스킬 이다.

많은 순간을 후회하고 나서도 고치지 못했었고, 주워담지 못 하는 실수들을 겪고 나서 뼈에 새겨서야 어느정도 절제하기 시작했다.

(안전 수칙은 피로 쓰이는데, 내 피는 묽지 않은지 너무 쉽게 지워져서 항상 고민이었다.)

책 초반부에 비해서 중, 후반은 같은 내용을 반복하는 감이 없지는 않지만 내 기준으로 다행히도 지루하게 질질 끄는 흐름은 아니라서 나와 같은 고민을 한 번이라도 했보았다면 책을 읽는 것을 추천한다.

[Week37] 스터디 회고

나복이 — Wed, 12 Mar 2025 00:19:59 +0900

슬슬 프로그래머스 LV2 문제 다 풀었지 싶어서 확인 했더니 아직도 52문제나 안풀었다...

LV3 넘어가긴 해야하는데, 지금도 간간히 풀긴 하지만 주로 푸는 문제는 LV2 라서 고민이 있다.

스터디 인원들이 슬슬 고착화 되면서 난이도는 계속해서 올라가는 기분은 들어서 문제 난이도가 올라간다고 쉽게 스터디가 와해되지는 않을 것 같은 느낌적인 느낌?

LV2 - 지게차와 크레인
G2 - 칵테일
G5 - 1로 만들기 2

칵테일 문제는 개인적으로 조금 오랫동안 고생하고 결국 다른 풀이도 참조해서 풀었다 ㅎㅎ..

[ 내 문제 풀이 with Java ]

지게차와 크레인

그래프 문제인데 백준의 치즈나 빙산 같은 문제와 유사한 풀이이다.

삭제해야하는 노드를 바로 삭제하면 동작중인 로직에 영향을 주기 때문에 따로 저장 했다가 로직이 끝난 후에 일괄로 삭제 처리 되도록 구현 했다.

기본적인 그래프 문제라서 크게 어렵거나 시간을 사용하지는 않았다.

이제는 기계적으로 풀 수 있는 유형의 문제

/**
 * Author    : Lee In Bok
 * Date      : 2025.03.02(Sun)
 * Runtime   : 22.95 ms
 * Memory    : 94.9 MB
 * Algorithm : Graph Search
 */
package com.year2025.Week37;

import java.util.LinkedList;
import java.util.Queue;

public class LV2_388353 {
    public static void main(String[] args) {
        Solution sol = new Solution();

        System.out.println(
                sol.solution(
                        new String[]{"AZWQY", "CAABX", "BBDDA", "ACACA"},
                        new String[]{"A", "BB", "A"}
                )
        );
    }

    static class Solution {

        public static int N;
        public static int M;
        public static int ans;
        public static int[] dx = {0, 1, 0, -1};
        public static int[] dy = {1, 0, -1, 0};

        public int solution(String[] storage, String[] requests) {
            N = storage.length;
            M = storage[0].length();
            Node[][] board = new Node[N + 2][M + 2];
            ans = N * M;

            for(int i = 0; i < N; i++) {
                String[] container = storage[i].split("");

                for(int j = 0; j < M; j++) {
                    int x = i + 1;
                    int y = j + 1;

                    board[x][y] = new Node(x, y, container[j]);
                }
            }

            for(String request : requests) {
                String command = Character.toString(request.charAt(0));

                if(request.length() == 1) {
                    useForkLift(board, command);
                } else {
                    useCrane(board, command);
                }
            }

            return ans;
        }

        public static void useForkLift(Node[][] board, String request) {
            Queue<Node> q = new LinkedList<>();
            // 제거 목록을 임시 저장한다. (이유: 로직이 동작하는동안 컨테이너를 빼면 다른 컨테이너가 영향을 받음)
            Queue<Node> shipOutList = new LinkedList<>();
            boolean[][] visited = new boolean[N + 2][M + 2];

            q.add(new Node(0, 0));
            visited[0][0] = true;

            while(!q.isEmpty()) {
                Node curNode = q.poll();

                for(int i = 0; i < 4; i++) {
                    int nextX = curNode.x + dx[i];
                    int nextY = curNode.y + dy[i];
                    
                    if(isValid(nextX, nextY) && !visited[nextX][nextY]) {
                        visited[nextX][nextY] = true;
                        Node nextNode = new Node(nextX, nextY);
                        
                        // null(= empty)
                        if(board[nextX][nextY] == null) {
                            q.add(nextNode);
                        } else if(board[nextX][nextY].isShipOutTarget(request)) {
                            shipOutList.add(nextNode);
                        }
                    }
                }
            }

            // 제거 목록으로 저장된 컨테이너 좌표 삭제
            while(!shipOutList.isEmpty()) {
                Node target = shipOutList.poll();

                ans--;
                board[target.x][target.y] = null;
            }
        }

        // 크레인은 지형적인 영향을 안받기 때문에 컨테이너 전부 제거
        public static void useCrane(Node[][] board, String request) {
            for(int i = 0; i < board.length; i++) {
                for(int j = 0; j < board[i].length; j++) {
                    if(board[i][j] != null && request.equals(board[i][j].val)) {
                        ans--;
                        board[i][j] = null;
                    }
                }
            }
        }

        public static boolean isValid(int x, int y) {
            return 0 <= x && x < N + 2 && 0 <= y && y < M + 2;
        }
    }

    static class Node {
        int x;
        int y;
        String val;

        public Node(int x, int y) {
            this.x = x;
            this.y = y;
        }

        public Node(int x, int y, String val) {
            this.x = x;
            this.y = y;
            this.val = val;
        }

        public boolean isShipOutTarget(String val) {
            return this.val.equals(val);
        }
    }
}

칵테일

혼자서 풀 수 있을거 같아서 혼자서 전전긍긍 하다가 최소공배수, 최대공약수 이용하는 문제라는걸 알게 되었다.

그래프 문제라는건 쉽게 알 수 있었는데, 그래프 내에서 각 노드간의 비율을 조율하는 과정이 쉽게 다가오지 않았었다.

특히 그래프 탐색을 시작할 때 비율이 정해져 있으니 임의의 노드로 시작할 때 최소 공배수로 값을 세팅하는 부분에서 나는 생각하지 못 했기 때문에 쉽게 풀지 못 했다.

/**
 * Author    : Lee In Bok
 * Date      : 2025.03.08(Sat)
 * Runtime   : 120 ms
 * Memory    : 15820 KB
 * Algorithm : Graph, Math
 */

package com.year2025.Week37;

import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.List;
import java.util.StringTokenizer;

public class G2_1033 {

    public static List<Node>[] graph;
    public static boolean[] visited;
    public static long[] ratio;

    public static void main(String[] args) throws IOException {
        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
        StringTokenizer st;
        int N = Integer.parseInt(br.readLine());
        long lcm = 1;
        graph = new ArrayList[N];
        visited = new boolean[N];
        ratio = new long[N];

        for(int i = 0; i < N; i++) {
            graph[i] = new ArrayList<>();
        }

        for(int i = 1; i < N; i++) {
            st = new StringTokenizer(br.readLine());

            int a = Integer.parseInt(st.nextToken());
            int b = Integer.parseInt(st.nextToken());
            int p = Integer.parseInt(st.nextToken());
            int q = Integer.parseInt(st.nextToken());

            // 최소 공배수 구하기 (각 노드간의 비율을 맞추기 위해서 필요)
            lcm *= p * q / gcd(p, q);
            graph[a].add(new Node(b, p, q));
            graph[b].add(new Node(a, q, p));
        }

        // 찾고자 하는 N 의 재료를 시작점으로 최소 공배수를 갖고 그래프 탐색을 통해서 노드간 비율에 따라서 조율
        long ggcd = ratio[N - 1] = lcm;
        dfs(N - 1);

        // 조율된 값을 최소 값으로 만들기 위해서 최대 공약수를 구한다.
        for(int i = 0; i < ratio.length; i++) {
            ggcd = gcd(ggcd, ratio[i]);
        }

        // 최대 공약수로 값을 나누어 출력
        for (int i = 0; i < N; i++) {
            System.out.print(ratio[i] / ggcd + " ");
        }
    }

    public static void dfs(int node) {
        visited[node] = true;

        for(Node next : graph[node]) {
            if(!visited[next.b]) {
                // 노드 사이의 정해진 비율에 따라서 값 조율
                ratio[next.b] = ratio[node] * next.q / next.p;
                dfs(next.b);
            }
        }
    }

    public static long gcd(long n1, long n2) {
        return n2 == 0 ? n1 : gcd(n2, n1 % n2);
    }

    static class Node {
       int b;
       int p;
       int q;

        public Node(int b, int p, int q) {
            this.b = b;
            this.p = p;
            this.q = q;
        }
    }
}

1로 만들기2

큐랑 스택을 이용해서 문제를 풀었는데, 풀고 나니까 그래프 문제 같기도 하다.

그래프 문제를 풀 때 큐랑 스택을 자주 이요하기도 하니까 그렇게 느끼는 건가

중요한건 1에 도달하는 순간 왔던 경로를 되돌아갈 수 있는 코드를 만들어야 하는 것 이었고, 이런 비슷한 유형을 풀었던 경험이 있어서 배열에 각 노드 이전 노드를 기록 해두었다.

/**
 * Author    : Lee In Bok
 * Date      : 2025.03.04(Tue)
 * Runtime   : 180 ms
 * Memory    : 21672 KB
 * Algorithm : Queue, Stack
 */
package com.year2025.Week37;

import java.util.*;

public class G5_12852 {

    public static Queue<Integer> q = new LinkedList<>();
    public static int[] seq;

    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        Stack<Integer> stack = new Stack<>();
        StringBuilder sb = new StringBuilder();
        int N = sc.nextInt();

        seq = new int[N + 1];

        search(N);

        int temp = 1;
        stack.push(temp);

        // 역추적: 목표로 하는 1 번 배열방에서 이전 각 요소로 저장된 이전 노드 번호를 타고 간다.
        while(temp != N) {
            stack.push(seq[temp]);
            temp = seq[temp];
        }

        // 경로 사이즈 출력
        System.out.println(stack.size() - 1);

        while(!stack.isEmpty()) {
            sb.append(stack.pop()).append(" ");
        }

        // 경로 출력
        System.out.println(sb);
    }

    public static void search(int N) {
        q.add(N);

        while(!q.isEmpty()) {
            int cur = q.poll();

            if(cur == 1) {
                break;
            }

            if(cur % 3 == 0) {
                addAndCheck(cur, cur / 3);
            }

            if(cur % 2 == 0) {
                addAndCheck(cur, cur / 2);
            }

            addAndCheck(cur, cur - 1);
        }
    }

    // 경로 추적을 위해서 seq 배열에 이전 노드의 번호를 저장 후 다음 노드를 큐에 담는다.
    public static void addAndCheck(int cur, int next) {
        if(seq[next] == 0) {
            seq[next] = cur;  // 다음 숫자에 이전 숫자 기록
            q.add(next);
        }
    }
}

[ 아쉬운 점...]

칵테일 문제가 혼자서 풀 수 있을 것 같은 느낌이 진짜 물씬 풍겨서 계속 잡고 있었는데, 결국 다른 풀이를 보고 말았다.

다른 풀이를 보고 푼 것은 아쉽지 않았는데, 오랫동안 잡고 있다가 포기 하니까 아쉬웠다.

[ 2025 ] 2월 회고록

나복이 — Wed, 5 Mar 2025 01:21:06 +0900

항해

항해 교육과정 8 주차 부터 과제 미수행...

사실 중요한 부분은 8 주차부터 인데, 이미 이전 과제부터 불만들이 있었고, 내 시간 쪼개서 하는건데 과제 범위가 내가 생각하는 것과 항상 달라서 시간을 배로 쓰는 상황이 생겼다.

물론 사람들과 소통 하면서 했으면 이런 상황이 생기지 않았을 텐데, 역시 가장 문제점은 내가 많은 시간을 할애하지 못 했다는 점이다.

운동 갔다오면 평일에 투자하는 시간이 고작 3 시간이라서 삽질 한 번 잘못하면 타격이 꽤나 컸다.

과제를 안했다고, 수강을 안한건 아니지만 결국 도망치는 선택을 했다.

알고리즘 스터디

정확하게 기억은 안나지만 2월 동안 3명은 추방 했던 것 같다.

새해 계획 시즌이라 어떻게 보면 당연히 예상되었던 부분이라 크게 놀랍지는 않지만 역시 사람 관리가 제일 힘들다.

스터디 난이도는 티가나지 않지만 조금씩은 올라가는 느낌이다.

다음에 스터디원 구할 때에는 난이도를 조금 조정해서 같이 풀 수 있는 사람들 위주로 구인 해봐야겠다.

취미

여전히 독서 모임으로 한 달에 한 권씩 읽고 있다.

아쉽게도 독서모임 이외의 책은 이제 읽고있지 않다.

사실 읽으려고 사놓은 책이 10권은 대기 중인데... 당근 거래로 싸게 사왔는데 역시나 시간을 핑계삼아 도망 다니는중

운동으로는 복싱을 여전히 하고 있다.

벌써 1년이 다 되어 가는데, 내 취향에 잘 맞는거 같아서 아직도 열심히 하는중이다.

다이어트도 겸사겸사 였는데, 어느 시점부터 체중이 줄지 않아서 시작한 식단이 아직까지 유지될지는 몰랐는데, 나 치고는 나름 밸런스있게 유지하고 있다고 생각 중이다.

조깅은 하지 못하고 있다.

추워서... 비와서... 눈와서... 여러가지 핑계로 몸을 쉬고 있는데, 휴식의 달콤함이 한 번 빠지면 다시 되돌아 오는게 정말 힘들다.

가을 날씨에는 10km 씩 주말에 뛰었는데, 요즘은 주말에 카페에서 공부만 하고 그 이외에는 뭐 없다.

이력서

요즘 몇 개의 공채들이 올라와서 부랴부랴 이력서 작성해서 몇 개 넣어봤는데, 벌써 1개의 탈락 메일을 받았다.

많이 쓰지는 않았지만 2월에 넣었던게 전부 탈락한다면, 전략을 바꿔야 할 것 같다.

기업에서는 어떤 이력서를 원하는 걸까...?

SI 업체에 다닐 때도 기록좀 잘 해놓을 걸... 이 시절에 한 업무는 거의 기록이 없어서 이력서 작성이 쉽지는 않다.

✨ 앞으로는 뭘 할까?

여전히 현상 유지가 1차 목표.

부족한 경험을 채워넣을 무언가가 필요한 시기인 것 같기는 한데, 다른 사람들은 이 시점을 어떻게 헤쳐나갔을까...?