Road To Developer

[특화 프로젝트] 추천 장소 조회 API 개발

RTD — Mon, 16 Mar 2026 12:19:53 +0900

빅데이터 분산 처리 프로젝트 - 추천 장소 조회 API 개발

목표

분석 결과를 활용하여 "나와 비슷한 여행자들의 pick"을 반환하는 REST API를 구현하는 것이 목표다.

전체 흐름

클라이언트 요청
    → GET /api/recommend?nationality=KR&ageGroup=20s&gender=M&...
    → Spring Boot가 PostgreSQL의 popular_places 테이블 조회
    → 조건에 맞는 추천 장소 목록을 JSON으로 반환

1. Entity 클래스 생성

Entity는 PostgreSQL 테이블을 Java 클래스로 매핑한 것이다.
Spark가 생성한 popular_places 테이블의 각 컬럼이 Java 필드가 된다.

패키지 구조

com.travel.bigdata.entity 패키지를 새로 생성했다.

PopularPlace.java

package com.travel.bigdata.entity;

import jakarta.persistence.*;
import lombok.Getter;
import lombok.Setter;

@Entity
@Table(name = "popular_places")
@Getter
@Setter
public class PopularPlace {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;

    private String nationality;

    @Column(name = "age_group")
    private String ageGroup;

    private String gender;

    @Column(name = "travel_purpose")
    private String travelPurpose;

    private String lifestyle;

    @Column(name = "place_id")
    private String placeId;

    @Column(name = "visit_count")
    private Long visitCount;

    @Column(name = "total_score")
    private Long totalScore;

    private Integer rank;
}

주요 어노테이션 설명

어노테이션	설명
`@Entity`	이 클래스가 DB 테이블과 연결됨을 선언
`@Table(name = "popular_places")`	매핑할 테이블 이름 지정
`@Id`	기본 키(Primary Key) 필드
`@GeneratedValue`	기본 키 자동 생성 전략
`@Column(name = "age_group")`	Java의 카멜케이스(`ageGroup`)와 DB의 스네이크케이스(`age_group`)를 매핑

2. Repository 생성

Repository는 DB에서 데이터를 조회하는 역할을 한다.
Spring Data JPA를 사용하면 메서드 이름만으로 SQL 쿼리가 자동 생성된다.

왜 Interface인가?

Repository는 Class가 아닌 Interface로 생성한다.
Spring Data JPA가 메서드 이름을 분석하여 실제 구현 코드를 자동 생성해주기 때문이다.
개발자는 "어떤 조건으로 찾을지" 메서드 이름만 정의하면 된다.

PopularPlaceRepository.java

com.travel.bigdata.repository 패키지를 새로 생성했다.

package com.travel.bigdata.repository;

import com.travel.bigdata.entity.PopularPlace;
import org.springframework.data.jpa.repository.JpaRepository;

import java.util.List;

public interface PopularPlaceRepository extends JpaRepository<PopularPlace, Long> {

    List<PopularPlace> findByNationalityAndAgeGroupAndGenderAndTravelPurposeAndLifestyleOrderByRankAsc(
            String nationality, String ageGroup, String gender, String travelPurpose, String lifestyle
    );
}

메서드 이름 → SQL 자동 변환

메서드 이름이 길지만, Spring Data JPA가 이를 파싱하여 아래 SQL을 자동 생성한다.

findBy                → SELECT * FROM popular_places WHERE
Nationality           → nationality = ?
And AgeGroup          → AND age_group = ?
And Gender            → AND gender = ?
And TravelPurpose     → AND travel_purpose = ?
And Lifestyle         → AND lifestyle = ?
OrderByRankAsc        → ORDER BY rank ASC

SQL을 직접 작성할 필요 없이, 메서드 이름 규칙만 지키면 된다.

3. 조회 API Controller 생성

사용자의 조건(국적, 연령대, 성별, 여행목적, 라이프스타일)을 받아
해당 군집의 인기 장소를 반환하는 API다.

RecommendController.java

controller 패키지에 생성했다.

package com.travel.bigdata.controller;

import com.travel.bigdata.entity.PopularPlace;
import com.travel.bigdata.repository.PopularPlaceRepository;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RequestParam;
import org.springframework.web.bind.annotation.RestController;

import java.util.List;

@RestController
@RequestMapping("/api/recommend")
public class RecommendController {

    private final PopularPlaceRepository repository;

    public RecommendController(PopularPlaceRepository repository) {
        this.repository = repository;
    }

    @GetMapping
    public ResponseEntity<List<PopularPlace>> getRecommendations(
            @RequestParam String nationality,
            @RequestParam String ageGroup,
            @RequestParam String gender,
            @RequestParam String travelPurpose,
            @RequestParam String lifestyle
    ) {
        List<PopularPlace> results = repository
                .findByNationalityAndAgeGroupAndGenderAndTravelPurposeAndLifestyleOrderByRankAsc(
                        nationality, ageGroup, gender, travelPurpose, lifestyle
                );

        return ResponseEntity.ok(results);
    }
}

동작 흐름

GET /api/recommend?nationality=KR&ageGroup=20s&gender=M&travelPurpose=SIGHTSEEING&lifestyle=ADVENTURE
    → RecommendController가 요청 파라미터를 받음
    → PopularPlaceRepository의 메서드 호출
    → Spring Data JPA가 SQL 자동 생성 및 실행
    → 결과를 JSON 리스트로 반환

4. 테스트

API 호출

curl "http://localhost:8090/api/recommend?nationality=KR&ageGroup=20s&gender=M&travelPurpose=SIGHTSEEING&lifestyle=ADVENTURE"

응답 결과

[
  {
    "id": 1,
    "nationality": "KR",
    "ageGroup": "20s",
    "gender": "M",
    "travelPurpose": "SIGHTSEEING",
    "lifestyle": "ADVENTURE",
    "placeId": "place_001",
    "visitCount": 3,
    "totalScore": 5,
    "rank": 1
  },
  {
    "id": 2,
    "nationality": "KR",
    "ageGroup": "20s",
    "gender": "M",
    "travelPurpose": "SIGHTSEEING",
    "lifestyle": "ADVENTURE",
    "placeId": "place_003",
    "visitCount": 2,
    "totalScore": 4,
    "rank": 2
  }
]

20대 한국인 남성 관광 모험형 여행자에게 place_001(1위, 점수 5)과 place_003(2위, 점수 4)이 추천되었다.

DB 확인 (DBeaver)

DBeaver에서 popular_places 테이블의 Data 탭을 클릭하면
API가 조회하는 데이터를 시각적으로 확인할 수 있다.

최종 프로젝트 구조

bigdata/
├── build.gradle
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/travel/bigdata/
│   │   │       ├── config/
│   │   │       │   └── HdfsConfig.java              ← HDFS 연결 설정
│   │   │       ├── controller/
│   │   │       │   ├── LogController.java            ← POST /api/logs (로그 저장)
│   │   │       │   └── RecommendController.java      ← GET /api/recommend (추천 조회)
│   │   │       ├── dto/
│   │   │       │   └── UserLogDto.java               ← 로그 데이터 구조
│   │   │       ├── entity/
│   │   │       │   └── PopularPlace.java             ← popular_places 테이블 매핑
│   │   │       ├── repository/
│   │   │       │   └── PopularPlaceRepository.java   ← DB 조회 인터페이스
│   │   │       ├── service/
│   │   │       │   └── HdfsService.java              ← HDFS 저장 로직
│   │   │       └── BigdataApplication.java
│   │   └── resources/
│   │       └── application.yml
│   └── test/
└── gradle/

travel-project/
├── docker-compose.yml
└── spark-jobs/
    ├── analyze_logs.py
    └── postgresql-42.7.4.jar

API 목록

메서드	URL	설명
POST	`/api/logs`	사용자 행동 로그를 HDFS에 저장
GET	`/api/recommend`	나와 비슷한 여행자들의 추천 장소 조회

GET /api/recommend 파라미터

파라미터	예시	설명
nationality	KR	국적
ageGroup	20s	연령대 (10s, 20s, 30s, 40s, 50s+)
gender	M	성별 (M, F)
travelPurpose	SIGHTSEEING	여행 목적
lifestyle	ADVENTURE	라이프스타일 (여행성향)

전체 프로젝트 완료 현황

단계	내용	상태
1단계	Docker 인프라 세팅 (PostgreSQL, Hadoop, Spark)	✅ 완료
2단계	Spring Boot 프로젝트 생성 + PostgreSQL 연동	✅ 완료
3단계	HDFS에 사용자 로그 적재	✅ 완료
4단계	Spark 배치 분석 + 결과 저장	✅ 완료
5단계	추천 장소 조회 API 개발	✅ 완료

전체 파이프라인 요약

사용자가 장소를 보거나(VIEW) 방문(GO)
    → POST /api/logs로 로그 전송
    → Spring Boot가 HDFS에 CSV로 저장
    → 새벽 4시 Spark 배치 실행 (spark-submit)
    → HDFS 로그를 읽어서 군집별 인기 장소 분석
    → 분석 결과를 PostgreSQL popular_places 테이블에 저장
    → 사용자가 앱에 접속하면 GET /api/recommend 호출
    → 국적/연령대/성별/여행목적/라이프스타일 기반으로 추천 장소 반환

기술 스택 요약

기술	역할
Java 21 / Spring Boot 3.5.11	백엔드 API 서버
PostgreSQL 15	분석 결과 저장 (RDB)
Hadoop HDFS 3.2.1	대용량 사용자 로그 분산 저장
Apache Spark 3.1.1	빅데이터 배치 분석 (군집별 인기 장소)
Docker / Docker Compose	인프라 컨테이너 관리
DBeaver	DB 시각적 관리 도구

[특화 프로젝트] Spark 배치 분석 및 결과 저장

RTD — Mon, 16 Mar 2026 11:52:37 +0900

빅데이터 분산 처리 프로젝트 - Spark 배치 분석 및 결과 저장

목표

HDFS에 쌓인 로그 데이터를 Spark로 분석하여
"비슷한 여행자들이 선호하는 장소" 결과를 도출하고 PostgreSQL에 저장하는 것이 목표다.

전체 흐름

HDFS (사용자 로그 CSV)
    → Spark가 읽어서 분석
    → 국적/연령대/성별/여행목적/라이프스타일별 인기 장소 도출
    → PostgreSQL의 popular_places 테이블에 저장

1. Spark 작업 실행 방식: spark-submit

Spark 분석 작업은 Spring Boot 내부에서 실행하는 것이 아니라,
별도의 스크립트를 Spark 클러스터에 제출(submit)하는 방식이다.
프로젝트 기획서에도 "새벽 4시 기준 스케줄링 : 트리거 역할"이라고 명시되어 있다.

