디자인도 이쁘고 코드도 이쁘게 짤 순 없을까??

이 단순한 생각에서 이 글 시리즈를 작성하게 된 계기가 되었습니다! (대 바이브코딩 시대에, 문서보고 코드짜는 멋쟁이가 되고 싶어...)

리액트를 직접 만든 사람들은 어떻게 생각하고 만들었을까?

React 공식 문서 Thinking in React를 단순히 ‘컴포넌트 나누는 방법’으로 보는 것이 아니라,

제가 열심히 해체 분석해보려 합니다! shout out to sAewoo

React의 본질적 철학(순수 함수 UI, 책임 분리, 단방향 데이터 흐름, 예측 가능성) 관점에서 알아보려고 합니다.

이 관점을 기반으로 다음을 얻을 수 있습니다!:

• React가 왜 이런 방식으로 UI를 구성하도록 가이드를 제시하는지 철학적 이유

• 컴포넌트 설계가 ‘감’에서 ‘원리 기반 판단’으로 전환하기.(추구했던 바!!)

목차

1. Thinking in React 5단계의 나만의 해석
2. 상태 배치(State Architecture)를 판단하는 기준
3. 단방향 데이터 흐름과 예측 가능성 확보

1. UI = f(state): 왜 이 식이 필요할까?

React를 진지하게 이해하려면, 먼저 이 한 줄을 이해해야 한다.

UI = f(state)

React 제작자 들이 하고 싶은 말은 단순하다.

“UI는 직접 조작하는 대상이 아니라, 상태(state)를 넣으면 계산되어 나오는 결과물이어야 한다.”

이 식이 왜 필요한지, 그리고 이게 무너지면 어떤 지옥이 펼쳐지는지부터 짚고 가자.

1.1 기존 UI 패턴이 왜 망가지는가: “상태 지옥”

전통적인 웹 UI는 대부분 이렇게 동작했었다.

• DOM에서 요소를 찾고
• 이벤트가 발생할 때마다
• class를 붙였다 떼었다,
• 텍스트를 바꾸고,
• 여러 상태나 데이터를 “수동으로” 맞춘다.

문제는 상태가 한 군데에 모여 있지 않다는 점이다.

• 서버 응답 결과 일부는 전역 변수에,
• 일부는 DOM attribute에,
• 일부는 컴포넌트 인스턴스 필드에,
• 심지어 유저가 뭔가 조작하면 또 다른 곳에 복사본이 생긴다.

이렇게 되면 필연적으로 이런 상황이 온다.

• 어떤 버튼은 활성화인데, 다른 영역은 여전히 비활성화로 보인다.
• 모달은 닫혔는데, 오버레이는 남아 있다.
• 토글 버튼 텍스트는 ON인데 실제 로직 값은 false다.

즉, “앱의 진짜 상태”와 “눈에 보이는 UI”가 서로 어긋나는 순간부터 디버깅은 감과 운에 의존하는 게임이 된다.

이게 React가 해결하려는 문제의 본질이다.

1.2 React의 관점: “UI를 단순 화면이 아니라 함수로 취급하자”

React는 여기서 접근을 통째로 바꾼다.

• 더 이상 “UI를 어떻게 바꿀지(how)”를 작성하지 말고,
• “지금 상태라면 UI가 어떻게 생겨야 하는지(what)”를 정의하라고 한다.

즉,

UI = f(state)

• 입력: 현재 앱 상태(state)
• 출력: 그 상태에서의 UI 트리(React element tree)

우리는 더 이상 DOM 조작 절차를 나열하지 않는다. 대신 state를 인자로 받아 UI를 반환하는 함수를 설계한다.

이게 “선언형 UI(Declarative UI)”.

“상태가 이렇게 생겼으면, 화면은 이렇게 보여야 한다”를 함수 정의로 고정해 두는 것.

1.3 순수 함수 UI의 세 가지 조건

React가 진짜로 원하는 건 “순수 함수처럼 보이는 UI”다. 순수 함수 UI는 최소한 아래 세 가지를 만족해야 한다.

