n8n 학습기 시리즈 — 6편(마지막). 토이 프로젝트 (3): Slack 알림 + 이슈 자동 등록 5편에서 회의록이 구조화된 데이터가 됐다. 이제 이 데이터를 실제 행동으로 옮긴다. 요약은 Slack으로, 액션아이템은 이슈로. "요약만 하는 봇"과 "실행까지 이어지는 자동화"의 차이가 여기서 완성된다.

들어가며

지금까지의 여정을 되짚어보자. 4편에서 회의록을 워크플로우 안으로 들여왔고, 5편에서 그걸 LLM에 태워 이런 데이터를 얻었다.

{
  "summary": "로그인 버그 수정과 회원가입 리뉴얼 일정을 논의함",
  "decisions": ["회원가입 페이지 리뉴얼은 다음 스프린트로 연기"],
  "actionItems": [
    { "assignee": "박서연", "task": "로그인 세션 만료 버그 수정", "dueDate": "2026-07-17", "priority": "high" },
    { "assignee": "이민호", "task": "디자인 시안 피그마 링크 공유", "dueDate": "2026-07-15", "priority": "medium" }
  ]
}

여기서 멈추면 그냥 "잘 정리된 JSON"이다. 우리가 애초에 못 견뎌 했던 건 결정이 실행에서 누락되는 것이었다. 그러니 이 데이터가 실제로 누군가의 할 일 목록에 꽂혀야 프로젝트가 완성된다.

이번 편의 목표는 둘이다. 요약과 결정사항은 Slack에 한 번 발송하고, 액션아이템은 각각 이슈로 등록하는 것.

두 출력은 처리 방식이 다르다

5편에서 "사람이 읽을 것 / 기계가 처리할 것"으로 나눴는데, 그 구분이 여기서 처리 방식의 차이로 이어진다.

• 요약·결정사항 → 하나의 메시지로 묶어 Slack에 한 번 보낸다. (1건)
• 액션아이템 → 배열 안에 여러 개가 들어 있고, 각각을 개별 이슈로 만들어야 한다. (N건)

전자는 단순하다. 후자가 이번 편의 핵심이자, 3편에서 배운 개념이 마침내 실전으로 쓰이는 지점이다.

배열을 아이템으로 쪼개기 — Split Out

문제가 하나 있다. LLM이 뱉은 데이터는 한 아이템 안에 actionItems 배열이 통째로 들어 있는 형태다. 이 상태로는 이슈를 하나씩 만들 수 없다. 이슈 등록 노드는 "아이템 하나 = 이슈 하나"로 동작하는데, 지금은 아이템이 하나뿐이고 그 안에 할일이 여러 개 뭉쳐 있기 때문이다.

3편에서 배운 게 여기서 떠올랐다. n8n은 아이템 단위로 노드를 반복 실행한다. 그러니 액션아이템 배열을 개별 아이템으로 펼쳐주면, 그다음 이슈 노드가 알아서 각각에 대해 한 번씩 돈다. 이 "배열을 아이템으로 펼치는" 일을 하는 게 Split Out 노드다.

Split Out 노드를 추가하고 설정한다.

• Field To Split Out → actionItems (펼칠 배열 필드)
• Include Other Fields → 필요하면 켠다 (요약 등 상위 필드를 각 아이템에 딸려 보내고 싶을 때)

이러면 액션아이템이 2개였을 때, Split Out을 통과한 뒤 아이템 2개가 된다. 하나씩 흐르는 것이다.

[ { actionItems: [A, B] } ]     →  Split Out  →  [ {A}, {B} ]
   (1개 아이템, 배열 안에 2개)                      (2개 아이템)

1편에서 "왜 데이터를 배열로 감싸지?"라고 물었던 것, 3편에서 "노드는 아이템마다 자동 반복된다"고 배운 것이 바로 이 순간을 위한 것이었다. 액션아이템이 3개인 회의록을 넣으면 이슈가 3개 생기고, 0개인 회의록을 넣으면(빈 배열) 이슈가 안 생긴다. 내가 루프를 짜지 않아도.

액션아이템을 이슈로 등록

Split Out 뒤에 이슈 생성 노드를 붙인다. 나는 GitHub Issues를 썼다(H-HABIT 레포와 엮으면 실전 그대로다). Notion, Jira, ClickUp 등 팀이 쓰는 도구로 바꿔도 구조는 같다.

노드 설정에서 이슈의 각 필드를 표현식으로 채운다. 2편에서 익힌 그 매핑이다.

• Title → {{ $json.task }}
• Body → 담당자와 기한을 조합. 예: 담당: {{ $json.assignee }} / 기한: {{ $json.dueDate }}
• Labels → 우선순위를 라벨로. {{ $json.priority }}

Split Out 덕분에 이 노드는 각 액션아이템마다 한 번씩 실행되고, 실행할 때마다 그 아이템의 task, assignee가 표현식에 채워진다. 아이템 단위 실행이 이렇게 편할 수가 없다.

한 가지 QA 습관이 발동한 부분. 이슈 제목이나 본문에 null이 그대로 박히면 보기 흉하다(담당자 미정인 경우). 그래서 표현식에 기본값을 넣었다.

담당: {{ $json.assignee ?? "미정" }}

5편에서 "담당자 없으면 null"로 뽑게 해놓고, 여기서 그 null을 "미정"으로 표시하는 것이다. 데이터 계층에선 null로 정확하게 두고, 표시 계층에서 사람이 읽기 좋게 바꾼다. 관심사를 분리한 셈이다.

요약은 Slack으로

액션아이템과 달리 요약·결정사항은 회의당 하나면 된다. 그래서 Split Out을 거치지 않은 원래 데이터에서 뽑아 Slack 노드로 보낸다.

여기서 워크플로우가 갈라진다. LLM 출력 하나가 두 갈래로 나뉘는 것이다. 한 갈래는 Split Out → 이슈 등록으로, 다른 갈래는 곧장 Slack으로. Slack 노드의 메시지를 표현식으로 구성한다.

Slack을 처음 연결할 때 한 가지 짚어둘 게 있다. 셀프호스팅 n8n에서 Slack을 붙이는 방식은 OAuth2와 Access Token 두 가지인데, OAuth2로 가려면 Slack에서 앱을 하나 만들어야 한다. api.slack.com/apps에서 앱을 만들고, n8n 자격증명 화면에 표시된 리다이렉트 URL을 Slack 앱의 Redirect URLs에 등록한 뒤, chat:write 스코프를 부여하고 Client ID/Secret을 n8n에 넣는 흐름이다. 4편의 구글 OAuth와 구조가 똑같다. 한 번 해봤다고 두 번째는 확실히 빨랐다. (Access Token 방식으로 xoxb- 봇 토큰만 넣는 더 간단한 길도 있으니, OAuth 설정이 번거로우면 그쪽을 택해도 된다.) 연결 후에는 메시지를 보낼 채널에 봇을 초대해두는 걸 잊지 말자.

📋 *회의 요약*
{{ $json.summary }}

*결정사항*
{{ $json.decisions.join("\n- ") }}

액션아이템 {{ $json.actionItems.length }}건은 이슈로 등록되었습니다.

decisions는 배열이니 join으로 줄바꿈해 붙이고, 액션아이템은 개수만 알려준다(상세는 이슈에 있으니까). Slack에 이 메시지가 뜨면, 회의에 못 들어온 사람도 결정사항과 할일 현황을 한눈에 본다.

실패를 조용히 넘기지 않기

5편에서 예고한 silent failure 방지를 여기서 마무리한다. 자동화가 신뢰를 얻으려면, 실패했을 때 실패했다고 말해줘야 한다.

이게 왜 필수인지 만들면서 몸으로 겪었다. 실행하다 이런 에러를 만난 것이다.

[503 Service Unavailable] This model is currently experiencing high demand.
consider setting this node to retry automatically

내 설정이 틀린 게 아니라, Google의 LLM 서버가 순간적으로 과부하라 응답을 못 준 것이었다. 잠시 후 다시 실행하니 멀쩡히 됐다. 문제는 실제 운영에선 내가 지켜보고 있지 않다는 점이다. 새벽에 회의록이 올라왔는데 마침 외부 API가 잠깐 죽어 있으면, 재시도 장치가 없는 한 그 회의록은 조용히 누락된다. 에러 메시지조차 "자동 재시도를 설정하라"고 대놓고 알려주고 있었다.

그래서 두 가지를 넣었다. 하나는 각 노드 Settings의 Retry On Fail로 일시적 오류(네트워크, API 순간 장애, 방금 그 503)에 자동 재시도. 다른 하나는 에러 브랜치다. n8n은 노드가 실패했을 때 흐를 별도 출력(On Error → Continue using error output)을 만들 수 있는데, 이 에러 갈래를 "처리 실패" Slack 알림으로 연결했다.

이러면 회의록 처리가 실패해도 그냥 사라지지 않고, "OO 회의록 처리 중 오류 발생"이라는 알림이 온다. 회의록이 조용히 누락되는 일이 없어진다. 애초에 이 프로젝트를 시작한 이유가 "결정이 누락되는 걸 못 견뎌서"였는데, 그 자동화 자체가 조용히 누락되면 앞뒤가 안 맞으니까.

완성된 파이프라인

최종 워크플로우는 이렇게 생겼다.

Google Drive Trigger (새 회의록)
  → IF (Google Docs 문서만 통과)
  → Google Docs (텍스트 읽기)
  → Basic LLM Chain (+ Auto-fixing Parser)  → 구조화된 JSON
      ├─→ Slack (요약·결정사항 발송)
      └─→ Split Out (actionItems 펼치기)
            → 이슈 생성 (아이템마다 하나씩)
      [에러 발생 시] → Slack (실패 알림)

회의가 끝나면, 아무도 손대지 않아도 요약이 Slack에 뜨고 할 일이 이슈로 등록된다. 6편에 걸쳐 만든 것이 이 한 흐름이다.

오늘 막혔던 것 / 메모

• 외부 연동은 OAuth보다 토큰이 편할 때가 많다 — GitHub는 Personal Access Token, Slack은 OAuth2와 Bot Token(xoxb-) 중 선택. 셀프호스팅에선 리다이렉트 설정이 없는 토큰 방식이 대체로 빠르다.
• Slack 봇을 채널에 초대해야 함 — 연결만 하고 채널에 초대 안 하면 메시지 발송이 실패한다.
• 일시적 503은 반드시 만난다 — LLM API도 외부 서비스라 순간 과부하로 죽을 수 있다. Retry On Fail은 선택이 아니라 필수.
• Split Out 경로 확인 — 펼칠 배열의 정확한 경로(actionItems인지 그 상위를 거치는지)를 INPUT 패널에서 확인해야 빈 결과를 피한다.

마지막 관문: 실제로 자동으로 돌게 하기

여기까지는 Fetch Test Event와 Execute step으로 수동 실행하며 만들었다. 실제로 회의 후 자동으로 돌게 하려면 두 가지가 남는다.

하나, 워크플로우 활성화. 4편에서 짚었듯 트리거는 워크플로우가 Active 상태여야 자동으로 돈다. 우측 상단에서 활성화한다.

둘, 24시간 켜져 있는 환경. Drive 트리거는 폴링이라, 내 로컬 도커가 꺼져 있으면 그동안의 회의록을 놓친다. 그래서 실제 운용하려면 항상 켜진 서버가 필요하다. 나는 로컬에서 개발을 끝낸 뒤 클라우드로 옮길 계획이다. 이 배포 과정은 그 자체로 이야깃거리라, 별도 글로 다루려 한다.

시리즈를 마치며 — 코드로 자동화하던 사람이 배운 것

0편에서 나는 "코드로 자동화하던 QA 엔지니어가 왜 노코드를 배우는가"라는 질문으로 시작했다. 여섯 편을 지나 답을 정리할 수 있게 됐다.

노코드는 코드의 하위 호환이 아니다. 처음엔 "이거 그냥 코드로 짜면 되는데"라는 생각을 계속했다. 실제로 단발성 스크립트라면 코드가 빠르다. 하지만 트리거, 인증, 재시도, 분기, 배열 처리, LLM 파싱 복구 같은 주변 뼈대를 매번 직접 만드는 비용을 n8n이 걷어가자, 나는 로직과 설계에만 집중할 수 있었다. 이번 프로젝트에서 내가 실제로 고민한 건 노드 배치가 아니라 "무엇을 검증하고, 어떤 경계 조건을 정의하고, 실패를 어떻게 드러낼 것인가"였다. 그건 QA 경험 그 자체였다.

동시에, 노코드도 결국 이해가 필요하다. OAuth의 복잡함(4편), LLM의 비결정성(5편), 아이템 단위 실행의 원리(3편)는 노코드라고 사라지지 않았다. 오히려 이 원리를 알아야 노드를 제대로 조립할 수 있었다. "버튼만 누르면 되는" 도구가 아니라, "구조를 이해한 사람이 빠르게 조립하는" 도구에 가까웠다.

그래서 이 시리즈의 진짜 결론은 이거다. 자동화의 본질은 도구가 아니라 문제 정의에 있다. 코드로 짜든 노드로 잇든, "회의에서 정한 것이 실행에서 누락된다"는 문제를 발견하고, 그걸 해결하는 흐름을 설계하는 일은 똑같이 사람의 몫이다. 도구는 그 설계를 얼마나 빨리 현실로 만드느냐의 차이일 뿐이다.

여기까지 긴 시리즈를 따라와 주셔서 감사합니다. 처음 n8n을 켜던 0편의 나보다, 지금은 조금 더 넓은 자동화의 지도를 갖게 된 것 같다. 다음엔 이 파이프라인을 실제 서비스 데이터에 붙여보는 이야기로 찾아오겠습니다. 🙌

n8n 학습기 시리즈 — 5편. 토이 프로젝트 (2): LLM으로 요약과 액션아이템 뽑기 4편에서 회의록 텍스트가 워크플로우 안으로 들어왔다. 이제 그 텍스트를 LLM에 넘겨, 사람이 읽을 요약과 기계가 처리할 수 있는 구조화된 액션아이템을 뽑아낸다. 그런데 LLM은 생각보다 말을 안 들었다.

들어가며

4편의 결과물은 "회의 원문 대화가 담긴 한 덩어리의 텍스트"였다. 사람이 읽을 순 있지만, 그것만으로는 아무 일도 일어나지 않는다. 우리 목표는 요약을 넘어 액션아이템을 이슈 트래커에 자동 등록하는 것이다(6편). 그러려면 텍스트가 아니라 데이터가 필요하다.

즉 이번 편의 진짜 과제는 "LLM에게 요약을 시키는 것"이 아니다. LLM이라는 비결정적인 녀석에게서, 다음 노드가 믿고 쓸 수 있는 형태의 출력을 안정적으로 받아내는 것이다. QA 하던 입장에서 보면 익숙한 문제다. 신뢰할 수 없는 컴포넌트의 출력을 어떻게 검증하고 방어할 것인가. 그리고 이 편을 쓰는 내내, 정확히 그 문제로 씨름했다.

두 가지 출력이 필요하다

회의록에서 뽑을 건 성격이 다른 두 가지다.

• 사람이 읽을 것 — 요약, 결정사항. Slack에 그대로 붙여넣을 자연어.
• 기계가 처리할 것 — 액션아이템. 이슈로 등록하려면 담당자·할일·기한·우선순위가 필드로 분리돼 있어야 한다.

후자가 이 프로젝트의 핵심이다. "회의 요약 봇"은 앞의 것만 하고 끝나지만, 우리는 뒤의 것까지 가야 한다. 그래서 원하는 출력은 이런 모양이다.

{
  "summary": "로그인 버그 수정과 회원가입 리뉴얼 일정을 논의함",
  "decisions": ["회원가입 페이지 리뉴얼은 다음 스프린트로 연기"],
  "actionItems": [
    {
      "assignee": "홍길동",
      "task": "로그인 버그 수정",
      "dueDate": "2026-07-17",
      "priority": "high"
    }
  ]
}

이 형태로 나오면 6편에서 actionItems 배열을 순회하며 이슈를 하나씩 만들 수 있다. 3편에서 배운 아이템 단위 실행이 거기서 쓰인다.

