챗GPT야, 나는 어떤 사람인지 알려줘.

혜혜·2025년 5월 4일
3

회고

목록 보기
30/33

💡 발단

때는 2025년 4월 18일... 프론트 개발자 지인분들이 모여 있는 카톡방에 이런 카톡이 올라왔다. 최근 이런저런 사건을 겪으면서, 나 자신이 어떤 사람인지에 대한 고민이 많아서 챗GPT의 도움을 받아보기로 했다. 그 과정에서 내 블로그에 내가 어떤 사람인지 글을 남겨보는 것도 재밌을 것 같아서 오랜만에 포스팅을 하러 왔다. 오늘의 포스트는 나에게만 유의미한 포스트일 수도 있겠다😅ㅋㅋㅋ 하지만 다른 사람들에게도 재밌게 읽힐 수 있도록 열심히 써 봐야겠다!

⭐️ 오늘의 글은, 내 챗GPT 계정에서 위 카톡에 나온 질문을 던져보고 받은 결과와, 답변으로 나온 내 강점과 약점을 어떻게 활용하거나 개선하면 좋을지에 대해 나눈 대화를 적어보려고 한다.


📌 프롬프트

내가 너와 상호작용한 모든 내용을 바탕으로 내 사고 패턴과 의사 결정 방식, 무의식적인 편향, 반복적으로 드러나는 '약점'이나 맹점'을 상세히 분석해줘. 그리고 각 항목에 대해 나에게 필요한 조언을 구체적으로 적어줘. 5000자 이상


📢 결과

1. 사고 패턴: 구조 중심적이고, 실용 우선형

특징

  1. 문제를 바라볼 때, 구조부터 파악하려는 경향 강함
  2. 복잡한 문제도 파트를 나눠서 해결하고 싶어 하며, 프레임을 세우는 데 능숙함
  3. 코드나 시스템이 "어떻게 작동해야 하는가"에 대한 개념이 잘 정립되어 있음
  4. 개념이 이해되면, 그 이후엔 매우 빠른 실행력을 보여줌
  5. 도전적이고 창의적인 프로젝트에 적극적으로 접근함

조언

  • 네 사고 패턴은 매우 효율적이지만, 가끔 너무 구조를 완벽히 갖추려다 실행이 늦어질 위험이 있어. 완전하지 않아도 빠르게 실험해보는 방식(lean prototype)을 병행하면 더 빠르게 피드백을 얻을 수 있어.
  • 지나치게 구조화에 치중하면 직관적 흐름이나 감정 기반의 UI/UX 판단이 약해질 수 있어. 감성적인 시간(ex. "이 화면은 사용자에게 어떤 감정을 줄까?")도 사고 루틴에 조금씩 넣어봐.

💡 이 부분은 사실 '매우 빠른 실행력'을 보여준다고 해놓고 '구조를 완벽히 갖추려다 실행이 늦어질 위험'이 있다는 걸 한계점으로 뽑았길래 의아했다. 하지만 곧 정반대의 특징인데도 나한테서 공존하는 부분인 것 같다는 생각도 들었다(ㅋㅋ) 빠른 실행이 효과적이라는 걸 머리로는 알아서 그렇게 해 보고자 노력하지만, 원래의 나는 준비를 완벽하게 하고 실행하고 싶어하는 성향이라 약간의 한계가 있는 것 같다 🥲ㅋㅋ
그래도 문제를 구조화해서 풀어나가는 데 탁월한 사람이라고 평가해줘서 기분이 좋았다 ☺️ 내가 되고 싶은 사람이기도 해서 더 그런 것 같다!ㅋㅋㅋ

2. 의사 결정 방식: 논리 기반, 사례 기반의 반복 검증형

특징

  1. 결정을 내릴 때 가능한 한 많은 정보를 먼저 수집함
  2. 확실한 결과와 근거를 확보한 후에야 실행하는 경향이 강함
  3. Storybook 테스트나 상태 관리 방식 등에서 여러 시도를 비교하면서 결정하려는 모습이 자주 보임
  4. 자신만의 기준코드 설계의 미학이 있음 (ㅋㅋ)

