먼저 토스팀에 먼저 합류하시고, 합격/이직 수기를 공유 해주신 분들에게 감사의 인사를 전한다. 글쓴이의 합격에 크게 기여했다. 이 글 또한 미래의 지원자들에게 도움이 될지는 모르겠지만, 최종합격 까지 과정에 대한 기억이 휘발되기 전에 글을 써본다.

서류제출

창밖으로 비가 추적추적 내린다. 열심히 정리한 이력서와 급하게 써내려간 포트폴리오 파일을 몇번이고 다시 확인했다. 토스로의 첫 지원이다. 기회를 낭비하기는 싫었다. 고민하고 고민하다 보니 서류제출 마감일. 하필 마감일이 낀 주말에 부모님을 뵈러 고향에 내려갔다.

포트폴리오가 문제였다. 어떤 내용을 포함할지 몇번이고 바꿨지만 도통 마음에 들지 않았다. 여러번 고쳐쓰다보니 마음은 더 급해졌다. 마지막으로 모집요강의 내용을 다시 확인하고, 불필요하다고 생각되는 정보를 모조리 쳐냈다. 이쁘게 꾸미고 싶은 욕구와 줄글을 쓰고 싶은 욕구를 참아냈다.

결국 서울로 올라오는 버스 안에서 제출하기 버튼을 눌렀다.

사전과제

서류가 통과 되었다. 이틀만에 유선으로 합격 연락이 온다음, 이메일로 사전과제 관련 안내가 날라왔다. 이때부터 토스팀의 빠른 일처리가 느껴졌다. 알 수 없는 오기로, 나도 최대한 빠르게 과정에 임하고 싶은 욕구에 타올랐다. 오는 일요일에 바로 과제를 진행해서 제출하겠다고 했다.

아뿔사, 그주 주말에 친구들과 양양에 가기로 약속이 잡혀있었고, 금요일 연차도 사용한 상태였다. 막무가내로 양양에 랩탑을 들고 내려갔다. 친구들은 이해해주는 한편 이상하게 쳐다봤다. 서핑샵에 붙어있는 카페에서 예상 문제를 상상하면서 코드를 끄적거렸다.

두가지 목표를 설정했다. 첫째, 토스팀에 합류하면 빠르게 적응 할 수 있다는 점을 코드로 어필 하기. 둘째, 같이 일하기 편해보이는 코드를 작성하기.

예전에 봤던 slash 컨퍼런스의 프론트엔드 발표 영상을 복기하고, slash 라이브러리의 코드들을 훑어 보았다. 토스뱅크의 프론트엔드 챕터에서 사용하고 있는 기술스택을 어떻게 과제에 녹여낼지 고민했다. 특히 emotion은 제대로 사용 해본적이 없어서 best practice 위주로 documentation을 속독했다.

휴가가 끝나고 서울로 돌아왔다. 일요일 점심이 다가왔고 과제의 상세 안내 사항을 안내 받았다. 주어진 시간은 8h. 요구조건들을 보자마자 만만치 않겠다 생각이 들었다. 어느 순서로 작업을 진행할지 결정하고, 1시간의 버퍼를 설정한 뒤 요구조건 별로 시간을 어떻게 배분 할지 결정했다.

버퍼를 설정한게 천만 다행이었다. 시간배분 실패로 마지막 일분 일초까지 사용했다. 시간 부족으로 넘어간 부분에는 주석으로 문제점과 개선 방향성을 남겼다. 나름 만족스러운 결과물을 제출했다.

직무 인터뷰

떨어졌구나, 생각이 들때 쯤에 과제전형 합격 연락이 왔다. 어찌나 기쁘던지!

직무 인터뷰는 제출한 사전과제 결과물과 이력서를 기반으로 진행한다고 안내를 받았다. 제출한 과제를 톺아보았다. 예상 질문 리스트를 만들고, 과제를 리팩토링하는 라이브 코딩을 연습했다. 이력서의 경우 항목별로 꼬리질문을 2 depths로 준비했다.

면접이 시작됬다. 다행히 내가 어필하고 싶은 부분을 콕찝어서 질문 해주셔서 마음껏 내생각을 전달 할 수 있었다. 답을 모르거나, 면접관의 의도를 잘못 파악해서 엉뚱한 대답을 몇번 했다. 그때마다 선문답을 하듯이 정답을 향해 대화를 이끌어 주셨다.

면접과정에서 내가 제대로 활용하고 있지 않았던 react-query의 기능과, compound component pattern의 장단점에 대해 알게되었다. 다음날 출근해서 새로 배운것을 바로 사용하는 방식으로 프로젝트의 코드를 리팩토링 했다. 기분이 아주 좋았다.

문화 인터뷰

다음주에 직무 인터뷰 합격 연락이 왔고, 문화 인터뷰 일정이 잡혔다.

우선 채용담당자님이 보내주신 토스커뮤니티 더 알아보기 자료들을 살펴봤다. <유난한 도전>도 구매 해서 읽기 시작했다. 마지막으로 이력서를 살펴보면서 나의 경험을 기반으로, 내가 어떻게 토스팀에서 시너지를 낼 수 있을지 정리했다.

면접이 시작되었다. 매우 직설적인 질문들을 받았다. 나도 최대한 핵심만 전달하기 위해 노력했다. 미처 생각치도 못한 질문들도 다수 받았다. 그때마다 잠시 생각을 해보겠다 한뒤, 생각이 정리되면 솔직하게 대답을 드렸다.

인터뷰가 끝나고, 저녁을 때우면서 집으로 돌아갔다. 집으로 돌아가는 길에 바로 내가 말한 내용들을 복기했다. 다소 횡설수설 했지만, 정합성이 있는 대답을 드렸다는 생각이 들었다.

결과

문화 인터뷰도 합격이었다. 만만세. 레퍼런스 체크와 처우 협의는 과정은 무탈하게 진행 되었다. 온보딩이 기대된다.

제목: 메모리가 누수되나요? 날짜: 1995/03/31

