좀 늦었지만 작성해보는 후기ㅎㅎ

Advent of SQL 2025는 solveSQL에서 진행하는 이벤트로, 12월 1일 부터 크리스마스까지 매일 하나의 SQL을 문제를 푸는 것으로 구성되어있다.

위와 같이 어떤 시점에 문제를 풀었느냐에 따라서 받을 수 있는 뱃지가 나뉘어지는데, 나는 12월 1일부터 매일매일 시간안에 모든 문제를 풀어 Advent of 2025 뱃지를 받았다.

Can you see this?!

38명 중 한명이라니 뿌듯하군. (야호~)

회사 다니면서 DB 마이그레이션할 때 SQL를 쓰긴 했지만, 자주 쓰진 않았어서 문법이 가물가물 했었는데 이번에 문제들을 풀면서 많이 감이 끌어올려진 것 같다. 특히나 윈도우 함수를 활용하는 것에 많이 익숙해진 것이 가장 큰 수확이라고 생각한다!

한편으로는 문제를 풀면서, '문제 상황에 대한 해결책은 AI가 더 잘하긴 할텐데, 의미가 있는 활동일까?' 라는 생각도 들었다. 이 어드벤트 캘린더를 완주한 지금도 생각은 동일하긴 하다. AI가 나보다 더 빨리 잘 풀 수 있을 것 같다.

그렇다면 이 활동의 의의가 뭐였을까?

의의

1. 알아야 판단할 수 있다.

나는 미래의 개발자 핵심 역할 중 하나가 판단이라고 생각한다. 누군가 생산한 코드가 도메인과 구조에 장기적으로 적합한지를 최종적으로 책임지고 결정해야하는 사람이 있어야 한다고 생각하고, 그게 전문지식을 보유한 개발자가 될 것이라고 생각한다. 즉, 판단을 위해서는 전문지식이 필요하며 그에 익숙한 사람이어야 한다. 그러한 측면에서 이번 활동은 SQL에 좀더 노출되고 익숙해지는 시간이었다고 생각한다. 간단히 말하면 공부의 일환이었다는 것~

2. 루틴 시작의 트리거

나를 움직이는 원동력은 루틴이다. 루틴을 시작하기만 하면, 나머지는 일사천리로 진행할 수 있다. 그러한 측면에서, 이 활동은 큰 부담도 없고, 문제를 풀었을 때 성취감이 있기 때문에, 카페에 앉아 가장 먼저 시작할 수 있는 일이 되었다. 내 루틴을 시작하는 요긴한 트리거로 아주 잘 작동한 셈이다.

마무리하며

2025년 연말에 가벼운 마음으로 하기 좋았던 활동이었다ㅎㅎ 무사히 완주한 나 자신에게 박수!👏 2026년에는 더 많은 도전들을 해나갈 예정인데, 새로운 성취를 위한 좋은 시작점인 것 같다. 기대되는구만. 남은 연말에는 회고하는 시간과 함께 새로운 목표를 가지고 돌아오겠다.

그럼 이만~

12월 22일자 문제를 푸는 도중 알게 된 것에 대한 간단 공유.

상황

datetime 타입의 칼럼을 요일로 변환해야 했다.

풀이방법

TO_CHAR(칼럼명, 'Day')

를 사용해서 변환.

문제상황

• 제출: Thursday
• 정답: Thursday

??????? 뭘 잘못한거지??????????

원인

PostgreSQL의 TO_CHAR 함수 스펙을 제대로 알지 못해 발생한 문제다.

TO_CHAR 함수 스펙을 확인해보자.

9char을 맞추기 위해 공백 패딩이 들어가있다고 한다. 오류 문구를 다시 보니 Thursday 가 아닌 Thursday 임을 확인할 수 있었다.

해결

TRIM 함수쓰기!

TRIM(TO_CHAR(칼럼명, 'Day'))

TO_CHAR(칼럼명, 'FMDay')를 쓰면 공백이 없는 요일명을 반환하긴하나, 이는 PostgreSQL전용 기능이므로, 범용성을 고려하면 TRIM을 사용하는게 더 좋다.

번외

TO_CHAR(칼럼명, 'Day')는 왜 공백 포함하여 9자를 맞출까?

1. 왜 9자?

Wednesday 가 가장 긴 요일명인데, 이게 9자여서.

2.공백을 왜 넣을까?

보고서, 터미널 UI 등으로 출력 시 정렬되어보이기 위함.

TO_CHAR 함수의 의도가 '데이터 추출'보다는 '출력 포맷 맞추기'인 것으로 보인다. 참고로 PostgreSQL외의 다른 DBMS도 동일하게 공백포함하여 출력된다고 한다.

오랜만에 이런 함수 스펙 관련된 이슈를 마주한듯하다. 코딩테스트 준비를 하다보면 사소해보이지만 중요한 지식공백을 발견할 수 있어서 참 좋다.

회사에서 한달치의 엑셀 데이터를 한번에 업로드하는 기능을 구현하였다.

초기에는 Batch INSERT 방식을 통해 데이터를 삽입하였다. 하나의 SQL 문으로 여러행을 삽입할 수 있었고 초기에는 충분히 빠르게 작동했었다.

그런데 해당 서비스 특성 상, 한달치 데이터의 양이 점진적으로 늘어나는 구조였고, 점점 처리속도가 느려졌다.

검색을 통해, 속도 저하의 원인이 SQL 문 실행 시 파싱에 대한 오버헤드임을 파악하였고,

파싱 오버헤드가 없는 Postgres의 COPY 로 대체하여 약 140%로 처리 속도를 감축하였다. (4000개 데이터 기준)

이번 글에서는 해당 문제 해결 과정에서 학습한 내용들을 정리하고자 한다.

개요

우선 Batch INSERT 문과 COPY문에 대해 간단한 설명을 하고 넘어가겠다.

Batch INSERT문

INSERT INTO … VALUES … 의 형식을 갖추고 있다.

values 절에 여러 개의 행 데이터를 넣으면, 여러개의 행을 한번에 삽입할 수 있다.

COPY문

PostgreSQL 전용 기능으로, 대용량 데이터를 한번에 처리할 때 사용한다.

파일이나 스트림에서 데이터를 불러와, 테이블에 삽입하거나 테이블의 데이터를 파일로 내보낼 때 사용된다.

테이블 삽입 예시

COPY employees (employee_id, name, department_id, hire_date)
FROM '/tmp/data.csv' 
DELIMITER ',' 
CSV HEADER;

참고

• DELIMITER ’,‘ : 필드의 구분자로 ,를 쓰겠다는 뜻
• CSV : 파일형식이 CSV임을 나타냄.
• HEADER : 맨 첫줄은 필드가 아닌 헤더임으로, 첫줄을 읽지 않도록 설정.

또는

COPY my_table (col1, col2) FROM STDIN WITH (FORMAT CSV);

테이블을 파일로 내보내기 예시

COPY employees 
TO '/employees_backup.txt'
WITH (DELIMITER E'\t');

참고

• WITH (DELIMITER E'\t') : 필드간의 구분은 \t (탭) 으로 하겠다는 뜻

지금은 COPY와 INSERT 문을 비교할 것이기 때문에, 테이블 삽입에 대한 내용만 다룰 것이다.

비교 실험

대용량 데이터 처리 시, Batch INSERT문보다 COPY문이 더 빠른 속도를 보인다.

실험을 통해 속도 차이를 확인해보자.

실험 내용은 간단하다.

같은 개수의 데이터를, Batch INSERT로 삽입했을 때의 시간과

COPY문으로 삽입하였을 때의 시간을 비교한다.

코드는 아래와 같다.

코드

import psycopg2
import time
from io import StringIO

# 1. DB 연결 설정
conn = psycopg2.connect(
    host="127.0.0.1",
    database="pg-test",
    user="jeongyun",
    password="jeongyun",
    port="5434"
)

# 테스트 데이터 생성 함수 (5,000개)
def generate_data(num_rows):
    data = []
    for i in range(1, num_rows + 1):
        data.append({
            'value1': f'TestValue_{i}',
            'value2': i * 10
        })
    return data

NUM_ROWS = 5000 # 10,000개, 50,000개 바꿔가며 테스트
test_data = generate_data(NUM_ROWS)

# --- 1. 배치 INSERT 테스트 ---
def test_batch_insert(data, connection):
    with connection.cursor() as cur:
        # 트랜잭션 시작
        cur.execute("BEGIN;") 

        # 튜플 리스트로 변환
        insert_values = [(item['value1'], item['value2']) for item in data]

        # VALUES (...), (...), (...) 형태의 배치 SQL 생성
        placeholders = ', '.join(['%s'] * len(insert_values[0]))
        query = f"INSERT INTO test_data (value1, value2) VALUES ({placeholders})"

        # executemany를 사용하여 내부적으로 배치 INSERT를 시도 (드라이버 최적화)
        start_time = time.time()
        cur.executemany(query, insert_values)
        end_time = time.time()

        cur.execute("COMMIT;")
    return end_time - start_time

# --- 2. COPY FROM STDIN 테스트 ---
def test_copy(data, connection):
    with connection.cursor() as cur:
        # 1. 데이터 문자열 생성 (CSV 형태)
        csv_data = StringIO()
        for item in data:
            # COPY는 필드 순서와 정확히 일치하는 문자열이 필요
            csv_data.write(f"{item['value1']},{item['value2']}\n")
        csv_data.seek(0)

        # 2. COPY 실행
        start_time = time.time()
        cur.copy_from(
            csv_data, 
            'test_data', 
            columns=('value1', 'value2'),
            sep=','
        )
        end_time = time.time()

    connection.commit()
    return end_time - start_time

# --- 테스트 실행 및 결과 출력 ---

# 테이블 초기화
with conn.cursor() as cur:
    cur.execute("TRUNCATE TABLE test_data RESTART IDENTITY;")
conn.commit()

# 배치 INSERT 실행
batch_time = test_batch_insert(test_data, conn)

# 테이블 초기화
with conn.cursor() as cur:
    cur.execute("TRUNCATE TABLE test_data RESTART IDENTITY;")
conn.commit()

# COPY 실행
copy_time = test_copy(test_data, conn)

