블로그

90년대 컴퓨터 공학 이야기 (1) — 80년대 이야기 — 퍼스널 컴퓨터

90년대 컴퓨터공학과를 다니면서 모은 에피소드들이지만, 기억은 80년대의 몇몇 단어들에서 시작한다.퍼스널 컴퓨터 경진대회1985년 국민학교에서 방과후 학습으로 산수경시반을 뽑았는데, 당시 부산에서 인근 구청에서 있던 수학경시대회가 없어지는 바람에 컴퓨터반으로 변경되어 운영이 되었고, 퍼스널 컴퓨터라는 것을 접하고 경진대회라는 것도 접하게 되었다. 지금 있는 올림피아드의 원형일 것이고, 당시 운도 좋았어서 1986년에는 부산 대표로 서울 잠실이라는 곳을 처음 올라오는 경험도 하게 되었다. 마치 과거 시험을 보듯이 넓은 공간에 각자 컴퓨터를 들고 와서 4시간인가 시험을 치르는 자리였고, 여기를 오기 위해 구 대회, 부산 시 대회 등을 거쳐야 했었다.첫 출전 당시 버그로 인한 탈락의 아픔이 있었고, 이를 극복해 보고자 지역에서 여러 번의 시도를 하며 중학교 2학년까지 여러 가지 기량을 쌓음과 동시에 컴퓨터 게임과 더 친해지게 되었다. 전국 대회와의 인연은 더이상 닿지 않았지만, 마지막 대회에서 구 1위까지는 올라갔던, 나름 해피 엔딩.삼성 SPC 1000우리 집에서의 첫 삼성 제품은 이 컴퓨터였다. 학교에서 접하고 나서 서울 전국대회 출전권을 따고 나서 부모님을 졸라서 인연이 닿은 첫 컴퓨터. 테이프를 이용한 낯선 기계음, 그것이 끝나면서 시작되는 게임들, 흑백 화면에서 펼쳐지는 dot 의 아기자기함 등… 국민학교를 함께 했고, 각종 대회에 같이 다녔으며 아쉬움과 실패를 경험하게 했던 기억들.컴퓨터학습매달 용돈을 받거나 벌어야 했던 첫번째 이유. 가끔씩 자매품인 학생과 컴퓨터 도 있어서 매 달 둘 중 어느 것을 사야 하나 고민을 했던 경험도 있고, 더 고급진 책도 있었던 기억이지만, 적당히 재미난 내용들, 신기술, 거기에 게임도 섞여 있었음. 무엇보다 이 책이 가진 의미는 소스 코드들에 있었고, 이를 타이핑하면서 인내심을 알게 모르게 키워 왔던 게 나중에 값지게 쓰였던 것 같다.Apple II+중학교 때 경진대회를 위해 졸라서 하나 새걸로 장만했던 기억인데, 이 때 제품이 정확하게 뭐였는지는 기억이 없다. IIe 였던 거 같기도 하고… 툭툭거리는 키보드가 마음에 들었었고, 플로피 디스크의 신세계를 여기서 경험하게 되었다. 경진대회를 빙자했지만, 게임 중독으로 가기 일보 직전이었던 거 같다.Lode Runner, Ultima 4, Ultima 5, Ogre나의 중학교 생활을 함께 했던 동지들. Lord British , thou art , 그리고 각종 게임용 spell , ingredient , weapon , dragon , …— -이후 나는 수험생 모드로 입시에 전념하면서 90년대를 맞이한다.

교양컴퓨터공학90년대

한국 IT 용어 이야기 (번외) - "인공지능"

최근, 특히 ChatGPT 이후 격변의 시기에 영어로도 한글로도 어마어마한 신조어들이 나오게 되면서 헷갈리게 되었다. 이전에는 리뷰 받은 후 발표되는 논문들과 official posting 이 source of truth 였다고 한다면 요즘에는 리뷰받지 않은 일방적인 주장 위주의 논문들, 각종 신문, 유튜버, communicator 들이 정신 없는 이야기들 속에서 가끔씩 잠깐만? 싶은 일들이 있곤 한다. 최근에 한 학기 AI literacy 관련 강의를 위해 정리하던 내용들... 2024년에는 또 어떤 신조어들이 생겨날 것인지... 쏙쏙 들어오는(?) 번역들Artificial Intelligence : 인공지능 . 가끔씩은 스피커 대화 서비스 or 챗봇 서비스를 나타내기도..Neural Network : 신경망Reinforcement Learning : 강화학습Gen AI , Generative AI : 생성형 인공지능오래 전부터 쓰였던, 여러 사람들을 통해서 쓰이고 있는 단어들. 상대적으로 귀에 잘 들어 옴. 최선을 다했다 싶은 번역들 ( 그냥 영어로 써도... ? )Convolutional neural networks : 합성곱 신경망Recurrent neural network : 순환 신경망regression : 회귀time series : 시계열Machine learning : 기계 학습Deep learning : 심층 학습Training / Inference : 훈련 / 추론RLHF : 인간 피드백 강화 학습Federated learning : 연합 학습(?) 이제 번역이 어색해 지기 시작함...영어 그대로 쓰자TransformerAttentionFine tuning / retrainigLanguage model / Large language model / small language modelLarge multimodal modelFrontier AI 앞으로 나올 수많은 개념들... 어지간하면 원어 기준으로 받아 들여 보자.. 고유명사 혹은 일반 명사들OpenAI / GPT4 / ChatGPT / 챗GPTGemini / Llama / midjourney / langchainCohere / Adhere / ...PyTorch / Tensorflow / ...Prompt / agent /약자들 : RAG / MoE / BERT ... 뭐가 회사 이름이고, 뭐가 제품 이름인지 이제 헷갈리기 시작... 타사 제품과 서비스와 헷갈리지 않을 수 있으면 좋겠고, 제발 일반명사는 쓰지 말고 귀찮더라도 풀어 설명해 주시길.... --a 불편한 신조어들초거대 AI : 한국형 마케팅 중심의 용어로 추정. "초", "거대" 둘 다 불편함. AI != LM 의 시각에서 알맞은 영어 번역도 떠오르지 않고, 어딘가에서 말하는 hyperscale 은 이미 data center 용 computing 을 나타내는 말로 적절한 영어 번역이 아님.생성형 모델 : 언어 모델을 이용한 생성 서비스 ? bonus - Very초거대 라는 단어를 들으면서 무의식적으로 'very는 아니겠지?' 라는 생각을 했었다. 오래 전 컴퓨터 구조 시간에 배웠던 몇몇 단어들이 생각났는데, '설마 very는 아니겠지?' 라며 들여다 보면 여지 없이 very 였어서 뭔가 작명에 게으른 선배 기술자님들을 떠올렸더랬다.VLSI : Very Large Scale Integration ( 초고밀도 집적 회로 )VLIW architecture : Very Long Instruction Word architectureVHDL : VHSIC Hardware Description Language : Very High Speed Integrated Circuit Hardware Description Language 

교양용어한글영어

신영우

[인프런 워밍업 스터디 클럽 1기 디자인] 2주차 발자국 (신영우)

학습 내용복습을 위해 이번 주에 필기한 강의 내용을 갈무리했습니다프로퍼티의 종류들Text 프로퍼티 → 디폴트 텍스트 설정instance swap → 변경할 수 있는 에셋 설정이때 Value 에서 디폴트 에셋 설정 가능Preferred values에서 변경할 수 있는 에셋들 설정 가능프로퍼티의 위치를 바꿔주는 것도 중요Leading icon 의 Boolean 프로퍼티 아래 → Leading icon 의 instance swap 프로퍼티를 위치시켜 디자인 시스템 사용성을 증진시키는 구성을 만들어 줌에셋의 높이를 통일시켜주는 것도 중요모 컴포넌트에 min, max 하이트 값을 넣어주면 자 컴포넌트에도 적용 볼드님 질의 응답 답변Storke가 살이있는 아이콘은 Union을 먼저 한 다음 Outline Stroke로 깨야함 → Storke 값이 살아있으면 리사이징 시 값이 유지 됌 (리사이징 되지 않음) 발견한 설계 꿀팁인스턴스가 조합된 최종 상태의 컴포넌트는 한번 더 묶어주기디자인 시스템 사용성 챙기기이 때 기준이 되는 모 컴포넌트는 ‘part/’ 라벨링을 붙여 검색 시 노출 안되게 해주기 ex)컴포넌트 베리언트에서 절대 위치(앱솔루트 포지션) 적용할 수 있음 그리고 절대 위치 적용한 디자인 에셋에 컨스트레인 적용해서 반응형으로 설정 가능함ex)컴포넌트 베리언트 정의한 영역 안에서 일괄 적용되지 않게 하려면 각 개별 컴포넌트 안에서 에셋을 정의하면 됌Boolean으로 적용하면 안되는 부분, 적용하지 않으려는 목적으로 작용ex)작업 이후 디자인 에셋들 Contrast 체크해서 접근성 갖추기몰랐던 점들이미지 삽입 관련이미지도 스타일 등록이 가능하니 자주 쓰는 이미지는 등록해놓으면 좋을 것 같다 이미지 삽입할 때 ‘프레임 배경 컬러 선택 → 이미지 선택’해서 넣어주는게 좋을 것 같다( 1. 이미지 자유롭게 리사이징 가능 / 2. 이미지 다른 에셋으로 곧바로 변경 가능 )오토 레이아웃 설정 관련오토 레이아웃 설정에서 스트로크 같이 면으로 처리 안되는 친구들의 ‘Included / Excluded’를 설정할 수 있다오토 레이아웃 설정에서 에셋들의 스택 순서를 ‘Last on top / First on top’으로 변경할 수 있다 미션 내용회고를 위해 이번 주에 진행한 미션 내용을 톺아봤습니다미션 #5 - 피그마 컴포넌트 기초 배우고 입력 컴포넌트 만들어보기미션 #6 - 입력 컴포넌트 나머지 만들고 마지막 점검하기미션 #7 - 디스플레이 컴포넌트 만들어보기미션 #8 - 디스플레이 컴포넌트 나머지 만들고 마지막 점검하기  이번 주 미션도 저번 주와 마찬가지로 총 4개의 미션이었다.미션 #5, #6, #7, #8 과정 모두 컴포넌트를 만드는 미션으로 UX 경험적으로 꼭 필요한 공통 에셋들을 만들어보는 과정이었다.실무에서 공통 에셋들을 만들어본 적은 있지만, 수업처럼 모든 에셋들을 만들어본 적은 없어서 본격적인 과정들이 쉽진 않았다. (생각보다 시간이 오래걸리는 점도 꽤나 힘들었다)그래도 미션 #5, #6, #7, #8 과정을 거치며 베리어블 사용하는 것에 어느정도 익숙해진 것 같다. (조금 속도가 붙었다)중간중간 적용을 까먹고 빼먹는 친구들이 종종 있는데 좀 더 꼼꼼히 살피면서 설계할 필요가 있는 것 같다.다음 주도 공통 컴포넌트 에셋을 만드는 작업을 이어서 진행한다.빨리 페이지에 만들어놓은 컴포넌트 에셋들을 적용시켜보고 싶다...!완주까지 기대가 되는 요즘이다. 굿! 스스로 칭찬하고 싶은 점 : 월요일, 화요일 매우 몰입해서 미션 #5, #6, #7, #8을 모두 완주한 점아쉬웠던 점 : 아이콘 시스템, 타이포 그래피 시스템을 다듬어야 하는데 다듬지 못한 점보완하고 싶은 점 : 타이포 그래피 시스템도 베리어블을 적용해보고 싶은 점다음주 목표 : 3주차 들어가기 전 아이콘 시스템, 타이포 그래피 시스템 다듬어야할 친구들 무조건 손보고 들어가기! 

UX/UI피그마베리어블디자인시스템

한국 IT 용어 이야기 (8) - "팀"

아마도 어릴 때 프로 스포츠들로 팀을 접해서 은연중에 아래와 같은 고정 관념들이 있어 왔다. 1) 적으면 5명, 대개 9명, 많으면 후보 포함 25명, 2) 공통의 목표가 있고, 경쟁을 해서 이겨야 할 상대방이 있음.... 3) 비슷한 규모의 다른 팀이 언제나 있음. 이후 대학교에 들어가서야 팀 프로젝트 같은 걸 접하게 되었고, 다른 단어 고민 없이 여러 가지 문맥에 상관 없이 팀이라는 단어를 접해 왔었다. 아래는 사회 생활을 하면서 접하게 된 "팀"에 대한 몇가지 이야기들..팀장과 팀원사회 생활을 하며 팀장이라는 직함을 쉽게 접하게 되었는데, 삼성전자의 경우 상무이사급 임원이 팀장으로 200명을 거느리고 있는 경우가 있었고, 자그마한 회사에서 1인 팀의 팀장이라 불리는 사람이 있기도, 혹은 3-4명 조별과제 정도 크기의 일들이 있었더랬다. 이 경우 팀장의 역할이라는 것도 스펙트럼이 넓었고, 인사권을 총괄하는 의미부터 간단한 POC 까지 다양했다. scope는 매번 눈치껏 알아서 챙겨야 했지만, 팀장의 호출 하에 한 자리에 모일 정도 되면 하나의 팀원으로 생각하는 정도...?대화 상대로서 ### 팀장이라는 사람을 만났을 때 어디까지를 기대해야 할까 ? 반대쪽의 입장에서 기대하는 정도에 따라서 난이도가 있었던 기억이고, 종종 '팀장이라는 당신 말고 책임자와 이야기하고 싶다' 라는 생각을 했던 기억이다.미국에서의 팀생각보다 광범위하게 쓰여서 다른 의미로 눈치가 필요했었다. 식당에 가면 종업원들이 팀 혹은 crew 로 불리우고 only team member allowed from here 등으로 뭐랄까 그룹지어질 수 있는 모든 규모를 다 팀으로 부르고 있었던 거 같다.회사에서 팀이 커지거나 해서 여러 계층이 필요하게 되었을 때 매번 이름을 짓는 것도 일인데, 행정적 편의로 누구누구네 팀을 그냥 불러서 쓰곤 했었다. Rajan's team, Jen's folks, Michael's guys 등등.. report line 을 통째로 들고 생각하는 모습이라 관리하는 측면에서 많은 이득이 있었다.조직도가 다른 사람들을 차출의 형식으로 모아 일하게 될 때 코드 네임 등을 유용하게 썼던 기억이다. 이전에 구글 플레이스토어 한국/일본 과제를 할 때 미국에서 일하는 한국어/일본어 능력자들을 차출한 후 "dragonball" 이라는 한일관계에 나름 중립적인 팀 이름으로 모인 적도 있었고, 그 이전에 한동안 Calypso 라는 이름으로 50명 정도의 팀이 알려진 적도 있었더랬다. 만나는 거의 모든 사람들과의 대화에 "What is Calypso?" 로 시작했어야 하지만, 나쁘지 않았고, 당시 이름이 과제의 주제와 꽤 잘 맞아서 많이들 좋아했던 기억이다. 검색, 유튜브 등과 같이 거대한 게 되지 않는다면 영원한 것은 없고, 결과적으로 과제 별로는 2-3년 정도가 적당한 life cycle 이었던 거 같다.목적 조직/기능 조직, squad, chapter, task force한국에 다시 조인하고 나서 가장 어색하게 적응했던 것이 목적 조직, squad, chapter, 등의 유사 팀의 운용에 대한 내용이다. 10년 넘게 구글에서 speed & flexibility 에서 전혀 손해를 보았다는 생각이 없는 상태여서 개인차가 물론 있을 것인데, 한국에서 대다수의 회사들이 agile, velocity 등의 명분으로 squad, chapter, silo 등의 이름으로 팀들을 다양하게 나누어 정의하고 운용하고 있음에 많이 어색해 한다.개인적인 선입견이 강하게 있다. 먼저, spotify 에서 시도했지만 실패로 기록이 남았다고 하는데, 그에 비해 너나 할 거 없이 쓰고 있는 게 이해가 잘 안 된다. 그리고 스쿼드의 형태로 운용되려면 아래 3가지 정도는 챙겨 져야 한다는 생각이다. 1) 해체를 포함한 기간을 담보한 직원들 rotation 보장, 2) 모든 직군 별 commitment level ( up to 100% ) 3) 최소한의 코드 quaitly ... 더 깊은 이야기는 케바케일 거 같으니 여기서는 이 정도만 ...당장 치루어야 할 과제를 하기 위해 어쩔 수 없이 시작했다가 여러 이유로 계속 눌러 붙어 있으면서 부작용들이 진행되는 모습들이고, 그게 특히 스타트업씬에서는 더 적나라하게 나타나는 것으로 이해한다. 코드의 경우 쓰는 사람들만 있고 지우는 사람들이 없는 모습과도 닿아 있고, 한두명이 번아웃이 났을 때 위험에 더 드러나게 되는 모습이 되기도 한다. 회사들마다 사정이 다르겠지만, 꼰대스러운 한 마디의 잔소리만 하자면, 스쿼드든 챕터든 나 말고 상대방을, 동료를 한 번 더 생각하고 거드는 모습이 더 있고, 그걸 매니지먼트에서 존중하면 조금 더 낫지 않을까 하는 생각이다.Lead, head of ###구글에 다녔을 때도 한국에서는 상대적으로 작은 규모의 팀이다 보니 중소기업에 다녔을 때처럼 명함의 직함이 조금 뻥튀기 되어 있기도 했다. 구글 내에서는 그래도 자기 직함을 쓰는 건 매니저 승인이 필요했지만, 아무래도 링크드인 출범 이후에 (살짝 과장된) 직함들이 감투로서 쓰이곤 하는 거 같다. 규모가 작은 회사일 수록 Chief , Lead , Head 등이 아무래도 자주 보이는데, 면접 과정이거나 실제 업무를 같이 해 보기 전에 판단을 해야 하는 입장에서는 난이도가 꽤 높다. 뭐 거짓말을 악의적으로 하려고까지는 아니라 생각해도...게다가 최근에 보았던 사례들은 감투를 주면 바로 퇴사를 감행하고, 그들의 이력서는 ### Lead 로 update 되어 있었다. 타사와 협상을 잘 이뤄냈다고 긍정적으로 볼 수도 있겠으나, 새로운 감투를 달았으면 그 감투를 달고 몇 명의 사람들과 어떤 일을 이루어 냈는지 등이 궁금하고 반대로는 자랑하고 싶어야 할텐데, 서로 속고 속이는 세상이 되고 있는 거 같아 조금 씁쓸하고 불안(?)하기도 하다.

