Front

상사가 부당한 지시를 했을 경우 어떻게 하실 건가요?

뚜따따 — Tue, 22 Jul 2025 23:07:11 +0900

상사가 부당한 지시를 했을 경우 어떻게 하실 건가요?

면접관이 내게 물었다. 높지도 낮지 않은 톤으로 담담하게 말하는 그에게서 조금의 감정도 느껴지지 않았다.

"모든 지시에는 이유가 있다고 생각합니다. 부당하다고 생각하는 건 아직 제가 상사의 지시를 이해하지 못했기 때문이라고 생각하고, 먼저 지시를 따르겠습니다."

내 대답에 면접관은 고개를 몇 번 끄덕이고 다음 질문을 이어갔다. 맛도 향도 없는 질문이 계속되었다. 나는 무기적으로 대답했다. 경쾌하지 않은 문장들이 끈적하게 바닥에 쌓이고 있었다.

집으로 돌아가는 지하철에서 합격 문자를 받았다. 믿기지 않아 여러 번 다시 봤다. '합격했습니다. 처우 협의는... 출근 가능 시점은......' 떨어지는 게 당연하다 생각하는 마음에 문자가 장난처럼 느껴지기도 했다.
쉬었던만큼 초조했던 나는 그 말이 장난일까 초조해하며, 제발 장난이 아니길 바라며 답장했다. 빠르게 안 보내면 혹여나 놓칠까 성급하게, 그렇게 회사에 들어가게 됐다.

상사가 부당한 지시를 했을 경우 어떻게 하실 건가요?

무미건조한 줄 알았던 면접관이 팀장님이 된 지 1년이다. 그러다 알게 된 건 팀장님이 그렇게 건조한 사람이 아니란 것이다. 그는 사소한 것에도 환하게 잘 웃는 사람이었고, 울 때는 몰래 우는 사람이었다.
팀장님이 몰래 우는 걸 봤을 때는 많이 놀랐다. 부당함에 억울해서 몰래 우는 건 나 같은 주니어에게만 일어나는 일이 아니었다.

'상사가 부당한 지시를 했을 경우 어떻게 하실 건가요?' 면접 때 팀장님이 했던 그 질문.
팀장님이 나에게 묻는 말이지만 팀장님 스스로도 몰랐던 질문이 아닐까 지금은 생각한다.
팀장님은 부당하다 생각하고, 억울함을 참고 일하고 계셨다. 그건 '팀장님이 좋은 사람이어서', '어쩔 수 없는 환경 때문에' , 그런 이유들이겠지만, 주변을 의지하지 않으려는 팀장님의 성향때문이기도 하다.

혼자 창고에서 울고 있는 팀장님을 보았을 때, 나는 팀장님의 고민과 짐을 좀 덜어드리기 위해 노력했다. 하지만 나는 끝내 팀장님의 신뢰를 얻을 수 없었다. 그는 너무 오랫동안 혼자에 익숙했기에, 서비스의 AWS 엔 오직 그만이 허락됐다.

팀장님은 i am. 그 자체였다.

상사가 부당한 지시를 했을 경우 어떻게 해야 할까?

취업을 위해 그 질문에 대답을 고민할 때, 어떤 대답이 유리할지 생각하다 보니 내가 어떻게 생각하는지 잘 몰랐던 것 같다.하하나 확실해진 건, 부당함을 줄일 수 있는 방법은 ‘신뢰와 소통’이라는 것이다.

최근 힘든 일을 겪으며 내 감정을 더 소중히 해야 한다는 사실을 알게 됐다. 상대를 배려하는 건 나를 소중히 여기는 것에서부터 출발한다는 것을.

'상사가 부당한 지시를 했을 경우 어떻게 해야 할까?'

1년 전 내 대답을 종종 생각한다. 그러다 최근 문득 알았다. 애초에 그 질문은 나를 소홀히 여기는 질문이었다는 것을. 내가 내 존재를 스스로 회사 앞에 포기하라 유도하는 질문이었다는 것을.

힘든 시간 적절히 대하지 못해 미안했다. 내 감정아. 내 이성아.
너희 문제가 아닌 걸로 너희를 탓해야 했다.
우리 이제 점진적으로 덜 괴로워 보자.

누군가의 악의에 연연하지 말자.

고요

뚜따따 — Sun, 30 Mar 2025 23:55:08 +0900

아마도 고요.

소란스럽게 인생을 채우던 소음들을 기억한다.
사람에게서 사람으로 무수히 교차하는 소음 속에서
나는 외로웠던 나머지 그 소음을 꼭 끌어안았다.

이제 서른 개의 해가 나의 나이가 된다.

서른 살. 내 삶을 돌이켜보면 여러 색의 기억들이 가득하다. 누군가를 이해하거나, 누군가를 이해했다 착각하거나, 눈물을 흘리며 감사하는 걸 듣거나, 반대로 우는 걸 보거나, 사랑하고, 애정에 보답하며 행복하고, 사랑하고, 괴로워하고, 민폐를 끼치고, 반대로 민폐를 견디며, 때론 누군가 파놓은 악의에 스스로 빠져 허우적거리기도 했다. 그 모든 시간을 넘어 지금을 보내고 있는 나 자신에게 감사하다.
사지 하나 잃어버리지 않고(무려 4개나 있는데 그중 하나도 잃어버리지 않았다!) 건강하게 지금 여기에 있다는 것이 너무 감사하다.
어릴 적엔 내가 서른이 되면, 후줄근한 행색으로 너덜너덜해져 있을 거라 생각했다. 세상은 무척 가혹했고, 나는 삶의 경험을 대부분 회피에 투자한 망캐였다. 어떤 불화나 고통도 현실에서 한 발자국 멀리 떨어져 관찰하는 걸로 해결할 수 있었다. 적어도 그렇게 보였다. 그러다 언젠가 세상을 회피하는 버그가 발생하길 바랐다.
어쩌면 나는 남들보다 피부가 얇은 것 같다. 누군가의 기본적인 악의나 모순이 나에겐 유독 아팠다. 사람을 너무 좋아했고, 내 생각을 강요하는 걸 사랑이라고 생각(그럴 리가 없을텐데)하며, 그렇게 사람을 앓았다.
작은 상처에도 아픔을 느끼면서, 그걸 티내면 나를 싫어할까 두려웠던 나머지 현실을 외면하고 계속 외면하며, 스스로 만든 작은 상자 안에서 어린 시절을 보냈던 것 같다.

소란스럽게 인생을 채우던 소음들을 기억한다.
사람에게서 사람으로 무수히 교차하는 소음 속에서
내가 지금 어디에 있는지 깨달았다.

회피하는 삶을 끝내고 현실과 마주보기로 한 것에 특별한 계기가 있었던 건 아니다. 그냥 회피하던 나를 위해 누군가 대신 괴롭고 있다는 것을 서서히 알게 됐던 것 같다.

사실 내 피부가 얇건, 세상이 나에게 특히 가혹하던, 그런 건 전부 회피였을 뿐이다. 나는 그냥 이기적이고 겁이 많은 정신승리자였다. 후줄근한 행색으로 너덜너덜해져도 세상에 맞서지 않고 보신만을 생각하며 열심히 사는 것에 관심 없는 척할 뿐이었던 것이다.

이후 놓쳤던 것을 되찾기 위해 노력한지 1년이 지났다. 술을 줄이고, 담배를 끊었고, 취업을 했다. 예전만큼 혼자 괴롭지 않고, 의지할 줄 알게 됐다. 배려와 존중, 함께 자라는 즐거움을 알게 됐다. 개발자 커뮤니티에 들어가고 나서는 주변에 존경스러운 사람들이 늘었다. 사람과 사람 사이 소음이 일정하게 정돈되기 시작하더니, 여러 장르의 음악처럼 들렸다. 소음이라고 생각했다면 소음이었을 것들이었다.

소란스럽게 인생을 채우던 소음들을 기억한다.
소음 속에서도 고요하게, 고요하게

배불뚝이 서른 살이 된 지금 이젠 30년 가까이 항상 느끼던 '소음과 불안'보다 이번 달 가계부나 오늘 저녁 반찬, 여행 계획에 관심이 많아졌다. 또 이렇게 현실로 불려 와 보니 참담하고 숨이 턱턱 막힐 때도 있지만, 괜찮다. 정말 괜찮다. 내 삶을 매일 새롭게 만드는 행복들이 널려 있고, 어느 곳에 있어도 괴롭거나 우당탕탕 불안하지 않으니까. 요즈음 습관처럼 '평화롭다.'는 말을 자주 한다. 어렸을 적 상상하던 '후줄근하고 너덜너덜한 녀석'은 절대로 하지 않을 말이다. 볼이 빵빵해진 상태로 평화로운 아저씨가 된 지금, 아무래도 이런 내가 있도록 노력해 준 내가 고맙다. 운이 좋았다고 생각한다. 내 주변에 좋은 사람들 때문에, 좋은 사람이 되지 않고는 버틸 수 없었으니까. 떠밀리듯 좋은 사람이 되게 만들어 줬으니까.

함께 안 자랄 거임 (w.함께 자라기를 읽고)

뚜따따 — Sun, 16 Mar 2025 17:30:54 +0900

함께_자라기를_읽고

1. 책 소개

2. 자라기

3. 함께

4. 회사에서 함께 자라기를 적용해 보았다!

5. 마치며

1. 책 소개

눈에 편한 초록색을 사용한 것도 깊은 뜻이지 있을까?김창준선생님_짱

김창준의 함께 자라기

함께 자라기 | 김창준 - 교보문고

함께 자라기 | 모두가 함께 발전하기 위한 제안‘함께’는 협력을 말하고, ‘자라기’는 학습을 말합니다. 무엇이건 실제 바깥세상(야생)에 임팩트를 남기려면 혼자 힘으로만 되는 게 없습니다.

product.kyobobook.co.kr