n8n의 AI 노드 구조

n8n에서 LLM을 쓰는 방식은 처음 보면 낯설다. 노드 하나가 아니라 여러 노드가 붙어서 한 덩어리로 동작한다.

• Basic LLM Chain — 루트 노드. 프롬프트를 정의하고 결과를 내보낸다.
• Chat Model — 서브노드. 어떤 모델을 쓸지와 API 키를 설정한다. LLM Chain 아래에 매단다.
• Structured Output Parser — 서브노드. 출력을 정해진 JSON 스키마로 강제한다.

AI Agent 노드와 헷갈릴 수 있는데, Agent는 도구를 호출하고 여러 단계로 추론하는 물건이고 Basic LLM Chain은 프롬프트 하나 넣고 응답 하나 받는 단순한 물건이다. 우리 목적(텍스트 → 구조화된 데이터)엔 Chain이 맞다.

첫 번째 벽: 모델 이름이 계속 죽어 있다

Chat Model로 Gemini를 골랐다. 무료 티어가 있고, 4편에서 이미 구글 생태계에 들어와 있으니 자연스러운 선택이었다. Google AI Studio에서 API 키를 발급받아 연결했다. 여기까지는 순조로웠다. 문제는 모델 선택이었다.

튜토리얼을 보고 gemini-2.0-flash를 골랐더니 이런 에러가 났다.

[429] Quota exceeded ... limit: 0, model: gemini-2.0-flash

limit: 0. 무료 할당이 초과된 게 아니라 아예 0이었다. 알고 보니 이 모델은 이미 폐기되어 퇴역한 상태였다. 그럼 다음 버전, 하고 gemini-2.5-flash로 바꿨다.

[404] This model is no longer available to new users.

이번엔 "신규 사용자에겐 제공 안 함"이었다. 나는 방금 키를 발급받은 신규 사용자였다. 결국 당시 신규 사용자가 쓸 수 있는 최신 Flash 계열(gemini-3-flash-preview)로 바꾸고 나서야 응답이 왔다.

여기서 얻은 교훈은 기술적인 게 아니라 습관에 관한 것이다. LLM 모델명은 몇 달 단위로 죽고 태어난다. 어제 글에 나온 모델이 오늘 404가 된다. 그래서 특정 모델명을 외우는 건 의미가 없고, Google AI Studio에서 지금 내 계정으로 실제 호출되는 모델이 뭔지 확인하는 습관을 들이는 게 맞다. AI Studio 드롭다운에 뜨는 모델은 같은 키로 n8n에서도 된다. (이 글을 읽는 시점엔 또 다른 이름일 것이다. 그러니 이름 말고 이 방법을 기억하길.)

프롬프트 설계

모델이 응답하기 시작하자 본격적인 작업이 시작됐다. Basic LLM Chain의 프롬프트에 4편에서 읽어온 회의록 텍스트를 표현식으로 꽂고(2편 문법), 시스템 메시지에 지시를 넣었다. 지키려 한 원칙이 몇 가지 있다.

하나, 역할과 작업을 분리한다. 시스템 메시지엔 지속적인 지시("너는 회의록에서 실행 가능한 항목을 추출하는 도우미다")를, 사용자 메시지엔 매번 달라지는 회의록 본문을 넣는다.

둘, 출력 형식을 예시로 보여준다. 스키마를 말로 설명하는 것보다 원하는 출력의 실제 예시를 넣는 게 훨씬 잘 먹힌다.

셋, 애매한 경우의 규칙을 미리 정한다. 회의록은 깔끔하지 않다.

• 담당자가 명시되지 않은 할일은? → assignee를 null로
• "다음 주까지" 같은 상대 표현은? → 회의 날짜 기준으로 계산해 YYYY-MM-DD로
• 액션아이템이 없는 회의는? → 빈 배열 [] (억지로 만들지 말 것)
• "미루기로 결정" 같은 건? → 액션아이템이 아니라 decisions로

이런 경계 조건을 명시하지 않으면 LLM은 매번 다르게 처리한다. 테스트 케이스를 설계할 때 경계값부터 잡던 습관이 프롬프트 설계에도 그대로 쓰였다.

넷, 어떤 부분을 근거로 삼을지 못 박는다. 실제 회의록을 열어보니 Google Workspace가 한 문서 안에 자동 요약과 원문 스크립트를 두 탭으로 넣어줬고, Docs 노드로 읽으면 둘이 섞여 들어왔다. 텍스트를 물리적으로 자르는 건 구조 변화에 약하니, 프롬프트로 통제했다. "요약은 무시하고 원문 스크립트만 근거로 삼아라. 원문에 근거가 없는 내용은 포함하지 마라." 자동 요약은 Google이 이미 한 번 가공한 2차 정보다. 신뢰할 수 있는 원본과 파생물을 구분해 원본을 근거로 삼게 한 것이다.

여기서 한 번 짚고 갈 질문. Google이 이미 요약해주는데 왜 직접 뽑나? 답은 형식의 통제권이다. Google의 요약은 사람이 읽기 좋은 자연어지만, 이슈로 자동 등록하려면 {담당자, 할일, 기한}으로 필드가 분리된 데이터가 필요하다. 그 필드와 규칙을 내 업무에 맞게 통제하려면, 범용 요약이 아니라 내 워크플로우 전용 추출이 필요하다. 이게 이 프로젝트가 존재하는 이유다.

두 번째 벽: LLM은 약속을 안 지킨다

프롬프트를 공들여 짜고 실행했더니 이 에러가 떴다.

Model output doesn't fit required format

모델이 응답은 했는데, 그 응답이 Structured Output Parser가 요구하는 JSON 형식에 안 맞는다는 뜻이다. 출력을 뜯어보니 원인은 매번 조금씩 달랐다. 어떤 날은 ```json 코드펜스로 감쌌고, 어떤 날은 "네, 다음과 같이 정리했습니다" 같은 말을 앞에 붙였고, 어떤 날은 값이 없는 필드를 아예 빼버렸다.

중요한 건 이게 버그가 아니라 특성이라는 점이다. 언어 모델은 본질적으로 비결정적이라, 온도를 0으로 낮춰도 출력이 흔들린다. 그래서 "JSON으로만 답해"라고 아무리 적어도 완벽히 지켜지지 않는다. QA를 해본 사람에게 이 패턴은 익숙하다. 가끔 실패하는 게 항상 실패하는 것보다 훨씬 위험하다. 20번 잘 되다 21번째에 깨지는 컴포넌트가 제일 무섭다.

방어선 1 — 프롬프트를 더 강하게

첫 번째 대응은 프롬프트 강화였다. 시스템 메시지 끝에 출력 형식 규칙을 독립된 블록으로 분리해서 못 박았다.

• 유효한 JSON 객체 하나만 출력한다
• 코드블록 표시(```)를 붙이지 마라
• JSON 앞뒤에 인사말이나 설명을 붙이지 마라
• 값이 없는 필드는 생략하지 말고 반드시 null을 넣어라
• 모든 문자열은 큰따옴표를 쓴다

특히 "필드를 생략하지 말고 null"이 중요했다. Structured Output Parser를 JSON 예시로 생성하면 모든 필드가 필수로 잡히는데, LLM이 dueDate가 없다고 그 필드를 빼면 "형식 불일치"로 실패하기 때문이다. 값이 없어도 null을 채우게 하면 이 문제가 준다.

이걸로 성공률이 확 올라갔다. 하지만 0이 되지는 않았다.

방어선 2 — Auto-fixing Output Parser

프롬프트로 아무리 조여도 가끔은 형식을 어겼다. 결국 프롬프트만으로는 못 잡는다는 걸 인정하고, 두 번째 방어선을 얹었다. Auto-fixing Output Parser다.

이 노드는 파싱이 실패하면, 그 실패한 출력을 LLM에게 다시 보내 고쳐오게 한다. 구성이 조금 특이해서 정리해둔다.

Basic LLM Chain
 └─ (Model)         → Chat Model          [본 작업용]
 └─ (Output Parser) → Auto-fixing Output Parser
                        ├─ (Model)  → Chat Model            [고칠 때용]
                        └─ (Parser) → Structured Output Parser  [스키마]

핵심은 Structured Output Parser를 LLM Chain에 직접 붙이지 않고, Auto-fixing을 중간에 끼운다는 것이다. 스키마 검증은 여전히 Structured Output Parser가 하고, Auto-fixing은 그게 실패했을 때 재요청을 맡는다.

비용이 걱정될 수 있는데, 파싱이 실패했을 때만 추가 호출이 일어난다. 1차에서 잘 나오면 추가 비용은 없다.

QA 관점에서 이 구조가 마음에 들었다. 1차 검증(스키마) → 실패 시 자동 복구(재요청) → 재검증. 재시도 로직을 내가 짜지 않아도 되는 것, 이게 n8n이 대신 해주는 뼈대의 좋은 예다. 코드로 짰다면 응답을 파싱하고, 실패를 잡고, 프롬프트를 다시 구성해 재호출하는 걸 전부 손으로 만들었을 것이다.

방어선 3 — 그래도 실패하면 조용히 넘기지 않기

두 겹을 쌓아도 실패는 0이 안 된다. 그래서 세 번째 원칙은 "조용히 실패하지 않게 하는 것"이다.

n8n 노드 Settings에 On Error 옵션이 있다. 이걸 Continue로 두면 실패해도 워크플로우가 멈추지 않는다. 편해 보이지만, 아무 장치 없이 이것만 켜면 회의록이 처리 안 됐는데 아무도 모르는 상황이 된다. QA에서 제일 싫어하는 게 이 silent failure다.

그래서 방향은 이렇다. 일시적 오류엔 Retry On Fail로 재시도하되, 최종 실패는 넘기지 말고 실패했다는 사실을 알림으로 보낸다(6편에서 구현). 자동화가 신뢰를 얻으려면, 실패했을 때 실패했다고 말해줘야 한다.

실행해보니

여러 방어선을 쌓고 테스트용 회의록을 넣었다.

"다음 주 금요일까지 로그인 버그 수정하기로 했고 담당은 OOO입니다. 회원가입 페이지 리뉴얼은 다음 스프린트로 미루기로 결정했습니다. 디자인 시안은 수요일까지 공유하기로 했습니다."

출력에 summary, decisions, actionItems가 스키마대로 안정적으로 들어왔다. "다음 주 금요일"이 실제 날짜로 변환되고, "미루기로 결정"이 액션아이템이 아니라 decisions로 분류되고, 요약 탭이 아니라 원문 기준으로 뽑힌 게 확인됐다. 프롬프트에 규칙을 명시하고 방어선을 쌓은 효과다.

코드로 자동화하던 관점에서

• Basic LLM Chain → LLM API를 호출하는 함수
• Chat Model 서브노드 → API 키와 모델을 주입하는 것
• Structured Output Parser → 응답 스키마 검증(JSON Schema 밸리데이션)
• Auto-fixing Parser → 검증 실패 시 재요청하는 재시도 로직

코드로 짰다면 이 네 가지를 다 직접 만들었을 것이다. 특히 파싱 실패 시 재요청 로직은 매번 새로 짜기 귀찮다. 그걸 서브노드 하나로 대신하는 건 확실히 편했다.

다만 프롬프트 설계와 경계 조건 정의는 누구도 대신해주지 않는다. 노코드든 코드든, "무엇을 검증할 것인가"를 정하는 건 사람의 일이다. 이 부분에서 QA 경험이 그대로 쓰였다. 결국 이번 편의 진짜 작업은 노드 배치가 아니라, 믿을 수 없는 출력을 믿을 수 있게 만드는 설계였다.

오늘 막혔던 것 / 메모

• 모델명이 죽어 있음 — gemini-2.0-flash는 퇴역(limit: 0), gemini-2.5-flash는 신규 사용자 차단(404). 모델명은 자주 바뀌니 AI Studio에서 지금 쓸 수 있는 걸 확인하는 게 답이다.
• 출력이 형식을 안 지킴 — 코드펜스, 앞뒤 잡담, 필드 누락. 프롬프트로 못 박되, "값 없으면 null" 지시가 특히 효과적이었다.
• 프롬프트로도 0%는 안 됨 — 결국 Auto-fixing Output Parser로 자동 복구를 얹어야 안정된다.
• 회의록에 요약 탭이 딸려 옴 — 원문과 요약이 한 문서에. 자르지 말고 "원문만 근거로"를 프롬프트로 지시하는 게 낫다.
• 스키마가 너무 빡빡하면 — JSON 예시로 만들면 모든 필드가 필수가 된다. 계속 실패하면 JSON Schema 직접 정의로 바꿔 필수 필드를 최소화한다.

마치며

5편의 결론은 이렇다. LLM에게 일을 시키는 것보다, LLM의 출력을 믿을 수 있게 만드는 것이 더 어렵고 더 중요하다. 프롬프트로 형식을 못 박고, Structured Output Parser로 스키마를 강제하고, Auto-fixing으로 복구하고, 실패는 조용히 넘기지 않는다. 이게 비결정적 컴포넌트를 실무에 쓰는 방법이다.

이제 손에 구조화된 액션아이템 데이터가 들어왔다. 다음 6편에서는 이걸 Slack 요약 발송과 이슈 자동 등록으로 연결한다. 3편에서 배운 아이템 단위 실행이 진가를 발휘한다. 액션아이템 배열이 아이템으로 쪼개져, 각각이 이슈 하나가 되는 것이다. 요약만 하는 봇과 실행까지 이어지는 자동화의 차이가, 마지막 편에서 완성된다.

읽어주셔서 감사합니다. 🙌

n8n 학습기 시리즈 — 4편. 토이 프로젝트 (1): 데이터 진입점 뚫기 개념 세 편(데이터 흐름, 표현식, 제어 흐름)을 지나 이제 실전이다. 이번 편의 목표는 단 하나, 실제 회의록이 n8n 워크플로우 안으로 들어오게 만드는 것이다.

들어가며

회의는 잘 한다. 문제는 그 다음이다. "이건 누가, 언제까지"까지 정해놓고도, 회의가 끝나면 결정사항이 흐지부지 흩어진다. 누군가 정리해 공유하면 다행이지만 그것도 매번 손이 간다.

QA를 하면서 몸에 밴 감각이 하나 있다. 결정된 것이 실행에서 누락되는 지점을 못 견디는 것. 테스트 케이스가 빠지면 버그가 새듯, 회의에서 정한 액션아이템이 빠지면 일이 샌다. 그래서 이걸 자동화해보기로 했다. 지금까지 배운 n8n으로.

무엇을 만드나

만들려는 파이프라인은 이렇다.

화상 회의가 끝난다 → 회의록이 자동 저장된다 → n8n이 감지해 읽는다 → LLM이 요약과 액션아이템을 뽑는다 → 요약은 Slack으로, 액션아이템은 이슈로 자동 등록된다.

단순한 "회의 요약 봇"에서 멈추지 않고, 뽑아낸 액션아이템을 담당자·기한이 있는 구조로 정리해 실제 이슈 트래커까지 자동 등록하는 것까지가 목표다. 요약만 하는 봇과 실행까지 이어지는 자동화의 차이가 거기서 갈린다.

전체를 한 편에 담기엔 크니 이렇게 나눈다.

• 4편 (이 글) — 회의록을 n8n 안으로 가져오기
• 5편 — LLM으로 요약과 액션아이템 뽑기
• 6편 — Slack 알림 + 이슈 자동 등록으로 실행까지 연결

회의록은 어디서 오나

데이터 소스부터. 화상 회의는 Google Meet을 쓴다. Meet은 회의 중 트랜스크립트를 켜두면, 회의가 끝난 뒤 대화 내용을 Google Docs 문서로 만들어 주최자의 Drive에 자동 저장해준다. 이게 파이프라인의 출발 데이터다.

두 가지를 짚어둔다. 이 자동 트랜스크립트 기능은 자격이 되는 Google Workspace 구독이 필요하다(개인 무료 Gmail로는 안 된다). 그리고 트랜스크립트는 회의를 주최한 계정의 Drive에 저장되므로, 회의는 그 계정으로 여는 게 좋다.