교양용어한글영어

삼각커피포리

[인프런 워밍업 스터디 클럽 1기] 디자인 1주차 발자국

첫번째 발자국우여곡절이 많았던 1주차였다. OT때 하루에 하나씩 미션을 수행하겠다는 다짐과 달리 미션을 못 한 날도 있고 몰아서 한 날도 있었다. 어찌저찌 1주차를 맞았으니 그동안 돌아보는 발자국을 작성해봐야겠다.  Day1 OT피그잼에서 수 많은 사람들의 마우스 커서와 함께 오리엔테이션이 진행되었다. 멘토님은 영국에서 우리와 다른 시간대에 계시면서 라이브를 진행하셨다. 인프런 워밍업 스터디 커리큘럼을 보면 매일 미션이 있어서 다 지킬 수 있을까? 하는 생각이 들어 신청하기 전 고민이 있었다. 미션은 기한을 놓치더라고 올리면 되고, 미리 올려도 된다고 말씀해주셔서 심리적으로 편안해졌다. 아무래도 온라인으로 진행되고 혼자하는 스터디라서 외롭지 않을까 싶었는데 피그잼에서 만난 다른이들의 마우스 커서가 정말 반가웠다. OT때 피그잼에 작성한 세 가지가 있었다. 스터디 러너로 신청한 이유, 매일의 계획, 자기 자신에게 줄 보상. 내가 적은 세 가지 항목들을 잊지말고 스터디에 열심히 임해야겠다.  DAY2 배리어블과 토큰, 디자인 시스템의 개념강의를 시작하며, 먼저 해야할 것이 있었다. 그것은 바로 피그마 에듀케이션 계정 신청이다. 현재 개인 피그마 계정을 무료 플랜으로 사용하는 나는 강의 시작 전 필수 사항에 나와있는 내용으로 에듀케이션 계정을 신청했다. 안내해주신 방법으로 진행하니 금새 신청이 완료되었다. 1주차 중에서 이 날이 가장 어려웠다. 토큰과 배리어블의 개념을 유튜브나 디자인 아티클을 보며 대략적으로 알고 있었다고 생각했는데 아니었다. 그동안 내가 알고 있던 것은 모두 수박 겉핥기 뿐인 지식이었다. 아마 개념 강의를 들으며 적은 노트가 다른 강의보다 제일 많았다.특히 이번 파트에서 좋았던 건 내가 디자인시스템을 뜯어보며 가장 궁금했던 이름들의 의미를 알 수 있어서 좋았다. --md-, spectrum-, --p-, --lsdg- 이런 이름들의 의미가 시스템의 이름이라는 것을 알 수 있어서 좋았다. 그리고 티셔츠 사이즈라는 개념도 배웠는데, 예전에 디자인시스템을 뜯어보다 발견한 문자 중 sm과 lg가 small, large의 약자인 지 몰라서 한참을 검색했던 기억이 생각났다.Shopify Polaris에서 캡쳐 Day3 색상 스타일 등록 및 배리어블이 파트에서는 무엇보다도 색상 구조의 이름을 비교해보기 위해서 직접 엑셀에 이름을 하나하나 뜯어서 정리해보셨다는 것이 인상깊었다. 그동안 디자인시스템을 분석하기 위해 각 사이트들을 모아서 살펴보고 피그마 파일도 뜯어봤지만 이렇게 정리해볼 생각은 못 했다. 비록 지금은 미션이 급해서 엑셀로 정리를 못 했지만 완강 이후에 2회독 때 꼭 이 작업를 해봐야겠다고 결심했다. 강의에서 가장 인상깊었던 부분 - 색상 배리어블 구조, 이름 짜보기에서 캡쳐강의를 들은 이후에 MS의 Fluent 2 Design System의 Color token 문서를 다시보니 전과는 다르게 보였다. 그 전에는 쏟아지는 영어와 색상들과 스크롤 길이에 압도 당하는 느낌이었는데 이제는 찬찬히 살펴볼 수 있게 되었다.Fluent 2 Design System에서 캡쳐 드디어 첫번째 미션이다. 처음에 강의 명만 봤을때는 컬러를 어떻게 헥사코드로 뽑을지 HSL로 뽑을지 궁금했었는데 강의를 보며 모두 플러그인으로 진행하는 것을 보고 큰 충격을 받았다. 그렇다. 피그마는 이제 플러그인이 발달해서 적재적소에 쓰기만 하면 되는 아주 편리한 툴이란 것을 새삼 깨달았다. 물론 실무에서는 브랜드컬러에 맞게 색상을 좀 더 세밀하게 조정하기도 하겠지만 플러그인으로 빠르게 작업을 한다며 업무 효율도도 많이 오르고 좋을 것 같다. Color Scoping이란 기능이 신기했다. 처음에 배리어블에 색상을 등록하면서 이렇게 계속 등록하다간 나중에 배리어블 창은 작고 선택할 색상이 많아서 찾느라 시간 보내는거 아닐까? 하는 생각은 기우였다. 해당 기능으로 원하는 요소에 원하는 색상만 보이게 한다는게 편하고 좋았다. 정말 피그마란 툴이 효율적으로 프로덕트를 만들기 위해 제작되었다는 걸 또 깨닫게 되었다. 나는 현재 실무에서 배리어블이 아니라 스타일을 사용하여 작업하고 있는데 이제 배리어블을 알게되었으니 언젠가는 스타일에 있는 컬러를 배리어블로 전환하는 일을 해야겠다는 생각도 들었다.  Day4 간격 배리어블, 타이포그래피, 아이콘간격 배리어블을 미리 알았으면 얼마나 좋았을까… 그동안 4,8,12로 간격을 주었지만 손가락이 미끄러져서 5,9,11 이런 식으로 잘못 오기된 나날들이 떠올랐다. 개발자 분이 작업한 간격이 이상해서 다시 살펴보면 내가 작업한 피그마에 간격이 잘못 입력되어 있을 때가 종종 있었기때문이다. 타이포그래피는 영문으로 진행되어 조금 아쉬웠다. 타이포 스타일 가이드 중에 국문으로 만들어주는 것이 있는지 찾아봐야겠다. 국문의 경우는 항상 자간을 조정하는데 영문은 그런 작업이 필요 없는지도 궁금했다. 추가로, 일단 화면 만들기 전에 타이포그래피 가이드를 먼저 만드는 점이 의아했다. 가이드를 만드는 선행 작업를 통해 작업물의 타이포 위계를 명확히 하려는 것이 목적인 거라면 실무에서 가이드로 만든 사이즈 외의 글자가 생겨날 땐 어떻게 대응하시는지 궁금했다. Feather Icon은 무료 아이콘으로 여러번 소개가 되어서 알고 있었는데 이렇게 강의에서 만나고 써보니까 새롭다. 일괄적으로 원하는 사이즈를 원하는 두께로 추출 가능하다는 점이 정말 좋았다. 바퀴를 다시 발명하지 마라 라는 격언이 떠올랐다. 오픈소스에다가 MIT라이선스인 아이콘 사이트가 하나 생각났다. 다른 러너분들도 알면 좋은 정보라고 생각되어 사이트를 기재해본다. Feather Icon처럼 두께 설정 세밀하게 할 수는 없지만 크기와 색상을 일괄적용 할 수 있어서 즐겨찾기 해둔 곳이다.Phosphor Iconshttps://phosphoricons.com/ Phosphor Icons에서 캡쳐  Day5 그림자 효과, 반응형 기준점, 기타 배리어블나는 정말 Elevation이 구글의 머터리얼 디자인 가이드를 살펴볼 때 너무 어려웠었다. 일단 단어가 생소하기도 하고 국문으로 일대일 번역하기 어려운 단어기도 해서 그런 것 같다. 특히 구글의 m3에서는 m2보다 내용이 더 추가되어 더 헷갈렸었다. 그런데 강의에서 ‘높낮이’라고 표현해주셨는데 그때 아! 하고 개념이 이해가 되었다. 비록 강의에서는 그림자(shadow)라고 한 뒤 미션을 진행되었지만 높낮이라고 이해하며 머터리얼 디자인가이드를 다시 읽으니 전과 다르게 이해가 잘되었다. 내게 Elevation의 개념을 가장 잘 설명해줬던 파트(강의 중 캡쳐) 반응형 기준점 설명 시에 나오는 고정형(fixed)과 반응형(fluid)는 미리 알고 있던 개념인데 하이브리드 개념은 처음 알게 되었다. 주로 왼쪽에 SNB가 있는 경우 왼쪽은 고정형, 오른쪽은 반응형으로 하는게하이브리드의 예시라고 하셨다. 이걸 알고나니 너무 속이 개운했다. 지금 실무에서 작업하는 레이아웃이 하이브리드 형태인데 그동안 이름을 몰라서 이걸 고정형도 아니고 반응형도 아니고 뭐라고 불러야되나 고심했던적이 있기 때문이다. 이렇게 강의를 들으며 새로 알게되는 사실이 그동안 고민을 했던 부분을 시원하게 해결해줘서 좋았다. 기타 배리어블에서는 테두리(Border)와 투명도(Opacity)를 다뤘다. 색상 배리어블 할 때 Frame, Text, Icon, Border의 색상 넣는 것을 할 때 보더의 두께나 투명도도 배리어블이 있었으면 좋겠는데 라는 생각을 했는데 강의가 나온 이후에 피그마에서 업데이트가 있었나보다. 여기에서도 앞에서 했던것과 마찬가지로 배리어블을 등록하고 쉬프트 누르고 왼쪽으로 클릭해서 값을 지정하니 정말 편했다.  Day6 스타일 파운데이션 다듬고 내보내기컴포넌트 설명을 붕어빵에 비유하신게 정말 찰떡이고 기억에 남았다. 그리고 컴포넌트 만드는 순서를 두 가지 보여주셨는데 두 가지 사례 중에서 내가 실무에서 사용하고 있는 방법이 첫번째 방법이라서 익숙했다. 앞으로 강의도 이와 같은 순서로 진행된다고 하는데 내가 실무에서 사용하고 있는 방법와 어떤 부분이 같고 다른지 비교해 볼 수 있을 것 같아서 기대가 된다.앞으로 강의에서 사용될 예정인 컴포넌트 만드는 순서 캡쳐강의 자료로 공유해주신 컴포넌트 워크시트에서 웹접근성 항목을 보며 그동안 나는 웹접근성을 지키면서 컴포넌트를 만들었는지 스스로를 되돌아보게 되었다. 왜냐면 일정에 쫓겨 항상 급하게 무언가를 만들고 화면을 쳐내기에 바빴지 이렇게 상세하게 정리하고 체크해본적이 없기 때문이었다. 아직 미션4는 작업중인데 디스코드에 올라오는 다른 러너들의 다양한 스타일이 무척 흥미롭다. 나도 나만의 스타일 가이드를 만들어서 미션을 마무리 지어야겠다는 생각을 했다. DAY7 첫번째 중간점검 및 질의응답 세션특별강의에서 가장 신기한 것은 아이콘이 안 깨지게 조정하는 앤트맨 전략이 정말 신기했다. 깨진 아이콘 문제를 해결하기 위한 다양한 사례들을 하나하나 보여주셨는데, 아이콘 문제를 해결하기 위한 튜터님의 집념에 경의를 표하고 싶었다.피그마에서 최근 업데이트 된 멀티 에딧은 업데이트되었다는 소식만 듣고 시간이 없어서 제대로 살펴보지 못했는데 이 세션에서 자세히 살펴 볼 수 있었다. 앞으로 다양한 컴포넌트를 만들 때 정말 잘 쓰일 것 같다. 특히 멀티 에딧을 할 때 아이콘은 프레임 상태가 아니라 꼭 에셋 상태로 등록해야 멀티 에딧을 제대로 쓸 수 있다는 것도 알게 되었다.디스코드 질문 답변 채널에 남긴 질문에 대한 답변을 들을 수 있었는데, 강의를 들으며 궁금했던 부분을 이렇게 라이브 세션으로 답변 받을 수 있어서 속 시원했다. 아이콘 크기가 다른 경우에는 버튼도 크기를 다양한 세트를 준비하는 것이 작업에 더 효율적이라고 알려주셨다.내가 디스코드 채널에 올린 질문 그 외 추가로 채팅창에 올라오는 질문들도 하나하나 모두 답변해주셔서 정말 감사했다.Q.아이콘도 사이즈별로 구성하는걸 추천하나요? (16px, 24px, 32px…)→ YES. 그렇게 쓰려고 아이콘을 깨는 겁니다. 그래야 사이즈가 다양하게 조절해도 되니까요. 우리 회사 디자인 리소스가 많다면(=디자인 일할 사람도 많고, 디테일을 원한다면) 다양한 사이즈 추천. 하지만 사람이 없다. 그럼 하나의 아이콘으로 쭉 쓰는걸 추천.Q.오픈소스 아이콘을 써도 무방할까요?→ YES 디자이너가 하나하나 만들 수는 없다.Q. 아이콘을 flatten selection 하면 수정이 불가능한데, 원본을 따로 저장하나요?→ YES 원본은 따로 저장해둡니다. 나 말고 다른 사람이 어떻게 쓸 지 모르기 때문에. 특히 프레임으로 만들어진 아이콘 라이브러리 따로, 시스템에서 사용하는 것 따로 존재함 특강에서 앞으로 만들 컴포넌트 종류를 살짝 보여주셨는데 정말 많았다. 수많은 컴포넌트가 나를 기다린다는 사실이 너무 기대되고 흥미진진하다. 번외로내가 미션을 제공해주신 미션보드가 아니라 다른 곳에서 제출해서 냈다는 사실을 미션이후에 받은 피드백을 통해서 알았다. 내가 왜 그랬나 다시 돌이켜보니까 에듀케이션 계정을 생성하고 팀 라이브러리를 지정한다는게 그대로 미션을 진행했던 것이었다. 분명 오리엔테이션으로 안내받은 사항이었는데 깜빡했었나 보다. 다음 미션부터는 제공해주신 미션보드를 통해 진행해야겠다. 