print(f"--- {NUM_ROWS}개 데이터 로드 결과 ---")
print(f"1. 배치 INSERT 시간: {batch_time:.4f} 초")
print(f"2. COPY FROM STDIN 시간: {copy_time:.4f} 초")
print(f"\nCOPY가 배치 INSERT보다 약 {(batch_time / copy_time):.2f}배 빠릅니다.")

conn.close()

결과

5,000-10,000-50,000-30,000-20,000-40,000 순

INSERT 문과, COPY 문 모두 데이터 개수에 비례하게 속도가 증가하긴 하나, 증가폭은 INSERT 문이 현격히 높은 것을 알 수 있다.

둘다 하나의 SQL인데, 왜 COPY가 더 빠를까?

그 이유를 알기 위해서는 SQL의 실행과정을 알아야 한다.

해석

SQL 문의 실행과정

여타 언어와 같이, SQL도 결국 일종의 명령어다.

명령어는 해석이 되어야 한다.

SQL은 아래와 같이 네 단계를 거쳐 해석된다.

1. 파싱 단계
   • SQL문을 토큰 단위(ex. SELECT, *, FROM, table_name 등)로 자르는 Lexing 단계를 거쳐,
   • 토큰들을 조합하여 문법에 맞는지 확인 후, Parse Tree를 만든다.
2. 분석 단계
   • 의미 확인 : SQL 문에서 사용된 테이블명, 함수명 등이 실제로 시스템 상에 존재하는지 확인하고,
   • 권한 확인 : 해당 명령어를 사용할 수 있는 권한이 있는지를 확인하며,
   • 쿼리 정규화 : 테이블 명을 DB 내부 id로 대체하는 등의 작업을 하여 parse tree → query tree 로 변환한다.
3. 플래닝 단계
   • 옵티마이저 실행: 인덱스 유무, 통계 정보 등을 고려하여 가장 비용이 적게 드는 Execution Plan을 생성한다.
4. 실행 단계
   • 플래닝 단계에서 생성한 Execution Plan대로 실행한다.

Batch INSERT 문의 경우, SQL문 자체가 굉장히 길어진다.

5,000개를 넣는다고 하면 VALUES 절 다음에 5,000개의 행에 대한 데이터 내용이 들어갈 것이고,

50,000개를 넣는다고 하면 VALUES 절 다음에 50,000개의 행에 대한 데이터 내용이 들어갈 것이다.

그말인 즉슨, INSERT 문을 사용할 경우, 데이터가 늘어날수록 데이터베이스 엔진이 파싱해야할 SQL양도 계속 늘어난다는 뜻이다.

반면, COPY의 경우, SQL 문은 데이터 개수와 관계없이

COPY test_data (value1, value2) FROM STDIN WITH (FORMAT CSV);

으로 고정이다.

데이터가 50,000개든 5,000,000개든 SQL 문 길이는 늘어나지 않는다는 말이다.

그렇기 때문에, COPY 문을 사용할 경우 SQL문 파싱에 드는 속도는 항상 동일하며, 데이터 양에 따라 데이터 스트리밍 시간만 변동되는 것이다.

정리

이번 글에서는 PostgreSQL에서 대용량 데이터를 삽입할 때 Batch INSERT와 COPY 방식 간의 성능 차이를 확인하고, 그 원인에 대해서 분석해보았다.

두 방식 모두 대량의 데이터를 저장하나,

Batch INSERT는 데이터가 많아질수록 SQL 문이 길어져, SQL 파싱에 많은 시간을 소요하는 반면,

COPY는 SQL 문이 고정된 형태로 유지되며 내부적으로 스트리밍 방식으로 데이터를 처리하기 때문에 SQL 파싱에 대한 오버헤드가 거의 없었다.

각 방식의 내부 동작 원리를 이해해야, 데이터 특성과 서비스 구조에 가장 적합한 접근 방식을 선택할 수 있다.

결국 핵심은 ‘되느냐’ 가 아니라 ‘왜 되느냐’ 임을 다시 한번 느낀다.

남의 삽질로그🪏: 다른 회사, 다른 사람들의 겪은 문제와 해결방법을 나의 방식으로 정리하는 글입니다. 정리를 통해 인사이트를 얻고, 문제해결력을 기르고자 합니다.

• 오늘의 글 : https://oliveyoung.tech/2025-12-08/iframe-postmessage-authentication/

배경

iframe으로 MFE 구축함.

MFE 자체에는 인증 시스템이 없었음.

따라서 MFE 내에서 인증 필요 시, 호스트앱으로부터 인증요청하고 토큰을 전달받는 구조.

(postMessage를 사용하여 구현)

문제

이때, MFE에서 동시다발적으로 API를 호출할 경우, API를 호출한 횟수만큼 인증 요청을 보냈음.

최초로 전달받은 토큰 하나만 있어도 충분할텐데, 불필요하게 여러번 요청을 보내고, 여러개의 토큰을 받게 됨.

해결

첫번째 요청 처리 중이라면,

그 다음부터 오는 요청들을 모두 큐에 집어넣기.

첫번째 요청에서 응답이 왔다면, 큐에 들어있던 모든 요청들에 대해 같은 응답 보내주는 방식으로 해결.

제약 조건 역추론

• 각 요청들은 각각의 서로 다른 API 와 물려있음 - 모든 요청에 대한 응답이 있어야 함. (첫번째만 처리하고 나머지 요청은 무시하면 안됨.)

어떻게 큐를 떠올렸을까?

여러 요청을 모두 보관해야함. 이때, 요청들이 순차적으로 쌓이고, 첫번째 요청에 대한 응답이 반환되었을 때 처리됨. 즉, 대기열 개념 ⇒ Queue

글을 읽고 선언적 프로그래밍 개념에 대한 이해를 넘어, 코드를 작성할 때 중요한 태도가 다시 리마인드되는 부분이 있었다. 그 내용을 기록으로 남기고자 정리를 해본다.

절차적 코드

“무엇을 어떻게 할지(How)”를 시간 순서대로 서술하는 코드

절차적 코드는 목표를 달성하기 위한 단계적인 행위를 기술한다.

아래 예시는 DOM API를 이용해 사용자 프로필을 생성하는 절차적 코드이다.

function createUserProfile(user) {
  const container = document.createElement('div');
  container.className = 'user-profile';

  const nameElement = document.createElement('h2');
  nameElement.textContent = user.name;
  container.appendChild(nameElement);

  const emailElement = document.createElement('p');
  emailElement.textContent = user.email;
  container.appendChild(emailElement);

  if (user.avatar) {
    const avatarElement = document.createElement('img');
    avatarElement.src = user.avatar;
    avatarElement.alt = `${user.name}의 아바타`;
    container.appendChild(avatarElement);
  }

  return container;
}

출처: https://evan-moon.github.io/2025/09/07/declarative-programming-misconceptions-and-essence/

사용자 프로필(userProfile)을 만들기 위해 어떤 DOM 요소를 생성하고,

어떤 순서로 속성을 설정하고, 어디에 추가할지 등을 명시적으로 기술하고 있다.

즉, “행위의 순서”가 코드의 핵심이다.

선언적 코드

“무엇을 할지(What)”를 중심으로 관계를 표현하는 코드

선언적 코드는 구현의 절차보다, 관계나 구조의 표현에 집중한다.

아래는 같은 기능을 React로 작성한 선언적 코드이다.

function UserProfile({ user }) {
  return (
    <div className="user-profile">
      <h2>{user.name}</h2>
      <p>{user.email}</p>
      {user.avatar && (
        <img src={user.avatar} alt={`${user.name}의 아바타`} />
      )}
    </div>
  );
}

출처: https://evan-moon.github.io/2025/09/07/declarative-programming-misconceptions-and-essence/

여기서는 “어떤 순서로 렌더링해야 하는가”보다,

UserProfile을 구성하는 요소 간의 관계가 중점적으로 표현된다.

즉, 시간적 순서보다는 의도와 구조가 드러난다.

절차적 vs 선언적을 구분하는 것 자체는 중요하지 않다.

핵심은 “A는 절차적이고, B는 선언적이야”를 구분하는 게 아니라,

현재 다루고 있는 문제의 본질이 무엇인지를 판단하는 것이라고 생각한다.

• 관계 표현이 중요한 부분이라면 선언적으로 접근하는 게 좋다.

  도메인의 구조를 명확하게 드러낼 수 있기 때문이다.

• 행위의 순서나 구현 효율이 중요한 부분이라면 절차적으로 작성해도 된다.

  예를 들어 인프라 레벨에서는 안전하고 효율적인 실행이 더 중요하다.

“비즈니스 로직 레벨에서는 선언적으로 접근하는 것이 좋다.

도메인의 본질적 관계를 표현하는 데 집중해야 하기 때문이다.

반면 인프라 레벨에서는 절차적이어도 괜찮다.

효율적이고 안전한 구현이 더 중요하기 때문이다.

핵심은 경계를 명확히 하고 추상화의 레벨을 맞춰주는 것이다.

어느 레벨에서 어떤 관심사를 다루는지 분명히 구분해야 한다.”

— Evan Moon, 선언적 프로그래밍에 대한 착각과 오해

결국 선언적 프로그래밍은 더 이해하기 쉬운 코드를 작성하기위한 접근 방식이라고 생각한다.

내가 표현하려는 의도를 명확히 파악하고,

그 의도를 가장 잘 드러낼 수 있는 방식을 선택할 수 있느냐가 결국 가장 중요하지 않을까.

Reference

• 선언적 프로그래밍에 대한 착각과 오해 — Evan Moon Blog

좋은 글을 작성해주신 문동욱 개발자님께 감사의 마음을 전합니다.

그동안 큰 접점이 없어서 AA님이라는 사람에 대해 잘 몰랐는데, 이번 대화를 통해서 큰 인사이트를 얻을 수 있었다.

내가 AA님께 가장 궁금했던 것은 왜 우리 회사에 합류하게 되었는지였다.

전공이 이 분야도 아니셨고, 이 분야에 대한 관심도가 크진 않으셨던 것으로 알고 있었기 때문이다.

내가 “어떤 이유로 합류를 결정하게 되셨어요?” 라고 여쭸을 때, “해보면 좋겠다, 재밌겠다, 라는 생각이 들어서요”라는 답변을 들을 수 있었다. 제안 받으셨을 때 어떤 직무를 맡는지도 모르셨다고 했다.