한 가지 의도적인 선택도 있다. 나는 Google이 만들어주는 AI 요약이 아니라 대화 원문 트랜스크립트를 쓴다. 요약은 5편에서 LLM에게 시킬 일이라, Google이 미리 요약해버리면 이 프로젝트의 재미가 사라진다.

첫 번째 관문: 셀프호스팅 n8n에 구글 붙이기

여기가 이번 편에서 제일 험한 구간이다. 실제로 4편 작업 시간의 대부분을 여기서 썼다.

n8n Cloud라면 "Sign in with Google" 버튼 하나로 끝난다. 그런데 도커로 셀프호스팅하는 경우엔 그게 안 된다. Google Cloud Console에서 직접 OAuth 앱을 만들어 n8n에 연결해야 한다.

순서가 중요하다. 구글부터 가면 두 번 왔다갔다 하게 되니, n8n에서 리다이렉트 URL을 먼저 확보하고 구글로 넘어가는 게 낫다.

1. n8n에서 Google Drive Trigger 노드를 추가하고, 자격증명 생성 화면을 연다. 여기 표시되는 OAuth Redirect URL을 복사한다(.../rest/oauth2-credential/callback 형태).
2. Google Cloud Console에서 프로젝트를 만들고, Google Drive API와 Google Docs API를 켠다.
3. OAuth 동의 화면을 구성한다. Workspace 계정이면 User Type을 Internal로 할 수 있는데, 이게 훨씬 편하다(테스트 유저 등록도, 뒤에 말할 7일 만료 문제도 없다).
4. OAuth 클라이언트 ID(Web application)를 만들고, Authorized redirect URIs에 1번에서 복사한 URL을 붙여넣는다.
5. 발급된 Client ID와 Client Secret을 n8n 자격증명에 입력하고 연결한다.

로컬 도커 사용자에게 다행인 점 하나. 공개 도메인이나 SSL, 포트포워딩이 없어도 된다. 구글이 개발 목적의 localhost 리다이렉트를 허용해주기 때문이다.

두 번째 관문: 자격증명은 서비스마다 따로다

여기서 내가 헛다리를 짚었다.

Drive 연결을 끝내고 뿌듯한 마음으로 Google Docs 노드를 붙였는데, 실행하자마자 이런 에러가 떴다.

Node does not have any credentials set

표현식도 제대로 걸었고 문서 ID도 미리보기에 잘 뜨는데 왜? 알고 보니 n8n에서 Google Drive와 Google Docs는 서로 다른 자격증명 타입이었다. Drive Trigger에 붙인 "Google Drive account"는 Docs 노드에서 쓸 수 없다. Docs는 Google Docs OAuth2 API 자격증명을 따로 요구한다.

당황할 필요는 없다. Google Cloud Console에서 앱을 새로 만들 필요는 없기 때문이다. 같은 OAuth 앱의 Client ID와 Secret을 그대로 다시 입력하고 로그인만 한 번 더 하면 된다. 요컨대 구글 쪽 앱은 하나, n8n 쪽 자격증명은 서비스별로 하나씩이다. 이 구분을 몰라서 "분명 연결했는데 왜 없다고 하지?"로 한참 헤맸다.

(그래서 2번 단계에서 Docs API도 미리 켜두라고 적었다. Drive API만 켜두면 로그인은 되는데 실행 시점에 API not enabled로 또 막힌다.)

Drive 트리거로 새 회의록 감지하기

연결이 됐으면 트리거를 놓는다. Google Drive Trigger 노드는 지정한 폴더를 주기적으로 확인(폴링)해서 새 파일을 감지한다.

설정은 단순하다. Trigger On을 Changes Involving a Specific Folder로 두고, 감시할 폴더를 지정하고, Watch For를 File Created로 고른다. Poll Times는 기본값(1분마다)이면 충분하다.

여기서 알아둘 점 몇 가지. My Drive 전체를 감시하면 아무 파일에나 반응하니 폴더를 콕 집어야 한다. 그리고 노드 안내문에 적혀 있듯 하위 폴더의 변경은 감지하지 않는다. 또 트리거가 실제로 자동 실행되려면 워크플로우가 활성화(Active) 상태여야 한다. 에디터에서 열어만 둔 상태로는 돌지 않는다. 개발 중엔 Fetch Test Event 버튼으로 최근 파일을 하나 가져와 테스트하면 된다.

세 번째 관문: 폴더엔 회의록만 있는 게 아니다

Fetch Test Event를 눌렀더니 파일 하나가 잡혔다. 그런데 열어보니 회의록이 아니었다.

"name": "...분석.docx",
"mimeType": "application/vnd.openxmlformats-officedocument.wordprocessingml.document"

내가 감시하도록 지정한 폴더에 예전에 넣어둔 Word(.docx) 파일이 있었던 것이다. 그리고 이건 그냥 실수가 아니라, 실제 운영에서 반드시 만나는 문제다. 폴더는 회의록 전용이 아니고, 사람들은 거기에 아무 파일이나 넣는다.

문제가 되는 이유는 명확하다. Google Docs 노드는 네이티브 Google Docs 문서(application/vnd.google-apps.document)만 읽을 수 있다. Word 파일이 들어오면 그대로 터진다.

QA 하던 버릇이 발동했다. 입력이 기대한 형식인지 먼저 검증해야 한다. 그래서 트리거 뒤에 3편에서 배운 IF 노드를 붙여, mimeType이 Google Docs인 아이템만 통과시키기로 했다.

{{ $json.mimeType }}  →  is equal to  →  application/vnd.google-apps.document

개념 편에서 배운 분기가 프로젝트에서 처음 실전으로 쓰이는 순간이었다. 3편의 IF가 여기서 이렇게 쓰일 줄은 그때는 몰랐다.

회의록 내용 읽어오기

이제 감지한 파일에서 텍스트를 꺼낸다. Google Docs 노드의 Get 동작을 쓴다.

핵심은 Doc ID or URL 필드다. 여기에 고정값을 넣으면 안 된다. 트리거가 방금 감지한 그 파일을 읽어야 하기 때문이다. 그래서 필드를 Expression 모드로 바꾸고 이렇게 넣는다.

{{ $json.id }}

2편에서 배운 드래그앤드롭 매핑이 실전에서 처음 쓰이는 순간이다. 왼쪽 INPUT 패널에서 id 필드를 끌어다 놓으면 표현식이 자동 생성되고, 필드 아래 미리보기에 실제 문서 ID가 뜬다.

여기서 잠깐 헷갈릴 수 있다. 트리거가 넘겨주는 JSON에는 permissionId, headRevisionId, thumbnailVersion 등 id처럼 생긴 필드가 여럿 있다. 우리가 쓸 건 최상위의 id 하나다. 이게 파일 자체의 고유 ID고, webViewLink의 /document/d/ 뒤에 붙는 그 값과 같다.

Execute step을 누르면 오른쪽 OUTPUT에 문서 내용이 들어온다. 노드의 Simplify 옵션을 켜두면 응답이 간소화되어 다루기 편하다.

여기까지의 확인

이번 편에서 만든 흐름은 이렇게 정리된다.

Google Drive Trigger(새 파일 감지) → IF(회의록만 통과) → Google Docs(텍스트 읽기)

실제로 회의를 한 번 하고 트랜스크립트를 켠 뒤, 그 파일이 폴더에 저장되고 n8n이 내용을 읽어오면 성공이다.

코드로 자동화하던 시절이라면 파일 시스템을 감시하고, OAuth 토큰을 갱신하고, Docs API를 파싱하는 코드를 직접 짰어야 할 부분이다. 그걸 노드 세 개로 대신했다. 다만 인증만큼은 "노드 하나로 대신"이 전혀 아니었다. 노코드 툴이라도 결국 OAuth의 복잡함은 그대로 마주해야 한다는 게 이번 편의 솔직한 소감이다.

오늘 막혔던 것 / 메모

• 자격증명이 서비스마다 별개 — Drive에 연결했다고 Docs가 되는 게 아니다. 구글 쪽 OAuth 앱은 하나로 재사용하되, n8n 자격증명은 서비스마다 따로 만들어야 한다.
• API를 안 켜서 나는 에러 — Drive API만 켜고 Docs API를 빠뜨리면, 연결은 되는데 실행에서 막힌다. 쓸 노드의 API는 미리 다 켜두자.
• redirect_uri_mismatch — n8n 자격증명 화면의 리다이렉트 URL과 Google Console에 등록한 URI가 한 글자라도 다르면 난다. 화면의 URL을 그대로 복사해 붙이는 게 안전하다.
• 7일 뒤 연결이 풀림 — OAuth 앱이 External + Testing 상태면 토큰이 약 7일 후 만료된다. Workspace 계정으로 Internal을 쓸 수 있으면 그게 편하다.
• 엉뚱한 파일이 트리거를 깨움 — 폴더엔 회의록만 있는 게 아니다. mimeType 검증은 선택이 아니라 필수다.
• 트리거가 안 울림 — 워크플로우가 비활성 상태이거나, 폴더 지정이 잘못됐거나 둘 중 하나였다.

마치며

셀프호스팅 n8n에 구글을 연결하고, Drive 트리거로 새 회의록을 감지해, mimeType으로 걸러낸 뒤, Docs 노드로 텍스트를 읽어온다. 인증 관문이 무겁지, 넘고 나면 흐름 자체는 노드 세 개로 단순하다.

이제 손에 회의 원문 텍스트가 들어왔다. 다음 5편에서는 이 텍스트를 LLM에 넣어, 요약과 결정사항, 그리고 담당자·기한이 있는 액션아이템을 구조화된 JSON으로 뽑아낸다. 2편에서 다진 표현식과 JSON 감각이 거기서 진짜로 쓰인다.

읽어주셔서 감사합니다. 🙌

n8n 학습기 시리즈 — 3편. 제어 흐름: IF, Switch, 그리고 아이템 단위 실행 1편에서 던졌던 질문, "왜 데이터를 굳이 배열로 감싸지?"의 진짜 답이 이번 편에 있다. 개념 파트의 마지막 편이다.

들어가며

지금까지는 데이터가 한 건일 때를 다뤘다. 1편에서 HTTP로 하나 가져오고, 2편에서 그 하나를 표현식으로 가공했다. 그런데 실제 자동화는 대개 여러 건을 다룬다. 메일 여러 통, 행 여러 개, 상담 여러 건. 게다가 조건에 따라 처리 경로가 갈린다. "완료된 건과 아닌 건을 다르게 처리한다" 같은 것.

이번 편은 그 두 가지, 여러 아이템을 어떻게 도는가와 어떻게 갈래를 나누는가를 정리한다.

아이템 단위 실행 — n8n이 대신 돌려주는 for 루프

1편에서 데이터가 항상 아이템 배열로 흐른다고 했다. 그리고 "왜 배열로 감싸지?"라고 물었었다. 답은 이렇다.

n8n의 노드는 입력으로 들어온 아이템 배열의 각 아이템에 대해 자동으로 반복 실행된다.

예를 들어 HTTP Request가 할 일 5개를 배열로 가져오면, 그 뒤에 붙은 노드는 5개 아이템 각각에 대해 한 번씩 동작한다. 내가 for 루프를 짜서 배열을 순회하지 않아도, 플랫폼이 각 아이템에 노드 로직을 알아서 적용해준다. 코드로 치면 이런 걸 n8n이 암묵적으로 해주는 셈이다.

// 내가 코드로 짜던 것
for (const item of items) {
  process(item);
}

// n8n에서는: 노드를 하나 놓으면 위 루프가 자동으로 돈다

이게 1편 질문의 답이다. 데이터를 항상 배열로 두는 이유는, 노드가 "한 건이든 여러 건이든 똑같은 코드로" 각 아이템을 처리할 수 있게 하기 위해서다. 단건은 그냥 원소가 하나인 배열일 뿐이다.

그럼 루프 노드는 어디 있나

여기서 나는 헤맸다. "여러 개를 도는 거면 루프 노드가 있어야 하는 거 아냐?" 하고 찾아다녔다. 그런데 대부분의 경우 루프 노드는 필요 없다. 방금 본 것처럼 반복은 기본으로 일어나기 때문이다.

물론 반복을 직접 제어해야 하는 노드도 있다. 그럴 때 쓰는 게 Loop Over Items 노드다(노드를 검색하면 괄호로 Split in Batches라는 옛 이름이 같이 뜨는데, 같은 노드다). 이 노드는 아이템을 정해진 크기(batch size)로 잘라 한 묶음씩 처리한다. 주된 쓰임새는 API 호출 rate limit 대응이다. 한 번에 다 보내면 막히는 API에, 10개씩 보내고 잠깐 쉬고(Wait 노드), 다시 10개 보내는 식으로 조절할 때 쓴다.

정리하면 이렇다. 단순히 "여러 개를 처리"하려고 루프 노드를 넣을 필요는 없다. 그건 자동이다. 루프 노드는 "몇 개씩 나눠서, 속도를 조절하며" 돌려야 할 때만 꺼내면 된다.

한 가지 주의. 모든 노드가 자동 반복하는 건 아니다. 일부 노드는 첫 아이템만 처리하거나 전체를 한 덩어리로 다룬다(예: RSS 읽기, 특정 DB 삽입 동작, "Run Once for All Items" 모드의 Code 노드). 이런 예외 노드를 만나면 그때 Loop Over Items로 직접 루프를 짜야 한다. 반대로, 여러 아이템 중 첫 번째만 처리하고 싶으면 노드 Settings 탭의 Execute Once를 켜면 된다.

갈래 나누기 1 — IF 노드

이제 조건 분기다. 가장 기본은 IF 노드다. 조건을 평가해서 아이템을 true 출력과 false 출력 두 갈래로 내보낸다. 코드의 if / else와 정확히 같다.

예를 들어 할 일 목록에서 "완료된 것과 아닌 것"을 나눈다고 하면, IF 노드에 이런 조건을 건다.

{{ $json.completed }}  →  is true

그러면 completed가 true인 아이템은 위쪽(true) 출력으로, 나머지는 아래쪽(false) 출력으로 흘러간다. 각 갈래에 서로 다른 노드를 붙이면 경로별로 다르게 처리할 수 있다.

조건은 여러 개를 조합할 수도 있다. AND로 묶으면 모든 조건이 참일 때, OR로 묶으면 하나라도 참일 때 true가 된다. 한 가지 실무 팁은, 최신 IF 노드는 타입 검증(type validation)이 엄격(strict)이라 문자열 "true"와 불린 true를 다르게 본다는 점이다. 값 타입이 안 맞으면 조건이 조용히 안 걸리니, 미리보기로 실제 평가 결과를 확인하는 게 안전하다.

갈래 나누기 2 — Switch 노드

IF는 갈래가 둘이다. 그런데 "상태가 new면 A, processing이면 B, done이면 C"처럼 셋 이상으로 나눠야 할 때가 있다. 이때 IF를 여러 개 사슬처럼 잇는 대신 Switch 노드를 쓴다.

Switch는 표현식 하나를 여러 값과 비교해서 각각에 맞는 갈래로 아이템을 보낸다. 코드의 switch 문과 같다.

{{ $json.status }}  →  "new" | "processing" | "done" ...

IF를 사슬로 잇는 것과 Switch의 차이를 기록해두면, IF 체인은 아이템이 매번 위에서부터 조건을 거치며 첫 매치에서 멈추는 반면, Switch는 한 번의 평가로 해당 갈래로 바로 보낸다. 캔버스도 훨씬 깔끔하다. 그래서 나는 규칙을 이렇게 잡았다. 갈래가 둘이면 IF, 셋 이상이면 Switch.

한 가지 함정도 있다. Switch는 여러 갈래 조건이 동시에 참일 때 첫 매치에서 멈추지 않고 매치되는 모든 갈래로 아이템을 보낸다. 의도한 게 아니라면 조건이 겹치지 않게 설계해야 한다.

다시 합치기 — Merge 노드