UX/UI피그마피그마토큰피그마배리어블figma디자인

BoBae Kim

[인프런 워밍업 클럽 1기] 1주차 발자국 👣

강의 요약 📝섹션1. 피그마 배리어블과 디자인 토큰피그마 배리어블과 디자인 토큰의 개념을 이해하고 필요성에 대해 배우는 시간이었다. 디자인 토큰 개념은 이해하고있었는데 디자인 토큰의 특징 중에 참조 기능이 있다는 것은 처음 알았다.  섹션2. 배리어블과 파운데이션 세팅하기색상 배리어블 구조를 이해하고 이름 규칙을 정해서 색상 배리어블을 직접 설정해보았다. 또 타이포그래피, 아이콘, 그림자, 그리드 기준점까지 디자인할 때 기본이 되는 부분들을 하나씩 차근차근 만들었다. 실무 프로젝트에서도 매번 시안 만들기에 바빠서 스타일 가이드를 제대로 작업하지않은 경우도 있었는데 이번 강의를 들으면서 아무리 바쁘더라도 기본을 잘 다져둬야 추후에 디자인의 일관성을 유지하면서 확장성있게 사용할 수 있다는 점을 확실하게 배웠다.  - 스타일 가이드 제작할 때 유용한 플러그인Apply variables : 적용하지않았거나 누락된 스타일의 베리어블을 찾아서 바꿔줌Typescales : 타이포그래피 스타일을 사이즈별로 생성해줌Styler : 설정한 스타일을 local style에 자동으로 등록해줌 Batch styler : 스타일을 수정하고 싶은 컴포넌트를 선택해서 변경 가능함Typorahy style guide : 타이포그래피 스타일 가이드 문서를 제작해줌 Frame all : 컴포넌트 각각의 프레임을 만들어줌- 유용한 단축키 정리control+shift+enter : 베리어블 추가control+ r : 선택된 레이어 이름 수정부모의 컴포넌트를 클릭하고 enter를 누르면 자식 컴포넌트만 선택됨  회고 ✨😆 Liked (좋았던 점) : 강의를 듣고 직접 만들어보면서 배리어블 개념, 용어, 피그마 단축키 등을 한번 더 정리해 볼 수 있는 시간을 가질 수 있어서 좋았다. 그리고 이번주에 진행되었던 특강 내용도 너무 좋았다!! 😅 Lacked (아쉬웠던 점, 부족한 점) : 스터디 첫 주였는데 계획했던것처럼 매일매일 강의를 듣지못했다.. 🧐 Learned (배운 점) : 이번주는 배리어블을 활용해서 스타일 가이드를 만드는 방법을 배웠다! 그동안 배리어블 개념에 대해서 대략적으로만 알고있어서 실무에서 활용하는게 쉽지않았는데 배리어블을 참조해서 새로운 배리어블을 만들고 활용하는 방법과 이름 정하는 규칙에 대한 구체적인 예시를 알려주셔서 실무에서 유용하게 적용해볼 수 있을 것 같다! 🤩 Longed for (앞으로 바라는 것) : 다음주 부터는 조금씩이라도 매일 공부하고 계획한대로 미션을 수행할 수 있도록 노력해보자!  

UX/UI워밍업클럽디자인

귤귤

[인프런 워밍업 스터디 클럽 1기 디자인] 1주차 발자국

배운 것Day 2 피그마 베리어블과 디자인 토큰/디자인 시스템 개념 이해하기디자인 토큰 정의모든 UI 요소의 기본 구성요소진실의 근원(Source of truth)작고 반복 가능한 디자인 결정디자인 토큰의 특징참조 기능: 서로 다른 단계의 색상이 서로 참조할 수 있고 이는 시스템을 더 확장 가능디자인 시스템이란?재사용 할 수 있는 컴포넌트, 패턴, 그리고 가이드의 집합체베리어블, 스타일 활용 예시다양한 모드에서 달라지는 재사용 가능한 색상을 사용하고 싶다면 베리어블그라디언트, 혼합 모드, 다수의 디자인 요소를 결합하여 사용해야 할 경우에는 스타일디자인 토큰(피그마 베리어블)의 계층 구조원시값: 본래의 값글로벌: 사용 맥락에 상관없는 기본 디자인 언어별칭: 특정 사용 맥락을 전달할 때 쓰이는 값컴포넌트: 컴포넌트와 관련한 모든 디자인 속성을 가진 값 Day 3 색상 스타일 등록 및 베리어블 등록하기로컬 베리어블 내 색상 컬랙션(Collection) 살펴보기기본(Primitive): 디자인 언어의 기본값을 나타내는 컬랙션으로, 색의 원시값(Raw value)을 포함테마(Theme): 멀티 브랜드를 적용할 시맨틱 색상을 담은 컬랙션시맨틱(Semantic): 라이트/다크 모드를 적용할 시맨틱 색상을 담은 컬랙션Day 4 간격 베리어블, 타이포그래피, 아이콘 등록하기간격 베리어블 기본 단위(Base Unit) 정하기4, 8배수 사용의 이유 중 하나는 홀수의 경우 1.5배수에서 깨지는 현상이 발생하기 때문아이콘 만드는 전체 순서선으로 아이콘 만들기선을 면으로 바꾸기면을 Flatten으로 펴기Day 5 그림자 효과, 반응형 기준점, 기타 베리어블 등록하기피그마에서 사용하는 그리드 용어 정리칼럼(Column): 수직으로 정렬된 열의 집합거터(Gutter): 칼럼 사이의 간격마진(Margin): 요소의 외부 여백그리드 종류 살펴보기고정 그리드(Fixed Grid): 요소들의 크기, 위치가 고정가변 그리드(Fluid Grid): 화면 크기에 따라 요소들의 크기, 위치가 유동적으로 조정하이브리드 그리드(Hybrid Grid): 고정 그리드와 가변 그리드의 특징을 결합회고칭찬할 점: 매일 미션 제출을 하는데 성공했다!아쉬웠던 점 + 보완하고 싶은 점: 한번 강의를 수강해서는 모든 내용을 파악하기 어려울 것이라는 생각이 들었다. 어려운 부분을 중심으로 반복적으로 강의 들어보고 이해하고 내 것으로 만드는 과정이 필요할 것 같다.미션Day 6 스타일 파운데이션 최종적으로 다듬어서 일관되게 문서화해보기볼드 쌤의 파운데이션 파일을 참고해서 미션 보드를 만들어 보았다. 생각보다 플러그인으로 자동화해서 문서화 가능한 부분이 많아서 나름대로 수월하게 진행할 수 있었던 것 같다. 코멘트로 남겨 주신 "시맨틱, Theme 색상 베리어블이 어떻게 alising이 되었는지" 내용에 대한 부분도 고민해서 추가해 보자!

UX/UI

이주영

[인프런 워밍업 스터디 클럽 1기 디자인] 1주차 발자국

  4L 회고Like (좋았던 점): 피그마를 독학할 때 유튜브에 짧게 널려 있는 영상을 보고 하나하나 적용하느라 힘든 부분이 꽤 많았는데 정말 작은 부분(컬러)부터 차근차근 배우니까 많이 도움이 된 것 같았다.Learned (배운 점): 배리어블 자체를 처음 써보았고 컬러 차트를 내가 만들 수 있는지도 처음 알았다. 그리고 이름 짓는 규칙(?)이나 간격 척도의 종류와, 아이콘 유니온도 처음... 😿 2챕터 후반부나 3챕터 초반은 나름 알던 것이라 괜찮았지만 앞 개념들을 따라가면서는 정말 많이 배웠다 (하나도 몰라서 ㅜ.ㅜ)Lacked (부족한 점): 일단 4학년이라 수업을 많이 듣는 것은 아니지만 졸작을 병행하느라 강의가 많이 밀렸다. 어느 정도 진행된 졸작에서 큰 이슈가 터져서 주제를 갈아 엎어야 했다. 그래서 강의 공부할 시간이 갑자기 증발했었고.. 또한 강의 내용을 나의 개인 노션에 적으면서 진행되었는데 이렇게 들으니까 시간이 다섯 배는 더 걸린 것 같았다. 볼드 강사님께서 따로 정리해 주신 노션을 적극 활용해서 실습과 발자국 작성에 시간을 쓰는 것이 맞는 것 같다.Longed for (바란 점): 첫 주차라 시간 분배를 1도 못하고 정말 엉망진창에 내가 이거 다 끝낼 수 있을까? 싶었지만 꼭 완주할 수 있도록 틈이 날 때마다 부담없이 공부해야겠다는 생각이 들었다 파이팅😂 앞으로는 꼭 주어진 일정대로 강의를 듣자... 🙉 강의 필기한 것 중에 중요한 / 여태 몰랐던 것들만 발췌했다!  배리어블디자인 토큰이나 프로토타이핑 툴의 기능을 함디자인 토큰이란?“모든 UI 요소의 기본 구성요소”로써 근원의 역할을 하는 작고 반복 가능한 디자인 결정전자 - 원자 (버튼, 라벨, 필드 등) - 분자 (앞의 것들을 결합한 것) - 유기체 - 템플릿 - 페이지 - UI디자인 토큰 : 전자에 해당색상, 폰트, 테두리, 그림자 효과 등 ⇒ 디자인 세팅 !! 배리어블 이름 구조← 의미, 논리, 모듈화, 일관성 (헷갈린닥,,ㅜㅜ)Namespace : 시스템 구분System 접두어, 모든 토큰 앞에 붙음Object(특정) Component : 컴포넌트 적용하고 싶을 때 중간Base : 디자인의 구성 요소 나타냄Category - Property(각 카테고리 내 세분화) : 기본적인 디자인 구성 요소Modifier : 그것의 변형 값을 보여줌Vraint(시각적 위계질서 primary-secondory-tertiary), State(인터랙션 상태), Scale(숫자나 사이즈, 강도 등) : 하나의 디자인 요소를 여러 상태에 따라 변형예시) 근데 카테고리 옆에 무조건 프로퍼티가 나오는 건 아닌..           styles to variable 플러그인styles to variable 플러그인styles에서 가져오는 방법primitive에는 배리어블에 무조건 기본 값이 들어가야 함 = row한 헥사 코드theme 컬러 : 브랜드semantic 컬러 안에 text / bg / icon / border별로 만들어 주기.. 그 안에 또.. 핵심 .. semantic 컬러 내부 분류 잘 하기 여러 상황 - 역할에 따라,,variable에서 scope 조절 설정 하면 해당 스코프에서만 색깔 보임컬러 스타일을 킵 하고 싶으면 상위 폴더를 만들고 앞에 .(점) 붙이기 ⇒ 나중에 퍼블리싱 할 때 안 빠져나감 (안 쓸 거면 그냥 지우기!!)나중에 아이콘 Union에 관해 더 자세히 배울 것⇒ 이렇게 컬러를 짜게 되면 수치와 컬러 이름 같은 raw 컬러를 보여주는 것이 아니라 시맨틱한, 의미있는 이름을 보여주기 때문에 컬러 속성을 넣을 때 쉽고 일관적임다시 automatic style guides 플러그인을 써서 새로운 페이지 만들기   

UX/UI피그마인프런워밍업클럽

꾸이

[인프런 워밍업 스터디 1기 디자인] 1주차 발자국