나는 어떤 것을 실행할 때, 실패에 대한 리스크를 크게 느끼는 사람이고, 그 부분이 도전을 저지한다고 생각하여 고치려고 노력하고 있다. 그래서 리스크가 있음에도, 어떤 것이 동기가 되어 그렇게 빠르게 결정을 내리셨는지가 궁금했다. 어떤 것이든 잘할 거라는 단단한 자신감이 원동력이 된 것일까? 자신감을 키워야하나? 라는 생각이 들던 찰나에, 돌아오는 답변은,

*“잃을 게 없다고 생각해서요. 가진 것도 없으니” *

충격이었다.

듣자 마자 든 생각은 ‘그러게. 난 잃을게 뭐가 그렇게 많다고 걱정을 한거지?’ 였다.

내가 그렇게 잃을 게 많았나?

뭐를 잃는 거지? 시간? 그치만 그 시간을 가치를 창출하는데 쓰면 아까운게 아닌데?

*나는 허상의 리스크랑 싸우고 있는 것이었다. *

허상의 리스크에 대한 걱정 때문에, 크고 작은 도전을 미루기는 너무나 아깝다는 생각이 든다.

물론 그 리스크가 허상이 아니라 실제 리스크라면 전략적으로 접근해야한다.
핵심은, “진짜” 리스크가 맞는지를 판단하는 것. 이라고 생각한다.

무언가를 실행할 떄 리스크가 있는 듯 하여 망설여진다면, 정말 리스크가 맞는지 문제정의를 명확히 해야겠다는 생각이 들었다. 경험상, 어려워 보이는 태스크도 들여다보면 그렇게 어렵지 않은 경우도 많았다. 나는 어려워보이는 태스크를 접근할 때는 divide and conquer 방식처럼, 더이상 어렵지 않아 보일 때까지 태스크를 쪼개본다. 비단 태스크가 아니라, 다양한 도전 과제에 망설임을 느꼈을 때에도, 망설임의 사고 흐름을 쪼개서 글로 써보면 객관화하는데에 도움이 되지 않을까. 잊지 말고 실천해봐야지.

주간 목표를 잘 세우고, 달성해보기로 한지 3주쯤 지났다.

지난 3주간 주중의 가용시간을 적고, 매일의 태스크를 타당하게 설정한 뒤, 잘하려는 마음보다는 내가 실제로 할 수 있는 양을 기준으로 목표를 세워보았다.

이전에 내가 설정한 솔루션에서는 ‘태스크 소요시간을 너무 적게 잡는 경향이 있으니 1.3배 늘려서 작성하자’ 라고 했는데, 굳이 그럴 필요는 없었다. 저번 글을 작성하면서, 내가 태스크를 수행할 수 있는 속도보다 무리하게 짧은 시간을 공기로 잡은 것이 메타인지가 되었나본지 점점 오차가 줄어들었다.

매일의 가용시간을 적는 것은 아직 완전히 익숙해지지는 않았지만, 내가 하루에 수행할 수 있는 양을 가늠하는데에 역시 도움이 되었다. 저번주에는 회사가 대한민국 ESG 친환경대전에 참여하게 되어 코엑스에 다녀왔는데, 이로 인해 줄어든 가용시간을 잘 고려해서, 무리하지 않게 태스크를 분배할 수 있었다.

이렇게 목표를 잘 설정해보니, 그동안 무리하게 많은 양을 수행하는 것을 목표로 잡음으로써 발생하였던 신체적인 무리와 정신적인 스트레스가 줄어들었다는 게 느껴졌다. 단순히 몸과 마음이 나아진 것뿐만 아니라, 고민하고 생각할 수 있는 힘이 생겨 더 효율적으로 몰입하여 일할 수 있었다.

새로운 문제, 왜 항상 90%정도만?

그래서 결국 목표를 달성했느냐?

아쉽게도 그러진 못했다. 새로운 문제점이 발견되었다. 세운 계획대로 착착착 진행을 잘 하다가, 묘하게 목표에서 한 90% 정도 달성하고 멈춰버리는 일이 자꾸 발생하였다. 그렇다고 목표를 120%로 세워버리면 또 이전처럼 몸과 마음을 혹사하는 것이라…어떻게 해야할지 고민이 되었다.

나만 이런가 싶은 마음으로 검색을 해보았더니 접근-회피 갈등이라는게 나왔다. 똑같은 지점에서 즐거운 자극과 불쾌한 자극이 동시에 일어나는 경우에 발생하는 갈등이라고 한다.

내 심리적 상황이 자연스럽에 이 이론에 대입이 되었다.

내가 목표로 향해가는 길은 바람직한 방향으로 가는 것(접근)이지만, 목표에 가까워질 수록 만약 목표를 달성하지 못하면 어쩌지? 라는 생각(회피)이 들어 자꾸만 목표달성을 회피하는 것 같았다.

90%를 100%로 만들기 위한 솔루션

어떻게 이 회피를 타파해보면 좋을까.

접근-회피 갈등에서 자극에 접근하는 방법은 두가지가 있다.

1. 자극에 대한 욕구를 높이기
2. 회피에 대한 두려움을 줄이기

사실 목표를 달성못한다고해서 죽는 건 아니기 때문에(…), 난 2번 방향으로 해결책들을 생각해보았다.

나의 해결책

1. 회피 강도가 높아질 수록 목표에 가까워진 것이라는 걸 리마인드하자.
2. 목표에 가까워진 것은 목표를 달성한게 아니라는 걸 리마인드하자.
3. 목표에 가까워질수록 일을 세밀하게 나눠보자. 그리고 세밀하게 나눈 태스크를 하나씩 끝낸다는 마인드로 접근하자. (목표 달성이라는 거시적인 시야보다는 작은 태스크 하나하나를 끝내는 것에 집중하는 미시적인 태도로 전환해보자)

1, 2는 간단하게 말하자면 스스로 최면을 거는 방법이라고 생각한다. 그동안의 나에 대한 빅데이터를 생각해보았을 때… 자기 최면은 잘 안걸리는 것 같긴하다. 그래서 3번까지 생각해보았다.

나는 미시적인 시야를 가지고 디테일한 것을 조정하는 걸 잘한다. 그래서, 내 시야를 좁게 만들어보고 목표보다는 태스크만 보게 하면 부담감이 덜어지고 회피하고자 하는 마음이 줄어들지 않을까?라는 가설을 세워보았다. 이번 주 부터는 이 가설을 잘 검증해보려고 한다. (해결책 1, 2도 생각날때마다 적용할 예정!) 과연 어떤 결과가 나올지..! 궁금하다.

마무리

누군가는 이러한 것들을 스스로 너무나 잘 컨트롤하기 때문에, 왜 이렇게까지 할까 라는 생각이 들 수 도 있겠다. 그치만 나는 나의 부족함을 너무나도 인정하기 때문에, 재능이 없으면 노력으로 메꿔야한다는 생각으로 나를 잘 빚어보고자 한다.

나는 일할 때, 개인의 주간 목표를 설정한다. 요즈음 주간 목표를 달성하지 못해 주말, 심지어는 연휴까지 일을 하는 일이 반복되었는데, 이번주 오랜만에 주간 목표를 완전히 달성하였다.

이번 주 해야할 일을 모두 다 하고 나니, 주말동안 일에 대한 부채감 없이, 알차고 행복한 시간들을 보낼 수 있었다. 토요일에는 친구들과 만나고 기획 책을 읽고, 일요일에는 학교 수업을 듣고, 개인 스터디를 하고 이렇게 여유롭게 회고를 작성하였다. 내가 이상적으로 생각하던, 휴식과 발전이 있는 삶이었다.

장기적으로 보았을 때, 이러한 시간을 보내는 것이 지속가능하게 일할 수 있는 능력을 만들어준다고 생각한다. 5일 동안의 지침을 보상할 수 있는 재충전의 시간과, 개인 스터디를 통한 개발자로서의 능력 향상의 시간.

그래서, 나의 지속가능성을 높여주는 '주간 목표 달성'을 왜 못하고 있었고, 어떻게 더 잘 수행할 수 있을지에 대해 생각하고 정리해보는 시간을 가졌다.

🥲 주간 목표 달성이 왜 어려웠을까?

주간 목표를 달성하지 못한 주에는, 주말까지 업무에 대한 부채감에 스트레스를 받았고, 능력이 충분하지 못한 자기자신에 대해 자괴감이 들었다.

나는 왜 주간 목표를 달성하는게 어려웠을까?

1. Ability 판단 미스

내가 할 수 있을 거라고 생각한 것보다 실제로 내가 할 수 있는 일의 양이 적었다.

왜 판단 미스가 있었는가?

a. 변수를 고려하지 않았다. 프로그래밍을 하다보면 변수가 항상 발생한다. 그러나 나는 변수들에 대한 패딩을 전혀 고려하지 않고, 이 일을 변수없이 가장 빨리 끝낼 수 있는 시간을 기준으로 일정을 산정하였기 때문에 예상한 만큼 일을 달성하지 못했다. 솔직히 말하자면, '능력있는 사람으로 인정받으려면 이 정도 소요시간에 이 태스크를 끝내야지'라는 내 워너비를 예상 소요시간으로 잡았던 것 같다. 그것도 아주 극단적으로.

** b. 실질적인 가용시간을 고려하지 않았다.** 나는 현재 학교와 회사를 병행하고 있고, 수업일정이 매주 변경되는 상황이라 가용시간이 유동적이다. 그러나 학교 강의 시간, 출퇴근 소요시간을 제외한 실제 가용시간을 매주 따져보지 않았고, '이 정도는 할 수 있겠지'라는 생각으로 태스크를 할당하였다. 태스크에 대해 전략적으로 대응하지 못했던 거다.

2. 외부 변수로 인해 팀의 목표가 빈번히 변경되었다.

우리 회사는 스타트업이기 때문에, 대기업에 비해 변동성이 크다. 이로 인해 팀의 목표가 변경되는 상황이 반번히 일어난다.

(현재 이런 케이스에 대해서는 주간 목표를 변경하는 방식으로 대응하고는 있었으나, 구체적인 해결책을 재고해보고자 적어두었다.)

👉 문제를 해결해보자!

주간 목표를 좀더 잘 달성하기 위해, 어려웠던 점을 해결할 수 있는 실질적 방법들을 생각해보았다.

첫번째, 예상 소요 시간에 패딩 부여하기