Norman H. Cohen (nco...@watson.ibm.com)가 썼습니다. : 고의적으로 메모리 누수가 있는 프로그램은 실행 시간이 충분히 짧고, : 타겟 머신의 가상 메모리 공간이 충분하여 메모리 부족이 걱정되지 않는 경우로 : 한정 됩니다. (이러한 프로그램에는 많은 학생 프로그래밍 연습 문제와 : 몇몇 간단한 애플릿과 유틸리티가 포함됩니다; 내장형 또는 안전 중심의 프로그램은 : 거의 없거나 전혀 해당하지 않습니다.)

위글은 제가 가진 흥미로운 기억 중 하나를 상기 시켰습니다. 한때 저는, 미사일을 위한 온보드 소프트웨어를 제작하고 있는 고객과 일하고 있었습니다. 코드 분석 중에 저장소 누수와 관련된 여러 문제점을 지적했습니다. 고객의 최고 소프트웨어 엔지니어가 "물론 누수되죠"라고 말했을 때 제가 얼마나 놀랐는지요. 그는 미사일의 전체 가능 비행 시간 동안 애플리케이션이 누출할 메모리의 양을 계산하고, 그 숫자를 두 배로 늘렸다고 설명했습니다. 그들은 이만큼의 추가 메모리를 하드웨어에 추가하여 누수를 "지원"했습니다. 미사일이 목표물에 부딪히거나 비행이 끝날 때 폭발하기 때문에, 프로그래머의 개입 없이도 궁극의 가비지 컬렉션이 수행되는 것입니다.

-- Kent Mitchell | 일이 계획대로 진행되지 않는 기술 컨설턴트 | 이유 일 수 있는 것 중 하나는 ..... Rational Software Corporation | 애초에 계획이 없었기 때문입니다!

원문

From: k...@rational.com (Kent Mitchell) Subject: Re: Does memory leak? Date: 1995/03/31

Norman H. Cohen (nco...@watson.ibm.com) wrote: : The only programs I know of with deliberate memory leaks are those whose : executions are short enough, and whose target machines have enough : virtual memory space, that running out of memory is not a concern. : (This class of programs includes many student programming exercises and : some simple applets and utilities; it includes few if any embedded or : safety-critical programs.)

This sparked an interesting memory for me. I was once working with a customer who was producing on-board software for a missile. In my analysis of the code, I pointed out that they had a number of problems with storage leaks. Imagine my surprise when the customers chief software engineer said "Of course it leaks". He went on to point out that they had calculated the amount of memory the application would leak in the total possible flight time for the missile and then doubled that number. They added this much additional memory to the hardware to "support" the leaks. Since the missile will explode when it hits its target or at the end of its flight, the ultimate in garbage collection is performed without programmer intervention.

-- Kent Mitchell | One possible reason that things aren't Technical Consultant | going according to plan is ..... Rational Software Corporation | that there never was a plan!

3월 16일 부로 기존의 reactjs.org가 사라지고 새로운 react.dev 사이트가 오픈 되었다. 여전 부터 beta 상태로 최신 다큐멘테이션을 읽어 볼 수 있었지만, 이제 기존 다큐멘테이션은 완전히 레거시로 넘어가게 되었다. 모던한 React 개발을 매우 친절하게 설명하고 있기에, FE 개발자라면 한번 톺아보는 것을 추천한다. 이 게시글에서 글쓴이 기준으로 React에 대해 어느정도 알고 있는 개발자도 리마인드 하거나 새로 익히면 좋을 정보들만 정리 했다.

다큐멘테이션 웹사이트에서 FE 트렌드가 보인다

Next.js & Tailwind의 채택

wappalyzer라는 툴로 확인 해본 결과 새로 작성된 React 다큐멘테이션은 Next.js로 만들어 졌고, 배포 환경에는 Vercel이 사용되었다. 메타 프레임워크, 서버리스(엣지) 환경 트렌드가 떠올려진다.

또한 살펴볼점은 Tailwind CSS의 채택이다. Tailwind CSS는 Utility-first CSS 프레임워크의 대표 주자이다. SSR의 가장 중요한 목표중의 하나는 성능이다. 이에 CSS-in-JS의 런타임 오버헤드를 피할 수 있는 Tailwind CSS 또한 최근 채택이 증가되고 있다.

글쓴이가 말한 내용이 흥미롭다면, 다음 아티클들을 추가로 읽어보는 것을 추천한다. 10 Web Development Trends in 2023 Why We're Breaking Up with CSS-in-JS

CRA는 공사진행 중

공식문서에서 create-react-app에 대한 추천이 사라졌다. 이제 새로운 프로젝트를 시작하는 경우 Next.js, Remix.js 등 React 기반 메타 프레임 워크를 추천하고, React를 라이브러리로 사용하려는 경우 Vite를 번들러로 추천한다. React Core팀은 create-react-app라는 커맨드는 유지하되, 프레임워크를 추천 해주는 launcher로 수정하는 방향을 잡았다고 한다. 궁금하다면 Dan Abramov의 설명을 읽어보자.

"Quick Start" 섹션을 먼저 살펴보자

Function Component First!

기존의 React 튜토리얼은 틱택토 게임을 Class Component로 작성했다. Function Component 또한 사용했지만, 상태를 가지고 있지 않은 소위 Dumb(Presentational) Component로 사용되었다. hooks API가 존재하기 전 Presentational and Container Component Pattern의 잔재 였으리라. 업데이트 된 튜토리얼에서는 Function Component와 useState가 사용된다.

"Thinking in React"가 강조 되었다!

Thinking in React라는 파트가 Quick Start 섹션으로 이동 되었다. 디자인 목업과 JSON API가 정의 되어있다고 가정하고, React를 사용하는 개발자가 작업하는 프로레스를 권장/설명 해주는 섹션이다.

1. UI를 컴포넌트 계층 만들기

UI 목업을 보고, 필요한 컴포넌트와 하위 컴포넌트를 정의한다. 이상적으로 단일 책임 원칙에 따라 하나의 컴포넌트를 분해하여 여러개의 하위 컴포넌트로 이루어진 계층을 만든다.

