기록으로 남기는 개발자 로그

안녕하세요,
바닐라코딩 부트캠프를 시작한 지 어느덧 4개월이 지났습니다.
그리고 지금, 저는 제 첫 개인 프로젝트를 무사히 마쳤습니다..! 👏👏👏👏
처음 일주일 체험 수업 했을 때 정말 이 시간이 다가올까 아득하게만 생각했는데,

결국 시간은 때로는 무심하게 때로는 냉정하게 흘러갔습니다. 

문득 돌아보니, 이 몇 달간의 시간은 단순히 기술을 배우는 과정이 아니였던 것 같아요.
그보다는 오히려 ‘나’라는 사람을 가장 깊이 들여다보고, 가장 많이 되묻고, 가장 많이 흔들렸던 시간에 가까웠던 것 같습니다.

"바코에 출근하는 것이 익숙해진 삶"

처음 바닐라코딩 주말 출근을 했을 때,
어색한 분위기와 느릿하게 흘러가는 시간이 참 지루하게 느껴졌어요.
결국 저녁 8시쯤, 참지 못하고 집으로 돌아갔던 기억이 아직도 생생합니다.

그랬던 제가,
이제는 눈 뜨자마자 바코에 출근하고,
눈 감기 직전까지 바코에 앉아 있는 게 당연한 일상이 되어버렸어요.

이상하게도, 바코에 있을 때는 시간에 무감각해지는 것 같아요.
집중하다 보면 어느새 새벽 3시가 되어 있고,
다음 날 다시 바코에 가는 것도 전혀 낯설지 않게 느껴져요.
"내일 가기 싫다"는 생각도, 어느샌가부터 제 머릿속에서 들지 않았던 것 같아요.

사실 바코에 오기 전,
영어학원을 그만두고 한창 백수 생활을 하고 있었을 때는
오후 2시에 일어나서 새벽까지 놀다가 잠드는 삶이 익숙했어요.
그리고 그때는 '무언가에 몰두한다는 감각'이 막연히 두렵게 느껴졌어요.

인스타그램을 보다가 누군가 자신의 '열심히'를 가득 담은 사진을 공유하면,
그걸 마주하는 게 어쩐지 불편했어요.
무의식적으로 외면하고,
"나는 저런 사람이 아니야" 하며 선을 긋기 바빴던 것 같아요.

그런 제가 지금은,

예전처럼 띵가띵가 놀고 먹던 감각은 점점 잊혀지고  오히려 무언가에 몰두하는 감각에 더 익숙해졌어요.

그래서인지 이번 바코 생활을 통해
"나는 다시 무언가에 최선을 다할 수 있는 사람이다"
라는 걸 새삼 느낄 수 있었어요.

이 감각 하나만으로도,
저는 바코에서 정말 값진 경험을 했다고 자신 있게 말할 수 있을 것 같습니다.

나는 앞으로 어떤 개발자가 되고 싶은가?

4개월이 지나고, 이제는 정말 스스로에게 물어봐야 할 타이밍인 것 같아요.

✔️ 코드의 본질을 이해하는 개발자

제가 바닐라 코딩 부트캠프에 참여 하기 전 국비 교육을 받으면서 
처음으로 만들었던 프로젝트는 바로 “택배왔냥”이라는 게임이었어요.
지금 생각해보면, 2년 전  그때의 저는 “코드를 쓰는 사람”이라기보다는 “기능을 흉내 내는 사람”에 가까웠던 것 같아요.

코드의 흐름도 잘 이해하지 못한 채,
“이걸 누르면 저게 나와야 하니까 여기에 이 코드 넣어야지!” 하는 식으로 기능 위주로 조각조각 붙여가며 개발을 했습니다.

한창 신나게 만들긴 했지만,
막상 시간이 지난 지금  제 “택배왔냥” 코드를 다시 열어봤을 때
이 코드들을 다시 처음부터 공부해야 할 정도로 제 머릿속에 남은게 없었어요.

중간중간에 “나중에 공부하기”라고 주석을 잔뜩 달아놨는데…
그 "나중"은 오지 않았고, 저 스스로도 다시 보고 싶은 코드가 아니었어요.

그런 코드를 이력서에 넣어놨다는 게
지금 생각하면 조금 부끄러워지더라고요.
기능만 되면 신났던 그 시절의 제 모습이,
지금의 눈으로 보면 철없고, 코드에 무책임했던 개발자처럼 느껴지기도 해요.

하지만 동시에, 그때의 제가 있었기에
지금의 저는 ‘코드의 본질’을 더 깊이 들여다보려는 사람이 되었구나 싶어요.

요즘은 하나의 함수, 하나의 동작을 구현할 때도
“왜 이렇게 짜야 하지?”
“더 좋은 흐름은 없을까?”
라는 고민을 하게 됐고, 그게 결국 코드에 대한 책임감으로 이어지고 있어요.

이제는, 단순히 돌아가기만 하는 코드가 아니라

다른 사람도 함께 이해할 수 있는 코드, 3개월 뒤에 내가 봐도 이해할 수 있는 코드를 쓰고 싶다는 욕심이 생겼습니다.

✔️ 사용자를 생각하는 개발자

프로젝트 전, 과제를 진행했을 때만 해도
버튼은 내가 괜찮다고 느끼는 위치, 혹은 CSS 짜기 편한 위치에 대충 배치했어요.
UI의 타입도 내가 코드 짜기 쉬운 방식으로 선택했고요.

그때는 ‘기능만 되면 됐지 뭐~’ 하는 마인드로
자기합리화에 능했던 개발자 지망생이었습니다.

그래서 항상 과제를 마치고 테스트할 때,
정작 테스트하는 나조차 불편함을 느꼈어요.
심지어 불편해하면서도 "그래도 기능은 다 했잖아~" 라며 애써 그 불편함을 외면했죠.

하지만 개인 프로젝트를 본격적으로 진행하면서,
저는 처음으로  스스로에게 물어봤습니다.

“나는 어떤 개발자가 되고 싶지?”
“지금 내가 짜는 이 코드가, 사용자를 위한 것일까?”