내가 처음에 할 수 있다고 생각한 시간(초기 예측시간)의 1.3배를 예상 소요시간으로 설정한다. 추후 실제 소요시간을 평균내어, 1.3배가 적절한 수치인지 확인 후 조정한다.

이를 실천하기 위해, 각 태스크마다의 예상 소요시간과 실제 소요시간 측정하여, 노션에 기록해보고자 한다.

두번째, 가용시간을 기록하기

전 주 일요일에 요일별 가용시간을 기록한다. 가용시간이 변경될 경우, 수행해야할 태스크의 양을 조절한 뒤, 주간 목표가 적절한지 다시 판단한다.

이를 실천하기 위해, 내가 매주 적는 주간 목표 노션 페이지에 요일별로 가용시간을 적어놓을 거다.

세번째, 외부 변수로 인한 팀 목표 변경에 대응하기

외부 변수로 인한 팀 목표 변경 유형은 아래와 같이 나눌 수 있다.

1. 새로운 업무가 추가됨. 2. 마감일이 앞당겨짐.

각각에 대한 해결책은 아래와 같다.

1. 새로운 업무가 추가되는 경우, 새로운 업무를 주간 목표에 추가하고, 해당 비중만큼 기존 목표를 줄인다.
2. 마감일이 앞당겨졌을 경우, 해당 부서와의 회의를 통해 해당 시간동안 달성할 수 있도록 태스크를 조정한다. 불가능할 경우에만 주말까지 투자한다.

🚀 "높은 퀄리티의 목표"를 달성하기 위하여

앞서 주간 목표를 달성하지 못했던 이유를 생각해보고, 그것에 대한 해결책을 만들어 보았다. 그러나 아무리 해결책을 잘 실천해도, 주간 목표의 퀄리티가 떨어진다면, 달성하는 의미가 없다.

예를 들어 주간 목표를 달성하기 위해 태스크를 아주 적게 할당하거나, 팀의 목표와 달리 전혀 쓸데없는 것들을 주간 목표로 설정하였다면? 일주일동안 나와 회사의 발전에 하등 쓸모없는 행위를 한 것이다.

그래서 내가 생각하는 "높은 퀄리티의 목표"가 무엇이고, "퀄리티 높은 목표였는지"에 대해서 평가하는 방법도 생각해보았다.

높은 퀄리티의 목표란?

높은 퀄리티의 목표는 아래 두가지로 생각해보았다.

1. 나의 총력을 다했을 떄 목표를 달성할 수 있어야 함. 2. 팀의 목표를 달성할 수 있어야 함.

우선 목표를 달성하기 위해 최선을 다할 수 있어야 한다. 왜? 내가 하는 일에 모든 능력을 끌어다쓰는 것이 일에 대한 나의 태도이고, 장기적으로 내가 더 높은 가치를 가진 인력이 될 수 있는 방법이기도 하다.

그리고 나의 목표를 달성하면, 팀의 목표를 달성할 수 있어야 한다. 우리 회사, 팀이 하고자 하는 것을 안한다? 회사와 팀에 소속되어있음에 대한 의무를 안지키는 거다. 그럴거면 회사 왜 다니니.

목표의 퀄리티 평가하기

높은 퀄리티의 목표가 무엇인지 정의하였으니, 내가 설정한 목표의 퀄리티를 평가할 수 있어야 한다. 앞서 말했다시피 단순히 목표 달성 여부로 목표의 퀄리티가 좋았다고 평가할 수 없기 때문.

그래서 세가지 항목으로 평가기준을 매겨 보았다.

1. 총력을 다했는지? (010) 2. 내 ability(총력)를 적절히 판단하였는지? (010) 3. 주간 목표를 달성함으로써 팀의 목표도 달성하였는지? (0~10)

정량적으로 평가할 수 없는 요소들이라 점수화를 해보았다. 매주 점수를 합산하여 목표의 퀄리티를 판단해보려고 한다.

마무리하며

오랜만에 글을 통해 나의 문제점을 되짚어 보고, 더 나아가기 위한 방법에 대해 서술해보았다. 내가 생각하는 나 자신을 돌아보고, 내 가치관도 다시금 확인할 수 있는 시간이었다.

회고를 통해 만들어본 해결책들은 이번주부터 적용해볼 예정이다. 적용뿐만 아니라 현실적으로 실천할 수 있는 방식이 맞는지 판단해보고 그에 맞게 수정하며 점진적으로 발전시키려고 한다.

나의 지속가능성을 위해서!🚀

그치만 우리가 기술을 신경쓰는 이유는 무엇일까?

사람이 가지고 있는 자원과 시간은 한정적이기 때문이다.

따라서 최대한 효율적으로 소기의 목적을 달성하고자 하며, 그를 위해 현재 상황에 가장 적합한 기술을 선택해야한다.

그렇다고 하여 무조건 빨리 구현하는 것이 좋은 방법은 아니다. 대부분의 소프트웨어는 일회용으로 사용되기보다는, 점진적으로 새로운 기능들을 추가하고, 기존의 기능들을 변경하며 더 많은 가치를 제공하려 한다.

따라서 우리와 같은 기술자들은, 앞으로 펼쳐질 미래까지 고려하여 소프트웨어가 더 많은 가치를 제공할 수 있도록 해야한다. 그렇기 때문에 소프트웨어의 유지보수성, 확장성, 가독성을 고려하며 기능을 구체화해야하는 것이다.

V8이 자바스크립트를 바이트 코드(bytecode)로 컴파일하고 실행한다는 내용을 보고, 바이트 코드에 대한 내용을 찾아보게 되었다. 처음에는 바이트 코드와 바이너리 코드가 동치인줄 알았어서 바이너리 코드에 대한 내용을 정리해보았고, 바이트 코드의 개념에 대해 읽다가 바이트 코드와 기계어는 어떻게 다른지가 궁금해져 관련 내용들을 찾아 정리하게 되었다.

정리

바이너리 코드(Binary code)

2심볼 시스템을 사용하는 데이터를 의미한다. 주로 이진수 체계의 0과 1을 의미한다 (0, 1이 각각 데이터 하나를 나타냄). 한국어로는 이진 코드라 불린다.

기계어(Machine language)

CPU가 해독하고 실행할 수 있는, 비트 단위(0, 1)로 이루어진 컴퓨터 언어를 통틀어 말한다. 어셈블리어와 1:1로 대응한다.

바이트 코드(Byte code)

CPU와 같은 특정 하드웨어가 아닌, 가상 컴퓨터에서 작동하는 실행 프로그램을 위한 이진 표현법이다. 가상컴퓨터 위에서 작동하기 때문에, 특정 하드웨어에 종속되지 않는다는 특징을 가지고 있다. 즉, 하드웨어에 대한 의존성이 낮다고 말할 수 있다.

바이트 코드는 컴파일 과정을 거쳐서 생성된다. 생성된 바이트 코드는, 주로, 한번에 한 명령어만 읽어 실행하는 인터프리팅 방식으로 실행이 된다.

바이너리 코드, 기계어, 바이트 코드간의 관계

기계어와 바이트 코드는 모두 0과 1로 이루어져있으므로, 바이너리 코드로 이루어졌다고 말할 수 있다.

기계어는 하드웨어가 이해할 수 있는 컴퓨터 언어이고, 바이트 코드는 하드웨어가 아닌 가상 컴퓨터에서 실행시킬 수 있는 코드이다. 기계어로 쓰여진 코드이냐, 바이트 코드이냐에 따라 실행할 수 있는 환경이 다르다는 것이 차이점이라고 할 수 있다.

느낀 점

각 용어들에 대한 개념들을 정리해본 시간이었다. 머릿속으로는 알고 있었던 개념들도 있었지만, 막상 글로 풀어내려니 명확히 알고 있지 않은 부분들이 보였다.

요즘 글쓰기의 중요성을 계속 느낀다. 시간이 좀 더 걸리더라도, 당장 다음 내용으로 넘어가고 싶은 급한 마음이 들더라도, 글로 차곡 차곡 정리해보려고 한다. 나만의 지식 자산을 많이 만들겠어🥹

참고

• 이진 코드
• 기계어
• 바이트코드

yarn PnP모드로 전환 후 vscode의 typescript가 제대로 적용되지 않아 애를 먹었었다. 그래서 블로그글을 막 구글링하여 일단 세팅을 했었는데, 내가 어떤 명령어를 수행하고 뭐가 일어났는지 전혀 모르겠더라.

그래서 공식 문서를 기반으로 몰랐던 부분을 다시 짚어가며 정리를 해보았다!

✨ 과정

yarn PnP모드 사용 시, vscode와 같은 smart IDE에서는 TypeScript를 위한 특별한 설정이 필요하다.

editor SDKs 생성 및 세팅하기

yarn dlx @yarnpkg/sdks

위 명령어를 실행하면 editor SDKs가 생성되고 설정들이 세팅된다.

yarn dlx 패키지 : 임시 환경에서 패키지를 실행할 때 사용하는 명령어

• 참고: https://yarnpkg.com/cli/dlx

• @yarnpkg/sdks 패키지를 이미 가지고 있는 경우라면 yarn sdks명령어를 통해 editor SDKs 생성 및 설정 세팅을할 수 있다. 아래 명령어 중 적합한 놈을 실행해주면 된다.

  • yarn sdks vscode vim: yarn에서 지원하는 editors(vscode, vim)에 맞는 base SDKs를 생성하고 설정 세팅해준다.

  • yarn sdks base: yarn에서 지원하지 않는 editors를 위한 명령어로, base SDKs만 설치해주고 세부 설정들은 직접 세팅해주어야 한다.

  • yarn sdks : 모든 설치된 SDKs와 editor settings를 업데이트 할 때 사용한다.

참고❗️
yarn PnP 모드에서는 패키지를 zip형태로 관리한다. 따라서 사용한 패키지의 원래 코드를 보기위해서는 (go-to-definitions 기능을 사용하기 위해서는) ZipFS와 같이 zip 저장소에 저장된 파일들을 바로 읽을 수 있는 extension을 설치해주어야 한다.

vscode에서 TS 설정 명시적으로 활성화하기

vscode를 사용하는 경우, 보안문제로 인해 타입스크립트 설정을 명시적으로 수행해주어야 한다.

