개발 블로그

Unity 오브젝트 생성·삭제할 때 자주 쓰는 함수들

daehwan2 — Thu, 5 Feb 2026 11:33:57 +0900

Instantiate부터 Destroy까지, 실제로 가장 많이 쓰는 것들만 정리

Unity로 게임을 만들다 보면
결국 계속 반복하게 되는 작업이 있습니다.

적 생성
총알 생성
이펙트 생성
오브젝트 삭제
다시 생성

처음엔 그냥 튜토리얼 따라 치다가
어느 순간 이런 고민이 생깁니다.

“이거 계속 Instantiate / Destroy 써도 되나?”
“SetActive랑 뭐가 다른 거지?”
“왜 프레임이 갑자기 떨어지지…?”

저도 이 부분에서 꽤 많이 삽질했습니다.
그래서 이 글에서는
Unity에서 오브젝트 생성·삭제할 때 실제로 가장 많이 쓰는 함수들을
실전 기준으로 정리해보려고 합니다.

1️⃣ Instantiate() – 오브젝트 생성의 시작

Instantiate(prefab);

Unity에서 오브젝트를 만드는 가장 기본적인 방법입니다.

보통 이렇게 씁니다.

Instantiate(prefab, position, rotation);

주로 사용하는 상황:

적 스폰
총알 발사
이펙트 생성
UI 동적 생성

프리팹 기반 생성이 기본 패턴입니다.

주의할 점

너무 자주 호출하면 성능 문제 발생
Update에서 무분별하게 쓰면 프레임 드랍 직행

2️⃣ Destroy() – 가장 쉬운 삭제, 하지만 함정도 많음

Destroy(gameObject);

오브젝트를 완전히 삭제합니다.

Destroy(gameObject, 2f); // 2초 후 삭제

자주 쓰는 경우:

이펙트 정리
죽은 적 제거
임시 오브젝트 제거

문제는 여기서부터입니다

Destroy는 즉시 메모리에서 사라지는 게 아닙니다.
GC(가비지 컬렉션) 타이밍에 영향을 주고,
많이 쓰면 프레임 드랍의 원인이 됩니다.

그래서 실무에서는
“무조건 Destroy”는 잘 안 씁니다.

3️⃣ SetActive() – Destroy보다 더 자주 쓰이는 함수

gameObject.SetActive(false); gameObject.SetActive(true);

오브젝트를 삭제하지 않고
비활성화만 합니다.

주 사용 사례:

총알, 적 재사용
UI 열고 닫기
이펙트 관리

성능 관점에서는
Destroy보다 SetActive가 훨씬 안전한 선택인 경우가 많습니다.

4️⃣ Destroy vs SetActive 차이 (중요)

이건 꼭 한 번 정리하고 가야 합니다.

구분DestroySetActive

메모리	해제됨	유지됨
성능	비용 큼	비용 적음
재사용	불가	가능
사용 용도	완전 제거	임시 비활성

반복 생성/삭제되는 오브젝트라면
Destroy 대신 SetActive를 먼저 고민하는 게 좋습니다.

5️⃣ 오브젝트 풀링(Object Pooling)과 연결됨

여기까지 오면
자연스럽게 이 개념으로 이어집니다.

“그럼 미리 만들어두고 켜고 끄면 되겠네?”

맞습니다.
그래서 Unity에서는 오브젝트 풀링을 많이 씁니다.

기본 흐름:

게임 시작 시 오브젝트 여러 개 생성
필요할 때 SetActive(true)
사용 끝나면 SetActive(false)

Instantiate / Destroy 남용으로 인한
성능 문제를 해결하는 대표적인 패턴입니다.

6️⃣ transform으로 생성 직후 위치 조정

오브젝트 생성 후 거의 항상 같이 쓰입니다.

GameObject obj = Instantiate(prefab); obj.transform.position = spawnPosition;

또는 한 줄로:

Instantiate(prefab, spawnPosition, Quaternion.identity);

생성 + 위치 지정은 거의 세트라고 봐도 됩니다.

7️⃣ 부모 지정 (SetParent)

UI나 그룹 관리할 때 자주 씁니다.

obj.transform.SetParent(parentTransform);

주 사용 예:

UI 동적 생성
여러 오브젝트 묶어서 관리

정리해보면 이렇습니다

Unity에서 오브젝트 생성·삭제 관련해서
실제로 손이 가장 많이 가는 함수들은:

Instantiate
Destroy
SetActive
transform.position
SetParent

그리고 중요한 포인트 하나.

Destroy는 최후의 수단처럼 생각하는 게 좋습니다.

마무리

처음 Unity 할 때는
Instantiate / Destroy만 알아도 게임은 돌아갑니다.

하지만
조금만 규모가 커지면
성능 이슈가 바로 드러납니다.

이 글을 보고
“아, 이건 Destroy 말고 SetActive 써야겠네”
이 정도만 느껴졌다면 충분합니다.

Unity 라이프사이클 함수 한 번에 정리 (Awake, Start, Update)

daehwan2 — Wed, 4 Feb 2026 09:15:30 +0900

게임 만들다 보면 자연스럽게 외우게 되는 것들

Unity로 게임을 처음 만들기 시작하면
제일 먼저 마주치는 게 함수 이름들입니다.

Start, Update, OnCollisionEnter…
튜토리얼에서는 막 쓰라고 하는데,
막상 보면 이런 생각 들죠.

“이 함수는 언제 호출되는 거지?”
“이걸 왜 여기다 쓰는 거야?”
“Update에 다 때려 넣으면 안 되나…?”

저도 처음엔
일단 돌아가면 OK 마인드로 개발하다가
프레임 떨어지고, 버그 터지고 나서
그제야 함수 역할을 하나씩 이해하기 시작했습니다.

이 글에서는
Unity에서 정말 자주 쓰이는 함수들만
실제 사용 기준으로 정리해보겠습니다.

1️⃣ Start()

void Start() { }

스크립트가 활성화될 때 한 번 호출
초기화 용도로 가장 많이 사용

보통 여기서 하는 일:

변수 초기값 세팅
컴포넌트 참조 가져오기 (GetComponent)
시작 시 한 번만 실행될 로직

게임 시작 시 딱 한 번 실행하고 싶은 로직이면
대부분 Start()에 들어갑니다.

2️⃣ Update()

void Update() { }

매 프레임마다 호출
Unity에서 제일 많이 쓰이면서, 제일 위험한 함수

주 사용 용도:

키 입력 처리
캐릭터 이동
실시간 상태 체크

⚠️ 주의할 점
Update 안에 무거운 로직 넣으면
프레임 드랍 바로 옵니다.

3️⃣ FixedUpdate()

void FixedUpdate() { }

물리 연산 전용
일정한 시간 간격으로 호출

주로 쓰는 경우:

Rigidbody 이동
물리 기반 캐릭터 컨트롤

AddForce, velocity 조작은
Update 말고 FixedUpdate가 정석입니다.

4️⃣ LateUpdate()

