
때는 2025년 4월 18일... 프론트 개발자 지인분들이 모여 있는 카톡방에 이런 카톡이 올라왔다. 최근 이런저런 사건을 겪으면서, 나 자신이 어떤 사람인지에 대한 고민이 많아서 챗GPT의 도움을 받아보기로 했다. 그 과정에서 내 블로그에 내가 어떤 사람인지 글을 남겨보는 것도 재밌을 것 같아서 오랜만에 포스팅을 하러 왔다. 오늘의 포스트는 나에게만 유의미한 포스트일 수도 있겠다😅ㅋㅋㅋ 하지만 다른 사람들에게도 재밌게 읽힐 수 있도록 열심히 써 봐야겠다!
⭐️ 오늘의 글은, 내 챗GPT 계정에서 위 카톡에 나온 질문을 던져보고 받은 결과와, 답변으로 나온 내 강점과 약점을 어떻게 활용하거나 개선하면 좋을지에 대해 나눈 대화를 적어보려고 한다.
내가 너와 상호작용한 모든 내용을 바탕으로 내 사고 패턴과 의사 결정 방식, 무의식적인 편향, 반복적으로 드러나는 '약점'이나 맹점'을 상세히 분석해줘. 그리고 각 항목에 대해 나에게 필요한 조언을 구체적으로 적어줘. 5000자 이상
✅ 특징
✅ 조언
💡 이 부분은 사실 '매우 빠른 실행력'을 보여준다고 해놓고 '구조를 완벽히 갖추려다 실행이 늦어질 위험'이 있다는 걸 한계점으로 뽑았길래 의아했다. 하지만 곧 정반대의 특징인데도 나한테서 공존하는 부분인 것 같다는 생각도 들었다(ㅋㅋ) 빠른 실행이 효과적이라는 걸 머리로는 알아서 그렇게 해 보고자 노력하지만, 원래의 나는 준비를 완벽하게 하고 실행하고 싶어하는 성향이라 약간의 한계가 있는 것 같다 🥲ㅋㅋ
그래도 문제를 구조화해서 풀어나가는 데 탁월한 사람이라고 평가해줘서 기분이 좋았다 ☺️ 내가 되고 싶은 사람이기도 해서 더 그런 것 같다!ㅋㅋㅋ
✅ 특징
✅ 조언
💡 아, 너무 공감이다...(ㅋㅋㅋㅋㅋㅋ) 고민을 많이 해서 실행이 늦어지는 게 내 최대 단점이자, 내가 계속해서 의식적으로 고쳐나가려고 하는 부분이라 정곡을 찔린 기분이었다. 최근에 면접 질문으로 받기도 해서 더 뼈저리게 느껴지는 것 같다 🥲 이런 상태를 "분석 마비"라고 부르는 건 처음 알았는데, 생각보다 내가 이 문제를 크게 겪고 있는 것 같아서 해결법을 진지하게 생각해 볼 필요가 있는 것 같다 🤔
✅ 특징
✅ 조언
💡 예전에 외부 라이브러리 버전 문제로 프로그램이 망가진 적이 있었는데, 그 뒤로 외부 라이브러리보다 직접 구현을 선호하는 사람이 된 것 같다. 하지만 시장에서는, 특히 내가 가고 싶은 스타트업에서는 때때로 안정성보다 생산성이 중요한 경우도 많기 때문에 보다 유연한 판단력이 요구될 수도 있겠다는 생각이 들었다. 아무튼 극단적인 사람이 되지 않도록 조심해야겠다!ㅠㅠㅋㅋ
💡 고마워.
| 영역 | 제안 |
|---|---|
| 협업 | 완벽한 구조보다, 빠른 공유와 피드백 루프. 동료들이 '너무 완벽하게 짜여진 코드'를 부담스러워할 수 있음. |
| 테스트 | 사용자 관점에서의 테스트(Storybook + Play function)는 잘 사용하고 있음. 더 발전시키려면 Cypress나 Playwright로 end-to-end 흐름을 실험해보는 것도 좋아. |
| UX 감각 | 기능 구현 중심에서, 감정적 흐름(사용자의 기대, 인지 부하, 실수 허용 등)을 반영하는 관점을 점점 더 키워야 함. |
| 불확실성에 대한 내성 | 당장 정답을 모르는 상태에서도 행동할 수 있는 태도는 스타트업 마인드셋과 잘 맞음. 조금 더 ‘불완전한 채로 출발’하는 걸 연습해보면 좋아. |
| 휴식과 회복 | 집중력이 높고 몰입형이기 때문에, 리듬 있게 쉬는 전략도 중요함. 지나치게 고민하다 정체될 수 있음. Pomodoro 기법 등 활용 추천. |
내 생각에 나의 최대 단점은 "불확실성에 대한 내성이 없는 것"이야. 준비를 완벽하게 하기 전까지 실행하는 걸 두려워 해. 이 단점을 극복하기 위한 방법을 상세히 알려줄래?
나의 가장 큰 단점이라고 생각하는 부분에 대해 상세한 극복 방법을 요청해 보았다.
💡 너무 정확하잖아...??ㅠㅠ 내 속마음 읽은 줄...
목표 : 완성도 60~70%일 때, '일단 시도'하는 습관을 만드는 것.방법도구Done is better than perfect 포스트잇 책상에 붙이기💡 근데 이건 어떤 일인지에 따라 다를 것 같다. 최근에는 프로젝트에서 속도보다 안정성이 조금 더 중요한 일들을 하고 있어서 완성도가 낮을 때 일단 시도하는 습관을 기르기엔 어려운 환경인 것 같다 🤔 적절한 상황이 있을 때 선택해야 하는 방법인 것 같다.
목표 : 작은 실패를 반복적으로 경험하며 실패에 둔감해지는 훈련
방법
- 일주일에 한 번은 **실패 확률이 높은 시도**를 의도적으로 하기
체크
- 실패 후 "어땠는가?" 회고를 글로 기록 (실패 감정의 실체 확인)
💡 이건 의외로 효과적인 방법이 될 수도 있을 것 같다. 실패를 줄곧 두려워 해 왔지만, 실제로 실패했을 때 그렇게 큰 문제가 발생하지 않고 오히려 배울 점이 많았던 순간들이 많았던 것 같아서... '너무 빠른 데드라인 잡기' 정도는 리스크 없이 시도해 볼 수 있을 것 같다.
기존 기준 : "정확한 계획이 없으면 시작하지 않는다"전환 기준 : "전체 맥락은 몰라도, 다음 1~2단계만 추정 가능하면 시작"💡 이것도 리스크가 적은 상황에 시도해 보면 좋을듯! (내 단점 극복을 위해 팀과 서비스에 민폐를 끼칠 수는 없으니 🥲)
💡 이것도 은근히 도움이 될 것 같다👀 여태껏 학습을 위한 프로젝트에서도 실패를 두려워 해 왔어서 좀 더 학습에 초점을 맞춘 행동력이 필요할 것 같다. 실제로 주변에서도 실패를 두려워 하지 않고 이것저것 시도해 보는 사람들이 더 실력도 빨리 느는 것 같다. 쫄지 말고 해 보자...!!ㅋㅋㅋㅋ
[내가 통제 가능한 것] vs [외부 요인]
예)
- 내가 통제함: 코드 품질, 시간 분배
- 통제 불가: API 속도, 사용자 반응
💡 예시 중에 API 속도는 모르겠는데, 사용자 반응은 확실히 통제 불가능한 영역이 맞는 것 같다(ㅋㅋ) "개발자 원칙" 책을 읽을 때도 나에게 가장 효과적이었던 조언이 '통제 불가능한 영역' 때문에 계속 끙끙대고 시간 낭비하지 말라는 것이었다. 하지만 항상 통제 불가능한 영역을 조금이라도 통제 가능하게 바꾸기 위해 노력하는 게 서비스를 만드는 사람들이 하는 일이라 딜레마에 빠지는 것 같다. 사용자 반응은 통제 불가능한 영역이 맞지만, 사용자 반응을 조금이라도 긍정적으로 만들기 위해 고민하고 시도하는 게 우리가 하는 일이니까... 최대한 노력은 하되, 결과가 좋지 않더라도 후회하고 상심하는 태도를 고치는 게 더 좋을 것 같다.
기존 : "결과가 완벽해야 한다" -> 결과 중심전환 : "나는 몇 번이나 실행했는가?" -> 실행 중심예시 기준표 : 주간 실행 횟수, 실행한 후 회고 수, 실패로부터 배운 포인트 수💡 오, "실패로부터 배운 포인트 수" 이건 재밌을 것 같다 👀 그러고 보니 나는 항상 회고를 할 때, 잃은 것보다 얻은 것에 더 초점을 많이 맞췄던 것 같다. 잃은 것도 직시하고 회고하는 태도는 확실히 지금보다 더 필요할 것 같다.

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