블로그

데브경수

[인프런 x 데브경수] 개발만화를 시작합니다!

  안녕하세요, 인스타그램에서 개발만화를 그리고 있는 데브경수입니다. 1월 말까지 매주 목요일마다 인프런에서도 만화를 연재하게 되었습니다!   공부를 하다가 잠시 기분전환이 필요할 때 가볍게 보실 수 있는, 재밌는 만화를 그려보려고 합니다. 인프런 커뮤니티의 다른 글에도 종종 출몰할 예정이니, 그곳에서도 같이 이런저런 얘기 나눌 수 있었으면 좋겠습니다.   그럼 재밌게 봐 주세요, 잘 부탁드려요!

기타 (개발 · 프로그래밍)･데브경수･개발･만화

감자

컴퓨터 공학(CS)이 중요할까요?

저는 학부 시절에 전공수업을 들으면서 항상 답답한 마음이 있었어요.논리회로, 컴퓨터 구조, 자료구조, 알고리즘, 운영체제, 네트워크 등 컴퓨터 공학에서 꼭 배우는 과목을 들을 때마다 너무 막연한 기분이었죠.분명히 한 과목을 들을 땐 해당 내용에 대해서 자세히 배우지만 너무 이론적인 것만 배우는 느낌이 들었고,"왜 지금 당장 결과가 보이는 내용으로 공부하지 않을까?"라는 질문을 했었죠.🧐CPU가 어떤 구조이고 어떻게 동작하는지 이론적으로는 배우지만 정작 CPU가 어떻게 생겼는지는 아무도 알려주지도 않고 스스로 찾아본 적도 없었어요.CPU뿐만 아니라 RAM, 하드디스크 등 주변장치가 어떻게 생긴 줄도 몰랐죠.다른 과 친구들은 "너 컴퓨터 잘 아니까 부품도 잘 알고 조립도 잘하겠네?"라고 종종 물어보지만 그렇지 않았죠.네트워크 수업 때는 모뎀, 허브, 라우터 등 전부 이론적으로, 기껏해야 그림으로 된 예시로 보니까 현실 세계랑 매칭이 잘되지 않았어요.교수님들은 학교에서 배우는 전공이 중요하다고 말씀하실 때 항상 따라붙는 말이 있었어요.컴퓨터 공학은 매우 복잡하므로 Divide and Conquer(분할 정복)로 접근해 하나씩 자세히 알아보는 것이 중요하다, 하지만 이렇게 하나씩 배운 개념을 조합해 전체적으로 볼 줄도 알아야 한다.당시엔 전체적으로 볼 줄 알아야 한다는 말이 크게 와닿지 않았었는데요. 첫 직장에서 백엔드 개발자로 일하는 순간부터 느꼈어요.회사에서 사용하는 기술 스택들은 처음 접해보는 것들이었고 말로만 듣던 AWS도 직접 만져봐야 했죠.이때 많은 기술 스택과 AWS에서 사용하는 용어들은 굉장히 혼란스러웠죠.하지만 용어만 다를 뿐 전공에서 배운 개념들은 그대로였어요.제가 고생했던 것은 "실제로" 이것들이 어떻게 연결되어 동작하는지가 머리에 잘 정리되어 있지 않았던 것이었죠.회사에서도 공부할 시간을 줘서 얼마 되지 않아서 정리할 수 있었어요.그때 교수님들의 말씀이 다시 생각났어요."하나씩 배운 개념을 조합하는 게 이래서 중요하구나~"라고요.회사에 적응하고 개발할 때도 학과에서 배운 내용이 직/간접적으로 도움 된 적이 많아서 그때마다 교수님들을 떠올렸죠.한 번은 사용자의 특정 요청 중 일부가 아주 가끔 중복돼서 들어오는 경우가 있었어요.똑같은 환경에서 테스트해봐도 확인해볼 수도 없었고 하루에 하나가 있을까 말까 했죠.저희 팀에선 이 문제가 한 달 넘게 해결하지 못하고 있었던 상황이었어요.저도 이 문제가 왜 발생하는지 골치 아팠었죠.🧟그러던 어느 날 문득 원인이 예측됐어요. 운영체제에서 배웠던 개념에서 떠올릴 수 있었어요.그래서 예측한 원인을 해결할 방법을 찾아 코드를 수정했고 지켜봤어요!똑같은 문제는 다시는 발생하지 않았죠. 👏 이렇게 실무에서 컴퓨터 공학(CS)의 중요성을 알게 되어 기본기가 탄탄해야 한다는 말에 극공감하게 됐어요.하지만 CS를 배우는 건 어렵고 지루해서 금방 포기하게 되죠.그래서 저는 수업에서 들었던 궁금증, 그때 알았으면 좋았을 것들을 그림과 예시를 들어가며 직접 만들기로 했어요.현재 준비하고 있는 강의는 네트워크인데요.이론적인 내용뿐만 아니라 우리가 일상에서 볼 수 있는 기기가 네트워크에서 어떤 용어로 쓰이고 어떤 역할을 하는지,큰 그림을 맞춰볼 거예요. 만약 CPU의 동작 방식을 배웠다면 위의 그림처럼 CPU가 실제로 어떻게 생겼는지도 알아야 헷갈리지 않겠죠?네트워크는 하드웨어와 소프트웨어가 공존하기 때문에 이렇게 하드웨어까지 알아가며 퍼즐을 맞춰갈 겁니다.이만 다음 강의인 "그림으로 쉽게 배우는 네트워크"를 준비하러 가보겠습니다.😊

기타 (개발 · 프로그래밍)･CS･전공자･비전공자･컴퓨터공학･그림으로쉽게배우는･네트워크