void LateUpdate() { }

모든 Update가 끝난 뒤 실행
카메라 처리에서 자주 사용

대표적인 예:

캐릭터 따라오는 카메라
Update에서 변경된 값 기준 후처리

“다 끝난 다음에 처리해야 하는 것”은
LateUpdate가 딱 맞습니다.

5️⃣ OnCollisionEnter()

void OnCollisionEnter(Collision collision) { }

Collider + Rigidbody가 있을 때 충돌 발생 시 호출
물리 충돌 처리용

사용 예:

플레이어가 적과 부딪힘
벽에 닿았는지 체크

비슷한 함수들:

OnCollisionStay
OnCollisionExit

6️⃣ OnTriggerEnter()

void OnTriggerEnter(Collider other) { }

Trigger로 설정된 Collider 충돌 시 호출
물리 반응 없이 이벤트만 처리

주 사용 예:

아이템 획득
특정 구역 진입 체크
이벤트 트리거

이벤트용 충돌 = Trigger
이건 거의 공식처럼 쓰입니다.

7️⃣ Awake()

void Awake() { }

Start보다 먼저 호출
오브젝트 생성 직후 실행

주로 쓰는 경우:

싱글톤 패턴
다른 오브젝트보다 먼저 초기화해야 할 때

초기화 순서가 중요하면 Awake

8️⃣ OnEnable / OnDisable

void OnEnable() { } void OnDisable() { }

오브젝트 활성/비활성 시 호출

자주 쓰이는 상황:

이벤트 구독 / 해제
UI 열고 닫을 때 처리

UI 시스템 만들 때 생각보다 자주 쓰입니다.

정리하면 이렇게 외우면 편합니다

Awake: 제일 먼저
Start: 시작할 때 한 번
Update: 매 프레임
FixedUpdate: 물리
LateUpdate: 마무리
Collision / Trigger: 충돌 이벤트

처음엔 전부 외우려고 하지 말고
“아, 이럴 땐 이 함수구나” 정도만 감 잡아도 충분합니다.

마무리하며

Unity 개발하다 보면
이 함수들은 결국 몸에 익게 됩니다.

문제는
아무 생각 없이 쓰면
나중에 디버깅이 지옥이 된다는 점입니다.

이 글을 보고
“아 이건 Update에 넣으면 안 되겠네”
이 정도만 느껴져도 충분히 의미 있습니다.

리액트 개발자를 위한 Animated 설명

daehwan2 — Tue, 3 Feb 2026 09:13:35 +0900

“왜 써야 하는지부터, 언제 쓰면 안 되는지까지”

React Native를 하다 보면
한 번쯤은 Animated를 마주치게 됩니다.

공식 문서도 있고 예제도 많은데,
막상 써보려고 하면 이런 생각이 먼저 듭니다.

“이거… 왜 이렇게 어려워?”
“useState로 opacity 바꾸면 되는 거 아냐?”
“이걸 꼭 써야 해?”

저도 처음엔 Animated가 괜히 복잡한 API 같았고,
실제로 몇 번은 안 써도 될 곳에 억지로 쓰다가 코드만 더 꼬였던 적도 있습니다.

이 글에서는
리액트 개발자 기준에서 Animated를 왜 쓰는지, 언제 써야 하는지
최대한 사람 말로 정리해보려고 합니다.

Animated는 뭐 하는 놈인가?

한 줄로 요약하면 이겁니다.

“부드러운 애니메이션을 성능 저하 없이 처리하기 위한 도구”

일반적인 리액트 상태 변경(useState)으로도
opacity, translate 정도는 구현할 수 있습니다.

그런데 문제가 하나 있습니다.

프레임 드랍

특히 React Native에서는
JS 스레드가 바쁠 때 애니메이션까지 같이 돌리면
스크롤이 끊기거나 터치가 먹통이 되는 상황이 자주 나옵니다.

Animated는 이걸 해결하려고 만들어진 API입니다.

useState 애니메이션 vs Animated 차이

예를 들어 이런 코드가 있다고 해봅시다.

const [opacity, setOpacity] = useState(0);

setOpacity(1);

이건 즉시 값이 바뀌는 것이지
“부드럽게 변화”하는 건 아닙니다.

물론 setInterval이나 setTimeout으로 흉내는 낼 수 있지만
성능도 안 좋고, 코드도 지옥이 됩니다.

Animated는 이렇게 씁니다.

const opacity = useRef(new Animated.Value(0)).current;

Animated.timing(opacity, {
  toValue: 1,
  duration: 300,
  useNativeDriver: true,
}).start();

여기서 핵심은 이 옵션입니다.

useNativeDriver: true

이게 바로 Animated의 존재 이유입니다.

useNativeDriver가 중요한 이유

React Native 구조를 아주 단순하게 말하면:

JS 스레드: 로직, 상태, 네트워크
Native 스레드: 실제 화면 그리기

useNativeDriver: true를 쓰면
JS 스레드가 바빠도 애니메이션은 네이티브에서 계속 돌아갑니다

그래서:

스크롤 중에도 애니메이션이 끊기지 않고
터치 이벤트도 안정적으로 처리됩니다

이 차이가 실제 앱에서는 꽤 큽니다.

Animated를 써야 하는 대표적인 상황

제가 실제로 써보면서 느낀 기준은 이렇습니다.

✅ 써야 하는 경우

opacity, translate, scale 같은 연속적인 변화
스크롤 연동 애니메이션
모달, 바텀시트, 헤더 숨김/노출
사용자 체감이 중요한 인터랙션

❌ 굳이 안 써도 되는 경우

단순 show / hide
한 번만 바뀌는 UI 상태
성능 영향 없는 작은 UI

Animated는 만능이 아닙니다.
필요한 곳에만 쓰는 게 오히려 코드 품질이 좋아집니다.

Animated가 어렵게 느껴지는 이유

대부분 여기서 막힙니다.

Animated.Value
Animated.timing
interpolate
addListener

솔직히 말하면
API 설계가 직관적인 편은 아닙니다.

그래서 요즘은:

Reanimated
Moti
Gesture Handler

같은 라이브러리들이 더 많이 쓰이기도 합니다.

그럼에도 Animated를 알아야 하는 이유는 명확합니다.

기본 개념은 전부 Animated에서 시작했기 때문입니다.

결론: Animated를 이렇게 생각하면 편합니다

Animated는 “애니메이션용 상태 관리 도구”
성능이 중요한 순간에만 사용
모든 UI에 쓰려고 하지 말 것
이해 안 되면 interpolate부터 건너뛰어도 됨

처음엔 어렵게 느껴져도
한두 번 실제 문제를 해결해보면
“아, 이래서 쓰는구나” 하고 감이 옵니다.

저도 그랬습니다.

마무리

Animated는
리액트 개발자가 한 단계 올라갈 때 꼭 한 번은 부딪히는 벽 같은 존재입니다.

피할 수 있다면 피하고 싶지만,
한 번 넘어두면 이후 UI 구현이 훨씬 편해집니다.