먼저 이 자리를 빌려 이 책을 읽을 나비효과를 준 글또 커뮤니티에 감사하고, 책을 빌려준 FE 개발자(나는 그녀만큼 함께 자라기를 실천하는 사람을 알지 못한다)님께 감사의 마음을 전한다.

함께자라기는 개발 직업군뿐 아닌 대부분의 직업군을 관통하는 책이다. 내가 그렇게 생각하는 이유와 '함께 안 자랄 거임'이라며 요란한 커버로 잔뜩 후킹한 이유(죄송)에 대해 읽는 읽는 사람을 이해시킬 수 있는 글이 되었으면 좋겠다.

한 가지 분명한 건 함께 자라기는 아무 페이지나 펼쳐 읽어봐도 꾹꾹 눌러쓴 흔적이 있는 깊이가 있는 책이며,
그 책을 읽고 나는 조금 더 나은 내가 되었다는 것이다

문득 내가 이 책을 제외하곤 한번도 개발방법론에 대한 책을 완독해 본 적이 없다는 사실을 깨달았다. 그런 내가 이 책을 완독할 수 있었던 이유는 무엇일까?

❓ 함께 자라기가 다른 책이랑 뭐가 다른데?

함께 자라기는 자랑하지 않는다.
저자는 자신의 실패담(정말 실패담이다. 그런 실패를 통해 성공으로 이루어졌다~~! 가 아니라, '결과는 실패였습니다'로 끝나버린다.)을 예시로 제공하며, 반면교사하도록 둔다. 주로 방법론을 설명하는 책들은 '이런 방법이 도입했을 때의 장점.'에 관해 얘기를 하며 자신의 성공 시나리오를 제시하곤 하는데, 이 책엔 의미 없는 자랑이 없어 읽기 더 수월했다. ~~자랑을 들으면 킹받는다.~~

함께 자라기는 사람을 생각한다.

책에서는 에자일 방법론이 옳다고 얘기하는 게 아니라, 듣는 이의 성향에 따라 에자일 방법론의 장점을 설명하는 방법을 친절하게 알려준다. 책을 관통하는 주제가 사람이라는 것, 그리고 저자의 목적이 정말 함께 자라기라는 일관성이 보여 저자가 매력적으로 느껴졌고, 글에 설득력이 더 커졌다.

함께 자라기는 하나의 목표를 추구한다.

함께 자라기에서는 분명하고 고정적인 하나의 목표만을 추구한다. '어떻게 하면 함께 자랄 수 있을까?' 책은 처음부터 끝까지 내가 그렇게 하기를 바란다. 저자 스스로 함께 자라려는 마음이 담겨 있어 글에서 더욱 설득력을 느끼지 않았나 싶다.

2. 자라기

책은 자라기, 함께, 에자일 파트로 나뉘어 있고, 그중 자라기 파트에서는 액션 아이템으로 사용할 수 있는 여러 자라는 방법을 알려준다. 성장에 대한 당연한 말이 아닌, 성장하는 방법을 이건 어때? 저건 어때? 제시해 주는 게 사려 깊다고 느꼈다.

어떤 방법으로 성장할지 몰라 많이 준비했어

경험을 기반한 그 얘기들은 대단히 인사이트가 있었고, 그중 특히 인상 깊은 부분들을 추려봤다.

우리는 양치의 고수가 되지 못했음

'의도적 수련' 부분에서 저자는 '일만 시간의 법칙'이 사실이 아니라는 점을 명확히 지적하고 있다. 이미 이 법칙이 어느 정도 과장되었다는 것을 알고 있었는데, 저자가 이를 직접적으로 반박하는 내용을 언급해 살짝 만족감을 느꼈다~~.(네가 왜)~~

중요한 건 의도적 수련이다. 반복을 통해 성장하길 권장되는 건 수타면의 달인이나 헬스트레이너 정도일 것이다.

작은 화재라도 내지 않으면 큰 화재가 날 수도?

'실수는 예방하는 것이 아닌 관리하는 것이다.' 많은 함께 자라기를 읽은 사람이 그랬듯, 이 부분이 킥이었다. 화재를 예방하는 것보다 중요한 건 화재를 관리하는 것이다. 예전에 읽었던 요리에 대한 칼럼 중에 그런 부분이 있었다. '서로 다른 식재료를 조합해 보는 시도가 새로운 맛의 지평을 열 수 있다.' 이제 와서 너무 당연한 말이지만 '실수와 실패를 통해 성장할 수 있다.' 그 당연한 말이 좀 더 가슴에 와닿는 계기가 된 파트였다.

AI는 관련해서는...

'가장 학습하기 힘든 직업이 살아남는다' 파트에 관해선 지엽적이라는 생각을 좀 했다. '알파고나 AI 가 못하는 것이 모호한 영역이다.'라고 쓴 그 문맥은 충분히 이해하지만, 이제는 그렇게 자신할 수 없는 시대가 된 것 같다. 책이 써진 2019년에는 의심할 수 없었을 일이 현재 일어나고 있다는 생각이 좀 무서웠다. 책에 나온 모든 부분을 부정하는 건 아니다. 단지 '설득'과 '협상'의 분야에서 가끔 나는 AI의 자문을 구하곤 한다. 책에서 나온 '창의성'과 '문해력'까지는 학습하기 힘든 것 같지만, 그것도 자신할 수 없다. 조직이나 회사에서 저자의 말에 동의하지만 점점 '혼자' 할 수 있는 영역이 점점 늘어나고 있다는 의견에 대한 저자의 생각이 궁금했다. ~~(그래서 김창준 선생님의 블로그를 찾아봤는데 현재는 폐쇄되어 있었다. 힝)~~

불안하면 b2 나 b1으로 움직이시고요. 지루하면 a1이나 a2로 가시면 됩니다.

X축에 실력을 두고 Y축에 시간을 두면 내 그래프는 저 하늘을 뚫어!(으면 좋겠어!)

제곧내(제목이 곧 내용이란 뜻)

업무가 불안하면 실력을 올리던가 난이도를 낮추시고, 업무가 지루하면 난이도를 높이거나 실력을 낮춰서 몰입의 경지로 가세요. 그게 당신을 성장시킬 것입니다. (자세한 건 링크를 참고하세요.)

3. 함께

이 파트에서는 함께하기 위해서는 어떻게 해야 할지 알려준다. 나는 예전부터 책 한 권만 읽은 사람만큼 두려운 게 없다고 생각했는데, 이제 그 책이 함께 자라기면 괜찮을 것 같다는 생각이 든다. 그만큼 넓은 인사이트를 전하는 책이라는 뜻이다.

불확실성이 높을 때는 불가사리 구조 < 그물망 구조
경영학으로 봤을 때 팀과 작업 그룹은 다르고 작업 불확실성이 높을수록 팀이 유리하다는 정보가 유용했다.

팀이 유리한 이유

문제 해결 능력: 팀은 다양한 관점을 모아 복잡한 문제에 대응할 수 있다.
의사결정의 유연성: 불확실성이 클수록 빠른 의사결정이 중요한데, 팀은 구성원 간 긴밀한 협업을 통해 신속한 대응이 가능하다.
혁신과 창의성: 다양한 배경을 가진 구성원들이 아이디어를 공유하면서 혁신적인 해결책을 모색할 수 있다.
책임 공유: 팀원들이 공동의 목표를 지니고 있어, 실패의 부담을 분산시키고 적극적인 참여를 유도할 수 있다.

협력의 목표 -> 추상화. 대화는 기적이다.
협력의 목표를 추상화 개념으로 연결시킨 점도 인사이트가 있었다. 저자의 말대로 혼자서 할 수 있는 추상화에는 한계가 명백할 것이다.

이 파트를 읽고 떠오른 건 Gan( Generative Adversarial Networks)에서 AI를 학습시키는 방법이다.

초등학생도_이해_가능한_GAN_출처_하단_첨부

대학 때 배웠던 내용이었는데, AI 끼리 협력의 방식으로 학습 정확도를 높이는 방법이다.
쉽게 말하면 위조지폐 만드는 AI 랑 그걸 판별하는 AI를 두고 판별 못할 때까지 다시 만들라고 하는 AI인데, 이런 방식도 협력의 중요성에서 착안된 게 아닐까 마인드스토밍을 했다.

상대의 콧대를 납작하게 만들어 승리하는 세계관은 협력사회에 없다.
신뢰를 위한 소통 파트에서 살짝 나온 말을 각색한 부분인데, 내가 책에서 느낀 부분 중 가장 날카롭게 와닿았던 파트인 것 같다. 올바름을 관철하는 것. 이 얼마나 오만한 일이었는지를 책을 읽고 알게 됐다. 어떤 자료나 정보로 상대를 설득하는 게 아니라, 그 사람이 어떤 사람인지 이해하는 것부터 시작하는 게 중요했다. 그리고 우연히도, 이 책을 액션 아이템으로 할 기회가 나에게는 많았다. 실제로 나만의 함께 자라기를 실천한 사례를 아래 설명하겠다.

4. 회사에서 함께 자라기를 적용해 보았다!

지금 다니고 있는 회사는 대단히 자그마한 회사이다. 그래서 IT 회사라고는 이해할 수 없었던 일들이 하루에 과장 없이 한 두 번씩 일어나곤 한다. 초반에는 많이 놀라웠다.
(ex. 장고가 파이썬 2.x 버전을 사용하는데, 문서화된 게 하나도 없어 부딪혀 보며 알아야 했다. 추후 내가 문서화)

(ex. 배포될 때 css 캐시 무효화가 되지 않고 있어, Bitbuckit에서 코드를 Ctrl c + v 해야 했다. 추후 내가 고도화)
(ex. PR 올리면 리뷰 없이 100 % 머지된다. 왜 PR을 하는지 아직도 의문이다)

(ex. AWS 계정을 1년째 못 받고 있다. 팀장은 IAM을 알고 있지만,,, 아직 나에 대한 신뢰가 부족한가 보다)