새벽 4시 (스케줄러 트리거)
    → spark-submit 명령어 실행
    → Spark가 HDFS에서 로그 읽기
    → 군집별 인기 장소 분석
    → 결과를 PostgreSQL에 저장

분석 스크립트는 PySpark(Python)로 작성했다.
Java로도 가능하지만 Python이 더 간결하고 데이터 분석에 적합하다.

2. 사전 준비

테스트 데이터 적재

분석을 위해 다양한 사용자 로그를 HDFS에 적재했다.

# 한국인 20대 남성 관광객 로그
curl -X POST http://localhost:8090/api/logs -H "Content-Type: application/json" \
  -d "{\"userId\":\"user001\",\"nationality\":\"KR\",\"age\":25,\"gender\":\"M\",\"travelPurpose\":\"SIGHTSEEING\",\"lifestyle\":\"ADVENTURE\",\"action\":\"VIEW\",\"placeId\":\"place_001\",\"timestamp\":\"2026-03-16T10:30:00\"}"

# 일본인 30대 여성 맛집 탐방객 로그
curl -X POST http://localhost:8090/api/logs -H "Content-Type: application/json" \
  -d "{\"userId\":\"user004\",\"nationality\":\"JP\",\"age\":32,\"gender\":\"F\",\"travelPurpose\":\"FOOD\",\"lifestyle\":\"RELAXATION\",\"action\":\"GO\",\"placeId\":\"place_005\",\"timestamp\":\"2026-03-16T12:00:00\"}"

# ... 총 6건의 로그를 적재

PostgreSQL JDBC 드라이버 준비

Spark가 분석 결과를 PostgreSQL에 저장하려면 JDBC 드라이버가 필요하다.

# spark-jobs 폴더에 드라이버 다운로드
curl -L -o spark-jobs/postgresql-42.7.4.jar https://jdbc.postgresql.org/download/postgresql-42.7.4.jar

docker-compose.yml 수정

Spark Master가 로컬의 스크립트 파일에 접근할 수 있도록 volumes를 추가했다.

  spark-master:
    image: bde2020/spark-master:3.1.1-hadoop3.2
    container_name: travel-spark-master
    ports:
      - "8080:8080"
      - "7077:7077"
    environment:
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - ./spark-jobs:/spark-jobs

./spark-jobs:/spark-jobs는 호스트의 spark-jobs 폴더를 컨테이너의 /spark-jobs 경로에 마운트한다.

폴더 구조

travel-project/
├── docker-compose.yml
└── spark-jobs/
    ├── analyze_logs.py            ← PySpark 분석 스크립트
    └── postgresql-42.7.4.jar      ← PostgreSQL JDBC 드라이버

3. PySpark 분석 스크립트

analyze_logs.py

from pyspark.sql import SparkSession
from pyspark.sql.functions import col, count, dense_rank, when, sum
from pyspark.sql.window import Window

# 1. Spark 세션 생성
spark = SparkSession.builder \
    .appName("TravelLogAnalysis") \
    .config("spark.jars", "/spark-jobs/postgresql-42.7.4.jar") \
    .getOrCreate()

# 2. HDFS에서 로그 읽기
df = spark.read.csv("hdfs://namenode:9000/user-logs/*/*", header=False)

# 3. 컬럼 이름 지정
df = df.toDF(
    "user_id", "nationality", "age", "gender",
    "travel_purpose", "lifestyle", "action", "place_id", "timestamp"
)

# 4. 나이를 숫자로 변환하고 연령대 생성
df = df.withColumn("age", col("age").cast("int"))
df = df.withColumn("age_group",
    when(col("age") < 20, "10s")
    .when(col("age") < 30, "20s")
    .when(col("age") < 40, "30s")
    .when(col("age") < 50, "40s")
    .otherwise("50s+")
)

# 5. 행동별 가중치 부여
df = df.withColumn("score",
    when(col("action") == "GO", 3)
    .when(col("action") == "RE_RECOMMEND", 2)
    .otherwise(1)  # VIEW
)

# 6. 군집별 장소 점수 합산
grouped = df.groupBy(
    "nationality", "age_group", "gender",
    "travel_purpose", "lifestyle", "place_id"
).agg(
    count("*").alias("visit_count"),
    sum("score").alias("total_score")
)

# 7. 군집 내에서 점수 높은 순으로 순위 매기기
window = Window.partitionBy(
    "nationality", "age_group", "gender",
    "travel_purpose", "lifestyle"
).orderBy(col("total_score").desc())

ranked = grouped.withColumn("rank", dense_rank().over(window))

# 8. 상위 5개 장소만 선택
top5 = ranked.filter(col("rank") <= 5)

# 9. 결과를 PostgreSQL에 저장
top5.write \
    .format("jdbc") \
    .option("url", "jdbc:postgresql://travel-postgres:5432/travel_db") \
    .option("dbtable", "popular_places") \
    .option("user", "admin") \
    .option("password", "admin1234") \
    .option("driver", "org.postgresql.Driver") \
    .mode("overwrite") \
    .save()

print("=== 분석 완료! popular_places 테이블에 저장됨 ===")

spark.stop()

스크립트 단계별 설명

단계	내용	설명
1~3	HDFS에서 읽기	모든 날짜(`//`)의 CSV 파일을 읽어서 컬럼명 부여
4	연령대 생성	나이를 10대/20대/30대 등으로 그룹화. 기획서의 "userId별로 하면 경우의 수가 많아지니까 남성, 20대, 국적 이렇게 분류" 요구사항 반영
5	가중치 부여	VIEW=1점, RE_RECOMMEND=2점, GO=3점. 기획서의 "각 로그별 스코어를 부여함 : 가중치를 위해" 요구사항 반영
6	군집별 합산	국적+연령대+성별+여행목적+라이프스타일 조합별로 장소 점수를 합산
7	순위 매기기	각 군집 내에서 total_score 기준 내림차순 순위 부여
8	상위 5개	군집별 인기 장소 Top 5만 추출
9	PostgreSQL 저장	결과를 popular_places 테이블에 overwrite 모드로 저장

PostgreSQL 접속 주소

스크립트에서 PostgreSQL 접속 URL이 localhost가 아니라 travel-postgres인 이유는,
Spark가 Docker 컨테이너 안에서 실행되기 때문이다.
Docker 네트워크에서는 컨테이너 이름으로 서로 접근할 수 있다.

호스트(내 PC)에서 접속할 때     → localhost:5432
Docker 컨테이너에서 접속할 때   → travel-postgres:5432

4. 실행

spark-submit 명령어

MSYS_NO_PATHCONV=1 docker exec -it travel-spark-master \
  /spark/bin/spark-submit \
  --jars /spark-jobs/postgresql-42.7.4.jar \
  /spark-jobs/analyze_logs.py

⚠️ Windows Git Bash 사용 시 주의

Git Bash는 /spark를 Windows 경로(C:/Program Files/Git/spark)로 자동 변환한다.
MSYS_NO_PATHCONV=1을 앞에 붙여서 경로 변환을 방지해야 한다.

성공 로그

실행 후 대량의 Spark 로그가 출력되다가 마지막에 다음 메시지가 나오면 성공이다.

=== 분석 완료! popular_places 테이블에 저장됨 ===

5. 결과 확인

CLI로 확인

docker exec -it travel-postgres psql -U admin -d travel_db -c "SELECT * FROM popular_places;"

결과

 nationality | age_group | gender | travel_purpose |  lifestyle  |  place_id  | visit_count | total_score | rank
-------------+-----------+--------+----------------+-------------+------------+-------------+-------------+------
 KR          | 20s       | M      | SIGHTSEEING    | ADVENTURE   | place_001  |           3 |           5 |    1
 KR          | 20s       | M      | SIGHTSEEING    | ADVENTURE   | place_003  |           2 |           4 |    2
 JP          | 20s       | F      | FOOD           | RELAXATION  | place_005  |           1 |           1 |    1
 JP          | 30s       | F      | FOOD           | RELAXATION  | place_005  |           1 |           3 |    1

결과 해석

한국인 / 20대 / 남성 / 관광 / 모험형: place_001이 1위(점수 5), place_003이 2위(점수 4)
일본인 / 여성 / 맛집 / 휴식형: 20대와 30대 모두 place_005를 선호

이 데이터가 "나와 비슷한 여행자들의 pick" 추천의 기반이 된다.
예를 들어 20대 한국인 남성 관광객이 앱에 접속하면, 이 테이블에서 해당 군집을 조회하여
place_001, place_003을 추천할 수 있다.

GUI로 확인 (DBeaver)

커맨드 라인 대신 DBeaver를 사용하면 테이블 데이터를 시각적으로 확인할 수 있다.

dbeaver.io에서 Community Edition 설치
새 연결 → PostgreSQL 선택
접속 정보 입력: Host localhost, Port 5432, Database travel_db, User admin, Password admin1234
travel_db > Schemas > public > Tables > popular_places 더블클릭

트러블슈팅

Git Bash 경로 변환 문제

exec: "C:/Program Files/Git/spark/bin/spark-submit": no such file or directory

Git Bash가 /spark를 Windows 경로로 변환해서 발생한다.

해결: 명령어 앞에 MSYS_NO_PATHCONV=1을 추가한다.

[특화 프로젝트] HDFS에 사용자 로그 적재

RTD — Mon, 16 Mar 2026 11:21:29 +0900

빅데이터 분산 처리 프로젝트 - HDFS에 사용자 로그 적재

목표

Spring Boot에서 HDFS에 사용자 행동 로그를 저장하는 파이프라인을 구현하는 것이 목표다.

전체 흐름

클라이언트 → POST /api/logs → Spring Boot → HDFS에 CSV 파일로 저장

1. Hadoop 라이브러리 추가

Spring Boot에서 HDFS에 접근하려면 Hadoop Client 라이브러리가 필요하다.
build.gradle의 dependencies에 추가했다.

dependencies {
    // 기존 의존성 생략...

    // HDFS 연동을 위한 Hadoop 라이브러리
    implementation 'org.apache.hadoop:hadoop-client:3.2.1'
}

버전은 Docker로 띄운 Hadoop(3.2.1)과 동일하게 맞췄다.

2. 프로젝트 패키지 구조

코드를 역할별로 분리하기 위해 4개의 패키지를 생성했다.

com.travel.bigdata
├── config/         ← 설정 클래스 (HDFS 연결 등)
├── controller/     ← API 엔드포인트
├── dto/            ← 데이터 구조 정의
├── service/        ← 비즈니스 로직
└── BigdataApplication.java

3. 로그 데이터 구조 정의 (DTO)

사용자 행동 로그에 담길 데이터를 정의하는 클래스다.
프로젝트 기획서에 명시된 필드(국적, 나이, 성별, 여행목적, 라이프스타일 등)를 그대로 반영했다.