이 글이
“Animated 써야 하나 말아야 하나” 고민하는 분들께
조금이라도 기준이 되었으면 좋겠습니다.

Sticky Header 터치 안됨 문제 해결 (React Native, 2026)

daehwan2 — Mon, 2 Feb 2026 10:57:24 +0900

React Native에서 스크롤 중 Sticky Header를 만들었는데,
버튼이 눌리지 않는 상황, 한 번쯤 겪으셨죠?

저도 한참 삽질했습니다.
화면에 분명히 버튼이 보이는데, 눌러도 반응이 없어요.
“코드가 잘못됐나?” → “라이브러리 버그인가?”
몇 시간 동안 고민한 끝에 원인을 찾았습니다.

결론부터 말하면,
Sticky Header 위에 다른 View가 겹치거나, 터치 이벤트를 막고 있는 경우가 대부분입니다.

1️⃣ 문제 상황 정리

FlatList / SectionList에 Sticky Header 적용
버튼, 아이콘 등 터치 컴포넌트 정상 배치
근데 눌러도 onPress 실행 안 됨
iOS는 되는데 Android에서만 안 되는 경우 있음

2️⃣ 원인 분석

1. 다른 View가 위에 겹쳐 있음

absolute 포지션 / zIndex 겹침
투명 View라도 터치 이벤트를 먼저 가져가면 막힘

2. ScrollView / FlatList 스크롤 이벤트와 충돌

FlatList가 Sticky Header를 관리할 때, ScrollView와 중첩되면 터치 이벤트 전달이 안 됨

3. Android zIndex 문제

iOS는 잘 되는데 Android에서는 elevation이 필요
zIndex만으로는 충분하지 않음

3️⃣ 해결 방법

① pointerEvents 사용

Sticky Header 외부 View에 pointerEvents="box-none" 적용
버튼이 눌리는 영역만 이벤트를 받도록 조정

② Android elevation 적용

style={{ zIndex: 10, elevation: 10, }}

Android에서 Sticky Header 버튼이 눌리지 않는 경우
zIndex + elevation 함께 적용 필요

③ ScrollView / FlatList 충돌 해결

ScrollView 안에 FlatList 넣지 않기
꼭 필요하면 FlatList keyboardShouldPersistTaps="handled" 적용

④ Debug: 투명 View 확인

배경색 잠깐 넣어보기

backgroundColor: 'rgba(255,0,0,0.2)'

눌러도 반응 없는 영역 확인 가능

4️⃣ 제가 보는 체크 순서

Sticky Header 버튼 안 눌릴 때:

다른 View가 겹치나? (absolute / zIndex)
Android면 elevation 적용했나?
ScrollView / FlatList 중첩 문제?
pointerEvents 조정 필요?

대부분 여기서 해결됩니다.

5️⃣ 마무리

Sticky Header 터치 안 되는 문제는
“코드 문제”보다는 레이아웃/스크롤 이벤트 문제인 경우가 많습니다.

저처럼 몇 시간 삽질하지 말고,
위 체크리스트대로 순서대로 확인하면 10분 안에 해결 가능합니다.

React Native onPress 안됨… 원인 찾느라 시간 날린 기록 (2026)

daehwan2 — Mon, 2 Feb 2026 07:36:58 +0900

React Native에서 FlatList를 쓰다 보면
스크롤은 되는데 터치가 안 되는 상황을 한 번쯤은 겪게 됩니다.

아이템을 눌러도 onPress가 안 찍히고,
“내 코드가 잘못된 건가?” 싶어서 한참을 들여다보게 되죠.

저도 처음엔
TouchableOpacity 문제인 줄 알았고,
그다음엔 상태값 문제인 줄 알았습니다.

근데 결론은 의외로 단순했습니다.
ScrollView랑 FlatList가 겹쳐 있었어요.

증상부터 정리해보면

이런 상황이었습니다.

FlatList는 잘 보임
위아래 스크롤도 정상
근데 아이템 클릭이 안 됨
콘솔 로그도 안 찍힘

특히 화면 끝까지 스크롤했을 때만 안 되는 경우도 있었고,
iOS에서는 되는데 Android에서만 안 되는 경우도 있었습니다.

이때 거의 대부분의 원인이
ScrollView + FlatList 중첩이었습니다.

가장 흔한 구조 (문제 있는 구조)

        <ScrollView>
          <View>
            <FlatList data={data} renderItem={renderItem} />
          </View>
        </ScrollView>

이 구조, 생각보다 많이 씁니다.

처음엔
“위에 다른 콘텐츠도 있고, 스크롤도 필요하니까”
자연스럽게 이렇게 짜게 되는데요.

이 상태에서 FlatList 안 터치가 먹통이 되는 경우가 많습니다.

왜 이런 문제가 생기냐면

ScrollView랑 FlatList는
둘 다 스크롤 제스처를 처리하는 컴포넌트입니다.

ScrollView가 위에 있으면:

터치 이벤트를 먼저 가져가고
FlatList 안 onPress까지 전달하지 않는 경우가 생깁니다.

특히:

position: absolute
sticky header
상단 고정 영역

이런 게 섞이면 더 잘 터집니다.

해결 방법 1️⃣ FlatList 단독으로 쓰기 (제일 깔끔)

가능하면 이게 제일 좋습니다.

    <FlatList
      ListHeaderComponent={<Header />}
      data={data}
      renderItem={renderItem}
    />

ScrollView 제거
FlatList 하나로 스크롤 통합

구조가 단순해지고
터치 문제도 같이 사라집니다.

해결 방법 2️⃣ keyboardShouldPersistTaps 설정

ScrollView를 꼭 써야 하는 상황이라면
이 옵션은 거의 필수입니다.

<ScrollView keyboardShouldPersistTaps="handled">

또는

keyboardShouldPersistTaps="always"

이걸 안 주면:

스크롤이 터치를 먼저 먹고
버튼 onPress가 실행 안 되는 경우가 많습니다.

해결 방법 3️⃣ FlatList 높이 명확히 주기

이건 은근히 많이 놓칩니다.

<FlatList style={{ flex: 1 }} />

또는

    <View style={{ height: 300 }}>
      <FlatList />
    </View>

FlatList의 높이가 애매하면
터치 영역 계산이 꼬이는 경우가 있습니다.

해결 방법 4️⃣ 투명 View가 덮고 있는지 확인

이건 진짜 많이 속습니다.

눈에 안 보이는 View
absolute 포지션
투명 배경

이런 게 위에 덮고 있으면
FlatList 터치는 전부 막힙니다.

제가 쓰는 확인 방법

backgroundColor: 'rgba(255,0,0,0.2)'

의심되는 View에 잠깐 넣어보면
“아 여기 있었네” 바로 보입니다.

iOS는 되는데 Android만 안 될 때

이 경우도 ScrollView 겹침 + zIndex 문제일 가능성이 큽니다.

Android에서는:

style={{
  zIndex: 10,
  elevation: 10,
}}

