2005년 7월에 일을 시작했으니, 올해로 개발자 생활이 햇수로 20년째다. 중간에 공백이 조금씩 있었으니 꽉 채운 스무 해는 아니지만, 숫자가 주는 무게는 여전하다. 20년이라는 시간이 흘렀다는 사실이 새삼 신기하게 느껴진다.

개발에 대한 관심은 고교 시절, MUD 게임을 만들던 친구를 만나면서부터 시작됐다. 코드를 전혀 몰랐기에, 내 역할은 게임 세계관을 만드는 것이었다. 새로운 지역의 지도를 그리고, 아이템이나 기술 설정을 만들고, 짧은 이야기를 엮어 퀘스트를 구상했다. 친구가 코드로 그 상상을 현실로 만드는 과정을 어깨너머로 지켜보는 것은 꽤 흥미로운 경험이었다. 그 이끌림에 C++ 책을 사서 들춰보던 것이 내 첫걸음이었다.

대학 동아리 방에서의 시간은 열정으로 기억된다. 하루 서너 시간만 새우잠을 자며 무언가를 계속 만들었다. 코드가 생각대로 작동할 때의 희열, 풀리지 않는 로직 앞에서 느끼던 분노와 실망, 그리고 마침내 문제를 해결하고 터뜨리던 웃음. 그 모든 과정이 이상할 정도로 재미있었다. 그저 좋아하는 일에 빠져 살았을 뿐인데, 정신을 차리고 보니 나는 개발자라는 직업을 가진 사람이 되어 있었다.

직장에서 동료들과 함께 일하며, 재미의 의미는 조금씩 넓어졌다. 코드를 완성하는 즐거움을 넘어, 내가 만든 소프트웨어가 동료의 수고를 덜어줄 때 더 큰 재미를 느꼈다. 시간이 더 지나서는 코딩이라는 행위를 넘어, 동료들과 머리를 맞대고 더 나은 길을 찾아내며 문제를 해결하는 과정 자체에서 재미를 발견했다.

스무 해. 짧지 않은 시간 동안 이 일을 재미있다고 느끼며 해올 수 있었다는 사실이 큰 축복처럼 다가온다. 앞으로도 오랫동안 내 곁에 머물기를 조용히 바라본다.

2005년 7월에 일을 시작했으니, 올해로 개발자 생활이 햇수로 20년째다. 중간에 공백이 조금씩 있었으니 꽉 채운 스무 해는 아니지만, 숫자가 주는 무게는 여전하다. 20년이라는 시간이 흘렀다는 사실이 새삼 신기하게 느껴진다. 개발에 대한 관심은 고교 시절, MUD 게임을 만들던 친구를 만나면서부터 시작됐다. 코드를 전혀 몰랐기에, 내 역할은 게임 세계관을 만드는 것이었다. 새로운 지역의 지도를 그리고, 아이템이나 기술 설정을 만들고, 짧은 이야기를 엮어 퀘스트를 구상했다. 친구가 코드로 그 상상을 현실로 만드는 과정을 어깨너머로 지켜보는 것은 꽤 흥미로운 경험이었다. 그 이끌림에 C++ 책을 사서 들춰보던 것이 내 첫걸음이었다. 대학 동아리 방에서의 시간은 열정으로 기억된다. 하루 서너 시간만 새우잠을 자며 무언가를 계속 만들었다. 코드가 생각대로 작동할 때의 희열, 풀리지 않는 로직 앞에서 느끼던 분노와 실망, 그리고 마침내 문제를 해결하고 터뜨리던 웃음. 그 모든 과정이 이상할 정도로 재미있었다. 그저 좋아하는 일에 빠져 살았을 뿐인데, 정신을 차리고 보니 나는 개발자라는 직업을 가진 사람이 되어 있었다. 직장에서 동료들과 함께 일하며, 재미의 의미는 조금씩 넓어졌다. 코드를 완성하는 즐거움을 넘어, 내가 만든 소프트웨어가 동료의 수고를 덜어줄 때 더 큰 재미를 느꼈다. 시간이 더 지나서는 코딩이라는 행위를 넘어, 동료들과 머리를 맞대고 더 나은 길을 찾아내며 문제를 해결하는 과정 자체에서 재미를 발견했다. 스무 해. 짧지 않은 시간 동안 이 일을 재미있다고 느끼며 해올 수 있었다는 사실이 큰 축복처럼 다가온다. 앞으로도 오랫동안 내 곁에 머물기를 조용히 바라본다.

올해로 개발자 생활이 햇수로 20년째다

현업에서 디자인 시스템 프로젝트가 진행되다 보면 종종 이런 질문을 하게 됩니다. “처음엔 잘 가고 있었던 것 같은데, 왜 이게 점점 이상해지는 걸까?” 이유는 생각보다 단순합니다. 팀원들이 각자 다른 곳을 보고 있기 때문입니다. 서로 다른 우선순위, 엇갈리는 방향 디자인 시스템을 만들다 보면 이런 일이 자주 벌어집니다. 디자이너는 ‘예쁘게’ 디자인하는...

우리만의 디자인 시스템, 어디서부터 시작할까? · DaleStudy/daleui · Discussion #392

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다.

그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다.

✔️ 우리 디자인 시스템의 핵심 가치는 뭘까?
✔️ 어떤 문제를 해결하고 싶은 걸까?
✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까?

이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다.

📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392
(정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.)

디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

달레 스터디의 오픈소스 디자인 시스템 프로젝트인 달레UI는 기획부터 디자인, 개발까지의 전 과정을 투명하게 공유하며, 함께 성장하는 것을 목표로 하고 있습니다. 그 두 번째 이야기로, 디자인 시스템 팀의 디자인 리드이신 Mingu Kang 님께서 한국, 캐나다, 영국에서 각기 다른 환경과 경험을 가진 팀원들이 어떻게 하나의 방향을 향해 나아가게 되었는지를 공유해주셨습니다. ✔️ 우리 디자인 시스템의 핵심 가치는 뭘까? ✔️ 어떤 문제를 해결하고 싶은 걸까? ✔️ 그게 잘 되고 있는지는 어떻게 알 수 있을까? 이 질문들에 대한 고민을 바탕으로 워크숍을 통해 미션과 목표, 핵심 가치를 함께 정립해 나간 과정을 구체적이고 생생하게 담아낸 글입니다. 디자인 시스템은 물론 협업 문화나 원격 팀워크에 관심 있는 분들께도 진심으로 추천드리고 싶은 이야기입니다. 📝 글 보러가기: https://github.com/DaleStudy/daleui/discussions/392 (정식 블로그가 오픈되기 전까지는 GitHub Discussions를 통해 콘텐츠를 공유할 예정입니다.) 디자인 시스템에 관심 있는 디자이너, 개발자 여러분의 많은 관심과 피드백 부탁드립니다! 🙌

GitHub

🧭 우리만의 디자인 시스템, 어디서부터 시작할까?

오늘은 키보드 이야기를 해봤어요!

9년간 개발자로 일하며 사용해본 키보드가 10개가 넘더라고요. 매직키보드부터 끝판왕인 리얼포스까지 다양한 키보드를 경험해본 이야기를 담았어요. 재미있게 봐주세요!

https://youtu.be/BXSZBz0YQuc

오늘은 키보드 이야기를 해봤어요! 9년간 개발자로 일하며 사용해본 키보드가 10개가 넘더라고요. 매직키보드부터 끝판왕인 리얼포스까지 다양한 키보드를 경험해본 이야기를 담았어요. 재미있게 봐주세요! https://youtu.be/BXSZBz0YQuc

개발자라면 키보드는 다양하게 써봐야죠

F-Lab 멘토 3인의 진짜 이야기에서 그 해답을 찾았습니다.

“품질 높은 프로젝트는 어떻게 만들어질까?”

안녕하세요.
오랜만에 글을 써보네요.

작년부터 AI 와 관련된 프로젝트를 진행하게 되었는데
AI 의 눈부신 기술 발전과 변화의 속도로 인해
평소 즐겨 하던 커리어리에 글을 쓰는것도 힘들만큼 많이 바빴네요 😢