1. 같은 state == 항상 같은 UI

   • 랜덤, 시간, 전역 mutable 변수 등에 의해 결과가 바뀌지 않는다.

2. UI는 오직 props와 state로만 결정된다

   • 컴포넌트 내부에서 몰래 전역 싱글톤을 직접 바꾸고 참조하는 패턴은 독이다.

3. 렌더링 과정에는 side effect가 없다

   • DOM 직접 조작, 네트워크 요청, 로깅 등은 useEffect 같은 별도 단계에서 처리해야 한다.

이게 지켜져야 다음이 가능해진다.

• 상태만 보면 UI가 어떻게 생겼는지 예측 가능
• 특정 state를 주입해서 화면을 테스트 가능 (그래서 TDD를?)
• UI 변경 이력을 추론 가능(“왜 이렇게 보이는지” 설명 가능)

즉, 테스트 가능하고, 예측 가능하고, 리팩터링 가능한 UI의 최소 조건이 바로 이거다.

1.4 이 식이 설계에 강제하는 구조적 결과

UI = f(state)를 진지하게 받아들이면, 설계는 어쩔 수 없이 다음과 같이 바뀐다.

1. 상태는 함수 밖에서 관리하고, arg로 주입한다.

   • 컴포넌트는 “현재 상태를 기반으로 UI를 그리는 기계”가 된다.

2. 렌더링 로직은 side effect에서 분리된다.

   • 그리는 것(render)과 “반응하는 것(effect)”을 분리해야 순수성이 유지된다.

3. 자식 컴포넌트는 함수 합성처럼 다뤄진다.

   • 부모가 state → UI로 계산한 결과 일부를 props로 넘긴다.
   • 자식은 받은 props를 다시 UI로 매핑하는 작은 함수다.

즉, 전체 React 앱은 거대한:

AppUI = f(globalState)

를 작은 함수 여러 개의 합성으로 분해한 것에 불과하다.

이 관점이 잡히면, 컴포넌트 나누기, props 구조, state 위치 선정은 전부 이 식을 깨지 않기 위한 아키텍처 작업으로 이해할 수 있다.

1.5 UI = f(state)가 깨질 때 벌어지는 사고들

반대로, 이 원칙을 무시하면 어떤 일이 생길까? 대표적인 실패 패턴 몇 가지를 보자.

1. 렌더링 중 전역으로 읽고/수정하는 컴포넌트

   • 테스트 환경에서 상태 주입이 안 된다.
   • 어디서 값이 바뀌는지 추적이 불가능해진다.

2. derived state를 또 다른 state로 중복 저장하는 패턴

   • 예: items와 filteredItems를 둘 다 state로 들고 있기
   • 둘의 동기화를 계속 맞춰야 한다는 건, 결국 언젠가 틀어진다.(디버깅시 매우 까다로워진다.)
   • 사실 filteredItems = f(items, filter)로 매번 계산하는 게 맞다.

3. 렌더링 안에서 DOM을 직접 건드리는 코드

   • React의 렌더링 사이클과 충돌한다.
   • “분명히 상태는 false인데, DOM은 여전히 열려 있음” 같은 모순 발생.

이 모든 문제는 한 줄로 정리된다.

“UI가 state의 함수가 아닐 때, UI와 state는 언젠가 반드시 어긋난다.”

1.6 Thinking in React

이제 “왜 UI = f(state)가 필요한가”는 어느 정도 명확해졌다. 그럼 공식 문서의 5단계는 어디에 위치할까?

• UI를 컴포넌트로 나누기
• 정적 버전 만들기
• 최소한의 상태 찾기
• 상태를 어디 둘지 정하기
• 단방향 데이터 흐름 구성하기

이건 전부 메타 수준에서 보면 한 가지 목적.

“앱 전체를 UI = f(state) 구조에 맞게 재조직하는 절차”