elevation 빠지면
터치 안 되는 경우 많습니다.

FlatList 터치 안 될 때 체크 순서 (이거만 봅니다)

문제 생기면 저는 이 순서로 봅니다.

ScrollView로 FlatList 감싸고 있나?
keyboardShouldPersistTaps 설정했나?
FlatList 높이가 애매하지 않나?
투명 View가 위에 덮고 있나?
Android면 elevation 빠졌나?

이 순서면
대부분 여기서 끝납니다.

마무리

FlatList 터치 안 되는 문제는
코드보다 레이아웃 구조 문제인 경우가 훨씬 많습니다.

특히:

ScrollView 안에 FlatList
고정 헤더
absolute 레이아웃

이 조합이면
한 번쯤은 꼭 터집니다.

지금도 같은 문제로 헤매고 있다면
ScrollView부터 한 번 의심해보세요.
생각보다 거기서 바로 해결될 수 있습니다.

뇽뇽이 - 66일 챌린지 소개 (습관앱 추천) - 1년 개발 후기

daehwan2 — Wed, 6 Aug 2025 11:13:05 +0900

서두

습관앱, 뇽뇽이 - 66일 챌린지 를 만든지도 벌써 1년이 지났다.

1년전, 책 "원씽" 을 읽다가 66일의 법칙을 알게되었다.

66일의 법칙은 새로운 행동을 습관으로 만드는데 대략 66일 정도 걸린다는 이론 이다. 해당 법칙을 서비스로 만들면 좋겠다고 생각했고 바로 행동으로 옮겼다. 처음에는 가장 기본적인 기능만 구현하고 바로 플레이 스토어 / 앱 스토어에 배포를 진행하였다.

그런 다음 매일 매일 조금씩 생각나는 기능들과 디자인적인 개선을 진행하였고 그러다보니 지금 1년 개발 후기 글을 작성하고 있다.

( 정말 빠르게 시간이 지나갔다 .. ! )

1년전에 간단한 기능만을 구현하여 배포를 진행하였을때도, 포스팅을 진행하였는데 혹시나 초기 앱의 화면이나

당시의 나의 생각이 궁금하다면 해당 포스팅을 읽어보길 바란다. https://program-note.tistory.com/46

앱 소개 및 기능

뇽뇽이 66일 챌린지 습관앱 - 홈, 습관 만들기, 습관 상세

뇽뇽이는 앞서 말했듯이 습관형성을 도와주는 앱이다.

습관을 형성할때는 습관명, 실패 조건일, 함께할 친구 이렇게 세가지를 설정할 수 있다.

세가지 지표가 어느정도 이해는 되겠지만, "실패 조건일" 의 경우 처음 접하면 이해하기 어려울 수 있어 예를 들어 보겠다!

ex)

실패조건일: 3일 - 마지막 체크로 부터 3일 안에 체크하지 않으면 실패함.

실패조건일: 1일 - 마지막 체크로 부터 1일 안에 체크하지 않으면 실패함. ( 즉 매일매일 실천할 항목일때만 설정해야 한다 ! )

습관앱, 뇽뇽이 - 66일 챌린지 에 커뮤니티 서비스 ( 피드 / 랭킹 / 뇽뇽 )

또한 뇽뇽이는 타 다른 습관 형성앱들과 다르게 커뮤니티의 성격을 가지고 있다.

관련된 서비스는 피드, 랭킹 그리고 뇽뇽이 꾸미기가 있다.

하나씩 간단한 설명을 해보겠다.

- 피드: 오늘 / 어제 유저들이 실천한 습관들을 보고 댓글과 좋아요를 달 수 있다. ( 비공개 / 친구만 공개 / 전체공개 설정이 가능하다.)

- 랭킹: 완료 습관과 진행 습관의 진행도 데이터로 순위를 매겨 TOP 50 유저를 볼 수 있다.

- 뇽뇽이 꾸미기: 이 기능에 대해서는 설명이 길어질 것 같아 아래에 적는다 !

습관앱, 뇽뇽이 66일 챌린지 - 코인 획득 조건

우선 "뇽뇽이" 는 앱의 대표 토끼 캐릭터 이다. 하단 메뉴바에서 "뇽뇽" 을 클릭하면 뇽뇽이를 꾸밀 수 있고

아이템들은 코인 을 이용하여 구매할 수 있다.

코인! 은 습관을 형성하면서 얻을 수 있는데, 획득 조건은 다음과 같다.

- 출석체크(앱에 접속시 1 코인)

- 습관 21일 완료시 21 코인

- 습관 66일 완료시 66 코인

21일은 습관을 뇌에 각인 시키는 단계이고 , 66일은 몸에 각인시키는 과정이라는 이론에 맞춰 획득 조건을 넣어 보았다.

뇽뇽이 아이템들은 계속해서 업데이트를 진행중이고 일주일에 하나씩은 꾸준히 올릴려고 하고 있다 !

( 실패조건일 10일로 설정해서 챌린지를 진행중이다 )

습관앱, 뇽뇽이 - 66일 챌린지 ( 통계 / 상점 )

그리고 나머지 기능으로는 통계 기능과 상점 기능이 있다.

통계에서는 달 별로 체크 일자를 그래프(?) 와 비슷한 시각적인 형태로 바로 볼 수 있다.

상점에는 현재 광고 제거, 실패 습관 살리기, 닉네임 변경권, 습관명 변경권 이렇게 네가지를 판매 중이고,

모두 유료 인앱 결제 형태로 되어 있다. 광고 제거와 실패 습관 살리기의 수요가 가장 많다.

다운로드 링크

플레이 스토어: https://play.google.com/store/apps/details?id=com.sixsixdaylaw

뇽뇽이 - 습관 만들기, 66일 챌린지 - Google Play 앱

뇽뇽이로 66일간 도전할 행동을 등록하여 습관을 만들어 보세요.

play.google.com

앱 스토어: https://apps.apple.com/us/app/%EB%87%BD%EB%87%BD%EC%9D%B4/id6664070484?platform=iphone

‎뇽뇽이

‎습관을 만들려면 얼마만의 시간이 필요할까요? 이와 관련된 연구 중 하나로 영국 런던대학(UCL)의 필리파 랠리 Phillippe Lally 교수 연구팀은 행동이 습관으로 자리 잡는 데는 66일이 걸린다는 ‘66

apps.apple.com

사용해주시는 유저분들에게

1년 동안 뇽뇽이를 사용해주신 모든 분들께 감사합니다.

유저분들이 잘 사용해주시고, 요청 및 기능 제안이 있었기에 계속해서 발전하고 성장할 수 있었던 것 같아요.

앞으로도 꾸준한 업데이트와 개선으로 더 나은 습관 형성 경험을 드릴 수 있도록 노력하겠습니다. 정말 감사합니다 ‍♂️

계속해서 잘부탁드려요 :)

문의 및 연락

인스타: https://www.instagram.com/66nyong_nyong

이메일: yournight0482@gmail.com