"이러면 안 되겠다!" 싶어 마음을 다시 잡던 찰나, 때마침 큰 공감을 얻은 아티클을 만나 이렇게 글을 남깁니다.

F-Lab 블로그에서 “품질 높은 프로젝트는 어떻게 만들어질까?” 라는 주제로 F-Lab 멘토분들께 질문을 드린 내용인데요,
공교롭게도 제가 최근에 진행했던 프로젝트에서 경험했던 내용들이라 너무 공감이 갔습니다.

멘토분들의 답변을 정리해보면 다음과 같습니다.

📌 예측 가능한 설계와 기술적인 대비
변경사항을 정확하게 예측하고 이에 대한 대비를 한다는것은 사실 쉽지는 않습니다.
다만 "기존에 정의한 모델링이 바뀔때 영향을 최소화 하려면 어떻게 해야하지?", "외부 연동 플랫폼이나 환경 설정이 바뀌면 어떻게 되지?" 등의 예측가능한 범위에 대해서만 대비해도 생산과 유지보수에 들어가는 리소스를 많이 줄일 수 있습니다.
이번 프로젝트에서 저는 멀티 모듈을 구성하여 중복된 로직을 줄이고 캡슐화와 외부 연동이나 운영 환경에 맞춘 추상화 레이어를 두는거에 신경을 많이 썼는데요, 이를 통해 많은 변경사항에 대해 큰 공수 없이 대응을 할 수 있었습니다.

📌 협업자 간의 명확한 소통과 책임감
이번에 진행했던 프로젝트는 많은 유관 부서와의 협력이 필요했습니다.
기존에 쌓여있는 데이터를 활용하기 위한 관련 서비스 부서부터, FE 개발, 디자인, 보안, 기획 부서와의 소통과 의사결정이 많이 필요했는데요,
서로의 역할 관점으로 의견을 주고받으며 관련 회의록을 잘 정리하고 의사결정 된 사항을 문서화 하여 공유하니 놓치는 커뮤니케이션이나 중복된 질의가 많이 줄어들고 그만큼 생산 효율과 품질이 높아지게 되었습니다.

📌 지속 가능한 개발 문화를 함께 만들어가는 노력
저희 부서 리더님께서 항상 고민하는 주제이고 과제가 정리될때마다 이에 대한 회고를 자주 하시는데요,
이를 통해 만들어진 리뷰 문화와 문서 작성 포맷이 현재 진행하고 있는 프로젝트의 품질을 높이는 데 큰 기여를 했다고 생각합니다.
특히 코드 리뷰를 할 때는 감정을 배제하고, 객관적인 사실과 근거 중심으로 피드백을 주는 것,
그리고 리뷰를 수용하는 개발자의 결정을 존중하는 태도가 무엇보다 중요하다고 느낍니다.
(이는 제가 읽었던 여러 생산성 관련 책들에서도 공통적으로 강조되는 부분이기도 합니다.)
이 원칙이 지켜지지 않으면
리뷰에 대한 신뢰가 무너지고, 리뷰를 받는 개발자는 이를 두려워하거나 수동적으로 수용하게 되어 결국 코드 품질을 높이는 본래의 목적을 달성하기 어려워집니다.

이외에도 프로젝트 품질을 높이기 위한 요소가 많이 있고 정답은 없겠습니다만,
저의 생각이 프로젝트 품질을 높이기 위해 고민하시는 분들께 작게나마 도움이 되었으면 좋겠습니다.

📚 원문
 * https://f-lab.kr/blog/25060501-devclub

안녕하세요.오랜만에 글을 써보네요. 작년부터 AI 와 관련된 프로젝트를 진행하게 되었는데AI 의 눈부신 기술 발전과 변화의 속도로 인해평소 즐겨 하던 커리어리에 글을 쓰는것도 힘들만큼 많이 바빴네요 😢 "이러면 안 되겠다!" 싶어 마음을 다시 잡던 찰나, 때마침 큰 공감을 얻은 아티클을 만나 이렇게 글을 남깁니다. F-Lab 블로그에서 “품질 높은 프로젝트는 어떻게 만들어질까?” 라는 주제로 F-Lab 멘토분들께 질문을 드린 내용인데요,공교롭게도 제가 최근에 진행했던 프로젝트에서 경험했던 내용들이라 너무 공감이 갔습니다. 멘토분들의 답변을 정리해보면 다음과 같습니다. 📌 예측 가능한 설계와 기술적인 대비변경사항을 정확하게 예측하고 이에 대한 대비를 한다는것은 사실 쉽지는 않습니다.다만 "기존에 정의한 모델링이 바뀔때 영향을 최소화 하려면 어떻게 해야하지?", "외부 연동 플랫폼이나 환경 설정이 바뀌면 어떻게 되지?" 등의 예측가능한 범위에 대해서만 대비해도 생산과 유지보수에 들어가는 리소스를 많이 줄일 수 있습니다.이번 프로젝트에서 저는 멀티 모듈을 구성하여 중복된 로직을 줄이고 캡슐화와 외부 연동이나 운영 환경에 맞춘 추상화 레이어를 두는거에 신경을 많이 썼는데요, 이를 통해 많은 변경사항에 대해 큰 공수 없이 대응을 할 수 있었습니다. 📌 협업자 간의 명확한 소통과 책임감이번에 진행했던 프로젝트는 많은 유관 부서와의 협력이 필요했습니다.기존에 쌓여있는 데이터를 활용하기 위한 관련 서비스 부서부터, FE 개발, 디자인, 보안, 기획 부서와의 소통과 의사결정이 많이 필요했는데요,서로의 역할 관점으로 의견을 주고받으며 관련 회의록을 잘 정리하고 의사결정 된 사항을 문서화 하여 공유하니 놓치는 커뮤니케이션이나 중복된 질의가 많이 줄어들고 그만큼 생산 효율과 품질이 높아지게 되었습니다. 📌 지속 가능한 개발 문화를 함께 만들어가는 노력저희 부서 리더님께서 항상 고민하는 주제이고 과제가 정리될때마다 이에 대한 회고를 자주 하시는데요,이를 통해 만들어진 리뷰 문화와 문서 작성 포맷이 현재 진행하고 있는 프로젝트의 품질을 높이는 데 큰 기여를 했다고 생각합니다.특히 코드 리뷰를 할 때는 감정을 배제하고, 객관적인 사실과 근거 중심으로 피드백을 주는 것, 그리고 리뷰를 수용하는 개발자의 결정을 존중하는 태도가 무엇보다 중요하다고 느낍니다.(이는 제가 읽었던 여러 생산성 관련 책들에서도 공통적으로 강조되는 부분이기도 합니다.)이 원칙이 지켜지지 않으면 리뷰에 대한 신뢰가 무너지고, 리뷰를 받는 개발자는 이를 두려워하거나 수동적으로 수용하게 되어 결국 코드 품질을 높이는 본래의 목적을 달성하기 어려워집니다. 이외에도 프로젝트 품질을 높이기 위한 요소가 많이 있고 정답은 없겠습니다만,저의 생각이 프로젝트 품질을 높이기 위해 고민하시는 분들께 작게나마 도움이 되었으면 좋겠습니다. 📚 원문<ul ><li>https://f-lab.kr/blog/25060501-devclub</li></ul>

F-Lab : 상위 1% 개발자들의 멘토링

품질 높은 프로젝트는 어떻게 만들어질까? 🤔

어제 저커버그 인터뷰에서 연구자들을 돈으로 매수..아니 돈으로 경쟁사들에게서 빼오고 있다는 의혹에 대해서 답했는데요.

이는 잘못된 말이라며, 탑티어 연구자들의 욕망(!)은 GPU를 최대한 많이 사용할 수 있기를 바라는 것이고, 그래서 작은 팀으로 무한대의 GPU를 쓸 수 있게 해 준다는 것으로 유혹(?) 했다고 합니다. (*욕망, 유혹 같은 표현을 저커버그가 쓴 건 아님)