프론트엔드 개발자의 본질은 결국 사용자에게 편리한 인터페이스를 제공하는 것인데,
그런 제가, 가장 중요한 초심을 놓치고 있었다는 걸 깨달았어요.

그래서 이번 프로젝트에서는 다짐했어요.
“사용자를 중심에 두고 개발하자.”

버튼 하나를 놓더라도,
내가 아니라 사용자의 손가락이 닿기 쉬운 위치에 두려고 했고,
UI/UX 흐름도 최대한 자연스럽게 느껴지도록 설계하려고 노력했습니다.

예전에는 그냥 position: absolute로 적당히 던져두던 요소도 지금은 왜 그렇게 배치해야 하는지를 고민하고,
사용자가 클릭하고 나서 어떤 반응을 기대할지를 상상하게 되었어요.

이런 작은 변화들이 쌓여가면서,
처음에는 낯설었던 ‘사용자를 위한 개발자 마인드셋’이 확립해가고 있는 것 같습니다!

✔️ 꾸준히 성장하는 개발자

앞으로 저는 분명 더 많은 시간을 개발에 투자하게 될 것입니다.
하지만 단순히 시간을 많이 쓴다고 해서 실력이 비례하는 건 아니라는 것을, 이 여정을 통해 뼈저리게 느꼈습니다.

그래서 저는 "얼마나 오래 했는가"보다 "어떻게 성장하고 있는가"를 돌아보는 개발자가 되고 싶습니다.
흘러간 시간을 아쉬워하는 개발자가 아니라,
다가올 시간을 설계하고 준비하는 개발자가 되고 싶어요.

기존에 익숙했던 기술이 있다 하더라도,
그 기술이 더 이상 사용자에게 최선이 아니라면
과감하게 내려놓고 더 나은 방법을 선택할 수 있는 사람.

그리고 최신 기술이 등장했다면,
그게 단순히 ‘새롭기 때문’이 아니라
사용자에게 더 편리하고 즐거운 경험을 줄 수 있기 때문이라는 이유로
배우고, 실험하고, 흡수할 수 있는 개발자가 되고 싶어요.

기술은 결국 사람을 위한 것이라는 철학을 잊지 않으면서,
나의 익숙함보다는 사용자의 편의를 선택할 수 있는 개발자.
저는 그런 사람이 되기 위해
앞으로도 계속 성장하고,
계속 버리고,
계속 만들어나가려고 합니다!

이건 끝이 아니라 시작이다 ✨

이제 개인 프로젝트는 끝났습니다.
하지만 제 마음속에는 “이제 진짜 시작이구나”라는 감정이 더 크게 남아있어요.

나는 아직도 많이 부족하고, 모르는 것도 많고, 긴장하면 말을 더듬고, 발표 때 실수도 잦지만,
배우고 싶은 마음만큼은 누구보다 단단하다는 확신이 생겼어요.

앞으로 어떤 개발자가 될진 모르겠지만, 한 가지는 분명 한 건
저는, 성장을 삶처럼 여기는 개발자가 되고 싶습니다.

그걸 위해 오늘도, 그리고 내일도
나는 이 길을 열심히 그리고 계속 걸어갈 예정입니다!

https://www.vanillacoding.co/

안녕하세요,

저는 고시원 방 한 칸에 살며, 한창 개인 프로젝트를 진행하고 있습니다.

개인 프로젝트를 하면서 "열심히 하고 있다"는 말에 선뜻 대답할 수 없겠다는 생각이 들었습니다.
'열심히'라는 말이 참 추상적이고도 상대적인 단어더라고요.
한 달 전의 나와 비교하면 분명 지금 더 열심히 살고 있다고 말할 수 있을 것 같은데,
또 다른 누군가의 "열심히"와 나를 나란히 놓고 보면,
‘과연 내가 정말 노력하고 있는 게 맞나?’ 라는 의심도 아닌 확신이 들었습니다.

그래서 상대적인 ‘열심히’를 '절대적인 ‘노력’으로 바꾸고자, 스스로 마음을 다잡게 된 것 같아요.

며칠간 절대적인 노력이란 뭘까 고민했는데,
그 절대라는 공간 안에는 결국 나 혼자뿐이더라고요.

비교할 사람도 나,
평가할 사람도 나,
열심히 하려는 사람도 나.

이 절대라는 공간 안에서는, 남과 나를 비교하는 것이 아니라 어제의 나와, 방금 전의 나와 비교하게 되고,
평가도 남이 해주는 게 아니라 "정말 열심히 했다고 내가 나에게 말할 수 있을까?"를 스스로 묻게 되는 구조인 것 같습니다.

‘열심히’라는 기준조차도 온전히 "나"라는 걸, 그걸 조금씩 깨닫게 되면서
"나 스스로 부끄럽지 않게 살자"는 다짐을 하게 되었습니다.

어제의 나를 부끄러워하지 않도록,
불과 몇 분 전의 나조차 부끄럽지 않도록.

"개인 프로젝트를 진행하면서..."

제 프로젝트 아이디어는 게임 보이 에뮬레이터, 게임 파일 실행기입니다.

아이디어 선정하는데 이번에도 어김없이 거름같은 아이디어를 내고 컷 당했지만 결국 이 아이디어가 다행히 생존했어요.
(너무 좋은 아이디어여서 생존한 것보다는, 거름 같은 아이디어들 사이에서 그나마 ‘그냥 아이디어’ 정도여서 살아남은 게 아닐까 싶어요…)

아이디어를 선정하고 나서 POC를 진행하는데, 아니 글쎄 게임 파일을 실행시켜주는 멋진 오픈소스 라이브러리가 이미 있지 않겠습니까...
정말 간단하게 API만 호출하면 게임이 실행되고, 세이브도 되고, 심지어 키 매핑까지 다 되어 있는 거예요.

근데 이걸 그냥 가져다 쓰는 건 개인 프로젝트에서 내가 얻을 수 있는 게 너무 적을 것 같았어요.
그래서 '이왕 하는 거 메모리부터 CPU까지 내가 직접 구현해보자!' 라는… 지금 생각하면 근자감 그 자체인 마음으로 패기롭게 시작하게 됐습니다.