한기용

성장하는 조직의 기술 부채는 언제 갚을까?

작은 회사에서 속도에 초점을 맞추고 주니어 중심으로 개발을 하면 당연히 기술 부채가 쌓인다. 워낙 숨 가쁜 일정으로 돌아가다 보니 유닛 테스트를 만드는 건 꿈도 꿀 수 없고 최종 QA(Quality Assurance)도 대충 하고 프로덕션에서 실제 고객들이 테스트 아닌 테스트를 하는 일도 다반사다. 자잘한 버그가 자주 보고되는 것은 물론 가끔 사고도 터지며, 이런 기술 부채로 인해 생긴 누더기 같은 코드로 인해 새로운 기능 개발도 지연되기 시작한다.  그렇다고 내일도 살아있을지 아무도 모르는 작은 회사에서 항상 깔끔하고 완벽하게 테스트된 코드만 지향하거나 무모하게 새로운 프레임워크를 사용해 볼 수도 없는 노릇이다. 시작하는 단계의 스타트업이 빠른 속도와 무결점 중 꼭 하나만 선택해야 한다면 속도를 선택하는 편이 유리하다는 게 내 생각이다. 그 대신 아래의 내용을 참고하면 돈이 더 생기고 더 경험 있는 사람을 뽑기 전까지 리스크를 최소화할 수 있을 것이다. 어느 시점부터는 슬슬 사고의 빈도가 늘며 정도도 심해지기 시작할 때 그 때부터는 아래를 고민해보는 것이 좋은 듯 하다.서비스 모니터링 프로세스를 만든다. 서비스에 문제가 생기면 빨리 인지하고 해결하는데 초점을 맞추는 것이다. 이 것도 상당한 노력과 시간을 필요로 할 수 있는데 기술 부채를 많이 안고 가는 상황에서 모니터링에 대한 노력을 먼저 기울이는 것이 맞다고 본다. 어떤 지표를 바탕으로 서비스의 안정성을 측정할 것인지 그리고 서비스에 문제가 생겼을 경우 어떻게 escalate하고 문제해결을 할지 점진적으로 개선해가며 프로세스를 만드는 것이다. 또한 사고의 심각성에 따라 재발을 막을 방법을 찾아봐야 하는데 이건 뒤 문단에서 이어서 더 이야기해보겠다. 2. 매주 엔지니어링 미팅 등에서 지난 한 주간의 버그와 사고를 리뷰하고 이유를 파악한다. 유닛 테스트 코드를 붙이지는 못하고 QA를 충분히 하지 못하더라도, 이미 발견된 버그와 사고가 재발하는 것을 방지하기 위한 테스트는 붙이는 것이 필요하다고 본다. 서비스 모니터링 프로세스가 어느 정도 자리잡혀있다면 사고 리뷰는 상대적으로는 쉬워진다. 만일 버그와 사고의 빈도가 점점 높아진다면 새로운 기능 개발뿐 아니라 기존 코드의 리팩토링에도 시간을 써야 한다. 유데미 시절 데이터 엔지니어링 팀은 이슈가 늘어나면서 그러다가 대형 사고를 한번 겪고 난 뒤 최대 40%의 시간을 리팩토링에 할애했다.  3. 훌륭한 개발자는 자신이 만든 결과물이 실제 사용자들에 의해 어떻게 사용되는지 관심이 많고 실제 사용자의 피드백에 귀를 기울이는 사람이다. ‘개발 다 했으니 내 업무는 끝!’이 아니라 어떻게 쓰이는지 보고 개선하려는 의지가 있다는 말이다. 인정받는 개발자 혹은 좋은 개발 팀의 매니저가 되고 싶다면, CS/CX 팀과의 협업 채널을 만들고 주기적인 미팅을 통해 고객의 소리를 들어보고 사람이 되자. SDD(Support Driven Development)라는 말을 들어봤는가? Y Combinator 스타트업 스쿨에서 강조하는 원칙 중의 하나이다.   몇 가지 상대적으로 쉽게 붙여볼 수 있는 중요한 성능 모니터링이 있는데 첫 번째는 백엔드 데이터베이스의 오래 걸리는 쿼리를 모니터링하고 문제 되는 부분을 찾아 미리 최적화하는 것이고 두 번째는 서비스 홈페이지나 중요 API의 실행시간 (latency) 모니터링을 해보는 것이다. 이를 기술 부채를 해결하기 위해 단기적 관점에서 해볼 수 있는 일이다.  물론 위와 같은 방법을 동원해도 사고는 터진다. 그중 몇 건은 대형 사고일지도 모른다. 그럴 때 중요한 것은 사고를 바라보는 경영진의 관점인데, 특정인이나 팀을 향해 손가락질하기보다는 사고 경위서를 작성해서 사고의 원인을 이해하고 재발 방지 대책을 세운 뒤 사내에 공유하는 과정에 집중해야 한다. 여기서 포인트는 경위서 작성 자체가 아니라, 밝혀진 문제의 재발을 막기 위한 조치들이 경위서의 내용에 포함되고 이런 조치들이 실제로 구현되어야 한다는 점이다. 온라인 서비스에서 사고는 언제 일어나느냐의 문제지 피해갈 수는 없다. 회사가 망할 정도의 사고만 아니라면 조직 구성원 모두가 기술 부채 등의 다양한 이슈를 체감하고 이를 줄이기 위해 노력할 수 있는 기회가 된다는 사실을 잊지 말자. 모든 위기는 기회가 될 수 있다. 모든 사람들이 기술 부채 문제를 체감하는 회사가 망할지 않을 정도의 대형 사고를 내가 사랑하는 이유다 🙂 What doesn’t kill you makes you stronger!