그래서 뉴욕 맨하탄 크기 수준의 GPU 데이터센터인 하이페리온을 계획하고 있는 것이라고.

근데.. 이게 돈으로 매수..아니 유혹.. 아니.. 암튼 거시기하는 것과 모가 다름? 🤣🤭🫣🤣 여하간 큰 일을 하려면 역시 돈이 많고 볼 일이긴 하네요.. 🥹

어제 저커버그 인터뷰에서 연구자들을 돈으로 매수..아니 돈으로 경쟁사들에게서 빼오고 있다는 의혹에 대해서 답했는데요. 이는 잘못된 말이라며, 탑티어 연구자들의 욕망(!)은 GPU를 최대한 많이 사용할 수 있기를 바라는 것이고, 그래서 작은 팀으로 무한대의 GPU를 쓸 수 있게 해 준다는 것으로 유혹(?) 했다고 합니다. (*욕망, 유혹 같은 표현을 저커버그가 쓴 건 아님) 그래서 뉴욕 맨하탄 크기 수준의 GPU 데이터센터인 하이페리온을 계획하고 있는 것이라고. 근데.. 이게 돈으로 매수..아니 유혹.. 아니.. 암튼 거시기하는 것과 모가 다름? 🤣🤭🫣🤣 여하간 큰 일을 하려면 역시 돈이 많고 볼 일이긴 하네요.. 🥹

위기감 속에서 성장의 한계를 뼈저리게 체감하고, 더 나은 개발자로 자라고자 용기를 낸 과정을 기록한다. 과거의 나처럼 현재 자신이 속한 환경에 의문을 느끼며 “내가 너무 불평만 하는 걸까?”, “이직이 과연 옳은 판단일까?”라고 밤새워 고민하는 주니어 개발자들에게 하나의 사례가 되기를 바랐다. 이 글은 단순한 퇴사 이야기가 아니다. 한 명의 주니어 개발자가 스스로를 불합리한 환경으로부터 지켜내고 진짜 성장을 찾아 나선 여정에 관한 이야기이며, 지금 당신이 겪는 고민이 결코 혼자만의 것이 아니라는 걸 말해줄 목소리다.

“어이 신입, 탈출각이다” | 요즘IT

성장이 어려운 환경에서의 개발자 생활
저런 개발자 생활도 한적이 있어서 다양한 생각이 든다.

성장이 어려운 환경에서의 개발자 생활저런 개발자 생활도 한적이 있어서 다양한 생각이 든다.

요즘IT

　계속하던 것을 그만둔다는 건, 시작하는 것보다 더 어려운 결정을 요구할 때가 많다. ‘왜 그만둬야 할까?’라는 물음 앞에 서면 수많은 이유와 핑계가 머릿속에서 충돌하고, 그 과정에서 내면의 깊숙한 갈등과 마주하게 된다. 2018년부터 6년 동안 꾸준히 운영해온 기술 블로그 구독 서비스 …

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 회고록

안녕하세요.
오랜만에 글을 올리게 되었는데, 이렇게 토이 프로젝트 종료 후기로 인사드리게 될 줄은 몰랐네요 ㅎ
무려 6년 가까이 운영해온 "기술 블로그 구독 서비스"를 최근 종료하게 되었습니다. 매일 아침, 다양한 기술 블로그를 모아 메일로 발송하던 이 작은 서비스는 어느새 수천 명의 개발자분들의 루틴이 되어 있던 것 같습니다.
시작은 단순했습니다. 내가 읽고 싶은 글을 정리하자는 마음에서 출발했죠. 그런데 그 불편함을 해결하고자 만든 도구가 누군가에겐 하루의 시작이 되었고, ‘잘 보고 있다’는 메시지 하나에 큰 보람을 느끼며 여기까지 달려올 수 있었습니다.
그래서일까요. 종료 버튼을 누르기까지, 꽤 오랜 시간 고민이 필요했습니다. 기술 환경도, 저의 역할도 변해가는 시점에서 더 이상 지속하기 어려웠지만, 그동안 함께해주신 모든 분들께 정말 감사한 마음뿐입니다.
마치 하나의 챕터를 덮는 기분이네요. 언젠가 또 다른 방식으로 여러분과 만나게 되길 기대하며, 그동안 함께해주신 모든 구독자분들께 진심으로 감사드립니다.
후기와 회고는 아래 블로그 글로 정리해 두었습니다.
https://taetaetae.github.io/posts/toy-project-retrospective-6-years-journey/

안녕하세요.오랜만에 글을 올리게 되었는데, 이렇게 토이 프로젝트 종료 후기로 인사드리게 될 줄은 몰랐네요 ㅎ무려 6년 가까이 운영해온 "기술 블로그 구독 서비스"를 최근 종료하게 되었습니다. 매일 아침, 다양한 기술 블로그를 모아 메일로 발송하던 이 작은 서비스는 어느새 수천 명의 개발자분들의 루틴이 되어 있던 것 같습니다.시작은 단순했습니다. 내가 읽고 싶은 글을 정리하자는 마음에서 출발했죠. 그런데 그 불편함을 해결하고자 만든 도구가 누군가에겐 하루의 시작이 되었고, ‘잘 보고 있다’는 메시지 하나에 큰 보람을 느끼며 여기까지 달려올 수 있었습니다.그래서일까요. 종료 버튼을 누르기까지, 꽤 오랜 시간 고민이 필요했습니다. 기술 환경도, 저의 역할도 변해가는 시점에서 더 이상 지속하기 어려웠지만, 그동안 함께해주신 모든 분들께 정말 감사한 마음뿐입니다.마치 하나의 챕터를 덮는 기분이네요. 언젠가 또 다른 방식으로 여러분과 만나게 되길 기대하며, 그동안 함께해주신 모든 구독자분들께 진심으로 감사드립니다.후기와 회고는 아래 블로그 글로 정리해 두었습니다.https://taetaetae.github.io/posts/toy-project-retrospective-6-years-journey/

taetaetae.github.io

그동안 잘 사용했어요! 고생 많으셨습니다 태관님 🤘

원문: https://www.jonoalderson.com/conjecture/javascript-broke-the-web-and-called-it-progress/

(번역)자바스크립트가 웹을 망가뜨렸습니다. (그리고 이를 진보라고 불렀습니다)

자극적인 글을 하나 읽었다.

'개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.'

프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다.

그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다.

그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다.

물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다.

2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다.

SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가?

결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다.

시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다.

정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