package com.travel.bigdata.dto;

import lombok.Getter;
import lombok.Setter;
import lombok.ToString;

@Getter
@Setter
@ToString
public class UserLogDto {
    private String userId;          // 사용자 ID
    private String nationality;     // 국적
    private int age;                // 나이
    private String gender;          // 성별
    private String travelPurpose;   // 여행 목적
    private String lifestyle;       // 라이프스타일 (여행성향)
    private String action;          // 행동 (VIEW, GO, RE_RECOMMEND)
    private String placeId;         // 장소 ID
    private String timestamp;       // 로그 생성 시간
}

Lombok 어노테이션

어노테이션	역할
`@Getter`	모든 필드의 getter 메서드 자동 생성
`@Setter`	모든 필드의 setter 메서드 자동 생성
`@ToString`	`toString()` 메서드 자동 생성

Lombok을 사용하면 보일러플레이트 코드를 직접 작성하지 않아도 된다.

4. HDFS 연결 설정 (Config)

Spring Boot에서 HDFS에 접속하기 위한 설정 클래스다.

package com.travel.bigdata.config;

import org.apache.hadoop.fs.FileSystem;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

@Configuration
public class HdfsConfig {

    private final String hdfsUri = "hdfs://localhost:9000";

    @Bean
    public FileSystem fileSystem() throws Exception {
        org.apache.hadoop.conf.Configuration configuration = new org.apache.hadoop.conf.Configuration();
        configuration.set("fs.defaultFS", hdfsUri);
        configuration.set("dfs.client.use.datanode.hostname", "true");

        // HDFS에 root 사용자로 접속
        System.setProperty("HADOOP_USER_NAME", "root");

        return FileSystem.get(configuration);
    }
}

주요 설정 설명

설정	설명
`@Configuration`	이 클래스가 Spring 설정 파일임을 선언
`@Bean`	이 메서드의 반환 객체를 Spring이 관리하도록 등록
`fs.defaultFS`	HDFS의 주소. Docker의 NameNode 포트(9000)와 매핑
`dfs.client.use.datanode.hostname`	DataNode 접근 시 컨테이너 IP 대신 hostname을 사용
`HADOOP_USER_NAME`	HDFS에 root 권한으로 접속 (권한 문제 방지)

5. HDFS 저장 로직 (Service)

로그 데이터를 받아서 HDFS에 CSV 파일로 저장하는 핵심 로직이다.

package com.travel.bigdata.service;

import com.travel.bigdata.dto.UserLogDto;
import org.apache.hadoop.fs.FSDataOutputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.springframework.stereotype.Service;

import java.time.LocalDate;

@Service
public class HdfsService {

    private final FileSystem fileSystem;

    public HdfsService(FileSystem fileSystem) {
        this.fileSystem = fileSystem;
    }

    public void saveLog(UserLogDto log) throws Exception {
        // 날짜별로 폴더를 나눠서 저장
        String date = LocalDate.now().toString();
        String fileName = "log_" + System.currentTimeMillis() + ".csv";
        Path path = new Path("/user-logs/" + date + "/" + fileName);

        // CSV 형태로 한 줄 만들기
        String csvLine = String.join(",",
                log.getUserId(),
                log.getNationality(),
                String.valueOf(log.getAge()),
                log.getGender(),
                log.getTravelPurpose(),
                log.getLifestyle(),
                log.getAction(),
                log.getPlaceId(),
                log.getTimestamp()
        );

        // HDFS에 파일 쓰기
        try (FSDataOutputStream outputStream = fileSystem.create(path, true)) {
            outputStream.writeBytes(csvLine + "\n");
        }
    }
}

설계 포인트

날짜별 폴더 분리: /user-logs/2026-03-16/ 형태로 저장하여 Spark가 특정 날짜의 로그만 선택적으로 읽을 수 있도록 했다.
CSV 형태 저장: Spark가 CSV를 쉽게 파싱할 수 있어 분석 단계에서 편리하다.
타임스탬프 기반 파일명: log_1773627176253.csv처럼 밀리초 단위 타임스탬프로 파일명을 생성하여 충돌을 방지했다.

6. API 엔드포인트 (Controller)

외부에서 로그 데이터를 POST 요청으로 보내면 HDFS에 저장하는 API다.

package com.travel.bigdata.controller;

import com.travel.bigdata.dto.UserLogDto;
import com.travel.bigdata.service.HdfsService;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.PostMapping;
import org.springframework.web.bind.annotation.RequestBody;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/api/logs")
public class LogController {

    private final HdfsService hdfsService;

    public LogController(HdfsService hdfsService) {
        this.hdfsService = hdfsService;
    }

    @PostMapping
    public ResponseEntity<String> saveLog(@RequestBody UserLogDto logDto) {
        try {
            hdfsService.saveLog(logDto);
            return ResponseEntity.ok("로그 저장 성공");
        } catch (Exception e) {
            return ResponseEntity.internalServerError().body("로그 저장 실패: " + e.getMessage());
        }
    }
}

요청-응답 흐름

POST /api/logs (JSON 데이터)
    → LogController가 요청을 받음
    → HdfsService.saveLog() 호출
    → HDFS에 CSV 파일 저장
    → "로그 저장 성공" 응답 반환

7. 테스트

API 호출

curl -X POST http://localhost:8090/api/logs \
  -H "Content-Type: application/json" \
  -d "{\"userId\":\"user001\",\"nationality\":\"KR\",\"age\":25,\"gender\":\"M\",\"travelPurpose\":\"SIGHTSEEING\",\"lifestyle\":\"ADVENTURE\",\"action\":\"VIEW\",\"placeId\":\"place_001\",\"timestamp\":\"2026-03-16T10:30:00\"}"

응답: 로그 저장 성공

HDFS에서 파일 확인

# 파일 목록 확인
docker exec -it travel-namenode hdfs dfs -ls hdfs://namenode:9000/user-logs/2026-03-16/

# 파일 내용 확인
docker exec -it travel-namenode hdfs dfs -cat hdfs://namenode:9000/user-logs/2026-03-16/*.csv

출력 결과:

user001,KR,25,M,SIGHTSEEING,ADVENTURE,VIEW,place_001,2026-03-16T10:30:00

전송한 로그 데이터가 CSV 형태로 HDFS에 정상 저장된 것을 확인했다.

트러블슈팅

1. HADOOP_HOME 경고

HADOOP_HOME and hadoop.home.dir are unset.

Windows에서 Hadoop 라이브러리를 사용하면 발생하는 경고다.
네트워크로 HDFS에 접속하는 방식이므로 로컬에 Hadoop이 설치되어 있을 필요가 없다.
무시해도 정상 동작한다.

2. Permission denied 에러

Permission denied: user=SSAFY, access=WRITE, inode="/":root:supergroup:drwxr-xr-x

HDFS는 root 사용자 권한으로 동작하는데, Spring Boot가 Windows 사용자(SSAFY)로 접속하면 쓰기 권한이 없다.

해결: HdfsConfig에서 System.setProperty("HADOOP_USER_NAME", "root") 설정으로 HDFS에 root 사용자로 접속하도록 했다.

3. DataNode 연결 실패 (UnresolvedAddressException)

java.nio.channels.UnresolvedAddressException

Spring Boot(호스트)가 Docker 컨테이너 내부의 DataNode에 접근하지 못하는 문제다.
세 가지를 수정하여 해결했다.

docker-compose.yml 수정:

DataNode에 hostname: datanode 설정 추가
DataNode에 ports: 9864, 9866 포트 매핑 추가
HDFS_CONF_dfs_datanode_hostname: datanode 환경변수 추가

HdfsConfig.java 수정:

dfs.client.use.datanode.hostname 설정을 true로 추가

Windows hosts 파일 수정:

C:\Windows\System32\drivers\etc\hosts에 127.0.0.1 datanode 추가
관리자 권한 PowerShell에서 아래 명령어로 추가 가능:

Add-Content -Path "C:\Windows\System32\drivers\etc\hosts" -Value "127.0.0.1 datanode"

최종 docker-compose.yml

3단계까지의 변경사항이 반영된 전체 파일이다.

services:
  postgres:
    image: postgres:15
    container_name: travel-postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: travel_db
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin1234
    volumes:
      - postgres_data:/var/lib/postgresql/data

  namenode:
    image: bde2020/hadoop-namenode:2.0.0-hadoop3.2.1-java8
    container_name: travel-namenode
    ports:
      - "9870:9870"
      - "9000:9000"
    environment:
      CLUSTER_NAME: travel-cluster
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - namenode_data:/hadoop/dfs/name

  datanode:
    image: bde2020/hadoop-datanode:2.0.0-hadoop3.2.1-java8
    container_name: travel-datanode
    hostname: datanode
    depends_on:
      - namenode
    ports:
      - "9864:9864"
      - "9866:9866"
    environment:
      SERVICE_PRECONDITION: "namenode:9870"
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
      HDFS_CONF_dfs_datanode_hostname: datanode
    volumes:
      - datanode_data:/hadoop/dfs/data

  spark-master:
    image: bde2020/spark-master:3.1.1-hadoop3.2
    container_name: travel-spark-master
    ports:
      - "8080:8080"
      - "7077:7077"
    environment:
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

  spark-worker:
    image: bde2020/spark-worker:3.1.1-hadoop3.2
    container_name: travel-spark-worker
    depends_on:
      - spark-master
    environment:
      SPARK_MASTER: spark://spark-master:7077
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

volumes:
  postgres_data:
  namenode_data:
  datanode_data:

최종 프로젝트 구조

bigdata/
├── build.gradle
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/travel/bigdata/
│   │   │       ├── config/
│   │   │       │   └── HdfsConfig.java          ← HDFS 연결 설정
│   │   │       ├── controller/
│   │   │       │   └── LogController.java        ← POST /api/logs API
│   │   │       ├── dto/
│   │   │       │   └── UserLogDto.java           ← 로그 데이터 구조
│   │   │       ├── service/
│   │   │       │   └── HdfsService.java          ← HDFS 저장 로직
│   │   │       └── BigdataApplication.java
│   │   └── resources/
│   │       └── application.yml
│   └── test/
└── gradle/

[특화 프로젝트] Spring Boot 프로젝트 생성 및 PostgreSQL 연동

RTD — Mon, 16 Mar 2026 09:51:36 +0900

빅데이터 분산 처리 프로젝트 - Spring Boot 프로젝트 생성 및 PostgreSQL 연동

목표

1단계에서 Docker로 인프라(PostgreSQL, Hadoop, Spark)를 구성했다.
2단계에서는 Spring Boot 프로젝트를 생성하고, Docker로 띄운 PostgreSQL과 연결하는 것이 목표다.