직장과 사이드 프로젝트를 병행하던 중 디자인 시스템에 대한 심화적인 공부의 필요성을 느꼈다. 사수 없는 디자이너라 스스로 배우고 성장해야만 했는데, 해외 아티클, 유튜브 등을 열심히 찾아봤지만 "어디서부터 어디까지 실무에서 적용시켜야 할지 모르겠다"는 문제 때문에 어려움을 겪었다. 그러던중 인프런 워밍업 클럽 - 스터디 1기의 존재를 알게됐고, 좋은 기회로 보여 신청했다. 📖 강의 요약0. OT첫 프로그램은 OT였다. 줌으로 화상회의를 진행하는 동시에 피그잼에서 강사님과 의사소통했다. 덕분에 집중이 잘됐다. 스터디는 다같이 으쌰으쌰하는 분위기가 중요한데, 참여자 모두가 쉽게 사용할 수 있고 귀여운 의사소통이 가능한 툴이라 그랬던 것 같다.평일 저녁에 짬을 내서 참여할 가치가 있었다. 기존에 존재하는 강의를 바탕으로 스터디로 진행하다 보니 안내사항이 많았는데, OT에서 설명을 잘해주셔서 따라가면서 잘 이해할 수 있었다. 특히 피그잼에서 "내가 왜 이 스터디에 참여했는지" "무엇을 얻고 싶은지" 등을 스스로 생각하고 써나가는 시간이 있었는데 이 시간이 정말 좋았다. 다른 사람들이 어떤 각오로 참여하게 됐는지를 보면서 동감하고 신기해하기도 하면서 "다같이 30일동안 열심히 공부할 사람들이 여기 있구나!"라는걸 새삼 느끼며 설레는 마음으로 스터디를 시작했다. 1. 디자인 시스템과 디자인 토큰강의는 베리어블이 먼저지만, 정리 과정에서 순서를 수정했습니다초반 강의에서는 디자인 시스템과 디자인 토큰 등 강의에서 다루는 개념들을 먼저 정리하는 시간을 가졌다. 아는 내용과 모르는 내용이 섞여있었는데, 전자는 내가 이미 아는 개념들을 강사님 입장에서 설명해주시는 것을 들으면서 "아, 저렇게 설명할 수도 있는 부분이구나!"고 생각하며 복습했고, 모르는 부분은 아는 부분보다 열심히 메모하고, 따로 표시해두었다. 1) 디자인 시스템디자인 시스템은 일관성과 확장성을 가진 재사용 가능한 컴포넌트와 패턴, 가이드를 말한다.디자인 시스템의 구성 요소는 다음과 같다.디자인 원칙/철학 Design Principle스타일 가이드 Style Guide컴포넌트 라이브러리 Component Library패턴 라이브러리 Pattern Library문서화 Documentation시스템 관리 운영 System Governance이 중에서 내가 주로 사용했던 것은 스타일 가이드, 컴포넌트 라이브러리뿐이었어서 다른 부분들을 어떻게 실무에 적용할 수 있을지 고민했다. 디자인 시스템의 장점은 다음과 같다.디자인 일관성 유지브랜드 강화효율적인 개발시간 단축팀 간 협업 강화빠른 온보딩유지 보수 용이높은 품질의 경험 디자인시스템을 시작할 때는 다음 사항들을 주의해야 한다.비즈니스, 디자인, 개발의 이해에서부터 시작디자이너 혼자서 만드는 게 아니라 회사의 여러 구성원이 함께 만드는 것작은 단계에서부터 성공해나가야 함디자인시스템은 보통 '효율'을 위해 만드는 시스템이지만 제대로 만들려면 시간과 비용이 많이 든다. 따라서 초반에 어디까지 만들지 제대로 설정하는 게 중요하다. 그리고 사이드프로젝트를 할 때도 느꼈지만 만들다보면 또 수정할 일이 생기고, 여기서 막히고 저기서 충돌하기 때문에.. 작은 성취들을 소중히 여기는 태도가 꼭 필요하다. 2) 디자인 토큰디자인 토큰은 모든 UI 요소의 기본 구성 요소로 작고 반복할 수 있는 디자인 결정이다. 브래드 프로스트의 아토믹 디자인 개념에서는 '전자'단계에 속한다.전자 -> 원자 -> 분자 -> 유기체 -> 템플릿 -> 페이지 토큰과 관련된 브래드 프로스트의 새로운 아티클도 첨부한다. 다음에 시간될 때 차근차근 읽어보면 개념 이해에 더 도움이 될 듯 하다. 그렇다면 디자인 토큰은 왜 필요할까? 바로 확장이 쉽고 관리가 유연하다는 이유 때문이다.❓ 여기서 "json으로 내보내기 가능해서 여러가지 플랫폼으로 이동 가능하다"고 강사님이 말하셨는데 이유가 궁금해서 찾아봤다.json은 JavaScript Object Notation의 약어로, 데이터를 표현하는 데 사용되는 형식이다. 현재 데이터 교환의 범용 표준이며 프론트엔드와 서비스 측 개발, 시스템, 미들웨어, 데이터베이스를 포함해 프로그래밍의 모든 영역에 사용된다. (출처: 거의 모든 SW 개발의 필수⋯JSON 데이터 포맷의 이해 - ITWorld Korea)디자인 토큰 형식 모듈/4.파일 형식에 따르면 json이 채택된 이유는 다음과 같다.1. 많은 프로그래밍 언어의 표준 라이브러리에서 광범위하게 지원된다. 이것은 개발자의 진입 장벽을 낮출 것으로 예상된다. 2. 현재 인기있으며 광범위하게 사용되는 언어다. 많은 사람들이 익숙하기 때문에 학습 곡선을 낮출 것으로 예상된다.3. 이진법이 아닌 텍스트 기반이어서 기본 텍스트 편집기 이외 특수 소프트웨어 없이 디자인 토큰 파일을 편집할 수 있다. 3) 베리어블의 이름과 구조혼자 공부할 때 가장 어려웠던 부분인데 설명을 너무 잘해주셔서 열심히 들었다. 모든 스터디가 끝난 뒤 가장 먼저 복습하게 될 챕터가 아닐까 싶다. 베리어블의 구조는 다음과 같다.이름(Name), 값(Value), 유형(Type)설명(Description)그룹 베리어블의 계층은 다음과 같다. 기업마다 정의하는 용어가 다를 수 있지만 신경쓰지 말고, 계층마다 기업들이 어떤 목적을 가지고 역할을 분류했는지에 초점을 맞춰야 한다.Raw value: 본래의 값 #D6840BGlobal/primitive/core/base/foundation/root: 사용 맥락에 상관없이 디자인 언어의 기본 값 Orange-mediumAlias/semantic/applied/purpose: 특정 사용 맥락과 의도를 전달할 때 쓰이는 값 Brand-primaryComponent/overwrites/scoped: 컴포넌트와 관련된 모든 디자인 속성을 가진 값 Button-primary-background-color❓ raw value와 primitive는 뜻이 똑같은데 왜 다른 분류 용어로 사용하는지 궁금했다. 베리어블 이름의 구조는 Namespace + Object + Base + Modifier로 이루어져있다.Namespace>System은 다른 디자인 시스템과 구분하기 위한 접두어로, 주로 모든 베리어블/토큰 앞에 위치한다.Object>Component는 디자인 시스템 내에서 특정 컴포넌트의 스타일 및 레이아웃을 적용하고 싶을 때 사용된다.Base는 Category와 Property로 구성되는데, Category는 UI 기본 구성 요소를 공통된 유형으로 그룹화하며 Property는 각 카테고리 내에서 특성에 따라 세분화된 것들이다.Modifier는 하나의 디자인 요소를 여러 상황, 상태에 따라 변형할 수 있도록 한다. Variant와 State로 구성되는데, Variant는 시각적 위계질서와 기능을 표현한다. State는 인터랙션 상태와 크기를 표현한다. ❓ 토큰 앞에 $(달러) 기호를 붙이는 것도 json 기반이라 그런건지 궁금했다. 찾아본 결과는 다음과 같았다.디자인 토큰 형식 모듈에 따르면, 토큰 이름과의 충돌을 방지하기 위해 토큰 속성은 달러 기호($)로 접두사를 붙인다. 이 접두사를 사용하면 예약어 목록이 필요 없고 사양을 미래에 대비하는 데 도움이 된다.덧붙여 다른 변수명에서 잘 사용하지 않는 기호를 사용하여 다른 변수와의 충돌을 줄이기 위해 $를 사용한다는 내용은 이 블로그에 잘 설명되어 있다. 베리어블 구조, 이름을 지을 때 몇 가지 실무 팁도 알려주셨다.개발자와 디자이너 둘 사이의 공통된 이름 짓기미리 80% 정도는 계획을 하도록 한다 (엑셀 시트, 피그잼 추천)2~3개 정도의 레퍼런스에서부터 시작하기사이드프로젝트에서 파운데이션을 제작하던 중 어떻게 보면 벼락치기 개념으로 들은 강의였어서 조금만 더 빨리 들었다면 같이 엑셀로 계획하고 할 수 있었을텐데! 라고 후회했다 😇... 정말.. 정말 중요한 팁을 주셨다. 디자인시스템 관련한 레퍼런스는 사실 너무♾ 많고, 그중에서도 개발하려는 서비스의 특성/규모 등에 맞춰서 조절해야 하니 욕심부리지 말고 적당한 선에서 참고하며 시작해야 한다 ... 2. 스타일 파운데이션 설정색상 Color사이드프로젝트를 할 때 가장 많이 헤맸던 부분인데, 여러가지 레퍼런스를 참고해서 정리해주신 파일을 기반으로 만들어야 할 베리어블을 정리한 뒤 제작하니 시간도 절약하고 이후 개발자가 이해하기도 좋을 것 같았다. 고려사항은 다음과 같다.Color Scopingsematicbg: FrameIcon: Shapetext: Textborder: Stroke특정 베리어블을 publishing하고 싶지 않다면 베리어블 콜렉션/그룹 앞에 _ 작성개별 베리어블 edit color variable -> Hide from publishing 설정이런게 진짜 꿀팁이지 싶었던 부분. 이외에도 강사님이 제공해주시는 피그마 파일을 통해 컴포넌트 정리할 때의 팁을 알아볼 수 있는데, 공부에 많은 도움이 된다. 간격 Spacing, 둥근 모서리 Border Radius기본 단위(Base unit)은 1.5배수 랜더링 이슈로 주로 8pt 그리드를 사용하며, 일반적으로 더 작은 단위로 레이아웃을 정렬하고 싶은 경우 4pt 그리드를 사용한다. 간격 크기(Spacing Scale)도 마찬가지.간격의 사용(Spacing in UI)은 작은 UI 구성 요소 / 카드 UI 패딩, 간격 / 큰 규모의 UI, 레이아웃 등 간격이 사용되는 케이스에 따라 적용하는 간격의 범위를 말한다.❗ 아틀라시안 디자인 시스템에서는 small, medium, large로 나누어서 적용하고 있었다. (아래 사진)간격 베리어블은 다음과 같이 구성할 수 있다.ComponentSemantic : Padding Gap Border Radius Width/Height Border WidthPrimitive : UnitBase Grid Point : 4❗ 시맨틱을 적용한 사례가 궁금해서 찾아봤다. Polaris는 --p-space-card-padding, --p-space-table-cell-padding 같은 식으로 몇몇 컴포넌트의 Padding과 Width, Height까지 정의한다. 둥근 모서리 베리어블은 다음과 같이 구성할 수 있다.Primitive: UnitSemantic: Border Radius 타이포그래피 Typography타이포그래피는 강의 녹화 당시에 베리어블이 없었어서 스타일로 제작하셨으며(추후 추가 예정이시며, 나는 특강으로 들을 수 있다!), 스타일을 쉽게 제작할 수 있는 플러그인을 많이 알려주셔서 도움이 됐다. 아이콘 IconFeather Icons을 불러와서 등록하는 법을 배웠다. 기존에 있는 아이콘을 불러오는 과정에서 생길 수 있는 문제를 유용한 단축키를 소개하면서 해결해주셨다.fn shift enter : 바깥에 있는 프레임 선택 -> 크기 조절enter : child frame 선택ctrl shift g : frame 해제5월 4일에 진행한 특강에서 심화 수업을 들었는데, 이 부분은 정리가 더 필요해서 다음주 발자국으로 넘긴다. 높이 Elevation❗ Material Design 3에 의하면 높이는 z축에 있는 두 표면 사이의 거리다.높이와 그림자는 UI 요소간의 계층구조를 시각적으로 명확하게 하고, 요소들간의 상대적인 거리와 깊이를 나타내 현실감있는 경험을 제공하며, 상호작용을 시각적 피드백으로 표현해 사용자 경험을 향상시킨다. 높낮이의 표현방법은 3가지가 있다. (이미지 출처: Material Design 3)다른 톤으로 표현하기같은 톤인 경우 그림자 효과 주기스크림*을 사이로 구분하기*스크림: 모달 뒷배경에 주로 사용되는 그것을 말한다. Material Design 2에서는 다음과 같이 설명한다. 스크림은 표면의 콘텐츠를 덜 눈에 띄게 만들기 위해 머티리얼 표면에 적용할 수 있는 임시 처리이다. 이는 스크림을 받는 표면에서 벗어나 화면의 다른 부분으로 사용자의 주의를 유도하는 데 도움이 된다. 그리드 Grid, 기준점 Breakpoints그리드 시스템은 시각적 질서, 일관된 레이아웃, 유연함과 확장성, 디자인 효율성을 제공해준다. 반응형 그리드의 기본 용어는 다음과 같다.칼럼(Columns): 섹션거터(Gutters): 칼럼 간의 간격마진(Margins): 그리드 양상단의 여백 Fixed, Fluid, Hybrid 그리드 정의는 다음과 같다.고정형, 유동적 그리드 : 크기 확대됐을 때 고정/유동하이브리드: 다양한 그리드가 한 스크린 안에 있음 그리드는 개념적으로는 이해가 된 상태였는데 피그마에서 오토레이아웃을 적용할 때 헷갈리는 부분들이 있었다. 그런 점들을 잘 짚고 넘어갈 수 있었다. 테두리 간격 Border Width, 투명도 Opacity배리어블을 만든 후 넘버 스코핑에 신경쓰면 되는 부분들이다.  🎯 미션미션 1, 2, 3이번주의 미션은 다음과 같았다.미션1. 컬러 베리어블을 로컬베리어블에 등록하고 다른 디자이너, 개발자 누구나 볼 수 있도록 문서화한다.미션2. 타이포 그래피 스타일, 간격 베리어블을 등록하고 Feather icon을 등록한 후 면으로 모두 바꾼다.미션3. 그림자 효과, 반응형 기준점, 기타 베리어블 등록하기미션4. 스타일 파운데이션 최종적으로 다듬어서 일관되게 문서화해보기그중 미션 1, 2, 3은 시간이 조금 걸리긴 했지만 강의를 따라가면 충분히 해결할 수 있는 과제들이었다. 미션 4미션4는 현재 사이드프로젝트나 회사 업무에 적용한다고 생각했을 때, 어떻게 해야 개발자들이 잘 이해할 수 있을까? 불필요한 커뮤니케이션을 줄일 수 있도록 문서화하고 싶다! 는 생각을 가지고 작업했다. 작업과정은 다음과 같다.참고할 디자인 시스템 정하기: 볼드님의 파운데이션, Wanted Design Library, Polaris Styles 를 참고했다.베리어블 -> 문서화 플러그인 찾기 잘 만들어진 플러그인들이 많았지만 1. 컴포넌트 형식이고 2. 컴포넌트 내부 요소들이 잘 구성되어 있고 3. 오류가 없거나 적은 것을 찾기가 힘들었다.플러그인을 찾은 것들은 컴포넌트를 정리해서 묶었다.플러그인을 찾지 못한 것들은 타 디자인시스템들을 참조해서 새로 제작하거나, 기존에 강의를 따라가면서 제작했던 문서를 가지고와서 정리했다.이후 문서를 통일하고 정리했다. 이 과정에서 볼드님의 파운데이션이 큰 도움이 됐다. 🌼 회고잘 한 점: 직장과 사이드 프로젝트를 병행하면서 1주차를 무사히 끝냈다!아쉬운 점: 미션에 집중하다보니 발자국 작성에 시간을 많이 쓰지 못한 점이 아쉽다.보완할 점실전에서 어떻게 활용할 수 있을지 생각하며 강의 듣기매일매일 강의 들은 뒤 강의 메모 이외 간단한 느낀점 꾸준히 작성하여 이후 발자국 모으기 쉽게 만들기다음주 계획: 이번주만큼만 하기! 💨

UX/UI워밍업클럽피그마

한국 IT 용어 이야기 (7) - "매니저"