갈래로 나눴으면 다시 합쳐야 할 때가 온다. 이때 쓰는 게 Merge 노드다. 여러 갈래에서 흘러온 아이템을 하나의 흐름으로 모은다. 분기 → 각자 처리 → 병합이라는, 코드에서 조건별로 갈라 처리한 뒤 결과를 한 리스트로 다시 모으던 패턴과 같다.

작은 실습 — 여러 아이템을 IF로 나눠보기

개념을 확인해봤다. 1편 워크플로우를 살짝 바꿔서, 이번엔 여러 건을 가져온다.

1. HTTP Request의 URL을 여러 건 반환하는 주소로 바꾼다.

GET https://jsonplaceholder.typicode.com/todos?_limit=5

실행하면 이번엔 아이템이 5개 들어온다(1편에선 1개였다). 여기서 이미 "여러 아이템이 흐른다"가 눈에 보인다.

2. 그 뒤에 IF 노드를 붙이고 조건을 {{ $json.completed }} is true로 건다.
3. Execute step을 누른다.

실행하면 IF 노드의 두 출력이 갈린다. 완료된 할 일은 true 쪽으로, 아직인 것은 false 쪽으로 나뉘어 각각 몇 개인지 보인다. 노드를 하나 놨을 뿐인데 5개 아이템이 각자 조건을 평가받아 두 갈래로 정리된 것이다. "아이템 단위 실행 + 분기"가 한 화면에서 확인되는 순간이다.

코드로 자동화하던 관점에서

• 아이템 단위 실행 → 내가 짜던 for (item of items) 루프를 플랫폼이 암묵적으로 돌려주는 것
• Loop Over Items → 배치 크기와 대기를 직접 제어하는 명시적 루프(주로 rate limit 대응)
• IF 노드 → if / else
• Switch 노드 → switch 문
• Merge 노드 → 갈라 처리한 결과를 다시 한 리스트로 모으는 것

1편에서 "그냥 코드가 빠르겠는데?"라고 했던 감각이 여기서 한 번 더 흔들렸다. 여러 건을 도는 루프를 내가 안 짜도 된다는 것, 분기와 병합이 노드 몇 개로 눈에 보이게 정리된다는 것은, 로직의 큰 그림을 잡을 때 분명한 장점이었다. 반대로 세밀한 제어가 필요하면 언제든 Code 노드로 내려가면 되고.

오늘 막혔던 것 / 메모

• 루프 노드를 찾다 헤맴 — "여러 개니까 루프가 필요하겠지" 하고 Loop Over Items부터 넣었다가, 대부분 자동 반복이라 필요 없다는 걸 알고 걷어냈다. 루프 노드는 배치·속도 제어가 필요할 때만.
• IF 조건이 안 걸림 — 타입 검증이 엄격해서 문자열과 불린을 다르게 본다. "true"(문자열)와 true(불린)를 혼동하면 조건이 조용히 실패한다. 미리보기로 실제 값과 타입을 확인.
• Switch 다중 매치 — 조건이 겹치면 여러 갈래로 동시에 흘러간다. 갈래를 상호 배타적으로 설계하는 걸 기본으로.

마치며

개념 파트는 여기까지다. 세 편을 요약하면, 데이터는 아이템 배열로 흐르고(1편), 표현식으로 값을 꺼내 가공하고(2편), 아이템 단위로 자동 반복되며 IF와 Switch로 갈래를 나눈다(3편). 이 세 가지만 손에 익으면 n8n 워크플로우의 대부분은 이 위에 얹히는 조합으로 읽힌다.

다음 편부터는 실제 토이 프로젝트다. 지금까지 배운 트리거, 데이터 흐름, 표현식, 분기를 엮어서, 회의록에서 할 일을 자동으로 뽑아 정리하는 파이프라인을 만들어볼 생각이다. 개념이 실제 문제 앞에서 어떻게 조립되는지, 그 과정을 그대로 기록해보려 한다.

읽어주셔서 감사합니다. 🙌

n8n 학습기 시리즈 — 2편. 표현식과 데이터 변형 1편에서 데이터가 "아이템 배열 + json 키" 형태로 흐른다는 걸 봤다. 이번 편은 그 데이터를 실제로 꺼내 쓰고 가공하는 방법이다. 개인적으로 n8n에서 제일 헷갈리면서 제일 중요한 부분이라 시간을 들였다.

들어가며

1편의 결론은 "데이터가 노드 사이를 정해진 형태로 흐른다"였다. 그런데 흐르기만 해서는 소용이 없다. 앞 노드가 가져온 값을 뒤 노드에서 꺼내 쓰고, 필요하면 모양을 바꿔야 자동화가 된다. 그 연결고리가 표현식(Expression) 이다.

1편에서 만든 Trigger manually → HTTP Request 워크플로우를 그대로 이어서 진행한다. 그때 HTTP Request가 가져온 데이터는 이거였다.

[
  {
    "json": {
      "userId": 1,
      "id": 1,
      "title": "delectus aut autem",
      "completed": false
    }
  }
]

이 title, id 같은 값을 뒤 노드에서 어떻게 꺼내 쓰는지가 이번 편의 주제다.

표현식이란 — {{ }} 안의 자바스크립트

n8n의 표현식은 노드 입력 필드에 직접 써넣는 작은 자바스크립트 조각이고, {{ ... }} 중괄호로 감싼다. 예를 들면 이런 것들이 다 표현식이다.

{{ 2 + 3 }}
{{ "Hello " + "World" }}
{{ $json.title }}

노드의 파라미터 필드는 기본적으로 "고정값(fixed)" 모드다. 필드 옆의 토글(중괄호 아이콘)을 누르면 "표현식(expression)" 모드로 바뀌고, 그때부터 {{ }}를 써서 값을 동적으로 계산할 수 있다. 편집기가 마지막 실행 데이터를 기준으로 실시간 미리보기를 보여줘서, 표현식이 실제로 어떤 값으로 평가되는지 즉시 확인할 수 있다. 이 미리보기가 있어서 학습이 훨씬 수월했다.

$json — 현재 아이템의 데이터 꺼내기

가장 많이 쓰는 패턴이다. $json은 현재 노드로 들어온 입력 아이템의 json 데이터를 가리킨다. 정확히는 $input.item.json의 축약형이다.

1편의 응답 기준으로, 필드를 이렇게 꺼낸다.

{{ $json.title }}      // "delectus aut autem"
{{ $json.id }}         // 1
{{ $json.completed }}  // false

중첩된 객체는 점(.)으로 파고들고, 배열은 대괄호로 인덱싱한다.

{{ $json.user.email }}
{{ $json.items[0].name }}

1편에서 "실제 값은 json 키 아래에 있다"고 강조했던 이유가 여기서 드러난다. $json이 바로 그 json에 대한 지름길이라, 필드명만 이어 붙이면 값에 닿는다. 코드로 치면 앞 함수가 반환한 객체에서 .title을 꺼내는 것과 다르지 않다.

손으로 다 외울 필요는 없다 — 드래그앤드롭 매핑

처음엔 이 표현식들을 다 외워야 하나 싶었는데, 아니었다. 표현식 모드에서 왼쪽 입력 데이터 패널의 필드를 드래그해서 파라미터에 떨어뜨리면 표현식이 자동으로 생성된다. title 필드를 끌어다 놓으면 {{ $json.title }}이 알아서 채워진다.

그래서 실무 흐름은 "필드를 끌어다 놓고, 필요하면 뒤에 자바스크립트 메서드를 덧붙이는" 식이 된다. IDE의 자동완성이 경로를 잡아주는 것과 비슷한 감각이라 금방 익숙해졌다.

다른 노드 참조하기 — $('노드이름')

바로 앞 노드가 아니라, 워크플로우 중간의 특정 노드 데이터를 참조해야 할 때가 있다. 이때는 노드를 이름으로 부른다.

{{ $('HTTP Request').item.json.userId }}

여기서 주의할 점 두 가지를 기록해둔다.

• 노드 이름은 대소문자와 공백까지 정확히 써야 한다. 편집기에 표시된 이름 그대로여야 하고, 오타가 있으면 값을 못 찾는다.
• 오래된 자료에는 $node["HTTP Request"].json 같은 문법이 자주 보인다. 이건 구버전 방식이고, 현재 공식 문서가 권장하는 건 $('노드이름') 형태다. 검색으로 예제를 참고할 때 이 둘이 섞여 있으니 헷갈리지 않는 게 좋다.

한 가지 흥미로웠던 건 .item의 의미다. $('HTTP Request').item은 단순히 "그 노드의 첫 아이템"이 아니라, 지금 처리 중인 현재 아이템에 대응(linked)되는 그 노드의 아이템을 가져온다. 여러 아이템이 흐를 때 짝을 맞춰주는 개념인데, 코드로 배열을 순회할 때 인덱스를 직접 맞춰주던 걸 n8n이 알아서 연결해준다고 이해했다. (여러 아이템을 다루는 이야기는 3편에서 더 자세히 다룬다.)

Set(Edit Fields) 노드로 데이터 변형하기

값을 꺼내는 것까지 봤으니, 이제 모양을 바꿔본다. 데이터 변형에 가장 기본이 되는 건 Edit Fields(옛 이름 Set) 노드다. 필드를 추가하거나, 값을 수정하거나, 필요한 필드만 남기는 노드다.

1편 워크플로우 뒤에 Edit Fields 노드를 붙이고, 필드를 세 개 만들어봤다.

// 문자열 메서드 활용
titleUpper = {{ $json.title.toUpperCase() }}

// 여러 값을 조합
summary = {{ "할 일 #" + $json.id + ": " + $json.title }}

// 내장 날짜 변수
fetchedAt = {{ $now }}

실행하면 출력 아이템에 세 필드가 더해진다.

{
  "titleUpper": "DELECTUS AUT AUTEM",
  "summary": "할 일 #1: delectus aut autem",
  "fetchedAt": "2026-07-09T..."
}

여기서 두 가지를 확인했다. 첫째, 표현식 안에서 toUpperCase() 같은 평범한 자바스크립트 문자열 메서드가 그대로 먹힌다. 둘째, $now 같은 n8n 내장 변수를 쓸 수 있다($now는 Luxon 기반 날짜/시간 객체라, 날짜 계산에 강하다). 즉 표현식은 "n8n이 데이터를 꽂아주는 자바스크립트 실행 환경"에 가까웠다.

표현식이냐, Code 노드냐

여기까지 오니 자연스럽게 든 의문. "그럼 복잡한 로직도 다 표현식에 우겨넣나?" 답은 아니오였고, n8n 문서의 기준도 명확했다.

• 표현식 — 이전 노드 값 참조, 가벼운 변형·계산. 파라미터 필드 안에서 로직을 값 가까이에 두고 싶을 때.
• Code 노드 — 자바스크립트나 파이썬을 한 스텝으로 돌리는 전용 노드. 여러 아이템을 한꺼번에 가공하거나, 조건이 복잡하거나, 재사용 로직이 필요할 때.

경험칙으로 정리하면 이렇다. 한 줄로 읽히면 표현식, 함수로 빼고 싶어지면 Code 노드. 표현식에 삼항 연산자를 두세 번 중첩하기 시작하면, 그건 Code 노드로 옮기라는 신호였다. 코드에서 인라인 표현식과 별도 함수 분리를 판단하던 기준과 똑같았다.

코드로 자동화하던 관점에서

• {{ $json.title }} → 앞 함수가 반환한 객체에서 .title 꺼내기
• 드래그앤드롭 매핑 → IDE 자동완성이 접근 경로를 잡아주는 것
• $('노드이름').item → 현재 아이템에 짝지어진 특정 노드의 값. 인덱스 매칭을 플랫폼이 대신 해주는 지점
• Edit Fields 노드 → 객체 리터럴을 만들어 필드를 매핑하는 것
• 표현식 vs Code 노드 → 인라인 한 줄이냐, 함수로 분리하냐

값을 참조하고 가공하는 이 층까지 익히고 나니, 1편에서 "그냥 코드가 빠르겠는데?" 했던 감각이 조금 달라졌다. 값 하나 꺼내려고 파싱 코드를 쓰지 않아도 되고, 날짜 처리 라이브러리를 따로 import하지 않아도 되는 건 분명한 편의였다.

오늘 막혔던 것 / 메모

• "referenced node hasn't run yet" 류 에러 — 이전 노드가 아직 실행되지 않은 상태에서 그 노드를 참조하면 값을 못 가져온다. 표현식을 테스트할 땐 앞 노드부터 한 번 실행해두는 게 안전하다.
• 노드 이름 오타 — $('http request')처럼 대소문자를 틀리면 조용히 undefined가 된다. 편집기 표시 이름을 그대로 복사하는 습관을 들였다.

마치며

2편의 핵심은 이렇게 요약된다. $json으로 현재 아이템의 값을 꺼내고, $('노드이름')으로 다른 노드를 참조하고, Edit Fields 노드와 표현식으로 데이터를 가공한다. 그리고 한 줄을 넘어가면 Code 노드로 내려간다.

여기까지 오면 단일 아이템을 다루는 감은 잡힌다. 그런데 자동화는 대개 여러 건을 다루고, 조건에 따라 길이 갈린다. 다음 3편에서는 분기(IF/Switch)와, n8n 특유의 "아이템 단위 실행" 방식을 정리한다. 1편에서 "왜 데이터를 배열로 감싸지?"라고 물었던 것의 진짜 답이 거기서 나온다.

읽어주셔서 감사합니다. 🙌

n8n 학습기 시리즈 — 1편. 핵심 개념: 노드, 트리거, 그리고 JSON 0편에서 왜 n8n을 배우기로 했는지 적었다. 이번 편은 실제로 띄워보고 첫 워크플로우를 뜯어보며 개념을 정리한다.

들어가며

말로만 개념을 읽는 것보다, 일단 화면을 띄워놓고 노드를 만져보는 게 빠르다고 생각했다. 그래서 이번 편은 순서가 이렇다. 먼저 n8n을 셀프호스팅으로 띄우고, 첫 워크플로우를 하나 만들어 실행해본 다음, 거기서 관찰한 걸로 핵심 개념 세 가지(노드 / 트리거 / 데이터)를 정리한다.

일단 띄우고 본다 (Docker)

0편에서 말했듯 처음부터 셀프호스팅으로 가기로 했다. 클라우드 버전의 실행 수 제약 없이 구조를 제대로 이해하고 싶었고, Docker 컨테이너 하나 띄우는 건 부담도 아니니까.

Mac에 Docker Desktop이 깔려 있다는 전제로, 터미널에 다음 두 줄이면 끝난다.

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -v n8n_data:/home/node/.n8n \
  docker.n8n.io/n8nio/n8n

첫 줄은 워크플로우와 자격 증명(Credentials)을 저장할 볼륨을 만드는 것이다. 이걸 붙여줘야 컨테이너를 내렸다 올려도 만든 워크플로우가 날아가지 않는다. 이미지 경로가 docker.n8n.io/n8nio/n8n인 점만 주의하면 된다(공식 레지스트리 경로다).

명령이 돌면 이미지를 받아 컨테이너가 뜨고, 브라우저에서 http://localhost:5678 로 접속하면 편집기가 나온다. 최초 1회 계정(오너) 설정을 하고 나면 빈 캔버스가 열린다.

참고: 최근 버전은 -e N8N_RUNNERS_ENABLED=true 같은 환경 변수를 권장하는데, 입문 단계에선 위 최소 구성으로도 충분하다. 프로덕션으로 갈 땐 타임존, DB(PostgreSQL) 분리 등을 붙이게 되지만 그건 한참 뒤 이야기다.

개념 1 — 노드: 워크플로우의 기본 단위

빈 캔버스에서 첫인상은 단순했다. 자동화의 각 단계가 노드(Node) 라는 상자 하나이고, 노드를 선으로 이어 흐름을 만든다. 코드로 치면 함수 하나하나를 상자로 그려놓고, 앞 함수의 리턴값을 뒤 함수 입력으로 넘기는 걸 눈에 보이게 만든 셈이다.

노드는 크게 두 종류로 나뉜다.