이펙티브 타입스크립트 스터디 - 1장

daehwan2 — Thu, 27 Feb 2025 16:33:43 +0900

이 글은 책 "이펙티브 타입스크립트" 스터디를 진행하면서 정리한 글이다.

본 글은 1장 타입스크립트 알아보기 까지를 정리한 글로,

해당 책을 읽기 위해서 사전에 이미 알고있어야 하는 개념 및 용어들을 먼저 정리하겠다.

용어 정리

- 덕 타이핑 ( Duck Typing )

객체의 실제 타입보다는 그 객체가 어떤 메서드나 속성을 가지고 있는지에 따라 동작을 결정하는 개념

즉, "새가 오리처럼 걷고, 오리처럼 꽥꽥거리면, 우리는 그것을 오리라고 부른다"

- 인터프리터 언어

코드를 한 줄씩 읽고 실행하는 방식의 프로그래밍 언어. python, javascript 등

- 컴파일

사람이 작성한 소스 코드(고급 언어) 를 기계어(저급 언어, 바이너리 코드)로 변환하는 과정.

- 트랜스파일

한 프로그래밍 언어를 같은 수준(고급 언어) 의 다른 언어로 변환하는 과정.

Typescript -> Javascript

- 런타임

프로그램이 실행되는 시간(환경)을 의미함. 실제로 프로그램이 실행되는 순간.

알고 있어야 하는 Typescript 문법 및 개념

interface
- 객체의 구조(타입)를 정의하는데 사용.
- extends 로 확장 가능 - 모든 속성과 메서드를 그대로 상속 받음.
- 같은 이름의 interface 끼리 자동 병합
type
class
등등.. 그냥 기본적인 타입스크립트 문법 및 사용법을 숙지한 상태여야지 책 자체가 이해가 될 것 같다.
타입 스크립트 핸드북 해당 사이트에 있는 개념을 모두 아는 상태로 이펙티브 타입스크립트 책을 읽으면 좋을 것 같다.

Introduction | 타입스크립트 핸드북

타입스크립트 핸드북 타입스크립트를 쉽고 재밌게 배울 수 있는 핸드북입니다 타입스크립트의 기본 개념부터 실전 프로젝트에 적용하는 방법까지 배워보실 수 있습니다. 이 핸드북은 인프

joshua1988.github.io

1장 타입스크립트 알아보기

아이템 1 타입스크립트와 자바스크립의 관계 이해하기

타입스크립트는 자바스크립트의 상위결합
타입스크립트는 타입이 정의된 자바스크립트의 상위집합이다.

모든 자바스크립트 프로그램은 이미 타입스크립트 프로그램이다.
타입체커를 통과했다고 해서 런타임 오류가 안나는 것은 아니다.
타입스크립트의 타입 시스템은 자바스크립트의 런타임 동작을 모델링한다.
- 즉 자바스크립트에서 문제가 업는 구문은 타입스크립트에서도 문제가 없다. ( 근데 문제가 되는 경우도 있다. )

아이템 2 타입스크립트 설정 이해하기

타입스크립트가 타입체크를 어떻게 할지는, 설정에 따라 다르다.
타입스크립트 설정 변경하는법
1. tsc 명령어 동작시 옵션 추가하기
  ex) tsc --noImplicitAny program.ts
2. tsconfig.json 파일 이용하기
  tsc --init 으로 생성 가능
  compilerOptions 에 설정 인자를 추가함으로 변경 가능.
설정의 종류
- 100가지가 넘음.
- noImplicitAny
  - 변수들이 미리 정의된 타입을 가져야 하는지에 대한 여부를 제어.
  - 타입 설정안하면 any 타입으로 간주. -> 암시적 any ( implict any )
  - 되도록이면 true 로 설정하자. 타입을 명시하는 습관을 들이자.
  - 설정해제는 언제하는게 좋을까 ? js 에서 ts 로 전환하는 경우 쓰면 유용하다!
    - -> 회사 프로젝트를 js 에서 ts 로 전환하였는데, 모든 설정을 켜놓고 전환해서 정말 힘들었던 기억이 있다.. 그 전에 이책을 읽었다면 좋았을텐데.. ㅎㅎ
- strictNullChecks
  - null 과 undefined 가 모든 타입에서 허용되는지 확인하는 설정
  - 해제시: 타입을 number 로 선언해도, undefined , null 로 할당이 가능
  - 이것도 되도록이면 설정을 키자!
  - 이걸 키려면 noImplicitAny 가 먼저 켜져있어야 한다.
- strict
  - 위 두가지 규칙을 포함한 대부분의 오류를 잡아주는 설정
  - 그냥 이걸 true 로 하고 프로젝트를 항상 시작하자!
    - 회사 프로젝트도 strict: true 로 마이그레이션을 했다..

noImplicitAny	any 타입이 암시적으로 지정되지 않도록 강제
strictNullChecks	null과 undefined를 정확히 체크
strictFunctionTypes	함수 타입 검사를 더 엄격하게 수행
strictPropertyInitialization	클래스의 속성이 생성자에서 반드시 초기화되도록 강제
strictBindCallApply	.bind(), .call(), .apply() 사용 시 타입 검사를 강화
alwaysStrict	파일에 자동으로 "use strict";를 추가하여 엄격한 JavaScript 모드를 활성화

* 참고: strict: true 시 켜지는 설정 ( chat gpt 가 정리잘해줬다. )

아이템 3 코드 생성과 타입이 관계없음을 이해하기

타입스크립트의 두가지 역할
- 최신 타입스크립트/자바스크립트를 브라우저에서 동작할 수 있도록 구버전의 자바스크립트로 트랜스파일 한다.
  - tsconfig.json 에서 compilerOptions.target 을 통해 어떤 버젼으로 트랜스파일링 할 것인지 정할 수 있다.
- 코드의 타입 오류를 체크한다.
위 두가지 역할은 완전히 독립적으로 행해진다.
타입 오류가 있는 코드도 컴파일이 가능하다.
- 여기서 컴파일 이라는 용어보다는 트랜스파일이란 용어가 더 정확해 보여서, 찾아보았다
- ✔ 엄밀한 표현 → "트랜스파일"
  ✔ 일반적인 표현 → "컴파일"이라고도 할 수 있음
  ✔ 공식적인 명칭 → TypeScript Compiler(tsc)
런타임에는 타입 체크가 불가하다.
- instance of 는 런타임에 일어나지만, interface 는 타입이기 때문에 아래와 같은 오류가 난다.
- 실제로 tsc 과정에서 모든 인페이스, 타입, 타입구문은 그냥 제거 된다.

class 는 값과 타입이 둘다 가능하다.
- 타입스크립트에서 class 는 런타임에는 값으로, 컴파일 시점에는 타입으로 동작한다.