1. Spring Initializr로 프로젝트 생성

https://start.spring.io 에서 프로젝트를 생성했다.

프로젝트 설정

항목	설정값
Project	Gradle - Groovy
Language	Java
Spring Boot	3.5.11
Group	com.travel
Artifact	bigdata
Packaging	Jar
Configuration	YAML
Java	17

Dependencies

의존성	용도
Spring Web	REST API 개발
Spring Data JPA	PostgreSQL과 ORM 연동
PostgreSQL Driver	PostgreSQL JDBC 드라이버
Lombok	보일러플레이트 코드 자동 생성

GENERATE 버튼을 눌러 zip 파일을 다운로드하고, 압축을 풀어 IntelliJ에서 열었다.

2. Gradle이란?

Spring Boot 프로젝트는 수많은 외부 라이브러리에 의존한다.
Gradle은 이 라이브러리들을 자동으로 다운로드하고, 코드를 컴파일하고, 실행 가능한 파일(.jar)로 빌드해주는 도구다.

build.gradle 파일에 필요한 라이브러리를 선언하면, Gradle이 알아서 다운받아준다.

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
    runtimeOnly 'org.postgresql:postgresql'
    compileOnly 'org.projectlombok:lombok'
}

새로운 라이브러리가 필요하면 여기에 한 줄 추가하고 Gradle 새로고침만 하면 된다.

3. IntelliJ에서 프로젝트 열기

프로젝트 로드

IntelliJ 실행 → Open → 압축 푼 bigdata 폴더 선택
우측 하단에 "Load Gradle Project" 팝업이 뜨면 클릭
Gradle이 의존성 다운로드 및 프로젝트 빌드를 자동 수행

JDK 설정

프로젝트를 열면 "Project JDK is not defined" 경고가 뜰 수 있다.
상단의 Setup SDK 링크를 클릭하고 JDK 21을 선택하면 된다.

⚠️ Java 버전 주의

Spring Initializr에서 Java 17로 설정했지만, IntelliJ가 자동으로 JDK 21을 다운받은 경우
build.gradle의 languageVersion을 21로 맞춰줘야 빌드 에러가 발생하지 않는다.
java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(21)
    }
}

빌드 확인

Gradle 패널의 새로고침 버튼( )을 클릭하면 빌드가 시작된다.
하단 Build 탭에 BUILD SUCCESSFUL이 표시되면 성공이다.

4. PostgreSQL 연동 설정

application.yml

src/main/resources/application.yml 파일에 DB 접속 정보와 JPA 설정을 작성했다.

spring:
  datasource:
    url: jdbc:postgresql://localhost:5432/travel_db
    username: admin
    password: admin1234
    driver-class-name: org.postgresql.Driver

  jpa:
    hibernate:
      ddl-auto: update
    show-sql: true
    properties:
      hibernate:
        dialect: org.hibernate.dialect.PostgreSQLDialect

server:
  port: 8090

주요 설정 설명

항목	설명
`datasource.url`	Docker로 띄운 PostgreSQL의 JDBC 접속 URL. 1단계에서 설정한 DB명(`travel_db`)과 포트(`5432`) 사용
`datasource.username / password`	docker-compose.yml의 `POSTGRES_USER`, `POSTGRES_PASSWORD`와 동일하게 설정
`jpa.hibernate.ddl-auto: update`	엔티티 클래스를 기반으로 테이블을 자동 생성/수정. 개발 단계에서 편리함
`jpa.show-sql: true`	실행되는 SQL 쿼리를 콘솔에 출력하여 디버깅에 활용
`server.port: 8090`	기본 포트 8080은 Spark Master가 사용 중이므로 8090으로 변경

5. 연결 테스트

실행 전 확인사항

Docker 컨테이너가 켜져 있어야 한다. 터미널에서 확인 가능하다.

# travel-project 폴더에서
docker-compose up -d
docker ps

5개 컨테이너(postgres, namenode, datanode, spark-master, spark-worker)가 모두 Up 상태여야 한다.

Spring Boot 실행

IntelliJ에서 BigdataApplication.java 파일을 열고, public class BigdataApplication 옆의 초록색 ▶ 버튼을 클릭하여 Run을 선택한다.

성공 로그

콘솔에서 다음 로그들이 확인되면 연동 성공이다.

HikariPool-1 - Start completed.                    ← PostgreSQL 연결 성공
Tomcat started on port 8090 (http)                  ← 서버 8090 포트에서 실행
Started BigdataApplication in X.XX seconds          ← Spring Boot 정상 기동

WARN 로그에 대하여

실행 시 두 가지 WARN 메시지가 나올 수 있다.

PostgreSQLDialect does not need to be specified explicitly — dialect를 명시하지 않아도 자동 감지된다는 안내. 무시해도 무방하다.

spring.jpa.open-in-view is enabled by default — open-in-view 설정 관련 안내. 개발 단계에서는 무시해도 된다.

두 가지 모두 에러가 아닌 참고용 경고이므로 정상 동작에 영향을 주지 않는다.

프로젝트 구조

bigdata/
├── build.gradle                          ← Gradle 빌드 설정 (의존성 관리)
├── src/
│   ├── main/
│   │   ├── java/
│   │   │   └── com/travel/bigdata/
│   │   │       └── BigdataApplication.java   ← Spring Boot 메인 클래스
│   │   └── resources/
│   │       └── application.yml               ← DB 연결 및 서버 설정
│   └── test/
└── gradle/

[특화 프로젝트]Docker 인프라 세팅하는 법

RTD — Mon, 16 Mar 2026 00:27:21 +0900

빅데이터 분산 처리 프로젝트 - On My Guide Docker 인프라 세팅

프로젝트 개요

외국인 관광객을 위한 여행지 추천 시스템의 백엔드를 개발하는 프로젝트다.
사용자 행동 로그를 수집하고, 빅데이터 분산 처리를 통해 "나와 비슷한 여행자들의 선호 여행지"를 분석하여 추천하는 것이 목표다.

기술 스택

Java 17 / Spring Boot 3.0.5 / Spring Security 6
PostgreSQL — 분석 결과 저장용 RDB
Hadoop (HDFS) — 대용량 사용자 로그 적재
Spark — 배치 분산 처리 (군집 분석)
Kafka — 로그 이벤트 스트리밍

전체 데이터 파이프라인

사용자 행동 (GO, 상세보기, 재추천)
    ↓
Kafka (로그 이벤트 스트림)
    ↓
Spring Consumer (Kafka 메시지 수신)
    ↓
HDFS (사용자 로그 적재)
    ↓
Spark 배치 처리 (새벽 4시, 군집 분석)
    ↓
PostgreSQL (분석 결과 저장)
    ↓
조회 API → 클라이언트에 추천 장소 반환

왜 Docker를 사용하는가?

이 프로젝트에는 PostgreSQL, Hadoop, Spark, Kafka 등 여러 인프라가 필요하다.
이걸 하나하나 로컬에 직접 설치하면 버전 충돌, 환경 차이, 삭제 시 찌꺼기 등의 문제가 발생한다.

Docker는 각 프로그램을 격리된 컨테이너에서 실행하는 도구다.
Docker Compose는 여러 컨테이너를 docker-compose.yml 파일 하나로 관리할 수 있게 해준다.

docker-compose up -d    # 전부 실행
docker-compose down     # 전부 종료

docker-compose.yml을 수정한 뒤 docker-compose up -d를 다시 실행하면,
변경된 컨테이너만 재시작되고 기존 컨테이너는 유지된다.

1. PostgreSQL 컨테이너 세팅

가장 먼저 분석 결과를 저장할 PostgreSQL을 띄웠다.

docker-compose.yml (PostgreSQL만)

services:
  postgres:
    image: postgres:15
    container_name: travel-postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: travel_db
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin1234
    volumes:
      - postgres_data:/var/lib/postgresql/data

volumes:
  postgres_data:

주요 설정 설명

항목	설명
`image: postgres:15`	PostgreSQL 15 버전 이미지 사용
`ports: "5432:5432"`	호스트의 5432 포트를 컨테이너의 5432 포트에 매핑. Spring Boot에서 `localhost:5432`로 접속 가능
`environment`	DB 이름, 사용자, 비밀번호를 환경변수로 설정. 컨테이너 최초 실행 시 자동 생성됨
`volumes`	컨테이너를 종료해도 데이터가 유지되도록 볼륨 마운트

동작 확인

# 실행
docker-compose up -d

# PostgreSQL 접속
docker exec -it travel-postgres psql -U admin -d travel_db

# 데이터베이스 목록 확인
\l

# 종료
\q

travel_db가 목록에 표시되면 성공이다.

2. Hadoop (HDFS) 컨테이너 세팅

사용자 로그를 대량으로 적재할 HDFS를 추가했다.

HDFS란?

HDFS(Hadoop Distributed File System)는 대용량 파일을 분산 저장하는 파일 시스템이다.
두 가지 역할로 구성된다.

NameNode — 파일이 어디에 저장되어 있는지 관리하는 메타데이터 서버 (전화번호부 역할)
DataNode — 실제 데이터가 저장되는 스토리지 노드 (창고 역할)

docker-compose.yml에 추가

  namenode:
    image: bde2020/hadoop-namenode:2.0.0-hadoop3.2.1-java8
    container_name: travel-namenode
    ports:
      - "9870:9870"
      - "9000:9000"
    environment:
      CLUSTER_NAME: travel-cluster
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - namenode_data:/hadoop/dfs/name

  datanode:
    image: bde2020/hadoop-datanode:2.0.0-hadoop3.2.1-java8
    container_name: travel-datanode
    depends_on:
      - namenode
    environment:
      SERVICE_PRECONDITION: "namenode:9870"
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - datanode_data:/hadoop/dfs/data

주요 설정 설명

항목	설명
`9870` 포트	Hadoop 웹 관리 화면 (`http://localhost:9870`)
`9000` 포트	HDFS 파일 읽기/쓰기용 포트 (Spring Boot, Spark에서 사용)
`CORE_CONF_fs_defaultFS`	HDFS의 기본 파일시스템 주소 설정. 이 설정이 없으면 Windows 환경에서 경로 인식 에러 발생
`depends_on`	DataNode는 NameNode가 먼저 실행된 후에 시작
`SERVICE_PRECONDITION`	NameNode가 완전히 준비될 때까지 DataNode가 대기

동작 확인

# 실행
docker-compose up -d

# 웹 브라우저에서 확인
# http://localhost:9870 접속 → Hadoop Overview 화면이 뜨면 성공

# HDFS에 테스트 파일 저장
docker exec -it travel-namenode bash -c "echo 'hello hdfs' > /tmp/test.txt && hdfs dfs -mkdir -p /test && hdfs dfs -put /tmp/test.txt /test/"