그 패기도 잠시...
게임기기 중 게임보이가 가장 구조가 단순한 하드웨어 중 하나인데도, 구현이 어려웠어요.

우선 CPU 명령어 세트를 구현하는데, 8비트 연산 하나하나가 전부 수작업이고, 플래그 레지스터 하나 잘못 처리하면 게임이 아예 안 돌아가고... (테트리스로 테스트 파일 돌리면서 20개쯤 하다가 안되겠어서 결국 256개 다 긁어온...)
가산기 구현하면서 진수 연산에 익숙하지 않다 보니, 0xFF 넘는 순간 carry 처리에서 삽질하고, half-carry는 또 도대체 이걸 왜 체크하는지 감도 안 잡히고..

그래도 버릴 수는 없으니까, Game Boy CPU 명령어 매뉴얼이랑 blargg 테스트 ROM  하루 종일 파면서 
테스트 하나하나 통과시킬 때마다 콘솔에 하나하나 씩 통과 된거 보면서 기뻐하고.... 

메모리 맵은 또 ROM, VRAM, WRAM, I/O, OAM 등등 각 메모리 영역이 어떤 주소에 어떻게 연결돼 있는지… 이걸 처음에 몰랐을 땐 그냥 if (addr < 0x8000) 식으로 대충 분기했는데,
나중에 알고 보니 게임보이는 MMU라는 걸로 은근 복잡하게 메모리를 분기하고 있었더라고요. 
(메모리에서 모든 하드웨어 처리를 하고 있어서 메모리가 복잡할 수 밖에 없는 구조...)
인터럽트 구현할 때는  HALT 버그도 있어서, IME가 꺼져 있는 상태에서 인터럽트가 pending이면 HALT에서 깨어나서 인터럽트가 실행되어야 하는데 계속 pending 상태고... 

결국 정말 레고 조립하듯이, 다른 사람 코드 조각 참고하고 닌텐도 개발 문서, reddit, stackoverflow, 깃허브  뒤지면서 어렵게 어렵게 겨우겨우 맞춰냈습니다. 사실 한번 뒤집어 엎기도 했어요

진짜... "코드로 기계를 만드는 느낌" 이라는 게 이런 거구나 싶었어요.
그리고 그런 과정을 거치면서 컴퓨터가 어떻게 작동하는지, 하드웨어가 소프트웨어와 어떻게 소통하는지를 가장 본질적인 수준에서 체감할 수 있었어요.
아직도 갈 길은 멀지만, 이 경험만큼은  오래 남을 것 같다는 생각이 듭니다.

"사용자 입장에서 개발하기"

켄님께서 중간 점검 끝나고 마무리하시면서 "사용자 입장에서 기능을 추가해야 한다"는 말씀을 해주셨는데,
그 순간 문득 개인 프로젝트를 하면서 내가 놓치고 있던 부분이 뭔지 확 와닿았어요.

그동안 저는 개발자 입장에서 이기적으로 코딩을 하고 있었더라고요.
개발자인 내가 편한 UX, 내가 이해하기 쉬운 UI, 내가 구현하기 쉬운 기능 위주로만 구현을 해왔던 거예요.
근데 켄님은 피드백을 주실 때  개발자 관점에서 말씀해주시기 보다 항상 사용자 입장에서 어떤 흐름이 자연스러운지,
어떤 UI가 불편할지 그런 걸 짚어주시더라고요.

그걸 듣다 보니 자연스럽게 기술적인 챌린지도 따라왔어요.
예전엔 그냥 로직만 동작하면 됐는데, 이제는 "사용자 입장에서는 이게 맞나?"를 계속 고민하게 되니까, 코드도 더 깔끔하게 짜야 하고, 기능도 더 신중하게 설계해야 하더라고요.

그러면서 프로젝트를 단순히 기술 구현 과제로만 보는 게 아니라,
‘사용자 경험을 만드는 일’이라는 관점으로 점점 전환되는 게 느껴졌어요.

그래서 이번 중간 점검은 단순히 코드를 점검받는 시간이 아니라,
개발자로서 내가 어떤 마인드로 프로젝트에 임하고 있었는지 돌아보게 되는 시간이었고,
결국 사용자 입장을 고려한다는 건 개발자 마인드셋을 다듬는 일이기도 하구나, 싶어서 오히려 좋았습니다.

그리고 저를 위해 적는 교훈 메세지가 있다면 중간 발표 때 두뇌풀가동하지 않기 입니다. 저번 모의 면접 때도 받았던 피드백인데요, 
중간 점검하면서 머리가 새하얘지면서 제가 자꾸 두뇌풀가동 + 변명  + 모르면서 나불나불... + 허세 + 과장하기 등등...
이것저것 나쁜 습관이란 습관은 다 가지고 있더라구요 면접 자리였다면 정말 최악일 것 같은... 그래도 이렇게 제 스스로를 깨닫고 고칠 수 있는 기회가 있었다는게 다행인 것 같습니다. 하루 빨리 이런 모습을 다 치워버려야겠다는 생각이 드는 하루였습니다. 


마지막으로 저의 화려한 에러 로그를 보여드리며 마무리하도록 하겠습니다!

읽어주셔서 감사합니다. 

안녕하세요 
저는 드디어 팀 프로젝트를 무사히 마쳤습니다.

팀 프로젝트를 끝내면서 제가 보낸 무려 5주라는 시간을 돌이켜보면, 협업이라는 틀 안에서 나라는 사람에 대해 고찰할 수 있었던
의미있는 시간이었던 것 같습니다.

지금껏 살아오면서 같이 일하는 사람으로서의 나를 알아보는 시간이 없었는데, 팀 프로젝트를 하면서 기술도 기술이지만 나에 대해 알아가는 시간, 즉 내가 같이 협력하는 사람으로서 어떤 사람인가에 대해 관찰할 수 있었던 시간이였던 것 같습니다.

"AI 개발 공부해야하지 않을까?"