• 정적 버전 만들기는, 순수 함수 UI 먼저 확보
• 최소 상태 찾기는, f의 입력을 필요 최소한으로 압축
• 상태 위치 정하기는, f가 어디서 정의되는지, 책임 단위로 배치
• 단방향 데이터 흐름는, 입력이 어디서 왔는지 추적가능하게 만들기

그래서 이 글 전체의 구조도 이렇게 잡아보자.

1. 1장: UI = f(state) — 왜 이 식이 필요한가 (지금 읽고 있는 부분)
2. 2장: 상태관리와 책임 단위 — f(state)에서 state를 어디서 관리할 것인가
3. 3장: 단방향 데이터 흐름 — state -> UI -> 이벤트 -> state로 이어지는 루프를 어떻게 닫을 것인가

이제 다음 장에서 다룰 질문은 명확하다.

“좋다, UI = f(state)인 건 알겠다. 그럼 그 state는 어디에 둬야 예측 가능한 시스템이 되나?”

그게 바로 2장의 주제, “상태관리 및 책임 단위(State Architecture)”이다.

출처 : https://overreacted.io/the-two-reacts/ https://www.youtube.com/watch?v=x7cQ3mrcKaY https://overreacted.io/a-complete-guide-to-useeffect/ https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0

문제

이번 주엔 1. TDD를 활용 하기 (RED-GREEN-REFATOR) 2. 포인트에서의 동시성 락을 어떻게 해결할까? (non-blocking, single-thread 기반의 nest.js)

TDD와의 첫 만남... (시험 2일 전)

사실 첫만남은 매우 비호감입니다; 중간고사와 겹치는 불상사!어쩔 수 없습니다. 해내는게 저이고 말고요.

일단 TDD의 기본 베이스는 이렇습니다.

Red : 실패하는 테스트 코드를 먼저 작성 Green : 테스트 코드를 성공시키기 위한 실제 코드를 작성 Refactor : 테스트 결과에 맞추어 (커버리지나 중복 코드 및 읽기 쉬운 코드 등) 리팩토링을 수행하는 것

개인적으로 느낀 장점은 이렇습니다.

한 번에 조금씩 커밋하고, 메시지는 Claude로 자동화

이렇게 개발하는 방법은 처음 겪어 봤기에 테스트 코드를 작성을 먼저 해봤습니다.

// 동시에 충전과 사용 요청
            const promises = [
                service.chargePoint(userId, chargeAmount), // +3000
                service.usePoint(userId, useAmount),       // -2000  
                service.chargePoint(userId, chargeAmount)  // +3000
            ];

            const results = await Promise.all(promises);

            // 최종 잔고는 15000 + 3000 - 2000 + 3000 = 19000이어야 함
            const expectedFinalBalance = 
                initialBalance + chargeAmount - useAmount + chargeAmount;

            // 모든 연산이 순차적으로 적용되었는지 확인
            // 현재는 동시성 제어가 없어서 예상과 다를 것
            const balances = results.map(result => result.point);
            const maxBalance = Math.max(...balances);

            expect(maxBalance).toBe(expectedFinalBalance);
        }, 10000);

이렇게 spec.ts를 기준으로 가설을 세우고, 동시에 충전과 사용 요청을 만들어 봤습니다.

초기값과 최종값에만 의존하는 상태함수 개념 (간단한 아이디어)

그래도 아직 테스트 코드 자체의 문법이 익숙하지 않아 학습할 필요가 있어 숙달해야할 듯 합니다.

사실 제대로 했을까?

현재 테스트는 최종 상태를 보지 않고 중간 응답의 최댓값으로 판정하므로 신뢰할 수 없움

nest.js의 튜토리얼을 참고해보기!

그렇게 커버리지 100퍼 달성은 refactoring 과정에서 달성을 할 수 있었다? 좋은거 맞아?

마치 문제를 정의하고 틀리게 해결하면 무슨 소용일까요.

가치있는 테스트를 위한 전략과 구현

위의 테스트 코드의 전략과 구현의 글을 보고 좋은 테스트 코드는 무엇인지 잘 숙지를 해야한다는 점입니다.