# 파일 확인
docker exec -it travel-namenode hdfs dfs -ls hdfs://namenode:9000/test/

⚠️ Windows Git Bash 사용 시 주의

Git Bash는 /를 Windows 경로(C:\)로 자동 변환하는 이슈가 있다.
hdfs dfs -ls / 명령어 실행 시 No FileSystem for scheme "C" 에러가 발생하면,
전체 HDFS 주소를 명시하면 된다.
# 에러 발생
docker exec -it travel-namenode hdfs dfs -ls /

# 해결 방법 1: 전체 주소 명시
docker exec -it travel-namenode hdfs dfs -ls hdfs://namenode:9000/

# 해결 방법 2: 경로 변환 비활성화
MSYS_NO_PATHCONV=1 docker exec -it travel-namenode hdfs dfs -ls /

3. Spark 컨테이너 세팅

HDFS에 적재된 로그 데이터를 분석할 Spark를 추가했다.

Spark란?

Spark는 대용량 데이터를 여러 노드에서 병렬로 분석하는 분산 처리 엔진이다.
이 프로젝트에서는 매일 새벽 4시에 HDFS의 사용자 로그를 읽어 군집 분석(성별, 나이, 국적 기반 그룹핑)을 수행한다.

Master — 작업을 분배하는 관리 노드
Worker — 실제 연산을 수행하는 실행 노드

docker-compose.yml에 추가

  spark-master:
    image: bde2020/spark-master:3.1.1-hadoop3.2
    container_name: travel-spark-master
    ports:
      - "8080:8080"
      - "7077:7077"
    environment:
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

  spark-worker:
    image: bde2020/spark-worker:3.1.1-hadoop3.2
    container_name: travel-spark-worker
    depends_on:
      - spark-master
    environment:
      SPARK_MASTER: spark://spark-master:7077
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

주요 설정 설명

항목	설명
`8080` 포트	Spark 웹 관리 화면 (`http://localhost:8080`)
`7077` 포트	Master-Worker 간 내부 통신 포트
`SPARK_MASTER`	Worker에게 Master의 주소를 알려주는 설정
`CORE_CONF_fs_defaultFS`	Spark가 HDFS에 접근할 수 있도록 주소 설정

동작 확인

# 실행
docker-compose up -d

# 컨테이너 상태 확인 (5개 모두 Up 상태여야 함)
docker ps

# 웹 브라우저에서 확인
# http://localhost:8080 접속 → Spark Master 화면에서 Workers(1) 확인

Status가 ALIVE이고 Workers가 1로 표시되면 성공이다.

최종 docker-compose.yml

services:
  postgres:
    image: postgres:15
    container_name: travel-postgres
    ports:
      - "5432:5432"
    environment:
      POSTGRES_DB: travel_db
      POSTGRES_USER: admin
      POSTGRES_PASSWORD: admin1234
    volumes:
      - postgres_data:/var/lib/postgresql/data

  namenode:
    image: bde2020/hadoop-namenode:2.0.0-hadoop3.2.1-java8
    container_name: travel-namenode
    ports:
      - "9870:9870"
      - "9000:9000"
    environment:
      CLUSTER_NAME: travel-cluster
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - namenode_data:/hadoop/dfs/name

  datanode:
    image: bde2020/hadoop-datanode:2.0.0-hadoop3.2.1-java8
    container_name: travel-datanode
    depends_on:
      - namenode
    environment:
      SERVICE_PRECONDITION: "namenode:9870"
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000
    volumes:
      - datanode_data:/hadoop/dfs/data

  spark-master:
    image: bde2020/spark-master:3.1.1-hadoop3.2
    container_name: travel-spark-master
    ports:
      - "8080:8080"
      - "7077:7077"
    environment:
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

  spark-worker:
    image: bde2020/spark-worker:3.1.1-hadoop3.2
    container_name: travel-spark-worker
    depends_on:
      - spark-master
    environment:
      SPARK_MASTER: spark://spark-master:7077
      CORE_CONF_fs_defaultFS: hdfs://namenode:9000

volumes:
  postgres_data:
  namenode_data:
  datanode_data:

관리 대시보드 접속 정보

서비스	URL	용도
Hadoop HDFS	`http://localhost:9870`	HDFS 상태 및 파일 시스템 모니터링
Spark Master	`http://localhost:8080`	Spark 작업 상태 및 Worker 모니터링
PostgreSQL	`localhost:5432`	DB 클라이언트 접속 (DBeaver 등)

재밌다 빅데이터 분산하길 잘했다.

[B형 기출] 커피점&제과점

RTD — Mon, 9 Mar 2026 16:09:00 +0900

커피점·제과점 최적 주택 찾기 — 다중 소스 다익스트라 풀이

1. 문제 요약

N개의 건물(0 ~ N-1)이 양방향 도로로 연결된 그래프가 주어진다. 도로에는 거리 정보가 있고, 실시간으로 새로운 도로가 추가될 수 있다.

calculate 호출 시 M개의 커피점 건물, P개의 제과점 건물, 제한 거리 R이 주어지면, 커피점도 제과점도 아닌 주택 중에서 다음 조건을 만족하는 건물을 찾아야 한다.

가장 가까운 커피점까지의 최단 거리 ≤ R
가장 가까운 제과점까지의 최단 거리 ≤ R

조건을 만족하는 주택이 여러 개라면, (커피점 최단 거리 + 제과점 최단 거리)의 최솟값을 반환한다. 조건을 만족하는 주택이 없으면 -1을 반환한다.

2. Main 코드 분석 — 입력 구조와 채점 로직 이해

제출 시스템에서는 main.py가 입력을 파싱하고, solution.py의 함수들을 호출한다. main 코드를 분석하면 문제의 숨겨진 제약조건과 호출 패턴을 파악할 수 있다.

2.1 전체 입력 구조

T score            ← 테스트 케이스 수, 배점
num_commands       ← 이번 TC의 명령 수
cmd                ← 100(init), 200(add), 300(calculate)
...

첫 줄에 테스트 케이스 수 T와 배점 score가 주어진다. 각 TC마다 명령의 수 num_commands가 주어지고, 이후 명령 코드에 따라 분기한다.

2.2 명령 코드별 분석

cmd = 100 (init) — 그래프 초기화

n, k = map(int, input().split())  # 건물 수, 도로 수
for i in range(k):
    s, e, d = map(int, input().split())  # 시작, 끝, 거리
init(n, k, sB, eB, mD)

TC 시작 시 한 번 호출된다. N개의 건물과 K개의 초기 도로가 주어진다.

cmd = 200 (add) — 도로 추가

s, e, d = map(int, input().split())
add(s, e, d)

기존 그래프에 새로운 양방향 도로를 하나 추가한다. 한 TC당 최대 2,000번 호출된다.

cmd = 300 (calculate) — 최적 주택 탐색

m, p, r = map(int, input().split())  # 커피점 수, 제과점 수, 제한거리
mCoffee = [int(input()) for _ in range(m)]
mBakery = [int(input()) for _ in range(p)]
expected = int(input())              # 정답
ret = calculate(m, mCoffee, p, mBakery, r)
if ret != expected:
    result = 0

핵심은 마지막 줄의 expected다. main 코드가 정답을 읽어서 calculate의 반환값과 비교한다. 하나라도 틀리면 해당 TC 전체가 0점이 된다. 한 TC당 최대 100번 호출된다.

2.3 Main 분석에서 얻는 제약조건 정리

파라미터	범위
N (건물 수)	6 ~ 10,000
K (초기 도로 수)	6 ~ 30,000
add() 호출	TC당 최대 2,000회
calculate() 호출	TC당 최대 100회
M, P (커피점/제과점 수)	1 ~ 1,000
mDistance (도로 거리)	1 ~ 1,000
R (제한 거리)	50 ~ 250,000

도로가 최대 K + 2,000 = 32,000개까지 늘어날 수 있다. 이 정보는 시간복잡도 분석에 핵심이 된다.

3. 시간복잡도를 고려한 풀이 전략 도출

3.1 나이브한 접근 — 왜 안 되는가?

가장 직관적인 방법은 각 커피점에서 다익스트라를 돌리고, 각 제과점에서도 다익스트라를 돌리는 것이다.

커피점 M개 × 다익스트라 = M × O(E log N)
제과점 P개 × 다익스트라 = P × O(E log N)

M, P가 최대 1,000이고, E가 최대 32,000, N이 최대 10,000이므로, 한 번의 calculate 호출에 약 1,000 × 32,000 × 14 ≈ 4.5억 연산이 필요하다.

calculate가 최대 100번 호출되므로 총 450억 연산. 파이썬은 물론이고 C++에서도 시간 내에 통과하기 어렵다.

3.2 핵심 아이디어 — 다중 소스 다익스트라 (Multi-Source Dijkstra)

우리가 필요한 것은 각 주택에서 "가장 가까운 커피점까지의 거리" 와 "가장 가까운 제과점까지의 거리" 이다. 이것은 개별 소스에서의 거리가 아니라, 소스 집합에서의 최단 거리다.

다중 소스 다익스트라는 이 문제를 정확히 해결한다.

원리: 가상의 슈퍼 소스 노드 S를 만들고, S에서 모든 커피점으로 거리 0인 간선을 연결한다고 상상해보자. S에서 다익스트라를 돌리면, 각 노드까지의 최단 거리는 곧 "가장 가까운 커피점까지의 거리"가 된다.

실제 구현에서는 가상 노드를 만들 필요 없이, 모든 소스 노드를 거리 0으로 힙에 넣고 시작하면 된다.

일반 다익스트라:  힙 = [(0, source)]        ← 소스 1개
다중 소스:       힙 = [(0, c1), (0, c2), ...] ← 소스 M개

이렇게 하면 다익스트라가 자연스럽게 각 노드에서 가장 가까운 소스까지의 거리를 구해준다.

3.3 최종 전략과 시간복잡도

calculate 1회 호출 시:
  1. 다중 소스 다익스트라 (커피점 전체 → 모든 노드)  : O(E log N)
  2. 다중 소스 다익스트라 (제과점 전체 → 모든 노드)  : O(E log N)
  3. 모든 주택 순회하며 최솟값 탐색                  : O(N)
  합계: O(E log N)

한 번의 calculate에 O(E log N) = 32,000 × 14 ≈ 45만 연산. 100번 호출해도 약 4,500만 연산으로, 충분히 빠르다.

접근법	calculate 1회	100회 호출 시
나이브 (개별 다익스트라)	O((M+P) × E log N) ≈ 9억	900억
다중 소스 다익스트라	O(E log N) ≈ 45만	4,500만

약 2,000배 차이가 난다.

3.4 추가 최적화 — R을 이용한 조기 종료