1. yarn dlx @yarnpkg/sdks vscode 실행 - 위의 editor SDKs 생성 및 세팅하기에서 이미 실행해주었다면 다시 할 필요 없음.
2. cmd + shift + p => Setting TypeScript Version 입력 => 엔터
3. Use Workspace Version 클릭

📖 참고

• https://yarnpkg.com/getting-started/editor-sdks
• https://yarnpkg.com/getting-started/editor-sdks#editor-setup

우리 조직에서 자주 사용하는 코드들이 있다. consolelog("변수명",변수)라던지, (console.log 아님) const dispatch = useAppDispatch() 라던지, const {변수명} = useAppSelector(state => state.슬라이스명)이라던지...

위와 같은 코드들을 정말 많이 사용하고 있으나, 항상 이것들을 직접 타이핑했었다. 짧지 않은 코드들을 반복해서 입력하는 것이 귀찮기도 했거니와, 반복되는 코드들을 간단하게 입력할 수 있는 방법이 있다면 코드 타이핑에 소요되는 시간이 많이 단축될 것이라고 생각했다. 짧은 시간내에 많은 결과물을 만들어야하는 우리 조직에서, 시간 단축은 아주 금 같은 것...!

따라서 이를 해결하기 위해, 짧은 예약어로 특정 패턴의 코드를 간단히 생산할 수 있는 코드 snippet을 해결책으로 떠올렸다.

그럼 우리 조직의 생산성을 위해, 우리 조직에 맞는 커스텀 snippet을 만들어보자!

⚒️ 스니펫 만들기

1. 커스텀 스니펫 파일 만들기.

맥북 기준 cmd + shift + p (윈도우 ctrl + shift + p) 입력하여 "Configure user Snippet" 검색 후 클릭!

클릭을 하면 위와 같은 화면이 나타난다. 프로젝트와 관계없이 전역적으로 해당 스니펫을 적용하고 싶다면, New Global Snippets file...을, 해당 프로젝트에만 적용하고 싶다면 New Snippets for '프로젝트명'... 이라는 명령어를 클릭하면 된다.

빈칸에는 원하는 snippet 이름을 붙여주면 된다. 나는 sample이라고 이름을 붙여주었다. 입력하고 엔터를 눌러주면 아래와 같이 snippet이름.code-snippets라는 이름을 가진 파일이 생성된다.

2. 스니펫 문법에 맞게 스니펫 작성하기

해당 파일안에 아래와 같이 스니펫을 작성해보았다. (주석은 지워줬음)

코드

{
  "Print to console": {
    "scope": "javascriptreact,typescriptreact,javascript, typescript",
    "prefix": "lg",
    "body": ["console.log('$1');", "$2"],
    "description": "Log output to console"
  },

  "For Loop": {
    "scope": "javascriptreact,typescriptreact,javascript, typescript",
    "prefix": ["for", "for-const"],
    "body": ["for (const ${2:element} of ${1:array}) {", "\t$0", "}"],
    "description": "A for loop."
  }
}

• 제목 : 스니펫의 제목을 입력해주면 된다. 스니펫마다 구분이 되도록 작성해주어야 한다.

• scope : snippet이 적용될 언어를 작성해주면 된다. 여러개의 언어를 지원하고 싶은 경우 콤마로 구분을 해주면 된다. scope를 아예 작성하지 않을 경우, 모든 언어에 대해 스니펫이 적용된다. 다양한 언어플랫폼을 사용하는 경우 scope별로 작성하는 것이 효율적일 수 있다! 그러나 나는 현재 js, ts만 사용하고 있어 scope를 생략해주었다.

  주의❗️ jsx, tsx 파일에도 스니펫을 적용하고 싶은 경우, scope에 javascriptreact, typescriptreact를 추가로 적어주어야 한다. "javascript, typescript" 만 적어주면 jsx, tsx 파일에서는 적용이 안된다.

• prefix: 스니펫을 실행시킬 단축어. 배열안에 여러개의 단축어를 집어넣을 수 도 있다.

• body: 스니펫 실행 시 실제로 작성해줄 코드를 의미한다. 자세한 문법은 아래를 참고.

  • Tab Stop $1 , $2 등으로 스니펫이 실행 후 커서가 위치할 곳을 지정해준다. $ 뒤에 붙은 숫자 순으로 커서가 이동되며, 커서의 이동은 tab 버튼 으로 실행할 수 있다.

  ---

  • Placeholder ${1:something1}, ${2:something2}형식으로 작성해줄 수 있다. Tab Stop과 마찬가지로 커서의 위치를 지정할 수 있고, 커서의 위치에 그 뒤에 적어준 문자가 placeholder로 들어가게 된다. 중첩된 형식으로도 작성할 수 있다. ex.${1:parents ${2:child}}

  ---

  • Choice 커서가 위치하는 곳에 들어갈 수 있는 옵션들을 미리 작성해줄 수 있다. ${1|one,two,three|}형태로 작성하였을 경우, 커서위치에서 one,two 또는 three 중에 하나의 값을 선택할 수 있다.

  ---

  • Variables vscode에서 지정해준 변수명을 통해 스니펫이 실행되는 파일 이름이라던지, 코드라인 번호라던지 등을 변수로 삽입할 수 도 있다!$변수명 또는 ${name:default} 형태로 사용할 수 있다. 변수명의 종류는 링크를 참고하자.

• description : 스니펫에 대한 세부적인 설명을 적어주면 된다.

3. 실행 예시

위의 snippet들 중 For Loop 이라는 제목을 가진 스니펫을 실행해보았다. 실행결과는 아래와 같다.

✨ 나의 결과물

{
  "Console log": {
    "prefix": ["cl", "clog"],
    "body": [
     "consolelog$1('🔊 ~ $TM_FILENAME:$TM_LINE_NUMBER $CLIPBOARD', $CLIPBOARD);",
      "$2"
    ],
    "description": "Log the text in clipboard with consolelog function"
  },

  "Create dispatch object": {
    "prefix": "dsp", // dispatch
    "body": ["const dispatch = useAppDispatch$1()", "$2"],
    "description": "Create dispatch object from useAppDispatch hook"
  },

  "Get redux state": {
    "prefix": "uaps", //useAppSelector
    "body": ["const {$2} = useAppSelector(state => state.${1:sliceName})", "$3"],
    "description": "Get redux state from useAppSelector hook"
  }
}

짜란-!

간단히 설명을 덧붙여보겠다!

• Console log

  단어를 선택하여 복사한 뒤, 원하는 위치에 해당 스니펫을 사용하면 consolelog('🔊 ~ 파일명:코드라인 넘버 복사한 단어', $복사한 단어); 형태로 코드가 작성된다. 커서는 consolelog 바로 뒤에 넣어, 해당 함수가 import 되지 않았을 때 바로 import할 수 있도록 만들어주었다.

• Create dispatch object

  스니펫을 실행하면 const dispatch = useAppDispatch() 코드가 생성된다. Console log와 마찬가지로 useAppDispatch가 import 되지 않았을 때 바로 import할 수 있도록 커서를 배치해주었다.

• Get redux state 스니펫을 실행하면 const {$2} = useAppSelector(state => state.$1) 코드가 생성된다. 커서 1번 위치에 sliceName을 placeholder로 주어, 무엇을 입력해야하는지 명시해주었다. 또한, sliceName을 먼저 입력하면, 해당 slice의 state들을 가져올 때, 자동완성을 사용할 수 있으므로 커서 위치를 slice - state 순으로 배치하였다.

🤔 느낀 점 및 고민

해당 스니펫으로 조직의 생산성이 향상될 생각을 하니 굉장히 두근두근하다ㅎㅎ 얼른 팀원들에게 공유하고 싶다.

그런데 이때 든 생각.

공유는 어떻게 하지?... 파일로 공유하게 되면 스니펫을 업데이트 할 때마다 모두가 이를 갱신해주어야 한다. 이것이 절대 좋은 해결책은 아닐 터.

따라서 이 다음으로는, 제작한 스니펫을 익스텐션으로 배포해보고자 한다. 나의 작은 도전기, 다들 함께 해요!

참고

• https://code.visualstudio.com/docs/editor/userdefinedsnippets

• https://www.youtube.com/watch?v=umeqCopb96w

참고: git flow extension이 설치되어있다는 것을 전제로한 글입니다.

✨How to do

0️⃣ git flow init 명령어를 실행한다.

git flow init은 Git Flow branching Model에 맞게 git repo를 초기화하기 위한 명령어이다.

이 명령어를 실행하면, Git Flow branching Model의 컨벤션을 따르는 branch가 생성되고, feature, hotfix, release와 같은 브랜치의 prefix(접두어)가 지정된다.

feature, hotfix, release가 브랜치의 prefix(접두어) 인 이유 > feature/popup, hotfix/1.0.2, release/1.3.0 등의 형태로 사용되기 때문

또한, 이 명령어를 실행한 뒤에는, 이 git flow extension에서 제공하는 명령어들을 이용하여 쉽게 Git Flow branching Model 대로 브랜치들을 관리할 수 있게 된다.

아, 이미 이 명령어가 실행된 적이 있다면, 굳이 다시 하지 않아도 된다. 말그대로 초기화이니까!

1️⃣ git flow hotfix start 버전명 을 실행한다.

이 명령어를 실행하면, hotfix/버전명의 브랜치가 생성된다.

이때 해당 명령어를 실행하는 브랜치명이 꼭 main이 아니어도 된다. 다른 브랜치에서 실행해도, 알아서 main브랜치에서 따와진다. 이러한 실수를 줄일 수 있는 요소가 git flow 사용의 장점이 아닐까 싶다.

2️⃣ hotfix할 요소들을 고치고, 커밋한다.

여기는 부가설명할게 없다. 고치고 hotfix/버전명브랜치에 커밋!

3️⃣ git flow hotfix finish 버전명 명령어를 실행한다

위의 명령어를 실행하면, hotfix/버전명의 커밋 내용이 로컬의 main과 develop에 각각 merge된다. 그리고 hotfix/버전명 브랜치는 로컬에서 삭제되며, "버전명"의 이름을 가진 tag가 생성된다.

그리고 현재 브랜치는 develop 브랜치가 된다.

4️⃣ 로컬의 main과 develop브랜치를 각각 origin의 main과 develop에 push 해준다.

현재 hotfix한 내용들은 local에만 반영이 되어있다. 따라서, 이를 원격 repo에도 반영을 각각 해주어야 한다.