2. React로 정적인 버전 만들기

유저 상호작용을 생각하지 않고, UI의 마크업을 진행한다. 이때 재사용 가능한 컴포넌트를 실제로 작성한다. 컴포넌트를 정의하면서 화면을 그리는데 필요한 prop 또한 정의한다. 간단한 컴포넌트 계층의 경우 top down으로 복잡한 계층의 경우 down up으로 작업하는 것이 추천된다.

3. UI 상태의 최소이지만 완전한 표현 찾기

상호작용을 구현하기 위한 state를 정의한다. 가장 중요한 점은 DRY 원칙에 따라 최소한의 state만 선언하는 것이다. 다른 state나 prop으로 부터 파생된 값은 render시 on-demand로 계산한다.

4. state가 어디에 위치 해야할지 결정하기

어느 컴포넌트에 어떤 state를 둘지 결정한다. 다음과 일반적으로 같은 과정을 통해 결정한다.

1. 특정 State에 따라 re-render 되어야하는 컴포넌트를 모두 찾는다.
2. 해당 컴포넌트들로 부터 가장 가까운 부모 컴포넌트에 state를 정의 한다.
3. State를 두는 것이 자연스러운 컴포넌트가 존재하지 않는다면 새로운 컴포넌트를 정의한다.

5. 역방향 데이터 흐름 추가하기

import { useState } from 'react';

function FilterableProductTable({ products }) {
  const [filterText, setFilterText] = useState('');
  const [inStockOnly, setInStockOnly] = useState(false);

  return (
    <div>
      <SearchBar 
        filterText={filterText} 
        inStockOnly={inStockOnly} 
        onFilterTextChange={setFilterText} 
        onInStockOnlyChange={setInStockOnly} />
      <ProductTable 
        products={products} 
        filterText={filterText}
        inStockOnly={inStockOnly} />
    </div>
  );
}

React에서 데이터 흐름은 단방향이다. 필요에 따라 부모의 state를 변경 시키는 setState 함수를 자식 컴포넌트에게 전달한다.

"Learn React" 섹션이 새로 생겼다!

Main Concepts 섹션이 Learn React 섹션으로 변경 되었다. 가장 많은 변화가 생긴 섹션이다. 유저편의를 위해 샘플 코드가 codesandbox에 연동되었고, 이해를 돕기 위한 비유와 일러스트레이션이 추가되었다.

특수한 상황이 아니면 이제 권장되지 않는 High-Order Component, PropTypes에 대한 설명이 삭제 되었다.

4가지 파트로 나누어져있는데 기존 다큐멘테이션에 비해서 매우 유기적으로 설명을 진행한다.

Describing the UI : jsx, property, list/conditional rendering Adding Interactivity : event, state, render & commit Managing State : declarative UI, state structure, context & reducer Escape Hatches : ref, effect, custom hooks

Escape Hatches에서 다루는 주제는 고급 개념이다. useEffect 잘 쓰기 위해서 가장 중요한 규칙은, 최대한 useEffect의 사용을 피하는 것이라는 말도 있는데 다큐멘테이션도 이를 알려주려한다. 또한 useRef에 대한 자세한 설명과 DOM Manipulation으로 분리 되었다.

Pure Function & Strict Mode

let guest = 0;

function Cup() {
  // Bad: changing a preexisting variable!
  guest = guest + 1;
  return <h2>Tea cup for guest #{guest}</h2>;
}

함수가 컴포넌트를 작성하는 기본 방법으로 권장되면서, 순수함수와 컴포넌트가 순수함수이여야 하는 이유에 대한 설명이 추가되었다. 컴포넌트가 순수하지 않으면 render 될때마다 부수효과를 야기 하기 때문이다. 이를 반쯤 강제하기 위한 StrictMode가 존재하긴 했지만 이제 다큐멘테이션에서 순수하지 않은 컴포넌트의 위험성을 자세히 설명 해준다.

필요하면 Immer를 사용하자

// useState
const [person, setPerson] = useState({
  name: 'Niki de Saint Phalle',
    artwork: {
      title: 'Blue Nana',
      city: 'Hamburg',
      image: 'https://i.imgur.com/Sd1AgUOm.jpg',
    }
});

function handleTitleChange(e) {
  setPerson({
    ...person,
    artwork: {
      ...person.artwork,
      title: e.target.value
    }
  });
}

// useImmer
const [person, updatePerson] = useImmer({
    name: 'Niki de Saint Phalle',
    artwork: {
      title: 'Blue Nana',
      city: 'Hamburg',
      image: 'https://i.imgur.com/Sd1AgUOm.jpg',
    }
  });

function handleTitleChange(e) {
  updatePerson(draft => {
    draft.artwork.title = e.target.value;
  });
}

필요하면 Immer를 사용하자. 일일히 spread 하지 않고 state의 불변성을 지킬 수 있게 도와준다.

Batching state Update

function App() {
  const [count, setCount] = useState(0);
  const [flag, setFlag] = useState(false);

  function handleClick() {
    fetchSomething().then(() => {
      // React 17 and earlier does NOT batch these because
      // they run *after* the event in a callback, not *during* it
      setCount(c => c + 1); // Causes a re-render
      setFlag(f => !f); // Causes a re-render
    });
  }

  return (
    <div>
      <button onClick={handleClick}>Next</button>
      <h1 style={{ color: flag ? "blue" : "black" }}>{count}</h1>
    </div>
  );
}

setState에 함수를 인자로 전달하면, state 업데이트가 batching 된다. React v18의 업데이트로 eventHandler 밖에서도 batching이 기본으로 적용된다.

state를 설계하는 규칙

관계가 있는 state는 묶어라

// 비추천
const [x, setX] = useState(0)
const [y, setY] = useState(0)

// 추천
const [position, setPosition] = useState({position})

모순된 state를 피해라

// 비추천
const [isSending, setIsSending] = useState(false);
const [isSent, setIsSent] = useState(false);