기타 (개발 · 프로그래밍)･기술부채･사고경위서･SDD

솔 (Sol)

우당탕탕! IT 회사 운영팀 공감 에피소드

“꼭 개발자만 코딩하고, 기술 얘기를 할까?” No! 테크 기업이나 개발자와 밀접하게 일하는 환경에서는 개발 직군이 아니더라도 문제를 해결하기 위해 코드를 짜고 구축하거나 개발자와 소통할 일이 종종 생기기 마련이죠.재미와 공감 사이! 인프런 운영팀에서 벌어진 가벼운 에피소드 세 가지를 소개할게요. (모든 에피소드에는 재미를 위한 약간의 양념(!)이 들어가 있습니다. ㅎㅎ)Episode 1. 강력 새로고침 그게 뭔데…?때는 2019년, 개발은커녕 컴퓨터도 잘 모르던 인프런 신입 콘텐츠 에디터 솔. 입사 첫 달, 버그를 발견하고 다급하게 개발 파트의 문을 두드렸는데요.조슈아(데브옵스 엔지니어) 말씀하신 버그 수정해서 배포했어요. 혹시 지금도 안 되나요?솔(콘텐츠 에디터) 넵! 아직 동작이 안 되고 있어요. ㅠㅠ조슈아(데브옵스 엔지니어) 아아 크롬 쓰시죠? 그럼 강력 새로고침 한번 해보실래요?솔(콘텐츠 에디터) …네?조슈아(데브옵스 엔지니어) 강력 새로고침이요!솔(콘텐츠 에디터) (멘붕) 어… F5를… 연타하면 되나요?구글 크롬(Google Chrome) 등의 브라우저에서 캐시된 데이터를 비우고 서버에서 새로 데이터를 받아오는 기능을 강력 새로고침(Hard Reload)이라고 하는데요. (Ctrl/Command + F5 또는 Ctrl/Command + Shift + R) 지금은 웃으면서 얘기하지만, 신입 시절 가장 당황스럽고 낯설었던 용어 중 하나였답니다 😂(부디 저만 모르는 용어가 아니었길 바라며...)Episode 2. 기술 사채(?)퇴근하고, 주말마다 짬짬이 파이썬 프로그래밍을 공부했던 B2B 파트 리드 고트. 이제 파이썬으로 자동화 처리나 웹 크롤링 등 간단한 작업을 할 수 있게 되었어요.고트(B2B 리드) 이제 이 코드를 실행시키면 제휴 기업에 필요한 데이터가 주루룩 떠요.솔(콘텐츠 에디터) 오오 대박… 완전 멋진데요. 근데 시간은 원래 이렇게 좀 걸리는 거예요?고트(B2B 리드) 그게 주먹구구로 코드를 짜서 성능은 어쩔 수 없어요. 저번에 코드 짜는 거 도와주신 개발자 한 분이 코드 보시더니 당황하시더라구.솔(콘텐츠 에디터) 기술 부채네요. ㅋㅋㅋ 리팩터링(Refactoring)을 해보면 어때요?고트(B2B 리드) ㅋㅋㅋㅋㅋ 음… 이건 기술 부채라고 할 만한 게 아니라 기술 사채를 쓴 거에 가깝기 때문에…영차영차 짜놓은 여러분의 코드, 지금 안녕하신가요? 파산 위기(?)에 놓이지 않게 조심하세요! 😓(기술부채_1장_요약.jpg) ©MBCEpisode 3. 위즈는 나야 둘이 될 수 없어?인프런 운영팀에서는 간단한 자동화가 필요할 땐 재피어(Zapier)라는 툴을 많이 활용하고 있어요. 특히 자동화에 진심(!)인 콘텐츠 MD 위즈가 여러 업무 태스크를 위한 자동화 봇을 재피어로 여러 개 구축해두었는데요.그 중 하나가 바로 æ-위즈! 콘텐츠 파트의 수많은 업무를 대신해주는 똑똑한 알림봇입니다.(요것이 æ-위즈. 걸그룹 에스파æspa에서 이름을 따왔어요.)하지만 자동화가 잘 갖춰진 환경을 마련하기까지는 쉽지 않은 법. 한번은 이런 얘기가 나온 적이 있었어요.메리(콘텐츠 MD) 근데 정산 관련해서 그 데이터는 누가 정리하고 있어요?코니(콘텐츠 MD) 어? 그거 æ-위즈가 자동으로 해서 알려주는 거 아니예요?위즈(콘텐츠 MD) 네 원래는 æ-위즈가 하는 게 맞는데…메리(콘텐츠 MD) 맞는데…? (불안)위즈(콘텐츠 MD) 재피어에서 뭐가 바뀌었는지 요새 봇이 안 울려서 æ-위즈 대신 사람 위즈가 하고 있습니다. 이번 달 데이터… 오늘 제가 정리해야 하거든요… ㅠㅠ전원 (숙연…)사람 손을 타지 않는 완전한 자동화의 길은 멀고도 험한 걸까요? 🥲더 편리한 업무 환경을 만들고, 똑똑하게 일하기 위한 팀원들의 고군분투는 계속됩니다. 쭉~!

기타 (개발 · 프로그래밍)･강력새로고침･기술부채･자동화･zapier･재피어･코딩

감자

컴퓨터 네트워크 강의를 준비중입니다.