• local main -> origin main
• local develop -> origin develop

만약 upstream repo를 따로 두어 pr로 관리하는 프로젝트라면, origin에 push한 내용들을 PR로 올려주면 된다.

• origin main -> upstream main
• origin develop -> upstream develop

⚠️주의
현재 브랜치가 무엇인지 잘 확인하고 push해야 한다.
git flow hotfix finish 버전명 명령어 실행 후 에는 develop 브랜치가 현재 브랜치로 설정된다.

5️⃣ git push remote명 --tags 명령어를 통해 원격 repo에 태그를 반영한다.

origin에 반영하려면 git push origin --tags를,
upstream에 반영하려면 git push upstream --tags를 하면 된다.

위의 명령어는, 원격 repo에는 없고 로컬에만 있는 모든 태그들을 repo에 반영하는 명령어이다.
만약 특정한 한개의 태그만 반영하고 싶다면,
git push remote명 태그명 명령어를 사용하면 된다.

참고
로컬의 태그 확인하는 명령어: git tag

🎙️느낀 점

git flow extension을 사용함으로써 사람이 수동으로 해야하는 것들을 효과적으로 줄일 수 있다는 것을 체감했다.
위의 내용들을 테스트해보면서, git flow가 제공하는 feature 등의 기능도 사용해보았는데, 기능개발이 끝난 뒤 로컬과 origin의 feature 브랜치를 모두 지워줘서 굉장히 편리했다.

그동안은 겁먹어서(...) 잘 안썼는데, 이제부터라도 열심히 써야겠다. ㅠ
새로운 기술은 입문이야 어렵지 시작하면 별거 아니라는 것,
그리고 그 기술을 도입함으로써 많은 시간을 단축할 수 있다는 것을 다시 기억하자.

🧐 분석

지라, 노션 등 여러 페이지를 참고해보면, 브라우저 배율을 축소했을 때는 ui 변화가 없이 선형적으로 컴포넌트들이 줄어들었다. 그러나 확대를 할때는, ui 배치가 달라지거나, 글씨 크기, 컴포넌트 크기 등이 급격히 변하는 느낌을 보여주었다.

이 모습을 보고 내린 결론은 아래와 같다.

1. "하나의 특정 기준 해상도를 정하고, 그 해상도에서는 모두 px 또는 퍼센트 단위로 지정한다."

2. 기준 해상도 보다 작아질 경우, responsive하게 vw, vh 등의 단위를 활용하거나, ui배치 등을 다르게 하여 해당 해상도에 대응한다.

내가 여기서 깨달은 가장 중요한 포인트는, 어느 순간부터는 vw,vh를 사용하지 않는 해상도가 있다는 점이다.

📱 About 기준 해상도

왜 어느 순간부터는 vw,vh 를 사용하지 않을까? 그 어느 순간은 도대체 "어느" 순간일까?

내 생각에는 그 "어느" 순간은 모바일이나 태블릿이 아닌, 컴퓨터, 즉 랩탑이나 데스크탑으로 보는 순간이다. 그 순간 부터 vw, vh를 보지 않는 이유는, 사용자가 배율을 자유롭게 확대, 축소함에 따라 ui도 자연스럽게 확대 축소되게 하기 위함이라고 생각한다.

vw,vh 단위를 사용하면, 기준이 모니터 그 자체이기 때문에, 확대와 축소를 해도 그 크기가 변하지 않는다.

그러나 브라우저에서 확대 축소를 하면 해상도가 변하는 것과 같아서, 같은 30px이어도 해상도가 높으면 작게보이고, 해상도가 크면 크게 볼 수 있는 것이다.

_(물론 너무 확대를 많이하게 되면 모바일 또는 태블릿의 해상도처럼 되어 vw, vh단위로 짜여진 ui가 보인다. 이에 대한 대응책은 아직 생각 중..) _ 모바일과 태블릿에서는 확대 축소가 해상도와 전혀 상관이 없기 때문에, vw, vh로 대응해도 상관없다.

그리고 모바일과 태블릿은 그 해상도가 너무도 다양하기 때문에 vw, vh로 대응해야만 여러 기기에서도 유사한 화면을 확인할 수 있을 것이다.

✅ 기준 해상도를 정하는 방법

그럼 기준 해상도는 몇으로 설정해야할까?

명확한 답은 아직 찾지 못했지만, 일반적인 경우에는 1536*864 또는 1366*768이 되지 않을까 싶다. 이 사이트 에 들어가면 국가별, 대륙별 또는 전세계의 모니터 해상도 사용자 비율을 볼 수 있다.

우리나라는 1920*1080을 가장 많이 쓰지만, 그보다 낮은 해상도인 1536*864 또는 1366*768를 기준으로 작업하면 얻을 수 있는 장점은 아래와 같다고 생각한다.

1920*1080를 기준으로 작업하면 1536*864 또는 1366*768에서 ui가 일그러질 가능성이 있다.

그러나 1536*864 또는 1366*768에서 작업하게 되면, 이미 이 ui에서는 정상출력이 되므로, 1920*1080에서는 당연히 정상 출력될 것이다! (앞서 말했다시피 기준 해상도에서는 vw,vh를 안쓰니까 기준해상도보다 높은 해상도로 보면 기준해상도로 작업한 ui가 그대~로 축소된 형태가 된다.)

그래서 1920*1080보다 작은 해상도를 기준으로 작업하는게 좋다고 생각한다!

🥰 느낀 점

반응형에 대한 실마리를 조금씩 풀어나가고 있다는 생각이 든다.

아직 컴퓨터 화면에서 확대를 너무 많이 했을 때는 어떻게 효율적으로 대처를 해야할지는 잘 모르겠지만,

이번 프로젝트를 반응형으로 적용해가면서 또다른 깨달음을 얻을 수 있지 않을까 생각한다.

제 생각에 오류가 있거나, 더 나은 방법을 아신다면 꼭! 댓글로 남겨주시기 바랍니다! 감사합니다

비동기식 처리는 특정 코드의 연산이 끝나기 전에 다른 코드를 실행시키는 작동시키는 자바스크립트의 특성을 말합니다.

🙉 비유

비동기식 처리는 아래와 같은 상황에 빗댈 수 있습니다. 오늘 내가 해야할 일이 1. 이메일 보내기 2. 이메일 받기 3. 약속 준비하기 라고 합시다.

만약 이것을 동기식 처리(비동기식 처리의 반대)로 진행한다면, 아래와 같이 진행됩니다.

1. 이메일을 보낸다
2. 이메일 답장이 올 때까지 기다린다.
3. 이메일 답장이 오면 그제서야 약속 준비를 시작한다.

굉장히 비효율적이죠? 이메일 답장을 기다리는 것과 약속 준비하는 일은 꼭 그 순서를 지키지 않아도 되기 때문입니다. 만약 이메일 답장이 이틀 지나서 오게 된다면, 더 이상 약속을 준비하는게 의미가 없어지게 됩니다.

그럼 비동기식 처리로 진행한다면 어떻게 할 수 있는 걸까요?

1. 이메일을 보낸다.
2. 이메일이 올 때까지 기다리면서, 약속 준비를 한다.
3. 약속 준비를 하다가 이메일이 오면 이메일을 받는다.
4. 약속 준비를 마저 한다.

비동기식 처리를 이용하면, 이메일 답장을 기다리는 시간을 낭비하지 않을 수 있습니다. 같은 일을 처리하더라도 훨씬 빠르게 처리할 수 있습니다.

👩‍💻 비동기식 처리와 서버 API 통신

비동기식 처리는 이러한 장점을 가지고 있기 때문에, 서버와 API통신을 할 때 비동기식 처리가 사용됩니다.

클라이언트는 서버에 필요한 정보가 있을 때 요청을 보내게 됩니다. 그럼 서버는 그 요청에 대한 내용들을 찾고, 찾은 정보를 다시 클라이언트로 보내게 됩니다. 그리고 클라이언트는, 서버에 필요한 정보를 보내고 받는 것 이외에도 페이지를 렌더링하는 등의 일을 해야합니다.

만약 이를 동기식 처리로 진행하게 된다면,

1. 서버로 요청을 보내고
2. 서버에서 정보를 보내줄 때까지 기다린다.
3. 서버에서 정보를 보내주면, 그제서야 렌더링을 시작한다.

의 과정을 거치게 됩니다.

이러면 사용자는 빈 페이지를 바라보며 하염없이 기다리게 되겠죠...

그래서 우리는 API통신 시 비동기식 처리를 하게 됩니다.

1. 서버로 요청을 보낸 뒤
2. 서버로부터의 답변을 기다리는 동안 화면을 렌더링한다.
3. 서버로부터 답변이 오면 답변을 받는다.

서버로 부터 정보를 받는데 까지 걸리는 대기시간을 훨씬 효율적으로 사용하게 됩니다. 따라서, 비동기식 처리로 인해 사용자는 렌더링된 페이지를 좀더 빨리 볼 수 있습니다! 사용자가 지루하게 빈화면을 보는 시간을 줄일 수 있는 것이죠😀

어떠신가요, 비동기식 처리의 장점이 잘 느껴지나요?

📌 요약 및 마무리

지금까지 비동기식 처리에 대해 알아보았습니다! 비동기식 처리는 코드 실행을 하는 도중에 다른 코드를 실행할 수 있도록 하는 것을 의미하며, 서버와 API통신에 비동기식 처리를 적용하게 되면, 서버에게 정보 요청을 하는 코드를 실행하는 동안, 렌더링 등의 코드를 실행할 수 있습니다.

제가 말하고자 하는 바가 잘 전달되었길 바라면서 글을 마치겠습니다. 감사합니다!

참고 자료

• https://velog.io/@unani92/Axios-%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC%EB%A5%BC-%ED%86%B5%ED%95%9C-%EB%B9%84%EB%8F%99%EA%B8%B0%EC%B2%98%EB%A6%AC-%EB%B0%A9%EC%8B%9D
• https://joshua1988.github.io/web-development/javascript/javascript-asynchronous-operation/

💻출처 : 프로그래머스 > 코딩 테스트 연습 > 2017 팁스타운 > 짝지어 제거하기 🏆난이도 : Level 2

📜 문제

📝 요약