• 트리거 노드 — 워크플로우를 시작시키는 노드. 모든 워크플로우는 트리거에서 출발한다. 캔버스에 처음 노드를 추가할 때 트리거부터 고르라고 나오는 이유다.
• 일반(액션) 노드 — 트리거 이후에 데이터를 처리하는 노드. API 호출, 데이터 변형, 조건 분기, 외부 서비스로 전송 등이 여기 속한다.

이 구분이 코드와 대응이 잘 됐다. 트리거 노드는 이벤트 리스너나 진입점(main, 웹훅 핸들러, cron 잡)이고, 일반 노드는 그 안에서 호출되는 함수들이다.

개념 2 — 트리거: 무엇이 워크플로우를 깨우는가

트리거 종류를 훑어보니 익숙한 것들이었다.

• Trigger manually — 편집기에서 버튼을 눌러 수동 실행. 개발 중 테스트용이다.
• On a schedule — 정해진 주기로 실행. 사실상 cron이다.
• On webhook call — 외부에서 HTTP 요청이 들어오면 실행. 내가 API 서버에서 웹훅 핸들러 붙이던 것과 같다.
• On app event — Gmail에 새 메일이 오면, Google Drive에 새 파일이 생기면 같은 서비스별 이벤트.

결국 "무엇이 이 자동화를 깨우는가"를 고르는 것이고, 코드로 자동화할 때 내가 매번 직접 만들던 진입 조건(스케줄러 등록, 웹훅 엔드포인트 개설, 폴링 루프)을 플랫폼이 노드 하나로 대신 제공하는 구조였다. 0편에서 "매번 새로 만들던 뼈대를 플랫폼이 깔아준다"고 기대했던 게 이 지점에서 처음 체감됐다.

개념 3 — 데이터는 JSON으로 흐른다 (이번 편의 핵심)

여기가 제일 중요하다. n8n을 이해하는 열쇠는 노드 사이를 흐르는 데이터의 모양을 아는 것이다.

n8n에서 노드 간 데이터는 항상 아이템(item)들의 배열로 흐른다. 그리고 각 아이템은 이런 형태다.

[
  {
    "json": {
      "id": 1,
      "title": "예시 데이터"
    }
  },
  {
    "json": {
      "id": 2,
      "title": "다음 아이템"
    }
  }
]

핵심을 정리하면 이렇다.

• 모든 노드는 아이템 배열을 입력으로 받아, 아이템 배열을 출력으로 내보낸다.
• 실제 데이터는 각 아이템의 json 키 안에 들어 있다. (파일 같은 바이너리는 별도로 binary 키에 담긴다.)
• 그래서 다음 노드에서 앞 노드의 값을 참조할 때 json을 거쳐 접근하게 된다. (구체적인 표현식 문법은 2편에서 다룬다.)

처음엔 "왜 데이터를 굳이 배열로 감싸고, 또 json 키로 한 번 더 감싸지?" 싶었다. 그런데 이유는 금방 납득됐다. 자동화는 대부분 여러 건을 다룬다. 메일 10통, 행 100개, 파일 여러 개. 데이터를 항상 배열로 취급하면, 노드는 "한 건이든 여러 건이든 똑같은 방식으로" 처리할 수 있다. 코드로 치면 단일 객체와 리스트를 분기 처리하지 않고, 처음부터 전부 리스트로 두고 map을 도는 것과 같은 발상이다.

첫 워크플로우: 데이터를 눈으로 확인하기

개념을 글로 읽었으니 실제로 확인해봤다. 가장 단순한 조합이다.

Trigger manually → HTTP Request

1. 캔버스에서 트리거로 Trigger manually를 추가한다. (추가하면 노드 이름이 When clicking 'Execute workflow'로 표시된다.)
2. 그 뒤에 HTTP Request 노드를 잇고, Method는 GET, URL에 테스트용 공개 API를 넣는다.

GET https://jsonplaceholder.typicode.com/todos/1

3. 노드의 Execute step 버튼을 누른다. (워크플로우 전체를 돌릴 땐 Execute workflow를 쓴다.)

실행하면 HTTP Request 노드에 결과가 뜨는데, 여기서 처음으로 "데이터가 흐른다"는 게 눈에 보인다. 노드 출력 패널을 보면 응답이 이렇게 담겨 있다.

[
  {
    "json": {
      "userId": 1,
      "id": 1,
      "title": "delectus aut autem",
      "completed": false
    }
  }
]

앞서 정리한 그대로다. API 응답이 아이템 배열의 json 키 안에 들어와 있다. n8n UI에서는 이 출력을 Table(표), JSON, Schema 세 가지 뷰로 볼 수 있는데, 특히 Schema 뷰가 다음 노드에서 어떤 필드를 참조할 수 있는지 보여줘서 유용했다.

여기까지가 1편의 목표였다. HTTP Request 한 줄로 외부 데이터를 가져오는 건 코드로 수백 번 해봤지만, 그 결과가 정해진 형태(아이템 배열 + json 키)로 캔버스 위를 흐르고, 다음 노드가 그걸 받아 쓸 수 있다는 감각이 n8n의 출발점이었다.

코드로 자동화하던 관점에서

정리하면서 계속 코드와 겹쳐 봤다.

• Manual Trigger → 스크립트를 직접 실행하는 것(main() 호출)
• HTTP Request 노드 → fetch / axios 한 줄
• 노드를 잇는 선 → 앞 함수의 리턴값을 뒤 함수 인자로 넘기는 것
• 아이템 배열 → API 응답을 리스트로 받아 map으로 순회하는 것

여기까지 보면 "그냥 코드가 더 빠르겠는데?"라는 생각도 들었다. 실제로 단발성 스크립트라면 그 말이 맞다. 다만 n8n의 값어치는 이 다음부터 나온다고 본다. 인증을 노드가 관리하고, 스케줄과 웹훅이 트리거로 붙고, 실패 시 재시도가 얹히는 순간, 내가 매번 짜던 "주변 코드"가 사라진다. 그 대조를 다음 편들에서 계속 확인해볼 생각이다.

오늘 막혔던 것 / 메모

• 처음에 노드 출력이 배열로 감싸여 있어서 잠깐 헷갈렸다. → n8n은 항상 아이템 배열 단위로 데이터를 다룬다는 걸 이해하니 풀렸다.
• 실제 값이 json 키 아래에 있다는 걸 놓치면, 나중에 표현식에서 필드를 잘못 참조하게 된다. 이건 2편에서 제대로 정리할 예정.

마치며

1편의 결론은 한 문장이다. n8n에서 데이터는 아이템 배열의 형태로, 각 값은 json 키 안에 담겨 노드 사이를 흐른다. 이 구조만 손에 익으면 나머지는 그 위에 얹히는 이야기다.

다음 2편에서는 이 데이터를 실제로 꺼내 쓰고 변형하는 방법, 즉 표현식({{ $json }})과 노드 간 데이터 참조를 정리한다. 개인적으로 여기가 n8n에서 제일 헷갈리면서도 제일 중요한 부분이라 생각해서, 시간을 들여 다뤄보려 한다.

읽어주셔서 감사합니다. 🙌

n8n 학습기 시리즈 — 0편. 왜 n8n인가 토이 프로젝트에 들어가기 전, 개념부터 하나씩 정리하며 남기는 기록입니다.

들어가며

2년 남짓 소프트웨어 품질 검증과 테스트 자동화를 해왔다. Playwright와 TypeScript로 E2E 테스트를 짜고, JUnit과 Maven으로 DB 동작을 검증하고, 반복되는 시나리오를 스크립트로 돌려왔다. 내 일의 상당 부분은 결국 "사람이 손으로 반복하던 걸 코드가 대신하게 만드는 것" 이었다.

그런 내가 요즘 n8n이라는 워크플로우 자동화 툴을 붙잡고 있다. 처음 마음먹었을 때 스스로도 좀 이상했다. 자동화라면 코드로 다 짜봤는데, 굳이 노코드 툴을 왜?

이 글은 그 질문에 대한 내 나름의 답이자, 앞으로 이어질 학습 기록의 0편이다. 배운 걸 정리하기 전에, 왜 배우기로 했는지부터 적어두려 한다.

코드 자동화와 업무 자동화 사이의 간극

테스트 자동화에는 명확한 대상이 있다. 로그인 폼, API 응답, 쿼리 결과. 검증할 게 정해져 있고, 기대와 다르면 빨간불이 켜진다. 이 세계는 익숙하고, 나름의 방법론도 몸에 배어 있다.

그런데 일을 하다 보면 "테스트"가 아닌 자동화가 계속 눈에 밟혔다.

• 회의가 끝나면 회의록을 정리해서 공유하기
• 어딘가에서 데이터를 긁어와 시트에 정리하기
• 특정 이벤트가 발생하면 알림 보내기
• API 두어 개를 엮어서 중간 데이터를 흘려보내기

하나하나 뜯어보면 코드로 못 할 건 없다. 실제로 몇 개는 파이썬 스크립트로 만들어 쓰기도 했다. 그런데 매번 스크립트를 짜고, 인증 붙이고, 돌릴 환경을 마련하고, 실패하면 로그를 뒤지는 과정이 배보다 배꼽이 컸다. 자동화 자체보다 자동화를 굴러가게 만드는 주변 작업이 더 무거웠다.

이 지점에서 워크플로우 자동화 툴이 뭘 해결해주는지 궁금해졌다. 트리거, 인증, 스케줄링, 재시도 같은 "매번 새로 만들던 뼈대"를 플랫폼이 대신 깔아준다면, 나는 로직에만 집중하면 되는 것 아닌가.

n8n이 뭐길래

먼저 정확히 짚고 넘어가자. n8n을 검색하면 "오픈소스 자동화 툴"이라는 소개가 흔하게 나오는데, 엄밀히 말하면 OSI 기준의 오픈소스는 아니다. n8n은 Sustainable Use License라는 fair-code(source-available) 라이선스를 따른다. 소스는 공개되어 있고, 개인이나 내부 업무 용도로는 자유롭게 셀프호스팅해서 무료로 쓸 수 있다. 다만 이걸 기반으로 상업용 SaaS를 만들어 남에게 재판매하는 건 별도 라이선스가 필요하다.

이 구분을 처음부터 정확히 알아둔 이유가 있다. 나중에 사업이나 제품을 고민할 때, "무료 오픈소스인 줄 알았는데 아니었다"는 건 꽤 뼈아픈 착오가 되기 때문이다.

기술적으로 n8n의 핵심은 이렇게 정리된다.

• 노드 기반 워크플로우 에디터 — 자동화의 각 단계가 하나의 "노드"이고, 노드를 선으로 연결해 데이터 흐름을 만든다. Zapier의 선형적인 "트리거 → 액션" 모델과 달리, 분기·루프·병렬 실행·서브워크플로우를 기본으로 지원한다.
• 실행(execution) 단위 과금 — 워크플로우가 아무리 여러 단계로 복잡해도 한 번 도는 걸 1 execution으로 센다. 단계마다 과금하는 task 방식과 대조되는 지점이다.
• 셀프호스팅 — Docker로 내 인프라 위에 직접 띄울 수 있다. 데이터가 내 서버 밖으로 나가지 않는다.
• HTTP Request / Webhook 노드 — 네이티브 연동이 없는 서비스라도 API만 있으면 직접 붙일 수 있다.
• Code 노드 — 필요하면 JavaScript나 Python 코드를 워크플로우 중간에 그대로 실행할 수 있다.

마지막 두 항목이 내 눈길을 끌었다. 노코드 툴이라고 해서 코드를 못 쓰게 막는 게 아니라, 필요한 순간에 코드로 내려갈 수 있는 탈출구를 열어둔 구조다.

왜 하필 n8n인가

Zapier, Make, n8n. 흔히 비교되는 세 가지 중에서 n8n을 고른 이유는 결국 내 배경 때문이다.

Zapier는 비개발자도 몇 분 만에 자동화를 만들 수 있는 게 강점이다. 대신 코드를 넣는 순간 실행 시간·메모리·호출 횟수에 빡빡한 제약이 걸린다. 반면 n8n은 애초에 기술 유저를 겨냥해 설계됐다. Code 노드에서 로직을 온전히 돌릴 수 있고, HTTP Request로 어떤 API든 직접 호출하고, 셀프호스팅하면 내 인프라의 일부처럼 동작한다.

정리하면 이렇다. 나는 이미 API 인증, HTTP, JSON 데이터 다루기, 스크립트 짜기가 익숙하다. 그렇다면 그 익숙함이 제약이 아니라 무기가 되는 도구를 고르는 게 맞다. n8n에서 낯선 건 노드 기반 UI라는 패러다임 정도이고, 나머지 상당수는 내가 코드로 하던 것의 다른 표현일 거라고 봤다.

한 가지 더. n8n은 2.0(2026년 1월)부터 LangChain 기반 AI 노드와 AI Agent 노드를 정식으로 품었다. Claude, OpenAI, Gemini 같은 모델을 워크플로우 안에서 도구처럼 부릴 수 있다. 자동화에 LLM을 얹는 흐름을 제대로 실험해보기에도 좋은 시점이라고 판단했다.

이 시리즈에서 다룰 것

거창한 강의는 아니다. 매일 조금씩 배우면서, 막혔던 지점과 그걸 어떻게 넘었는지를 위주로 남길 생각이다. 대략 이런 순서를 잡고 있다.

• 0편 (이 글) — 왜 n8n인가
• 1편 — 핵심 개념: 노드, 트리거, 그리고 데이터가 JSON으로 흐른다는 감각
• 2편 — 표현식과 데이터 변형: {{ $json }} 문법과 노드 간 데이터 참조
• 3편 — 제어 흐름: 분기(IF/Switch)와 아이템 단위 실행이라는 n8n 특유의 방식
• 4편~ — 실제 토이 프로젝트: 트리거 → 처리 → 실행까지 이어지는 워크플로우 만들기

특히 코드로 자동화하던 관점에서 "이건 코드로 하던 그거네", "이건 오히려 코드가 편한데?", "아 이래서 노코드가 필요하구나" 같은 대조를 놓치지 않고 기록하려 한다. 같은 걸 다른 각도에서 보는 게 이 시리즈의 색깔이 될 것 같다.

마치며

배운 걸 글로 정리하는 습관은 예전 SDET 학습기를 쓰면서 효과를 봤다. 손으로 정리하지 않으면 "돌아가는 걸 봤다"에서 멈추고, 정작 왜 그렇게 되는지는 흐릿하게 남는다.

그래서 이번에도 토이 프로젝트에 뛰어들기 전에, 기초를 다지는 과정부터 차근차근 남겨보려 한다. 다음 글에서는 n8n을 직접 띄우고 첫 워크플로우를 뜯어보며 핵심 개념을 정리할 예정이다.

읽어주셔서 감사합니다. 🙌

이전 글에서 Playwright 설치를 완료했습니다. 이번 글에서는 설치 시 생성된 기본 예제 코드를 활용해서 다양한 테스트 실행 옵션을 알아보겠습니다.

💻 작성 환경

• macOS Tahoe 26.2
• VS Code
• Node.js

기본 예제 코드 살펴보기

Playwright 설치 시 tests/example.spec.ts 파일이 자동으로 생성됩니다.

import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);
});

test('get started link', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Click the get started link.
  await page.getByRole('link', { name: 'Get started' }).click();

  // Expects page to have a heading with the name of Installation.
  await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});

이 코드는 Playwright 공식 사이트에 접속해서 타이틀을 확인하고, "Get started" 링크를 클릭하는 간단한 테스트입니다. 이 예제를 기준으로 다양한 실행 옵션을 살펴보겠습니다.

테스트 실행 옵션

기본 실행

npx playwright test

모든 테스트 파일을 실행합니다. 기본적으로 headless 모드(브라우저 창 없이)로 실행되며, 설정된 모든 브라우저(Chromium, Firefox, WebKit)에서 테스트가 진행됩니다.

Worker 수 지정

npx playwright test --workers 3

병렬로 실행할 worker 수를 지정합니다. 기본값은 CPU 코어 수의 절반입니다. 테스트가 많을 때 worker 수를 늘리면 전체 실행 시간을 단축할 수 있습니다. 반대로 리소스가 부족하거나 테스트 간 충돌이 발생하면 worker 수를 줄여볼 수 있습니다.