안녕하세요 "그림으로 쉽게 배우는 컴퓨터공학" 커리큘럼을 만들고 있는 감자입니다!지금까지 제가 만들어 온 모든 강의에서는 여러분의 이해를 돕기 위해 그림을 이용해 설명해 드렸습니다.그런데, 지금 제가 준비하고 있는 강의는 네트워크 강의로 물리적인 장치의 이해까지 필요합니다.보통 전공 수업에선 이론적인 내용 위주로 설명하므로 여러분의 컴퓨터에서 데이터가 실제로 어떻게 이동하는지 직관적으로 알기는 어렵습니다.따라서 네트워크의 이론적인 내용과 물리적인 흐름을 모두 쉽게 이해할 수 있도록 강의 방식을 업그레이드 해보려 합니다.저로서도 새로운 도전이니 여러분들이 많이 응원해주시고 피드백 주시면 좋겠습니다. 😄(가정집 내에 있는 통신단자함 내부)저는 여러분이 인터넷을 사용할 때에 여러분의 집에 있는 통신단자함부터 건물의 통신실, 통신사, 서버까지로 데이터가 어떻게 이동하는지 시각화해 직관적으로 보여드리고 싶었습니다.하지만 기존의 강의 방식으로는 이러한 흐름을 보여드리기에 한계가 있었습니다.(사진과 그림만으로 이러한 것들을 설명하려니 만족스럽지 않았습니다)그래서 저는 여러분에게 직관적으로 전달할 수 있는 가장 좋은 방법이 뭘까 이리저리 고민하다가 3D 모델을 이용해 보기로 했습니다.(서울에는 내 빌딩이 없지만 3D세상에서는 구글빌딩이 내꺼🤗)3D 모델링을 하면서 굉장히 재밌게 준비했습니다.여러분들에게 가장 효율적으로 설명해 드릴 수 있다는 생각에 두근거리기도 해요!이제 준비한 내용으로 네트워크 강의를 열심히 만들어보겠습니다.많이 기대해주세요 😀 (시중에서 팔지 않는 제품도 3D 모델링이면 자세하게 소개할 수 있습니다)

기타 (개발 · 프로그래밍)･네트워크･3D모델링･그림으로쉽게배우는컴퓨터공학･CS･컴퓨터공학

솔 (Sol)

IT 개발 용어 뜻, 잘 모른다면? (API, 기술부채, 컴파일, 마이그레이션...)

혹시 내 얘기 아닌가요? 그렇다면 주목! IT 회사 들어왔는데, 다들 무슨 말 하는지 모르겠다! 개발자랑 농담 주고받고 싶다! 개발 용어, 뭔진 알겠는데... ‘느낌적인 느낌’만 안다! 프로그래밍에 관심있는데 진짜 아무것도 모른다...! 이게 대체 뭐람... 👉 그렇다면, 지금 인프런 공식 SNS 팔로우하고 매주 올라오는 인프런 단어짱을 읽어보세요!페이스북 | 인스타그램 | 트위터  오늘은... (두둥) 인프런이 전.격.홍.보! 안녕하세요! 인프런 콘텐츠 마케터 솔🌞입니다. 인프런 뉴스레터 및 ‘인프메이션’ (구: 주간 인프런) 발행을 맡고 있는데요.인프런 공식 SNS 채널 삼대장, 페이스북 + 인스타그램 + 트위터에서만 볼 수 있는 스페셜 콘텐츠(!)의 존재를 모르고 계셨던 인프러너 분들께 깜짝 소식을 전하러 왔습니다.바로... 2022~2023년 동안 인프런 공식 뉴스레터로 보내드리던 ‘인프런 단어짱’ 코너가 올해 3월부터 공식 SNS에서 재개되었어요.  인프런 단어짱이 뭔데? IT 용어에 대한, 왕초보도 알 수 있는 (중요!) 쉬운 해설이 필요하다는 건 저 역시도 인프런에서 일하면서 직접 뼈저리게 느끼곤 했는데요.(nn년 전 IT와 아~무 상관없는 전공 + 구)스타트업 깡신입의 대환장 조합...! 🥲)그래서인지, 그동안 인프런에서 발행했던 수많은 콘텐츠 중에서도2020년 ‘뉴비를 위한 개발 용어 사전’2022년 ‘소소한 IT 용어 모음집 - 인프런 단어짱’에 반응을 보내주셨던 분들이 유독 많아 놀랐던 기억이 있어요. 아무튼, 이번에 다시 부활한 인프런 단어짱은 더 자주 + 더 쉽게 더 많은 분들께 IT 개발 용어 뜻을 철저히 뉴비, 개발 왕초보 관점에서 알려드리는 걸 포부(?)로 삼고 있답니다! 담당자의 과한 드립 욕심(...)은 보너스 오늘까지 API, 기술 부채, 컴파일/인터프리트, 백도어, 마이그레이션 등 여러 IT 용어에 대한 해설과 에피소드가 공개되었으니 뜻이 알쏭달쏭하셨거나, 인프런이 하고 있는 무언가(?)가 궁금하신 분들이라면 언제든 인프런 공식 페이스북 / 인스타그램 / 트위터를 찾아와주세요! 여러분의 팔로우와 좋아요❤가 인프런 담당자를 춤추게 합니다...! 덩실덩실 항상 인프런과 함께해주시는 많은 분들께 감사드립니다. (Hoxy... 인프런이 초면이라면, 이것도 인연인데 앞으로 더 자주 만나요! 🫂)우리 함께 배우고 나누고 성장해요! 🍀인프런 마케터 솔 드림

기타 (개발 · 프로그래밍)･기술부채･컴파일･백도어･마이그레이션･IT･인스타그램･페이스북･트위터･API･인프런

비전공 개발자가 흔히 하는 고민