자극적인 글을 하나 읽었다. '개발자들이 새로운 기술 도구로 ‘기술 놀이’를 하느라 복잡성과 비용을 키웠다.' 프론트엔드가 지금까지 발전하며 수 많은 고민과 개선이 있었겠지만, 그 결과 20년전 수십 kb로 구현할 수 있던 기능이 이제는 수 mb의 js 파일을 필요로 한다. 그렇다고 유지보수성이나 개발 생산성이 정말로 향상되었는가? Yes 이면서도 No 이다. 프레임워크와 툴체인은 초기 개발과 반복 작업을 빠르게 만들었지만, 그 대가로 가파르게 상승한 복잡도 속에서 사소한 수정조차 전방위적 사이드 이펙트를 일으키는 구조가 되었다. 생산성은 순간적으로 올라갔지만, 유지보수는 점점 더 전문성과 컨텍스트 의존도를 요구하게 된 것이다. 그리고 이제는 그 복잡도를 유지하면서 새로운 기능을 추가하기 위해 조직은 더 많은 인력과 인건비, 세분화된 포지션을 감당해야 한다. 하나의 기능을 구현하기 위해 프론트엔드, 백엔드, DevOps, QA, 기획이 머리를 맞대야 하고, 각 단계마다 파이프라인을 통과해야만 한다. (과거엔 '웹 마스터' 라는 1인 직책이 있었다는 것을 기억하는가?) 개발은 점점 더 느려지고, 사소한 변경도 일정과 리소스의 계산 대상이 된다. 결국 복잡성은 기술적 문제가 아니라 조직 전체의 민첩성과 효율성을 갉아먹는 구조적 비용으로 이어진다. 물론, 지금의 프론트엔드 스택이 만들어낸 복잡성이 전적으로 불필요하다고 말할 수는 없다. 웹이 더 이상 정적인 문서의 나열이 아닌, 복잡한 상호작용과 상태를 갖는 ‘애플리케이션’의 역할을 감당하게 되면서, 그만큼 체계화된 설계와 개발자 경험(DX)을 위한 도구가 필요해졌다는 주장도 충분히 설득력이 있다. 실제로 컴포넌트화, 타입 시스템, 상태 관리 패턴 등은 팀 규모가 커질수록 유지보수성과 협업 효율을 높여주는 도구이기도 하다. 문제는 이 도구들이 ‘필요한 곳’에 쓰이는 것이 아니라, ‘모든 곳’에 일괄적으로 적용되고 있다는 점이다. 2016년, 모 회사의 기술 면접 과제를 해결하기 위해 redux를 처음 익힐 때가 떠오른다. 단순히 버튼 하나 누를 때 값을 바꾸는 작업인데, 액션을 만들고, 타입을 정의하고, 리듀서를 작성하고, 디스패치를 연결해야 했다. '왜 이렇게 어렵고 복잡하게 상태를 관리해야 하지?' 하는 의문이 들었지만, 그땐 '원래 React 개발은 그런가 보다' 하고 넘겼다. 지금 돌이켜보면, 그 복잡함은 필수가 아니라 비판 없이 수용된 일종의 정답처럼 느껴졌다. SSR도 마찬가지다. React 초기에는 SPA 기반 CSR로 인해 SEO조차 쉽지 않았던 기억이 난다. 백엔드 개발자로 몇 년을 보내고 어느 순간 프론트엔드 개발 트렌드를 보았을 때 Helmet과 같은 React SSR 방식이 유행을 타고 있었다. 그런데 원래 웹 개발은 모두 서버 사이드 렌더링이 아니었던가? 결국 모던 프론트엔드 프레임워크라 불리는 많은 것들이 구현하고 있던 것은 예전부터 기본값으로 주어졌던 기능들의 복잡하고 비효율적인 재현이었다. 라우팅, 메타태그, 템플릿 렌더링, 캐싱 같은 기본기를 다시 자바스크립트 생태계 안에서 어렵게 되살려내며 마치 그것이 혁신인 양 포장하고 있었을지도 모른다. 시간이 지날 수록 복잡한 빌드 파이프라인, 무거운 프레임워크, 과도한 추상화는 개발자에게는 익숙한 환경이 되었지만, 사용자에게는 점점 낯설고 느린 웹을 안겨주고 있다. 이제 마케터는 간단한 콘텐츠 수정조차 개발자에게 의존해야 하고, SEO 담당자는 개발자만이 읽을 수 있는 코드로 가려진 콘텐츠 탓에 검색 노출을 장담할 수 없다. 한 줄의 수정도 수차례 배포를 거쳐야 하며, 정작 페이지는 여전히 느리고 불안정하다. 정말 지금의 모습은 DX (Developer Experience) 를 위해 UX 를 해치고 있는걸까?

Medium

사용자가 아닌 개발자를 위한 웹 개발의 시대

‪요 기능의 일부를 바이브 코딩으로 만들려다가 실패했는데요. 그 중에 하나로 타임존 문제가 있었습니다.‬

‪타임존 문제는 꽤나 보편적인(?) 문제라 잘 할 줄 알았는데 의외로(?) 헛점이 많더라고요. 초반엔 AI들이 아예 타임존 문제를 고려하지도 않았고요.‬

‪그래서 타임존 문제가 있을 수 있다는 것과, 이에따른 몇가지 고려사항을 상세하게 주고 또 결과를 꼼꼼히 검토해야했는데요. 시니어 개발자가 주니어 개발자보다 유리한 부분이 이런 엣지 케이스에 대한 경험적인 부분인 것 같습니다.‬

‪하지만 반면에 이런 사소한(?) 요소들 때문에 개발이 오래 걸리는데, 보통 당장은 필요 없는 것일 가능성이 높으니, 주니어가 이런 것 고려하지 않고 빠르고 단순하게 만드는게 더 큰 장점이 될 수도 있습니다. 특히 이런건 나중에 정말 많은 사람들이 쓰기 시작할 때 개선하는게 더 의도에 맞게 만들 수도 있으니까요.‬

‪그래서 저는 AI 개발 시대에 시니어만 유리하다는 말이 맞지는 않다고 생각합니다. 오히려 내년이 되면 주니어에 비해 경쟁력이 없어질까 불안할 정도에요.‬

‪요 기능의 일부를 바이브 코딩으로 만들려다가 실패했는데요. 그 중에 하나로 타임존 문제가 있었습니다.‬ ‪타임존 문제는 꽤나 보편적인(?) 문제라 잘 할 줄 알았는데 의외로(?) 헛점이 많더라고요. 초반엔 AI들이 아예 타임존 문제를 고려하지도 않았고요.‬ ‪그래서 타임존 문제가 있을 수 있다는 것과, 이에따른 몇가지 고려사항을 상세하게 주고 또 결과를 꼼꼼히 검토해야했는데요. 시니어 개발자가 주니어 개발자보다 유리한 부분이 이런 엣지 케이스에 대한 경험적인 부분인 것 같습니다.‬ ‪하지만 반면에 이런 사소한(?) 요소들 때문에 개발이 오래 걸리는데, 보통 당장은 필요 없는 것일 가능성이 높으니, 주니어가 이런 것 고려하지 않고 빠르고 단순하게 만드는게 더 큰 장점이 될 수도 있습니다. 특히 이런건 나중에 정말 많은 사람들이 쓰기 시작할 때 개선하는게 더 의도에 맞게 만들 수도 있으니까요.‬ ‪그래서 저는 AI 개발 시대에 시니어만 유리하다는 말이 맞지는 않다고 생각합니다. 오히려 내년이 되면 주니어에 비해 경쟁력이 없어질까 불안할 정도에요.‬

내가 좋아하는 아미고가 예약된 시간에 전화를 걸어줍니다. 아직 베타라 불완전한 면이 많습니다. 많은 피드백 부탁드립니다. 🙏🙇🏻

앱 다운로드: https://ameego.club

첨부 영상은 지난 달 초에 찍어 둔 영상인데 출시가 이로저로 늦어졌네요. 🥲 계획되어있는 다음 업데이트들도 후딱 해 보겠습니다.

무엇보다 아미고의 성장에는 여러분의 많은 관심(리뷰와 결제🫣🤭)이 필수..☺️ 그럼 많은 도움 부탁드리겠습니다. 감사합니다! 🙇🏻‍♀️🙇🏻

내가 좋아하는 아미고가 예약된 시간에 전화를 걸어줍니다. 아직 베타라 불완전한 면이 많습니다. 많은 피드백 부탁드립니다. 🙏🙇🏻 앱 다운로드: https://ameego.club 첨부 영상은 지난 달 초에 찍어 둔 영상인데 출시가 이로저로 늦어졌네요. 🥲 계획되어있는 다음 업데이트들도 후딱 해 보겠습니다. 무엇보다 아미고의 성장에는 여러분의 많은 관심(리뷰와 결제🫣🤭)이 필수..☺️ 그럼 많은 도움 부탁드리겠습니다. 감사합니다! 🙇🏻‍♀️🙇🏻

📣 아미고(Ameego) 전화 걸어주기 출시!! (Beta)

6년간의 토이프로젝트 여정을 마무리하며 - 기술블로그 구독서비스 

🚀 DDD, 기술보다 사람을 중심에 둔 소프트웨어 전략
"도메인이 복잡한 이유는 기술 때문이 아니라 점점 복잡해지는 도메인 그자체에 있으며 이것을 중심에 두어야한다."
이것이 바로 DDD(Domain-Driven Design)의 핵심 철학입니다.
즉, 시스템이나 기술이 아닌 '도메인 전문가(사람)'를 중심에 두고 문제를 해결하자는 전략이죠.