Fast: 테스트는 빠르게 동작하여 자주 돌릴 수 있어야 함 Independent: 각각의 테스트는 독립적이며 서로 의존해서는 안 됨 Repeatable: 어느 환경에서도 반복 가능해야 함 Self-Validating: 테스트는 성공 또는 실패로 bool 값으로 결과를 내어 자체적으로 검증되어야 함 Timely: 테스트는 적시에 즉, 테스트하려는 실제 코드를 구현하기 직전에 구현해야 함

✨ 핵심 테스트 코드를 목적에 맞게 적절히 구현하는 것이 중요

동시성 락, 싸우지마 애들아!

위 그림을 본다면 덮어쓰기가 2번 동작하네??? 어라,,, 그러면 115달러가 아니고 105달러가 최종 답이네...? John과 Alice는 계좌 금액에 대해 동시 접근을 해...

경쟁 상태(race condition)란?

여러 개의 프로세스가 공유 자원에 동시 접근할 때 실행 순서에 따라 결과값이 달라질 수 있는 현상

그렇다면 어떻게 해결하는 것이 좋을까?

누가 먼저 할래? 그럼 줄 서

• 선택한 접근 방식: Promise 기반 Lock 시스템

왜 이 방식을 선택했는가?

• 1. Node.js 싱글 스레드 특성 활용하기

// 전통적인 Mutex 대신 Promise 기반 접근
private readonly locks = new Map<number, Promise<any>>();

Node.js는 싱글 스레드 이벤트 루프 기반
메모리 내 Map을 통한 간단하고 효율적인 구현
별도 라이브러리 의존성 없음

• 2. 사용자별 독립적 Lock 관리

async withLock<T>(userId: number, operation: () => Promise<T>): Promise<T> {
    const existingLock = this.locks.get(userId);
    // 사용자별 개별 Lock 처리
}

다음과 같은 플로우 차트를 기반으로 기획을 했었다.

사실 이건 거짓 락에 불과한 건데, 제출하고 나서 스스로 분석도 하고 피드백을 참고해보니까...

• 1. 허들(Thundering herd)문제 : 이벤트가 발생하면 모두 동시에 깨어나 하나의 자원을 차지하려고 경쟁하는 현상

if (existingLock) await Promise.race([existingLock, timeout]);
const newLock = operation();
this.locks.set(userId, newLock);

여러 호출이 같은 기존 락이 끝나길 기다린 뒤, 동시에 operation()을 시작할 수 있습니다. 마치 오픈런...

• 2. 해제 제대로 안된다...

    operation().finally(() => this.locks.delete(userId));

나보다 나중에 들어온 작업이 this.locks.set(userId, next)로 새 작업(tail)을 세팅해도, 먼저 끝난 작업의 finally가 무조건 delete를 호출하면 현재 진행 중인 끝 부분도 같이 지워진다.

• 3. 이전 작업 실패 전파

existingLock이 reject 되면 다음 호출도 await에서 같이 터짐 -> 연쇄 실패. (보통 직렬화 큐는 “이전 실패와 무관하게 다음 작업은 진행”이 자연스러움)

• 4. 공정성/대기열 없음

FIFO 보장 없음. “먼저 도착한 요청이 먼저 실행”이 깨지기 쉽습니다.

가차없는 피드백을 받았습니다,,, 사실 map말고 queue를 썼다면 좋을텐데~

다음 목표

시간에 쫓기지 않고 좀 더 CS기반으로 판단해서 구현을 하는 것을 목적으로!

플로우 차트를 그리면서 고민 또 고민을 했어야했고, 왜 맵을 썼는지 이유를 근거해서 구현을 하면 좋을 것 같아.

내가 맞게 했는지 의심하고 또 의심해라

구현을 하면서 테스트코드 자체가 맞다고 생각하면서 구현을 하니 아무것도 성공할 수 없었습니다. 잘못된 테스트는 잘못된 리팩토링을 불러옵니다