지난 주에 30대 초반에 부트 캠프를 통해 엔지니어로 전직한 분과 이야기해보는 시간이 있었다. 30대 중반이 되어 주니어 개발자로 일하고 있는데 대학을 졸업한지 2-3년차 동료들과 비교하며 힘들어 하고 있었다. 부트캠프부터 치면 3년이 되어가는데 아직도 잘 모르겠다고 하면서 어떻게 살아야할지 길을 잃은 것 같다고 고민을 털어놓았다. 30-40대 경력 전환 주니어 개발자들과 이야기하다보면 항상 나오는 패턴이다.20대로 돌아가면 어떻게 살것 같냐고 했더니 조금 생각하더니 술술 잘 이야기하길래 지금부터 그렇게 살면 된다고 조언해주었다. 앞에 시간이 많기에 (이분은 앞으로 적어도 40년은 일해야한다 ^^) 늦은 것 같지만 늦은 게 아니다. 나이가 주는 강박관념과 과거에 보낸 시간이 물경력이 아닐까 하는 후회, 그러다보니 나보다 어리지만 사실은 그 분야에서 더 오랜 시간을 보낸 사람들과 비교하기 쉽다.개발에 들어온지 3년만에 잘 할 수 있다면 그건 천재다. 오랜 시간이 걸리며 디버깅은 다들 아주 사소한 걸로 몇 시간부터 며칠 보내는 일이 허다하다. 마음이 조급하다보면 회사 일을 열심히 해서 실력을 늘리기 보다는 회사 일은 회사 일이고 업무 시간 밖에서 아직은 너무 어려운 다른 공부를 하며 스트레스 받기 쉽다 (방정식을 배우는 단계에서 미분을 배우려고 하는 듯 한 느낌). 처음은 기본기다.길게 바라보며 나만의 길을 찾고 내가 있는 곳에서 잘 하려고 최선을 다 해보는 것이 커리어를 발전시키는 가장 쉬운 길이다. "나"와 "현재"에 집중해보자.커리어 멘토링에 관심있다면 https://www.inflearn.com/mentors?mentor_id=1823 :)

기타 (개발 · 프로그래밍)･커리어고민･비전공개발자･물경력

셰리

IT 업계 회고 문화 겉핥기 🍉

'뒤를 돌아본다'는 의미의 회고. 1~4주 정도의 짧은 주기(스프린트) 안에 결과물을 구현, 배포한 뒤 빠르게 제품을 개선하는 루틴을 반복하는 애자일(Agile) 프로세스와 관련이 깊다고 해요.오늘은 직장인들에게, 특히 IT 업계 종사자에겐 일상과도 같은 회고 문화를 빠르게 훑어보려고 합니다. 회고에 대한 인프런 팀원의 생각도 담겨 있으니 끝까지 읽어보세요! 😆회고는 왜 해야 할까?회고는 지나온 프로젝트 과정에서의 문제를 찾고 발전하기 위해 진행한다고 해요. 반복적인 문제 상황을 줄이고 효율적인 업무 방식을 찾기 위한 과정인 것이죠.비케이(Product Designer) ⚒️회고의 목적은 'Better'라고 생각해요. 문제 상황을 공유하면서 피드백이나 개선점을 찾고, 잘한 부분은 칭찬하고. 그러면서 프로젝트를 통해 무엇을 얻었는지 확인할 수 있는 것 같아요.프로젝트를 함께한 팀원과의 회고는 서로의 감정을 공유하는 자리이기도 해요. 함께 일하는 팀원의 생각을 조금 더 이해하고 팀워크를 다지는 계기가 되기도 하죠.보니(Product Mananger) 🦊스프린트 회고와 최종 회고의 역할이 조금 다르다고 생각해요. 스프린트 회고(주간 회고)는 프로젝트 자체가 잘 운영되기 위한 회고에 가까워요.최종 회고는 팀이나 개인 차원에서의 장기적인 발전을 위한 회고인 것 같아요. 서로의 생각을 공유하고 앞으로 더 잘하기 위한 반성이 포함된 느낌?출처: MBC 무한도전  회고를 '잘' 하려면?1. 팀이나 개인에 맞는 회고 방식을 모색하는 시간이 필요해요.인프랩은 보통 KPT 방식으로 회고를 진행해요.빠삐코(Front-end Engineer) 🍦회고를 잘하기 위해서 개인적으로 여러 시도를 해봤는데요. 매일 업무 일지를 작성하는 게 도움이 많이 됐어요. 간단하게만 작성해둬도 나중에 전체 회고를 할 때 도움이 되는 경우가 많았어요. 프로젝트 과정에서 발생했던 문제를 시간이 지나면 잊기도 하는데, 업무 일지가 그런 것들까지 떠올리게 해줬습니다. 2. 프로젝트의 목표를 명확하게 정해두는 게 좋아요.엠제이(Product Designer) Ⓜ️처음에 프로젝트의 목표를 명확하게 정해두는 게 꼭 필요하다고 생각해요. 목표가 명확해야 회고할 때의 기준이 생기고, 업무에 대한 동기부여가 되는 것 같아요. 프로젝트가 목표에 맞게 잘 진행이 되었는지를 중심으로 이야기하니까 회고하기도 수월했어요.중요한 점은 목표를 반드시 팀원 다같이 논의해서 정하는 거예요. 3. 프로젝트에 대한 설계나 계획이 잘 되어 있어야 해요.보니(Product Mananger) 🦊프로젝트 동안 팀원 각자 역할에 대한 계획을 세우는데, 그 계획을 잘 세워두면 좋은 회고가 가능한 것 같아요. 프로젝트 동안 팀원 개개인이 매일 어떤 일을 했는지 스스로 알고 있어야 회고할 거리가 생기더라고요. 그렇지 않으면 느낌이나 기억에 의존한 감정적인 회고에만 그칠 수 있다고 생각해요. 4. 프로젝트를 함께한 팀원에 대한 존중과 배려가 필요해요.비케이(Product Designer) ⚒️회고할 때 감정이 아닌 행동 중심으로 이야기하라는 말에 공감해요.빠삐코(Front-end Engineer) 🍦서로를 존중하되, 솔직하게 말하는 태도가 필요하다고 생각해요. 서로를 존중하느라 진짜 하고 싶은 이야기를 놓치면 안되니까요.출처: MBC 아빠! 어디가?회고에 대한 정답이 정해져 있는 건 아니지만, 회고의 목적이 업무의 효율성과 앞으로의 성장에 있다는 점은 누구나 공감할 것 같아요.여러분은 회고를 해야 하는 이유가 무엇이라고 생각하시나요? 회고를 잘하기 위한 방법은 뭐라고 생각하시나요? 회고에 대한 다양한 의견을 댓글로 남겨주세요! 회고 문화를 더 깊게 다룬 글을 읽어보고 싶다면?[개발자의 공유 문화 이모저모 (2) 회고 문화] 읽어보기 >> 인프랩 팀원이 작성한 다양한 회고록을 살펴보고 싶다면?[인프랩 실Log] 읽어보기 >>