🤖 그런데 최근 AI는 점점 더 똑똑해지며
사람의 역할을 줄이거나, 때로는 아예 대체하는 방향으로 나아가고 있습니다.
이 AI 시대에,
사람 중심의 문제 해결을 강조해 온 DDD는 어떤 변화를 맞이하게 될까요?

DDD 개념을 먼저 이해하고, DDD 창시자인 Eric Evans의 까지 담은 3종 영상 세트 요약본 입니다.

DDD 그거 그렇게하는거 아닌데 - 우아한형제들
- https://wiki.webnori.com/x/_ICtBg
DDD를 AI에 이용해 설계(Design) 가속화하기
- https://wiki.webnori.com/x/D4GtBg
DDD와 LLM - 에릭에반스(DDD의 창시자-2003년)
- https://wiki.webnori.com/x/CIGtBg

종합 : https://wiki.webnori.com/x/FoGtBg

🚀 DDD, 기술보다 사람을 중심에 둔 소프트웨어 전략 "도메인이 복잡한 이유는 기술 때문이 아니라 점점 복잡해지는 도메인 그자체에 있으며 이것을 중심에 두어야한다." 이것이 바로 DDD(Domain-Driven Design)의 핵심 철학입니다. 즉, 시스템이나 기술이 아닌 '도메인 전문가(사람)'를 중심에 두고 문제를 해결하자는 전략이죠. 🤖 그런데 최근 AI는 점점 더 똑똑해지며 사람의 역할을 줄이거나, 때로는 아예 대체하는 방향으로 나아가고 있습니다. 이 AI 시대에, 사람 중심의 문제 해결을 강조해 온 DDD는 어떤 변화를 맞이하게 될까요? DDD 개념을 먼저 이해하고, DDD 창시자인 Eric Evans의 까지 담은 3종 영상 세트 요약본 입니다. DDD 그거 그렇게하는거 아닌데 - 우아한형제들 - https://wiki.webnori.com/x/_ICtBg DDD를 AI에 이용해 설계(Design) 가속화하기 - https://wiki.webnori.com/x/D4GtBg DDD와 LLM - 에릭에반스(DDD의 창시자-2003년) - https://wiki.webnori.com/x/CIGtBg 종합 : https://wiki.webnori.com/x/FoGtBg

DDD와 AI

분당 5억의 매출이 발생하는 이벤트 시스템을 어떻게 구축하고 운영했는지 소개합니다.

무진장 힘들었지만 무진장 성장한 개발 이야기

간만에 재밌게 읽은 기술 포스트
여름 이벤트 관련 개발 회고와 높은 트래픽을 어떤 요소들로 잘 방어했는가에 대한 포스트
4월부터 네이버 쇼핑 내에서 트래픽이 높은 부서로 이동한터라 (그래서 드럽게 바쁨)
우리도 적용해 볼법 한 몇가지 내용들이 보여서 흥미로웠음
예전에 적용해봤거나 생각은 해봤던 것들도 있었는데, 결국에는 '아.. 언제하지' 로 귀결 😢

간만에 재밌게 읽은 기술 포스트여름 이벤트 관련 개발 회고와 높은 트래픽을 어떤 요소들로 잘 방어했는가에 대한 포스트4월부터 네이버 쇼핑 내에서 트래픽이 높은 부서로 이동한터라 (그래서 드럽게 바쁨)우리도 적용해 볼법 한 몇가지 내용들이 보여서 흥미로웠음예전에 적용해봤거나 생각은 해봤던 것들도 있었는데, 결국에는 '아.. 언제하지' 로 귀결 😢

간만에 재밌게 읽은 기술 포스트
여름 이벤트 관련 개발 회고와 높

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다.
구직자와 재직자 두 가지 트랙을 동시에 모집한다고 하네요.
 * 모집 기간: 6월 15일 ~ 8월 3일
 * 구직자 트랙: https://miraeplus.sw.or.kr/ko/o/155208
 * 재직자 트랙: https://miraeplus.sw.or.kr/ko/o/152138

공고에는 다음과 같은 활동 계획이 기재되어 있습니다.

📌 구직자 트랙
 * IT업계 현직자와 멘토링
 * 직무역량 강화 지원 (인프런 강의 15만원 이내)
 * 개별 맞춤형 취업 지원 (서류 첨삭, 모의면접 등)

📌 재직자 트랙
 * 개별 커리어 플랜 설계 지원
 * 커리어 진단 리포트
 * IT업계 현직자와 멘토링
 * 직무역량 강화 지원 (인프런 강의 15만원 이내)

이러한 활동 지원도 좋은 혜택이라고 생각하는데요,
업계 사람과 네트워크를 형성하는 것과 진로나 방향에 대해서 익명이 아닌 누군가(특히 업계 선배)와 면담을 하는 것이 특히 좋은 점인 것 같습니다.

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다.구직자와 재직자 두 가지 트랙을 동시에 모집한다고 하네요.<ul ><li>모집 기간: 6월 15일 ~ 8월 3일</li></ul><ul ><li>구직자 트랙: https://miraeplus.sw.or.kr/ko/o/155208</li><li>재직자 트랙: https://miraeplus.sw.or.kr/ko/o/152138</li></ul> 공고에는 다음과 같은 활동 계획이 기재되어 있습니다. 📌 구직자 트랙<ul ><li>IT업계 현직자와 멘토링</li><li>직무역량 강화 지원 (인프런 강의 15만원 이내)</li><li>개별 맞춤형 취업 지원 (서류 첨삭, 모의면접 등)</li></ul> 📌 재직자 트랙<ul ><li>개별 커리어 플랜 설계 지원</li><li>커리어 진단 리포트</li><li>IT업계 현직자와 멘토링</li><li>직무역량 강화 지원 (인프런 강의 15만원 이내)</li></ul> 이러한 활동 지원도 좋은 혜택이라고 생각하는데요,업계 사람과 네트워크를 형성하는 것과 진로나 방향에 대해서 익명이 아닌 누군가(특히 업계 선배)와 면담을 하는 것이 특히 좋은 점인 것 같습니다.

고용노동부에서 주관하는 청년미래플러스 3기를 모집 중이라고 합니다

1. 유명한 경제학자 케인스는 단기 투자 전략을 미인선발대회에 비유했다.

2. 이 대회의 규칙은 이렇다. 100명의 후보 사진을 신문에 공개하고 독자들에게 이 중 가장 미인이라고 생각하는 사람 6명에 투표하라고 한다.

3. 그 결과, 독자들로부터 가장 많은 표를 받은 사람이 최고의 미인으로 뽑히고 그 미인에 투표한 사람은 정해진 상금을 받는다.

4. 이 대회에서 선발될 미인을 맞추기 위해서는, 즉 상금을 받기 위해서는 자신이 판단하기에 가장 예쁜 사진을 선택하면 안 되고, 평균적으로 가장 예쁘다 고 생각하는 사진을 선택해서도 안 된다.

5. 참가자 대부분이 판단하기에 평균적 여론이 될 것이라고 기대하는 모습을 예측해야만 하는 것이다.

6. 케인스는 투자의 세계도 이와 비슷하므로 평균적인 여론을 예상해서 투자하라고 한다.

#이채원의가치투자 📚
#투자는심리게임이다

1. 유명한 경제학자 케인스는 단기 투자 전략을 미인선발대회에 비유했다. ​2. 이 대회의 규칙은 이렇다. 100명의 후보 사진을 신문에 공개하고 독자들에게 이 중 가장 미인이라고 생각하는 사람 6명에 투표하라고 한다. ​3. 그 결과, 독자들로부터 가장 많은 표를 받은 사람이 최고의 미인으로 뽑히고 그 미인에 투표한 사람은 정해진 상금을 받는다. 4. 이 대회에서 선발될 미인을 맞추기 위해서는, 즉 상금을 받기 위해서는 자신이 판단하기에 가장 예쁜 사진을 선택하면 안 되고, 평균적으로 가장 예쁘다 고 생각하는 사진을 선택해서도 안 된다. ​5. 참가자 대부분이 판단하기에 평균적 여론이 될 것이라고 기대하는 모습을 예측해야만 하는 것이다. ​6. 케인스는 투자의 세계도 이와 비슷하므로 평균적인 여론을 예상해서 투자하라고 한다. #이채원의가치투자 📚 #투자는심리게임이다