타입 연산은 런타임에 영향을 주지 않는다.
런타임 타입은 선언된 타입과 다를 수 있다.
- ex) api 응답값 같은 경우, 미리 interface 로 약속된 타입을 선언해놓고 사용하지만, 실제로 그 응답값이 오는지는 알 수 없다.
타입스크립트 타입으로는 함수를 오버로드할 수 없다.
- 함수 오버로딩을 지원하지는 하지만 구현체가 하나 이다.
타입스크립트 타입은 런타임 성능에 영향을 주지 않는다.

아이템 4 구조적 타이핑에 익숙해지기

자바스크립트는 본질적으로 덕 타이핑 기반.
값을 할당할 때 정의된 타입에 필요한 속성을 가지고 있다면 호환된다. ( 구조적 타이핑 )
타입스크립트의 타입은 열려(open) 있다.
- *봉인된(sealed) 타입: 매개변수의 속성들이 매개변수의 타입에 선언된 속성만을 가지는 것.
- *열린(open) 타입: 위와 반대. 정의되지 않은 다른 매개변수가 있어도 무관.

테스트를 작성할때는 구조적 타이핑이 유리하다

아이템 5 any 타입 지양하기

any 타입에는 타입 안정성이 없다.
any는 함수 시그니처를 무시해 버린다.
any 타입에는 언어 서비스가 적용되지 않는다.
any 타입은 코드 리팩토링 때 버그를 감춘다
any는 타입 설계를 감춘다
an는 타입 시스템의 신뢰도를 떨어뜨린다.
그냥 쓰지 말자 !

2024, 3년차 프론트 개발자 회고

daehwan2 — Sun, 29 Dec 2024 23:38:55 +0900

벌써 2024년 이 지나가고 나는 올해 28살이 된다. 2022년 7월 4일에 입사를 한 이후로
어쩌다 보니 매년 회고록을 적고 있다. 올해 회고록은 사실 적을 생각이 딱히 없었는데,, 어쩌다가 남이 포스팅한 여러 회고록 글을 보게 되었고 읽으면서 나도 써야겠다는 마음을 먹고 노트북 앞에 앉았다. 글을 쓰기전에 작년 이맘때쯤 작성한 2023년 회고록 을 읽어보았다.

읽어보니 고민이 꽤나 많은 시기에 글을 작성한 것으로 보인다. 근데 저 당시 작성했던 걱정과 고민이 지금까지 이어져 오고 있다.

개인적인 이야기..

2024 년에는 개인적으로 많은 것이 바뀐 해다. 우선 이사를 진행해서 형이랑 10월부터 같이 살고 있다.
또한 정말 어릴때부터 해결하지 못한 집안일이 있는데 올해 10월에 이사를 하면서 해결이 되었다. 음 이 문제에 대해서는 평생 해결을 못할거라 생각하고 포기하며 살고 있었는데 생각보다 너무 간단하게 일이 끝나서 허무한 감정이 들었다.
이 집안일 때문에 옛날부터 많은 것을 포기하고 살았는데 이 문제가 간단하게 해결되고 나니.. 뭔가 공허했고 인생의 목표가 없어진 기분이었다..ㅋㅋ
아직까지도 조금 공허하고 마음을 다잡기 위해 노력중이다.

아무튼 ! 자세하게 적지는 않지만 거의 20년동안 해결하지 못한 문제가 해결되어 나에게는 정말 의미가 있는 한해였다.

회사 이야기

우선 2023년 회고글을 적을때와 같이 현재도 회사의 개발팀원은 나 포함 총 3명 ( 프론트 1, 백2 ) 이다. 여전히 이전에 사용하던 기술들을 활용하여 회사내 자체 서비스를 개발 및 유지보수하는 업무를 하고 있다. 업무 자체는 너무나도 익숙해져서 정말 편하게 진행하고 있다.

다만 요즘은 이직에 대한 고민이 있는데, 이직을 고민하는 이유는 다음과 같다.
첫번째는 회사 내 서비스( 직접적으로 서비스명을 밝히지는 못하겠다.. ) 가 방향을 잃은 것 같고, 그 방향을 잡아줄 사람이 없다고 느껴진다. PM 직책을 가진 팀장님이 계시지만, 현재 약 2년간 같이 근무를 했지만 앞으로 방향을 잡아서 나갈 수 있을까라는 의문이 든다. 시간이 지날수록 경영관리부의 전산팀의 업무를 더 많이 하고 계시는 것 같이 느껴진다.
개인적으로 느끼기에는 획기적인 기능 기획이나, 회사의 이윤을 창출하기 위한 기획, 계획등이 1년간 거의 없었다. 그냥 타 경쟁사가 새로운 기능을 내면 그 기능을 따라서 내는 정도의 기획을 내어 계속해서 그러한 작업만을 맡아 진행하고 있다. 그러다보니, 개발을 하는 입장에서 이게 진짜 필요한 기능인가? 좋은 기능인가? 좋은 기능이라면 이렇게 밖에 사용할 수 없나? 등의 기획 및 방향성에 대한 의문을 계속 가지게 되었다. 방향성 및 발전이 없을 것 같은 회사에서 계속 다녀도 되는가? 가 첫번째 이유다.

두번째는 개발팀 문화 및 프로젝트의 체계가 없어졌기 때문이다. 2022년에는 개발팀 문화 코드 리뷰, 코드 규칙, 컨벤션에 대한 규칙, 브랜치 관리 방법, 프로젝트에 대한 전반적인 매니징 등이 꽤나 체계적으로 잡혀 있었고 더 좋은 방식이 있을까? 모두가 고민하였다. 근데 현재는 그렇지 않다. 그 이유는 우선 기존에 있던 팀원들이 모두 이직을 하셨다. 그리고 기존에 없었던 PM 직책의 비개발자(옛날에 php 로 약간의 개발 경험이 있으신)분이 팀에 들어오셨고, 그 이후로 현재 업무를 진행중이신 백엔드 개발자 두분이 들어오셨다. PM 분은 코드리뷰와 같은 개발팀내 문화를 전혀 경험해 보시지 않으신 분이셨고, 개발 문화에 대해서 굳이 그걸 해야되냐는 마인드를 가지신 분이셨다. 그냥 빠르게 기능을 내는게 중요하다 라는 식의 마인드 셨고 그 분 입장에서는 기능만 충족하면 어떤 코드든 전혀 상관이 없었다. 그렇다고 해서 프로젝트 매니징을 잘하고 계신 것도 아니다. 그러한 영향인지 현재 백엔드 개발자분들은 코드리뷰라거나 코드내 규칙, 커밋 규칙 같은 것이 전혀 없는 상태이다. 그리고 나는 거의 1년 넘게 프론트 프로젝트를 혼자 관리하고 있어, 같이 코드를 공유할 인원이 없다.
물론, 현재 신입 프론트 개발자 채용을 하고 있다. 아마 1월 초쯤부터 새롭게 프론트 개발자분이 오실 것 같은데, 오시면 내 나름대로의 프론트 개발팀 문화를 만들어갈 예정이다. PM 분이 원하는 업무 방식은 아닐 것이기에.. 내가 잘 만들어갈 수 있을까 우려가 조금 된다. 아무튼 개발자로서의 성장을 잘 할 수 없는 회사가 아닌가? 라는 의문이 두번째 이유다.