기타 (개발 · 프로그래밍)･회고･회고문화･애자일

솔 (Sol)

개발 기술 스택 심볼 & 마스코트 톺아보기

‘노트북 꾸미기’ 좋아하세요? 많은 개발자들이 노트북에 자기가 쓰고 있거나 좋아하는 기술 스택 로고 스티커를 붙이며 나만의 개성을 표현하곤 하는데요. 혹시 여러분의 노트북엔 어떤 스티커가 붙어 있나요?귀엽고 멋진 건 놓칠 수 없는 개발자라면 주목! 수많은 개발자들의 마음을 사로잡은 기술 스택에 숨은 아기자기한 심볼과 마스코트 몇 가지를 가볍게 소개할게요.썸네일 속 노트북은 인프런 백엔드 개발자 제이의 노트북!지금 쓰고 있는 스택(GraphQL 등...)이나 앞으로 배우고 싶은 스택(Go 등...), “Think Twice Code Once” 같은 개발자 밈 스티커까지 컨퍼런스나 주변 개발자 분들께 받은 스티커가 붙어 있어요. 🥰프로그래밍 언어 로고/심볼자바 (Java) 모락모락 김이 나는 귀여운 커피 컵! 자바 개발자들은 인도네시아 자바 섬에서 난 원두로 만든 커피를 마시곤 했대요. 몇 시간 동안 머리를 맞대고 토의한 끝에 정한 이름이라고 합니다.파이썬 (Python)‘비단뱀’이라는 뜻의 파이썬. 심볼 속 뱀 두 마리를 찾으셨나요? 파이썬을 만든 귀도 반 로섬(Guido van Rossum)이 영국 코미디 그룹 몬티 파이튼(Monty Python)에서 이름을 따왔다고 해요.스위프트 (Swift) iOS, macOS 개발에 쓰이는 스위프트는 ‘칼새’ 혹은 ‘신속한, 재빠른’이라는 뜻의 영단어 Swift에서 따온 이름이에요. 로고 모양도 날쌘 칼새를 닮았죠? 신속함을 강조하는 스위프트의 정체성을 잘 보여주네요.코틀린 (Kotlin) 자바와 비슷하면서도 간결한 문법으로 이목을 끄는 코틀린! 코틀린을 개발한 젯브레인(JetBrains) 사의 R&D 센터가 있는 러시아 코틀린(Ко́тлин) 섬에서 이름을 따왔는데요. 자바 역시 섬 이름인 걸 보면 두 언어의 관계가 재미있죠. 심볼 역시 머리글자 K를 간결하게 변형한 모양이에요.•••다양한 기술 스택 속 귀여운 마스코트깃허브 (Github) - 옥토캣 (Octocat) 복잡한 코드를 결합하고 관리하는 깃허브의 문어 다리 달린 고양이 마스코트 ‘옥토캣’. 3개 이상의 브랜치를 결합하는 작업을 가리키는 Octopus Merge에서 영감을 얻었다고 해요.리눅스 (Linux) - 턱스 (Tux) 믿거나 말거나! 리눅스를 만든 리누스 토르발스(Linus Torvalds)는 호주 캔버라 동물원에서 펭귄에게 물어뜯겨 펭귄염(?)에 걸린 적이 있다고 해요. 리눅스 마스코트로 삼을 정도면 그만큼 강렬한 경험이었던 모양이죠? 😅PHP (PHP: Hypertext Preprocessor) - 코끼리 (ElePHPant) 대문자로 쓴 PHP라는 글자를 옆에서 비스듬히 보면 코끼리처럼 보인다는 이유로 코끼리 마스코트를 갖게 된 PHP. elePHPant라는 말장난도 왠지 귀엽지 않나요?러스트 (Rust) - 페리스 (Ferris) 최근 개발자들 사이에 코어한 인기를 끄는 언어, 러스트의 비공식 마스코트는 주황색 게 모양이죠. 갑각류(Crustacean)에서 따온 듯한 요 마스코트 덕에 러스트 개발자들은 스스로를 Rustacean이라고 부른다고 하네요.고 (Golang) - 고 고퍼 (Go Gopher) 일러스트레이터 르네 프렌치(Renee French)가 그린 고퍼는 프로그래밍 언어 Go를 상징하는 주머니고퍼(흙파는쥐) 모양의 마스코트예요. 원래는 특별히 정해진 색이 없었다가 Google I/O 2011에서 Go App Engine 런타임을 출시하면서 파란색이 되었다고 해요.안드로이드 (Android) - 안드로보이 (Androboi) 단순한 듯 귀여운 녹색 로봇 마스코트 안드로보이! 안드로이드는 버전 1.1부터 OS 버전에 따라 디저트 이름을 붙이기로 유명한데 (컵케이크, 도넛, 오레오, 롤리팝…) 디저트 모양에 따라 달라지는 안드로보이의 모습을 보는 소소한 재미도 있죠.셀 수 없이 많은 기술 스택만큼, 매력적인 심볼과 마스코트도 무궁무진한데요. 여러분이 좋아하는 기술 심볼/마스코트는 어떻게 생겼나요? 댓글로 여러분의 최애 스킬(!)의 모습을 소개해주세요. 🥰