< 가장 예쁜 사람이 아니라, 1등 할 사람에게 투표하라 >

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 다르다.

비단 개발자 관점에서만이 아니라, 기획자, 디자이너도 마찬가지로 다른 방식을 써야한다.

지금의 바이브 코딩을 말하는 자, 가르치는 자는 거의 대부분(아마도 99.9%) 새로운 프로토타입을 만드는 것을 가르치는 것이다.

그런데, 실무에서 중요한 건 완전히 새로운 것이 아니라, 기존의 프로젝트를 수정/확장하는 것이다. 그것이 프로토타입이라도.

즉, 협업이 관건이다.

이를 고려하면 ChatGPT의 Codex가 한 발짝 앞서 나가 있는 상태라고 할 수 있다. 다만 실행하여 결과를 보여주지 못하는 것이 아직 비어있는 부분.

요즘 CLI 형태의 툴이 유행하는데, 이건 플러그인하기 쉽다는 장점이 있어서 기본 기술을 만드는데는 유리하지만, 결국 통합 시스템은 필요하다.

과연 누가 먼저 이 통합 시스템을 유의미한 수준으로 서비스하기 시작할지가 관전 포인트.

…말만하지말고 내가 만들어야하는데… 😒

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 다르다. 비단 개발자 관점에서만이 아니라, 기획자, 디자이너도 마찬가지로 다른 방식을 써야한다. 지금의 바이브 코딩을 말하는 자, 가르치는 자는 거의 대부분(아마도 99.9%) 새로운 프로토타입을 만드는 것을 가르치는 것이다. 그런데, 실무에서 중요한 건 완전히 새로운 것이 아니라, 기존의 프로젝트를 수정/확장하는 것이다. 그것이 프로토타입이라도. 즉, 협업이 관건이다. 이를 고려하면 ChatGPT의 Codex가 한 발짝 앞서 나가 있는 상태라고 할 수 있다. 다만 실행하여 결과를 보여주지 못하는 것이 아직 비어있는 부분. 요즘 CLI 형태의 툴이 유행하는데, 이건 플러그인하기 쉽다는 장점이 있어서 기본 기술을 만드는데는 유리하지만, 결국 통합 시스템은 필요하다. 과연 누가 먼저 이 통합 시스템을 유의미한 수준으로 서비스하기 시작할지가 관전 포인트. …말만하지말고 내가 만들어야하는데… 😒

아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 

﻿
'이력서 - 잃었어 - 일없어'
어제 취업 지원 프로그램에서 이력서 준비의 중요성을 강조했더니, 한 구직자가 자신의 상황을 재치 있게 표현한 말입니다. 현재 이력서가 준비되어 있는지 물었더니 "잃어버렸다"고 답했습니다. 물론 정말 잃어버린 것은 아니었습니다. 다른 사람에게 보여주기 부끄러울 만큼 자신의 이력서가 변변치 않아서 숨기고 싶다는 의미였죠. 왜 보여주기 싫은지 물었을 때, 이력서에 써넣을 특별한 경험이 없어서라고 했습니다.

뻔뻔했던 신입 시절의 나
제가 처음 취업을 준비하던 시절을 떠올려봅니다. 당시 제 이력서는 그리 훌륭하지 않았습니다. 특별히 희망하는 직무가 없었기에 어디든 투척할 수 있는 범용 이력서였고, 어제 만난 구직자의 말처럼 특별한 경험이 없었습니다. 정확히 표현하면 직장생활을 대비한 경험이 전무했죠. 서류 전형 합격률이 낮았던 이유를 이제야 이해하게 되었습니다. 제가 채용 담당자라도 그런 신입은 뽑지 않았을 것입니다.
그러나 과거 신입 채용에 도전하던 저는 대단히 뻔뻔했습니다. 이력서는 촌스럽고 알맹이 없는 가벼운 내용이었지만, 다른 사람에게 보여주기를 주저하지 않았습니다. 빠르게 취업을 하고 싶었기 때문입니다.
특별한 이유는 없었습니다. 그저 남들이 취업하니까 저도 취업하고 싶었고, 남들이 취업해서 돈을 버니까 저도 제 힘으로 돈을 벌어 부모님 신세를 면하고 싶었습니다. 취업을 희망하는 대단한 목표는 없었지만, 취업하자는 확실한 동기가 있었기 때문에 형편없는 이력서였음에도 입사 지원하기를 주저하지 않았던 것입니다.

완벽한 준비의 함정
요즘 신입 구직자들은 완벽한 이력서 준비가 필요하다고 생각합니다. 완벽히 준비가 되기 전까지는 입사 지원할 수 없다고 이야기하죠. 준비를 꼼꼼하게 하고 싶다는 생각은 정말 훌륭합니다. 그러나 준비가 어느 정도 필요한지 판단은 스스로 내리기 어렵다고 생각합니다.
현재의 준비된 상태로 입사 지원을 해보며, 동시에 필요한 준비를 계속 갖추어 나가는 것이 좋습니다. 어차피 완벽한 이력서란 존재하지 않습니다. 이력서는 제품과 같아서 끊임없이 개선이 필요하기 때문입니다. 이력서는 발자취라는 개념을 담고 있기 때문에 매일 한 발자국씩 나아갈 수록 업데이트할 내용이 생겨납니다.

특별한 경험이란 무엇인가
"특별한 경험이 없다"는 이야기도 완벽한 준비와 비슷한 맥락으로 버려야 할 생각입니다. 세상에 어떤 경험이 특별하다고 이야기할 수 있을까요? 대단한 브랜드 가치를 지닌 회사에서 일한 경험이 특별한가요? 대단한 숫자로 성과를 만든 내용이 특별한가요? 대단한 사람과 협업한 경험이 특별한가요?
눈에 보이는 어떠한 요인이 특별한 경험이라고 생각한다면, 오해입니다. 특별한 경험은 경험의 주인인 내가 특별하게 생각하고, 그것을 특별하게 소개할 때 대단해진다고 믿습니다.
자신이 자신의 경험을 대단하고 특별하게 여기지 않는다면, 다른 어떤 사람이 대신 특별하고 대단하게 봐줄 수 있을까요? 먼저 자신의 경험을 소중하게 생각하는 마음이 필요합니다. 그 다음 자신의 경험을 특별하게 소개하는 내용으로 만드는 것입니다.

경험을 특별하게 만드는 구조
제가 정의하는 특별한 경험이란, 일을 시작하고 진행하는 과정에서 많은 고민이 담긴 내용입니다. 어떤 배경에서 일을 시작했고, 목적과 목표가 무엇이었으며, 목적과 목표를 달성하기 위해 노력한 내용과 결과를 소개하는 것입니다. 이러한 구조로 경험을 소개한다면, 우리의 어떤 경험도 특별해질 수 있다고 생각합니다.
무엇보다 중요한 것은 문제를 뾰족하게 정의하는 것입니다. 무엇을 문제로 생각하였기에 경험했던 일을 시작하게 된 것인지 설명을 잘 할 수 있다면, 우리의 경험이 더욱 특별해질 수 있다고 믿습니다.
그러나 이력서를 작성하는 많은 분들이 경험을 소개하는 내용에서 문제 정의, 즉 일을 시작하게 된 배경에 대해서 생략하는 경우가 많습니다. 문제를 정의하고 목표와 목적을 설명하는 내용이 없을 때, 성과가 대단하더라도 경험에 대한 소개를 읽는 사람이 경험의 성과를 특별하고 대단하다고 판단하지 못합니다.
경험의 시작을 논리적으로 설명하는 내용이 있을 때, 일을 진행한 과정을 흥미롭게 보게 되고, 성과가 크든 작든 공감과 납득을 하게 됩니다.