머릿속에 있는 것을 그냥 그대로 적고 있는데, 어쩌다 보니 회사에 대한 불평과 불만을 많이 적게 되었다
전혀 의도하지 않았는데..

그렇다고 바로 현재 이직 준비를 바로 하고 있지는 않다. 아마 새로 프론트 개발자분이 오면 그 분과 같이 일하면서 많은 것을 경험하고 배우게 될 것 같기도 하고, 또 가고 싶은 회사가 있는 것도 아니기 때문이다. 막상 이직을 했는데 현재 회사보다 더 환경이 안좋을 수 도 있지 않을까 싶기도 하다. ( 실제로 이직한 다른 개발자 분들을 보면 그런 경우도 꽤 있는 것 같다. )

신입 개발자 면접관 후기

아 앞서 말한대로 이번에 신입 개발자 채용을 진행하였다. 현재 회사 프론트 개발자가 나 혼자 뿐이기 때문에, 당연히(?) 면접관으로 내가 들어가게 되었다. 제대로된 면접관으로 들어간 것은 거의 처음이라서 좋은 경험이였다. 신입, 3년차 경력분 등 해서 총 5명 정도 면접을 진행했었고 프로젝트 및 프론트 개념적인 질문을 많이 했었다. 준비를 거의 안해온 분들도 있었고 모든 질문에 대답을 잘하는 지원자도 있었다.

면접을 진행하면서 지원자분들의 개발에 대한 열정과 개발자라는 직업에 대한 생각, 그리고 본인이 어떻게 하면 개발자로서 더 성장할 수 있을까에 대한 생각들 등을 들을 수 있었다. 음.. 그걸 들으면서 나도 2년전만 해도 그러한 열정과 생각을 가지고 있었는데 지금은 좀 많이 약해진 것 같음을 느꼈다. 그래서 다시금 개발자에 대해 깊게 생각해 보았고 신입 개발자분이 오시면 그 분과 같은 열정과 마음가짐으로 개발을 진행할 것을 다짐하였다. 지금 시점에서 좋은 경험이였던 것 같다 !

사이드 프로젝트에 대하여

작년 회고글에도 적혀있듯이 원래 목표는 개인 앱 100개를 출시하여 소소한 부수입을 얻는 것이 목표였었다.
근데 갑자기 꾸준히 뭔가를 포기하지 않고 계속해서 앞으로 나가기만 하면 언젠가는 성공을 이룰 수 있을 것 같다는 생각이 들었다. 현재 회사에서 운영중인 서비스도 그렇다할 획기적인 발전이 있는 건 아닌데도 계속해서 돈을 벌고 있다. 그 이유가 포기하지 않고 꾸준히 팀원들이 매일 8시간씩 그 서비스에 대한 업무를 하고 있어서 그런게 아닌가 싶은 생각이 들었기 때문이다.

그래서 꾸준히 하나의 앱에만 집중을 할 계획을 세웠고 9월쯤 개발 및 기획을 시작해서 하나의 앱을 만들어서 IOS, Android 에 모두 배포하였다. 그 앱이 뇽뇽이 - 습관챌린지 앱이다. https://66daylaw.netlify.app/ 앱 소개 랜딩 페이지이다.

뇽뇽이 - 습관만들기, 66일 법칙

66daylaw.netlify.app

66일 챌린지를 실행할 수 있는 앱이고, expo 와 node.js 를 이용하여 개발을 진행하였다.
현재 활성 유저는 약 200명 정도 된다. 뇽뇽이 프로젝트에 대한 자세한 설명은 추 후 포스팅으로 미루겠다..

어쩌다보니 글이 너무 길어져서 ..

아무튼 일단은 2025년도 뇽뇽이 앱을 끊임없이 발전시켜서 수익을 창출해 낼 생각이다.

2024년 개발자로서 성장하였는가

음.. 회사 프로젝트에 완벽히 적응하면서, 회사 자체에서 개발자로서의 성장은 거의 없었다고 생각한다. 익숙한 언어와 구조내에서 혼자서 프론트 프로젝트를 관리하다 보니 그런 것 같다. 새로운 기술을 접하지 않다보니 그렇게 느껴지는 것 같다..
다만 사이드 프로젝트를 하면서 expo 와 node.js + express 로 서버 구축에 대해 자신감이 생겼고 조금 익숙해 졌다.
진짜 개발자로서의 성장에 대해 적으려니 적을게 없는 것 같다. 반성해야겠다..
2025년에는 테스트 코드를 작성한다거나 등 새로운 기술들을 많이 접해서 적을게 많도록 한해를 보내야겠다.

마무리

글을 쓰다보니 푸념만 엄청나게 늘어놓은 것 같다. 2025년에는 이러한 푸념들을 모두 해결하고 이겨낸 뒤에 회고록을 작성할 수 있게 보내야겠다. 그리고 뇽뇽이 활성유저 3000명을 만들겠다. 글을 작성하다보니 두시간이 넘어가서 집중력이 점점 없어지고 있는데, 뒤에 글들은 잘썼는지 모르겠다.. 얼른 마무리해야겠다.

다들 새해복 많이 받으세요. ‍♂️

뇽뇽이 - 습관 만들기 앱 , 66일 챌린지 앱을 만들었습니다.

daehwan2 — Sat, 5 Oct 2024 23:43:25 +0900

오랜만에 프로젝트 포스팅을 작성해본다.

3개월정도 진행중인 프로젝트이며, 계속해서 업데이트 해나가고 있다.

현재 안드로이드 ios 모두 배포되어 서비스를 진행중이다.

"원씽" 이라는 책에서 새로운 습관을 만드는 데는 평균 66일이 걸린다는 구절을 읽고 이걸 활용한 프로젝트를 진행해야겠다는 생각이 들었다.

책 원씽 중...

그래서 뇽뇽이 - 습관만들기, 66일 챌린지 를 만들어 보았다.

뇽뇽이 메인 로고

시중에도 비슷한 앱들이 있었지만, "습관 만들기" 라는 주제를 포기하고 싶지는 않았다.

그래서 챌린지 앱이면서 커뮤니티의 성격을 지니게 하여 다른 앱과의 차별점을 두기로 하였다.

처음에는 앱에 모든 부분을 혼자서 만들었었는데, 디자이너 한분을 어떻게 알게되어 도움을 받아 디자인 개선을 진행하였다.

그래서 지금은 디자이너 한 분이 앱을 사용해보면서, 디자인을 개선해주면 내가 적용하는 방식으로 작업을 하고 있다.

앱 화면은 다음과 같다.

기본 66일 챌린지 기능

커뮤니티성 기능

친구를 맺어, 피드에서 친구가 오늘 완료한 습관을 볼 수 있다.

친구 검색이 가능하며, 프로필을 꾸밀수도 있다.