기타 (개발 · 프로그래밍)･java･python･swift･kotlin･github･linux･php･go･android･rust

솔 (Sol)

컴퓨터/IT 용어, 한국어로는 어떻게 옮길까?

폰트는 ‘글꼴’ 다운로드는 ‘내려받기’... 우리 입에 자연스럽게 굳어진, 친숙하게 번역된 표현이 있죠.그렇다면 ‘클라우드’는 어떨까요? ‘버그’나 ‘링크’는? 왠지 한국어로 옮기기 어렵게 느껴지지 않나요?컴퓨터 및 IT 기술의 기원이 해외에서 처음 온 만큼 많은 관련 용어가 외국어, 특히 영어로 되어 있는데요. 그래서 이런 용어를 한국어로 옮기는 게 좋은지, 오히려 그대로 사용하는 게 좋은지에 대한 의견도 참 분분하죠?마침 10월 9일 한글날도 성큼 가까워져 온 지금, 컴퓨터/IT 용어 번역과 현지화를 둘러싼 이야기를 몇 가지 정리해보았어요. 가볍게 읽어주세요! 🗣️“원래부터 있던 말 아닌가?” 자연스럽게 굳어진 이름한국어 번역이 자연스럽게 굳어진 컴퓨터/IT 용어 중 쉽게 떠올릴 수 있는 용어라면 특히 소프트웨어 관련 조어가 많죠. 몇 개만 살펴볼까요?Desktop → 바탕 화면 GUI 운영체제를 탑재한 최초의 컴퓨터 제록스 알토(Alto)에서 처음 쓰인 데스크톱 메타포에 대해, 마이크로소프트 윈도우 95 한국어 버전에서 번역한 이름입니다. (Windows 3.1까지는 ‘책상정리’로 번역)Favorites → 즐겨찾기 마이크로소프트 인터넷 익스플로러(Internet Explorer) 한국어판에서 처음 사용한 이름. 유사 기능인 Bookmarks는 그대로 ‘북마크’ 또는 ‘책갈피’로 번역합니다.그밖에 도움말(Help), 바로가기(Shortcut), 탐색기(Explorer), 실행 취소(Undo) 등…바탕 화면, 제어판, 휴지통, 시작 등 현지화를 위해 붙인 한국어 번역 표현이 돋보이는 Windows 95.이런 용어 중엔 마이크로소프트(Microsoft)나 어도비(Adobe) 사의 제품처럼 외산 소프트웨어를 수입해 공식 한국어판으로 출시하며 새로 번역했거나, 한글과컴퓨터, 이스트소프트 등 한국 기업발 소프트웨어에서 붙인 이름이 굳어진 경우가 많습니다. 소프트웨어 점유율이 높거나 초기에 보급되는 등 여러 이유로 친숙해진 고유명사가 보통명사처럼 쓰이는 일도 흔하죠.이밖에 일본, 중국 등 한자문화권 국가에서 쓰던 한자 표현을 그대로 한국어로 옮겨온 용어도 있죠. 학교나 동호회, 각종 커뮤니티, 인터넷 등을 타고 퍼진 경우도 드물지 않습니다.좋은 번역, 나쁜 번역?PC 보급 초기부터 이어진 전산용어 순화 움직임이른바 ‘PC통신 낭만기’로 불리는 1990년대에는 PC통신상에 전산용어 순화 게시판(BBS)이 생기고 용어를 한국어로 순화하는 운동도 벌어졌습니다. 당시 만들어진 ‘열쇠말’(Password), ‘풀그림’(Program), ‘사이띄개’(Space Bar) 등 대부분의 용어가 지금은 쓰이지 않고 발음 그대로 외래어를 쓰거나 다른 한국어 표현으로 대체되었지만, ‘내려받기’(Download), ‘글꼴’(Font) 같은 용어는 요새도 더러 쓰이고 있죠.PC통신 시대를 뜨겁게 달궜고, 지금도 전철이나 버스에서 볼 수 있는 ‘둥근모꼴’ 폰트가 이 시기에 만들어졌다고 해요.공적 차원의 한국어 다듬기민간이나 사기업 차원에서의 번역뿐 아니라 국립국어원이나 KBS 같은 공공기관 및 언론사 등이 주도해 만든 단어도 있죠. ‘댓글’(Comment)이 대표적입니다. ‘누리꾼’(Netizen), ‘누리집’(Homepage) 같은 단어도 종종 볼 수 있고요. 댓글처럼 대중적으로 정착한 표현도 있지만, 어색하거나 억지스러워서 오히려 이해하기 어렵다는 비판을 받은 말들도 많았어요.국립국어원에서는 전산 및 IT 관련 다듬은 말이나 중앙행정기관에서 고시한 표준 전문용어를 볼 수 있는데요. 몇 가지만 소개해볼게요.메타버스(Metaverse) 확장 가상 세계 가상 융합 세계디버그(Debug) 벌레잡기디지털 트랜스포메이션(Digital Transformation) 디지털 전환빅테크(Big Tech) 정보 기술 대기업애플리케이션 프로그램(Application Program) 응용 프로그램해커톤(Hackathon) 끝장 개발 대회배치 파일(Batch File) 묶음철 묶음기록철세이브(Save) 보존 갈무리 저장그밖에개인이나 민간 차원에서 컴퓨터/IT 용어를 한국어로 옮기는 모습은 최근에도 종종 찾아볼 수 있어요.RanolP님 “더 나은 번역을 위한 번역 용례집”서울대학교 컴퓨터공학부 “프로그래밍 언어 및 프로그래밍 시스템 분야 번역 용례집” 및 “컴퓨터과학/컴퓨터공학 쉬운 전문용어” (이광근 교수)‘번역’과는 조금 다르지만, 코딩할 때 변수나 함수 등의 이름을 한글로 짓는 일에 대한 견해 역시 무척 분분하죠.토스페이먼츠 “한글 코드 규칙 a.k.a 세종대왕 프로젝트”컴퓨터/IT 용어 한국어 번역, 여러분은 어떻게 생각하시나요? 외국어가 서툴거나 전문가가 아니라면 알아듣기 어려운 언어의 장벽을 낮출 수 있다는 말부터, 뜻이 부정확해지거나 어감이 어색해서 오히려 정보 전달을 어렵게 한다는 의견까지 참 다양한 토론이 오가는 주제인데요.인프러너 여러분 각자의 의견을 댓글로 함께 이야기해주세요! 💬