다익스트라 진행 중 힙에서 꺼낸 거리가 R을 초과하면, 최소 힙의 특성상 이후에 꺼낼 값들도 모두 R 이상이다. 따라서 break로 탐색을 즉시 종료할 수 있다.

if d > R:
    break  # 이후 힙의 모든 원소는 d 이상 → R 초과 확정

R이 작을 때 탐색 범위가 대폭 줄어들어 실측 성능이 크게 개선된다.

4. Solution 코드 상세 설명

4.1 전역 변수와 그래프 구조

from heapq import heappush, heappop

N = 0       # 건물 수
adj = []    # 인접 리스트: adj[u] = [(v, w), ...]

그래프를 인접 리스트로 표현한다. adj[u]에는 (인접 노드, 거리) 튜플의 리스트가 저장된다. 인접 행렬 대비 메모리 효율적이며, 간선 순회 시 불필요한 탐색이 없다.

heapq에서 heappush, heappop을 직접 import하는 것은 파이썬 최적화 테크닉이다. heapq.heappush()처럼 모듈 경유 호출보다 함수 직접 호출이 약간 더 빠르다.

4.2 init — 그래프 초기화

def init(n, k, sBuilding, eBuilding, mDistance):
    global N, adj
    N = n
    adj = [[] for _ in range(N)]
    for i in range(k):
        u = sBuilding[i]
        v = eBuilding[i]
        w = mDistance[i]
        adj[u].append((v, w))
        adj[v].append((u, w))

양방향 도로이므로 adj[u]와 adj[v] 양쪽에 간선을 추가한다. 매 TC마다 호출되어 그래프를 완전히 새로 구성한다.

4.3 add — 도로 추가

def add(sBuilding, eBuilding, mDistance):
    adj[sBuilding].append((eBuilding, mDistance))
    adj[eBuilding].append((sBuilding, mDistance))

O(1)로 간선을 추가한다. 문제 조건상 이미 존재하는 간선이 다시 주어지지 않으므로 중복 체크는 불필요하다.

4.4 _dijkstra — 다중 소스 다익스트라의 핵심

def _dijkstra(sources, R):
    INF = float('inf')
    dist = [INF] * N          # ① 거리 배열 초기화
    hq = []
    for c in sources:          # ② 모든 소스를 거리 0으로 힙에 삽입
        dist[c] = 0
        heappush(hq, (0, c))
    _adj = adj                 # ③ 로컬 변수로 참조 (파이썬 속도 최적화)
    while hq:
        d, u = heappop(hq)    # ④ 최소 거리 노드 추출
        if d > dist[u]:        # ⑤ 이미 더 짧은 경로로 방문됨 → 스킵
            continue
        if d > R:              # ⑥ R 초과 → 조기 종료
            break
        for v, w in _adj[u]:   # ⑦ 인접 노드 완화 (relaxation)
            nd = d + w
            if nd < dist[v]:
                dist[v] = nd
                heappush(hq, (nd, v))
    return dist

각 단계를 자세히 살펴보자.

① 거리 배열 초기화: 모든 노드의 거리를 무한대로 설정한다.

② 다중 소스 삽입: 일반 다익스트라와의 유일한 차이점이다. 소스가 여러 개일 때, 모든 소스를 거리 0으로 힙에 넣는다. 이렇게 하면 다익스트라가 "가장 가까운 소스로부터의 거리"를 자동으로 계산한다.

직관적 이해를 위해 커피점이 {A, B}인 경우를 생각해보자. 노드 X까지의 거리가 dist(A→X) = 30, dist(B→X) = 20이라면, B가 먼저 X에 도달하여 dist[X] = 20이 된다. 이후 A에서 X로 가는 경로(30)가 힙에서 꺼내져도, 이미 dist[X] = 20이므로 ⑤에서 스킵된다.

③ 로컬 변수 참조: _adj = adj는 전역 변수 adj를 로컬 변수 _adj에 바인딩한다. 파이썬에서 전역 변수 접근은 로컬 변수보다 느리다. 반복문 내부에서 수만 번 접근하므로 체감 차이가 생긴다.

⑤ 중복 방문 스킵: 파이썬의 heapq는 decrease-key 연산을 지원하지 않는다. 대신 새 (거리, 노드) 쌍을 힙에 추가하고, 꺼낼 때 현재 dist보다 크면 무시하는 lazy deletion 전략을 사용한다.

⑥ 조기 종료: 최소 힙에서 꺼낸 거리가 R을 초과하면, 힙에 남아 있는 모든 원소의 거리도 R 이상이다. 어차피 R 초과인 노드는 결과에 영향을 주지 않으므로 즉시 break한다.

4.5 calculate — 결과 조합

def calculate(M, mCoffee, P, mBakery, R):
    dist_coffee = _dijkstra(mCoffee, R)   # ① 커피점들로부터의 최단 거리
    dist_bakery = _dijkstra(mBakery, R)   # ② 제과점들로부터의 최단 거리

    exclude = [False] * N                  # ③ 커피점/제과점 제외 마스크
    for c in mCoffee:
        exclude[c] = True
    for b in mBakery:
        exclude[b] = True

    ans = float('inf')
    for v in range(N):                     # ④ 모든 주택 순회
        if exclude[v]:                     #    커피점/제과점이면 스킵
            continue
        dc = dist_coffee[v]
        if dc > R:                         #    커피점 거리 조건 불만족 → 스킵
            continue
        db = dist_bakery[v]
        if db > R:                         #    제과점 거리 조건 불만족 → 스킵
            continue
        s = dc + db
        if s < ans:
            ans = s

    return ans if ans != float('inf') else -1

① ~ ②: 다익스트라를 정확히 2번 실행한다. dist_coffee[v]는 노드 v에서 가장 가까운 커피점까지의 최단 거리, dist_bakery[v]는 가장 가까운 제과점까지의 최단 거리다.

③ 제외 마스크: set 대신 boolean 배열을 사용했다. 파이썬에서 set의 in 연산은 평균 O(1)이지만 해시 오버헤드가 있다. boolean 배열은 인덱스로 직접 접근하므로 상수 시간이 더 작다. N이 최대 10,000이므로 메모리 부담도 없다.

④ 주택 순회: 조건 검사 순서도 최적화의 일부다. exclude 체크 → dc > R 체크 → db > R 체크 순으로 빠르게 탈락시킬 수 있는 조건을 먼저 검사한다. 특히 dc > R을 먼저 검사하여, 커피점에서 너무 먼 노드는 db를 조회하지도 않는다.

5. 예제 트레이스로 검증

문제에서 제시된 순서 5를 따라가 본다.

calculate(1, {0}, 1, {5}, 50) — 도로 추가 후 (3-4: 30, 1-4: 30)

커피점 다익스트라 (소스: {0}):

노드	0	1	2	3	4	5
거리	0	30	30	40	60	50

경로: 0→2→1 (30), 0→2 (30), 0→2→1→3 (40), 0→2→1→4 (60), 0→2→1→4→5 (50)

제과점 다익스트라 (소스: {5}):

노드	0	1	2	3	4	5
거리	80	50	60	50	20	0

경로: 5→4→1 (50), 5→3 (60→50은 아님, 5→4→3이 50), 5→4 (20)

주택 판별: 0(커피점), 5(제과점) 제외 → 주택은 {1, 2, 3, 4}

조건 검사 (R=50):

주택	dc	db	dc≤50?	db≤50?	dc+db
1	30	50	O	O	80
2	30	60	O	X	-
3	40	50	O	O	90
4	60	20	X	-	-

최솟값은 80... 이 아니라 문제 예시의 답은 90이다.

잠깐, 도로를 다시 확인해보자. 순서 4에서 1-4 도로(거리 30)가 추가되었으므로:

0→1: 초기 도로 0-1 (80), 또는 0→2→1 = 30+10 = 40. 즉 dist(0,1) = 40
0→3: 0→2→1→3 = 30+10+10 = 50

다시 계산하면:

노드	dist from 0
0	0
1	40 (0→2→1: 30+10)
2	30 (0→2)
3	50 (0→2→1→3: 30+10+10)
4	70 (0→2→1→4: 30+10+30)
5	50 (0→2→1→4→5: 30+10+30+20=90? → 또는 0→2→1→3→5: 30+10+10+60=110)

정리하면 dist(0, 5)의 최단은 0→2(30)→1(10)→4(30)→5(20) = 90? 아, 여기서 초기 도로를 다시 보자.

초기 도로: (0,1,80), (2,0,30), (1,2,10), (1,3,10), (5,3,60), (4,5,20)
추가 도로: (3,4,30), (1,4,30)

dist(0,1) = min(80, 0→2→1 = 30+10 = 40) = 40
dist(0,3) = 0→2→1→3 = 40+10 = 50
dist(0,4) = min(0→2→1→4 = 40+30, 0→2→1→3→4 = 50+30) = 70
dist(0,5) = min(0→...→4→5 = 70+20, 0→...→3→5 = 50+60) = 90

노드	dist from 5
5	0
4	20
3	50 (5→4→3: 20+30 = 50, 또는 5→3: 60) → 50
1	50 (5→4→1: 20+30 = 50, 또는 5→3→1: 60+10 = 70) → 50
2	60 (5→4→1→2: 50+10 = 60)
0	70 (5→4→1→2→0: 60+30=90, 또는 5→4→1→0: 50+80=130...) → 아 0→2가 30이므로 0←2도 30: 60+30 = 90

주택 판별 (0, 5 제외):

주택	dc (from 0)	db (from 5)	dc≤50?	db≤50?	dc+db
1	40	50	O	O	90
2	30	60	O	X	-
3	50	50	O	O	100
4	70	20	X	-	-

최솟값 = 90. 정답과 일치한다.

6. 파이썬 최적화 포인트 정리

이 문제는 C/C++ 기준으로 설계되어 있어, 파이썬에서는 상수 최적화가 중요하다. 적용된 최적화들을 정리한다.

1. 모듈 함수 직접 import: from heapq import heappush, heappop으로 함수를 직접 가져온다. heapq.heappush() 대비 속성 조회 오버헤드를 제거한다.

2. 전역 → 로컬 바인딩: _adj = adj로 전역 변수를 로컬에 바인딩한다. CPython에서 로컬 변수 접근은 LOAD_FAST, 전역은 LOAD_GLOBAL 바이트코드를 사용하며, 전자가 더 빠르다.

3. 조기 종료: R 제한을 활용한 break는 탐색 공간을 대폭 줄인다. 특히 R이 작을 때 효과적이다.

4. 조건 검사 순서: exclude → dc > R → db > R 순으로 빠른 탈락을 유도한다.

5. boolean 배열 vs set: exclude를 set이 아닌 list[bool]로 구현하여 해시 오버헤드를 제거했다.

7. 정리