이번 글에서는 너무나 두리뭉실하게 쓰이고 있는 각종 매니저에 대해 이야기해 보려 한다. 일단 오랜 기억부터한국에서 매니저와 미국에서 매니저내 기억의 가장 오래된 매니저는 나무위키의 순서와 일치한다. 연예인 혹은 운동 선수의 일들을 도와 주는.. 연예인 쪽에서 유병재, 정준하 씨, 그리고 영화에서의 제리 맥과이어 등. 코미디의 소재로 접하기 시작해서 잘못된 선입견을 가지게 되었고 은연중에 '하대'를 기본으로 생각하는 직군으로 생각하고 있었다.(미국에서) 취직을 하니 나에게 매니저가 생겼고, 나도 매니저가 되면서 교육을 받았는데, 이는 한편으로 많이 달랐더랬다. 이른바 '생사여탈권'을 쥐고 있고, 그 사유가 'performance'일 경우 외국인 노동자인 나에게 추방까지 영향을 줄 수 있는 사람이 매니저라는 것이었고, 한국에서 알고 있던 경험과 정반대의 컨셉이었기에 꽤 충격이 컸었다. 그래도 한동안 직급/직책에 explict 하게 manager 라고 주어지지는 않았고, manager/reportee 의 상하관계가 맺어졌었고, 직군에 나타나는 매니저(들)은 또 다른 이야기라 하겠다.직군으로서 다양한 매니저들구글 내에서 다양한 직군으로서 매니저들을 만났다. 가장 가까이에서부터 만났던 것부터는Engineering ManagerProduct Manager / Associate Product ManagerTechnical Program ManagerAccount Manager / Technical Account ManagerGeneral Manager생각해 보니 밖에서도 property manager, facility manager, restaurant manager 등의 직함들을 만날 수 있었던 거 같다.그리고 한국에 와서 알게 된 project manager, CX manager 같은 더 많은 매니저들. 모 회사는 직급 파괴의 수단으로 모두에게 매니저를 붙여 주기도 한다고 들었고, 무의식적으로 받아 들일 때는 쉬웠는데, 촘촘히 생각해 보면 일이 커진다 싶다. (개인적인) 깨달음과 정리들매니저가 뭘 하는 사람인가에 대한 질문에 원래대로 한 발 돌아가서 개인적으로는 아래와 같은 잠정적인 정리이다.직함과 상관 없이 manager/reportee 의 관계의 경우- reportee 들을 이용해서 팀 전체의 성과를 높이고- reportee 들의 행복을 바라면서 자랑도 대신 해 주고- 평가 시기를 제외하고는 동원할 수 있는 최대한으로 일을 잘 할 수 있게 하고- 그래서 팀의 운영의 credit 을 manager가 가지고 가고- 평가 시기에 가장 바쁘고 힘이 있도록...직함에 있는 'manager'는- manager를 제외한 나머지가 어떻게된 "잘" 되게 하는 게 역할-- product manager 는 product 이 잘 되어야 하고-- account manager 는 account 가 더 흥해야 하고... 등...- 고충 처리반의 느낌에 가깝고, 대상의 행복, 성과 or feedback 이 주요 평가 지표- '하대'까지는 아니라도 갑을 관계가 있다면 '을'에 가까움.- engineering manager 의 경우 engineer 들의 고충을 이해하고 처리해 주는 게 주 업무... --a회사에서 상하관계를 맺어 주는 것에 대한 업권 전체에 대한 여러 고민들이 섞이기에 쉬운 문제는 아니라 하겠고, 직함이 세분화되는 것 자체도 주는 질서가 있기에 나의 정리는 하나의 의견으로 각자의 고민이 있다면 조금 정리하는 용도로 쓰이면 한다.직군으로서는 아래의 것들이 가장 헷갈린다... Product manager vs Program manager vs Project manager ( vs Product owner ) 아주 작은 startup 의 경우 혹은 직군 파괴의 회사의 경우는 어떻게 해야 할까... 이 책이 가이드라인은 줄 수 있지 싶다..ps. 한국 IT 용어 이야기 연재(?)는 (8) '팀'으로 일단 마무리하려 합니다. 읽어 주셔서 감사합니다...

교양한글용어영어

김혅

[인프런 워밍업 스터디 1기 디자인] 1주차 발자국 🐾

OT부터 1주 차 스터디, 그리고 첫 온라인 중간 점검까지 마치고 남기는 첫 발자국!역시 나는 강제성(?)같은 동기가 부여되어야 하는 사람임을 다시 느꼈다. 🙄>짜여진 커리큘럼과 그에 맞는 미션이 설계되어 있어서 따라가기 너무 좋았고,강사님께서 노션과 강의 요약본까지 정리해두셔서 더 편리하게 할 수 있었다. 쵝오...👍강의는 무작정 "자, 일단 따라 해봅시다!"가 아닌 기초 개념부터 쌓아 올려가는 방식이라 너무 좋았고, 설명에 맞는시각적 예시까지 곁들여주셔서 따라가기 너무 좋았다. 유용한 사이트와 플러그인 정보도 유익한 건 덤~(WOW)~아직 아날로그 인간이라 강의를 손으로 필기하는데, 그중 몇 개를 아래에 간단하게 적어 회고를 해보고자 한다!Chapter 1.피그마 배리어블과 디자인 토큰디자인 시스템을 만들어야 하는 이유 ✧ 커뮤니케이션(공감대 형성)스타일, 배리어블? ✧ 기본 디자인 토근 관리를 위해서는 배리어블 ✧ 다수의 디자인 요소의 결합은 스타일 Chapter 2.배리어블과 파운데이션 세팅하기✦ 색상 베리어블 세팅 ✧ border의 경우 너무 두꺼우면 텍스트와 잘 부딪히니 색을 빼주어 구분을 해주자.  ✧ icon은 텍스트와 주로 같이 간다.✦ 그리드 ✧ 4-point grid는 작은 단위로 레이아웃 정렬에 용이하다.  ✧ gutter/columns의 개념 헷갈리지 않기. ✧ fluid의 경우 margin 값을 필수로 넣어주어야 한다. ✧ fixed와 fluid의 constraits 각각의 차이 기억하기.✦ 기타 베리어블 ✧ ex)stroke 배리어블 버튼이 안보일때 우 클릭&apply variable or shift+왼쪽 클릭 ✧ opacity의 경우 fill이 아닌 layer에서 적용시키기. 미션✦ 놓치는 부분이 없는지, 적용이 잘 되었는지 더블의 더블 체크 해주기.✦ 생각보다 어려워서 난항을 겪었던 미션 4 ▸ 참고한 템플릿은 크게 두 가지 범정부UIUX_디자인스타일가이드n컴포넌트 / Wanted Design Library ▸ 컬러 부분이 상당히 오래 걸렸는데, 맘에 드는 플러그인을 찾기 어려웠고 요소가 많은데 그 안에서도 최대한 구분이 되어 보이기를 바라며 구성하였다. -Theme의 경우 각 변수의 수가 똑같기 때문에 가로 정렬 -Sementic의 경우 각 변수의 차이가 약간 있고 내용이 많아 세로 정렬로 진행해 주었다.마치며, 2주 차 다짐📍아직까지는 따라가기 바쁘다, 복습은 필수.📍커리큘럼대로만 잘 따라가자, 부지런해져라(제발🥺) 

UX/UI워밍업클럽1기피그마

한국 IT 용어 이야기 (1) – 고도화

미국과 한국에서 개발자와 매니져 생활을 25년 넘게 하게 되었는데, 최근에 한국의 일선에서 여러 가지 단어들을 새로이 접했는데, 그 내용들에 대해 가볍게 적어 보려 한다. 커리어의 앞의 절반은 유튜브가 없던 시절에 책을 통해 한국에서 배워 왔던 것이었고, 뒤의 절반은 미국 회사에서 배워 왔던 것이었으며, 최근 2년간 한국에서 현업에서 접했던 것들에 대한 이야기이다.---으뜸은 누가 뭐래도 "고도화"이다. 직군을 가리지 않고, 거의 모든 사람들이 언젠가부터 쓰고 있는 표현이었다. 15년 전에 전혀 쓰지 않았던 단어이기도 하고, 한국 생활로 돌아올 때 적응에 가장 어려움을 느낀 단어이다. 정부 보고서나 신문 기사들도 쓰고 있어서 나만 모르는 단어인 줄..'고도'라고 쓰지 않고 꼭 '고도화'까지 붙여서 쓰이고 있으며, ~'화' 의 한자식 표현이 개인적으로 어색해 하고 있는 정도이다. 문서나 신문 기사에도 종종 보이지만, 주로 발표할 때 혹은 계획을 잡을 때 '뭐라 구체적으로 설명하기엔 애매하지만 여하튼 개선하려고 하는 모든 계획들' 정도의 의미이고, 가끔씩 구체적으로 사안들을 적어 주면 좋을텐데 등의 아쉬움이 있는 정도이다.네이버 사전에는 '정도가 높아짐'의 뜻이지만, gemini 가 알려주기로 영어 표현으로 improve, advanced, develop, upgrade, refine, perfect, master, polish 등이 있다고 하는데, 거꾸로 저 용어들을 한글로 번역해 놓는다고 생각하면 각각의 단어를 생각해 내는 대신 이제 '고도화'가 가장 적절한 단어일 거라는 생각이 든다.Bard 의 "고도화"의 영어 번역개발을 하면서 다른 사람들이 쓴 문서들을 접하게 될 때, 특히 design document가 개선되는 제안을 담고 있는 문서들에서는 polish 라는 단어가 쓰여진 문서가 고급져 보인다는 생각을 했었다. improve는 너무 무난하고, advanced, refine 은 어색하며, upgrade는 너무 영어가 짧아 보인다는 생각을 했었을까..? 어느 순간부터 내가 쓴 문서들은 저런 추상적인 단어들 보다는 아예 직접적인 설명들을 정확하게 적으려 했던 기억들이다.---생각나는 단어들은 일단 아래와 같다. 각각 다 여러 가지 의미로 충격이 있었던 단어들이라 몇 개 적어 보려 한다.고도화 , 아래나ㄹ, 티켓 쳐내기, 역량, 성장, 엠비피, 실험, 오케알, 케피아이, 팀, TFT, 파운데이션, 스쿼드, AARRR, UT, TC, 프레임워크, 이미지 말기, 굽기, 레거시

교양용어개발자한국어

FE 과제

day2실행 주소 :: https://a-yeye.github.io/Frontend/day2/day2.htmlgithub 주소 :: https://github.com/A-YEYE/Frontend/tree/main/day2<div class="menuDiv"> <button class="button" id="all">All</button> <button class="button" id="breakfast">Breakfast</button> <button class="button" id="lunch">Lunch</button> </div>const buttonElement = document.querySelector('.button'); buttonElement.addEventListener('click', (event) => { let inputClass = event.target.id; console.log(inputClass); }); ?1. button이라는 공통된 class를 가진 요소들 중 하나를 클릭했을 때 클릭된 target의 id를 가져올 줄 알았는데 id가 all인 버튼만 작동하고 breackfast, lunch는 아무 값도 반환하지 않음.=> querySelector() 메소드는 DOM에 일치하는 항목이 없으면 null을 리턴하고, 매개변수로 지정된 CSS 선택자와 일치하는 요소가 있는 경우 첫 번째 요소만을 리턴한다고 한다. 아쉬운 점- 완벽한 반응형이 아니군.....- 공통된 class를 가지고 있으니까 활용하고 싶었는데 방법을 못 찾아서 id를 이용해서 기능을 만들었는데 다른 방법이 있을까 궁금함 제이쿼리 밖에 답이 없는 걸까?  day3실행 주소 : https://a-yeye.github.io/Frontend/day3/day3.htmlgithub 주소 : https://github.com/A-YEYE/Frontend/tree/main/day3칭찬 : 처음부터 구조 잡고 들어감.아쉬운 점 :div에 내용 넣을 때 그냥 div에 넣는 게 좋은 건지 div 안에 input 박스를 넣고 투명도를 두면서 작성하는 게 좋은 건지 모르겠으나div먼저 구조 잡고 스타일 넣은 상태에서 input box 넣고 다시 스타일 주는 게 귀찮아서 남은 횟수랑 플레이어와 컴퓨터의 승점을 input type="hidden"에 넣어두고 그 값을 불러와서 div값을 변경해주는 방법으로 짰는데 이렇게 하다보니 더 복잡하게 짠 느낌..... 2. 처음에 짜둔 구조에다가 결과가 나올 때 div의 속성에 접근해서 높이나 값을 변경해줬는데 이러지말고 새로운 div를 생성해서 display를 none, block 처리했으면 더 나았을 거 같음day4실행 주소 : https://a-yeye.github.io/Frontend/day4/day4.htmlgithub 주소 : https://github.com/A-YEYE/Frontend/tree/main/day4day5-1실행 주소 :: https://a-yeye.github.io/Frontend/day5-1/day5-1.htmlgithub 주소 :: https://github.com/A-YEYE/Frontend/tree/main/day5-1day5-2실행 주소 :: https://a-yeye.github.io/Frontend/day5-2/day5-2.htmlgithub 주소 :: https://github.com/A-YEYE/Frontend/tree/main/day5-25-2에서 너무 시간을 오래 보냄.......처음에 유저가 없다고 뜨는 이유는 화면 녹화키를 눌러서 R키를 눌렀다고 인식해서...마지막에 조회했다가 해당 유저가 없습니다는 너무 오래있다가 없어지긴 함....더 잡고 싶지만 과제가 밀려서 이건 여기까지.... day6실행 주소 :: https://a-yeye.github.io/Frontend/day6/day6.htmlgithub 주소 :: https://github.com/A-YEYE/Frontend/tree/main/day6옵저버 패턴을 배우고 클릭 이벤트가 발생할 때 사용할 수 있지 않을까 싶어서 뻘짓을 하다가 여기에선 맞지 않는 다는 걸 깨닫고 원래 짜던대로 짬....비밀번호 체크할 때 정규식을 매번 남이 만들어 놓은 거 복붙해서 만들었었는데 직접 만들려니까 엄청 헤맴..let pwRule = /^(?=.*[0-9]).{6,}$/; // 1. 정규표현식 리터럴 let pwRule = "^(?=.[0-9].{6,}/)"; // 2. let regex = new RegExp(pwRule); // 3. 정규표현식 객체 생성자 2 만들어 놓고 test함수를 돌렸는데 에러가 계속 나서 한참 헤맸는데 정규표현식 객체로 만들어 줬어야 했다과제 아니었음 계속 몰랐을 듯.. day7실행 주소 :: https://a-yeye.github.io/Frontend/day7/day7.htmlgithub 주소 :: https://github.com/A-YEYE/Frontend/tree/main/day7

학생

인프런 워밍업 클럽 스터디 0기 FE 후기