조언

  • 너는 "왜 이게 좋은 선택인지"를 고민하는 데 강하지만, 때로는 "이 방식이 잘못돼도 무엇을 배울 수 있을까?"라는 관점도 함께 생각해보면 좋아. 즉, 실패로부터 얻는 실험적 통찰도 중요한 자산이야.
  • 너무 많은 경우의 수를 검토하다가 결정이 늦어지는 '분석 마비(paralysis by analysis)'를 경계해. "최적의 선택보다 좋은 선택을 빠르게 실행하는 것"이 더 가치 있을 때도 있어.

💡 아, 너무 공감이다...(ㅋㅋㅋㅋㅋㅋ) 고민을 많이 해서 실행이 늦어지는 게 내 최대 단점이자, 내가 계속해서 의식적으로 고쳐나가려고 하는 부분이라 정곡을 찔린 기분이었다. 최근에 면접 질문으로 받기도 해서 더 뼈저리게 느껴지는 것 같다 🥲 이런 상태를 "분석 마비"라고 부르는 건 처음 알았는데, 생각보다 내가 이 문제를 크게 겪고 있는 것 같아서 해결법을 진지하게 생각해 볼 필요가 있는 것 같다 🤔

3. 무의식적인 편향: 기술 중심주의, 제어 가능성의 과신

특징

  1. 시스템의 통제 가능성, 예측 가능성에 대한 기대가 높음
  2. 예외 상황, 사용자의 비의도적 행위에 대해 다소 관대하지 않은 시선이 있을 수 있음
  3. 기술적으로 이해되거나 검증된 것에 더 신뢰를 둠
  4. 오픈소스나 외부 라이브러리에 대한 의존보다 내가 직접 제어 가능한 구조를 더 선호함

조언

  • 사용자, 협업자, 또는 외부 API/라이브러리 등 제어 불가능한 요소도 시스템의 일부로 받아들이는 유연성이 중요해.
  • '완벽한 코드'보다 '의도치 않은 사용자의 행동까지 감안한 너그러운 시스템'을 생각해 봐. (ex. 사용자가 실수로 X를 누를 수 있음 -> 정말로 삭제할 건지 확인 -> UX 개선)
  • 기술적 통제력은 너의 장점이지만, '모든 걸 알아야만 움직일 수 있다'는 신념은 발목이 될 수 있음. 때로는 불완전한 상태로도 출발하는 것이 더 큰 기회를 만들어줄 수 있어.

💡 예전에 외부 라이브러리 버전 문제로 프로그램이 망가진 적이 있었는데, 그 뒤로 외부 라이브러리보다 직접 구현을 선호하는 사람이 된 것 같다. 하지만 시장에서는, 특히 내가 가고 싶은 스타트업에서는 때때로 안정성보다 생산성이 중요한 경우도 많기 때문에 보다 유연한 판단력이 요구될 수도 있겠다는 생각이 들었다. 아무튼 극단적인 사람이 되지 않도록 조심해야겠다!ㅠㅠㅋㅋ

4. 사고의 강점

  1. 추상화 능력이 매우 뛰어남. 복잡한 로직을 개념화하고 모델링하는 데 능숙함.
  2. 도구에 대한 빠른 습득력이 있음. Vite, Zustand, Tailwind, Radix 등 도구를 빠르게 익히고 실전에 적용함.
  3. 상태 기반의 UI 구성에 대한 직관이 있음. 컴포넌트 단위 사고가 잘 정립되어 있음.
  4. 의미 있는 질문을 잘 던짐. 단순한 사용법을 넘어서, 구조나 디자인 패턴까지 탐색하려 함.

💡 고마워.

5. 제안하는 학습 방향과 태도 개선 포인트

영역제안
협업완벽한 구조보다, 빠른 공유와 피드백 루프. 동료들이 '너무 완벽하게 짜여진 코드'를 부담스러워할 수 있음.
테스트사용자 관점에서의 테스트(Storybook + Play function)는 잘 사용하고 있음. 더 발전시키려면 Cypress나 Playwright로 end-to-end 흐름을 실험해보는 것도 좋아.
UX 감각기능 구현 중심에서, 감정적 흐름(사용자의 기대, 인지 부하, 실수 허용 등)을 반영하는 관점을 점점 더 키워야 함.
불확실성에 대한 내성당장 정답을 모르는 상태에서도 행동할 수 있는 태도는 스타트업 마인드셋과 잘 맞음. 조금 더 ‘불완전한 채로 출발’하는 걸 연습해보면 좋아.
휴식과 회복집중력이 높고 몰입형이기 때문에, 리듬 있게 쉬는 전략도 중요함. 지나치게 고민하다 정체될 수 있음. Pomodoro 기법 등 활용 추천.