항목	내용
핵심 알고리즘	다중 소스 다익스트라 (Multi-Source Dijkstra)
시간복잡도	calculate 1회당 O(E log N)
공간복잡도	O(N + E)
핵심 최적화	소스 집합을 한 번에 처리 / R 기반 조기 종료

다중 소스 다익스트라의 핵심은 "여러 소스에서 각각 돌리지 말고, 전부 거리 0으로 힙에 넣고 한 번만 돌리자" 는 발상이다. 이 패턴은 "가장 가까운 X까지의 거리"를 구하는 모든 문제에 적용할 수 있으므로 꼭 익혀두자.

[Linux] Shell Script 이해

RTD — Mon, 12 Jan 2026 16:59:24 +0900

리눅스 Shell Script & 패키지 관리 완벽 정리

1. Shell & Script 기초

Shell의 종류

Bash (Bourne Again SHell): 우분투 기본 CLI 쉘, 리눅스 사용자에게 가장 인기 있음.

Dash (Debian Almquist SHell): 임베디드 리눅스에서 주로 사용 (작은 용량).

확인 방법:

  cat /etc/passwd | grep ssafy   # 사용 중인 쉘 확인
  cat /etc/shells                # 설치된 모든 쉘 확인
  du -h /bin/bash /bin/dash      # 용량 비교

쉘 변경 (실습): sudo chsh [계정명] -s /bin/dash 후 재부팅.

Shell Script 개요

목적: 반복적인 작업을 자동화하기 위함 (예: 백업, 초기 세팅 등).
확장자: .sh

기본 구조:

  #!/bin/bash    # (Shebang) 스크립트를 실행할 쉘 지정
  # 내용 작성

실행 방법:
- source test.sh: 현재 쉘 환경에서 실행 (가장 많이 사용).
- ./test.sh: 실행 권한 필요 (chmod +x), 별도 프로세스로 실행.

문법 핵심

변수:
- 선언: NAME=value (띄어쓰기 금지, 모든 값은 문자열 취급).
- 사용: $NAME
- 산술 연산: $(( 1 + 2 ))
조건문 (if):
- if [ 조건 ]; then ... fi (대괄호 안쪽 띄어쓰기 필수).
- 비교 연산자:
  - -lt (<), -gt (>), -eq (==), -ne (!=), -ge (>=), -le (<=)
  - -f: 파일 존재 여부 (Regular file)
  - -x: 실행 권한 여부
배열: ARR=(1 2 3) / 출력: ${ARR[0]}
환경변수:
- export NAME=value: 현재 세션에 변수 등록 (재부팅 시 사라짐).
- ~/.bashrc에 등록: 영구 등록 (터미널 실행 시 자동 적용).
- 확인: printenv | grep NAME

2. Crontab (스케줄링 자동화)

Cron Daemon

역할: 백그라운드에서 주기적인 작업을 관리 및 수행.
상태 확인: service cron status / 재시작: service cron restart

Crontab 설정

편집: sudo vi /etc/crontab
시간 설정 문법 (5자리):

분 시 일 월 요일 사용자 명령어
- * * * * *: 매 분마다 수행.
- */3 * * * *: 3분마다 수행.
- 0 7 * * *: 매일 아침 7시에 수행.

실습 예제 (매 분 스크립트 실행):

  # 1. 스크립트 권한 부여
  sudo chmod a+x /home/ssafy/test.sh

  # 2. crontab 등록
  * * * * * ssafy /home/ssafy/test.sh

3. 리눅스 파일 압축 및 해제

압축 방식 비교

압축률: zip < gz < bz2 < xz (xz가 압축률 가장 높음, 속도 느림).

명령어 정리

형식	압축하기	풀기	특징
zip	`zip -r [파일.zip] [대상]`	`unzip [파일.zip] -d [경로]`	널리 쓰임, 원본 유지
gzip	`gzip [파일]`	`gunzip [파일.gz]`	단일 파일 압축, 원본 삭제
xz	`xz [파일]`	`xz -d [파일.xz]`	높은 압축률, 원본 삭제
tar	`tar -cvf [파일.tar] [대상]`	`tar -xvf [파일.tar] -C [경로]`	파일 묶기 (압축 아님)
tar.xz	`tar -Jcvf [파일.tar.xz] [대상]`	`tar -Jxvf [파일.tar.xz] -C [경로]`	묶기+압축 (가장 많이 씀)

4. 소프트웨어 설치 및 배포 방법

1. Binary 파일 설치 (Node.js 예시)

특징: 컴파일된 실행 파일을 다운로드하여 배치.
과정:
1. wget으로 파일 다운로드 (tar.xz).
2. 압축 해제: sudo tar -Jxvf node-v20...tar.xz -C /usr/local/lib/nodejs/
3. 심볼릭 링크 생성 (어디서든 실행 가능하게):
  sudo ln -s /usr/local/lib/nodejs/.../bin/node /usr/bin/node
4. 확인: node -v

2. dpkg (Debian Package) 설치

특징: .deb 확장자 파일 설치. 의존성 문제를 해결해주지 않음 (단점).
명령어:
- 설치: sudo dpkg -i [파일.deb]
- 삭제: sudo dpkg -P [패키지명]
보완: 의존성 오류 발생 시 apt를 사용하여 해결하거나 설치.

3. Source Code 설치 (빌드)

특징: 소스코드를 직접 다운받아 내 컴퓨터 환경에 맞춰 컴파일. (시간 오래 걸림, 커스터마이징 가능).
과정 (Unix 표준):
1. 필수 도구 설치: gcc, g++, make, python3 등.
2. 압축 해제 및 디렉토리 이동.
3. 설정: ./configure (환경 설정).
4. 빌드: make -j4 (컴파일, 4코어 사용).
5. 설치: sudo make install (시스템에 복사).
6. 삭제: sudo make uninstall

[Linux] Build System 이해

RTD — Mon, 12 Jan 2026 16:58:36 +0900

️ Build System & Linux Command 학습 정리

1. Build System 개요

빌드(Build)란?

정의: 소스코드(.c, .cpp)를 실행 가능한 소프트웨어(.elf, .exe)로 변환하는 과정 또는 결과물.
Build System: 빌드에 필요한 여러 작업을 도와주는 프로그램 (예: make, cmake).

GCC 기준 빌드 과정 (2단계)

Compile & Assemble
- 소스코드 파일을 0과 1로 구성된 Object 파일(.o)로 변환.
- 명령어: gcc -c ./main.c (➔ main.o 생성)
Linking
- 생성된 Object 파일들과 Library들을 모아 하나로 합침.
- 명령어: gcc ./main.o ./yellow.o -o ./go (➔ 실행 파일 go 생성)

빌드 자동화의 필요성

Bash Shell Script (.sh):
- source 파일명.sh로 빌드 가능.
- 단점: 파일 하나만 수정해도 전체를 다시 빌드해야 함 (시간 소요 큼).
Make Build System:
- 파일 간의 의존성(Dependency)을 추적하여, 변경된 파일만 컴파일함 (속도 최적화).

2. Make (소프트웨어 빌드 자동화 도구)

특징

Makefile이라는 특별한 형식의 파일을 사용.
설치: sudo apt install make -y
실행: make

Makefile 문법

Target (타겟): 빌드하려는 최종 결과물 (1개 이상 필수).
Dependency (의존성): Target을 만들기 위해 필요한 파일 목록.
Command (명령어): 실행할 명령어 (반드시 Tab으로 들여쓰기).

변수 (Variable)

사용: $(변수명) 또는 ${변수명}. 가독성을 위해 상단에 정의.
할당 연산자:
- =: 코드 전체 기준 최종값 (지연 할당).
- :=: 현재 위치 기준 값 (즉시 할당).
- +=: 기존 값에 추가.
특수 변수 (Automatic Variables):
- $@: Target 이름.
- $^: Dependency 목록 전체.
- $<: Dependency 목록 중 첫 번째 파일.

주요 기능 및 옵션

컴파일 옵션:
- -g: 디버깅 정보 포함.
- -Wall: 모든 경고(Warning)를 에러처럼 표시.
- -O2: 최적화 2단계.
Wildcard 함수: *.c (현재 디렉토리의 모든 .c 파일).
확장자 치환: OBJS = $(SRCS:.c=.o) (.c를 .o로 변경).

Makedepend 유틸리티

입력한 소스파일을 분석해 헤더파일 의존성을 자동으로 등록해주는 도구.

설치: sudo apt install wutils-dev -y (또는 xutils-dev)
사용: makedepend main.c func1.c -Y
특징: Makefile 하단에 의존성 추가, Makefile.bak 백업 생성.

3. CMake (Cross Platform Build System)

특징

운영체제에 상관없이 빌드 가능한 크로스 플랫폼 도구.
Makefile을 자동으로 생성해주는 상위 빌드 시스템.
설치: sudo apt install g++ cmake -y

사용 흐름

CMakeLists.txt 파일 작성.
cmake . 실행 → Makefile 자동 생성.
make 실행 → 빌드 완료.

4. 리눅스 파일 관리 명령어

파일 내용 및 검색

cat [파일]: 파일 내용 출력.
>: 내용 쓰기 (덮어쓰기).
>>: 내용 이어 쓰기 (Append).
grep [텍스트] [경로]: 문자열 검색.
- 예: ls -al | grep test*

파일 찾기 및 정보

find [경로] -name [이름] -type [f/d]: 파일(f) 또는 디렉토리(d) 찾기.
file [파일]: 파일 종류 확인 (ASCII text, executable 등).
which [명령어]: 명령어 실행 파일의 위치 확인.

용량 확인

du -sh [파일/디렉토리]: Disk Usage 확인.
- -s: 총 사용량만 출력 (Summary).
- -h: 사람이 보기 편한 단위로 출력 (Human-readable).

5. Shell 명령어 & 기타

시스템 정보 및 로그

echo [텍스트]: 화면 출력.
date: 현재 시간 확인.
uptime: 시스템 부팅 후 경과 시간 및 부하 확인.
dmesg: 커널 부팅 로그 및 하드웨어 메시지 출력.
history: 사용한 명령어 기록 확인 (!번호로 재실행).

C언어 연동