팀플 마지막 주 부터 AI 에이전트 수업을 듣게 되었습니다. 바쁜 와중에 수업을 들어야했기 때문에 팀원분들한테 사전에 양해를 구하고 참여하게 되었어요. 제가 AI 수업을 선택한 이유는 바로 메타 인지입니다. 바닐라 코딩을 다니면서 켄님도 태우님도 누누히 말씀해주셨던게 바로 메타 인지였거든요. 요즘 개발 취준생들이 AI로 인해 취업이 안된다 안된다 하지만 저는 이걸 역이용 해보고 싶어졌어요. AI 다들 안쓰고 못살 지경이라면 내가 잘 다룰 수 있는 사람이 되면 어떨까? 라는 생각이 들었어요.
그리고 AI 수업을 들은 첫 날 제 생각이 옳은 생각일 수도 있겠다는 생각을 했습니다. 
켄님께서 LangChain이라는 라이브러리가 최근 큰 투자를 받았다는 소식을 말씀해주셨습니다. 수업이 끝나고 검색해보니 무려 2500만 달러 (330억원)을 투자받았다는 뉴스를 접할 수 있었어요. 돈의 흐름이 AI로 흘러가고 있다는 소식이 제 생각을 한 층 견고하게 해주었습니다. 

스마트폰이 처음 등장했을 때와 비슷하다고 생각합니다. 당시 스마트폰 사용자는 ‘앞서가는 사람’이었지만, 곧 새로운 표준이 되었죠. 개발 세계도 마찬가지로 트렌드를 감지하고, 그 흐름에 올라탈 줄 아는 개발자가 결국 살아남을거라고 생각합니다.

"오들오들 떨렸던 발표"

이번 팀 프로젝트 최종 발표에서 제가 발표를 담당하게 되었는데, 얼마나 떨리던 지 이때껏 팀원들과 함께 쏟은 결과물을 다른 사람들에게 어필한다는 것은 쉬운 일이 아니였어요. 아무리 창의력이 좋고 코드적으로 잘 짜여진 프로젝트를 발표하더라도 내가 말한 한 단어 때문에 그 프로젝트가 순식간에 흔한 프로젝트가 될 수 있는거고,  짜여진 코드를 어떻게 설명하냐에 따라 네이밍이나 코드 스타일을 못지킨 단점만 부각될 수도 있기에 면접 자리라고 생각하고 긴장해서 잘해보자라는 생각을 했던 것 같아요.
근데 시작부터 마우스 확대 축소가 반대로 되어있어서 허둥지둥.... 버그는 최대한 안보여주기로 하면서 짠 메뉴얼대로 하지도 않고... 구현한 기능을 당구 같다고 하느니... 내 생각대로 발표가 흘러가지 않아서 많이 당황했답니다..

끝나고 나니 아쉬움이 가득했지만, 회고 문서로 부족한 점을 정리하며 다음 발표를 대비하기로 했습니다. “발표도 결국 연습”이라는 사실을 몸소 깨달은 중요한 경험이 되었습니다.

"마무리하며..."

이번 5주의 여정은 협업·트렌드·커뮤니케이션 세 키워드로 정리할 수 있을 것 같아요.

1. 협업 — 함께 일할 때의 내 모습을 발견하고, 동료들의 다양한 작업 방식에서 많은 것을 배웠습니다.
2. 트렌드 — AI와 같은 거대한 흐름을 두려워하기보다 먼저 이해하고, 적극적으로 활용해야 한다는 확신을 얻었습니다.
3. 커뮤니케이션 — 코드만큼이나 중요한 것이 설명과 공유임을 느꼈습니다.

이 경험을 발판 삼아, 앞으로도 새로운 기술을 두려워하지 않는 개발자, 협업을 즐기는 동료, 그리고 메시지를 명확히 전달하는 발표자로 성장해보려고 합니다! ✨

안녕하세요 ! 
저는 지금 팀 프로젝트 마지막 주를 앞두고 있습니다.
첫 부트캠프 시작을 걱정하던 제가, 어느덧 팀 프로젝트를 마무리하고 있네요 

여기서 하루하루를 보내면서 매일 같이 드는 생각이 저는 끝을 향해 가고 있는게 아닌, 시작을 향해 가고 있는 것 같아요
그 시작은 제가 개발자로서 첫 입사하는 날이 될 수도, 혹은 처음으로 회사에서 프로젝트를 맡는 날일 수도 있겠죠.

항상 끝만 바라보며 살던 제가 무수히 많은 시작을 향해 달려가고 있는게 설레기도 해요
여러분도 끝을 향해 달려가고 있었다면 시작을 향해 달려가보는건 어떨까요?
단어 하나 차이일 뿐인데 나에게 많은 끝이 있는 것 보다 시작이 있다는게 때론 저처럼 인생의 방향점이 되기도 하는 것 같아요 

" 같이 일하고 싶은 사람이 되는 것"

이번 팀 프로젝트를 시작하면서 저는 "같이 일하고 싶은 사람이 되자"는 다짐을 했습니다.
누군가한테는 팀 프로젝트에 불과할 수도 있겠지만,
저는 정말 몰입해서 회사에서 동기분들과 같이 진행하고 있다는 생각으로 전념했어요.
그리고 생각한게 "같이 일하고 싶은 사람이 되자" 였습니다.

그리고 그 전에 어떤 사람이 같이 일하고 싶은 사람인가에 대해 고민했어요
제가 생각했을 때 그런 사람은 코딩 실력도 아닌 원래 본성이 착한 사람도 아닌 감정이 없는 사람이였어요
감정이 없다고 하면 그게 어떻게 같이 일하고 싶은 사람이냐라고 의문을 품으시겠지만, 팀 프로젝트 하면서 생각보다 방해됐던게 
바로 "나의" 감정이였거든요. 물론 감정은 누구나 가지고 있지만, 이번 프로젝트를 하며 저는 제 감정이 오히려 협업에 방해가 될 때가 많았어요. 짜증, 초조함, 과한 기쁨조차도 팀 분위기를 흐릴 수 있더라고요.

그래서 최대한 프로젝트에 감정을 담지 않기로 했어요.
코드가 안 풀리면 더 공부하고, 의견 충돌이 생기면 근거를 찾아 설득했습니다.
순조롭게 진행될 때조차 흥분하지 않으려 노력했어요.