특정 파일 실행

npx playwright test one.spec.ts

특정 테스트 파일만 실행합니다. 파일명 일부만 입력해도 매칭되는 파일을 찾아 실행합니다.

npx playwright test one.spec.ts two.spec.ts

여러 파일을 지정하려면 공백으로 구분해서 나열하면 됩니다.

파일명 키워드로 실행

npx playwright test one two

파일명에 one 또는 two가 포함된 모든 테스트 파일을 실행합니다. 확장자 없이 키워드만 입력해도 됩니다.

테스트 이름으로 실행

npx playwright test -g "test title"

-g 옵션을 사용하면 테스트 이름(title)으로 필터링할 수 있습니다. 예제 코드 기준으로 "has title" 테스트만 실행하고 싶다면 다음과 같이 입력합니다.

npx playwright test -g "has title"

정규식 패턴도 사용 가능합니다.

특정 브라우저에서 실행

npx playwright test --project=chromium

특정 브라우저에서만 테스트를 실행합니다. playwright.config.js에 정의된 프로젝트 이름을 사용합니다.

브라우저 창 띄워서 실행

npx playwright test --headed

기본적으로 Playwright는 headless 모드로 실행되어 브라우저 창이 보이지 않습니다. --headed 옵션을 사용하면 실제 브라우저 창이 열리면서 테스트가 진행되는 모습을 눈으로 확인할 수 있습니다.

디버그 모드 실행

npx playwright test --debug

디버그 모드로 실행합니다. Playwright Inspector가 열리면서 테스트를 단계별로 실행하고, 각 단계에서 멈춰서 상태를 확인할 수 있습니다.

특정 라인부터 디버그

npx playwright test one.spec.ts:11 --debug

파일명 뒤에 :라인번호를 붙이면 해당 라인에 있는 테스트부터 디버그 모드로 실행합니다. 특정 테스트만 집중적으로 디버깅할 때 유용합니다.

옵션 조합 예시

여러 옵션을 조합해서 사용할 수 있습니다.

# Chromium에서 headed 모드로 특정 파일 실행
npx playwright test example.spec.ts --project=chromium --headed

# worker 1개로 순차 실행하면서 디버그
npx playwright test --workers 1 --debug

# 특정 테스트만 Firefox에서 실행
npx playwright test -g "has title" --project=firefox

실행 옵션 요약

마치며

테스트를 작성하다 보면 전체 테스트를 돌리기보다 특정 테스트만 반복 실행하는 경우가 많습니다. 오늘 다룬 옵션들을 활용하면 개발 중에 빠르게 피드백을 받으면서 테스트를 작성할 수 있습니다.

다음 글에서는 테스트 코드를 직접 작성하는 방법을 알아보겠습니다.

📚 참고 자료

• Playwright - Running Tests
• Playwright - Command Line

이전 글에서 Playwright가 무엇인지, 왜 사용하는지 알아봤습니다. 이번 글에서는 실제로 Playwright를 설치하고 첫 테스트를 실행하는 과정을 다뤄보겠습니다.

Node.js와 VS Code가 이미 설치되어 있다는 가정 하에 진행합니다.

💻 작성 환경

• macOS Tahoe 26.2
• VS Code
• Node.js

프로젝트 폴더 생성

먼저 Playwright 프로젝트를 위한 폴더를 생성하고 이동합니다.

mkdir my-playwright-project
cd my-playwright-project

VS Code에서 해당 폴더를 열어주세요.

code .

Playwright 설치

VS Code에서 터미널을 열고 다음 명령어를 실행합니다.

npm init playwright@latest

명령어를 실행하면 몇 가지 질문이 나타납니다.

설치 옵션 선택

1. TypeScript 또는 JavaScript 선택

Do you want to use TypeScript or JavaScript?
  ▸ TypeScript
    JavaScript

원하는 언어를 선택합니다. 이 가이드에서는 TypeScript를 기준으로 진행합니다.

2. 테스트 폴더 경로

Where to put your end-to-end tests?
  ▸ tests

테스트 파일이 저장될 폴더명입니다. 기본값인 tests를 그대로 사용하면 됩니다.

3. GitHub Actions 워크플로우 추가 여부

Add a GitHub Actions workflow?
  ▸ false

Github Actions에서 CI/CD 설정이 필요하면 true를 선택합니다. 지금은 false로 진행해도 괜찮습니다.

4. 브라우저 설치 여부

Install Playwright browsers?
  ▸ true

반드시 true를 선택합니다. Playwright가 사용할 브라우저 바이너리(Chromium, Firefox, WebKit)를 설치합니다. false를 할 경우 나중에 직접 브러우저를 설치해줘야하는 불편함이 있으니깐 웬만하면 true로 하시길 권장합니다.

설치 완료 확인

설치가 완료되면 프로젝트에 다음 파일들이 생성됩니다.

package.json을 열어보면 Playwright가 devDependencies에 추가된 것을 확인할 수 있습니다.

제대로 설치되었는지 확인

설치가 완료되면 다음 명령어로 Playwright 버전을 확인할 수 있습니다.

npx playwright --version

버전 정보가 출력되면 설치가 정상적으로 완료된 것입니다.

마치며

터미널 명령어 몇 줄이면 Playwright 설치가 완료됩니다. 다음 글에서는 실제 테스트를 실행하고 코드를 작성하는 방법을 알아보겠습니다.

📚 참고 자료

• Playwright - Installation
• Playwright - Running Tests

웹 애플리케이션을 개발하다 보면 "이 기능이 제대로 동작하는지 어떻게 확인하지?"라는 고민을 하게 됩니다. 버튼을 클릭했을 때 페이지가 잘 이동하는지, 폼을 제출했을 때 데이터가 정상적으로 저장되는지, 매번 수동으로 확인하기엔 시간도 부족하고 실수할 가능성도 높죠.

이런 문제를 해결해주는 것이 바로 E2E(End-to-End) 테스트 자동화입니다. 그리고 오늘 소개할 Playwright는 이 영역에서 빠르게 주목받고 있는 도구입니다.

E2E 테스트란?

E2E 테스트는 사용자 관점에서 애플리케이션의 전체 흐름을 검증하는 테스트입니다.

예를 들어 쇼핑몰에서 "로그인 → 상품 검색 → 장바구니 담기 → 결제"까지의 과정이 정상적으로 동작하는지 확인하는 것이죠. 단위 테스트가 함수 하나하나를 검증한다면, E2E 테스트는 실제 사용자가 경험하는 시나리오 전체를 검증합니다.

왜 필요할까요?

• 개별 컴포넌트는 정상이어도 통합했을 때 문제가 생길 수 있습니다
• 배포 전 주요 기능이 동작하는지 빠르게 확인할 수 있습니다
• 수동 테스트에 드는 반복적인 시간을 줄여줍니다

Playwright 소개

Playwright는 Microsoft에서 개발한 오픈소스 E2E 테스트 프레임워크입니다. 2020년에 처음 공개되었고, 빠른 속도와 안정성으로 Cypress, Selenium과 함께 대표적인 E2E 테스트 도구로 자리잡았습니다.

# 설치
npm init playwright@latest

설치 명령어 하나로 프로젝트 구조, 설정 파일, 예제 테스트까지 자동으로 생성해줍니다.

Playwright의 주요 특징

1. 크로스 브라우저 지원

Chromium, Firefox, WebKit 세 가지 브라우저 엔진을 단일 API로 제어할 수 있습니다. 하나의 테스트 코드로 Chrome, Safari, Firefox에서 모두 동작을 검증할 수 있다는 의미입니다.