후기시작 동기대학교 졸업 후 오랜 고민 끝에 취업 직무를 FE개발로 정하고 독학을 하다가, 재미있는 것을 만드는 팀 프로젝트에 어서 참여하고 싶다는 생각을 했다. 팀 프로젝트에 참여하려면 어느정도의 실력이 있어야 하는지 알지 못해 무작정 공부만 하다 보니, 속도도 느리고 비효율적임을 느꼈다. 그리고 하고 있는게 맞는 것인지 감도 못잡고 있었다. 그렇기에 프로젝트에 참여하기 전, 제대로 커리큘럼을 갖춰 누군가 이끌어주며 사람들과 함께할 수 있는 스터디를 찾아야겠다고 생각해 여러 코딩 강의 사이트 커뮤니티를 보던 중 본 인프런 워밍업 클럽 스터디 0기 모집 공고를 보게 되었다. 3주라는 짧은 시간에 필요한 정보를 배우고 비슷한 분야의 목표를 가진 사람들과 함께 달릴 수 있다는 것은 마음이 급한 나에게는 더없이 매력적인 부분이었다. 따라서 망설임 없이 참여하게 되었다. 이것은 나의 프론트엔드 분야에서의 첫 활동이고 도전이었다. 그렇기에 최선을 다하고 싶었다.3주 돌아보기1주: OT를 하고, JavaScript의 전반적인 내용을 다루었다. 강의를 전투적으로 듣고 미션 과제를 해나갔다.2주: JavaScript를 마무리하고 중간점검 Q&A를 한 뒤 리액트의 내용으로 들어갔다. 아직 제대로 이해되지 않은 부분들이 있다는 것을 인지하고 그 부분들을 공부해나갔다.3주: 리액트를 마무리하였다. 앞의 JavaScript부분에 시간을 할당하느라 더 어려운 리액트부분을 비교적 쫓기듯이 공부한 것 같아 스스로 반성했다. 공부하며 느낀 것은 Next.js같은 프레임워크가 있어서 상당히 간편하다는 점이었다.스터디 완주조건은 행사참여(OT, 중간점검), 발자국 1주에 1개(총3개이상), 자바스크립트 과제 7개중 3개, 리액트 과제 7개중 4개였다. 나는 자바스크립트 과제는 첫 주에 대부분 하였지만 리액트 과제 조건 달성을 실패할 뻔 했다. 명확하게 이해가 되지 않은 부분들도 있었으며 노트북까지 잘 따라와주지 않는 등(굉장한 렉이 걸렸다.)의 고통을 맛보았다. 하지만 다행히 과제 제출 기한을 늘려주셔서 숨이 트였고, 비록 처음의 목표였던 '모든 과제를 다 하기'는 실패하였으나 적어도 완주만은 성공하자는 의지로 조건을 달성하였다. 아쉬움이 남지만, 이번 경험을 토대로 하나로 질질 끌지 말고 해야 할 일 먼저 하는 습관을 들이기로 했다.오프라인 수료식오프라인 수료식은 판교역 근처의 건물에서 진행되었다. 처음에 건물을 착각해 아예 반대쪽의 건물을 돌아다니다가 다시 뛰어오느라 조금 지각을 하였지만 다행히 크게 놓친 부분은 없었다. 생각보다 사람들이 정말 많이 있어서 놀랐고 대부분 백엔드 분들이었다. 프론트엔드 분들은 나를 포함해서 4명이었다. 코치님도 함께 계셨는데, 영상으로만 보던 분과 한 테이블에서 식사를 하며 대화를 하는 것이 신기하였고, 테이블의 모든 분들이 반갑게 느껴졌다. 모두 친절하셨고 열심히 하시는 것이 느껴졌다. 대화를 더 나누지 못한 것이 아쉽지만 동종업계이므로 언젠가 또 뵙게 될 수 있지 않을까 생각한다.수료식은 OT, 식사타임(피자를 먹으며 대화), 코치님들의 Q&A, 우수러너 시상, 네트워킹 타임으로 구성되었다. 나는 함께 식사를 한 프론트엔드 몇 분들과 함께 우수러너로 선택되어 상품을 받았다. (오프라인으로 받은 인프런 굿즈. 그밖의 혜택은 인프콘 초대권, 1:1멘토링권 등이 있다) 인프런 굿즈의 구성품은 에코백, 컵, 뱃지, 우산이다. 전부 좋지만 특히나 작고 하찮은 뱃지가 마음에 든다. 누가 봐도 개발을 잘 할 것 같은 외모의 네모 친구다. 우수러너가 되도록 열심히 한 것이 뿌듯했으며, 우수러너로 선정해주시고, 상품 및 혜택을 주신 분들에게 감사함을 느꼈다. 네트워킹 타임에는 프론트엔드 분들 및 백엔드 분들과 여러 이야기를 나누었다. 대부분 프론트엔드 인프런 현직자 분과의 Q&A형식 비슷하게 되었고, 이것저것 질문하여 유익한 시간이 되었다. 판교에 와보고싶었는데 이번 기회에 구경하게 되어 좋았고, 이번 스터디는 꽤나 만족스러운 경험이 되었다.지금까지 열심히 지도해주시고 유익한 시간 보낼 수 있게 해주셔서 감사합니다!

Groot

[워밍업 클럽 0기 - 백엔드] 참여 후기

"인프런 워밍업 클럽 0기 - 백엔드" 참가 후기입니다.참가한 계기참가하게 된 계기는 기본기를 기르고자하는 마음 60%, 호기심 40%? 때문입니다.백엔드 프로그래머를 지망하는 만큼 자바로 실무를 하게 될 가능성이 높은데 이때까지는 이상하게 FastAPI, NestJS, ASP.NET과 같은 프레임워크를 많이 사용했었습니다.그러면서도 자바는 상당히 익숙했습니다.학교 수업을 들으며 자바로는 오히려 Client 프로그래밍을 훨씬 많이 한 것 같습니다. 학우들은 자바를 다 알아서 눈에 보이는 작업물을 보여주기에는 자바 Swing만한 것이 없었던 것 같습니다...아무튼 학교를 빠져나와서 백엔드 지망하는 분들이랑 얘기나 스터디를 하다보면 항상 예제로 나오는 것이 스프링이었습니다. DI, 컨테이너와 같은 컨셉도 소개될 때마다 예시로 등장하는 것이 스프링이고 스터디를 하다가도 다른 분이 예시로 보여주는 것도 스프링일만큼 매일 등장해서 아.. 계층 나누고 주입해주는 것은 비슷한데 자바가 훨씬 자료가 많고 추상화가 더 잘되어있구나 싶었습니다. 안 해봐서 잘은 모르지만 무엇보다 완성도가 높은 느낌이 들었습니다... 몇 년 전에 Node 진영에 ORM을 공부할 때는 자료가 너무 없어서 JPA 코드를 보면서 공부했기도 했습니다.프로젝트 끝날 때마다 Spring Boot는 해보려고 마음 먹고는 했는데 이번 기회에 입문했습니다. 기본적인 개념도 익히고 적절하게 매일 1시간 정도 과제를 고민하고 해결하며 직접 코드를 짜볼 수 있어서 좋았습니다. 다른 스터디 참여자분의 과제 코드도 볼 수 있어서 공부가 많이 된 것 같습니다.다른 프레임워크에서 넘어온만큼 보이는 것도, 예전에 제가 실수한 것도 떠올라서 강사님의 라이브 영상이나 Q&A 내용을 보면서도 많은 팁을 얻었습니다.참가하며 남긴 기록들학교가 개강하고 다른 취준 일정이랑 겹치면서 점점 시간에 쫓기고 빨리해야 했어서 마지막에 몰아서 해버렸지만 후... 아무튼 완강까지 성공했습니다.후기강의는 백엔드 개발에 입문하는 사람이 대상입니다. 그렇다 보니, Git, HTTP나 서버-클라이언트 등의 개념도 입문자를 위한 설명을 포함됩니다. 다른 MVC 프레임워크 경험한 분은 30~50% 정도는 익숙한 내용일 수도 있을 것 같습니다. 개념에 맞춰서 잘 쪼개어 있고 강의 설명이 정말 깔끔합니당.. 이런 분이 강의를 하시구나 했습니다. 저는 아무래도 시간에 쫓기며 웹 개발을 많이 했기에 여러 내용들은 점검해가는 과정이라 생각하고 열심히 수강했습니다.그래도 난이도가 낮은 경우 빠르게 보고 덮은 다음, 스스로 찾아보면서 코드를 구현해보았습니다. 매일 라디오 듣듯이 따라가며, 다른 유사 MVC 프레임워크에서 추구했던 것도 비교하며 학습했습니다. 다른 분들의 질답도 많은 공부가 되었습니다. 고민의 깊이가 다르시더라고요!!배운 것최종적으로는 자바의 역사와 주변 지식, JDSL, Lombok, 코드를 보는 관점 등 여러 키워드를 얻을 수 있어서 유익했습니다.이전에는 VSCode를 많이 썼는데 이 참에 인텔리제이의 단축키도 익숙해질 수도 있었습니다.자바에서 자주 쓰는 단축키 CheatSheet을 만들어보는 것은 어떤가요?다른 사람의 과제랑 코드를 볼 수 있는 것도 좋은 경험이었습니다. 스터디를 매우 열심히 참여하시던 분들이 많아 놀랐습니다. 그러다보니 저도 기운을 받아서 더 공부하고 찾아봤던 것 같습니다ㅎㅎ.앞으로도 파이팅해서 만들고 싶은 프로젝트를 하나 만들어보려고 합니다. To Inflearn, 최태현 지식 제공자님. 재밌고 유익한 스터디 만들어주셔서 감사합니다!

백엔드인프런인프런워밍업클럽스터디0기

crispin

[인프런 워밍업 스터디 클럽 0기_BE] 후기

3주간의 스터디가 끝이났다. 정말 많은 걸 배울 수 있었고, 새로운걸 경험해 볼 수 있었다. 1. 코치님0기 백엔트 코치님은 최태현 코치님이다. 이전 찍으셨던 몇개의 강의(사실 전부..ㅎㅎ) 를 통해 내적 친밀감이 쌓여있었는데스터디 코치님 이라는 이야기를 듣고 꼭 스터디에 참여하고 싶다는 생각이 들었다. 강의를 통해서도 정말 많은걸 알려주시려 하고, 질문도 매우 친절하게 답변해주셨었는데 스터디를 진행하면서도 코치님은 질문 뿐만 아니라특강을 통해서 정말 많은걸 알려주시려고 하는 모습이 정말 대단하다고 느껴졌다.👍 현업에서 일을 하시면서 늦은 시간까지 이어지는 질문에도 친절하게 답변해주시는 모습을 보면서 나도 저런 좋은 영향력을 주위에 끼칠수 있는 개발자가 되고 싶다는 생각이 들었다. 2. 코드리뷰스터디를 처음 시작할때 커리큘럼을 보고 미니 프로젝트를 진행할때 다른 분들과 함께 코드리뷰를 하며 진행하면 어떨까?라는 생각이 들었었다. 할까말까 고민을 정말 많이 했었는데 개인적으로도 코드 리뷰를 해보고 싶었고, 좀 더 이 스터디기간동안 많은걸 배우고 싶어 용기를 내어 함께 진행해 볼 인원을 구했었다. 정말 다행히도 5분의 스터디원 분들이 함께해보자고 하셨고, 결과적으로 너무 만족스러운 시간을 보낼 수 있었다. 내 코드를 다른 사람에게 보여준다는건 지금도 쑥쓰럽긴 하지만 그렇기 때문에 코드 한줄을 작성할때도 정말 많은 생각을 하면서 작성할 수 있었다. 그리고 그 고민했던 내용을 함께 나누면서 정말 많은걸 배울 수 있었다. 다시 한번 함께 미니프로젝트를 진행했던 백엔드 스터디원분들 에게 감사하다는 말을 전해고 싶다.🙇‍♂ 3. 인프런보통의 회사에서 하기 어려운 이런 좋은 영향력을 전파하고 만드는걸 할 수 있다는게 늘 놀랍다. 해커톤이나 개발자 컨퍼런스 후원 기업에 매우 자주 인프런이 있는걸 볼 수 있고, 직접 인프콘 이라는(한번도 가보지 못했다. 나는왜 운이 없는것인가..💧) 큰 컨퍼런스를 열기도 하고. 전반적으로 개발자 생태계에 정말 좋은영향력을 널리 퍼트리고 있는 모습을 보면 정말 대단한 기업이라는 생각이 든다. 생각은 누구나 할 수 있지만 이걸 실천할수 있다는게 참 놀랍다. 이번 스터디도 그렇고 앞으로 더 많은 좋은 영향력을 널리 퍼트리려고 다양한 시도를하고 있는 모습을 보고 있으면 언제가는 인프런에서 일을 꼭 해보고 싶다 라는 생각이 듣다.(자바 개발자 안필요 하신가요💧) 4. 0기앞으로 이 워밍업 클럽이 0기에서 멈추는것이 아니라 1기 2기 쭉쭉 더 많은 사람들에게 좋은 경험이 될 수 있도록커져갔으면 좋겠다. 다음에 더 좋은 스터디가 열린다면 주변에 적극 추천해주고, 나도 다시 한번 참여해봐야겠다. 5. 마무리좋은 기회를 만들어주신 인프런 관계자 분들에게 정말 감사드린다. 특히 스터디 운영에 대해 이런저런 공지와 궁금증을해결해주신 셰리 에게 감사의 인사를 전하고 싶다. 더 많은걸 알려주시려 했던 최태현코치님 그리고 함께 했던 모든 백엔드 스터디 원 분들에게도 다시 한번 감사하다는 인사를 전하고 싶다. 주저리주저리 말이 많아졌는데, 혹시라도 미래에 있을 1기 신청을 고민하며 이 글을 보고 있다면 당장 신청 하라고 적극 권해 주고 싶다.

웹 개발인프런인프런워밍업클럽스터디0기백엔드

[인프런 워밍업 클럽 BE] 참여 후기

이 후기글은 인프런 워밍업 클럽 0기 BE의 전체 소감문입니다.https://inf.run/Hywa 사실 후기글을 써본 경험이 거의 전무하기에, 어떻게 작성해야 하는지조차 감이 잘 잡히지 않는다. 그래서 느낀 감정들을 두서없이 그저 솔직하게 작성해볼까 한다. 참가 신청과 첫 주이번 최태현 코치님 강의는 이전에 절반만 들어놓고 반년 간 시간을 허비하며 지낸 그런 부끄러운 과거 속의 강의 중 하나였다 . 그래도 운이 좋게도 메일로 이번 워밍업 클럽 홍보 글이 날아온 것을 보았고 바로 신청했다. 나는 스스로의 실력에 확신이 차지 않으면 도전하지 못하는, 어찌보면 많이 소극적인 성격인 편이다. 그랬기에 그동안 인프런에서 팀 프로젝트를 시도해보려고 해도 개발자로서의 지식이 너무 얕은 것 같아 차마 도전해보기가 어려웠다. 이번 스터디 신청 자체가 나 나름대로의 하나의 도전이었던 셈이었다. 결과적으로는 잘한 선택이었다고 현재는 마음 깊이 생각하고 있다.디스코드에 처음 접속해 서로 인사말을 남기는데 사실 조금, 아니 상당히 당황스러웠다. 나처럼 초보자 분들이 많이 오는 것을 예상했으나 이미 현업 종사자분들도 다수 참가하시는 것을 보았다. 그때부터 발등에 불이 떨어진 기분이었다. 다른 분들의 질문의 깊이나 발자국, 과제 내용 등을 보고 압도되는 기분이었다. 😂😂그리고 대망의 첫 중간 점검 라이브 때, 일정 관리 실패로 나는 바보같이 라이브를 놓쳐버렸다. 완주 러너의 조건에 중간 점검 라이브를 모두 참가해야 한다는 조항이 있었기 때문에 일주일 만에 열심히 하겠다는 나름의 다짐이 완전히 망가졌다. 그 이후, 그리고 스터디 끝첫 라이브를 놓치고 하루는 기분이 약간 쳐지긴 했었다. 딱히 우수 러너를 노리거나 포인트를 꼭 받아야겠다! 는 아니었지만, 그래도 무언가를 완주했다는 그 성과 자체가 없어지는 것이니 뼈아픈 일이었다. (그리고 수료증을 못 받는 것도 아쉬웠고... ) 하지만 제 1의 목표는 어디까지나 학습이니 그 이후도 내 나름대로 착실히 수행했다. 완주 러너가 되지는 못하겠지만 과제도 꾸준히 제출했고 2차 점검 라이브도 모두 참석했다.이전 후기에서도 작성했듯이 미니 프로젝트 코드 리뷰도 진행해보았고 지금은 좋은 분들과 함께 사이드 프로젝트를 진행 중이다. 아직 본격적인 개발 단계 전이지만... 😊그리고 인프런과 코치님들의 배려로 완주 조건이 완화되어 무사히 완주 러너가 될 수 있었다!당연히 완주 러너가 못 될 것을 예상해 오프라인 수료식 참가 신청을 하지 않은 것은 후회하긴 했지만... 완주 러너가 된 것 만으로도 만족했다. 그리고 대망의 수료식 날, 정말 예상하지 못하게 우수 러너로 선정이 되었다. 선정해주신 코치님에게 몇 번이고 감사 인사를 드리고 싶었다. 우수 러너 혜택으로 인프콘 티켓과 코치님과의 1:1 멘토링을 얻게 되었으니 정말 너무 과분하고 감사한 보상이다. 🙇‍♀️🙇‍♀ 반성할 점과 이모저모람다 함수와 스트림 학습을 위해 새 블로그 글을 만든 것이 있는데 첫 날 이후 정말 하나도 갱신하지 못했다.😭 3/9에 SQLD 시험이 있었기에 강의, 과제, 자격증 시험 공부를 병행하면서 저 글까지 갱신하는 것은 아무래도 과한 목표였을지도 모른다. 사실 저 SQLD 시험도 진작에 공부했으면 됐겠지만... 이미 지나버렸으니 어쩔 수가 없다. 요즘은 학습한 내용을 모두 개인 노션 페이지에 정리하고 있기에 아마 추가 학습을 해도 저 블로그 글은 갱신이 안 되지 않을까 싶다.요즘은 영한님의 로드맵을 따라 쭉 강의를 듣고 있다. 사이드 프로젝트에 폐를 끼치지 않기 위해 본격적인 시작 전 최대한 기반 지식을 더 다지고 있다. 우수 러너 혜택으로 1:1 멘토링도 남아있어서 더 많은 것을 얻기 위해서라도 많은 지식을 쌓아놓아야 할 듯 하다.