그 결과, 우리는 갈등 없이 의견을 조율했고
필요하다면 코드를 다시 처음부터 짜는 일도 담담히 받아들일 수 있었습니다.
저는 이번 경험을 통해 협업에서 감정을 덜어내는 법을 배웠고,
그게 바로 “같이 일하고 싶은 사람의 조건” 중 하나라는 생각이 들었습니다.

"팀 프로젝트에서의 나"

팀 프로젝트하면서 저는 이기적인 성장을 했던 것 같아요 
저는 프로젝트를 하면서 협업을 중요시 여겼지만 부수적으로 생각했던건 팀원들의 지식을 하나라도 줏어먹고 싶은 거지 근성이 있었던 것 같아요. 그래서 조금이라도 이해가 안되는 말이 있으면 회의 중이라도 방금 말씀하신 ~~가 뭔지 알 수 있을까요? 방금 하신 말씀 이해 안됐는데 다시 설명해줄 수 있을까요? 정말 간단한거라도 제가 이해안되고 모르는게 있으면 바로 바로 묻고 팔로업하고 조사하고를 계속 반복했던 것 같아요. 근데 정말 감사하게도, 팀원분들은 제가 어느 포인트에서 감을 못 잡고 있는지 함께 고민해주셨고, 더 잘 이해할 수 있도록 설명 방식을 바꿔보거나, 도움이 될 만한 공식 문서를 직접 찾아서 공유해주시기도 했습니다.

덕분에 저도 도움을 요청하는 데 주저하지 않되, 그 도움에 상응하는 노력을 더 기울여야겠다는 책임감을 가질 수 있었던 것 같아요.

 팀 프로젝트가 끝날 무렵 한 팀원이 저에게 인님 진짜 많이 성장한 것 같다라고 말씀해주셨는데,
제가 초반에 질문했던 모습과 지금의 질문 퀄리티가 달라진 것 같다고 하셨어요 처음에는 질문만 하는 느낌이였다면 지금은 인님의 생각도 겸해 들을 수 있고 그걸 답변해주면서 자신의 생각도 정리가 되고 때로는 새로운 아이디어를 얻어서 좋다고 해주셔서 조금이나마 제 성장이 체감이 되는 순간이였습니다. 

"마무리"

이번 프로젝트는 단순히 코드를 짜는 시간 그 이상이었습니다.
감정을 조절하며 소통하고, 질문을 통해 함께 성장하며
진짜 “같이 일할 수 있는 사람”의 태도가 무엇인지 고민하게 해줬습니다.

앞으로도 저는,  묻는 걸 두려워하지 않고, 감정을 배제하며, 배운 것을 나눌 줄 아는 개발자로 성장하고 싶습니다.

https://www.vanillacoding.co/

이 길이 내 길인 줄 아는 게 아니라
그냥 길이 그냥 거기 있으니까 가는 거야
원래부터 내 길이 있는 게 아니라
가다보면 어찌어찌 내 길이 되는 거야

안녕하세요, 테스트 & 모의면접 주간을 마치고 돌아왔습니다.

제가 맨 처음에 적어둔 노래 가사는 "장기하 - 그건 니 생각이고" 입니다.

왜 적어뒀냐면, 제가 힘들 때 마다 듣는 노래거든요...ㅎㅎ

저 노래를 듣다보면 저를 힘들게 했던 생각들도 별게 아니게 되는 그런 기분을 겪는 것 같아요. 

"이게 내 최선이 맞나?"

테스트 주간을 보내면서, 노트북을 닫는 순간에 항상 이런 생각이 들었어요. 

"이게 내 최선이 맞나?"

그리고 항상 스스로 묻는 질문에 애석하게도 돌아오는 답변은 부정이었습니다.

그리고 그 부정은 때때론 제 노트북을 다시 열게 하기도 하고, 좌절에 그칠 때도 있었어요.

테스트 주간에 바닐라코딩에서 새벽 6시까지 테스트 과제를 하고 소파에 누워 오늘 하루를 되돌아보는데, 최선을 다하지 못한 것 같은 죄책감이 저를 짓눌렀어요. 다음 날 오후 6시에 제출임에도, 최선의 코드를 작성하지 못한 제가, 최선의 행동으로 6시에 누워자는게 너무 아쉬웠어요. 엄마가 가끔 저한테 신들렸냐고 ( 옛날에 제 모습이 아니여서 그런 말씀을 하신 것 같아요 ;;) 하실 때가 있는데, 저는 그냥 하루하루가 아쉬워서 그런 것 같아요. 결국 지금 제가 내린 마인드셋은 "하루하루 아쉬움이 덜 남게하자" 인 것 같습니다. 

저는 여기서 값진 경험을 하고 있다고 생각해요. 하루하루가 아쉽다고 생각이 든건 정말 처음이였거든요.
그리고 궁극적으로 그 아쉬움이 제 발을 움직이고 눈을 뜨게하고 손을 쓰게 하는 것 같아요.

매사에 아쉬움이 없는 하루를 보내자는 모토를 새긴 주간이였습니다!

"부족한 결과물로 성장하다"

 테스트 과제를 제출하고 오후 6시, 저는 테스트를 제출하고 애써 부족한 면들을 외면하려고 했던 것 같아요.

제 자신이 이 정도에 그쳐 테스트를 제출한게 너무 싫었던 것 같아요. 그리고 제출한 날 멘토님이 Ken님이셨는데, 제가 제 코드를 주먹밥이라고 표현하니까 똥💩!!!!!이라고 하시는 거에요. 저는 순간 헉 똥은 고쳐야 하는데 라고 생각하고 다시 제 코드를 들여다보고 고쳐야겠다고 생각했어요. 주먹밥이라고 생각했을 땐 음 ~ 그래도 먹을 순 있으니까..했는데 똥!!!!이였지 뭐에요.

그럼 당연히 악취제거 해야죠..네..저는 그날부터 제 코드를 다시 리팩토링 하기 시작했습니다.

신기하게도, 다시 제 코드를 여러 번 다시 들여다보니 고쳐야 할 부분이 보이고 내가 왜 이렇게 짰을까 후회하기도 했어요.

추가로 모의 면접 때 코드 피드백 받은 걸 반영하니 제 코드가 점점 더 명확해지 듯 했어요.