사실 프론트엔드 개발만 진행하다 보고, 어쩌다 내일 일경험에서 백엔드도 다뤄야 했어서 조금씩 경험했던 게, 계기가 되었다. 좋은 사람들과 함께 성장할 수 있다는 점도 매우 크게 작용했다. 학교 밖에서의 사람들과 협업할 수 있다니 너무 기쁘다.

10주간의 목표

1. TDD를 앞으로의 프로젝트에서 다룰 수 있을 정도

2. 대용량 트래픽을 활용한 나만의 프로젝트 개발

3. 여러 선배 개발자들의 지식 및 철학 흡수하기

프로그래머스 뉴스 클러스터링

문제 정의

두 문자열에서 연속된 2글자씩 끊어 만든 다중집합을 구성하고, 두 다중집합의 자카드 유사도 J(A, B) = 교집합(A,B) / 합집합(A,B) 를 계산해 65536을 곱해 소수점 아래를 버린 값을 구해야 한다.

• 알파벳만 유효(숫자/특수문자 포함 쌍은 제외)
• 대소문자 구분 없음(모두 소문자로 처리)
• 다중집합(원소 중복 허용) 기준의 교집합/합집합 계산
• 두 집합 모두 공집합이면 유사도 1로 간주, 65536 반환

접근 방법

• 문자열을 순회하며 2글자 쌍을 만들고, 둘 다 알파벳인 경우만 선택

• 소문자로 변환하여 정규화 : tolower() 사용

• 다중집합 구현은 2차원 카운팅 배열 사용: 알파벳 26×26 (a~z)

  • count1[a][b], count2[a][b]

• 교집합 크기: 각 키에 대해 min(count1, count2)의 합

• 합집합 크기: 각 키에 대해 max(count1, count2)의 합

  • 예시의 힌트를 활용했다!

• 개꿀*

• 합집합이 0이면 65536, 아니면 floor((inter/union) * 65536) 반환

구현 코드 (C++)

#include <bits/stdc++.h>

// 어 문자열 문제? 
// 유사도를 구하는데 2개씩 비교 (교집합) / (합집합)
// 집합 A와 집합 B가 모두 공집합일 경우 -> 1

// 확장하니 원소의 중복을 허용하는 다중집합
// (교집합-중복x) / (합집합-중복o)
// 알파벳 + 빈도 수 -> 2차원 <키(a,b), 나오는 빈도> 배열 활용
using namespace std;


int solution(string str1, string str2) {
    int answer = 0;

    int ch_map1[26][26];
    int ch_map2[26][26];

    fill(&ch_map1[0][0], &ch_map1[0][0]+26 * 26, 0);
    fill(&ch_map2[0][0], &ch_map2[0][0]+26 * 26, 0);
    //알바벳 first, second 에 저장되는 cnt -> 0으로 초기화

    for(int i = 0; i < str1.size()-1; i++){
        char a = tolower(str1[i]);
        char b = tolower(str1[i+1]);
        if (isalpha(a) && isalpha(b)) {
            ch_map1[a - 'a'][b - 'a']++;
        }
    }
    for(int i = 0; i < str2.size()-1; i++){
        char a = tolower(str2[i]);
        char b = tolower(str2[i+1]);
        if (isalpha(a) && isalpha(b)) {
            ch_map2[a - 'a'][b - 'a']++;
        }
    }



    int interCnt = 0; //교집합
    int unionCnt = 0; //합집합
    for (int i = 0; i < 26; i++) {
        for (int j = 0; j < 26; j++) {
            interCnt += min(ch_map1[i][j], ch_map2[i][j]); 
            //설명에서 다중집합 확장한 방법
            unionCnt += max(ch_map1[i][j], ch_map2[i][j]);
        }
    }

    if (unionCnt == 0) return 65536; //공집합이면 유사도 1

    //자카드 유사도 계산
    answer = floor( (interCnt*1.0 / unionCnt) * 65536);//소수점 버림

    return answer;
}

핵심 포인트