(ex. 파일 업로드 기능을 공통화하지 않고 계속 복사하고 붙여 넣어, 600 줄 이상의 key 만 바꾼 코드가 기능마다 들어가 있었다. 추후 내가 공통화)

~~등등... 말하다 보니 후련해져서 계속 말하는 저를 이해해 주세요.~~

이런 부분들보다 내 위장을 아프게 하는 건 소통 없이 일이 진행되는 경우가 많다는 것이다. 다음은 내가 함께 자라기를 실천하게 된 배경이다.

1. 육아휴직 기간이 끝난 G님이 복귀하셨다. 그녀는 이 회사가 첫 회사이고 3년 차이다.
2. G님이 내가 만든 서비스에 합류하셨다.
3. G님이 서비스 디자인을 개편하면서 내가 만든 기능의 디자인을 수정했다.
(나는 전달받지 못했다. 커밋 메시지는 'rebase 전 commit'으로 되어 있었다)
4. 특정 상황에서 버튼이 활성화되지 않아 기능이 동작하지 않게 됐다. (뒤늦게 라이브에서 발견)

내가 유지보수와 가독성을 더 생각했다면 위와 같은 문제를 막을 수 있을 것 같다는 생각은 한다. ~~하지만 분기되어 있는 게 어떤 기능인지 몰라 지우는 건 악의가 아닐까 하는 생각이 더 크다.~~

이런 비슷한 상황이 계속 반복되었다. 그때는 옥상에서 살려달라고 소리라도 지르고 싶었다.

더 큰 문제는 그 상황에 대해 말씀드렸을 때 G님의 태도였다. '이건 기획이 이상하다.' '나는 몰랐다.' '초록님(나)은 너무 코드에 대한 장인정신이 크다' '고객을 먼저 생각해야 한다.'

그런 요즈음, 함께 자라기를 회사에서 실천하기로 했다. G님과 미팅을 잡았고, 생각보다 둘 사이 앙금을 많이 풀 수 있었다.

1. 그녀는 부족한 실력을 만회하고자 뭐라도 했어야 했고,
2. 내가 너무 공격적이라고 느껴졌으며
3. 소통을 거부하는 줄 알았다고 한다.

G님은 내가 공격적으로 했기에 본인도 공격적으로 나올 수밖에 없었다는 것을 재차 강조했다. 나는 내가 장인 정신이 부족한 사람인 것을 확실하게 전하며, 추후 commit 형식과 디자인과 기획서로 먼저 전달받을 것을 약속했다.

이렇게 대화로 잘 풀어나갈 수 있었던 건, 이전과 달리 내가 한 명의 사람으로서 G님을 보려고 한 덕분이었다.

확실한 건 그날 이후 회사 다니는 스트레스가 정말 많이 줄었다는 것이다.

싸워야 하는 사람은 사라지고 내 편이 한 명 더 늘었기 때문에.

5. 마치며

현재 내가 다니는 회사는 단적으로 함께 자라기를 할 수 없는 회사다. 팀원 구성은 안드로이드 팀 1명, FE 2명(나 + G님), 윈도우 개발자 1명과 서비스의 모든 것을 혼자 만드신 팀장님이 계신다.(그는 너무 뛰어난 나머지 윈도우와 안드와 리액트와 BE와 임베디드까지 모조리 혼자 하셨습니다.) 그중 협업에 대해 가장 경험이 많은 게 놀랍게도 3년 차인 나이다. 그들과 함께하고 싶어 노력하고 실패했던 여러 과정들이 스트레스였었는데, 함께 자라기를 읽고 회사에서 적용해 보며 한 사람의 사람으로서 그들을 이해할 수 있었다. 놀라운 건 그러자 그들도 나를 한 사람의 사람으로 봐주었단 것이다. 언제부턴가 나도 모르게 그들의 콧대를 누를 생각을 하지 않았나 싶다.

책은 함께 자라는 방법과, 실제 사례와 연구를 보여준다. 그러나 그걸 습득하고 적용하는 건 언제나 나이다.

함께 자라기 위해서 혼자 자라는 것. 그것이 내가 책을 읽으며 얻은 가장 큰 가르침이다.
~~(후킹을 위해서였다는 것도 부정할 수 없다)~~ 진인사대천명. 함께 자라고 싶은 매력적인 개발자가 될 테야!

도움받은 글

[출처] 함께자라기 리뷰들

[독후감] 함께 자라기 - 신입 개발자의 포부를 곁들인

함께 자라기 책을 읽고, 프론트엔드 개발자로서 어떻게 일해야 동료와 함께 성장하며, 일을 잘 할 수 있을까 고민을 정리했습니다.

velog.io

현재 상황을 어떻게 타파할까? 근 몇주간 (이제 신입 핑계 댈 수 없는) 2년차 개발자의 고민

1월 초중순부터 현재까지, 그리고 앞으로 몇달간 바빴고, 바쁘고, 바쁠 예정입니다. 정신없이 달려가는 와중에 현재의 어려움을 기록하고 이를 어떻게 타파하는 게 좋을지를 주제로 글을 써야겠

velog.io

혼자 자라면 풀, 함께 자라면 숲! - "함께 자라기"를 읽고

자! 자라고, 함께 성장하자! 요즘 글또 10기 활동을 하면서 성윤님 추천으로 '함께 자라기' 책을 알게 되었어요! (개발자들 사이에서는 이미 유명한 책이라고 하더라고요! )평소에 함께 성장하

develop-ssooo.tistory.com

[출처] [초등학생도 이해하는 AI] GAN, 서로 싸우면서 데이터를 생성한다. Generative Adversarial Networks

[초등학생도 이해하는 AI] GAN, 서로 싸우면서 데이터를 생성한다. Generative Adversarial Networks

GAN은 '생성자'와 '판별자'로 구성되며 이들을 적대적으로 학습시킵니다. 결국 &#x...

blog.naver.com

프로그래머스 - N개의 최소공배수

뚜따따 — Sun, 2 Mar 2025 23:20:11 +0900

프로그래머스 - N개의 최소공배수난이도

프로그래머스 - N개의 최소공배수

난이도 : Level 2
정답률: 67%

https://school.programmers.co.kr/learn/courses/30/lessons/12953

프로그래머스

SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

▶ 문제

▶ 풀이

function solution(arr) {
    let answer = 0;
    

    let n = 1
    let flag = true;
    while(flag)
    {
        n++;
        for(let i = 1; i < arr.length; ++i){
            if((arr[0] * n) % arr[i]  === 0){
                flag = false;
            } else {
                flag = true;
                break;
            }
        }
    }
    answer = arr[0] * n;
    return answer;
}

한 숫자를 곱하고 남은 나머지의 값이 모두 0으로 떨어지면 모든 값의 최소공배수가 구해질 거라고 생각하고 코드를 짰다.

이렇게 짤 경우 최소공배수의 값이 클수록 while 루프가 오래 반복되므로 시간이 기하급수적으로 증가할 수 있다.

▶ 다른 사람의 풀이(좋은 풀이)

// 또 다른 풀이
function getGcd(a, b) {
  if (b === 0) return a;
  return getGcd(b, a % b);
}

function solution(arr) {
  return arr.reduce((a, b) => (a * b) / getGcd(a, b));
}

(유클리드 호제법을 이용한 풀이)

이 풀이의 빅오표기는 O(N log M) 이다.

알기 쉽게 내가 짠 코드와 비교하면 다음과 같다.

입력 배열	유클리드 방법	내가 짠 코드
[2, 3]	O(1)	O(6)
[2, 3, 4]	O(1)	O(12)
[2, 3, 5, 7, 11]	O(log M)	O(2310[모든 수의 곱]) (매우 비효율적)
[10, 15, 20, 25, 30]	O(log M)	O(300) (매우 비효율적)

유클리드 방법은 log 시간에 해결 가능 (훨씬 빠르다!)

▶ 유클리드 호재법이란?

유클리드 호제법(Euclidean Algorithm)은 두 수의 최대공약수(GCD, Greatest Common Divisor)를 구하는 효율적인 알고리즘이다. 그 성능이 어마어마하게 떠오

유클리드 호재법의 원리

두 자연수 AA와 BB (A>BA > B)가 있을 때,

AA를 BB로 나눈 나머지를 구한다.
만약 나머지가 0이면 BB가 최대공약수(GCD)이다.
나머지가 0이 아니라면, AA를 BB로, BB를 나머지로 바꾸고 1번 과정을 반복한다.

example)
1071과 1029의 최대공약수를 구한다고 하면,

1071은 1029로 나누어 떨어지지 않기 때문에, 1071을 1029로 나눈 나머지를 구한다. ==> 나머지는 42 이다.

나머지가 42 니까 1029는 42로 나누어 떨어지지 않기 때문에, 1029를 42로 나눈 나머지를 구한다. ==> 나머지는 42 이다.
나머지가 21 이면 42는 21로 나누어 떨어진다.
따라서, 최대공약수는 21이다.

이제 당신도, 최대공약수 마스터이다!

▶ 느낀점

유클리드 호재법의 시작은 기원전 300년경 고대 그리스 수학자 유클리드부터라고 한다. 그 얘길 듣고 고등학교 선생님이 이제 된 친구의 얘기가 떠올랐다. 우리나라에 수포자가 많은 이유는 수학이란 과목만은 지름길이 없기 때문이라고 한다.

국어나 사회, 과학, 영어는 중간부터 공부한다고 해도 따라갈 순 있지만, 수학의 경우에는 덧셈을 모를 경우 곱셈을 알려줄 수 없고, 곱셈을 모르는 아이한테 방정식을 알려줄 수 없다고 한다.

그 말이 참 맞는 말이라는 생각이 들었던 게 내가 개포자(개발포기자) 라고 스스로 생각했던 시기가 그랬던 것 같다.