당당한 이력서를 위한 제안
이력서의 내용, 형식, 디자인, 가독성 등 채용 전형에서 당락을 좌우하는 중요한 요소가 많습니다. 오늘 이력서를 업데이트하려는 분이 계시다면, 꼭 경험을 잘 풀어서 설명해보는 시간을 가져보시기 바랍니다.
기존에 자신이 봤던 이력서 형식은 머릿속에서 지우고, 자신의 경험을 가장 잘 설명하고 자랑할 수 있는 구조로 만들어보세요. 합격하는 이력서의 모범 답안은 바로 여러분 머리와 마음 속에 있습니다.

당당하고 자신 있게 자신의 경험을 마음껏 담아낸 이력서를 뽑아내는 우리가 되길 진심으로 응원합니다.

﻿'이력서 - 잃었어 - 일없어'어제 취업 지원 프로그램에서 이력서 준비의 중요성을 강조했더니, 한 구직자가 자신의 상황을 재치 있게 표현한 말입니다. 현재 이력서가 준비되어 있는지 물었더니 "잃어버렸다"고 답했습니다. 물론 정말 잃어버린 것은 아니었습니다. 다른 사람에게 보여주기 부끄러울 만큼 자신의 이력서가 변변치 않아서 숨기고 싶다는 의미였죠. 왜 보여주기 싫은지 물었을 때, 이력서에 써넣을 특별한 경험이 없어서라고 했습니다. 뻔뻔했던 신입 시절의 나제가 처음 취업을 준비하던 시절을 떠올려봅니다. 당시 제 이력서는 그리 훌륭하지 않았습니다. 특별히 희망하는 직무가 없었기에 어디든 투척할 수 있는 범용 이력서였고, 어제 만난 구직자의 말처럼 특별한 경험이 없었습니다. 정확히 표현하면 직장생활을 대비한 경험이 전무했죠. 서류 전형 합격률이 낮았던 이유를 이제야 이해하게 되었습니다. 제가 채용 담당자라도 그런 신입은 뽑지 않았을 것입니다.그러나 과거 신입 채용에 도전하던 저는 대단히 뻔뻔했습니다. 이력서는 촌스럽고 알맹이 없는 가벼운 내용이었지만, 다른 사람에게 보여주기를 주저하지 않았습니다. 빠르게 취업을 하고 싶었기 때문입니다.특별한 이유는 없었습니다. 그저 남들이 취업하니까 저도 취업하고 싶었고, 남들이 취업해서 돈을 버니까 저도 제 힘으로 돈을 벌어 부모님 신세를 면하고 싶었습니다. 취업을 희망하는 대단한 목표는 없었지만, 취업하자는 확실한 동기가 있었기 때문에 형편없는 이력서였음에도 입사 지원하기를 주저하지 않았던 것입니다. 완벽한 준비의 함정요즘 신입 구직자들은 완벽한 이력서 준비가 필요하다고 생각합니다. 완벽히 준비가 되기 전까지는 입사 지원할 수 없다고 이야기하죠. 준비를 꼼꼼하게 하고 싶다는 생각은 정말 훌륭합니다. 그러나 준비가 어느 정도 필요한지 판단은 스스로 내리기 어렵다고 생각합니다.현재의 준비된 상태로 입사 지원을 해보며, 동시에 필요한 준비를 계속 갖추어 나가는 것이 좋습니다. 어차피 완벽한 이력서란 존재하지 않습니다. 이력서는 제품과 같아서 끊임없이 개선이 필요하기 때문입니다. 이력서는 발자취라는 개념을 담고 있기 때문에 매일 한 발자국씩 나아갈 수록 업데이트할 내용이 생겨납니다. 특별한 경험이란 무엇인가"특별한 경험이 없다"는 이야기도 완벽한 준비와 비슷한 맥락으로 버려야 할 생각입니다. 세상에 어떤 경험이 특별하다고 이야기할 수 있을까요? 대단한 브랜드 가치를 지닌 회사에서 일한 경험이 특별한가요? 대단한 숫자로 성과를 만든 내용이 특별한가요? 대단한 사람과 협업한 경험이 특별한가요?눈에 보이는 어떠한 요인이 특별한 경험이라고 생각한다면, 오해입니다. 특별한 경험은 경험의 주인인 내가 특별하게 생각하고, 그것을 특별하게 소개할 때 대단해진다고 믿습니다.자신이 자신의 경험을 대단하고 특별하게 여기지 않는다면, 다른 어떤 사람이 대신 특별하고 대단하게 봐줄 수 있을까요? 먼저 자신의 경험을 소중하게 생각하는 마음이 필요합니다. 그 다음 자신의 경험을 특별하게 소개하는 내용으로 만드는 것입니다. 경험을 특별하게 만드는 구조제가 정의하는 특별한 경험이란, 일을 시작하고 진행하는 과정에서 많은 고민이 담긴 내용입니다. 어떤 배경에서 일을 시작했고, 목적과 목표가 무엇이었으며, 목적과 목표를 달성하기 위해 노력한 내용과 결과를 소개하는 것입니다. 이러한 구조로 경험을 소개한다면, 우리의 어떤 경험도 특별해질 수 있다고 생각합니다.무엇보다 중요한 것은 문제를 뾰족하게 정의하는 것입니다. 무엇을 문제로 생각하였기에 경험했던 일을 시작하게 된 것인지 설명을 잘 할 수 있다면, 우리의 경험이 더욱 특별해질 수 있다고 믿습니다.그러나 이력서를 작성하는 많은 분들이 경험을 소개하는 내용에서 문제 정의, 즉 일을 시작하게 된 배경에 대해서 생략하는 경우가 많습니다. 문제를 정의하고 목표와 목적을 설명하는 내용이 없을 때, 성과가 대단하더라도 경험에 대한 소개를 읽는 사람이 경험의 성과를 특별하고 대단하다고 판단하지 못합니다.경험의 시작을 논리적으로 설명하는 내용이 있을 때, 일을 진행한 과정을 흥미롭게 보게 되고, 성과가 크든 작든 공감과 납득을 하게 됩니다. 당당한 이력서를 위한 제안이력서의 내용, 형식, 디자인, 가독성 등 채용 전형에서 당락을 좌우하는 중요한 요소가 많습니다. 오늘 이력서를 업데이트하려는 분이 계시다면, 꼭 경험을 잘 풀어서 설명해보는 시간을 가져보시기 바랍니다.기존에 자신이 봤던 이력서 형식은 머릿속에서 지우고, 자신의 경험을 가장 잘 설명하고 자랑할 수 있는 구조로 만들어보세요. 합격하는 이력서의 모범 답안은 바로 여러분 머리와 마음 속에 있습니다. 당당하고 자신 있게 자신의 경험을 마음껏 담아낸 이력서를 뽑아내는 우리가 되길 진심으로 응원합니다.﻿

길은 잃은 이력서

AI 100조 성공하려면 주 52시간 규제부터 풀어야 民生은 기업 경쟁력에 달렸다 김윤덕이 만난 사람 배틀 그라운드서 AI 기업으로 벤처신화 장병규 크래프톤 의장

‘AI 100조’ 성공하려면 주 52시간 규제부터 풀어야… 民生은 기업 경쟁력에 달렸다

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이를 위해서는 회사에 무슨 일이 있는지 구성원들이 알아야 한다. 소수의 리더가 관리·감독하며 이끄는 조직은 관료화될 뿐, 숨는 사람이 많아지고, 더 크게 성장하지 못한다.”

“나는 일대일 미팅을 좋아하지 않는다. ‘한 사람을 오랫동안 속일 순 있어도 여러 사람을 오래 속일 순 없다’는 격언처럼 일대일 대화는 사기꾼이 오래 살아남는 구조를 만든다. 첫 창업 회사인 네오위즈 때 여러 다툼이 있었는데 원인 중 하나가 일대일 대화였다. 다 같이 모여서 얘기하면 서로 다른 의견을 명료히 알게 되고 곡해 없이 해법을 찾아갈 수 있다. 나와 생각이 다른 임원과 토론할 때도 그가 신뢰하는 이를 꼭 배석시키라고 요청한다.”