// playwright.config.js
projects: [
  { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
  { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
  { name: 'webkit', use: { ...devices['Desktop Safari'] } },
]

2. Auto-waiting

테스트 자동화에서 가장 골치 아픈 문제 중 하나가 타이밍입니다. 버튼이 아직 로딩 중인데 클릭하려고 하면 테스트가 실패하죠. Playwright는 요소가 클릭 가능한 상태가 될 때까지 자동으로 기다려줍니다.

// 별도의 wait 없이도 안정적으로 동작
await page.click('button#submit');

3. 강력한 디버깅 도구

테스트가 실패했을 때 원인을 찾기 쉽도록 다양한 도구를 제공합니다.

• Trace Viewer: 테스트 실행 과정을 스크린샷, DOM 스냅샷, 네트워크 요청과 함께 타임라인으로 확인
• Codegen: 브라우저에서 직접 조작하면 해당 동작을 코드로 자동 생성
• UI Mode: 테스트를 시각적으로 실행하고 각 단계를 확인

# Codegen 실행
npx playwright codegen https://example.com

4. 네트워크 제어

API 요청을 가로채서 원하는 응답으로 대체하거나, 네트워크 상태를 시뮬레이션할 수 있습니다. 백엔드 없이도 프론트엔드 테스트가 가능해집니다.

await page.route('**/api/users', route => {
  route.fulfill({
    status: 200,
    body: JSON.stringify([{ id: 1, name: 'Test User' }])
  });
});

5. 병렬 실행

테스트를 여러 워커에서 동시에 실행하여 전체 테스트 시간을 크게 단축할 수 있습니다.

Playwright의 장점

빠른 실행 속도

브라우저와 직접 통신하는 방식을 사용해 Selenium 대비 체감될 정도로 빠릅니다. 특히 병렬 실행을 기본 지원하기 때문에 테스트 수가 많아져도 전체 실행 시간을 효율적으로 관리할 수 있습니다.

안정적인 테스트

Auto-waiting과 자동 재시도(retry) 기능 덕분에 "어제는 됐는데 오늘은 안 되는" 불안정한 테스트(flaky test)가 줄어듭니다. 이건 실무에서 정말 큰 장점입니다.

낮은 진입 장벽

Codegen으로 브라우저 조작을 녹화해서 코드를 생성할 수 있어, 처음 접하는 분들도 빠르게 테스트를 작성할 수 있습니다. 공식 문서도 잘 정리되어 있고 예제가 풍부합니다.

활발한 생태계

Microsoft의 지원 아래 꾸준히 업데이트되고 있고, VS Code 확장 프로그램도 제공합니다. GitHub Actions 등 CI/CD 파이프라인과의 연동도 간편합니다.

마치며

E2E 테스트 자동화를 시작하려는 분들에게 Playwright는 좋은 선택지입니다. 설정이 간단하고, 디버깅 도구가 강력하며, 무엇보다 안정적으로 동작합니다.

다음 글에서는 실제로 간단한 테스트를 작성하고 실행하는 과정을 다뤄보겠습니다.

📚 참고 자료

• Playwright 공식 문서
• Playwright GitHub

일반적으로 많은 프로젝트들에서 기본적으로 이미지 업로드 하는 기능들이 많이 들어갑니다. 그래서 AWS 기반으로 S3 + CloudFront + Presigned URL 조합을 사용하면 빠르고 안전하며 비용 효율적인 이미지 업로드를 구현할 수 있습니다.

1️⃣ 이미지 업로드 아키텍처

흐름

1. 클라이언트 → 서버: 업로드 요청
2. 서버 → AWS: Presigned URL 생성
3. 서버 → 클라이언트: Presigned URL 전달
4. 클라이언트 → S3: 이미지 직접 업로드
5. 서버 → DB: 업로드 정보(경로, 파일명, 유저) 저장
6. 조회 시: CloudFront URL 통해 이미지 접근

✅ 장점: 서버 부하 최소화 + 빠른 CDN 조회 + 보안 강화

2️⃣ Spring Boot 구현

🔹 Presigned URL 생성

@Service
@RequiredArgsConstructor
public class S3Service {
    private final AmazonS3 amazonS3;
    private final String bucketName = "demo-images";

    public String generatePresignedUrl(String fileName) {
        Date expiration = new Date(System.currentTimeMillis() + 1000 * 60 * 5); // 5분 유효
        GeneratePresignedUrlRequest request =
            new GeneratePresignedUrlRequest(bucketName, fileName)
            .withMethod(HttpMethod.PUT)
            .withExpiration(expiration);
        return amazonS3.generatePresignedUrl(request).toString();
    }
}

🔹 클라이언트 업로드 (React Native 예시)

await axios.put(presignedUrl, file, {
  headers: { "Content-Type": file.type }
});

3️⃣ CloudFront + S3 구조

• S3 (Private): 이미지 저장
• CloudFront: 전 세계 CDN 캐싱
• OAC(Origin Access Control): S3 직접 접근 차단
• Signed URL(Optional): 민감한 이미지 접근 제어

(예시 다이어그램: S3 + CloudFront + Presigned URL 구조)

4️⃣ 보안 체크리스트

업로드 서비스는 XSS·파일 위장·대용량 업로드에 취약할 수 있습니다.
아래 보안 전략을 적용하면 안전합니다.

• 허용 확장자만 업로드 (jpg, png, webp)
• MIME 타입 검증 (image/ 로 시작 여부)
• 파일 크기 제한 (1~2MB)
• UUID 기반 파일명 (사용자 입력 이름 사용 ❌)
• S3 Private + Presigned URL 사용
• CloudFront OAC 설정으로 직접 접근 차단
• 필요 시 Signed URL or JWT 인증
• 업로드 후 Lambda로 이미지 포맷 검증

5️⃣ 비용 최적화

• 프리티어 사용 시
  • S3 5GB / CloudFront 1TB / 20,000 GET / 2,000 PUT 무료
• 월 사용량 예시 (300명 × 5장/일 × 1MB)
  • 45GB 저장, 45,000 PUT → 월 $2~3 수준
• 비용 절감 방법
  • 업로드 전 리사이징/압축
  • 오래된 파일 S3 Glacier로 이동

6️⃣ 최종 정리

S3 + CloudFront + Presigned URL
구조를 적용하면 서버 부하를 최소화하고,
보안·속도·비용 모든 면에서 효율적인 구조를 만들 수 있습니다.

이번 미션에서는 더 읽기 좋은 코드를 만들기 위해 기존 코드를 리팩토링하고, SOLID 원칙을 자기만의 언어로 정리하는 작업을 수행했다.

✅ 미션 수행 목표

🔹 1. 코드 리팩토링

• [섹션 3. 논리, 사고의 흐름]에서 이야기하는 내용을 중심으로 리팩토링
• 코드의 가독성을 높이고, 유지보수를 쉽게 만들기

🔹 2. SOLID 원칙 정리

• SOLID 원칙을 이해하고, 이를 나만의 언어로 정리

📌 1️⃣ 코드 리팩토링 과정

🕒 [Step 1] 기존 코드 분석

다음은 주어진 validateOrder 메서드의 기존 코드이다.

📌 기존 코드

public boolean validateOrder(Order order) {
    if (order.getItems().size() == 0) {
        log.info("주문 항목이 없습니다.");
        return false;
    } else {
        if (order.getTotalPrice() > 0) {
            if (!order.hasCustomerInfo()) {
                log.info("사용자 정보가 없습니다.");
                return false;
            } else {
                return true;
            }
        } else if (!(order.getTotalPrice() > 0)) {
            log.info("올바르지 않은 총 가격입니다.");
            return false;
        }
    }
    return true;
}

🔍 분석 결과

• getter를 직접 호출하는 부분이 많음 → 캡슐화를 해치고 있음
• 부정 연산자(!, !=) 사용이 많음 → 코드의 직관성이 떨어짐
• 중첩된 조건문이 많음 → 가독성이 낮음

🕒 [Step 2] 리팩토링 방향 설정

리팩토링 시 고려할 사항:
✔️ getter 사용을 최소화하기 위해 Order 내부에 메서드를 추가
✔️ 부정 연산자(!)를 제거하여 가독성을 높임
✔️ 불필요한 else 문을 제거하여 코드 흐름을 단순화

🕒 [Step 3] Order 클래스 개선

Order 클래스 내부에 필요한 메서드를 추가하여 객체 스스로 판단할 수 있도록 수정

📌 수정된 Order 클래스

import java.util.List;

public class Order {

  private final List<Integer> items;
  private final int totalPrice;
  private final int customer;

  public Order(List<Integer> items, int totalPrice, int customer) {
    this.items = items;
    this.totalPrice = totalPrice;
    this.customer = customer;
  }

  public boolean isEmpty() {
    return items.isEmpty();
  }

  public boolean hasCustomerInfo() {
    return customer != 0;
  }

  public boolean moreThanZeroTotalPrice() {
    return totalPrice > 0;
  }
}

🕒 [Step 4] 리팩토링된 validateOrder 메서드

리팩토링된 validateOrder는 더 직관적이고 읽기 쉬운 코드가 되었다.

📌 수정된 validateOrder 메서드

public class MissionDay4 {

  public boolean validateOrder(Order order) {
    if (order.isEmpty()) {
      log.info("주문 항목이 없습니다.");
      return false;
    }

    if (order.moreThanZeroTotalPrice()) {
      if (order.hasCustomerInfo()) {
        return true;
      }
      log.info("사용자 정보가 없습니다.");
      return false;
    }

    log.info("올바르지 않은 총 가격입니다.");
    return false;
  }
}

🔍 리팩토링 결과 정리

📌 2️⃣ SOLID 원칙 정리

SOLID 원칙은 객체 지향 프로그래밍에서 유지보수성과 확장성을 높이기 위한 설계 원칙이다.
아래는 내가 이해한 SOLID 원칙을 나만의 언어로 정리한 내용이다.

✅ 1. 단일 책임 원칙 (SRP, Single Responsibility Principle)

"하나의 클래스는 하나의 책임만 가져야 한다."

• 한 클래스가 너무 많은 역할을 맡으면 변경이 어려워짐
• 하나의 책임만 있도록 기능을 나누는 것이 중요

✅ 2. 개방-폐쇄 원칙 (OCP, Open/Closed Principle)

"확장은 가능하지만, 기존 코드는 수정하지 않는다."

• 새로운 기능이 필요하면 기존 코드를 수정하는 것이 아니라, 확장해야 함
• 인터페이스, 추상 클래스를 활용하면 유연한 코드 작성 가능

✅ 3. 리스코프 치환 원칙 (LSP, Liskov Substitution Principle)

"하위 클래스는 상위 클래스를 대체할 수 있어야 한다."

• 부모 클래스를 상속받은 자식 클래스가 부모처럼 동작해야 함
• 그렇지 않으면 다형성을 활용할 수 없음

✅ 4. 인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

"필요한 기능만 포함된 인터페이스를 사용하라."

• 한 개의 큰 인터페이스보다는, 작은 단위의 인터페이스를 여러 개 만드는 것이 좋음
• 필요하지 않은 기능까지 구현하지 않아도 됨

✅ 5. 의존 역전 원칙 (DIP, Dependency Inversion Principle)

"구체적인 것보다, 추상적인 것에 의존하라."

• 클래스가 다른 클래스를 직접 참조하는 것이 아니라, 인터페이스나 추상 클래스를 통해 의존
• 변경에 유연한 구조를 만들 수 있음

📌 출처

📖 강의 제목: Readable Code: 읽기 좋은 코드를 작성하는 사고법
👩‍🏫 강사: 박우빈

데이터 모델링에서 Entity(개체), Attribute(속성), Instance(인스턴스) 개념을 이해하는 것이 중요하다. 이를 쉽게 설명하기 위해 간단한 예제와 함께 살펴보자.

🔹 개념 정리

• Entity (개체): 관리할 대상이 되는 데이터 (예: 학생, 강의, 도서 등)
• Attribute (속성): 개체가 가지는 정보 (예: 학번, 이름, 학년 등)
• Instance (인스턴스): 개체(Entity)의 실제 데이터 값 (예: 학번 2023001, 이름 김철수)

Entity는 데이터를 저장하는 개체, Attribute는 개체가 가지는 속성, Instance는 실제 데이터를 의미한다.

🎯 이해하기 쉬운 비유

📦 택배 시스템으로 설명하면?

• Entity (개체) → "택배 상자"
• Attribute (속성) → "택배 상자에 붙어 있는 송장 (수령인, 주소, 무게)"
• Instance (인스턴스) → "실제 배송 중인 특정 택배"

이렇게 비유하면 Entity, Attribute, Instance 개념이 더 쉽게 이해될 것이다! 🚀

🔹 Entity (엔터티)

"식별 가능한 객체"

✅ 엔터티의 특징

1. 업무에서 사용되는 정보여야 함
2. 유일성을 보장하는 식별자(Primary Key)가 있어야 함
3. 두 개 이상의 인스턴스(Row)를 가져야 함
4. 반드시 속성(Attribute)을 포함해야 함
5. 다른 엔터티와 하나 이상의 관계(Relationship)를 가져야 함

🔹 엔터티의 분류

1️⃣ 유형에 따른 분류

• 유형(Entity): 물리적인 형태가 존재 (예: 학생, 도서)
• 개념(Entity): 물리적 형태 없이 개념적으로 존재 (예: 강의 계획)
• 사건(Entity): 행위를 통해 발생하며, 빈번하고 통계 자료로 활용 가능 (예: 주문 내역)

2️⃣ 발생 시점에 따른 분류

• 기본 엔터티: 원래 존재하는 독립적인 정보, 자식 엔터티를 가질 수 있음
• 중심 엔터티: 기본 엔터티에서 파생되며, 데이터 양이 많고 업무에서 중심적인 역할 수행
• 행위 엔터티: 두 개 이상의 엔터티에서 파생되며, 데이터의 수정과 증가가 잦음

🔹 Attribute (속성)

"객체의 특징"

예를 들어, "사람"이라는 객체가 있다면 이름, 나이, 생년월일 등 다양한 특징이 존재할 것이다. 이처럼 개체(Entity)의 특정 정보를 나타내는 요소를 속성(Attribute)이라고 한다.

🔹 속성의 분류

1️⃣ 특성에 따른 분류

• 기본 속성 (Basic Attribute): 업무 프로세스에서 바로 정의할 수 있는 속성
• 설계 속성 (Designed Attribute): 업무에 존재하지 않지만 설계 시 필요하다고 판단되는 속성 (예: 고유번호)
• 파생 속성 (Derived Attribute): 다른 속성의 값을 계산하거나 특정 규칙으로 변형하여 생성하는 속성

2️⃣ 구성 방식에 따른 분류

• PK (Primary Key) 속성: 엔터티의 인스턴스를 식별할 수 있는 속성
• FK (Foreign Key) 속성: 다른 엔터티의 속성에서 가져온 속성
• 일반 속성: PK, FK를 제외한 나머지 속성

🔹 도메인 (Domain)

"속성이 가질 수 있는 값의 범위"

예를 들어, 성별 속성의 도메인은 [남, 여] 와 같이 미리 정의된 값의 범위를 가진다.

📖 참고 도서: 《SQL개발자 SQLD 과외노트》 - 정미나, 시대에듀

🔹 모델링(Modeling)이란?

"현실 세계를 단순화하여 표현하는 기법"

✅ 모델링의 3가지 조건

1. 현실 세계를 반영해야 함
2. 단순화하여 표현해야 함
3. 관찰하고자 하는 데이터를 모델로 설계해야 함

🔹 모델링의 3가지 특징

1️⃣ 추상화(Abstraction)

• 현실 세계를 일정한 형식으로 표현하는 과정
• 아이디어나 개념을 간략하게 정리

2️⃣ 단순화(Simplification)

• 복잡한 현실 세계를 정해진 표기법으로 쉽게 표현

3️⃣ 명확화(Clarity)

• 불분명한 요소를 제거하여 해석이 명확하게 가능하도록 표현

🔹 모델링의 3가지 관점

1️⃣ 데이터 관점 (Data Perspective)

• 데이터 중심의 모델링
• 업무에 연관된 데이터와 데이터 간의 관계를 분석

2️⃣ 프로세스 관점 (Process Perspective)

• 업무 프로세스 중심의 모델링
• 현재 또는 미래의 업무 처리 방식에 초점

3️⃣ 데이터와 프로세스의 상관 관점 (Interaction Perspective)

• 데이터와 프로세스의 관계를 분석
• 프로세스의 흐름에 따라 데이터가 어떻게 변하는지 모델링

🔹 모델링의 3가지 단계

1️⃣ 개념적 데이터 모델링 (Conceptual Data Modeling)

• 가장 추상화 수준이 높은 모델링 단계
• 기업(전사) 차원의 데이터를 분석하고, 업무 중심적이고 포괄적인 모델링을 수행
• 개체(Entity)와 그 관계(Relationship)를 정의하는 단계

2️⃣ 논리적 데이터 모델링 (Logical Data Modeling)

• 데이터베이스를 설계하기 위한 핵심 모델링 단계
• 재사용성이 가장 높은 모델링으로,
  • Key(키), 속성(Attribute), 관계(Relationship) 등을 상세하게 정의
• DBMS에 독립적인 설계가 가능

3️⃣ 물리적 데이터 모델링 (Physical Data Modeling)

• 실제 데이터베이스로 구현할 수 있도록 성능과 가용성을 고려하는 단계
• 데이터의 물리적 저장 구조(테이블, 컬럼, 인덱스 등)를 정의
• DBMS의 특성을 반영하여 최적화 진행

🔹 데이터의 독립성 (Data Independence)

"ANSI-SPARC 아키텍처는 DBMS의 추상적인 설계 표준이다."
✅ 총 3단계의 스키마 구조를 갖고 있음

1️⃣ 외부 스키마 (External Schema)

• 사용자 관점 (User View)
• 사용자가 데이터베이스를 보는 관점에 따라 각기 다른 스키마를 정의
• 여러 개의 외부 스키마가 존재할 수 있음 (Multiple User's View)

2️⃣ 개념 스키마 (Conceptual Schema)

• 통합된 관점 (Community View of DB)
• 데이터베이스 전체 구조를 나타내는 스키마
• 모든 사용자가 공유하는 데이터의 구조 및 관계를 정의

3️⃣ 내부 스키마 (Internal Schema)

• 물리적인 관점 (Physical Representation)
• 데이터의 저장 방식, 인덱스, 컬럼 정의 등을 포함
• 실제 물리적인 저장 구조를 나타냄

🔸 데이터 독립성이 보장하는 2가지 원칙

1. 논리적 독립성 (Logical Independence)
   • 개념 스키마가 변경되어도 외부 스키마(사용자 관점)는 영향을 받지 않음
2. 물리적 독립성 (Physical Independence)
   • 내부 스키마(저장 구조)가 변경되어도 외부/개념 스키마는 영향을 받지 않음

🔹 ERD (Entity Relationship Diagram)

"어떤 개체(Entity)들이 존재하고, 그들 간에 어떤 관계(Relationship)가 있는지를 시각적으로 표현한 다이어그램"

✅ ERD의 주요 구성 요소

• Entity(개체): 데이터를 저장하는 주요 단위 (예: 고객, 주문, 제품)
• Attribute(속성): 개체가 가지는 정보 (예: 고객 이름, 주문 날짜)
• Relationship(관계): 개체 간의 연관성 (예: 고객은 주문을 한다)

📝 이 단계에서는 개념을 큰 틀에서 이해하는 것이 중요함!

📖 참고 도서: 《SQL개발자 SQLD 과외노트》 - 정미나, 시대에듀

Array(배열)의 기본 개념

배열이란?

"동일한 타입의 데이터를 연속된 메모리 공간에 저장하는 자료구조" 라고 정의할 수 있습니다.

배열의 장점과 단점

장점 : 빠른 접근 속도 (O(1)로 인덱스 접근이 가능합니다.) 단점 : 크기가 고정되어 있으며, 삽입 or 삭제 시 성능이 저하됩니다.

Array(배열)의 연산

배열 생성 및 초기화

int[] arr = new int[5]; // 크기가 5인 배열 생성
int[] arr2 = {1, 2, 3, 4, 5}; // 초기화된 배열

요소 접근 및 수정

arr[0] = 10; // 배열 첫 번째 요소를 10으로 수정
System.out.println(arr[0]); // 출력: 10

다차원 배열

int[][] matrix = {
    {1, 2, 3},
    {4, 5, 6},
    {7, 8, 9}
};
System.out.println(matrix[0][1]); // 출력: 2

가변 배열 (Jagged Array)

int[][] jagged = new int[3][];
jagged[0] = new int[2]; // 첫 번째 행의 길이: 2
jagged[1] = new int[3]; // 두 번째 행의 길이: 3
jagged[2] = new int[1]; // 세 번째 행의 길이: 1

Array(배열)의 알고리즘적 활용

정렬(오름차순/내림차순)

Arrays.sort(arr); // 오름차순 정렬
Arrays.sort(arr, Collections.reverseOrder()); // 내림차순 정렬 (Integer[] 필요)

탐색(Linear Search, Binary Search, 최대값/최소값 찾기)

//선형 탐색(Linear Search)
int key = 3;
for (int i = 0; i < arr.length; i++) {
    if (arr[i] == key) {
        System.out.println("Found at index: " + i);
    }
}

//이진 탐색 (Binary Search)
int index = Arrays.binarySearch(arr, key); // 정렬된 배열에 사용
System.out.println("Index: " + index);

//최대값 찾기, 최소값은 if문만 변경해서 작성하면 됨.
int max = arr[0];
for (int i = 1; i < arr.length; i++) {
    if (arr[i] > max) max = arr[i];
}
System.out.println("Max: " + max);

Array와 ArrayList의 차이

• 배열은 크기가 고정되지만, ArrayList는 동적으로 크기가 변경됩니다.
• 배열은 기본 자료형을 저장할 수 있지만, ArrayList는 객체만 저장 가능합니다.

빠르고 간단하게 Array에 대해서 review 해봤습니다. 오늘도 error / issue 없는 하루 되시길 바랍니다. 감사합니다 :)

1. 자료구조 공부 및 문제 풀이
2. 빅오 표기법 (big-O nation) 익히기
3. 알고리즘 공부 및 문제 풀이
4. 알고리즘 분석

다음과 같은 순서로 진행하려고 합니다.

1. 자료구조(Data structure) 공부 및 문제 풀이

앞으로 공부할 자료구조는 Array, String, Stack, Queue, Priority Queue, Deque, Hash 정도 입니다. 자바로 coding test를 준비할 예정이기 때문에 *이론 공부 -> 자바 내장 클래스의 메소드 공부 -> 백준 문제 풀이 * 순서로 진행할 예정입니다.

- 이론 공부 간단 요약

Array: 배열의 구조와 특징, 탐색 및 정렬 알고리즘
String: 문자열의 처리 방법, 다양한 문자열 메소드
Stack: LIFO 구조, 다양한 활용 예시
Queue: FIFO 구조, 일반 큐와 원형 큐의 차이점
Priority Queue: 우선순위 큐의 개념과 활용
Deque: 양쪽 끝에서 삽입과 삭제가 가능한 자료구조
Hash: 해시 테이블의 원리, 충돌 해결 방식

- 자바 내장 클래스 간단 요약

Array: Arrays 클래스의 메소드 (정렬, 검색 등)
String: String 클래스의 주요 메소드
Stack: Stack 클래스 (push, pop, peek 등)
Queue: Queue 인터페이스와 LinkedList 또는 ArrayDeque 구현
Priority Queue: PriorityQueue 클래스
Deque: Deque 인터페이스와 ArrayDeque 클래스
Hash: HashMap, HashSet 클래스의 메소드

백준 문제 풀이의 경우에는 하루 평균 3~5문제 풀 예정입니다.

2. 빅오 표기법 (big-O nation) 익히기

알고리즘 공부하기 앞서서 빅오 표기법을 공부하려고 합니다. 해당 표기법은 알고리즘에서 가장 기초가 되는 부분으로 알고리즘의 시간 복잡도, 공간 복잡도를 나타낼 수 있는 수학적 기법입니다. 공부해야하는 이유는 효율성 평가, 최적화, 문제 해결, 면접 준비에 필요하고 필수적이기 때문입니다.

효율성 평가: 알고리즘의 성능을 평가하고 다른 알고리즘과 비교할 수 있습니다.
최적화: 성능을 개선하기 위해 어떤 부분을 최적화해야 하는지 이해할 수 있습니다.
문제 해결: 특정 문제에 적합한 알고리즘을 선택하는 데 도움을 줍니다.
면접 준비: 많은 코딩 테스트 인터뷰에서 알고리즘의 복잡도를 물어보므로 필수적인 지식입니다.

기본 개념 정리 후 실제 코드를 보면서 시간 복잡도, 공간 복잡도를 구해보면서 공부할 예정입니다.

3. 알고리즘 공부 및 문제 풀이

앞으로 공부할 알고리즘에 종류에서 정렬(quick sort, merge sort), 탐색(binary search, DFS, BFS), 재귀, DP, Graph를 공부할 예정입니다. 해당 공부는 이론 공부 -> 백준 문제(실버) -> 백준 문제(골드) 순서로 진행할 예정입니다. 하루 평균 3~5문제정도 풀이할 예정입니다.

- 이론 공부 간단 요약

1. 정렬 알고리즘
   • 퀵 정렬: 평균 O(n log n), 분할 정복 방식.
   • 병합 정렬: O(n log n), 안정적인 정렬.
2. 탐색 알고리즘
   • 이진 탐색: O(log n), 정렬된 배열에서 특정 원소 찾기.
   • DFS (깊이 우선 탐색): 재귀적 또는 스택을 이용한 탐색.
   • BFS (너비 우선 탐색): 큐를 이용하여 레벨별 탐색.
3. 재귀
   • 자기 자신을 호출하여 문제를 해결하는 기법.
   • 기본 구조와 종료 조건 이해.
4. 동적 프로그래밍 (DP)
   • 문제를 더 작은 하위 문제로 나누어 해결.
   • 메모이제이션 또는 타뷸레이션 기법 사용.
5. 그래프
   • 그래프 표현 방법 (인접 행렬, 인접 리스트).
   • 그래프 탐색 (DFS, BFS)과 최단 경로 알고리즘 이해.

4. 알고리즘 분석

알고리즘 분석은 주어진 문제를 해결하기 위해 작성한 코드의 성능을 평가하는 과정입니다. 이를 통해 알고리즘의 효율성을 이해하고, 최적화할 수 있는 기회를 제공합니다. 앞으로의 알고리즘 분석은 다음과 같은 방법으로 진행할 예정입니다:

1. 시간 복잡도 계산
   • 코드의 실행 시간이 입력 크기에 따라 어떻게 변화하는지를 분석합니다.
   • 반복문이나 재귀 호출의 횟수를 세고, Big O 표기법으로 표현합니다.
   • 예를 들어, 중첩 반복문이 있는 경우 O(n²)로 표현할 수 있습니다.
2. 공간 복잡도 계산
   • 코드가 사용하는 메모리의 양을 분석합니다.
   • 변수, 배열, 객체 등에서 사용하는 메모리의 양을 고려합니다.
   • 재귀 호출로 인해 사용하는 스택 메모리를 포함하여 평가합니다.
3. 다른 사람의 코드 분석
   • 다른 사람의 알고리즘을 분석하여 다양한 접근 방식을 배웁니다.
   • 코드의 시간 복잡도와 공간 복잡도를 이해합니다.
   • 자신의 코드와 비교하여 개선할 수 있는 부분을 찾아봅니다.

이러한 단계들을 통해 알고리즘 분석의 기초를 다지고, 문제 해결 능력을 향상시키는 데 중점을 둘 것입니다. 알고리즘의 성능을 체계적으로 평가함으로써, 더 효율적인 코드 작성과 문제 해결 전략을 개발할 수 있도록 노력하겠습니다.

happy new year :)

여러 개의 값을 저장하고 그 값을 쉽고, 효율적으로 처리해주는 표준화 클래스의 집합 입니다. 쉽게 말하자면 Data structure인 리스트, 큐, 스택, 해시맵 등을 직접 구현하지 않고 쉽게 사용할 수 있습니다. 대표적으로 ArrayList , Stack, Queue, ArrayDeque, HashMap 등이 있습니다.

컬렉션 프레임워크의 주요 클래스

• ArrayList ArrayList는 가변 크기를 가지며, 요소를 인덱스에 따라 저장하는 리스트입니다.

  import java.util.ArrayList;
  

public class ArrayListExample { public static void main(String[] args) { // Create ArrayList list = new ArrayList<>(); list.add("Apple"); list.add("Banana");

    // Read
    System.out.println(list.get(0)); // Apple

    // Update
    list.set(1, "Cherry");
    System.out.println(list.get(1)); // Cherry

    // Delete
    list.remove(0);
    System.out.println(list); // [Cherry]
}

}

- **Stack**
Stack은 `LIFO(Last In First Out)` 구조로, 요소를 쌓아 올리는 형식입니다.

```java
import java.util.Stack;

public class StackExample {
    public static void main(String[] args) {
        // Create
        Stack<String> stack = new Stack<>();
        stack.push("A");
        stack.push("B");

        // Read
        System.out.println(stack.peek()); // B

        // Update (Stack에서는 update가 아닌 pop 후 push로 처리)
        stack.pop(); // 제거
        stack.push("C"); // 새 요소 추가

        // Delete
        stack.pop(); // C 제거
        System.out.println(stack); // [A]
    }
}

• Queue Queue는 FIFO(First In First Out) 구조로, 먼저 들어온 요소가 먼저 나갑니다.

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

public class QueueExample {
    public static void main(String[] args) {
        // Create
        Queue<String> queue = new LinkedList<>();
        queue.add("1");
        queue.add("2");

        // Read
        System.out.println(queue.peek()); // 1

        // Update (Queue는 직접적으로 업데이트 불가, 제거 후 추가)
        queue.poll(); // 1 제거
        queue.add("3"); // 새 요소 추가

        // Delete
        queue.poll(); // 2 제거
        System.out.println(queue); // [3]
    }
}

• ArrayDeque ArrayDeque는 덱(Double Ended Queue)으로, 양쪽 끝에서 요소를 추가하거나 제거할 수 있습니다.

import java.util.ArrayDeque;

public class ArrayDequeExample {
    public static void main(String[] args) {
        // Create
        ArrayDeque<String> deque = new ArrayDeque<>();
        deque.add("X");
        deque.add("Y");

        // Read
        System.out.println(deque.peekFirst()); // X

        // Update (Update가 아닌 제거 후 추가)
        deque.pollFirst(); // X 제거
        deque.addFirst("Z"); // 새 요소 추가

        // Delete
        deque.pollLast(); // Y 제거
        System.out.println(deque); // [Z]
    }
}

• HashMap HashMap은 키-값 쌍으로 데이터를 저장하며, 키를 통해 값을 빠르게 조회할 수 있습니다.

import java.util.HashMap;

public class HashMapExample {
    public static void main(String[] args) {
        // Create
        HashMap<String, Integer> map = new HashMap<>();
        map.put("Apple", 1);
        map.put("Banana", 2);

        // Read
        System.out.println(map.get("Apple")); // 1

        // Update
        map.put("Apple", 3); // 값 업데이트
        System.out.println(map.get("Apple")); // 3

        // Delete
        map.remove("Banana");
        System.out.println(map); // {Apple=3}
    }
}

프리미티브 타입(Primitive type) 원시 타입 은 정수, 실수, 문자, 논리 리터럴 등의 실제 데이터 값을 저장하는 타입입니다.

int, long, double, float, boolean, byte, short, char

레퍼런스 타입(Reference Type) 참조 타입 은 객체(Object)를 참조(주소를 저장) 하는 타입으로 메모리 번지 값을 통해 객체를 참조하는 타입이다.

Integer, Long, Double, Float, Boolean, Byte, Short, Char

연산 속도는 Primitive type가 Reference Type보다 빠릅니다.

• 비교 연산

  System.out.println(a==b); // 같은 값인지 비교, false
  System.out.println(a!=b); // 같지 않은 값인지 비교, false
  System.out.println(a>b);  // 왼쪽 같이 더 큰지 비교, false
  System.out.println(a<b);  // 왼쪽 값이 더 작은지 비교, false
  System.out.println(a>=b); // 왼쪽 값이 더 크거나 같은지 비교, false
  System.out.println(a<=b); // 왼쪽 값이 더 작거나 같은지 비교, false

• 비트 연산

  int a = 13;
  int b = 4;
  System.out.println(a & b); // AND, 4
  System.out.println(a | b); // OR, 13
  System.out.println(a ^ b); // XOR, 9
  System.out.println(~ a); // NOT, -14
  System.out.println(a << 2); // 왼쪽 시프트 (a에 2^2를 곱한 것과 동일) / 52
  System.out.println(a >> 1); // 오른쪽 시프트 (a에 2^1로 나눈 것과 동일) / 6

부동소수형 데이터는 표현 과정에서 오차가 발생할 수 있다. 이것을 엡실론(epsilon)이라고 하며 항상 생각해야합니다.

1.개발환경 안내

본인은 MacBook Air, Apple M2, macOS Sonoma 14.6.2 입니다.

2. OpenCV와 C++ 소개

OpenCV는 다양한 이미지 처리 기능을 제공하는 오픈 소스 라이브러리입니다. C++는 OpenCV와 함께 사용할 때 성능이 뛰어나기 때문에 많은 개발자들이 선호합니다. OpenCV를 통해 이미지 필터링, 객체 인식, 얼굴 인식 등 다양한 작업을 수행할 수 있습니다.

3. Apple Silicon M2에서의 환경 설정

Apple Silicon M2는 ARM 아키텍처를 기반으로 하여, 기존의 Intel 기반 Mac과는 다른 환경을 제공합니다. 따라서, M2에서 OpenCV와 C++를 설치하기 위해서는 몇 가지 추가적인 설정이 필요합니다.

4. VS Code 설치 및 설정

먼저, Visual Studio Code(VS Code)를 설치해야 합니다. VS Code는 다양한 언어를 지원하는 강력한 코드 편집기입니다. Apple Silicon에 맞는 버전을 다운로드하려면 VS Code 공식 웹사이트로 가서 Apple Silicon 버전을 선택하여 설치합니다.

설치가 완료되면, VS Code를 실행하고 C++ 확장 프로그램을 설치합니다. 이를 통해 C++ 개발 환경을 더욱 편리하게 사용할 수 있습니다.

5. Homebrew 설치 및 OpenCV 설치

Homebrew는 macOS에서 패키지를 관리하는 도구입니다. Homebrew를 설치하려면 터미널을 열고 아래의 명령어를 입력합니다:

bash /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

설치가 완료되면, OpenCV를 설치할 수 있습니다. 터미널에 다음 명령어를 입력하여 OpenCV를 설치합니다:

bash brew install opencv

설치가 완료되면, OpenCV의 경로를 확인하고 환경 변수를 설정해야 합니다. 아래의 명령어를 입력하여 OpenCV의 설치 경로를 확인합니다:

bash brew info opencv

이제 VS Code에서 OpenCV를 사용할 수 있도록 설정합니다. VS Code의 설정 파일에 OpenCV의 경로를 추가합니다.

6. OpenCV와 C++ 프로젝트 설정

이제 OpenCV와 C++ 프로젝트를 설정할 차례입니다. VS Code에서 새로운 C++ 프로젝트를 생성하고, CMakeLists.txt 파일을 생성하여 OpenCV 라이브러리를 포함시킵니다. 아래는 기본적인 CMakeLists.txt의 예시입니다:

cmake cmake_minimum_required(VERSION 3.10) project(프로젝트명)
find_package(OpenCV REQUIRED) add_executable(프로젝트명 파일명) target_link_libraries (프로젝트명 ${OpenCV_LIBS})

이 코드는 지정한 이미지를 불러와서 화면에 표시하는 간단한 예제입니다. 이미지를 불러올 수 없는 경우 오류 메시지를 출력합니다.

7. 프로젝트 실행

CMakeLists.txt를 완성한 후, 우리가 원하는 프로젝트를 실행할 차례입니다. VScode 터미널에서 실행하게 됩니다. 다음 명령어들을 입력하면 됩니다.

cd build make ./프로젝트명

다음과 같이 입력하시게 되면 CMakeLists.txt에서 설정한 파일이 실행됨을 알 수 있습니다. 실행한 프로젝트를 종료하시려면 control + z 누르시면 됩니다.

이번 문제는 프로그래머스 Level 2 [멀쩡한 사각형] (https://school.programmers.co.kr/learn/courses/30/lessons/62048) 입니다.

문제 설명

가로 길이가 Wcm, 세로 길이가 Hcm인 직사각형 종이가 있습니다. 종이에는 가로, 세로 방향과 평행하게 격자 형태로 선이 그어져 있으며, 모든 격자칸은 1cm x 1cm 크기입니다. 이 종이를 격자 선을 따라 1cm × 1cm의 정사각형으로 잘라 사용할 예정이었는데, 누군가가 이 종이를 대각선 꼭지점 2개를 잇는 방향으로 잘라 놓았습니다. 그러므로 현재 직사각형 종이는 크기가 같은 직각삼각형 2개로 나누어진 상태입니다. 새로운 종이를 구할 수 없는 상태이기 때문에, 이 종이에서 원래 종이의 가로, 세로 방향과 평행하게 1cm × 1cm로 잘라 사용할 수 있는 만큼만 사용하기로 하였습니다.

가로의 길이 W와 세로의 길이 H가 주어질 때, 사용할 수 있는 정사각형의 개수를 구하는 solution 함수를 완성해 주세요.

한줄로 요약하면!! 가로/세로 값이 해당 사이즈의 직사각형을 반절로 접었을 때, 그 대각선을 지나는 칸을 제외한 나머지 칸을 구하면 됩니다.

제한사항

W, H : 1억 이하의 자연수

입출력 예시

w = 8 , h = 12 일때, 전체 칸은 96칸 입니다. 그 직사각형의 대각선을 그립니다. 해당 대각선이 지나는 칸이 총 16칸이기 때문에 그 만큼을 제외한 80칸이 return 됩니다.

코드 작성 전, 생각 정리

• 파라미터가 int 타입인데, return 타입이 long이라 계산할 때 타입 변환하기
• 다른 값들 통해서 규칙성을 찾기
  • 위의 사진을 보면, 총 4번의 동일한 패턴을 보인다.

여기서 4라는 숫자가 어떻게 나올 수 있을까? 예제에서 8과 12일 때, 4라는 숫자는 여러가지로 생각해볼 수 있지만 최대공약수로 추측할 수 있다. 그 외의 경우에도 고려해보면 공약수가 없는 경우를 제외하면 모든 경우에 최대공약수로 결과값을 구하면 원하는 값과 동일하다.

1. (2,3)일 때, 4개의 직사각형이 영향을 받음

2. (5,2)일 때, 6개의 직사각형이 영향을 받음

   일반식으로 만들어보면!! 영향을 받는 직사각형의 수 = (너비) + (높이) - 1 이 되고, 결론적으로 전체 계산식을 작성하면 (너비) x (높이) - ((너비) + (높이) - 1) x (최대공약수)이 됩니다.

코드(자바)

class Solution {
    public long solution(int w, int h) {
        long answer = 1;
        long big = gcd(w,h);
        long weight = (long)w;
        long height = (long)h;

        answer = weight*height - ((weight/big)+(height/big)-1)*big;

        return answer;
    }

    public static long gcd(int a, int b) {
        while (b != 0) {
            int temp = b;
            b = a % b;
            a = temp;
        }
        return (long)a;
    }
}

개인 소감

규칙성을 찾는데 시간이 걸렸다. 매번 코딩 테스트 문제만 풀이하면서는 '어떤 라이브러리의 어떤 메소드를 사용하면 좋을까?' 이런 고민들을 많이 했었다. 너무나도 많은 라이브러리에 메소드를 기억하기 어려워서 찾아서 공부하고, 찾아서 코드에 작성하는 형식이였다. 이번 문제는 다른 문제들과 다르게 오랜만에 라이브러리와 메소드를 고민하는 것보단 고등학교 시절로 돌아가 수학 문제를 풀던 때로 돌아간 기분이였다. 뭐든 안하면 잊어버리고 머리가 굳기 마련이다. 굳지 않고 말랑말랑한 상태 유지를 위해서 열심히 노력하자!!