JS의 동작 원리도 제대로 모르는 상태로 리액트와 vue 부터 접했으니, 새로운 기술이 생긴 배경도 모른체 따라하는 코더가 되며 개발에 흥미를 잃었던 것이다.

평생 가야할 길에서는 지름길이 더 느릴 수도 있다는 생각이 든다. 탄탄하게 나아가자.

나는 마침내 BFS 와 DFS 를 이해했다.

뚜따따 — Sun, 16 Feb 2025 18:12:45 +0900

~~제목이 곧 내용입니다~~

차례

0. 시작하며
1. DFS와 BFS 가 먼데?
2. 그래서 이걸 언제 사용하는데?

3. 그래서 이걸 어떻게 사용하는데?

4. 마치며

0. 시작하며

이 글의 목적은 BFS와 DFS 가 뭔지 1도 모르는 사람에게 아주 아주 기초 사전 지식만 있으면 이해할 수 있도록 쓰려고 노력했다. 단순히 이해를 넘어, 이거 그래서 개발생활에 어떤 문제에서 쓸 수 있는지를 코테를 통해 설명하고자 한다.

완벽하게 이해할 필요 없이 '오, 그렇군?' 정도만 생각하고 넘어갈 수 있어도 좋을 것 같다. 이거 하나는 내가 확신한다.

나도 이해한 BFS와 DFS, 너도 이해할 수 있어!!

1. DFS 와 BFS 가 뭔데?

DFS(Depth-First Search)와 BFS(Breadth-First Search)는 그래프 탐색 알고리즘이다.

그래프는 이런 녀석이다.

그래프다.

0은 1과, 3과 4와 이어져 있고,

1은 0과 2와 이어져 있고,

3은 0과 2와 이어져 있고,

4는 0과 이어져 있고,

5는 4워 이어져 있다.

이걸 JS로 표현하면 다음과 같다.

const graph = [[1, 3, 4], [0, 2], [1, 3], [0, 2], [0, 5], [4]]; // ~~알아보기 어렵다~~

DFS와 BFS는 이렇게 생긴 그래프를 탐색하는 방법이다. 아래 그림처럼 움직인다고 보면 된다.

이렇게 탐색하는 것이다! 출처: 꺼무위키

DFS는 Deep 하게 탐색하는 녀석이라 쭉쭉 아래부터 간다.

BFS는 Breadth(너비)로 탐색하는 녀석이라 같은 정점을 바라보는 녀석부터 찾는 게 특징이다.

2. 그래서 이걸 언제 사용하는데?

	DFS	BFS
탐색 방식	깊이 우선(깊게 탐색 후 백트래킹)	너비 우선(가까운 노드부터 탐색)
최단 경로 탐색	❌	✅
시간 복잡도	O(V + E) (V: 노드 수, E: 간선 숫자)	O(V + E) (V: 노드 수, E: 간선 숫자)
사용 예시	백트래킹, 체스	최단 거리 문제, 네트워크 탐색

DFS는 각 정점에 숫자가 적혀있고 a부터 b까지 가는 경로를 구하는데 경로에 같은 숫자가 있으면 안 된다는 문제 등, 각각의 경로마다 조건을 저장해야 할 때 쓰기에 알맞다. 표에 예시에 나온 백트래킹이란 경우의 수를 탐색하면서, 불가능한 경우를 제외(Pruning)하는 탐색 기법인데, BFS에서는 경로마다 특징을 가지지 못해, DFS를 사용하는 게 유리하다.

BFS는 하나의 정점을 바라보는 녀석부터 탐색하기 때문에, 가장 가까운 녀석 찾거나 할 때 유리하다.

3. 그래서 이걸 어떻게 사용하는데?

먼저 기본적인 BFS와 DFS의 js 코드를 여기서 긁어왔다.

~~(내 글이 이해가 안 가면 저 블로그를 보세요, 저기가 더 잘 설명한 듯)~~

DFS 구현 함수

// graph 자료구조와 startNode를 입력
const DFS = (graph, startNode) => {
  const visited = []; // 탐색을 마친 노드들
  let needVisit = []; // 탐색해야할 노드들

  needVisit.push(startNode); // 노드 탐색 시작

  while (needVisit.length !== 0) { // 탐색해야할 노드가 남아있다면
    const node = needVisit.shift(); // queue이기 때문에 선입선출, shift()를 사용한다.
    if (!visited.includes(node)) { // 해당 노드가 탐색된 적 없다면
      visited.push(node); 
      needVisit = [...graph[node], ...needVisit];
    }
  }
  return visited;
};

BFS 구현 함수

// graph 자료구조와 startNode를 입력
const BFS = (graph, startNode) => {
  let visited = []; // 탐색을 마친 노드들
  let needVisit = []; // 탐색해야할 노드들

  needVisit.push(startNode); // 노드 탐색 시작

  while (needVisit.length !== 0) { // 탐색해야할 노드가 남아있다면
    const node = needVisit.shift(); // 가장 오래 남아있던 정점을 뽑아냄.
    if (!visited.includes(node)) { // 해당 노드 방문이 처음이라면,
      visited.push(node); 
      needVisit = [...needVisit, ...graph[node]];
    }
  }
  return visited;
};

그럼 이제 문제를 통해 BFS와 DFS를 활용해 보자.
https://school.programmers.co.kr/learn/courses/30/lessons/43163?language=javascript

프로그래머스

SW개발자를 위한 평가, 교육, 채용까지 Total Solution을 제공하는 개발자 성장을 위한 베이스캠프

programmers.co.kr

문제 정의는 이렇다.

두 개의 단어 begin, target과 단어의 집합 words가 있습니다. 아래와 같은 규칙을 이용하여 begin에서 target으로 변환하는 가장 짧은 변환 과정을 찾으려고 합니다.

1. 한 번에 한 개의 알파벳만 바꿀 수 있습니다.
2. words에 있는 단어로만 변환할 수 있습니다.

예를 들어 begin이 "hit", target가 "cog", words가 ["hot", "dot", "dog", "lot", "log", "cog"]라면 "hit" -> "hot" -> "dot" -> "dog" -> "cog"와 같이 4단계를 거쳐 변환할 수 있습니다.

두 개의 단어 begin, target과 단어의 집합 words가 매개변수로 주어질 때, 최소 몇 단계의 과정을 거쳐 begin을 target으로 변환할 수 있는지 return 하도록 solution 함수를 작성해 주세요.

제한사항

각 단어는 알파벳 소문자로만 이루어져 있습니다.
각 단어의 길이는 3 이상 10 이하이며 모든 단어의 길이는 같습니다.
words에는 3개 이상 50개 이하의 단어가 있으며 중복되는 단어는 없습니다.
begin과 target은 같지 않습니다.
변환할 수 없는 경우에는 0을 return 합니다.

입출력 예

begin	target	words	return
"hit"	"cog"	["hot", "dot", "dog", "lot", "log", "cog"]	4
"hit"	"cog"	["hot", "dot", "dog", "lot", "log"]	0

입출력 예 설명

예제 #1
문제에 나온 예와 같습니다.

예제 #2
target인 "cog"는 words 안에 없기 때문에 변환할 수 없습니다.

'어라? 이게 왜 BFS / DFS로 푸는 거지?' 싶었다. 어떻게 그래프를 그려야 하는지도 모를 거다. ~~나도 잘 모르겠다.~~

일단 그래프부터 그려보자! 문제에서 주어진 words 배열의 각 원소 사이에는 연결 관계가 없지만, 다른 노드에 방문하는 조건이 있다. 바로 '한 글자'가 다를 때 방문한다는 것이다.

어라? 그러면, 'hit'라는 단어와 words 들 사이를 연결할 수 있을 것 같다. 한 글자가 다른 것들은 사실 다음 방문지라고 생각해도 되니까!

어라? 그리고 이거, '가장 짧은 변환 과정'이네? 그렇다면 최단 거리를 찾는 문제니 BFS를 사용해야겠다!!

가장 짧은 변환 과정이래! BFS 다!

정정...ㅠ

*최단 거리를 찾을 때 BFS 가 맞으나, 다시 생각해 보니 위 문제 같은 경우, 어차피 정점이 정해져 있고 한 단어씩 바꾸는 거라 '최단 거리' 워딩과 다르게 DFS를 사용해도 괜찮았을 문제였을 것 같다. BFS와 DFS를 설명하기에 애매한 코태를 선정한 것 같다ㅠ 읽는 여러분은 글자에 현혹되어 저처럼 실수하지 마세요ㅠㅠ

오호라! 그렇다면 BFS 코드에 그대로 집어넣으면 되겠다!

function solution(begin, target, words) {
  const visited = { [begin] : 0 }; // init 값 푸시를 그냥 바로 했다.
  const needVisit  = [begin]; // 얘가 queue 다

  while(needVisit.length) {
    const node = needVisit.shift(); // 가장 오래된 녀석 꺼냄
    if(node === target) break;
    for(const word of words) {
      if(!visited[word]) { // 해당 노드 방문이 처음이라면
        visited[word] = visited[node] + 1; // 몇 번째인지 순서를 적어두자!
        needVisit.push(word);
      }
    }
  }
  return visited[target] ? visited[target] : 0; // 없으면 0 return 해야 하니까!
}

앗! 그런데, 이동할 수 있는 조건이 제한되었었잖아? 글자 중 하나만 같을 경우 호출하도록 조건이 추가되어야겠다!

// 글자중 하나만 같을 경우 호출 (왜냐면 이게 사실상 연결된 노드니까!)
const canTransfer = (str1, str2) => {
  let count = 0;
  for (let i = 0; i < str1.length; i++) {
    if (str1[i] !== str2[i]) count++;
    if (count > 1) return false;
  }
  
  return count === 1;
};

그럼 이렇게 하면 되겠다!

최종 코드