(심지어 원래 안되던 에러도 고쳤어요...)

이제는 냄새 안나는 똥... 같습니다. (아마도) 

"바닐라코딩은 지금부터 시작"

제가 생각하는 바닐라코딩의 하이라이트는 지금부터인 것 같습니다.

지금까지의 제 여정은 지금부터를 위한 준비과정에 불과하지 않았을까...하하

드디어 다음 주 부터 팀 프로젝트을 시작하게 됩니다. 

사실 제가 팀 프로젝트를 하면서 얼마나 성장할 수 있을 지 기대돼요✨

물론 좌절도 많이하고 제 부족함에 화도 많이 나겠지만, 그런 감정들을 느끼는 거에 비례하여 저는 성장할테니까요!

https://www.vanillacoding.co/

안녕하세요 다시 돌아온 바닐라코딩 부트캠프 후기입니다! 
4주차 후기로 마지막 인사를 드렸었는데, 어느덧 한 달 가까이 시간이 빠르게 흘러 7주차에 도달했습니다..

지금의 저는 자바스립트 주차를 종료하고 드디어 프론트엔드 주차를 맞이하여 React를 공부하고 있습니다.

처음에는 상태 관리, JSX, 가상 돔 ... 뭐든 것이 어렵게만 느껴졌었지만  과제도 어떻게든 뚝딱뚝딱 만들어내고 있습니다.

지금은 막 써내려간 고작 3 줄짜리 근황이지만 마지막 후기를 뒤로하고 보낸 3주는 저에게 있어 절대 3줄 짜리가 아니였습니다.

처음 리액트를 접하고 멘붕와서 바닐라코딩에서 새벽까지 전전긍긍하다가 만화카페, 찜질방에서 2~3시간 자고 다시 출근하고...

이렇게 며칠동안 집도 못가고 노트북을 붙잡고 있었던 얼마 전을 떠올리며 왜 그렇게 할 수 있었을까 곱씹어보면,

그 노력들이 오롯이 나를 위한 노력이었기에 가능했던 것 같아요.

누군가에게 잘 보이기 위해서도 아닌, 

노력했다라는 명분이 필요해서도 아닌,

정말  단순한 노력이 잠을 이겨 낼 힘을 주고, 내가 왜 이걸 이렇게 까지 해야되는지에 대해 명분을 주는 것 같았어요.

누군가 저에게 바닐라 코딩에서 무엇을 배웠냐고 여쭤본다면 단순한 노력을 배웠다고 말씀 드릴 것 같아요.
저는 항상 무언가를 하기에 이유가 필요한 사람이였거든요. 

돈을 벌고 싶으니까 알바를 하고 학점을 낮게 받으면 졸업을 못하니까 공부를 하고..

때로는 공들이지 않는 노력이 삶의 원동력을 주고, 깊게 생각해서 나온 무언가가 아닌 하찮은 노력이 더 힘이 될 때가 있다는 걸 깨달은 시기였습니다. 

"적는다고 다 코드가 아니고 작동한다고 다 구현이 아니다"

이게 갑자기 왠 뚱딴지 같은 소리라고 생각할 수 있겠지만, 이번 주차를 통해 저한테 사전에는 명시되어 있지 않은 저만의 사자성어가 되었어요. "적코작구" 웃기게 들리실 수도 있지만 나름 진지하답니다. 

이번 주에는 코드 리팩토링 기법에 대해 배우고 실습해보는 시간을 가졌습니다. 단순히 “리팩토링이 뭘까?”라는 개념적인 궁금증을 해소하는 데 그치지 않고, 실제 과제와 GitHub practice 문제에 적용해보고, 동기들과 코드 리뷰를 통해 다양한 관점을 접하고, 주말 스터디까지 같은 주제로 깊이 파고들며 배운 내용을 다져볼 수 있었어요.

그 과정에서 제가 코드에 대해 가졌던 생각이 많이 바뀌었습니다.
예전의 저는 “돌아가면 됐지 뭐”라는 안일한 생각으로 구현을 마무리했다면, 지금은 동작하는 코드 너머의 것들—가독성, 일관성, 유지보수성을 함께 고민하게 되었어요. 

‘작동하는 것’과 ‘좋은 구현’은 다르다는 걸 체감하면서,
이제는 코드를 “어떻게 더 잘 쓸 수 있을까?”라는 질문을 먼저 던지는 개발자가 되어가고 있습니다.

이번 주는 단순히 기술 하나를 배운 주차가 아니라,
개발자로서의 태도와 기준을 다잡게 된 시간이었습니다.
“적코작다”, 저만의 작은 다짐이자 리마인더로 계속 가져가 보려 합니다.🌈✨

마무리🌟

놀랍게도 이번 주를 마무리하고  브레이크 주간이 지나면 벌써 테스트 주간입니다.

테스트를 앞두고 벌써부터 마음이 바쁘고 긴장도 되지만, 리팩토링을 통해 코드를 보는 눈을 기른 것처럼, 이번에 치루게 될 테스트도 스쳐 지나가기를 바라는 테스트가 아닌 개발자로서의 나를 더 잘 알 수 있는 기회가 되길 바래봅니다! 

     https://www.vanillacoding.co/

안녕하세요,
저는 일주일 체험 수업 후기를 작성하고 약 한 달 뒤 3/17부터  바닐라 부트캠프에 정식으로 참여하게 되었습니다.👏🏻👏🏻

벌써 부트캠프가 시작된 지 한달이 되었는데요.

저는 어느덧 지하철에서 유튜브 숏츠만 돌려보던 제가, "읽기 쉬운 코드가 쉬운 코드"라는 책을 읽으면서 지하철을 타게 되고,

집에서 한 달 동안 게임 하고 누워있던 제가, 아침 6시에 일어나 밤 10시까지 공부하는 무언가에 몰두하는 삶을 살게 되었습니다.

조금씩 변화해가는 제 모습을 보며 저는 학원이 아닌 마치 템플 스테이에 온 것 처럼 느껴졌어요.