이까지가 현재 개발되어 있다.

앞으로 업데이트를 진행할 기능들은

- 친구와 같이 66일 챌린지를 도전하는 기능

- 위젯 기능

정도가 있다.

업데이트 사항들은 인스타 피드로 업로드를 하고 있다.

다운링크와 인스타링크다.

혹시 친구와 같이 66일 챌린지를 도전하고 싶으신분들이 있다면 다운받아서 사용해보시기를 바란다.

인스타: https://www.instagram.com/66nyong_nyong/

안드로이드: https://play.google.com/store/apps/details?id=com.sixsixdaylaw

뇽뇽이 - 습관 만들기, 66일 챌린지 - Google Play 앱

뇽뇽이로 66일간 도전할 행동을 등록하여 습관을 만들어 보세요.

play.google.com

IOS: https://apps.apple.com/us/app/%EB%87%BD%EB%87%BD%EC%9D%B4/id6664070484?platform=iphone

‎뇽뇽이

apps.apple.com

+++ 개발적으로 어떤 기술 스택, 구조를 가졌는지는 추후 포스팅하겠다.

타이탄의 도구들 중.. 타인을 섬기는 사람이 가장 큰 것을 얻는다. 고찰

daehwan2 — Sun, 12 May 2024 00:08:23 +0900

요즘 책을 꾸준히 읽고 있다.

최근 읽고 있는 책은 팀 페리스의 "타이탄의 도구들" 이라는 책이다.

타이탄의 도구들

이 책에 21 섹션(?) "안태암불로가 되어라" 를 읽다가 지금 회사 생활과 앞으로의 인생에 도움이 될만한 많은 문장들이 있어

후기와 함께 좋은 글들을 남기려고 이렇게 노트북을 켰다!

21. 안태암불로가 되어라 섹션에 대해서 아주 간단하게 이야기하면 다음과 같다.

안태암불로는

옛 로마 제국에서 예술가들이 부유한 계층한테 후원을 받는 대신 길을 터주고 심부름을 하는 등 후원자의 생활 편의를 도모하는 역할중 하나를 말한다. 유명한 풍자시인인 마르티알리스도 안태암불로였다. 마르티알리스는 자신이 안태암불로라는 것에 불만이 있었지만, 풍자시로 유명해진 것 자체가 자신이 안태암불로였기 때문이였다.

즉, 자신이 안태암불로가 아니였다면 좋은 작품을 쓰지 못햇을 것이다.

여기서 깨달음을 얻은 팀페리스가 현대 사회생활에 적용할 수 있게 좋은 글들을 작성해준 섹션이다.

여기서 이제 막 사회생활을 시작한 젊은이들에게 꼭 숙지했으면 하는 세가지를 말한다.

세가지를 적어보겠다. 그리고 그 밑에 현재 내가 회사 생활하면서 느낀 것들을 파란색으로 적어보았다.

1. 당신은 당신이 생각하는 것만큼 유능하거나 중요한 인물이 아니다.

-> 이건 한 입사하고 1년이 지나서 깨달은 사실인 것 같다. 개발에 대해 자부심이 있었고 못만드는 건 없다는 생각을 가지고 있었다. 지금도 마찬가지긴하나 당시엔 그 능력 자체만으로 회사에는 내가 없으면 안된다는 생각을 하였었다. 하지만 그건 잘못된 생각이였다. 회사는 내가 없어도 잘 돌아갈거다. 나를 대체할 개발자는 많고, 나보다 더 나은 능력을 가진 개발자도 많다. 이 사실을 깨닫게 된 계기는 회사에서 가장 오래된 백엔드 개발자분이 이직을 하실때, 그 분이 없으면 회사 서비스가 안돌아갈 것 같았다. 하지만 생각보다 회사는 잘 돌아갔고 인력은 대체가 가능했다. 이 상황을 보고 나도 마찬가지이겠구나.. 생각하며 깨달았었다. 아무튼 지금은 잘 알고 있는 사실이 책에 있어 공감하며 읽었다!

2. 당신은 태도를 바꿀 필요가 있다.

-> 입사 당시와 현재 회사에 업무 환경 및 개발 문화가 많이 달라졌다. 이전 환경 및 업무 방식과 비교하며 최근 현재 업무 처리 방식에 대해 불만이 조금 생긴 상태였는데, 이를 해결할 생각은 못하고 혼자서 스트레스를 많이 받았었다. 스트레스만 받지 내가 뭔가를 하지 않으면 업무 처리 방식이 변경되지 않을 것이라는 생각을 하였었다. 그래서 이 환경에 대한 생각부터 긍정적이게 바꾸려고 노력을 하고 있고 그리고 업무에 대한 불만이 있으면, 이야기를 해서 서로 윈윈할 수 있는 환경을 만들기 위해 노력을 하고 있다. 그리고 태도도 바꾸었다.

하기 싫은 잡무라던가 뭔가 이게 개발자가 해야할 일이 맞나(?)라고 생각 되는 것들은 이전에는 ( 내가 하기 싫으면 다른 사람도 하기 싫을 것이라고 생각했기에 ) 하기는 했지만 웃으면서 하지는 못했었는데, 이제는 웃으면서 먼저 일을 하려고 한다. 그리고 꼭 개발 업무가 아니더라 열정과 의욕을 가지고 진심으로 모든 것을 하려고 태도를 바꾸었다. 이렇게 태도를 바꾸니 실제 모든 일을 할 때 이전보다 훨씬 재밌게 할 수 있음을 느꼈다.

3. 당신이 안다고 생각하는 사실들, 혹은 책이나 학교에서 배운 것들은 대부분 시대에 뒤떨어지거나 잘못된 것들이다.

-> 이거는 잘 공감이 안되지만, 항상 유연하게 새롭게 배울 준비를 하는 깨어있는 사람이 되어라는 의미로 받아들이고 있다.

그리고 책에서 구체적인 조언도 다섯가지 나오는데 다음과 같다.

이 조언은 책에서 말하는 타이탄(성공한 사람들)들이 전한 것이라고 한다.

1. 상사에게 넘겨줄 수 있는 아이디어를 찾아낸 사람은 누구보다 한 걸음 앞서간다.

2. 아이디어가 뛰어난 사람, 장래가 유망한 인재들은 서로 연결해준다.

3. 아무도 하고 싶어 하지 않는 일을 찾아서 그 일을 한다.

4. 비효율, 낭비, 중복이 많은 곳을 맨 먼저 찾아낸다. 그러면 나와 내 조직이 새로운 분야로 진출하는데 필요한 자원을 확보할 수 있다.

5. 자신의 아이디어를 기꺼이 공유한다.

다섯가지 모두 실천하도록 노력을 계속해서 해야겠다.

그리고 책에 명언(?)이 마지막에 적혀있는데 밑에 적으면서 글을 마무리 하겠다.

"위대한 사람은 언제나 순종할 준비가 되어 있다. 자신의 지휘 능력은 나중에 언제든 증명할 수 있기 때문이다."