function solution(begin, target, words) {
  const visited = { [begin] : 0 };
  const needVisit  = [begin];

  while(needVisit.length) {
    const node = needVisit.shift();
    if(node === target) break;
    for(const word of words) {
      if(canTransfer(word, node) && !visited[word]) { // 방문되는 녀석 중 해당 노드 방문이 처음이라면
        visited[word] = visited[node] + 1;
        needVisit.push(word);
      }
    }
  }
  return visited[target] ? visited[target] : 0;
}

// 글자중 하나만 같을 경우 호출 (왜냐면 이게 사실상 연결된 노드니까!)
const canTransfer = (str1, str2) => {
  let count = 0;
  for (let i = 0; i < str1.length; i++) {
    if (str1[i] !== str2[i]) count++;
    if (count > 1) return false;
  }
  
  return count === 1;
};

방문 조건을 추가해 주면 끝! 이렇게 BFS와 DFS를 실제 코태에 적용해 봤다. 나처럼 '이 녀석 언제 써먹지?' 싶은 사람들에게 도움이 되었으면 좋겠다.

4. 마치며

DFS와 BFS의 개념만 알고 있을 때는 그걸 어따 쓰는지 몰랐지만, 코테를 풀면서 고민해 가며 알아가는 과정이 보람찼다.

하지만 다 풀고 알았는데, 이건 BFS와 DFS 간의 차이를 설명하기에 좋은 예제가 아니었던 것 같은데 시간관계상 냅다 제출했다. 이 부분은,, 여유롭게 글을 시작해 완성도를 높이는 것으로 해야겠다.

그리고 사실 내가 푼 거랑 다른 좋은 예제를 많이 참고했는데, 그 과정 중 내 경험을 보여주는 거와 모두가 이해하기 좋은 글을 쓰는 거 사이 밸런스를 살짝 고민했다.

사실 제일 좋은 건 모두가 이해하기 좋게 만든 내 경험을 보여주는 거란 거 알고 있다.

언젠가 내가 스스로 그런 수준이 되길 바란다. Try Try~

도움 받은 것들

쉽게 설명한 블로그

https://velog.io/@lucky-korma/DFS-BFS%EC%9D%98-%EC%84%A4%EB%AA%85-%EC%B0%A8%EC%9D%B4%EC%A0%90

DFS, BFS의 설명, 차이점

그래프란, 정점(node)과 그 정점을 연결하는 간선(edge)으로 이루어진 자료구조의 일종을 말하며,그래프를 탐색한다는 것은 하나의 정점으로부터 시작하여 차례대로 모든 정점들을 한 번씩 방문하

velog.io

이쁘게 설명한 블로그

https://chamdom.blog/graph/

Home

기록하는 프론트엔드 개발자

chamdom.blog

깊은 복사와 얕은 복사

뚜따따 — Fri, 31 Jan 2025 16:05:05 +0900

차례

1. 깊은 복사 / 얕은 복사란?

2. 참조 타입의 얕은 복사

3. 참조값의 깊은 복사 방법

4. structuredClone

5. 마치며

빙하기 같았던 취업 시장을 뚫으려 공부했던 깊은 복사 / 얕은 복사 개념이 아무래도 애매해서, 신입이 들어왔을 때
'헉! 저 사람은 깊은 복사와 얕은 복사도 잘 모르나 봐!' 라고 공공연하게 조리돌림을 당해 창피를 당할 수도 있겠단 생각에 급하게 정리해본 깊은 복사와 얕은 복사. ~~이렇게 정리해 두면 더 이상 까먹지 않겠지? 분명 또 까먹고 말겠지.~~

1. 깊은 복사 / 얕은 복사란?

Javascript 의 얕은 복사는 객체의 참조값(주소 값)을 복사하고, 깊은 복사는 객체의 실제 값을 복사한단다.

복사된 녀석(카피)의 값을 변경했을 때, 원본 녀석도 바뀌면 얕은 복사,
복사된 녀석(카피)의 값을 변경해도 그대로면 깊은 복사이다.

이렇게만 정리하니 '원시값' 과 '참조값' 개념이 좀 헷갈린다. 예제를 통해 알아보자.

대입을 통한 원시값(변수) 복사 -> 깊은 복사가 된다.

const a = 'a';
let b = 'b';
 
b = 'c';

console.log(a, b);

================================
출력 (원본은 그대로!)
a c

대입을 통한 참조값(객체) 복사 -> 얕은 복사가 된다. (원본은 그대로다!)

const a = {
  one: 1,
  two: 2,
};
let b = a;
 
b.one = 333;
 
console.log(a, b); 

================================
출력 (원본이 변했다!)
{ one: 333, two: 2 }
{ one: 333, two: 2 }

그럼 이제 참조값을 복사하기 위해서는 어떻게 해야하는지를 알아보자. 이게 또 골치 아프다.

2. 참조 타입의 얕은 복사

참조값을 그냥 대입하면 위처럼 얕은 복사가 된다. 그건 JavaScript 의 참조값들은 주소를 가르키고 있기 때문이다.

그럼 참조값을 깊은 복사하려면 어떻게 해야 하냐?

slice() 와 spread 연산자, Object.asign() 등등을 이용한다면, 1depth 는 깊복, 2depth 는 얕복을 하게 할 수다. 이 녀석들을 참조 타입의 얕은 복사라 부른다.

const original = [
  {
    a: 1,
    b: 2,
  },
  true,
];
const copy = original.slice();
  
// 복사된 배열만 변경.
copy[0].a = 99;
copy[1] = false;
  
console.log(original);
// [ { a: 99, b: 2 }, true ]
console.log(copy);
// [ { a: 99, b: 2 }, false ]

a 는 얕복이라 원본이랑 카피본 둘 다 99로 바뀌었고 true 는 깊복이라 copy 만 false 로 바뀌었다. 따로국밥이다.

3. 참조값의 깊은 복사 방법

const copy = JSON.parse(JSON.stringify(object));

이 녀석, 프론트 개발자라면 실무에서 많이 써봤을 녀석이다.

const object = {
  a: "a",
  number: {
    one: 1,
    two: 2,
  },
  arr: [1, 2, [3, 4]],
};
 
const copy = JSON.parse(JSON.stringify(object));
 
copy.number.one = 3;
copy.arr[2].push(5);
 
console.log(object); // { a: 'a', number: { one: 1, two: 2 }, arr: [ 1, 2, [ 3, 4 ] ] }
console.log(copy); // { a: 'a', number: { one: 3, two: 2 }, arr: [ 1, 2, [ 3, 4, 5 ] ] }

이렇게 copy 를 만들면 copy 를 변경한다고 같이 변경되지 않는 걸 확인할 수 있다.

찾아보며 알았는데 이 녀석은 객체 안에 함수가 있으면 undefinded가 되어서 나오는 한계가 있었다.

4. structuredClone

찾아보다 나온 녀석.

우리가 알고 있는 lodash 나 es-toolkit 을 사용하지 않고도, JSON.parse()보다 강력한 복사 메소드가 js 에는 있었다.
아직은 일부 브라우저(Web API 형태로) 및 환경에서만 지원한다고 하는데, 깊은 복사를 제공하는 녀석이다.

순환되는 데이터 구조를 처리할 수 있고, 내장 데이터 타입(Map 같은 녀석)을 지원할 수 있으며 일반적으로 더 강력하고 더 빠르다고 한다.

const obj1 = {
  a: 1,
  b: 2,
  c: function () { return this.a + this.b }, // (함수는 복사할 수 없다.)
  d: new Date(), //  Date 타입으로 가져온다!
  e: 1n //BigInt 도 된다!
}

const obj2 = structuredClone(obj1);

5. 마치며

우리고 언어로 사용하고 있는 복사는 대체로 깊은 복사일 것이다.
복사된 내 민증에 낙서를 한다고 원본 민증에 낙서가 되지 않는 것처럼. 생활 레벨에서 복사에서는 원본과 같이 움직인다는 개념은 존재하지 않는다. 그것만 기억하면 쉽다. 우리가 보통 사용하는 복사라는 개념은 깊은 복사이고, 얕은 복사란 원본과 같이 움직이는 연결과 가깝다는 점.

도움받은 곳
https://bbangson.tistory.com/78 [뺑슨 - JavaScript 깊은 복사 얕은 복사]

플러터 개쩐다

뚜따따 — Sun, 19 Jan 2025 19:36:39 +0900

- 목차

1. 왜 플러터를 배우려고 했어?

2. 리엑트 네이티브 vs 플러터

3. Dart는 어때

4. Flutter

5. 플러터로 지금까지 한 것들 (노마드코더 니콜라스)

1. 왜 플러터를 배우려고 했어?

첫번째 이유는 창업 준비중인 프로젝트가 플러터여서였다.

10월부터 준비하고 있는 프로젝트가 플러터를 이용한 프로젝트였는데, 우리 서비스의 코드에 대한 개발자로서의 호기심이 생겼다.

두번째 이유는 글또에서 얻은 인사이트 덕분이다.

최근 글또 [앱만들어또 모임]에서 앱을 만든 분(과 만드려는 분)들과 얘기를 나누었는데, 그 때 많은 인사이트를 얻었다. 각자 개발자로서의 자아와 프로덕트 레벨에서 생길 수 있는 고충, 마케팅이나 사업 전반에 대한 이야기를 들을 수 있었는데, 거기서 은찬님의 1인 개발자로 진로를 정한 부분에 많은 감명을 받았다.

은찬님이 추천해준 영상에서 내가 할 수 있는 것과 내가 할 수 없는 것에 대해 인식할 수 있는 기회가 되었다.

https://www.youtube.com/watch?v=xWSwohmOrzQ&feature=youtu.be

개발자가 돈을 버는 방법에 대한 정리

영상에서 정리해준 개발을 통한 경제적 자유 실현 방법은 다음과 같다.

영상에서 말한취업은 '대기업 / 중견기업' 을 제외한 입장이다. 그럼에도 취업과 컨텐츠 크리에이션에 대해서는 내 생각과 조금 다르긴 하다.