🚀 문제 극복

내 생각에 나의 최대 단점은 "불확실성에 대한 내성이 없는 것"이야. 준비를 완벽하게 하기 전까지 실행하는 걸 두려워 해. 이 단점을 극복하기 위한 방법을 상세히 알려줄래?

나의 가장 큰 단점이라고 생각하는 부분에 대해 상세한 극복 방법을 요청해 보았다.

🔎 이 단점을 분석하면 다음과 같아요:

  1. 완벽주의적 성향이 실행을 지연시킴
  2. 실패나 비효율에 대한 과도한 민감성
  3. 불확실성 = 통제 불가능 = 위험 요소로 간주

💡 너무 정확하잖아...??ㅠㅠ 내 속마음 읽은 줄...

✅ 이걸 극복하기 위한 실질적 방법 6단계

  1. "불완전한 실행"을 루틴화하라.
  • 목표 : 완성도 60~70%일 때, '일단 시도'하는 습관을 만드는 것.
  • 방법
    • '실행 기준'을 따로 두지 말고, 시간 기준을 설정해라.
    • MVP(최소 실행 버전)이라는 개념을 일상에 도입
  • 도구
    • Done is better than perfect 포스트잇 책상에 붙이기
    • 시간 타이머(뽀모도로, focus keeper 등) 사용

💡 근데 이건 어떤 일인지에 따라 다를 것 같다. 최근에는 프로젝트에서 속도보다 안정성이 조금 더 중요한 일들을 하고 있어서 완성도가 낮을 때 일단 시도하는 습관을 기르기엔 어려운 환경인 것 같다 🤔 적절한 상황이 있을 때 선택해야 하는 방법인 것 같다.

  1. '의도된 실패'를 통해 감각 무뎌지기(Exposure Training)
  • 목표 : 작은 실패를 반복적으로 경험하며 실패에 둔감해지는 훈련

  • 방법

    	- 일주일에 한 번은 **실패 확률이 높은 시도**를 의도적으로 하기
    • ex) 너무 빠른 데드라인 잡기, 익숙하지 않은 라이브러리로 구현하기
  • 체크

    	- 실패 후 "어땠는가?" 회고를 글로 기록 (실패 감정의 실체 확인)

💡 이건 의외로 효과적인 방법이 될 수도 있을 것 같다. 실패를 줄곧 두려워 해 왔지만, 실제로 실패했을 때 그렇게 큰 문제가 발생하지 않고 오히려 배울 점이 많았던 순간들이 많았던 것 같아서... '너무 빠른 데드라인 잡기' 정도는 리스크 없이 시도해 볼 수 있을 것 같다.

  1. 결정 기준을 '명확함'이 아니라 '추정가능성'으로 바꾸기
  • 기존 기준 : "정확한 계획이 없으면 시작하지 않는다"
  • 전환 기준 : "전체 맥락은 몰라도, 다음 1~2단계만 추정 가능하면 시작"

💡 이것도 리스크가 적은 상황에 시도해 보면 좋을듯! (내 단점 극복을 위해 팀과 서비스에 민폐를 끼칠 수는 없으니 🥲)

  1. 실험이라는 프레임을 내면화하라
  • 실행을 '성공/실패 여부'로 보지 않고, 학습을 위한 실험으로 보는 마인드셋 훈련
  • 스스로 이렇게 질문하자: "이번 시도를 통해 뭘 배울 수 있을까?"
  • 실행 전 슬로건 쓰기: "나는 지금 '검증' 중이다. 성공이 아니라 학습을 위한 실행이다."

