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;
    }
}

개인 소감

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

이번 문제는 프로그래머스 Level 2 기능개발 입니다.

문제 설명

프로그래머스 팀에서는 기능 개선 작업을 수행 중입니다. 각 기능은 진도가 100%일 때 서비스에 반영할 수 있습니다.

또, 각 기능의 개발속도는 모두 다르기 때문에 뒤에 있는 기능이 앞에 있는 기능보다 먼저 개발될 수 있고, 이때 뒤에 있는 기능은 앞에 있는 기능이 배포될 때 함께 배포됩니다.

먼저 배포되어야 하는 순서대로 작업의 진도가 적힌 정수 배열 progresses와 각 작업의 개발 속도가 적힌 정수 배열 speeds가 주어질 때 각 배포마다 몇 개의 기능이 배포되는지를 return 하도록 solution 함수를 완성하세요.

제한 사항

1. 작업의 개수(progresses, speeds배열의 길이)는 100개 이하입니다.
2. 작업 진도는 100 미만의 자연수입니다.
3. 작업 속도는 100 이하의 자연수입니다.
4. 배포는 하루에 한 번만 할 수 있으며, 하루의 끝에 이루어진다고 가정합니다. 예를 들어 진도율이 95%인 작업의 개발 속도가 하루에 4%라면 배포는 2일 뒤에 이루어집니다.

입출력 예시

progresses: 현재 진행률 speeds: 하루당 개발 속도 return: 배포 당시 구현 완료된 기능의 수

문제 요약

progresses의 순서는 우선순위를 의미하기 때문에 바꾸지 않고, 앞에 있는 기능 개발이 완료되어야 뒤에 있는 기능들도 같이 배포할 수 있습니다. 각기 다른 진행 속도를 갖기 때문에 뒤에 있는 것이 모두 진행이 완료되어도 앞에 있는 기능이 완료되지 않으면 배포가 불가능합니다.

문제 풀이 전 생각 정리

• 큐를 이용해서 풀면 될꺼 같습니다. 큐의 성질인 (FIFO)를 이용합니다다.

1. progresses의 값을 큐에 넣고 speeds를 기반으로 증가를 시켜줍니다.
2. 100이 넘는 숫자들은 remove 하고, answer의 값을 증가시킵니다.
3. 이 과정을 반복 후, answer를 return 합니다.

코드

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

class Solution {
    public ArrayList solution(int[] progresses, int[] speeds) {
        ArrayList<Integer> answer = new ArrayList<Integer>(); //추가하는데 편의를 위해서 ArrayList 사용
        Queue<Integer> works = new LinkedList<>();

        // Queue에 progresses값으로 100%까지 걸리는 일수 저장하기
        for(int i =0; i< progresses.length; i++){ 
            float cal = (100-progresses[i])/speeds[i];
            if((100.0-progresses[i])%speeds[i] != 0) cal++;
            works.offer((int)cal);
        }

        // 배포를 위한 검사 시작
        while(!works.isEmpty()){
            int work = works.poll(); // 제일 앞에 있는 것을 하나 꺼냄.
            int count = 1;

            //work보다 작은 것들의 수를 셈. 배포할 때, 몇개의 기능을 배포할 수 있는지 파악하기 위해서
            while(!works.isEmpty()){
                if(work < works.peek()) break; // work보다 크면 그 기능 뒤부터는 배포 불가능해서 종료함.
                works.remove();
                count++;
            }
            answer.add(count); // answer에 추가해줌.
        }

        works.clear();
        return answer;
    }
}

개인 소감

난이도는 level2 치고는 어렵지 않았던 것 같다. 풀이를 생각하는데 어려움이 있었던 건 아니고 아무래도 Queue, ArrayList, LinkedList와 같이 자바 내장 라이브러리를 사용을 해야해서 level2가 아닌가 싶었다. 그리고 큐를 사용하지 않고 문제를 풀이할 수 있을거 같다는 생각이 들긴 하였다. 나중에 시간이 되면 배열로도 한번 풀어봐야겠다.

이번 문제는 2020 KAKAO BLIND RECRUITMENT에서 출제되었고 level 2 문자열 압축 입니다.

문제 설명