이 표와 영상을 통해 나에게 인디해커(1인 개발)에 대한 열망이 있다는 것을 알게 되었다.

2. 리엑트 네이티브 vs 플러터

그럼 어째서 같은 크로스플랫폼인 리액트 네이티브를 선택하지 않았는가?
리액트 경험이 있으니 리액트 네이티브를 시작하는 것에 더 유리했을텐데!

~~사실 이유는 리액트가 지긋지긋해서일 수도..~~

그 이유는 플러터가 예쁘기 때문이다. 리엑트 네이티브와 달리 Flutter는 자체적인 렌더링 엔진을 활용해 모든 UI를 완벽히 제어하기 떄문에 다른 프레임워크와 비교해 더욱 세련되고 아름다운 앱을 만들 수 있다. 마치 Unity처럼!

물론 리엑트 네이티브가 네이티브적인 느낌(서비스가 아이폰 앱처럼 보이거나 안드로이드 앱처럼 보이는 것 같은 느낌) 은 더 띄어나다는 장점이 있지만, 그건 아이폰의 기능이나 안드로이드의 기능을 리엑트 네이티브가 사용하기 때문이라, 장점이라고 보기엔 어렵다고 나느 생각한다.

냅킨이 쪄줬다

React Native

운영체제 별 순정 UI를 사용한 앱을 만들기 쉽다.
프로젝트 버전을 업데이트하기 매우 어렵다.
범용적인 개발언어를 사용한다.

Flutter

자체 디자인 언어를 가진 커스텀 UI를 사용한 앱을 만들기 쉽다.
프로젝트 버전을 업데이트하기 쉽다. => 큰 사이드이펙트가 없는 것으로 알고 있음.
전용 개발 언어를 사용한다.

3. Dart는 어때?

다트는 개쩐다.

일단 배열 안에 if 문과 for 문이 들어간다.

var numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];
 
var a = ['오', '이게되나?', for (int number in numbers) if (number % 2 == 0) number];

print(a); // ['오', '이게되나?', 2, 4, 6, 8, 10]

위처럼 배열 안에서 for 문과 if 문이 들어갈 수 있는데, 와 개쩐다! 라고 생각했다.

하지만 개쩔긴 하는데 그렇게 가독성이 좋아 보이진 않는다. 그럼 이걸 언제 어떻게 쓸까? 꼭 필요한 기능일까 생각하며 강의를 계속 듣다 알게 되었다.

(플러터 코드)

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(title: Text('ListView 예제')),
        body: DynamicListView(),
      ),
    );
  }
}

class DynamicListView extends StatelessWidget {
  final List<int> numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

  @override
  Widget build(BuildContext context) {
    return ListView(
      children: [
        for (var number in numbers)
          ListTile(
            title: Text('아이템 $number'),
            subtitle: Text('이 숫자는 ${number % 2 == 0 ? '짝수' : '홀수'}입니다.'),
          )
      ],
    );
  }
}

이건 플러터로 짝수와 홀수를 찍는 코드인다.

주목할 부분은 children: [ ] 부분이다. 배열 안에 for 문으로 List 에 있는 아이템을 뽑을 수 있다. 이걸 리액트에서 하려면 다음처럼 해야 한다.

(리액트 코드)

import React from "react";

const App = () => {
  const numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

  return (
    <div>
      <h1>리스트 예제</h1>
      <ul>
        {numbers.map((number) => (
          <li key={number} style={{ display: "flex", alignItems: "center" }}>
            <div>
              <strong>아이템 {number}</strong>
              <div>이 숫자는 {number % 2 === 0 ? "짝수" : "홀수"}입니다.</div>
            </div>
          </li>
        ))}
      </ul>
    </div>
  );
};

export default App;

이렇게 리액트는 중괄호와 소괄호를 사용해서 화면을 그려야 하는 반면 Dart 는 배열 안에 뚝딱 집어넣으면 되니 훨씬 편했다.

4. Flutter는?

Flutter의 철학은 효율적이고 일관되며 아름다운 사용자 경험(UI/UX)을 다양한 플랫폼에서 구현할 수 있는 개발 환경을 제공하는 데 중점을 둔다고 한다.

진짜 그래서인지 개발 경험이 쩐-다. 함수 모듈화 노가다를 알아서 해주는 것 보고 감동했다. Flutter 의 개발 경험을 좋게 하는 몇 가지를 알아보려고 쳇지피티한테 물어봤다. 다음과 같은 기능 떄문이란다.

1. Hot Reload: 실시간 코드 반영

Flutter는 Hot Reload 기능을 통해 개발자가 코드를 수정하면 앱이 즉시 변경 사항을 반영합니다.

장점:
- 화면을 새로 고치거나 다시 실행할 필요 없이, UI와 기능을 실시간으로 확인 가능.
- 개발 속도가 대폭 향상되며, 디버깅과 UI 수정이 즐거운 경험이 됩니다.
예: 버튼 색상이나 레이아웃 위치를 바꾸고 저장하면, 화면이 바로 업데이트됩니다.

2. 강력한 위젯 시스템

Flutter는 모든 것이 위젯으로 구성되어 있으며, 직관적이고 재사용 가능한 UI 설계를 지원합니다.

장점:
- 기존 위젯을 조합해 새로운 위젯을 생성하거나, 원하는 대로 커스터마이징할 수 있습니다.
- Material Design과 Cupertino 디자인을 기본 지원하여, 플랫폼에 맞는 아름다운 UI를 쉽게 구현할 수 있습니다.
예:

dart

CopyEdit

ElevatedButton( onPressed: () {}, child: Text('클릭하세요'), );

단순한 버튼부터 복잡한 UI까지 일관된 방식으로 개발할 수 있습니다.

3. 일관된 UI와 성능

Flutter는 자체 렌더링 엔진을 사용하여 iOS와 Android에서 동일한 UI를 제공합니다.

장점:
- 네이티브처럼 보이는 일관된 UI를 제공하면서도, 성능 저하 없이 동작합니다.
- 애니메이션이나 화면 전환이 매우 부드럽고 자연스럽게 동작합니다.

라고 한다. 말 그대로인 것 같다.

추가로 내가 감동했던 건 아이콘 기능인데 구글의 Material 디자인 시스템을 기반으로 한 다양한 아이콘을 1,000개 이상 그냥 사용 가능하다! Icon.favorite_outlined 하면 좋아요 표시가 그냥 나온다!
디자인 에셋에서 찾을 필요 없어! 너무 좋아!

5. 플러터로 지금까지 한 것들

My Wallet

플러터에서 어떻게 디자인 요소를 다루는지 배움

Pomodoros

사용자 인터렉션을 어떻게 활용하는지 배움

Webtoon 클론

API 활용과 페이지네이션, 비동기 처리, 라우팅 애니메이션, 기기별 로컬 데이터 저장, 을 배움

역대급 영지 설계사 유치한데 재밌습니다 나이가 드니까 사람이 유치한 거를 더 선호하게 되는 것 같아요. 머리 안 쓰고 얻는 도파민이 세상에는 참 많은 것 같아요. 주절주절

이상, 노마드 코더 강의를 통해 플러터를 찜쪄 먹어봤다. 재밌었다. 사실 약간 스크래치 코딩 하는 느낌이 들었다. 이거 하면서, 좀 그런 생각이 들었는데,, 이렇게 개발이 쉬워지면 아무나 개발자가 되는 세상이 와 버리지 않을까?
내 밥그릇 지키려면 진짜 뭐라도 더 열심히 해야겠다.

도움 받은 것들

노마드코더 다트 강의

https://nomadcoders.co/dart-for-beginners/lobby

Dart 시작하기 – 노마드 코더 Nomad Coders

Flutter 앱 개발을 위한 Dart 배우기

nomadcoders.co

노마드코더 플러터 기본 강의

https://nomadcoders.co/flutter-for-beginners/lobby

Flutter 로 웹툰 앱 만들기 – 노마드 코더 Nomad Coders

Flutter for Beginners

nomadcoders.co

2024.

뚜따따 — Sun, 5 Jan 2025 15:09:07 +0900

- 목차

1. 개발

2. 사랑

3. 창업

1. 개발

개발자로 다시 돌아오기까지에는 1년의 시간이 있었다. 2023년의 나는 점점 줄어드는 통장 잔고만큼의 소설을 썼고, 더 이상 쓸 돈이 없을 때가 될 때가 되어서야 개발자가 되었다.

솔직히 고발하자면, 나는 개발에 뜻이 없다. 20살, 오로지 돈을 위해 들어갔던 공장. 그 때와 2년차 개발자인 지금 내가 느끼는 업무에 대한 의식은 크게 다르지 않다. 그 당시에도 '어떻게 더 일을 잘하지?' 를 고민했고 지금도 마찬가지이다. 다만 일차원적인 공장 프로세스와 달리 개발이라는 큰 개념과 소통하며 일을 잘하는 무수히 많은 방법들을 알게 되었을 뿐이다.

개발자가 되기 위해 공부했던 때,

개발로 누군가에게 도움이 되었을 때,

개발자가 되어 느낀 고마운 순간들이 많다.

하지만 나에게 그런 순간들이 큰 의미로 다가오지 않는다.

'개발자로서의 의식' 그걸 위해 노력하는 모든 개발자들이 존경스럽다. 다만 존경은 간혹 이해할 수 없는 것에 대한 회피일 수도 있을 것이고, 대체로, 아마, 내가 그렇다.

그럼에도 나는 다시 개발자가 되었다. 미래 때문이다. 글로 1년간 벌었던 170만원은 가난을 두려워하는 나에게 큰 불안이었고, 애초에 내가 글을 쓰고 싶던 마음은 내 게으름보다 대단하지 않았다. 단지 나는 게으른 사람이라는 것을 인식하는 순간, 내 게으름을 제어하기 위해 필수적으로 회사를 다녀야만 했다. 그 과정에서 100개의 서류 탈락이 있었지만, 자업자득이다. 오히려 결심한 다음부터는 괴롭지 않았던 것 같다. 다시 회사에 들어가 훌륭한 개발자를 목표로 지내고 있고, 개발자가 되어 다행이라고 생각한다. 힘든 상황 속 개발에 대한 경력이 나를 구했다.