백엔드스터디후기

90년대 컴퓨터 공학 이야기 (5) — cache

이전의 두 단어 ( trade-off , orthogonal ) 이후에 그 뒤로도 아마 많은 이야기를 들었겠지만, 다른 류의 대학 생활과 섞이면서 오히려 뒤의 기억들은 흐릿한데, 커리어를 관통할 것으로 소개해 주신 세번째 그리고 기억 속의 마지막 단어는 'cache'. 첫번째 단어인 trade-off 의 연장선 상에서 아주 잘 정의된 예제이기도 하고, 담당 교수님의 전공 분야이기도 했었다. 어린 마음에 computer architecture 에 대한 매력을 느끼게 되었던 결정적인 부분이기도 하다. 아래는 연관된 몇가지 기억들. Locality ( 지역성? )시간적 지역성 ( temporal locality ) 와 공간적 지역성 ( spatial locality ) 를 이용해서 시스템 전체의 실행 속도를 올리는 아주 잘 정의된 요구사항들과 software / hardware 로 구현하기. 그로 인한 극대화되는 효율. 당시 교수님께서는 '아름답다'는 말을 종종 하셨는데, benchmark 를 통한 여러 기법들까지 이해할 부분이 많았던 당시에는 아름답다는 걸 이해하지 못했더랬다.CPU 안에 만들어진 것들을 구현하기 위해서는 hardware가 logic구현하고 있다는 사실에 놀랐었고, 이후 Operating system, file system 등을 깊게 들어갈 수 있는 용기와 무모함을 얻게 되었다. 그리고 당시 compiler 에게 hint를 주는 여러 기법등의 세심함과 집요함까지.. 이를 구현해 보기 위해 GCC 같은 것을 고치고 실패하고 등등 여러 좌절을 겪기도 했었다. 조금의 인내심이 더 있었으면 다른 미래가 펼쳐졌을 수도 있었을 텐데 싶긴 하다.다른 memory들학부 때 새로운 컴퓨터로 Intel Pentium 이라는 게 나오면서 L2 cache 라는 말을 이제 이해할 수 있게 되었고, 한편으로는 뭐 무조건 많고 비싸면 좋은 거 아닌가 등의 단순한 생각이긴 했었다. 그리고 이후 SRAM 같은 다양한 형태의 RAM, NOR/NAND Flash memory, SSD 등 메모리 입장에서만 해도 폭발적으로 변화하는 세상에서 본의든 아니든 다양한 걸 알게 되어야 했었다.나야 뭐 맛보기만 경험했었지만, 민교수님과 대학원 선후배님들은 언제나 그 중심에서 여러 일들을 하셨고, compiler , OS, controller 등을 섭렵하면서 같은 개념을 그대로 혹은 개선해서 구현하는 걸 보면서, 마음 한 편에서는 이 급변하는 세상에 수년이 지나도 관통한다는 게 이런 건가 싶은 깨달음을 얻기도 하었다. 한편으로는 예전의 compiler 에게 hint를 준다거나, application-aware 등의 아기자기함은 이제 논문이나 이야기 속에서만 존재하기도 하지만 그런 것들이 아마도 기반을 닦아 나갔을 것이다..밖에서도 cache컴퓨터 구조를 배우면서 소위 '정통파'에서 시작했다지만, 밖에서 만나는 모든 개념들도 여기 닿아 있고, 이제는 너무나 다들 자연스럽게 쓰는 용어가 되어 버렸다. https://en.wikipedia.org/wiki/Cache_(computing) 에도 hardware cache, network cache, software cache 등... 실제로 buffer(혹은 memory) 가 터졌을 때의 아기자기함(?)들과 관련된 사건사고등도 기억나기도 하지만, 점점 managed service 를 쓰는 입장으로 많이 바뀌면서 어떻게 구현하는지보다는 어떻게 사용하는지에 더 관심을 두며 지내 오게 되었다.몇몇 시스템디자인 인터뷰에서는 그냥 '캐쉬 앞에 붙이면 좋아져요', '돈으로 기계 사면 되요' 등의 무지성 대답도 하거나 들을 수 있게 되었고, 한편으로는 실전에서는 또 그렇게 인정하며 쓰는 습관들도 되어 버렸다. Memoization, CDN, Cloud storage gateway 모두 같은 개념이라 하겠고, 앞으로도 계속 그러하겠다.ps. 민상렬 교수님석사까지밖에 인연이 없었지만 돌아가신 교수님은 여전히 애증의 감정으로 기억한다. 분명 졸업 때는 미운 감정도 꽤 있었던 기억인데, 부족함이 많아 많은 것들을 더 배우지 못했고, 나중에 철이 들면서 이해를 하게 된 부분도 많고, 지금은 닮고 싶은 혹은 닮고 싶었던 어른의 모습에 가장 가깝다 하겠다. 특히 선함과 아름다움을 추구하는 마음가짐 등에 대해서는 깨달음이 늦었다는 게 많이 아쉽고, 16년 전 구글에 합격했다는 인사를 드렸을 때 환하게 웃어 주셨던 게 마지막 면담이 되었던 게 지나고 보니 특히 아쉽다.아래는 과학동아에 인용된 인터뷰들 중 발췌..---민 교수는 연구원들에게 항상 전체 시스템을 이해하라고 강조한다. 그래서 학부에서 하드웨어를 공부한 사람은 소프트웨어 연구를, 소프트웨어를 다뤄본 사람은 하드웨어 연구를 할 것을 제안한다.“과거 어떤 쪽을 미리 연구했는가 보다는 전체 시스템을 잘 이해하고 문제를 적극적으로 풀어나가는 능력이 중요하기 때문입니다. 2007년에 개발한 플래시메모리의 핵심 부품도 원래 소프트웨어를 다루던 연구원이 설계했습니다. 그리고 관련 기업에서도 전체 시스템을 잘 이해하는 연구원을 높게 평가하고, 필요로 합니다.”...“99%의 완성도를 만드는 것은 쉽습니다. 하지만 100%의 완성도를 가진 아름다운 제품을 만들기 위해선 그때까지 들었던 노력의 5~10배를 들어야 합니다. 그 1%를 만들기 위한 노력이 한국 플래시메모리의 미래를 결정할 것입니다.”하지만 민 교수는 현재 우리나라의 교육 여건에서 이런 완성도 있는 제품을 만들 인재가 나오기 힘들다고 지적한다. 어렸을 때부터 아름다운 것을 본 적이 있나? 라고 묻습니다. 하지만 한 명도 대답하지 못하더군요. 다양한 분야의 책을 읽거나. 곳곳을 여행하고, 이성도 만나면서 아름다움을 경험할 시기에 입시에만 빠져 지내는 청소년들을 보면 아쉽습니다.“

교양90년대컴퓨터공학

신영우

[인프런 워밍업 스터디 클럽 1기 디자인] 3주차 발자국 (신영우)