1. 정규화: 대소문자 무시 -> 모두 소문자 변환
2. 유효 문자 필터링: 2글자 모두 알파벳일 때만 선택하기
3. 다중집합 계산: 교집합은 min, 합집합은 max의 합으로 구현 : 설명 내에 답이 있었다.
4. 엣지 케이스: 합집합이 0이면 65536 반환
5. 상수 크기 맵: 26×26 카운팅 배열로 빠르게 처리 (메모리/속도 유리)

시간 복잡도

• 문자열 전처리: O(|str1| + |str2|)
• 교집합/합집합 계산: O(26×26) = O(1)
• 전체: O(N)

학습 포인트

• 다중집합 교집합/합집합을 빈도 맵으로 구현하는 패턴 이해
• 문자열 전처리와 유효성 검사(isalpha, tolower) 순서 중요
• 자카드 유사도 정의 및 엣지 케이스 처리(공집합)

문제 정의

• 입력: N×N 보드 (0=빈칸, 1=벽)

• 시작점: (0,0)

• 목표점: (N-1, N-1)

• 이동: 상하좌우 한 칸씩 이동

• 비용:

  • 직선 이동: 100원
  • 코너 발생 시: 100 + 500 = 600원

• 목표: 목표칸까지 누적 비용의 최솟값

핵심 인사이트

문제의 핵심

같은 좌표라도 "들어온 방향"에 따라 이후 코너 비용이 달라지므로, dist[x][y]만으로는 최적성 보장이 불가능.

해결 방안

좌표 상황을 (x, y, dir)로 확장하여 dist[x][y][dir]에 "dir로 진입했을 때의 최소비용"을 저장.

알고리즘 선택

비용이 균일하지 않으므로 BFS는 부적합, 다익스트라 알고리즘을 사용해야 한다.

알고리즘 개요

자료구조

// 3차원 거리 배열: dist[x][y][dir]
vector<vector<vector<int>>> dist(
    size, vector<vector<int>>(size, vector<int>(4, INF))
);

// 우선순위 큐 (최소 힙)
priority_queue<block, vector<block>, Cmp> pq;

초기화

• 시작점 (0,0)은 방향이 없음
• (0,0) 인접 유효 칸으로 첫 이동을 직선 비용(100) push

전개 과정

1. pq에서 최소 cost를 꺼냄 (꺼낸 cost != dist이면 스킵)
2. 4방향으로 확장
   • 다음 방향이 현재 dir과 같으면 +100 (직선)
   • 다르면 +600 (코너)
3. 더 작게 갱신되면 dist 갱신 후 pq에 푸시

종료 조건

정답 = min(dist[N-1][N-1][0..3])

구현 포인트

방향 벡터 설정

int dir[4][2] = {{0,-1}, {-1,0}, {0,1}, {1,0}}; 
// 상좌하우 방향, 세로 이동 0,2 / 가로이동 1,3

우선순위 큐 설정

struct Cmp {
    bool operator()(const block& a, const block& b) const {
        return a.cost > b.cost; // 비용 작은 게 top
    }
};

중요한 구현 세부사항

• 첫 이동만 직선 비용 처리 (시작에 방향 X)

자주 나오는 버그와 수정

복잡도 분석

• 블럭 상태의 수: O(4N^2) = O(N^2)
• 시간복잡도: O(N^2 log N) (각 상태에서 최대 4개의 간선, 힙 시간복잡도 포함)
• 공간복잡도: O(N^2)

코드 구조

typedef struct Block {
    int cost; // 지금까지 누적 cost
    int x;    // 현재 x(행)
    int y;    // 현재 y(열)
    int dir;  // 이 칸으로 들어온 방향(0~3)
} block;

#define L_COST 100  // 직선 비용
#define C_COST 600  // 코너 비용 (100 + 500)
#define INF 999999  // 무한대

핵심 로직

// 코너 판별 및 비용 계산
int add = (i == cur.dir) ? L_COST : C_COST;
int nc = cur.cost + add;

// 최적화: 이미 더 좋은 비용으로 갱신되었다면 스킵
if (cur.cost != dist[cur.x][cur.y][cur.dir]) continue;