아마 이 글은 내 커리어에 전혀 도움이 되지 않을 것이다. 다만 그저 나는 어디선가 한 번 진실해보고 싶었다.

이 글은 거의 나를 위한 글이만, 이 글을 읽는 누군가에게 공감과 위로가 되면 좋겠다는 생각이다.

내가 어떻게 생각하는지와 내 역량과 성취는 별개이다. 다만 나는 즐기면서 개발하는 그대들을 존경한다는 얘기이다.

2025년의 나는 어쩌면 개발이 좀 더 즐거워질수도 있다. 다른 즐거운 일을 찾을수도 있고.

요약하자면 그냥 서른 된 남자가 아직도 방황한다는 얘기다.

2. 사랑

2024년, 10년간 피던 담배를 끊게 된 건 사랑 덕이었다. 나는 자유를 사랑하는 사람이고, 담배를 피우던 순간의 자유로움이 좋았다. 아무도 없는 곳에서 세상과 단절해 오로지 나에 집중하는 시간. 그걸 자유라고 나는 생각했다. 하지만 사실 담배야말로 자유롭지 못한 일이었다. 담배를 필 때에만 자유를 느낄 수 있었기 때문이다.

그리고 사랑은 속박이라고 생각하는 과거에는 전혀 몰랐지만, 사실 사랑이 곧 자유였다. 내가 나로 있다는 것을 인정해주는 누군가 덕에 나는 나를 더 잘 알게 되었고, 나를 더 사랑하게 되었다. 그걸 알게 된 2024년과 내 연인에게 감사하다. 나이 서른, 너무 늦게 알게 된 일이지만, 사랑은 고맙고 소중한 것이다.

3. 창업

열 번의 만남보다 가치 있을 한 번의 이별

이별노트 렌딩 페이지 주소: https://ibyeolnote.com/

수없임 많은 만남과 만나기 위한 서비스들이 있다.
그런데 왜 이별한 사람을 위한 서비스는 없지?

위와 같은 의문에서 기획된 위 이별노트 서비스, 내 역할은 기획 / 전략 / FE 이다.

아무래도 회사 생활과 병행하며 준비하기에는 리소스가 부족한 부분이 많았다만, 뭐 어쩔 수 없지. 다행인 건 회사가 그리 바쁘지 않아 업무 외 추가 리소스가 크게 들지 않았다는 것이다.

저번 주 헐레벌떡 프라이머 제출이 끝났다. 최선을 다했다만 긍정적인 결과를 기대하기는 아무래도 힘들 것 같다. 하지만 데이터 수집 및 동기, 사업계획서를 쓰던 과정이 보람찼고 그 과정 속에서 창업이 더 명확해지는 게 즐거웠다. 이제 시작. 2025년은 바쁜 한 해가 될 것 같다.

고객 니즈가 보이는 데이터 분석 with 파이썬 훑어보기

뚜따따 — Fri, 20 Dec 2024 17:31:34 +0900

차례
1. 이 책을 고른 이유

2. 무엇을 배웠나요?

3. 어떤 게 좋았나요?

4. 마치며

1. 이 책을 고른 이유

첫 번째 이유
이 책을 고른 첫 번째 이유는 지금 다니는 회사에서 고객 데이터 감정 분석 기술이 필요했기 때문이다.

하지만 책이 배송되었을 때는 이미 프로젝트는 조각조각 난도당한 상태였고,
이사 준비로 바빠 뒤늦게 본가에 가 책을 수령한 나는 의미를 잃어버린 그 녀석을 소중하게 집어 들었다.

프로젝트가 사라지고 난 뒤~~ ♪ 나와 책만이 남아~~

심지어 길벗 측의 사소한 실수로 책이 5권이 발송되어서 '어떠카지! 어떠카지!' 하다가 성윤님한테 연락드려 책을 돌려드리러 묵직한 그 녀석의 4개의 분신을 들고 뚜벅뚜벅 편의점을 왔다가 갔다. 성윤 님도 왔다 갔다 힘드셨을 거야. 성윤님 너무 고생 많으셨어요ㅠㅠ

두 번째 이유

이 책을 고른 두 번째 이유. 3년 전부터 자연어 처리에 대한 해소되지 않은 갈증이 남아있었다.
그 때 나는 졸업논문 주제를 '신문 기사 3줄 요약 AI'로 잡았었다.

(AI 수업 하나 잘 보고 잔뜩 신이 나서 감히 잠자는 NLP의 코털을 건드렸다)

데이콘에서 한국어 문서를 요약하는 챌린지가 있었는데 거기서 제공받은 신문 기사 데이터를 바탕으로 textrank 나 KoGPT2 처럼 직접 나만의 자연어 처리 모델을 만드려고 했지만, 빈약한 배경지식과 관련 자료의 부족. 물리적 시간, 정신적 나의 에너지를 고려하지 않아 당당하게 실패하고 말았다.

결국, 졸업논문은 textrank를 사용한 신문 기사 요약, 생성 웹을 만드는 것으로 방향을 전환했었는데, 그 당시에 못해본 찝찝함을 해소해 보고자 이 책을 골랐다.

2. 무엇을 배웠나요?

책의 목차는 다음과 같다.

1장. 자연어 분석 준비

2장. 스크래퍼로 데이터 수집

3장. 수집한 데이터로 자연어 분석

4장. 자연어 분석에 필요한 통계 공부

부록 A. GPT-3.5로 자연어 분석하기

부록 B. 코랩 시작하기

부록 C. GPU 사용 설정하기

1장에서는 파이썬 기초와 Pandas를 사용해 엑셀 쪼개고 붙이고 자르고 하는 그런 것들이 자세하게 나와 있다. 이 책을 읽으며 정인근 선생님이 대단히 따뜻한 사람이라고 ~~혼자 멋대로~~ 생각하게 되었는데, 되게 편한 단어들을 주로 사용하고 친절한 옆집 아저씨 같은 말투로 서술되어 있다는 것이다. 중간중간 주는 팁들도 그렇고, 간단한 matplotlib로 그래프 그리는 것까지 알려줘 대학시절 생각이 살짝살짝 낫다. ~~(사실 1장은 힐끔 보고 건너 뛰었다.)~~

2장에서는 크롤링과 스크래퍼에 대해 다룬다. 길벗 사이트 스크래핑을 해보는 과정이 인상적이었고(ㅋㅋㅋㅋ 길벗 랜딩 페이지가 바뀌는 순간 2장의 예시는 모두 사용할 수 없게 된다!)

3장에서는 실제 데이터를 분석하는 과정을 다룬다. 개념 -> 실습 형태로 해서 흐르듯 이해하며 넘어갈 수 있었고, 흥미 깊은 주제(ex. 어떤 떡볶이가 맛있을까, 내 여자친구 최애 쿠션 찾아주기)에 대해 얘기하며 중간중간 데이터와 머신러닝 개념들을 설명하는 게 인상적이다.

4장은 본격적으로 데이터 용어들을 다룬다. 간단하게 설명되어 있어 데이터에 대해 무지한 사람이 읽기 좋을 것 같다. 실제로 그래프를 그려보는 과정은 갓 파이썬 입문한 사람들에게 귀할 것 같다는 생각을 했다.

3. 어떤 게 좋았나요?

의문을 먼저 해결해 주는 소프트한 데이터 분석
책을 읽다가 어? 이건 어떻게 하지?라는 부분이 생기면 바로 다음 장에 그것에 대한 개념과 실습이 있다.

여러 가지 라이브러리 제공과 비교 분석
한국어 맞춤법 교정을 해주는 hanspell 라이브러리는 더 이상 pip으로 설치할 수 없는데, 소스파일을 제공해 줬다! (감사)
koromon이나 okt 같은 형태소 분석기를 비교 분석하며 알려주는 부분이 세심하다고 생각했다.

흥미로운 주제로 해보는 실습

남자 개발자라면 응당 목차를 보고 3.4 '내 여자친구 최애 쿠션 찾아 주기'부터 펼쳐봤을 것이다. ~~나만 그런가~~ 이런 킥을 놓치지 않는 부분이 참 좋았다.

편안한 단어와 편안한 말투. 따뜻한 설명
딱딱한 전문 용어나 복잡한 문장을 사용하지 않고 누구나 쉽게 이해할 수 있는 쉽고 부드러운 단어를 위주로 사용한다.

알맞은 도식을 사용하고 자연스러운 문체로 흘러가서 읽는데 피로감이 덜하다.

독자를 설득시켜 주는 책.

근시안적인 결과에 대해 경계하는 저자는, 데이터를 이용해 설득하는 방법을 보여준다고 나는 생각했다. 주어진 데이터를 이용해 '맛있는 떡볶이'를 기획하는 저자의 단단한 논리에 감히 의심을 품을 수 없었다.

※ 길벗 출판사의 후원을 받아 서평을 작성했습니다. 책을 받게 되어 영광입니다. 감사합니다.

https://www.yes24.com/Product/Goods/125892195

고객 니즈가 보이는 데이터 분석 with 파이썬 - 예스24

고객의 진정한 니즈가 담긴 데이터를 수집하고 분석한다!유튜브, 네이버 카페, 트위터 등에서 찾아내는 고객 니즈와 시장 트렌드!데이터 시대에서 살아가고 있는 만큼, 데이터를 분석해 의사 결

www.yes24.com

내가 셋을 세면 시작하는 거야...!! 원!!!!! 투!!! 쓰리.js

뚜따따 — Fri, 1 Nov 2024 18:47:31 +0900

밤새도록 돌아가는~ 자동차

~~어찌저찌 돌아가는~ 내 인생~~

차례