기타 (개발 · 프로그래밍)･번역･프로그래밍･IT･한글화･한국어･기술용어･한국어화･외래어･외국어･현지화

왜 CS 전공지식은 ‘개발자 기본기’로 꼽힐까?

컴퓨터 구조, 자료구조, 알고리즘, 운영체제, 네트워크, 데이터베이스 등은 컴퓨터공학 및 컴퓨터과학, 소프트웨어공학 등의 전공에서 반드시 배우는 주제로 꼽힙니다. 학교나 학과마다 커리큘럼에 차이는 있더라도 내용 자체는 모두 동일한 개념을 배우게 되는데요.이러한 CS 전공 지식은 컴퓨터 관련 학과에서의 전공 이해를 좌우할 뿐만 아니라, 개발자 채용을 위한 기술 면접 과정에서 주로 검증하는 핵심 개념이기도 합니다. 가령 서비스 개발자라면 비즈니스 로직을 구축하는 등, 프로그램의 구조를 만들고 문제를 해결하는 바탕이 되기 때문입니다. 이미 실무에 진출한 개발자들조차도 CS 전공 지식을 강조하는 이유가 여기에 있죠.다시 말해 CS 전공 지식은 개발자로서 필요한 문제 해결 역량을 결정하는 기본기 역할을 합니다. 대학생, 취업 준비생, 주니어 개발자 등을 막론하고 실력 있는 프로그래머가 되기 위한 든든한 뿌리가 필요하다면 CS 전공 지식에 주목해야 합니다.•••기술 면접 전, 실무 프로젝트 전 빠르게 기초를 정리하고 싶으신가요?지금 인프런 프리즘 [CS 전공 지식 로드맵]을 통해 학습해보세요. https://www.inflearn.com/roadmaps/643•••인프런 프리즘 브랜드 스토리 읽어보기 >>

기타 (개발 · 프로그래밍)･CS전공지식･컴퓨터구조･알고리즘･자료구조･운영체제･네트워크･데이터베이스･컴퓨터공학･인프런프리즘･InflearnPrism

WhoSoon Hwang

15. 내가 생각하는 반복 (feat. 이소룡)

 요즘 개발자들에게 자주 듣는ㅋㅋㅋ  질문) “어떻게 하면 그렇게 개발을 하시나요?” 내 답변) 내가 살아온 경험을 공유해주니…  질문자 답변) “그렇게까지 하고 싶진 않네요. 좀 더 쉬운 길은 없나요.” 내 답변) “저는 이렇게 해왔어서 다른 길은 저도 잘, 다른 분들에게 물어보시는 게 나을지도 모르겠네요.” 내 생각) 그럼 지금과 별반 다르진 않겠지.  같은 방법으로 살면서 다른 결과를 어떻게 기대하지 도통 이해가 안 된다. 모두가 잘하는 방법은 수없이 많이 듣는다. 들을 때뿐이어서 그렇지. 왜 알면서 안 할까? 노력 없이, 희생 없이 무언가를 얻고 싶으면 다른 길을 찾아봐야 하는데 그 어떤 길도 그렇게 쉽게 얻을 수 없다고 생각하는 편이다. 나도 아직 너무나 부족한데, 나보다 부족하다고 생각하는 사람들이 나만큼도 노력을 하지 않는다. 나는 여전히 가장 많은 코드를 구현하고, 리팩토링하고, 가장 많은 공부를 한다. 내가 선택한 길이고, 내가 원하는 꿈 너머 꿈을 현실로 만들기 위해서는 아직도 턱없이 부족하다. [나는 한번 수련에 만 번의 발차기를 하는 사람은 무섭지 않다. 한 번씩의 발차기 수련을 만 번 하는 사람이 무서운 거다.] - 이소룡 (ref. https://qusmo.com/celeb/2) 나는 이소룡의 재능이 없기에 십만 번 하는 사람이 되어보려 한다. 근데, 반복만 하는 게 아니라 반복할 때마다 달라야 한다. 전과 똑같은 반복은 성장의 폭이 너무 얇다.

기타 (개발 · 프로그래밍)･반복･수련