💡 이것도 은근히 도움이 될 것 같다👀 여태껏 학습을 위한 프로젝트에서도 실패를 두려워 해 왔어서 좀 더 학습에 초점을 맞춘 행동력이 필요할 것 같다. 실제로 주변에서도 실패를 두려워 하지 않고 이것저것 시도해 보는 사람들이 더 실력도 빨리 느는 것 같다. 쫄지 말고 해 보자...!!ㅋㅋㅋㅋ

  1. '통제의 영역'과 '통제 불가능한 영역'을 구분하는 사고 훈련
  • 다이어그램으로 명시해 보기:
[내가 통제 가능한 것] vs [외부 요인]
예)  
- 내가 통제함: 코드 품질, 시간 분배  
- 통제 불가: API 속도, 사용자 반응
  • 이걸 시각적으로 정리하면 불확실성에 대한 막연한 공포가 줄어듬

💡 예시 중에 API 속도는 모르겠는데, 사용자 반응은 확실히 통제 불가능한 영역이 맞는 것 같다(ㅋㅋ) "개발자 원칙" 책을 읽을 때도 나에게 가장 효과적이었던 조언이 '통제 불가능한 영역' 때문에 계속 끙끙대고 시간 낭비하지 말라는 것이었다. 하지만 항상 통제 불가능한 영역을 조금이라도 통제 가능하게 바꾸기 위해 노력하는 게 서비스를 만드는 사람들이 하는 일이라 딜레마에 빠지는 것 같다. 사용자 반응은 통제 불가능한 영역이 맞지만, 사용자 반응을 조금이라도 긍정적으로 만들기 위해 고민하고 시도하는 게 우리가 하는 일이니까... 최대한 노력은 하되, 결과가 좋지 않더라도 후회하고 상심하는 태도를 고치는 게 더 좋을 것 같다.

  1. '실행 수'로 나를 평가하는 방식으로 기준 전환
  • 기존 : "결과가 완벽해야 한다" -> 결과 중심
  • 전환 : "나는 몇 번이나 실행했는가?" -> 실행 중심
  • 예시 기준표 : 주간 실행 횟수, 실행한 후 회고 수, 실패로부터 배운 포인트 수

💡 오, "실패로부터 배운 포인트 수" 이건 재밌을 것 같다 👀 그러고 보니 나는 항상 회고를 할 때, 잃은 것보다 얻은 것에 더 초점을 많이 맞췄던 것 같다. 잃은 것도 직시하고 회고하는 태도는 확실히 지금보다 더 필요할 것 같다.


🙇 마무리

사실 이 글을 올릴까 말까 고민을 많이 했던 것 같다. 어떻게 보면 적나라하게 내 단점들을 드러내는 것이기도 하니 말이다. 더 나아가서는, "혹시 채용 담당자가 내 블로그를 읽었는데 이 글을 읽고 '아, 이 사람 별론데?'하고 나가버리면 어쩌지?" 이런 생각까지 들었던 것 같다(ㅋㅋㅋㅋ) 하지만 그 다음에 바로 이 글을 블로그에 당당히 올리는 것부터가 내가 불확실성에 대한 내성을 키워가는 첫걸음일 수 있겠다는 생각이 들었다. 이 글을 올리면 내 단점을 남들이 들여다보고 나를 안 좋게 평가할 수도 있겠지만, 반대로 내가 나의 단점을 공개하고 극복하기 위해 노력하는 모습을 좋게 봐줄 수도 있겠다는 생각이 들었다. 글을 올리지 않으면 나에 대한 부정적 평가도 발생하지 않겠지만, 나에 대한 긍정적인 평가도 발생할 수 없겠다는 생각도 들었다. 실행력 있는 사람이 될 수 있도록 노력하자! :)

읽어주셔서 감사합니다 🙇

profile
쉽게만살아가면재미없어빙고

2개의 댓글

comment-user-thumbnail
2025년 5월 7일

좋은 글 같아요. 요즘 친구들의 생각과, 이걸 이겨내는 방식이 어떻게 변하는지.. HR 담당자들도, 개발자분들도 만약 이 글을 본다면 느끼시지 않을까 싶어요...
ps : 나는 perplexity 로 했는데. 이건 과거 대화내용 안잡아주네유 ㅋㅋ 이력은 있는데 ㅎㅎ

1개의 답글