알파벳 소문자로 이루어진 문자열이 주어진다. 문자열에서 같은 알파벳이 붙어있다면, 그 둘을 제거한 뒤 앞뒤를 이어붙인다. 이 과정을 반복하여, 더이상 문자열을 제거할 수 없을 때 문자열이 남아있지 않은 상황이라면 1을, 문자열이 남아 있다면 0을 반환한다.

🧠 문제 분석

현재, 주어질 수 있는 문자열의 최대 길이는 1,000,000이다. 따라서 직접 같은 알파벳이 두개가 붙어있는 부분을 찾고, 해당 부분을 지운 뒤 다시 처음부터 탐색하여 다시 동일한 알파벳 두개가 붙어있는 부분을 찾는 방식은 시간초과가 날 것이라고 생각하였다.

문자열을 지울 지의 여부는 현재 관찰하고 있는 문자의 앞뒤만 보고도 판단할 수 있다. 예컨데 abbcc 문자열에서 2번째 인덱스인 b를 관찰한다고 하였을 때, 2번째 인덱스에 인접한 인덱스, 즉, 인덱스 1번과 인덱스 3번만 관찰하면 된다.

또한, 짝지어진 알파벳을 제거한 후, 남은 문자열의 앞뒤를 이어붙여야 하기 때문에, 짝지어진 알파벳 이외에도 나머지 알파벳들을 알고 있어야 한다.

💡 풀이 방법

위의 분석을 통해, 이 문제에 가장 적합한 자료구조는 stack이라고 판단하였다.

stack을 이용한다면, 현재 조회하는 문자와 인접한 문자를 stack의 top에서 쉽게 확인할 수 있으며, pop연산을 통해 문자 제거 및 이전 문자열과의 연결을 쉽게 구현할 수 있기 때문이다.

구체적인 구현방식은 아래와 같다.

1. 문자열을 맨 앞에서 부터 한 문자씩 순서대로 조회를 한다.
2. 현재 조회한 문자가 stack의 top에 있는 문자와 동일하다면, stack에서 pop을 수행한다. (짝지어졌으므로 제거)
3. 만약 현재 조회한 문자가 stack의 top에 있는 문자와 다르다면 stack에 저장한다.
4. 문자열을 끝까지 조회한 뒤, stack에 문자가 남아있다면 0을 반환하고, stack에 문자가 남아있지 않다면 1을 반환한다.

   stack 문자가 남아있다는 것은, 제거되지 않은 문자들이 있다는 것을 의미하기 때문이다.

💻 코드

위의 풀이과정을 코드로 구현하였다. stack에 아무 것도 없는 경우는 조회할 top이 없기 때문에, 바로 조회한 문자를 push해주었다.

function solution(s)
{
    const length = s.length
    const stack =[]

    for(let i = 0; i<length;i++){
        if(stack.length === 0) 
            stack.push(s[i])
        else
            stack[stack.length-1] === s[i] ? stack.pop() :  stack.push(s[i])
    }

🎤 느낀 점

stack을 떠올릴 수 있었다면 구현은 쉬웠던 문제라고 생각한다! 좀 더 어려운 응용 문제를 풀기 위해, 어떤 상황에서 stack을 사용하면 되는지를 위주로 정리해보았던 문제였다 :)

💻출처 : 프로그래머스 > 코딩 테스트 연습 > 2019 KAKAO BLIND RECRUITMENT > 오픈 채팅방 🏆난이도 : Level 2

📜 문제

📝 요약

사용자가 오픈 채팅방을 들어왔다 나갔다 할 수 있다.

사용자는 오픈 채팅방에 들어온 상태에서 닉네임을 바꿀 수 있고, 오픈 채팅방에 입장할 때도 닉네임을 바꿀 수 있다. 오픈 채팅방에서 나가있는 상태에서는 닉네임을 바꿀 수 없다.

사용자가 오픈 채팅방에 들어올 때는 "닉네임님이 들어왔습니다."라는 문구가 출력되고, 오픈 채팅방에서 나갈 때는 "닉네임님이 나갔습니다."라는 로그가 출력된다.

닉네임의 경우 사용자들끼리 중복될 수 있으며, 닉네임을 변경한 경우 로그에 출력된 닉네임까지 모두 변경된다.

사용자들에게는 고유한 아이디가 부여된다.

사용자의 채팅방의 입장&퇴장, 닉네임 변경 기록이 사용자의 아이디와 함께 주어진다. 입장과 닉네임 변경의 경우에는 닉네임도 함께 제공된다.

주어진 기록을 이용하여 최종적으로 출력될 로그를 구하시오.

🧠 문제 분석

결국은 사용자의 아이디에 해당하는 최종적인 닉네임만 알면 되는 문제이다. 이 최종 닉네임을 구하는 방법으로 아래와 같은 방법들을 생각해보았다.

💡아이디어 1 - 시간 초과

첫번째로는 look-up table을 만들어 보는 방식을 생각했다.

사용자가 채팅방에 들어오고 나가는 로그는 여러개 일 수 있는데, 사용자의 아이디에 따른 닉네임은 하나다.

왜냐하면, 우리는 사용자의 처음 닉네임, 두번째로 바꾼 닉네임.. 등의 히스토리가 필요한 것이 아니라, 최종 닉네임 단 하나만 필요하기 때문이다.

따라서, 아래와 같이 테이블을 구성하여 문제를 풀고자 하였다.

우선 문제에서 제공하는 기록을 조회하며 테이블들을 구성하였다.

기본적으로 id와 사용자의 Enter, Leave 정보는 왼쪽의 테이블에 저장하였다.

그리고 사용자의 닉네임을 바꿀 수 있는 Enter, Change 의 경우는 아래와 같은 두가지 상황에 따라 다르게 대처하였다.

• 오른쪽에 있는 테이블에 id가 있는 경우: 닉네임 변경
• 오른쪽에 있는 테이블에 id가 없는 경우: id와 닉네임을 테이블에 새로 추가

위와 같은 규칙으로 최종적인 테이블을 구성하였다면, 왼쪽 테이블의 id와 state를 하나씩 읽으며, 오른쪽의 look-up 테이블에서 사용자의 id에 대응하는 닉네임을 조회하여 찾고자 하였다.

이를 구현한 코드는 아래와 같다.

코드

function solution(record) {
    idAndState =[]
    idAndNickname=[]

    record.forEach((r)=>{
        let info = r.split(" ")
        const state = info[0]
        const id = info[1]
        const nickname = info[2]


        if(state==="Change" || state=="Enter"){
            const index = idAndNickname.findIndex((idNick)=>idNick[0]===id)
            if(state==="Change"){
                idAndNickname[index] = [id,nickname]
            }else{
                if(index===-1){
                    idAndNickname.push([id,nickname])
                }else{
                    idAndNickname[index] = [id,nickname]
                }
            }
        }

        if(state=="Enter" || state=="Leave"){
            idAndState.push([id,state])
        }

    })

    var answer = [];

    idAndState.forEach((idState)=>{
        const nickname = idAndNickname.find((idNick)=> idNick[0] === idState[0])[1]

        if(idState[1] == "Enter"){
            answer.push(`${nickname}님이 들어왔습니다.`)
        }else{
            answer.push(`${nickname}님이 나갔습니다.`)
        }
    })

    return answer;
}

이 코드의 결과는 실패다😅

코드를 짜면서도 걱정했었던 시간 초과가 발생했기 때문이다.

테이블 만들면서도 오른쪽 테이블에서 해당 id가 존재하는지 여부를 알기위해id로 검색 연산을 하고, 출력 로그들을 생성할 때도 오른쪽 테이블에서 id로 닉네임 검색 연산을 하니...시간을 안초과할수야 없겠더라.

그래도 도무지 아이디어가 나오지 않아 구글링을 하였다.

💡아이디어2 - Map 사용✨

구글링을 통해 얻은 것은 바로 Map 자료구조이다!

Map 자료구조는 key값과 value 값으로 구성되어 있고, 검색속도가 아주 빠르다는 특징을 가지고 있다.

검색 속도가 빠른 이유는, key값을 hashing 한 결과를 인덱스 값으로 사용하기 때문이다.

간단히 말하자면, key 자체를 배열의 인덱스로 사용하는 자료구조라고 생각하면 된다.

그렇기에, key값을 알고 있으면, 그에 대응하는 value를 아주 빠르게 조회할 수 있다.

현재 아이디어 1을 참고해보았을 때, 우리는 id에 대응하는 닉네임을 찾고자 하며, 조회에 시간이 오래걸리는 문제가 있었다.

여기에 Map 구조를 사용하면, id는 key에 대응시키고 닉네임는 value에 대응시킬 수 있으며, Map 구조의 특성 덕분에 실행 속도도 줄일 수 있다.

이를 구현한 코드는 아래와 같다.

💻 코드

function solution(record) {
    const idAndState =[]
    const idAndNickMap = new Map();

    record.forEach((r)=>{
        const [state,id,nickname] = r.split(" ");

        if (state !== "Change"){
            idAndState.push([id,state])
        }

        if(nickname){
            idAndNickMap.set(id,nickname);
        }

    })

    var answer = [];

    idAndState.forEach((idState)=>{
        const [id,state] = idState;
        const nickname = idAndNickMap.get(id)

        if(state == "Enter"){
            answer.push(`${nickname}님이 들어왔습니다.`)
        }else{
            answer.push(`${nickname}님이 나갔습니다.`)
        }
    })

    return answer;
}

🎤 느낀 점

머릿속 깊은 곳에 있는 Map을 다시 꺼내올 수 있었던 문제였다. 현재 문제에 가장 적합한 자료구조를 생각해내는 것도 중요한 요소라는 생각이 들었다.

💻출처 : 프로그래머스 > 코딩 테스트 > Summer/Winter Coding(2019) > 멀쩡한 사각형 🏆난이도 : Level 2

📜 문제

📝 요약

직사각형 종이를 대각선으로 자르면 두 개의 직각삼각형이 생긴다. 이 두개의 직각 삼각형에서 얻을 수 있는 1cm*1cm 크기의 정사각형 개수를 구하여라. 단, 각 정사각형의 가로, 세로는 원래 종이의 가로, 세로 방향과 평행해야 한다.

💡 아이디어 1 - O(WH)

직사각형을 대각선 방향으로 자르면 크기가 똑같은 직각 삼각형 두 개를 얻을 수 있다. 그럼 직각 삼각형 하나에 들어있는 정사각형 개수만 알면 되겠군!