프론트엔드 개발자가 되기 위한 역량을 갖춰가는 것도 그렇지만, 제가 스스로가 무언가  채워지는 느낌을 받는 한 달이였습니다.

그럼, 제가 4주 차에는 어떤 것들을 경험했는지 지금부터 쓰려고 합니다.

4주차는 "테스트 주간"이였습니다. 3주간 배운 것들을 토대로 과제를 진행하면서  그 누구에게도 도움을 받지 않고 스스로 부딪혀보고 깨우침을 위한 주간이였습니다. 

"저 진짜 이거 할 수 있는 거 맞아요..?"

과제를 받고 든 생각은 "나 이거 할 수 있나..?" 였습니다. 아무리 3주간 고군분투 했지만 내가 이걸? 내가?? 마음 속으로 물음표를 수백개는 띄운 것 같습니다.. 결론부터 말하자면 가능했습니다. 제가 왜 할 수 있었냐를 천천히 생각해보면 처음으로 떠오르는 것은 

시작 전 탄탄한 준비였던 것 같습니다. 가이드라인에 제시된 시작 전 도움되는 영상, 리서치 주제, 중요 키워드를 한번 머릿속에 넣어보자라는 생각으로 임했습니다. 다만, 너무 시간을 쏟지 않는 것도 신경을 썼어요. 왜냐하면, 전 과제에서 리서치에 너무 집중한 나머지 시간이 촉박했던 경험이 있었기에, "100% 이해하지 않고 넘어가는 대신 과제 끝나고 또 공부하자" 라는 마인드로 공부했습니다. 

(저는 바코에서 깨달은 이 공부법을 강력 추천드립니다. 한번 봐서 100%이해할 지 언정 인간은 망각의 동물인지라 시간이 지난 후에는 최악의 상황으로 30% 언저리 밖에 남지 않더라구요. 반복학습만이 어떤 개념을 확실히 이해하는 가장 빠른 길인 것 같습니다.)

리서치, 영상 , 예제 코드 따라써보기 등을 마친 뒤, 테스트 과제에 돌입했어요. 역시나 쉽지만은 않았어요. 하지만 쉽지 않을 때 마다 제가 보고 배우고 느끼고 들은 3주간의 여정이 도움이 되었습니다. 머릿속을 지나가는 켄님의 "에러가 뜨면 이게 무슨 에러인 지 파악이 중요해요" 라는 말씀이 떠올라 에러 내용 구글 서치하고 놀랍게도 에러 파악만으로 문제점 접근이 훨씬 쉬워졌어요. 옛날의 저는 에러가 뜨면 스트레스부터 받고 방금 이 코드 고쳤으니 이게 문제겠거니 하고 무작정 값 바꿔보고, 형 바꿔보고 오히려 더 에러 폭탄을 맞는 일이 대수였는데 지금은 에러 접근 방식이 180도 달라졌음을 테스트 과제를 통해 느낄 수 있었어요. 

그렇게 차근차근 과제를 해결하며 앞으로 나아가고 있었습니다.

"한 단어를 쓰기위한 10시간"

과제를 하다 큰 벽을 마주한 적이 있습니다. 디버깅을 통해 에러가 어디서 왜 발생하는 지는 깨달았는데, 문제를 해결할 방법이 도통 떠오르지 않았어요. 하지만 버릇은 굳히기는 쉬워도 떼기는 어렵다는 말이 있듯이 에러 파악은 했으면서 혼자 또 무작정 코드를 작성하기 시작했습니다. 그러다가 안되니까 인터넷도 막 검색해봤어요. 인터넷 검색해도 안되니까 또 막 무작정 디버깅, 무작정 코드..지금 생각해보니 멘붕이 온 것 같았어요. 새벽 2시가 다되어가는 시점이였는데, 진정하고 환기할 필요가 있는 것 같아 결국 한 시간만 자고 다시 해결해보기로 했어요. 자려고 누웠는데 그 에러를 해결하고 싶어서 안달난 마음이 진정이 안됐어요. 결국 악몽을 꾸고 한 시간만에 잠에 벌떡 깨어 다시 그 에러와 다시 고군분투 하기 시작했어요 확실히 잠을 자고 오니 침착해진 것 같았습니다.

그리고 앉으면서 결심한게 있어요 에러 파악과 문제 해결 방안이 정확이 떠오르지 않을 때 까지는 코드를 보지 않는 거였습니다.

그렇게 아침이 되고, 저는 에러와 진중한 대화를 아직도 하고 있었어요. 마음 같아선 진실의 방에 데리고 가고 싶었 

하지만 그 침착하게 접근했던 시간동안 얻은게 있었어요. 에러 사항에 대한 문제 해결 방안이에요. 제가 3주동안 얻은 데이터베이스에 따르면 거의 모든 것은 "공문서" 안에서 해결 되었는데 그걸 에러에 대한 패닉 + 쏟아오지는 졸음 덕에 떠올리지 못했었어요. 

자, 이제 에러에 대한 해결 방안은 알았으니 어떻게 써먹냐인데... 아직 해결하지 못한 저는 무거운 발걸음으로 바닐라 코딩에 출석했습니다. 그리고 제 자리에 앉아 해결 방안을 토대로 코드를 작성하고 있었어요. 에러를 파악하면 문제 해결 방안을 못하고 문제 해결 방안을 알아도 써먹지 못하는 제가 막막하게만 느껴졌죠. 그러다 켄님이 하신 말씀 중에 깃헙에 코드를 검색하면 다른 사람들이 사용한 코드를 보여준다는 말씀이 떠올랐어요. 네.. 한 단어를 쓰고 그렇게 장황했던 저의 에러 해결기를 종료했습니다..

10시간이 아깝게 느껴졌냐고 물으신다면, 저는 아니라고 대답할 수 있을 것 같아요. 비록 그때의 저는 현타도 많이오고 내가 바보인가도 여러번 생각했지만, 지금 저한테 그 한 단어가 얼마의 값 어치를 가지고 있냐고 했을 때, 제 10시간이 부족하다고 말씀 드릴 것 같아요. 에러 사항에 접근하고 , 문제 해결 방안 터득하는 노하우를 습득하고, 정신력을 쏟아붓고 그런 과정 자체가 사실 저는 재밌었어요. 그 한 단어도 절대 잊지도 못하게 되었기도 하구요 하하하 그리고 제일 크게 배운 것 바로 디버깅 하는 방법이였답니다. 