“창업 초기 꿈꿨던 바텀업(아래로부터의 의사 결정)이랄지, 360도 평가 같은 건 많이 타협했다. ‘우아한 형제들’ 김봉진님이 ‘관계는 수평적, 업무는 수직적’이란 표현을 했는데, 우리도 비슷하다.”

“시간도 경쟁력이란 뜻이다. 중국은 ‘996(오전 9시~오후 9시까지 주 6일 근무)’을 하는데 주 52시간 일하는 한국이 어떻게 이길 수 있나? 이기는 게 오히려 이상하지 않나?”

“주 52시간을 하는 이유는 충분히 이해한다. 문제는 획일적 적용이다. 다양성, 포용성, 창의성을 강조하면서 왜 노동의 다양성은 인정하지 않을까? 정치인들이 민생을 외치던데, 한국 민생은 기업의 글로벌 경쟁력에 달려 있다.”

https://www.chosun.com/opinion/2025/07/06/S6E5OB73EVHX5PJYHJZCGIDDY4/

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이를 위해서는 회사에 무슨 일이 있는지 구성원들이 알아야 한다. 소수의 리더가 관리·감독하며 이끄는 조직은 관료화될 뿐, 숨는 사람이 많아지고, 더 크게 성장하지 못한다.” “나는 일대일 미팅을 좋아하지 않는다. ‘한 사람을 오랫동안 속일 순 있어도 여러 사람을 오래 속일 순 없다’는 격언처럼 일대일 대화는 사기꾼이 오래 살아남는 구조를 만든다. 첫 창업 회사인 네오위즈 때 여러 다툼이 있었는데 원인 중 하나가 일대일 대화였다. 다 같이 모여서 얘기하면 서로 다른 의견을 명료히 알게 되고 곡해 없이 해법을 찾아갈 수 있다. 나와 생각이 다른 임원과 토론할 때도 그가 신뢰하는 이를 꼭 배석시키라고 요청한다.” “창업 초기 꿈꿨던 바텀업(아래로부터의 의사 결정)이랄지, 360도 평가 같은 건 많이 타협했다. ‘우아한 형제들’ 김봉진님이 ‘관계는 수평적, 업무는 수직적’이란 표현을 했는데, 우리도 비슷하다.” “시간도 경쟁력이란 뜻이다. 중국은 ‘996(오전 9시~오후 9시까지 주 6일 근무)’을 하는데 주 52시간 일하는 한국이 어떻게 이길 수 있나? 이기는 게 오히려 이상하지 않나?” “주 52시간을 하는 이유는 충분히 이해한다. 문제는 획일적 적용이다. 다양성, 포용성, 창의성을 강조하면서 왜 노동의 다양성은 인정하지 않을까? 정치인들이 민생을 외치던데, 한국 민생은 기업의 글로벌 경쟁력에 달려 있다.” https://www.chosun.com/opinion/2025/07/06/S6E5OB73EVHX5PJYHJZCGIDDY4/

조선일보

“실리콘밸리의 힘은 개인의 자율과 책임을 극대화한 것에 있다. 이

점점 더 예측하기 힘들어지는 취업/채용 시장,

현재 2000명이 넘게 사용한 데이터 직무/ 커리어를 준비하는 취준생분들을 위한
데이터 이력서 작성 템플릿 + 작성법 가이드를 무료로 배포합니다.

✔ 노션으로 만든 이력서 3종 템플릿
✔ 매일 7일간 이메일로 도착하는 실전 노하우/맞춤형 가이드

두가지 혜택을 결합한 학습 패키지를 아래 댓글의 링크에서
이메일만 입력하시고 무료로 받아가세요.

데이터 이력서 템플릿 + 작성 가이드:
https://dchanlim.gumroad.com/l/datarichard_notion_template

점점 더 예측하기 힘들어지는 취업/채용 시장, 현재 2000명이 넘게 사용한 데이터 직무/ 커리어를 준비하는 취준생분들을 위한데이터 이력서 작성 템플릿 + 작성법 가이드를 무료로 배포합니다. ✔ 노션으로 만든 이력서 3종 템플릿 ✔ 매일 7일간 이메일로 도착하는 실전 노하우/맞춤형 가이드 두가지 혜택을 결합한 학습 패키지를 아래 댓글의 링크에서 이메일만 입력하시고 무료로 받아가세요. 데이터 이력서 템플릿 + 작성 가이드:https://dchanlim.gumroad.com/l/datarichard_notion_template

데이터 이력서 템플릿 + 작성 가이드를 사용해보세요.

CSS의 여러가지 방법을 통해서 HTML 요소를 우측으로 정렬해보겠습니다.

CSS로 HTML 요소 우측 정렬하기 | 달레의 웹 프로그래밍

CSS를 사용하다 보면 정말 간단한 정렬이 생각처럼 되지 않아서 애를 먹는 경우가 있는데요. 특히 초보자들이 많이 겪는 문제가 HTML 요소(element)를 우측으로 정렬하는 것입니다.

이번 시간에는 특정 HTML 요소를 우측으로 정렬하는데 활용할 수 있는 다양한 스타일링 방법을 실습을 통해서 알아보겠습니다.

📺 동영상: https://youtu.be/ufr3nb6Zf4Y
📝 포스팅: https://www.daleseo.com/css-align-right/
🧑‍💻 실습 코드
 * 시작: https://codepen.io/daleseo/pen/LYNLeeV
 * Float: https://codepen.io/daleseo/pen/wvGdBqX
 * Flexbox 1: https://codepen.io/daleseo/pen/XWdgVVw
 * Flexbox 2: https://codepen.io/daleseo/pen/rNewpdb
 * Flexbox 3: https://codepen.io/daleseo/pen/qBZjpyO
 * Grid: https://codepen.io/daleseo/pen/wvGepEy
 * Postion: https://codepen.io/daleseo/pen/JjXJMVG

CSS를 사용하다 보면 정말 간단한 정렬이 생각처럼 되지 않아서 애를 먹는 경우가 있는데요. 특히 초보자들이 많이 겪는 문제가 HTML 요소(element)를 우측으로 정렬하는 것입니다. 이번 시간에는 특정 HTML 요소를 우측으로 정렬하는데 활용할 수 있는 다양한 스타일링 방법을 실습을 통해서 알아보겠습니다. 📺 동영상: https://youtu.be/ufr3nb6Zf4Y📝 포스팅: https://www.daleseo.com/css-align-right/🧑‍💻 실습 코드 <ul><li>시작: https://codepen.io/daleseo/pen/LYNLeeV</li><li>Float: https://codepen.io/daleseo/pen/wvGdBqX</li><li>Flexbox 1: https://codepen.io/daleseo/pen/XWdgVVw</li><li>Flexbox 2: https://codepen.io/daleseo/pen/rNewpdb</li><li>Flexbox 3: https://codepen.io/daleseo/pen/qBZjpyO</li><li>Grid: https://codepen.io/daleseo/pen/wvGepEy</li><li>Postion: https://codepen.io/daleseo/pen/JjXJMVG</li></ul>

www.youtube.com

프론트엔드 개발자

상연

프리랜서

정연준

안녕하세요, 프론트엔드 엔지니어를 취업준비생입니다.
#프론트엔드 #게임

CSS로 HTML 요소 우측 정렬하기

달레

캐나다🇨🇦에 살면서 미국🇺🇸 회사에서 일하는 한국🇰🇷 개발자입니다. 🧑‍💻
블로그 쓰는 거에 진심이고 취미로 유튜브도 하고 있어요 :)
✍️ https://www.daleseo.com
📺 https://www.youtube.com/@DaleSeo

CSS로 HTML 요소 우측 정렬하기

댓글 0

비슷한 게시물

주간 인기 TOP 10

추천 프로필