데이터 처리 전문가가 되고 싶은 "어피치"는 문자열을 압축하는 방법에 대해 공부를 하고 있습니다. 최근에 대량의 데이터 처리를 위한 간단한 비손실 압축 방법에 대해 공부를 하고 있는데, 문자열에서 같은 값이 연속해서 나타나는 것을 그 문자의 개수와 반복되는 값으로 표현하여 더 짧은 문자열로 줄여서 표현하는 알고리즘을 공부하고 있습니다. 간단한 예로 "aabbaccc"의 경우 "2a2ba3c"(문자가 반복되지 않아 한번만 나타난 경우 1은 생략함)와 같이 표현할 수 있는데, 이러한 방식은 반복되는 문자가 적은 경우 압축률이 낮다는 단점이 있습니다. 예를 들면, "abcabcdede"와 같은 문자열은 전혀 압축되지 않습니다. "어피치"는 이러한 단점을 해결하기 위해 문자열을 1개 이상의 단위로 잘라서 압축하여 더 짧은 문자열로 표현할 수 있는지 방법을 찾아보려고 합니다.

예를 들어, "ababcdcdababcdcd"의 경우 문자를 1개 단위로 자르면 전혀 압축되지 않지만, 2개 단위로 잘라서 압축한다면 "2ab2cd2ab2cd"로 표현할 수 있습니다. 다른 방법으로 8개 단위로 잘라서 압축한다면 "2ababcdcd"로 표현할 수 있으며, 이때가 가장 짧게 압축하여 표현할 수 있는 방법입니다.

다른 예로, "abcabcdede"와 같은 경우, 문자를 2개 단위로 잘라서 압축하면 "abcabc2de"가 되지만, 3개 단위로 자른다면 "2abcdede"가 되어 3개 단위가 가장 짧은 압축 방법이 됩니다. 이때 3개 단위로 자르고 마지막에 남는 문자열은 그대로 붙여주면 됩니다.

압축할 문자열 s가 매개변수로 주어질 때, 위에 설명한 방법으로 1개 이상 단위로 문자열을 잘라 압축하여 표현한 문자열 중 가장 짧은 것의 길이를 return 하도록 solution 함수를 완성해주세요.

제한 사항

s의 길이가 1000이하, 모두 소문자입니다.

입출력 예시

문제 요약(문제가 너무 길어,,,)

Main point 반복되는 문자를 "반복횟수 + 반복되는 문자"로 대체하는데 최대한 짧게 만드는 것이다.

문제 풀이 전 생각 정리

1. 최소 위해서 최대로 초기화한다. answer를 문자열의 길이로 정하고 시작한다.
2. 글자를 1 ~ s.length()/2로 순차적으로 잘라서 검사를 진행한다.

-> substring 사용하면 될 듯 3. 잘라서 검색하다가 반복이 되지 않으면 "반복횟수 + 반복되는 문자"로 저장한다. -> 최소로 만드는 것이 목표이기 때문에 s를 다시 재사용 가능성 있음 4. 길이가 1인 경우는 그냥 return 1 처리

❗️ 굳이 문자열로 저장해서 문제를 풀어야할까?❗️ 아무래도 문자열이 무거우니깐 단순 검사 통해서 하면 어떨까?

코드

import java.util.ArrayList;

class Solution {

    public int press(String str, int length) {
        StringBuilder sb = new StringBuilder(); // 줄인 문자열을 저장.

        String last = "";
        int count = 0;
        for (int start = 0; start < str.length(); start += length) {
            int end = start + length;

            if (end > str.length()) end = str.length(); //길이가 오버돼서 에러나는 경우

            String token = str.substring(start, end); //압축할 단위

            if (token.equals(last)) count++;
            else {
                if (count > 1) sb.append(count);
                sb.append(last);
                last = token;
                count = 1;
            }
        }
        if (count > 1) sb.append(count); //1은 반복이 아니기 때문에 1보다 큰 값일 경우
        sb.append(last);

        return sb.length();
    }

    public int solution(String s) {
        int answer = s.length();
        if (s.length() == 1) return 1;

        for (int length = 1; length <= s.length()/2; length++) {
            int pressed = press(s, length); // 압축했을 때 문자열의 길이
            if (pressed < answer) { // 최소값 찾기
                answer = pressed;
            }
        }

        return answer;
    }
}

개인 소감

코딩 테스트 준비한지 얼마 되지 않아서 생각하는 것도 구현하는 것도 미숙한 부분들이 많다는 느낌을 많이 받았다. 그리고 문제 풀고 나서 개인적으로 문자열을 새롭게 만들어서 결과를 구하는 방법이 메모리 측면에서 비효율적이라는 생각이 들었다. 추후 문자열로 저장하지 않고 단순 검사를 통해서 결과값을 구해볼 예정이다.

to be continue,,,,