따라서, 직각 삼각형에 정사각형을 그린 후, 해당 정사각형이 직각 삼각형 내부에 모두 포함되어있는지 판단하였다.

이를 판단하기 위해, 직각 삼각형을 아래 그림과 같이 모눈위에 올려놓았다.

노란색 선을 직선의 방정식으로 표현한 뒤, 정사각형의 오른쪽 위 꼭짓점을 직선의 방정식에 대입해, 결과가 음수인지 양수인지에 따라 하늘색 영역에 포함되는지 여부를 판단하였다.

그럼 정사각형의 오른쪽 위 꼭짓점을 기준으로 본다고 정했으니까, (1,1) 있는 정사각형을 시작으로 for 문을 돌리면서, 하늘색 영역을 벗어날 때까지 사각형의 x좌표를 하나씩 증가시키면 되겠네? 만약 하늘색 영역을 벗어나면 y좌표를 증가시켜서 그 윗줄에 포함된 정사각형 개수를 구하면 되고!

아, 그런데 문제의 조건을 다시보자. w, h 의 범위는 1억 이하의 자연수이다.

...

이렇게 풀면 무조건 시간 초과다

그래서 문제를 다시 읽었더니 예시의 그림이 눈에 들어왔다.

그림에서 약간의 힌트를 주고 있었다. 아, 대각선 부분에 걸쳐있는 사각형 개수만 구하면 되네! 그래서 아래의 방법을 생각하였다.

💡 아이디어 2 - 실제 풀이✅

이 방식은 컴퓨터 그래픽스의 rasterization 단계에서 사용하는 DDP 알고리즘과 유사하다. (수업 때 배운 걸 드디어 써먹는구나)

DDP 알고리즘의 경우, 대각선의 방향을 따라가며 대각선을 포함하는 정사각형을 찾는 알고리즘이다. 나는 DDP 알고리즘처럼 아래와 같은 규칙을 찾아보았다.

우선, 문제에서 준 예시와 달리 아래와 같이 사각형을 두고 생각하였다. (개인 취향)

이 사진을 보면, 대각선 위에 존재하는 정사각형의 옆이나 위, 그리고 대각선 위치(우상향 방향)에, 대각선 위에 있는 다른 정사각형이 존재한다는 것을 알 수 있다.

따라서, 정사각형의 오른쪽 위의 좌표가 (1,1)인 정사각형을 시작점으로 대각선을 따라 우상향 방향에 있는 정사각형을 보고, 대각선 위에 있는 정사각형의 특징을 알아냈다.

직사각형의 대각선의 기울기를 m이라고 하자.

현재 정사각형의 오른쪽 위 좌표를 (x,y) 라 했을 때, w > h 인 직사각형에서는

• x/y < m이라면 현재 정사각형의 오른쪽 정사각형도 대각선에 포함되고,
• x/y > m 이면, 현재 정사각형의 위쪽 정사각형이 대각선에 포함되며,
• x/y == m 이면, 현재 정사각형의 오른쪽 위 대각선에 있는 정사각형이 대각선에 포함된다.

따라서, 나는 이러한 규칙을 이용하여 정사각형의 오른쪽 위의 좌표가 (1,1)인 정사각형을 시작점으로, 대각선 위에 있는 정사각형들의 개수를 모두 구했고, 전체 정사각형 개수에는 이를 제외하여 최종 결과를 얻었다.

참고 ❗ w < h 인 경우는 규칙이 살짝 달라진다. 그러나, 위에 내용을 이해했다면 충분히 규칙을 찾을 수 있을 것이다. 직접 그려서 규칙을 찾으면 이해가 쉽다!

function solution(width, height) {
    var answer = 1;
    let w = width;
    let h = height;

    if(w < h){ // 규칙 통일을 위해 w < h 인 경우, w > h로 변경 
        w = height;
        h = width;
    }

    const m  = w/h;  // 기울기

    let x=1; // 정사각형 시작 좌표 
    let y=1;

    let count =0; // 대각선 위에 놓여 있는 정사각형 개수 

    while (x !== w || y !== h){
        count++;

        // 현재 정사각형의 위에 있는 정사각형이 대각선 위의 정사각형 
        if(m < x/y){ 
            y++;
            continue;
        }

          // 현재 정사각형의 대각선에 있는 정사각형이 대각선 위의 정사각형 (아래의 x++ 까지 실행함)
        if(m == x/y) y ++;

        x++; // if 문 모두 실행 안되는 경우 - 현재 정사각형의 오른쪽에 있는 정사각형이 대각선 위의 정사각형 
    }

    count ++ ; // 최 우상단에 있는 정사각형 세어주기 
    answer = w*h - count;

    return answer;
}

🎤 느낀 점

야심차게 생각했던 첫번째 아이디어는 무용지물이었다. 처음부터 문제의 조건과 예시를 주의 깊게 살펴보았다면, 허비되는 시간을 줄일 수 있었을 것이다😥

*📌 결론 * : 어떤 문제든 간에 문제를 잘 살펴보도록 하자!

🔥 오류 내용

ERROR in [eslint] Plugin "react" was conflicted between 
"package.json » eslint-config-react-app » C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\eslint-config-react-app\base.js" 
and 
"BaseConfig » C:\choi\SideProjects\oneNth\1-n-Web-Frontend\node_modules\react-scripts\node_modules\eslint-config-react-app\base.js"

리액트를 쓰면서 이런 오류는 처음봤다. yarn start로 프로젝트를 실행시키면 이렇게 오류가 등장하고, package.json을 ctrl+s 로 저장하면 정상 실행되는... 그런 오류였다.

🚿 해결 방법

구글링을 한 결과, casing 문제, 즉, 대소문자 문제라고 하였다. 위의 오류에서 파일 경로가 두개 나와있는데, 잘 보면 첫번째 경로에는 1-n-web-frontend로 되어있고 두번째 경로에는 1-n-Web-Frontend라고 되어있다. 대소문자가 다르다.

이건 윈도우 환경에서 발생하는 문제인데, 이전 버전의 리액트는 대소문자 구분 없이 경로를 찾았지만 업데이트 후 변경된 모양이다.

현재 저장된 형태는 1-n-Web-Frontend이었기 때문에, 이를 1-n-web-frontend 로 변경해주었다.

그래서 이 오류는 해결!✨

두번째 오류

🔥 오류 내용

첫번째 오류를 해결했더니 모든 컴포넌트에 대해 아래와 같은 오류들이 발생하였다.

 Parsing error: require() of ES Module C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\eslint\node_modules\eslint-scope\lib\definition.js 
 from C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\babel-eslint\lib\require-from-eslint.js not supported.

Instead change the require of definition.js in 
C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\babel-eslint\lib\require-from-eslint.js 
to a dynamic import() which is available in all CommonJS modules

역시 구글링...

🚿 해결 방법

이 오류의 원인은 deprecated된 babel-eslint를 사용하려했기 때문이었다. 현재 babel-eslint는 @babel/eslint-parser로 옮겨졌다.

따라서, package.json 파일의

babel-eslint": "^10.0.2

부분을,

@babel/eslint-parser": "^7.5.4"

로 수정해주었다.

그 후, 터미널에서 yarn install을 실행하였다. (npm의 경우 npm i)

그후 다시 yarn start로 프로젝트를 실행해보았더니, 컴포넌트마다 발생했던 오류는 모두 사라지고 아래와 같은 오류가 등장했다.

[eslint] Failed to load parser 'babel-eslint' declared in 
'package.json » eslint-config-react-app » C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\eslint-config-react-app\base.js': 
Cannot find module 'babel-eslint'
Require stack:
- C:\choi\SideProjects\oneNth\1-n-web-frontend\node_modules\eslint-config-react-app\base.js

오류 내용을 보면 현재 node_modules\eslint-config-react-app\base.js 에서 babel-eslint를 못찾고 있다는 것을 알 수 있다.

우리는 babel-eslint를 쓸 것이 아니기 때문에, node_modules\eslint-config-react-app\base.js 파일을 열어서

parser: 'babel-eslint',

라고 적혀있는 부분을,

 parser: "@babel/eslint-parser",

로 변경해주었다.

느낀 점

구글링으로 해결할 수 있는 문제라서 정말 다행이었다...ㅎㅎ 프로젝트 설정 관련해서도 신경쓸게 꽤 있다는 것을 다시금 체감한 하루였다 😛

출처🔖

• 첫번째 오류 해결 방법 : stackOverFlow
• 두번째 오류 해결방법 : stackOverFlow

💻출처 : 프로그래머스 > 코딩 테스트 > 위클리 챌린지 🏆난이도 : Level 2

📜문제

요약

게임에는 여러 던전이 있다. 던전을 플레이하기 위해서는, 플레이어의 피로도가 던전에 할당된 최소 피로도 이상이어야 한다. 플레이어가 던전을 플레이한 이후, 플레이어의 피로도는 던전의 소모 피로도만큼 감소한다. 사용자가 탐험할 수 있는 던전의 최대 개수를 출력하라.

🔑 풀이

사용자가 어떤 순서로 던전을 탐험하느냐에 따라 탐험할 수 있는 최대 던전의 수가 달라진다. 예시를 살펴보았을 때, 던전의 최소 피로도와 소모 피로도에 따른 탐색 순서에는 특별한 규칙이 없어보인다. 따라서, 가능한 던전의 모든 배열 순서(순열)를 탐색하여 사용자가 탐험할 수 있는 최대 던전의 수를 구하였다.

던전들의 모든 배열 순서는 DFS를 응용하여 구현하였다.

💻 코드

function solution(k, dungeons) {
    let max=0;
    const visited = Array(dungeons.length).fill(false)

    function dfs(count,k){
        max = max < count ? count : max;
        for(let i=0;i < dungeons.length;i++){
            if(visited[i])
                continue;

            let curDungeon= dungeons[i]
            if(curDungeon[0]<=k){
                visited[i]=true;
                dfs(count+1, k-curDungeon[1])
                visited[i]=false;
            }
        }

    }

    dfs(0,k)
    return max;
}

🎤 느낀 점

간단한 코드지만 오랜만에 DFS를 구현하였더니 좀 막막한 구석이 있었다. 문제를 꾸준히 풀어 이런 낯섦을 빨리 없애야 겠다😥