async function handleSubmit(e) {
  e.preventDefault();
  setIsSending(true);
  await sendMessage(text);
  setIsSending(false);
  setIsSent(true);
}

// 추천
const [status, setStatus] = useState('typing');

async function handleSubmit(e) {
  e.preventDefault();
  setStatus('sending');
  await sendMessage(text);
  setStatus('sent');
}

불필요한 state를 피해라

// 비추천
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');
const [fullName, setFullName] = useState('');

//추천
const [firstName, setFirstName] = useState('');
const [lastName, setLastName] = useState('');

const fullName = firstName + ' ' + lastName;

state 복사를 피해라

// color가 업데이트 되지 않는다
import { useState } from 'react';

export default function Clock(props) {
  const [color, setColor] = useState(props.color);
  return (
    <h1 style={{ color: color }}>
      {props.time}
    </h1>
  );
}

// 가능하면 state 복사를 피해라
export default function Clock({color, time}) {
  return (
    <h1 style={{ color }}>
      {time}
    </h1>
  );
}

깊게 nesting 된 state를 피해라

// 비추천
export const initialTravelPlan = {
  id: 0,
  title: '(Root)',
  childPlaces: [{
    id: 1,
    title: 'Earth',
    childPlaces: [{
      id: 2,
      title: 'Africa',
      childPlaces: [{
        id: 3,
        title: 'Botswana',
        childPlaces: []
      }, {
        id: 4,
        title: 'Egypt',
        childPlaces: []
      }, ...                 

// 추천
export const initialTravelPlan = {
  0: {
    id: 0,
    title: '(Root)',
    childIds: [1, 43, 47],
  },
  1: {
    id: 1,
    title: 'Earth',
    childIds: [2, 10, 19, 27, 35]
  },
  2: {
    id: 2,
    title: 'Africa',
    childIds: [3, 4, 5, 6 , 7, 8, 9]
  }, ...

useEffect 사용이 필요한 경우들

non-React widget를 제어 할때

useEffect(() => {
  const map = mapRef.current;
  map.setZoomLevel(zoomLevel);
}, [zoomLevel]);

event에 구독 할때

useEffect(() => {
  function handleScroll(e) {
    console.log(window.scrollX, window.scrollY);
  }
  window.addEventListener('scroll', handleScroll);
  return () => window.removeEventListener('scroll', handleScroll);
}, []);

애니메이션을 트리거 할때

useEffect(() => {
  const node = ref.current;
  node.style.opacity = 1; // Trigger the animation
  return () => {
    node.style.opacity = 0; // Reset to the initial value
  };
}, []);

분석 정보를 로깅할 때

useEffect(() => {
  logVisit(url); // Sends a POST request
}, [url]);

useEffect 사용이 불필요한 경우들

Prop의 변경으로 state를 일괄 초기화 할때

export default function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  // 🔴 Avoid: Resetting state on prop change in an Effect
  useEffect(() => {
    setComment('');
  }, [userId]);
  // ...
}

export default function ProfilePage({ userId }) {
  return (
    <Profile
      userId={userId}
      key={userId}
    />
  );
}

function Profile({ userId }) {
  // ✅ This and any other state below will reset on key change automatically
  const [comment, setComment] = useState('');
  // ...
}

Post requst 전송

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic should run because the component was displayed
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  // 🔴 Avoid: Event-specific logic inside an Effect
  const [jsonToSubmit, setJsonToSubmit] = useState(null);
  useEffect(() => {
    if (jsonToSubmit !== null) {
      post('/api/register', jsonToSubmit);
    }
  }, [jsonToSubmit]);

  function handleSubmit(e) {
    e.preventDefault();
    setJsonToSubmit({ firstName, lastName });
  }
  // ...
}

function Form() {
  const [firstName, setFirstName] = useState('');
  const [lastName, setLastName] = useState('');

  // ✅ Good: This logic runs because the component was displayed
  useEffect(() => {
    post('/analytics/event', { eventName: 'visit_form' });
  }, []);

  function handleSubmit(e) {
    e.preventDefault();
    // ✅ Good: Event-specific logic is in the event handler
    post('/api/register', { firstName, lastName });
  }
  // ...
}

Data Fetching

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);

  useEffect(() => {
    // 🔴 Avoid: Fetching without cleanup logic
    fetchResults(query, page).then(json => {
      setResults(json);
    });
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

function SearchResults({ query }) {
  const [results, setResults] = useState([]);
  const [page, setPage] = useState(1);
  useEffect(() => {
    let ignore = false; // ! avoid race condition
    fetchResults(query, page).then(json => {
      if (!ignore) {
        setResults(json);
      }
    });
    return () => {
      ignore = true;
    };
  }, [query, page]);

  function handleNextPageClick() {
    setPage(page + 1);
  }
  // ...
}

외부 저장소에 구독

function useOnlineStatus() {
  // Not ideal: Manual store subscription in an Effect
  const [isOnline, setIsOnline] = useState(true);
  useEffect(() => {
    function updateState() {
      setIsOnline(navigator.onLine);
    }

    updateState();

    window.addEventListener('online', updateState);
    window.addEventListener('offline', updateState);
    return () => {
      window.removeEventListener('online', updateState);
      window.removeEventListener('offline', updateState);
    };
  }, []);
  return isOnline;
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

function subscribe(callback) {
  window.addEventListener('online', callback);
  window.addEventListener('offline', callback);
  return () => {
    window.removeEventListener('online', callback);
    window.removeEventListener('offline', callback);
  };
}

function useOnlineStatus() {
  // ✅ Good: Subscribing to an external store with a built-in Hook
  return useSyncExternalStore(
    subscribe, // React won't resubscribe for as long as you pass the same function
    () => navigator.onLine, // How to get the value on the client
    () => true // How to get the value on the server
  );
}

function ChatIndicator() {
  const isOnline = useOnlineStatus();
  // ...
}

우리는 페이지를 디자인 하는 것이 아니라, 컴포넌트로 이루어진 시스템을 디자인한다. Stephen Hay

&nbsp 웹디자인이라는 기술이 진화함에따라, 단순한 웹페이지의 집합이 아니라, 제대로 정의된 디자인 시스템 개발의 필요가 대두 되고있다.

&nbsp 디자인 시스템을 만드는 것에 대해서는 많은 논의가 이루어졌다. 이 논의의 대부분은 색상, 타이포그래피, 그리드, 텍스처 등을 확립하는데 집중한다. 이러한 생각도 매우 중요하다, 하지만 나는 앞서 언급한 요소에 대한 흥미가 상대적으로 적다. 앞서 언급한 요소는 주관적이고 앞으로도 주관적일 것이기 때문이다. 최근, 나는 우리가 사용하는 인터페이스가 어떻게 구성되어있고, 디자인 시스템을 질서있게 만들 방법에 대해 관심을 가지고 있다.

&nbsp 나는 적합한 비유를 위해 화학을 사용한다. 고체, 액체, 기체, 등 모든 물체는 원자(atom)으로 이루어져있다. 이러한 원자가 모여 분자(molecule)가 된다. 분자는 모여 유기체(organism)이 되고 결국 우주의 모든 물질을 구성한다.

&nbsp 이와 유사하게, 우리가 만든 인터페이스는 하위 컴포넌트들로 이루어져있다. 인터페이스를 기초적인 구성 요소로 해체하여 거기서 부터 작업할 수 있다는 것을 의미한다. 이것이 아토믹 디자인(atomic design)의 요점이다.

아토믹 디자인이란 무엇인가?

아토믹 디자인이란 디자인 시스템을 만드는 방법론이다. 아토믹 디자인에는 다섯가지 수준이 존재한다.

1. Atoms
2. Molecules
3. Organisms
4. Templates
5. Pages

atoms

&nbsp atom는 물질의 기본 구성요소(basic building block) 이다. 웹 인터페이스에 이를 적용하면, atom이란 label, input, button 같은 HTML 태그라 할 수 있다.

&nbsp 또한 atom은 색상 팔레트, 폰트 같은 추상적인 요소일 수 있고, 애니메이션 같은 인터페이스의 양상일 수도 있다.

&nbsp 현실과 같이 atom은 추상적이고, 독립적으론 크게 유용하지 않다. 하지만 패턴 라이브러라는 문맥에서 본다면, 글로벌한 스타일을 한번에 볼 수 있게 해주는 레퍼런스로써 훌륭하다.

molecules

&nbsp atom을 조합하기 시작하면 일이 훨씬 흥미롭고 명백 해지기 시작한다. molecule은 접합 된 atom의 모음이고 화합물의 주요한 단위이다. molecule은 각자의 속성을 지니고 디자인 시스템의 뼈대로 쓰인다.

&nbsp 예를 들어, form label, input, button의 따로따로 크게 유용하지 않다. 하지만 3개를 form으로 합친다면 실제로 기능을 담당할 수 있다.

&nbsp atom으로 부터 molecule를 만드는 것은 "하나의 일을 하고 그 일을 제대로 해라"라는 모토를 장려한다. molecule은 복잡 할수도 있지만, 투박한 정의를 하자면 다음과 같다. molecule이란 재사용을 위해 만들어진, 상대적으로 심플한 atom의 조합이다.

organisms

&nbsp molecule은 우리가 작업할 수있는 기본 구성요소이다. 이제 우리는 molecule을 조합하여 organism을 만들 수 있다. organism은 상대적으로 복잡하며, 웹 인터페이스의 분명한 구역을 담당한다.

&nbsp 우리는 점점 더 구체적인 부분을 다루고 있다. 클라이언트는 디자인 시스템의 atom에 대해 흥미가 없을 수 있다. 하지만 organism을 다루기 시작하면 최종적인 웹 인터페이스의 형태가 잡히는 것을 볼 수 있다. 내가 협업하고 있는 Dan Mall은 element collage를 사용한다. element collage는 주요한 organism의 아이디어를 명료하게 표현하여 클라이언트와의 의사소통을 용이하게 하고 디자인의 방향성을 미리 정할 수 있게 해준다.

&nbsp organism은 유사하거나 상이한 molecule로 구성 될 수 있다. 예를 들어, masthead(페이지 헤더) organism은 logo, primary navigation, search form 등 상이한 molecule로 이루어 질 수 있다. 반면 product grid(상품 리스트) organism은 동일한 molecule의 반복으로 이루어질 수 있다.

&nbsp molecule로 organism을 만드는 것은 독립적이고 재사용 가능한 컴포넌트를 작성을 장려한다.

templates

&nbsp template의 레벨에서 화학을 통한 비유가 끝나고, 클라이언트가 이해하기 쉽고 실제 결과 물과 밀접한 언어가 사용된다. template은 oragnism을 묶어 만들어 놓은 페이지이다. 여기서 우리는 디자인이 완성되고 레이아웃의 실체를 볼 수 있게 된다.

&nbsp template은 매우 구체적이며 상대적으로 추상적인 molecule과 organism에게 문맥을 제공한다. 또한 클라이언트는 template을 통해 디자인의 완성을 보기 시작한다. 나는 아토믹 디자인이라는 방법론을 사용하면서, template은 HTML 와이어 프레임으로 시작하여 최종적으로 정확도(fidelity) 증가하며 최종 결과물이 된다. Pittsburgh의 Bearded Studio는 유사한 방법을 사용한다. 디자인은 흑백톤의 레이아웃리스로 시작하여 최종 디자인으로 발전한다.

pages

&nbsp page는 template의 특정한 인스턴스이다. 플레스홀더는 실제 콘텐츠로 대체되며, 최종적으로 유저가 보게 될 화면이 묘사 된다.

&nbsp page는 가장 구체적이기 때문에 가장 정확도가(fidelity) 높은 레벨이다. 일반적으로 대다수의 유저가 사용하고, 많은 리뷰의 대상이다.

&nbsp page는 디자인 시스템의 효율성을 테스트하는 곳이다. 실제 문맥(웹페이지)에서 molecule, organism, template이 필요한 일을 하는지 확인 후, 컴포넌트를 리팩토링 할 수 있다는 것이다.

&nbsp 또한 page는 template의 여러가지 사례를 테스트 할 수 있는 곳이다. 예를 들어 헤드라인은 40자가 될 수 있고, 340자가 될 수도 있다. 장바구니에 상품이 하나가 있을 수 있고, 상품이 10개 있을 수도 있다. 할인 코드가 적용된 상태일 수 있고, 아닐 수도 있다. 거듭이 말하자면, 이러한 실제 사례는 어떻게 디자인 시스템을 만들지에 영향을 미친다.

왜 아토믹 디자인을 사용하나

&nbsp 여러가지 의미로, 우리는 앞서 언급한 방법들을 사용하고 있었다. 무의식적으로 했던 의식적으로 했던간에 말이다.

&nbsp 아토믹 디자인은 디자인 시스템을 만들기 위한 명확한 방법론을 제공한다. 클라이언트와 팀 멤버들 또한 디자인 시스템을 눈앞에서 보는 것을 통해 디자인 시스템의 개념과 중요함을 제대로 인지 할 수 있다.

&nbsp 아토믹 디자인은 추상적인 개념과 구체적인 개념을 모두 들여다볼수 있게 해준다. 이 덕분에 우리는 일관적이고 확장 가능한 디자인 시스템을 만듦과 동시에 최종 결과물을 동시에 보여줄 수 있다. 또한 해체(deconstructing)으로 부터 시작하는 것이 아니라 조립(assembling)의 방법을 사용하기 때문에, 뒤늦게 패턴을 선택하는 것이 아니라, 시작 부터 디자인 시스템 설계를 시작 할 수 있다.

원문 : atomic-web-design *가독성을 위해 의역한 부분이 존재합니다.

📚누구를 위한 포스트인가?

1. 변수, 함수, 객체 등 프로그래밍에 대한 기초 지식이 있는 사람
2. 파이썬을 사용 해본적 있지만 자세히 모르는 사람
3. 흥미 위주로 파이썬에 대해 읽을 거리가 필요한 사람

&nbsp 본 포스팅은 프로그래밍에 대한 기본 개념이 있는 아는 사람이, 파이썬을 사용하면서/사용하기전 미리 알고 있으면 좋을 개념들을 간략하게 정리하기 위해 작성 되었습니다. 모든 부분을 상세히 설명하는 것보다, 새로운 개념을 소개하고 읽을 거리를 추천하는 형식으로 작성했습니다.

🚧 작업중인 포스트 입니다

&nbsp 내용이 수정되거나 추가 될 수 있습니다 :)

1. 빅픽처

🙆‍♂️ 파이썬은 객체지향 언어이다

&nbsp 파이썬이 프로그래밍을 처음 접하는 사람에게 추천 되어서 망각되는 부분이다. 파이썬은 명령적 성격을 지닌 객체지향 언어이다. 파이썬에서 모든 것은 객체이다.

잠시만요~ 파이썬에는 클로저도 있고, 고차함수도 있고, 익명함수도 있고 함수지향 적인 부분이 많지 않나요?

&nbsp 맞는 말이다. 파이썬의 함수는 일급함수이다. 파이썬을 사용하면서 순수함수를 사용하고 선언적으로 프로그래밍 할 수 있다. 파이썬의 기능이 확장 되면서 lambda, map, filter 같은 함수지향 파라다임에 영향을 받은 기능이 추가 되었다. 하지만 파이썬 개발자들은 list comprehension을 선호하고 귀도 반 로섬도 파이썬을 함수지향 언어로 보지 않았다고 한다.

읽을 거리

Origins of Python's "Functional" Features Functional Programming in Python

🤔 파이썬은 컴파일 절차를 거치고 인터프리트 된다

파이썬은 인터프리터 언어로 한줄 읽어지면서 실행 되요~

&nbsp 맞는말이다. 그런데 의문이 들지 않는가? 파이썬 코드를 작성 해놓으면 윈도우에서도 동작하고 맥에서도 동작하고 리눅스에서도 동작한다. 어떻게 그런 걸까. Java의 "Write once, run anywhere(WORA)"이 생각이 난다면 정답이다. JVM 처럼 PVM이 존재한다. 무슨 말인지 모르겠다고요? 최대한 간략하게 설명을 해보겠다.

&nbsp 우리는 .py 확장자로 파이썬 소스코드를 작성한다. 이 코드는 컴퓨터에 의해서 바로 실행 되지 않고 바이트코드라는 플랫폼 독립적인 저차원 코드로 컴파일 된다. 이 바이트코드는 Python Virtual Machine(PVM)이라는 플랫폼 종속적인 프로그램에 의해 실행 된다.

&nbsp 파이썬의 컴파일과 실행을 담당하는 대표적인 프로그램이 Cpython이다. Cpython은 이름 그대로 C언어로 구현되어 있다. Cpython 이외에 Jpython, pypy 같은 임플리멘테이션이 있다.

읽을 거리

Understaing Python Bytecode How Does Python Work

🌪️ 파이썬 3.4 부터 공식적으로 비동기 프로그래밍이 지원 된다

&nbsp 자바스크립트 개발자에게 특히 유의미한 부분일 수 있다. 파이썬 버전 2 까지는 언어 레벨에서 비동기 프로그래밍을 지원하지 않았다. Twisted 같은 이벤트 기반 엔진이나 Tornado 같은 비동기 웹프레임 워크가 존재하긴 했다. 하지만 버전 3.4 부터 asyncio라는 공식 라이브러리가 추가 되었고, async await 문법을 통해서 비동기 프로그램을 할수 있게 되었다.

asyncio는 상대적으로 새로운 파이썬 모듈이다. 파이썬 버전 마다 api가 자주 바뀌고 이미 deprecated 된 부분도 존재하니, 기왕이면 공식문서를 참고 하자

읽을 거리

Asyncio Python Asyncio Docs

2. 디테일

🔍 스코프를 구현하기 위한 네임스페이스

&nbsp 파이썬의 globals()나 locals() 키워드가 무엇인지 궁금하지 않았는가? 해당 키워드는 파이썬의 특정 네임스페이스를 접근하기 위해서 사용된다. 파이썬에서 네임스페이스는 스코프를 구현하기 위한 구현 방법이다. 네임스페이스는 파이썬의 자료형의 하나인 dictionary로 구현 되어있다. 파이썬의 네임스페이스에는 네가지 종류가 있다.

1. Built-In
2. Global
3. Enclosing
4. Local

변수의 참조는 4 > 3 > 2 > 1의 순서로 간다. 함수안에서 글로벌 네임스페이스에 접근하기 위해선 global이라는 키워드를 명시 해야한다.

읽을 거리

Python Namespace Scope

🪄 init 같은 메소드는 magic method라고 불린다

&nbsp 파이썬 소스코드를 보면서 언더바 두개로 감싸진 함수를 본적이 있을 것이다. 대표적으로 __init__ 이 있겠다. 이러한 메소드는 magic method 또는 special method라고 불린다.

왜 하필 magic method 이냐고? 사용자가 정의한 클래스에 마법 같은 기능을 부여하기 때문이다

말이냐 방구냐고? 풀어서 설명 해보겠다. 매직 메소드를 클래스에 추가하면, 사용자가 생성한 커스텀 클래스가, 파이썬의 빌트인 타입과 동일한 동작을 할수 있게 하는 것이 가능하다.

매우매우 간략한 예시를 들자면 __eq__라는 메소드를 정의하면 == 연산자를 오브젝트에 사용할 시 어떻게 동작 할지 정의 할 수있다.

읽을거리

magicmethods

Mutable vs Immutable

&nbsp 파이썬의 모든 것은 객체이다. 어떤 객체는 mutable이고 어떤 객체는 immutable인지 알면 좋다. 아래의 그래프도 한번 훑어보자. 빨간색 박스에서 시작해서 화살표 방향으로 읽으면 된다.

1. List are Mutable.
2. List are the most popular type of Collections
3. List are orderd group of Elements which are actually Pointers.

읽을거리

Mutable and Immutable Side of Python

✨ Class Attributes

🚧 추가 예정

읽을거리

Python Class Attributes an Overly Thorough Guide

3. 기타

포멧팅은 어떻게 하면 좋을까?

javascript에는 prettier가 있고 golang에는 gofmt가 있는데 파이썬은? 삼대장이 있다. autopep8, yapf, black에서 취향껏 선택하면 된다. 글쓴이는 black을 사용 중이다.

읽을거리

Auto formmatters for Python

알고리즘을 공부 안한다고 코딩을 못하는 것은 아니다. 하지만, 알고리즘을 공부하면 컴퓨터에게 더 똑똑하게 일을 시킬 수 있다.

&nbsp 프로그래밍 입문자를 위한 포스팅입니다. 알고리즘과 재귀의 정의, 하노이의 탑 게임의 룰을 알고있다면 더 재미있게 읽으실 것이라고 생각합니다 😊

알고리즘, 알고리즘, 알고리즘

&nbsp 글쓴이는 프로그래밍을 처음 입문 할 당시, 알고리즘 알레르기가 있었다. 물론 기능을 구현하는데 필요한 자료구조와 알고리즘은 제외. 아무튼 글쓴이는 알고리즘은 당장 취업할때나 필요하고, 이후엔 매우 어려운 문제에 봉착하는 경우, 특수한 케이스를 해결하기 위해서 공부하면 될 것이라고 생각했다. 그런데 얼마전에 이를 바꿀만한 경험을 했고, 그 경험을 공유하고자 포스팅을 한다.

프로그래밍 감각과 재귀법

&nbsp 사수님과 점심을 같이 먹고 있었다. 갑자기 질문을 받았다.

사수님 : 입문자가 프로그래밍 감각이 있는지 판단하기 가장 쉬운 방법이 뭔지 아세요? 글쓴이 : 음... 잘모르겠네요 사수님 : 재귀 알고리즘 문제를 풀어보라고 하면 되요 글쓴이 : 어째서죠??? 사수님 : 재귀함수를 잘 짜면 연역적으로 사고 할 수 있다는 뜻이거든요 ㅎㅎ

하노이의 탑

&nbsp 사수님에게 설명을 부탁드렸다. 백문이불여일견이라고 알고리즘 문제를 직접 풀어보는게 빠르다고 말하셨다. 여러분도 직접 풀어볼 수 있도록 문제를 내보겠다. 제약 사항을 집중해서 보자.

하노이의 탑 n개의 꽂힌 원판들을 그 순서 그대로 다른 기둥으로 옮겨서 다시 쌓아야 한다.

1. 한 번에 하나의 원판만 옮길 수 있다.
2. 큰 원판이 작은 원판 위에 있어서는 안 된다.

문제 n개의 원판을 모두 옮기는데 필요한 시행 회수를 도출하는 함수를 구현하라. 예시) 3개의 원판을 모두 옮기려면 7번의 시행 회수가 필요하다면 hanoi(3) = 7

1. 재귀함수로 구현 할 것.
2. 귀납법을 사용하면 안된다.

&nbsp 귀납법은 사례나 현상에서 부터 일반적인 결론을 이끌어내는 추론 방법이다. 즉 하노이의 탑을 귀납적으로 해결한다고 하면, 직접 게임을 수행 한후, 일련의 과정에서 통용 되는 법칙을 찾을 것이다. 독자들이 글쓴이와 유사하다면, 다음과 같은 과정을 거칠 것이다.

귀납적으로 푼다면

1. 우선 원판 직접 게임을 시행 해볼까?

1. hanoi(1) = 1 일 것이고 hanoi(2) = 3이고 hanoi(3)은 몇이지?
2. 머리속에서 하기 어렵군 그림을 한번 그려보자.

4. hanoi(3) = 7이군. 이제 통용되는 로직을 생각해보자. 우선 맨 위에 있는 원판을 c로 이동시키고, 그 다음에는...

귀납 멈춰!!!✋

재귀법의 문제 해결 방법

1. 일정 조건이 만족 되면 자기 자신을 호출하지 않는다. (종료조건)
2. 자기 자신을 호출하면 할 수록 1번의 조건에 가까워져야한다. (종료조건으로 수렴)
3. 1번에 부합하지 않는다면, 2를 이행하는 행동을 하고 자기자신을 호출한다. (재귀)

&nbsp 정신이 멍해져버렸다. 정신을 가다듬고 다시 생각 해보자. 문제에 재귀법을 사용하라 했으니 당연히 재귀함수를 짜야할 것이다. 재귀함수에는 종료조건이 필요하다. 머리를 식힐겸 함수를 한번 짜보자.

def hanoi(n):
    # 원판이 1개라면 1회의 시행으로 게임이 끝난다
    if n == 1:
        return 1

오케이 이건 금방 생각 할 수 있다. 그러면 어떻게 종료조건으로 수렴 시키면 좋을까?

연역적으로 푼다면

&nbsp 연역법은 일반적으로 알려진 이론을 어떠한 현상에 대입시켜 이에 대한 결론을 도출해내는 방법이다. 사전적 개념은 '어떤 명제로부터 추론 규칙에 따라 결론을 이끌어 내는 것'을 말한다. 글쓴이와 같이 문제를 다시 살펴보자.

1. 당연하지만, 사람이 풀라고 만든 문제일 것이다.

1. 재귀법을 사용하라고 했다, 따라서 재귀법으로 풀 수 있는 문제일 것이다.
2. 재귀함수는 자기자신을 호출한다, 반복적으로 함수가 실행된다는 것이다.
3. 즉 하노이의 탑 게임은, 반복적으로 같은 행동을 수행하면 클리어 가능한 게임이다.

사실 연습문제 였다. 축하합니다. 하지만 덕분에 당신은 연역법을 마스터했습니다. 이제 하노이의 탑 게임의 룰을 생각해보자

1. 작은 원판 위에 큰 원판이 있을 수 없다.

1. 따라서, 목적지 기둥에는 가장 큰 원판 부터 순서대로 원판이 쌓여야한다.

2. 즉, 목적지 기둥에 가장 큰 원판을 먼저 옮겨야한다.

3. 그러기 위해서는 가장 큰 원판을 제외한 모든 원판을 중간 기둥으로 옮겨야한다.

   

띠띠용!💡 가장 큰 원판을 제외한 원판을 중간 기둥으로 옮기는 것은 1개 적은 원판 개수로, 하노이의 탑 게임을 하는 것과 동일하다!!! 반복작업을 찾았다!!!

수식으로 표현하면 다음과 같다. 이걸 그대로 함수에 적용하면 된다.

hanoi(n) = 2 * hanoi(n-1) + 1

빨리 정답 알려주세요

def hanoi(n):
    # 원판이 1개라면 1회의 시행으로 게임이 끝난다
    if n == 1:
        return 1
    # 수식을 그대로 집어 넣자
    return 2 * hanoi(n-1) + 1

&nbsp 뭔가 엄청 간단해 보인다. 게임 클리어에 필요한 시행 회수를 계산하는 함수를 만들긴 했는데, 어떻게 가장 짧은 회수로 게임을 클리어하는 방법 자체는 모르겠다. 하노이의 탑 그게 뭔데? 그거 어떻게 하는 건데?

모르는게 정상이다

&nbsp 극단적인 예시를 들어보자. 물리엔진을 만든 개발자가 있다. 당신은 그 개발자에게 다음과 같은 질문을 했다.

님이 만드신 물리엔진에서 젠가를 쌓아놓고 거기다가 공을 차면 어떻게 되나요?

다음 중 어느 대답이 더 신빙성이 있는가?

1. 그러한 경우 제가 이렇게 저렇게 동작하게 만들어 놓았기 때문에 다음과 같은 결과가 나올 것입니다...
2. 시뮬레이션을 돌려봐야 알 것 같은데요. 해당 케이스에 적용 되는 법칙은 다음과 같습니다...

글쓴이 같으면 2번 대답이 더 신빙성이 있을 것 같다. 물론 글쓴이가 물리엔진을 잘안다는 것은 아니고. 물리엔진 처럼 복잡한 프로그램을 만들면서, 모든 케이스를 일일히 직접 생각해가면서 만드는게 편할까. 통용이 가능한 공식의 모음으로 생각하면서 만드는게 편할까? 전자와 후자 중 어느 경우가 에러가 더 많을까?

컴퓨터에게 생각을 이양하자

&nbsp 컴퓨터는 똑똑하다. 계산을 실수하는 일도 없고. 기억력도 사람보다 좋다. 하지만 컴퓨터는 멍청하기도 하다. 당연하지만, 시킨일 밖에 못한다. 컴퓨터에게 명령하기 위해서는 명확한 룰을 정해서 프로그래밍 언어로 실수 없이 정리 해줘야한다. 효율적으로 프로그램을 짜기 위해서는 컴퓨터에게 현명한 명령을 내려야한다. 말은 쉽지 현명하게 명령을 내리는 것은 겁나 어렵다. 그래서 알고리즘이 어렵다.

&nbsp 하지만 현명하게 명령을 내릴 수 있다면 어려운 문제를 해결 할 수 있다. 애초에 사람이 쉽고 빠르게 해결할 수 있는 문제였으면 프로그램을 작성할 필요가 희박하다고, 글쓴이는 생각한다. 뭔가 하노이의 탑 알고리즘을 이야기하다가, 왜 프로그래밍을 하는지에 대해 까지 급발진 한 것 같다. 정리 하자면 다음과 같다.

&nbsp 알고리즘이란 어떠한 문제를 해결하기 위해 정해진 일련의 절차나 방법을 공식화한 형태로 표현한 것 또는 계산을 실행하기 위한 단계적 절차를 의미한다. 알고리즘 문제를 푸는 것은 컴퓨터에게 생각 또는 작업을 이양하는 것의 연습이다.