system("명령어"): C 코드 내에서 쉘 명령어를 실행 (#include <stdlib.h>).

심볼릭 링크 (Symbolic Link)

정의: 윈도우의 '바로가기'와 같은 링크 파일. 원본을 가리킴.
명령어: ln -s [원본] [링크명]
- 예: ln -s ./bts ./bbq (bbq가 bts를 가리킴).
확인: ls -al로 확인 시 -> 화살표로 연결 표시됨.

[Raspberry pi] sensor

RTD — Sat, 10 Jan 2026 11:13:02 +0900

[TIL] 라즈베리파이 신호 처리 및 센서(Sense HAT) 심화 학습

1. 신호 처리 기초 (Analog vs Digital)

아날로그 신호의 처리

문제점: 라즈베리파이에는 아날로그 신호를 디지털로 변환하는 ADC(Analog-to-Digital Converter) 하드웨어가 내장되어 있지 않음.
해결책 (PWM):
- PWM (Pulse Width Modulation): 펄스 폭 변조.
- 디지털 신호를 빠르게 스위칭(On/Off)하여 마치 아날로그 신호인 것처럼 보이게 하는 기술.

주파수와 주기

공식: $f(Hz) = 1 / T(s)$ (주파수는 주기에 반비례)
CPU 속도 예시:
- 일반 CPU (5GHz): 1초에 50억 회 진동 (1회 진동 시 0.2ns 소요)
- 라즈베리파이 5 (ARM Cortex-A76 2.4GHz): 1초에 24억 회 진동 (1회 진동 시 약 417μs 소요)

2. 센서(Sensor)와 MEMS

센서 개요

Sense HAT: 라즈베리파이 공식 센서 키트 (Add-on Board).
센서(Sensor): 정보를 수집하여 수치 값으로 만들어내는 장치.
- 예: 오감(시각, 청각) 외 초음파, 압력, 자기, 온도, 가스, 가속도 등.

MEMS (Micro Electro Mechanical Systems)

정의: 반도체 제조 공정을 응용하여 만든 초소형 정밀 기계 시스템.
활용 분야: 자동차, 정보 통신 등 다양한 분야.
- 에어백: 가속도 센서 활용.
- 차체 제어: 자이로 센서 활용.
- 타이어: 공기압 센서 활용.

3. MCU와 드라이버 (Driver)

드라이버의 필요성

MCU의 한계: GPIO 핀 부족, 직접 제어 시 프로그래밍의 복잡함 등으로 모든 모듈을 직접 제어하기 어려움.
드라이버(Driver)의 역할:
- H/W Interface: 모듈을 제어할 수 있는 인터페이스 역할.
- 동작 원리: MCU는 드라이버에게 명령을 내리고, 드라이버가 실제 모듈(LED, 모터 등)을 제어함.
- 종류: FND 드라이버, 모터 드라이버, LCD 드라이버, LED 드라이버 등.

4. 라즈베리파이 Sense HAT 실습

개요 및 구성

구성: 다양한 센서 집합(자이로, 가속도, 기압, 지자기, 온습도) + 8x8 LED Matrix + 조이스틱.
주의사항: 하드웨어 연결 시 반드시 라즈베리파이 전원을 끄고 연결할 것.

Sense HAT Emulator (가상 시뮬레이터)

하드웨어가 없거나 불량 테스트 용도로 사용 (실제 코드와 호환됨).

설치 명령어:

  git clone https://github.com/astro-pi/python-sense-emu
  cd ./python-sense-emu
  sudo python3 setup.py install

API 테스트 코드 (Python)

from sense_hat import SenseHat
sense = SenseHat()
sense.show_message("HELLO")

트러블 슈팅 (OSError 발생 시)

원인: 설정 파일에 Sense HAT 오버레이가 누락된 경우.
해결 방법:
1. /boot/firmware/config.txt 파일 열기 (sudo vi ...)
2. dtoverlay=rpi-sense 내용 추가 후 저장.
3. sudo reboot (재부팅).

회로도 확인

공식 사이트: Raspberry Pi Datasheets
확인 방법: 'sense-hat' 검색 → Schematic(회로도) 클릭 → 부품 실크 번호(ex: U3, U4)로 상세 부품 확인 및 PDF 조회.

5. IMU (Inertial Measurement Unit, 관성 측정 장치)

개요

물체의 기울기, 위치, 방향 등 정보를 측정하는 장치 (드론, 자동차, 선박 등 활용).
센서 축(Axis) 구성:
- 3축: 가속도 or 자이로 or 지자기 중 택 1 (X, Y, Z).
- 6축: 자이로스코프 + 가속도 센서.
- 9축: 자이로스코프 + 가속도 센서 + 지자기 센서.
Sense HAT 스펙: 9축 센서 탑재 (회로도 실크: U4).
- 자이로스코프 (Pitch, Roll, Yaw)
- 가속도 센서 (X, Y, Z)
- 지자기 센서 (X, Y, Z)

데이터 보정 (필터링)

필요성: 자이로스코프 등의 Raw data는 오차가 있을 수 있어 보정이 필수.
주요 필터:
- 상보 필터 (Complementary Filter)
- 칼만 필터 (Kalman Filter)
참고: 정확한 각도를 구하기 위해 사용되며, 최근에는 관련 라이브러리가 잘 구축되어 있음.

가속도 센서 활용 원리

가속도 적분 → 속도 산출.
속도 적분 → 이동 경로 산출.
진동 분석 → 장비 고장 여부 판단.
기울기 측정 → 모터 제어 등에 활용 (예: MPU6050).

6. 기타 구성 요소 상세

LED Matrix

Sense HAT에 내장된 디스플레이.
공식 문서: Sense HAT API - LED Matrix

조이스틱 (Joystick)

특징: 라즈베리파이에는 ADC가 없음.
구조: 명칭은 조이스틱이지만 실제로는 아날로그 스틱이 아닌 5개의 디지털 버튼(좌, 우, 위, 아래, 클릭)으로 구성됨.
회로도 실크: J2

라즈베리파이 & 임베디드 기초

RTD — Sat, 10 Jan 2026 11:11:44 +0900

라즈베리파이 & 임베디드 기초 학습 정리

1. 라즈베리파이 (Raspberry Pi) 개요

정의: SBC (Single Board Computer). 많은 리눅스 및 임베디드 SW 개발자가 교육용으로 다루는 훌륭한 MPU.
역할: GUI 원격 제어기로서 Edge Device와 DB 사이에서 중계 및 제어 역할을 담당.
라즈베리파이 5 스펙 (Model B):
- 칩셋: Broadcom BCM2712
- CPU: 2.4GHz ARM Cortex-A76 쿼드코어
- RAM: 8GB
- 통신: WiFi, BLE (Bluetooth 5.0), 이더넷 등
- IDE: Thonny Python IDE 내장 (Python 주로 사용)

2. 전기전자 기초

전압과 전류

임베디드 장치는 적절한 용량의 전기가 공급되어야 고장나지 않고 동작합니다.

전압 (Voltage, V): 전하가 갖는 전위의 차이. (압력)
전류 (Current, A): 단위 시간당 흐르는 전하의 양. (흐름)
전력 (Power, W): W = V * A
멀티미터 측정:
- 병렬 연결: 전압 측정
- 직렬 연결: 전류 측정
전원: 임베디드는 주로 직류(DC)를 사용하며, 항상 VCC(+)와 GND(-)를 가짐.

저항 (Resistor)

역할: 전기의 흐름을 방해하여 원하는 전압/전류를 맞춤 (과전류 방지).
주요 저항 색띠:
- 220Ω: 빨/빨/갈 (4띠), 빨/빨/검/갈 (5띠)
- 10kΩ: 갈/검/주
브레드보드: 빨간색 라인(VCC), 파란/검정 라인(GND) 연결.

정격 전압/전류 (Rating)

정격: 기기가 동작하는 데 필요한 표준 값.
규칙: 공급 전압은 정격과 일치해야 하며, 공급 전류는 정격보다 커야 함.
라즈베리파이 5 전원: 5V / 5A (정품 어댑터 권장).
GPIO 전기 규격:
- 공급 전압: 최대 3.3V
- 핀당 최대 전류: 16mA
- 모든 핀 총 전류: 1A

3. 임베디드 개발 방식

개발 형태 분류

Bare-metal (Firmware):
- OS 없이 하드웨어 위에서 직접 동작하는 코드 작성.
- 주로 작은 MCU(마이크로컨트롤러) 개발 시 사용.
RTOS (Real Time OS):
- 실시간성을 보장하는 가벼운 OS 사용.
Embedded Linux:
- 리눅스 기반의 풍부한 개발 도구와 생태계 활용. (라즈베리파이 해당)

크로스 컴파일 (Cross Compile)

정의: 개발 환경(PC)과 실행 환경(타겟 보드)의 아키텍처가 다를 때 사용하는 컴파일 방식.
이유: 개발 PC(Host)의 성능이 임베디드 보드(Target)보다 훨씬 우수하기 때문에, PC에서 컴파일하여 실행 파일만 보드로 전송하여 실행함.

4. GPIO 제어 및 실습

GPIO (General Purpose Input Output)

정의: 칩 제작사가 용도를 고정하지 않고, 사용자가 자유롭게 H/W를 연결해 제어하도록 만든 핀.
제어 방법:
1. Device Driver: 리눅스 커널 레벨에서 제어.
2. Library: 랩핑(Wrapping)된 함수를 사용하여 쉽게 제어.
Pinout 가이드: https://pinout.xyz/

파이썬 라이브러리

gpiozero (추천): 초보자가 사용하기 쉽도록 직관적으로 설계됨.
RPi.GPIO: 더 세부적인 로우 레벨 설정이 가능함.

LED 제어 실습 코드 (`led.py`)


from gpiozero import LED
from time import sleep

red = LED(14)  # GPIO 14번 핀에 연결

while True:
    red.on()   # High 신호 (켜기)
    sleep(1)
    red.off()  # Low 신호 (끄기)
    sleep(1)

실행: python3 led.py

주의: LED는 긴 쪽이 +, 짧은 쪽이 -. 사용하지 않는 모듈은 분리(특히 GND).

5. 스위치와 플로팅(Floating) 상태

플로팅 상태란?

스위치를 누르지 않았을 때, 핀의 전압이 High(1)인지 Low(0)인지 확정할 수 없는 불안정한 상태.

모든 MCU 입력 핀에서 발생 가능.

해결 방법 (Pull-up / Pull-down)

저항을 사용하여 평소 상태(Default)를 고정해 줌.

풀업 (Pull-up):

평소(스위치 Open)에 High 상태 유지.

스위치를 누르면 Low가 됨.

VCC 쪽에 저항 연결.

선호: 노이즈 제거 및 회로 보호에 유리하여 더 많이 사용됨.

풀다운 (Pull-down):

평소에 Low 상태 유지.

스위치를 누르면 High가 됨.

GND 쪽에 저항 연결.

Tip: 라즈베리파이 GPIO 핀에는 내부 풀업 회로가 내장되어 있어, 소프트웨어적으로 설정하거나 자동으로 적용되는 경우가 많습니다.

️ 기타 팁

VNC 접속 불가 시: Raspberry Pi Configuration → Interfaces → VNC 활성화(Enable) 체크.

회로 연결 순서: 항상 3.3V와 GND를 먼저 연결하여 기준 전위를 잡을 것.