0. 쓰잘데기 없는 데모 (위에서 끝남)
1. Three.js 모임 회고
2. Three.js란?
- 장면(Scene)
- 카메라(Camera)
- 렌더러(Renderer)
3. 원시 모델 (Primitives)
- 기하학(Geometry)
- 재질(Material)
- 조명(Lighting)
4. 마치며

1. Three.js 모임 회고 (사실 감사글이자 반성글)

지난 10월 20일, 쓰리제이에스 킥오프를 다녀왔다. 기대를 그렇게 크게 하진 않았는데, 원규님께서 Three.js 발표를 하시며 지식을 꽂아 넣어주셨다. (그날,,, 그는 빛으로 이루어진 무언가셨다) 뇌로 직접 듣는 Three.js 발표를 해주신 원규님에 대한 감사한 마음을 여기에 다시 한 번 적는다. anyway 정말 값진 시간이었다.
그리고 우리 조원들과도 말이 잘 통해 뒷풀이도 즐겁게 다녀웠다. 다들 너무 감사하게도 내 얘기(한강 작가님 노벨상 개쩔지 않아요?! MBTI 를 믿나여! etc etc)를 즐겁게 들어주셔서 조금 과하게 신이 나버렸던 것 같다. ~~너무 감사합니다!~~ 이젠 강하게 나의 신남을 단속할 필요가 있다. anyway 좋은 주관들을 수집할 정말정말 값진 시간이었다.

2. Three.js란?

쓰리.js 란 무엇일까. Three.js는 사용하기 쉬운, 가볍고, 크로스 브라우저 호환성을 가진 자바스크립트 3D 라이브러리
라고 한다. 쉽고, 가볍고, 호환되는 3D 녀석이다!

오잉? 근데 3D 할 거면 Three.js 꼭 써야 해?

예전에 이런 걸 만든 적 있다.

멍하니 보고 있으면 왠지 기분이 좋다

CSS 의 transform 이랑 animation 으로 만들어진 걸 ~~머리 안 쓰고~~ 배껴와서 가공한 녀석이다.

'& .box': {

position: 'relative',

transformStyle: 'preserve-3d'

'& .box__face': {

width: '100px',

height: '100px',

position: 'absolute',

display: 'flex',

justifyContent: 'center',

alignItems: 'center',

color: '#fff',

fontSize: '1rem',

borderRadius: '20%'

'& .--front': {

background: '#e76554',

opacity: '0.9',

transform: 'rotateY(0deg) translateZ(50px)'

'& .--back': {

background: 'rgba(98, 155, 206, 0.9)',

transform: 'rotateY(0deg) translateZ(-50px) scaleX(-1)'

'& .--right': {

background: 'rgba(80, 188, 223, 0.9)',

transform: 'rotateY(90deg) translateZ(50px)'

'& .--left': {

background: 'rgba(149, 98, 206, 0.9)',

transform: 'rotateY(-90deg) translateZ(50px)'

'& .--top': {

background: '#ABA45F',

transform: 'rotateX(90deg) translateZ(50px)'

'& .--bottom': {

background: '#A45FAB',

transform: 'rotateX(-90deg) translateZ(50px)'

}

원본 코드 출처: https://nykim.work/26

도메인에 따라서 간단한 CSS 와 html 로 빠르고 간결하게 3D 에니메이션을 뽑아내야 할 떄도 있을 거다. 그럴 때는 저렇게css 의 translate 를 써도 상관 없겠지만, 저 네모네모 주사위를 3D 그래픽스로 부르기는 좀 힘들어 보인다. 왜냐, 저 네모네모에겐 Three.js 의 특징 3가지가 없기 때문이다. 바로 요 녀석들이다.

장면(Scene)
카메라(Camera)
렌더러(Renderer)

삼형제생성기 출처: http://vbcstatic.s3-website-us-west-2.amazonaws.com/brothers/ ㅋㅋㅋㅋ 지금 보니 글자 짤림 엌ㅋㅋㅋㅋ 죄송ㅋㅋㅋ

그럼 지금부터 삼형제를 한 명씩 만나러 가보자

장면(Scene)

출처: Three.js 메뉴얼 https://threejs.org/manual/#ko/fundamentals

위 도식화처럼 Scene은 Renderer 가 그려준 녀석 중 카메라를 제외한 모든 녀석이다. 위에서 말한 것처럼 '무대' 이다. 무대니까 카메라가 저래 위에 걸쳐 있다.
Mesh 와 Light 는 후술.

카메라(Camera)

어디서 무대를 보고 있는지를 나타낸다.

출처: Three.js 메뉴얼 https://threejs.org/manual/#ko/scenegraph 작은 탱크한테 걸리면 아주 뿅 되는거야!

위 3D Object 인 탱크의 시점이 변하는 것처럼, 카메라는 시야각, 시작과 끝 지점, 종횡비 같은 걸 설정한다.

카메라의 종류는 크게 원근 카메라와 정투영 카메라가 있는데, 일반적으로 원근 카메라가 쓰인다.

1. 원근 카메라 (Perspective Camera)

원근 카메라는 사람의 눈과 비슷하게 작동하여, 물체가 가까이 있을수록 크게 보이고 멀리 있을수록 작게 보이는 원근감을 표현한다
용도: 게임, 시뮬레이션, 가상현실(VR) 등 현실적인 시각 효과가 필요한 장면에 주로 사용.
주요 속성:
- fov (Field of View): 카메라의 수직 시야각을 설정. 각도가 커질수록 더 넓은 범위를 볼 수 있다.
- aspect (Aspect Ratio): 화면의 가로 세로 비율로, 일반적으로 캔버스의 크기 비율에 맞춘다.
- near | far: 가까운(near) 곳과 먼(far) 곳의 거리 제한을 설정한다.

const fov = 40;

const aspect = 1;

const near = 0.1;

const far = 1000;

const camera = new THREE.PerspectiveCamera(fov, aspect, near, far);

Near 과 Far 개념이 잘 이해가 안 가서 near 을 100으로 올려봤다.

near 만 100 으로 올렸을 때

near 가 0.1 일때

near 가 0.001 일 때 (으악!)

near 과 far 가 의 값이 너무 멀어지게 되면 위처 서로 가까이 위치한 두 객체가 정확히 구분되지 않아, 떨리거나 깜박이는 시각적 오류가 발생한다
깊이 버퍼 정밀도 부족으로 발생하는 이 증상을 Z-파이팅이라고 부른다!

결론) 적당히 설정하자

2. 정투영 카메라 (Orthographic Camera)

정투영 카메라는 물체의 원근감을 제거하여 거리에 상관없이 모든 객체가 동일한 크기로 보이게 한다. 물체의 형태가 왜곡되지 않으므로, 주로 건축 도면, UI 디자인, 2D 게임 등에 유용하다. 끝

렌더러(Renderer)

이렇게 쓴다. WEBGL 기술을 활용하며, 계단현상 막는 것 외로 그림자 등 여러 옵션을 제공한다.

const rederer = new THREE.WebGLRenderer({

canvas: document.querySelector('#c'),

antialias: true,

alpha: true

});

3. 원시 모델 (Primitives)

Three.js의 원시 모델이란, 주로 런타임에서 다양한 인자들로 정의한 3D 모양을 의미한다. (ex 원뿔, n각형, 글씨 이런 거)

Geometry (기하학)

기하학은 3D 객체의 형태를 결정하는 데이터 구조이다. 점(Vertex), 면(Face), 그
리고 각 점의 위치와 간격으로 객체의 기본 모양을 정의한다.

구성 요소

Vertex (정점): 3D 공간에서 객체의 특정 위치를 나타내는 좌표로, 기하학의 가장 기본 요소
Face (면): 정점들이 모여 이루는 면. 면을 여러 개 합쳐 3D 형태가 만들어진다.
Edges (모서리): 두 개의 정점을 연결하는 선분, 객체의 외형을 구성.

Material (재질)

시각적인 효과를 부여하는 요소. 빛을 반사하거나, 투명하거나, 색상을 가지도록 만든다.

재질 종류

MeshBasicMaterial: 빛의 영향을 받지 않는 단순한 색상 재질
MeshLambertMaterial: 부드러운 조명 효과가 필요한 경우 사용. 환경에 따라 색상이 조금씩 다르게 보인다.
MeshPhongMaterial: 광택 효과가 있는 재질로, 반사와 하이라이트 표현이 가능
MeshStandardMaterial: 물리 기반 렌더링(PBR) 재질로, 사실적인 표현이 필요할 때 사용된다.

조명(Lighting)

조명은 3D 장면에 사실감을 더하고, 각 객체가 시각적으로 구분되도록 하는 요소이다. 그 중에는 여러 조명이 있지만, 두 개가 주로 쓰이는 것 같으니, 두 개만 설명하겠다! ~~(당당)~~

특성	PointLight	AmbientLight
빛의 방향	한 지점에서 모든 방향으로 발산	방향성 없음, 모든 객체에 균일하게 적용
거리 감쇠	distance와 decay로 조절 가능	없음
그림자 생성	그림자 생성 가능	그림자 없음
용도	전구, 촛불 등 집중된 빛을 표현	장면의 기본적인 밝기를 조절하는 배경 조명

4. 마치며

[공부 -> 글쓰기] 를 통해 시간을 아끼고 더 효율적인 글쓰기를 할 예정이었건만 어째
[공부 -> 글쓰기 -> 아, 정리한 거 봐도 잘 모르겠네 -> 서칭 -> 공부 -> 글쓰기] 의 모양세가 되어 생가보다 시간이 오래 걸렸다. 퀄리티가 일정한 글을 유지하고자 노력했는데, 아무래도 실패한 것 같다. 다음엔 초반에 힘을 좀 더 빼고 들어가야지.. 어쨌든 정신 사나운 글을 끝까지 봐주셔서 감사합니다.

글 쓰는데 걸린 시간: 5시간 30분

참고 자료: Three.js docs