이 알고리즘은 블럭 상태의 추가와 다익스트라를 결합하여 경로의 방향성을 고려한 최적 경로를 찾는 문제.

이번 기회에 백준 문제풀었던 걸 복기하기 위해 작성을 시작했습니다!! 같이 열심히 백준 풀어봅시다!

이 문제에 대해 간단히 알아봅시다:)

다음과 같은 기능을 구현하는 스택입니다.

push X: 정수 X를 스택에 넣는 연산 pop: 스택에서 가장 위에 있는 정수를 빼고, 그 수를 출력한다. 만약 스택에 들어있는 정수가 없는 경우에는 -1을 출력 size: 스택에 들어있는 정수의 개수를 출력 empty: 스택이 비어있으면 1, 아니면 0을 출력한다. top: 스택의 가장 위에 있는 정수를 출력한다. 만약 스택에 들어있는 정수가 없는 경우에는 -1을 출력한다.

1. 스택 구조란?

스택 구조는 흔히 말하는 FILO(First In, Last Out), 즉 선입후출 구조입니다.

위와 같은 스택 구조는 기본적으로 일직선 적인 구조라 선형구조입니다. 그래서 스택을 배열과 연결 리스트 두 가지 방식으로 짤 수 있습니다.

typedef struct StackNode {
    element data;
    struct StackNode* link;
}stack;

위의 코드는 간단한 스택의 리스트형 구조입니다. 노드끼리 연결해주는 포인터와 데이터입니다. 연결리스트의 기본 요소니 기억해주세요

마지막 부분은 TOP으로 잡겠습니다. 나가는 출구 및 입구!

2. 스택 각 기능 구현

스택에서 필요한 것은 딱 두가지 선형 구조와 어디가 마지막인지 알려주는 탑 입니다.

push : 새로운 노드를 생성하고 데이터를 저장합니다. 새 노드의 link를 현재 TOP으로 설정! pop: 1. 스택이 비어있는 경우 -1을 반환합니다. 2. 스택의 모든 노드를 순회. size: 스택에 들어있는 정수의 개수를 출력 empty: 스택이 비어있으면 1, 아니면 0을 출력 top: 스택이 비어있으면 -1을, top인덱스가 가르키는 노드의 데이터를 반환

3. 답안 코드

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

typedef int element;

typedef struct StackNode {
    element data;
    struct StackNode* link;
}stack;

void push(element x);
element pop(void); // no top = -1
int size(void);
int empty(void); //empty == 1, not empty == 0
element top(void); // no top = -1

stack* TOP;

int main()
{
    int n;
    char cmd[6];
    int cnt = 0;

    TOP = NULL;

    scanf("%d", &n);

    for (int i = 0; i < n; i++) {
        scanf("%s", cmd);
        getchar();

        if (!strcmp(cmd, "push")) {

            element input;
            scanf("%d", &input);

            push(input);
            continue;
        }

        else if (!strcmp(cmd, "pop")) {
            printf("%d\n", pop());
            continue;
        }

        else if (!strcmp(cmd, "size")) {
            printf("%d\n", size());
            continue;
        }

        else if (!strcmp(cmd, "empty")) {
            printf("%d\n", empty());
            continue;
        }

        else if (!strcmp(cmd, "top")) {
            printf("%d\n", top());
            continue;
        }
    }

    return 0;
}

void push(element x) {
    stack* tmp = (stack*)malloc(sizeof(stack));

    tmp->link = TOP;
    tmp->data = x;
    TOP = tmp;

    return;
}
element pop(void) {
    if (empty()) return -1;
    else {
        stack* old = TOP;

        TOP = old->link;
        element tmp = old->data;
        free(old);
        return tmp;
    }
}
int size(void) {
    stack* tmp = TOP;
    int cnt = 0;

    while (tmp) {
        cnt++;
        tmp = tmp->link;
    }
    return cnt;
}
int empty(void) {
    if (TOP == NULL) {
        return 1;
    }
    else {
        return  0;
    }
}
element top(void) {
    if(empty()) return -1;
    else {
        return (TOP->data);
    }
}