추적하면서 지금 조사식을 확인하고, 이 코드가 무슨 목적의 코드인지 추론하고 깨닫고, 코드 흐름을 잘 이해할 수 있는 하나의 큰 계기가 되었어요. 그리고 앞으로 저한테 큰 디딤판이 될 것을 알기에 저한테는 아주 아주 뜻깊은 시간으로 남아있답니다✨

"느낀점"

과제는 해결하면서 구현도 구현이지만, 혼자 해결하는 방법을 배운 것 같았어요. 그리고 이번 과제를 통해 제가 얻고 깨달은 것들이 바닐라코딩에서 의도한 바 였던 것 같습니다. 에러가 나면 원인 파악을 하고, 디버깅을 해보고 스스로의 코딩 능력도 능력이지만 해결 능력을 길러주기 위함이였던 것 같아요. 그 의도대로 정말 저한테 뜻깊은 시간을 만들어주어서 알맹이가 꽉 찬 과제라고 생각했습니다!

한 달 동안 저는 사람으로서 성장도 많이 한 것 같아요. 옛날에 저는 다른 사람 눈만 마주쳐도 피하기 일쑤였지만, 지금은 동기 분들한테 인사하는 것도 꼭 꼭 잊지 않으려고 애쓰고 간단한 인삿말이라도 건네려고 노력하고 있어요. 그리고 전에는 수업 도중 손을 번쩍 들고 내 의견을 말하는게 쪽팔리다고 생각하여 숨기에 급급했지만, 지금은 수업 중에 궁금한 것 , 내 의견을 말하는 것을 연습하고 있어요. 물론 지금도 얼굴이 뜨거워지고 챙피하다고 느끼지만 의견을 효과적으로 전달하는 법, 질문에 내 의도를 정확히 담아 전달하는 법등에 강해지고 있는게 느껴져요. 앞으로 또 후기를 쓸 때 마다 성장 할 저를 생각하니 더욱이 기대가 되는 것 같습니다! 다음 후기에는 더 성장한 제가 되어 돌아오도록 할게요!👋🏻

바닐라 코딩 :https://www.vanillacoding.co/

HTML에 자바 스크립트를 삽입하는 방법을 공부하다 왜 script 태그는 body 맨 뒤에 삽입을 하는 지에 대해서 공부했다.

사실 <script>태그는 <body>,<head> 어디에 놓더라도 동작한다. 

근데 왜 다른 html코드를 보면 다 맨 뒤에 작성한걸까?

실제로 구글 창도 개발자 도구를 열어보면 스크립트 코드를 맨 밑에 작성한 것을 확인할 수 있다.

케이스 별로 알아보도록 하자!

1. head 태그 안에 위치시키는 경우

브라우저가 HTML 코드를 읽어내려오다가 <script> 태그를 만나면, 코드 읽는 것을 멈추고 script를 다운로드 하고 실행을 시킨다.

그리고 다시 HTML 코드를 읽기 시작한다. 

만약 이때, script 파일 용량이 너무 크거나 갯수가 많으면 다운로드하고 실행하는데 많은 시간이 소요됨으로 사용자가 화면을

보기까지 상당히 많은 시간이 걸릴 수 있다. 

2. body 태그의 맨 아래에 위치 시키는 경우

브라우저가 HTML 코드를 다 읽은 후에 스크립트를 다운받고 실행하기 때문에 사용자들은 기본적인 html 콘텐츠를 볼 수 있다.

하지만 만약 html 코드가 스크립트에 의존적이라면, 아직 동적 동작이 안되는 무의미한 content를 보게되는 단점도 존재하지만 이 방법은 DOM트리가 생성되기 전에 script가 DOM 조작을 시도하는 것을 방지할 수 있기 때문에 주로 사용된다.

이 밖에도 async,defer등 비동기 방법이 존재한다.

이번에는 비동기 방법에 대해 알아보자.

<async>

script 태그를 만나도 HTML 코드를 중단하지 않는다. script 로드와 html 읽기를 함께 하다가 script 로드가 끝나면 script가 실행되는 시점에 HTML 읽기를 중단하고 실행이 끝나면 다시 읽는다.

<script async src="script.js">

<defer>

script 태그를 만나도 html 파일을 읽는 것을 중단하지 않고 일단 script 로드와 파싱을 함께 한 후 html 파싱이 끝난 후에 로드한 script를 실행시킨다.

<script defer src= "sript.js">

<ref>

https://codingnotes.tistory.com/44

https://velog.io/@dltjsgho/Script-%ED%8C%8C%EC%9D%BC%EC%9D%98-%EC%9C%84%EC%B9%98

CSS 스타일 적용 우선순위

1. 인라인 스타일(Inline style) 

2. 내부 적용 스타일(Internal style)

3. 외부 적용 스타일(External style)

CSS 우선순위 실험

Html 문서 내에 내부 적용 스타일, 외부 적용 스타일, 인라인 스타일을 동시에 사용하였다.

브라우저를 열어보니 인라인 스타일이 적용되었다. 

실험 결과로 인라인 스타일 > 내부 적용 스타일 > 외부 적용 스타일임을 알게 되었다. 

적용 우선순위

  ❶ 속성 값 뒤에 !important를 붙인 속성

  ❷ HTML에서 style을 직접 지정한 속성 (인라인 스타일)

  ❸ #id로 지정한 속성

  ❹ 클래스, :추상클래스로 지정한 속성

  ❺ 태그이름으로 지정한 속성 

  ❻ 상위 객체에 의해 상속된 속성 

❔!important 

css 스타일을 지정할 때 우선 순위를 무시해야 할 때가 있다. 이럴 경우 !important 키워드를 사용하면 일반적인 property: value; 보다 해당 선언이 중요하다고 표시한다.

property: value !important;

💡실험

!important를 쓰니 우선 순위를 무시하고 내부 적용 스타일로 반영이 된 것을 확인해 볼 수 있었다.

span : 인라인 요소

div : 블록 요소