학습 내용복습을 위해 이번 주에 필기한 강의 내용을 갈무리했습니다 베리어블 모드를 사용하는 경우라이트 모드 / 다크 모드로 설정이 나눠져 있을 경우다중 언어 지원이 필요할 경우디바이스별 대응이 필요할 경우멀티브랜드 대응이 필요할 경우 라이트 모드 / 다크 모드→ 빛, 배터리, 인지 능력과 관련되어 있음라이트 모드평범한 사람들은 훨씬 퍼포먼스가 좋음긴시간 노출될 경우 근시 확률이 높아짐다크 모드빛이 덜 발산해서 배터리가 덜 듦저시력자의 경우 다크 모드를 선호함단, 서비스에 따라 다름상품 또는 콘텐츠가 돋보여야 하는 경우(ex. 이커머스, F&B 서비스)에는 라이트 모드 지향몰입형 미디어를 제공해야하는 경우(ex. OTT 서비스)에는 다크 모드 지향플랫폼 마다 다크 모드 디폴트 배경색이 다름 (→ 그림자 등 디자인 에셋에 영향을 끼침)AOS → 짙은 회색 (#121212)iOS → 완전한 검은색 (#000000) 다크 모드 설정 시 주의할 점브랜드 아이덴티티 고려접근성 고려특히나 명암 대비디자인 요소 - 3:1일반 텍스트 - 4.5:1작은 텍스트 - 7:1지속적인 테스트로 수정 가능성 고려 발견한 설계 꿀팁기존 컴포넌트 사용해서 새로운 컴포넌트 만들 시 오토 레이아웃이 아닌 그룹으로 만들어주면 불린을 적용할 때 영역을 차지하지 않음 사이즈 조절할 때 백터 에셋도 같이 조절하려면 백터 컨스트레인을 Scale로 변경해주면 됌 Command+R로 레이어 라벨링할 때 숫자의 경우 ’nn’ 앞에 ‘n’ 지워주면 1자리 수로 적용할 수 있음 네스트 인스턴스 적용할 때 스페이스바 사용해서 한번에 검색해 여러개를 동시에 적용할 수 있음 그룹을 먼저 적용하고 오토 레이아웃을 하면 자동으로 잡히는 영역없이 오토레이 아웃을 할 수 있음  미션 내용회고를 위해 이번 주에 진행한 미션 내용을 톺아봤습니다미션 #9 - 피드백 컴포넌트 전체 만들어보고 색상 대비 점검을 하기미션 #10 - 네비게이션 카테고리에 해당하는 컴포넌트를 만들어 보기미션 #11 - 네비게이션 카테고리에 해당하는 나머지 컴포넌트를 만들어 보기미션 #12 - 베리어블 다크모드 개념을 익히고 활용해보기 이번 주 드디어 모든 컴포넌트 작업을 마치고 다크 모드 적용에 들어갔다!컴포넌트 만드는 과정을 돌이켜보면 프로그레스바 만드는 미션이 가장 재밌었다.1도 예상치 못한 기발한 방법으로 프로그레스바를 만들며 피그마가 얼마나 잘 되어있는 툴인지 새삼 깨달았다.다른 컴포넌트를 만들 때도 적용할 수 있을 것 같아 절대 까먹지 않고 기억해두려 한다.다크 모드 적용은 컬러 콘트라스트를 체크해 시멘틱 컬러 베리어블을 다듬는 과정이 꽤나 어려웠다.라이트 모드에서 하나의 모드가 더 생겼을 뿐인데 관리할 포인트가 무진장 많아진 느낌이다...나중에 고생하지 않으려면 시스템은 초반부터 잘 만들어야 함을 다시금 깨닫는 순간이었다...!다크 모드는 실제로 처음으로 적용해 보는데 계획하는 단계가 잘 이해가지 않는다.(나중에 혼자 할 수 있을까 걱정이다...ㅠ)다음 주면 막 주다!드디어 기다리고 기다렸던 실제 화면 만들기에 들어간다.지금껏 꽤나 오랜 시간 공들여 만들어온 컴포넌트를 신나게 사용할 때가 다가온 것이다...이 말이다...막주까지 잘 달려서 모든 미션 완수하자! 화이태ㅐ애애애앵~!! 스스로 칭찬하고 싶은 점 : 1) 아이콘 시스템 수정 필요한 부분들 수정한 점2) 타이포 그래피 시스템 행간 수정해서 스타일 가이드까지 적용해 놓은 점아쉬웠던 점 : 1) 컬러 콘트라스트를 체크해 최대한 모든 부분을 수용할 수 있도록 수정했지만, 어쩔 수 없이 대비가 미미한 부분이 존재하는 점2) 다크 모드에서 눈물을 머금고 넘어가야하는 디자인 에셋(ex. 스켈레톤 UI)이 존재하는 점보완하고 싶은 점 : 프리미티브 컬러를 수정해보고 싶다...!다음주 목표 : 지금 처럼 킵 고잉해서 모든 미션 완료하기~!~!!

UX/UI피그마디자인시스템베리어블

여언주

[인프런 워밍업 스터디 클럽 2기 BE] 두 번째 발자국

2주차 5/7 - 5/10Section 3 역할의 분리와 스프링 컨테이너목표좋은 코드가 왜 중요한지 이해하고, 원래 있던 Controller 코드를 보다 좋은 코드로 리팩토링한다.스프링 컨테이너와 스프링 빈이 무엇인지 이해한다.스프링 컨테이너가 왜 필요한지, 좋은 코드와 어떻게 연관이 있는지 이해한다.스프링 빈을 다루는 여러 방법을 이해한다.스프링 컨테이너스프링 빈 (Spring Bean)서버가 시작되면, 스프링 서버 내부에 거대한 컨테이너를 만들게 된다.컨테이너 안에는 클래스가 들어가게 된다. 이때 다양한 정보도 함께 들어있고, 인스턴스화도 이루어진다.→ 스프링 컨테이너 안으로 들어간 클래스를 스프링 빈이라고 한다.cf) JdbcTemplate도 Dependency (의존성)에 의해 스프링 빈으로 등록되어 있다.서버가 시작되면스프링 컨테이너(클래스 저장소)가 시작된다.기본적으로 많은 스프링 빈들이 등록된다. 예를 들어, JdbcTemplate이 등록된다.우리가 설정해준 스프링 빈이 등록된다. 예를 들어, UserController가 등록된다.이때 필요한 의존성이 자동으로 설정된다. 예를 들어, UserController를 만들 때 JdbcTemplate을 알아서 넣어준다.Repository와 Service 스프링 빈 등록하는 방법Repository를 스프링 빈으로 등록할 때는 @Repository 어노테이션 사용Service를 스프링 빈으로 등록할 때에는 @Service 어노테이션 사용 ⇒ UserController는 UserService가 스프링 빈이니 굳이 직접 new 연산자를 통해 인스턴스화해줄 필요가 없다! 또한 UserRepository가 JdbcTemplate을 직접 가지고 있기 때문에 JdbcTemplate도 가지고 있을 필요도 없어진다.스프링 컨테이너를 왜 사용할까?스프링 컨테이너를 이용하는 이유컨테이너가 BookService를 대신 인스턴스화하고, 그 때 알아서 BookMemoryRepository 혹은 BookMySqlRepository 중 하나를 BookRepository로 결정해준다!= 제어의 역전 (IoC, Inversion of Control)이때 컨테이너가 BookService를 만들어 줄 때 BookMemoryRepository와 BookMySqlRepository 중 하나를 선택해서 넣어주는 과정= 의존성 주입 (Dependency Injection)- @Primary 어노테이션을 이용해 우선권을 제어할 수 있다.책 이름을 메모리에 저장하는 API 예시controller > book > BookController.javapackage com.group.libraryapp.controller.book; import com.group.libraryapp.service.book.BookService; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RestController; @RestController public class BookController { // new BookService() 안해도 됨! private final BookService bookService; // constructor public BookController(BookService bookService) { this.bookService = bookService; } @PostMapping("/book") public void saveBook() { bookService.save(); } } service > book > BookService.javapackage com.group.libraryapp.service.book; import com.group.libraryapp.repository.book.BookRepository; import org.springframework.stereotype.Service; @Service // 어노테이션 추가 public class BookService { private final BookRepository bookRepository; public BookService(BookRepository bookRepository) { this.bookRepository = bookRepository; } public void save() { bookRepository.save(); } } repository > book > BookMemoryRepository.javapackage com.group.libraryapp.repository.book; import org.springframework.stereotype.Repository; @Repository // 어노테이션 추가 public class BookMemoryRepository implements BookRepository{ @Override public void save() { System.out.println("Memory Repository"); // 테스트용 출력 } } repository > book > BookMySqlRepository.javapackage com.group.libraryapp.repository.book; import org.springframework.context.annotation.Primary; import org.springframework.stereotype.Repository; @Primary // 우선권을 부여하는 어노테이션 @Repository public class BookMySqlRepository implements BookRepository { @Override public void save() { System.out.println("MySql Repository"); // 테스트용 출력 } } 스프링 컨테이너를 다루는 방법빈을 등록하는 방법@Configuration클래스에 붙이는 어노테이션@Bean을 사용할 때 함께 사용해줘야 한다!@Bean메소드에 붙이는 어노테이션메소드에서 반환되는 객체를 스프링 빈에 등록한다.@Component주어진 클래스는 ‘컴포넌트’로 간주1) 컨트롤러, 서비스, 리포지토리가 모두 아니고 2) 개발자가 직접 작성한 클래스를 스프링 빈으로 등록할 때 사용@Service + @Repository vs @Configuration + @Bean개발자가 직접 만든 클래스를 스프링 빈으로 등록할 때 => @Service + @Repository외부 라이브러리, 프레임워크에서 만든 클래스를 등록할 때 => @Configuration + @Bean스프링 빈을 주입받는 방법(가장 권장) 생성자를 이용해 주입받는 방식@RestController public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService = userService; }setter와 @Autowired 사용@Autowired public void setUserController(UserService userService) { this.userService = userService; }→ 누군가 setter를 사용하면 오작동할 수 있다.필드에 직접 @Autowired 사용@Autowired private final UserService userService;→ 테스트를 어렵게 만드는 요인이다.스프링 빈의 우선순위 설정@Qualifier 사용스프링 빈을 사용하는 쪽에서만 쓰면, 빈의 이름을 적어주어야 한다.양쪽 모두 사용하면, @Qualifier끼리 연결된다!@Primary vs @Qualifier → 사용하는 쪽에서 직접 적어준 @Qualifier가 이긴다!Section 4 생애 최초 JPA 사용하기목표문자열 SQL을 직접 사용하는 것의 한계를 이해하고, 해결책인 JPA, Hibernate, Spring Data JPA가 무엇인지 이해한다.Spring Data JPA를 이용해 데이터를 생성, 조회, 수정, 삭제할 수 있다.트랜잭션이 왜 필요한지 이해하고, 스프링에서 트랜잭션을 제어하는 방법을 익힌다.영속성 컨텍스트와 트랜잭션의 관계를 이해하고, 영속성 컨텍스트의 특징을 알아본다.Spring Data JPA를 사용한 데이터베이스 조작JPA (Java Persistence API) 개념Persistence (영속성 ) : 데이터를 생성한 프로그램이 종료되더라도 데이터가 영구적인 속성을 갖는 것API : 정해진 규칙JPA : 객체와 관계형 데이터베이스의 테이블을 짝지어 데이터를 영구적으로 저장할 수 있도록 정해진 Java 진영의 규칙 / ORM (Object-Relational Mapping) 기술 표준JPA를 실제 코드로 작성한 가장 유명한 프레임워크 = Hibernate (내부적으로 JDBC 사용) Entity = 저장되고 관리되어야 하는 데이터user 객체에 @Entity 어노테이션 붙여주기@Entity를 붙이게 되면, 스프링이 이를 인식하여 서버가 동작할 때, User 객체와 user 테이블을 같은 것으로 간주@Column 어노테이션 : column에 붙여주기, 다양한 옵션 (필드에 null이 들어갈 수 있는지의 여부, 길이 제한, DB에서의 column 이름 설정 등) 최초로 JPA를 적용할 때application.yml 파일에 설정 추가!Spring Data JPA를 이용해 자동으로 쿼리 날리기 (기능 리팩토링)save : 주어지는 객체를 저장하거나 업데이트해준다.findAll : 주어지는 객체가 매핑된 테이블의 모든 데이터를 가져온다.findById : id를 기준으로 특정한 1개의 데이터를 가져온다.User : 이름을 기준으로 유저 데이터를 조회해 유저 객체를 반환한다. (유저 정보가 없다면, null)findByName : name을 기준으로 특정한 1개의 데이터를 가져온다. (함수 이름만 작성하면 알아서 SQL 조립)Spring Data JPA의 추가적인 쿼리 작성법 조사 및 연습!트랜잭션과 영속성 컨텍스트트랜잭션여러 SQL을 사용해야 할 때 한 번에 성공시키거나, 하나라도 실패하면 모두 실패시키는 기능→ 쪼갤 수 없는 업무의 최소 단위commit : 트랜잭션이 시작된 후 사용된 SQL을 성공적으로 반영rollback : 트랜잭션을 시작하고 사용한 SQL을 모두 취소UserService에 트랜잭션 적용메소드에 @Transactional 어노테이션 붙여주기주의) org.springframework.transaction.annotation.Transactional데이터의 변경이 없고, 조회 기능만 있을 때는 readOnly 옵션영속성 컨텍스트테이블과 매핑된 Entity 객체를 관리/보관하는 역할스프링에서는 트랜잭션을 사용하면 영속성 컨텍스트가 생겨나고, 트랜잭션이 종료되면 영속성 컨텍스트가 종료된다.영속성 컨텍스트의 역할변경 감지 (Dirty Check) : 영속성 컨텍스트 안에 불러와진 Entity는 명시적으로 save를 해주지 않더라도 알아서 변경을 감지해 저장할 수 있게 해준다.쓰기 지연 : 트랜잭션이 commit 되는 시점에 여러 SQL을 모아서 한 번만 날린다.1차 캐싱 : ID를 기준으로 Entity를 기억한다/Section 5 책 요구사항 구현하기목표책 생성, 대출, 반납 API를 온전히 개발하며 지금까지 다루었던 모든 개념을 실습해본다.객체지향적으로 설계하기 위한 연관관계를 이해하고, 연관관계의 다양한 옵션에 대해 이해한다.JPA에서 연관관계를 매핑하는 방법을 이해하고, 연관관계를 사용해 개발할 때와 사용하지 않고 개발할 때의 차이점을 이해한다. 조금 더 복잡한 기능을 API로 구성하기책 생성 API, 대출 기능, 반납 기능 구현 과제과제 4과제 52주차 회고이번 주차에 스프링의 굵직굵직한 개념들이 등장했는데, 코드 예시와 함께 단계별로 적용해보는 강의 내용이 이해에 도움이 많이 되었다. 특히 과제를 해결하고자 고민하는 과정에서 재미있고 자신감도 붙는 것 같다. 강의의 흐름을 따라가면서 더 공부해야 할 것들이 차곡차곡 정립되고 있다. 그때그때 찾아보고 적어두고 지식 불리기 중! 클린 코드 책도 읽겠다는 목표도 세웠다.벌써 절반을 훌쩍 넘어버렸으니 다음 주는 더더 화이팅!

백엔드인프런워밍업클럽백엔드

삼각커피포리

[인프런 워밍업 스터디 클럽 1기] 디자인 2주차 발자국

두번째 발자국시간이 너무나도 부족했던 2주차였다. 퇴근 후에 남는 시간을 모두 강의와 미션에 할애했는데도 불구하고 시간이 많이 소요되는 2주차였다. 아직 미션을 완주하지 못 했지만 이번주를 되돌아보는 발자국을 작성해야겠다. Day8 피그마 컴포넌트 기초 배우고 입력 컴포넌트 만들어보기 드디어 모든 컴포넌트의 기초인 버튼 컴포넌트를 만들어 볼 수 있게 된 시간이라서 무척 기대했다. 왜냐면 내가 실무에서 만든 버튼 스타일과 볼드님의 버튼 만드는 순서나 과정이 어떻게 다른지 궁금했기 때문이다. 버튼 컴포넌트에서 내가 만든 것과 볼드님의 스타일 중 다른 것은 바로 아이콘과 레이블의 배치였다. 나는 label onlly, icon+label, label+icon 이런식으로 버튼 타입을 구성했었는데, 볼드님은 LeadingIcon+Label+TrailingIcon으로 구성했다는 점이 달랐다. 이 점이 훨씬 더 경제적이고 아이콘을 불린 프로퍼티로 관리할 수 있어서 편리한 방법이라는 생각이 들었다.그리고 포커스 버튼 상태를 포커스 링 컴포넌트를 만들어서 앱솔루트 포지션으로 만드는 점도 인상깊었다. 나는 이전까지 버튼의 포커스 상태는 직접 스트로크를 outline 상태로 줘서 만들었는데 포커스링을 이용하여 만드는 포커스 상태는 더 눈에 잘 띄고 배리언트 관리가 용이하다고 느껴졌다.그리고 체크박스와 라디오버튼은 단독으로 쓰이기도 하지만 레이블과 함께 결합해서 미리 컴포넌트를 구성해두는 방법을 배우게 되었다. 토글 스위치에는 버튼에 아이콘을 넣을 생각조차 못 했는데 강의를 통해서 ON/OFF 상태에 아이콘을 넣어서 좀 더 명확하게 표현 할 수 있다는 것을 배웠다. 그리고 보너스 미션으로 설문조사 폼을 만들어봤는데, 만들고 나니 컴포넌트를 어떻게 활용해야 겠다는게 감이 잡히게 되었다. Day9 입력 컴포넌트 나머지 만들고 마지막 점검하기 IconPlaceholder라는 지식을 배우게 되었다. 그동안 입력 필드에 들어가는 텍스트만 플레이스홀더라고 생각했었지 아이콘은 플레이스 홀더라는 생각을 못했는데 이번 강의를 들으면서 새롭게 알게되었다. 입력필드도 생각보다 다양한 상태가 있어야 한다는 것을 알게 되었다. 그동안 상태는 버튼만 많다고 생각했는데 입력필드도 총 7가지의 상태(디폴트, 호버, 프레스, 셀렉트, 입력, 에러, 디스에이블)를 만들었더니 내가 실무에서 빼먹은 상태가 무엇인지 알게 되었다.텍스트필드 다음에 만든 텍스트 에리어에서는 현재 카운트와 토탈 카운트를 따로따로 구성한다는 것을 알았다. 그동안은 모두 현재 카운트와 토탈카운트를 하나의 텍스트 입력으로 퉁 쳤는데 이렇게 나눠서 구성하고 레이어 이름을 지으니 개발자와 소통하기 더 편할 것 같다는 생각이 들었다.셀렉트 그룹은 가장 배우고 싶었던 컴포넌트인데 배우고 나니까 바로 실무에 적용해야 겠다는 생각이 들었다. 왜냐하면 현재 실무에서 내가 만든 셀렉트는 어디가 잘 못 된 지 모르겠는데 오토레이아웃으로 하면 틀어지고 프레임으로 해야만 선택한 상태를 볼 수 있는 상태다. 그런데 볼드님의 방식으로 셀렉트를 만들고 인스턴스를 테스트해보니 아이콘도 붙일 수 있고, 체크박스도 붙일 수 있고, 라디오버튼도 붙을 수 있고 심지어는 포커스 상태도 만들 수 있는 아주 이상적인 셀렉트 박스를 만들 수 있었다.그리고 보너스 미션으로 회원가입 폼을 간단하게 만들어봤는데 이 날 배운 모든 컴포넌트를 이리저리 조합하니까 회원가입 폼을 쉽게 만들 수 있어서 매우 편했다. 잘 만든 컴포넌트를 UI를 빠르게 디자인 할 수 있는 아주 좋은 기초 공사라는 생각이 들었다.보너스미션으로 제작한 회원가입 폼 여담나는 1주차 미션을 미션보드에서 진행하지 못 했기 때문에 이전에 만든 스타일 가이드를 모두 퍼블리시해서 2주차 과제부터는 미션보드에서 작업 할 수 있었다. 1주차부터 미션보드를 활용한 사람들과는 조금 다르게 이번주 미션을 했지만 그래도 덕분에 퍼블리시 기능을 이용해 볼 수 있는 좋은 기회가 되었다고 생각한다.아직 미션7과 8을 모두 끝내지 못 했지만 한 주의 마무리를 하기 위하여 미션하며 느꼈던 점을 위주로 발자국을 작성했다. 돌아오는 주에 좀 더 시간을 투자하여 미션을 진행해야겠다. 

UX/UI피그마figma인프런워밍업클럽컴포넌트디자인

aabb

[인프런 워밍업 스터디 1기 디자인] 2주차 발자국

2 주차 / 5.7 - 5.10 / 컴포넌트 만들기 1 KEEP컴포넌트 만드는 게 점점 익숙해지고 있다.2주차 할일을 3주차로 미루지 않고 끝까지 해냈다😊강의를 먼저 쭉 듣고 두번째는 음소거 해 놓고 같이 실습하니까 확실히 시간이 절약되었다. PROBLEMcontrast 플러그인을 통해 명도 대비를 확인하는 과정에서 primary 컬러의 대비가 낮아 좀 더 진하게 수정하는 등 변경사항이 많아 시간이 많이 소요되었다.ㄴ 컬러를 수정하면서 전반적으로 어두워져서 내가 생각한 primary 컬러랑 멀어지는 게 난감했다.ㄴ 전체적으로 컬러를 뒤엎고 싶기도 했지만 너무 오래 걸릴 것 같아 일부 수정하는 걸로 마무리했다. /명도 대비를 확인하면서 다른 브랜드들은 어떤지 확인해 봤는데, G마켓 디자인시스템을 살펴보니 primary 컬러를 CTA 버튼에 사용하지 않고 action 컬러를 별도로 설정하여 CTA에 적용하는 점이 인상적이었고 네이버를 포함해서 의외로 꽤 많은 브랜드들이 CTA버튼의 명도 대비를 지키지 않는 걸 확인하면서 꼭 지키지 않아도 되는 건지 헷갈렸다..추후 bold님께 질문해야겠다! typography를 Notosans KR에 행간 140%으로 잡고 가니까 확실히 너무..불편하다. 컴포넌트를 만들면서 Roboto도 따로 써야되고.. 수정이 필요해 보인다. TRY사이드 프로젝트에 배운 디자인시스템 적용해 보기  

UX/UI워밍업클럽디자인시스템