Tigercow.Door

2024 Prography 네트워킹 세미나 이야기

Tigercow.Door — Mon, 8 Jan 2024 02:51:58 +0900

IT 커뮤니티, Prography

안녕하세요. 문범우입니다.

2024년 첫 주말, 1월 6일 토요일 Prography에서는 여러 사람들을 대상으로 네트워킹 세미나를 개최했습니다.

저 또한 세미나에서 "6년차 서버개발자가 IT커뮤니티를 하는 이유"라는 주제로 발표를 진행했는데요,

네트워킹 세미나에서의 이야기를 공유드리고자 합니다.

Prography에서는 1월13일부터 9기 모집이 시작됩니다.
글을 읽으며 조금이라도 가슴이 뛰거나,
열정이 꿈틀꿈틀 움직이신다면 적극적인 지원 부탁드립니다.
또한 앞으로도 네트워킹 세미나와 같은 행사를 꾸준히 개최하기 위해 노력하고 있으니, 많은 관심 부탁드립니다!

Prography : https://prography.org/
Prography 플러스채널 : http://pf.kakao.com/_tusXG

0. 네트워킹 세미나

Prography에서 준비한 네트워킹 세미나는 프로그라피 소개 세션을 포함하여 총 9개의 세션으로 구성이 되었습니다. 그리고 총 1시간의 커피챗이 준비되어 있었습니다.

(자세한 내용을 보려면 아래 더보기를 클릭해주세요!)

Prography 네트워킹 세미나 타임스케줄

네트워킹 데이 사전 수요조사 참석율

사실 어떠한 주제들이 많은 분들에게 공감을 사고 열정을 나눌 수 있을지 많은 고민을 했던 터라 세션 주제에 대해서 사전수요조사 부터 진행했었는데, 기대한 바 이상으로 수요조사의 응답이 좋아서 계획했던 수요조사 기간을 기다리지 않고 약 3일만에 수요조사 설문을 마감했었어요.

네트워킹 세미나 신청율

많은 분들께서 참여해주신 사전수요조사에서 좋은 반응이 있던 주제들을 중심으로 전체적인 세션을 구성했으며, 딱 1주일간 네트워킹 세미나 신청을 받았음에도 불구하고 세션당 평균 65명의 신청자가 모집되었습니다

아무도 관심이 없으면 어떡하지?

귀한 2024년 첫 주말을 우리와 함께 해줄 분들이 많이 있을까?

우리가 준비한 주제에 공감해줄까?

많은 프로그라피 매니저들이 고민과 걱정들로 시작했지만, 많은 분들이 관심와 애정을 보내주셔서 남은 시간동안 더욱 힘내서 준비할 수 있었던 것 같습니다.

2024 Prography 네트워킹 세미나

1. Marketing / ProductOwner / Design

Design 세션. "사이드 프로젝트를 포트폴리오에 활용하기" by 김준성 매니저님

오전 시간에는 마케팅 세션을 시작으로 ProductOwner 세션과 Design 세션이 진행되었습니다.

이른 아침부터 시작되는 세션들이라서 참여하시는 분들이 기대보다 적거나 힘드시지는 않을까 걱정했지만, 정말 많은 분들이 찾아와주셨고 그 누구보다 뜨거운 열정으로 세션에 참여해주셨습니다!

참여자 Q&A

특히나, 세션 내용이 종료되고 Q&A 시간에도 많은 질문들을 주셔서 함께 이야기를 나누는 시간이 될 수 있었던 것 같아서 정말 뿌듯했습니다.

또한 Prography 매니저와 함께 커피챗을 하는 시간에도 많은 분들이 함께 이야기하는 모습을 보면서 커피챗 시간을 조금 더 길게 잡았어야하나 싶은 아쉬움도 생기더라구요

비개발 직군 커피챗

2. Prography 소개 세션

Prography 소개 세션 by 염준우 디렉터님

프로그라피 소개 세션은, 염준우 디렉터님께서 진행해주셨습니다.

5년이 넘어가는 시간동안 지속되는 Prography의 철학과 특히 올해 9기에서 변화되는 점들, 매니저들이 준비하고 기대하고 있는 점들을 이야기 했어요.

Prograhy 소개 세션 : 목차

프로그라피는 아래와 같은 4가지 철학을 가지고 있어요.

- Communication : 서로 신뢰하며 소통을 편안하게
다채로운 경험을 통해 재밌게, 보다 편안하게 몰입합니다.
- High Quality : 탁월한 동료와 최상의 임팩트 추구
각 분야의 실력있는 크루가 모여 도전적인 목표로 나아갑니다.
- Synergy : 함께하는 즐거움에서 성취하는 짜릿함으로
파트별 최소 인원으로 팀을 구성해 잠재력을 최대한 끌어냅니다.
- Improvement : 서비스를 지속하기 위해 끊임없이 고민
런칭 후에도 빠르게 개선하며 유저를 위한 정답을 만들어갑니다.

이러한 철학을 위해 Prography가 준비해야 하는 것들, 그리고 준비하고 있는 것들을 참여해주신 분들과 함께 공유했습니다.

3. Frontend / Mobile / Backend

Frontend 세션. "프로그라피 홈 개편 프로젝트" by 송민선 매니저님

오후시간에는 개발파트에 대한 세션들이 진행되었습니다.

특히, Frontend 세션에서는 2024년 새롭게 런칭된 프로그라피 홈페이지 개발기에 대한 이야기를 진행했습니다.

실제로 빠른시간동안 개발을 진행하고 성공적으로 런칭하고 운영중인 결과물을 여러분들과 함께 공유하면서 앞으로 프로그라피 홈페이지에서 어떤 것들을 제공할 수 있을지 함께 고민할 수 있는 시간이 된 것 같습니다.

Backend 세션. "6년차 서버개발자가 IT커뮤니티를 하는 이유" by 문범우 매니저

그리고 제가 준비했던, "6년차 서버개발자가 IT커뮤니티를 하는 이유" 세션도 진행이 되었습니다.

세션에서는, "더 나은, 더 좋은 개발자는 무엇인지" 함께 이야기를 하고 이를 바탕으로 어떻게 이러한 것들을 프로그라피에서 채워나갈 수 있는지를 소개해드렸습니다.

직접적으로 기술과 관련된 내용이 아니라 개발자분들께서 많이 관심을 가져주실까 걱정이 많았는데 그래도 많은 분들께서 세션 중에 좋은 리액션을 보여주시고 Q&A나 커피챗 시간을 통해 좋은 피드백을 주셔서 너무나 뿌듯하게 진행했던 것 같습니다. ‍♂️

4. 네트워킹 세미나, 그 이후

네트워킹 세미나가 성황리에 종료되고, 세션을 했던 매니저들 이외에도 함께 준비하고 진행했던 매니저들과 함께 저녁식사를 하며 간단한 피드백과 함께 우리가 앞으로 어떻게 더 많은 분들에게 좋은 인사이트를 제공드리고, 함께 사이드 프로젝트를 하며 성장해나갈 수 있을지 이야기를 나누었습니다.

특히나, 세션 종료 후에 피드백을 주시는 분들의 이야기를 하나하나 꼼꼼히 읽어보면서 우리가 앞으로 어떠한 것들을 더 준비해야 할지 체크해나가고 있습니다.

프로그라피는 많은 분들과 함께,
새로운 가치를 만들어 나가기 위한
IT커뮤니티로
성장해나아가고 있습니다.

그리고, 그 과정 속에서
함께 사이드프로젝트를 진행하시는 분들의
쉼터이자 든든한 버팀목,
지원군이 되기 위해
더욱 뜨겁게 달려가고 있습니다.

이러한 프로그라피의 여정에
더 많은 분들이 함께하여
더 좋은 IT 커뮤니티를
함께 만들어나가기를 기대합니다.

Prography 9기 매니저

Prography에서는 1월13일부터 9기 모집이 시작되니,

글을 읽으며 조금이라도 가슴이 뛰거나 열정이 꿈틀꿈틀 움직이신다면 적극적인 지원 부탁드립니다.

또한 앞으로도 네트워킹 세미나와 같은 행사를 꾸준히 개최하기 위해 노력하고 있으니, 많은 관심 부탁드립니다!

Prography : https://prography.org/

Prography 플러스채널 : http://pf.kakao.com/_tusXG

IT동아리 프로그라피(Prography) 8기 운영진 활동 이야기

Tigercow.Door — Sat, 16 Dec 2023 04:17:32 +0900

프로그라피 Prography

안녕하세요. 문범우입니다.

오랜만에 블로그에 글을 적게 되었네요.

오늘은 23년 한해동안 활동한 프로그라피(Prography)에 대해서 후기를 적어보려고 합니다.

곧 24년이 다가오면서, 새롭게 외부활동이나 동아리, 단체를 고민하시는 분들에게 조금이나마 도움이 되었으면 좋겠네요.

1. 프로그라피(Prography)는 무엇을 하는 곳 인가요?

주변분들에게도 동아리 활동을 한다고 이야기했을 때, 가장 많이 듣는 질문이기도 합니다.

프로그라피는 '디자이너, 개발자가 모여서 하나의 프로덕트를 만들고 운영하며 함께 성장하는 곳' 입니다.
( 24년 프로그라피 9기에서는 P.O와 마케터가 합류해서 보다 전문적인 프로덕트를 만들어 나갈 예정입니다! )

매년 조금씩 차이는 있지만, 8기에서는 디자이너2명, 프론트개발자2명, 서버개발자2명이 한 팀이 되어 함께 약 6개월의 시간동안 하나의 프로덕트를 만들어 나가는 활동을 하였습니다. 결국 프로그라피에서는 여러분들이 사이드 프로젝트를 하기위해 도움을 주는 세션과 활동들을 진행하구요.

저는 프로그라피에서 8기 Spring part 매니저로 활동하였기에 23년초 리쿠르팅 과정부터 함께 하였습니다.

Spring part에서는 100명이 넘는, 많은 분들께서 지원해주셔서 어려운 고민속에 12분을 프로그라피 8기로 모시게 되었고, 12명 모두 6개월의 기간동안 끝까지 서버 개발을 열심히 해주어서 괜스레 뿌듯했습니다 :D

활동을 시작하는 3월에는 8월말까지 함께 프로덕트를 만들어갈 팀을 구성하며, 팀원들과 더 친해질 수 있는 다양한 활동들을 하면서 어떠한 프로덕트를 만들지 아이디어도 모아보면서 서비스를 구체화 하는 시간을 가지기 시작합니다.

팀마다 조금씩은 다르지만, 대체적으로 4월~5월을 넘어가면서 실제 개발이 시작되었습니다.

물론 팀마다 본인들의 프로덕트를 개발하는게 메인 목표이긴 하지만, 또 파트별로 서로가 의견을 나누며 성장할 수 있도록 파트별 모임도 진행합니다. 파트별 모임에서는 본인 팀의 프로덕트와 연관되어 고민되고 있는 부분이나, 해결한 이슈등을 공유하며 같은 커리어를 가진 사람들끼리 더욱 성장할 수 있는 시간을 보내었습니다.

또한, 7월에는 '스타트업 데이' 시간을 통해 다양한 스타트업에서 참가하여 본인들의 서비스를 소개하고, 프로그라피 8기 인원들이 고민하고 있는 것들에 대해 함께 이야기해보거나, 회사의 채용과 연계된 이야기를 해보는 시간을 가졌습니다.

이후 8월말에는 프로그라피의 마지막 활동, '데모데이'를 진행하며 8기를 마무리하였습니다.

2. 기억에 남는 활동은 무엇인가요?

프로그라피 8기 데모데이

가장 기억에 남는 활동은 '데모데이'입니다.

많은 분들이 6개월의 시간동안 서로 열심히 고생하며 노력한 결과물들을 한눈에 볼 수 있는 시간이었고, 실제로 사용해보며 감탄하는 시간들이 되었던 것 같아요.

또한 서버개발자의 관점에서만 프로덕트를 보는 것이 아니라, 사용자의 입장에서 어떠한 서비스들이 더 매력적으로 다가오는지를 함께 피드백하며 '데모데이'가 8기 활동의 마무리이지만, 각 서비스에게는 또 다른 '시작'이라는 느낌이 들더라구요.

특히나, 이번 프로그라피 8기 데모데이에서는 외부인들도 초청하여 방문가능하게끔 운영을 하였는데요.

본인의 지인과 함께 참여하여 지인들에게 직접 만든 서비스를 보여주거나, 다른 팀의 서비스를 보여주며 자랑아닌 자랑을 하는 모습도 재밌었습니다. 그리고 실제로 데모데이가 진행된 역삼역 마루180주변을 지나가던 고연차의 디자이너 두분이 플랜카드를 보고 방문하여 좋은 말씀을 해주셨던 부분도 기억에 남네요.

프로그라피 8기, 케이크크(cakk) 서비스

특히나, 단순 토이프로젝트나 프로토타입의 형태가 아니라 실제로 사용할 수 있는 수준의 서비스들을 함께 보면서 길지 않은 시간동안 정말 많은 노력들을 통해 멋진 프로덕트들을 만들어 냈다는 것을 체감할 수 있는 시간이었습니다.

프로그라피 8기, AI 그림일기 서비스

GPT 등으로 한창 핫해지고 있는 AI 분야와 접목해서 만들어진 'AI 그림일기' 서비스는 현재도 꾸준히 버전이 업데이트 되고 있으며, 현시점 기준 앱스토어에서 5점 만점 평가를 받고 있는 아주 멋지고 신선한 서비스 입니다.

프로그라피 8기, AI 그림일기 서비스

각자가 가진 뛰어난 역량들을 그대로 두지 않고, 또 다른 직군의 사람들과 만나서 이렇게 멋진 서비스들을 만들어 낸다는 것이 프로프라피 최고의 매력이 아닐까 싶은 시간들이었습니다.

3. 프로그라피 활동을 통해 성장할 수 있는 포인트는 무엇인가요?

단순히 프로덕트를 만드는 것만으로는 사실, 본인의 커리어에 대한 걱정이 빠질 수 없죠.

하지만 저는 프로그라피 활동이 어떠한 파트에게든 본인의 커리어에 대단한 영향을 미치고 엄청난 성장을 이끌어 올 것이라고 생각합니다.

그리고 이러한 점들을 이미 알고있거나, 기대하고 있는 다양한 사람들이 모이는 곳이 프로그라피이기에 그들과 함께하는 시너지는 엄청난 효과를 발휘하고 있습니다.

함께 프로젝트를 만들어 나가기 위한 명확한 목표 선정

프로그라피는 학생과 직장인 구분없이, 본인이 희망하는 파트에 대한 최소한의 실력만 갖추었다면 함께 하고자하는 의지와 열정만으로 뭉친사람들입니다.

그들과 6개월동안 하나의 프로덕트에 집중하면서 성장할 수 있는 포인트는 너무나 많습니다.

특히나, 서버개발자 관점에서는 프로덕트를 초기에 준비하며 기본적인 세팅들을 하는 것부터 큰 배움이 될 수 있습니다.

단순히 토이프로젝트나 팀프로젝트 식으로 준비하는 것이 아닌, 실제 서비스 운영단계까지 고려하면서 프로젝트를 세팅해야하기 때문에 학습차원을 넘어서 고민해야할 것들이 많습니다.

또한, 초기 서비스 도메인에 대해 파악하고 이를 기반으로 설계를 진행해본다는 것은 매우 어려운 업무이면서도 다양한 것들을 고민해볼 수 있는 기회입니다. 흔히들 이야기하는 '클린 코드', '클린 아키텍처'등에 대해서 지속적인 고민을 해야하고, 왜 그러한 것들을 잘 지켜나가면서 개발해야하는지를 몸소 느낄 수 있는 시간들이 될 수 있죠.

보다 좋은 서비스를 만들기 위해 꾸준히 고민하고, 함께 이야기합니다.

그리고 본인이 만들어낸 로직들이 실제로 시장에 배포되고 관련된 지표들을 보면서 Next Step을 생각하고 개선방안을 고민하는 것은 학생이나 직장인 모두에게 신선한 재미와 또 다른 성장 포인트로 다가오기도 합니다.

단순히 회사에서 요구하는, '해야해서 하는 개발'이 아니라 내가 우리의 서비스를 위해 '하고싶은 개발'을 해볼 수 있는 시간들이 넘쳐나고, 활동 중 이용되는 디스코드를 보고 있으면 주말이나 새벽시간 할 것 없이 모두가 열정을 쏟아 각자 최선을 다하는 모습을 볼 수 있습니다. 그리고 그러한 사람들과 함께하는 6개월은 엄청난 시너지를 통해 본인도 모르게 스스로의 성장을 이끌어내게 되는 모습을 심심치않게 볼 수 있습니다.

4. 아쉬웠던 점은 무엇인가요?

이번 8기에서는 특별히, 서비스 초기에 '페이크 마케팅'을 진행하며 우리가 고민한 아이디어가 얼마나 많은 사람에게 매력적일지 살펴보는 등의 과정도 있었는데요. 이러한 방법이 처음인 사람들에게도 매우 신선한 방법이었습니다.

또한 위에서 말씀드린 것 처럼 실제로 시장에 배포한 서비스들은 외부에 마케팅을 진행하며 보다 많은 사용자 유입을 이끌어내기도 하였습니다.

이러한 과정들이 있다보니, 마케팅분야에 대한 본격적인 니즈가 필요해지기도 했지만 관련된 전문가가 없기에 어려웠던 부분들이 적지 않았던 것 같습니다.

기본적인 마케팅만 진행하게 되거나, 마케팅을 진행하더라도 결과를 전문적으로 분석하는 것이 힘들거나 하는 상황들이 벌어지곤 했습니다.

때문에, 팀에 전문 마케터가 있거나 서비스 자체에 대한 오너십을 가지며 미래를 그려나갈 수 있는 담당자가 있으면 어떨까 하는 아쉬움이 남았던 것 같습니다.

5. 우리, 프로그라피 9기에서 만나요!

그리고 우리는 이러한 아쉬움을 채우기 위해, 프로그라피 9기에서는 팀 구성에 변화를 주어 P.O(Product Owner)와 마케터(Marketer)를 함께 선발하게 되었습니다.

요새 다양한 IT동아리들이 운영되고 있지만, 그 중에서도 P.O와 마케터를 함께 모집해서 서비스에 대한 전문성과 집중도를 강화시키는 곳은 오직 프로그라피 뿐이라고 생각합니다.

그리고 그러한 변화에 발맞추어 현재 관련 파트의 전문가들이 매니저로 모여 23년9월부터 24년에 진행될 프로그라피 9기를 위한 준비를 함께하고 있습니다.

어떻게 하면, 프로그라피 9기 여러분들이
더욱 좋은 서비스를 만드는 것에 집중할 수 있을까?
더욱 좋은 서비스를 더 멋지게 운영할 수 있을까?
본인의 역량을 어떻게 더 끌어올릴 수 있을까?
커리어에 대해 성장할 기회를 만들어 줄 수 있을까?

우리 프로그라피 9기 매니저들이 매일매일 고민하며 밤낮과 주말없이 준비하고 있는 것들입니다.

물론 매니저들 뿐만 아니라, 함께 활동할 9기분들이 함께 만들어나가는 프로그라피가 될 것이기에, 본인의 역량을 의심하기보다 이글을 읽으며 호기심이 생기고 조금이나마 가슴이 뛰었다면, 주저말고 프로그라피 9기 모집에 함께 참여해보시길 추천드립니다!

프로그라피 9기는 2024년 1월 13일(예정) 모집을 시작하며, 3월2일 첫 만남을 시작으로 9월까지 약 6개월간 함께 합니다.

활동기간에는 해커톤, 데모데이, 스타트업데이, 컨퍼런스 등 다양한 활동을 통해 더 멋진 서비스, 더 멋진 성장이 될 수 있도록 준비하고 있습니다. 아래 링크를 통해 프로그라피 9기 모집시작에 대한 알림을 받을 수 있습니다.

프로그라피 홈페이지: https://prography.org/

왜 개발자가 되려고 하시나요?

Tigercow.Door — Mon, 25 Apr 2022 03:11:17 +0900

여러분들은, 왜 개발자가 되려고 하시나요?

안녕하세요. 문범우입니다.

이번 글에서는 ‘개발자'에 대해서 개인적인 생각을 풀어보려고 합니다.

글을 쓰고자 하는 의도는, ‘개발자’라는 직업을 생각하고 꿈꾸는 분들께 보다 현실적인 이야기를 전해드리기 위함이고 글의 내용만을 본다면 ‘개발자의 단점'이라고 볼 수도 있을 것 같습니다.

무엇보다 주관적인 견해의 글이며 다른 개발자분들께서는 다르게 생각하실 수도 있으니 가볍게 읽어주시면 좋을 것 같습니다.

최근 개발자라는 직업이 다양한 매체에서 좋은 모습으로 많이 소개되는데, 정말 좋은 모습만 있는건 아니라는 것을 전달드리고 싶어서 글을 써내려간다는 점을 생각하고 읽어주시면 좋을 것 같습니다.

(아래 사용된 모든 사진들의 출처는 Instagram @waterglasstoon입니다.)

1. 실력이 없다면 언제든지 도태된다.

많은 분들이 들어보셨을 것 같습니다.

“개발자는 평생 공부하는 직업이야”

하지만, 생각보다 많은 분들이 이 문장에 대해 정말 진지하게 생각하지 않는 경우를 종종 보았습니다.

평생 공부를 해야한다는 것은 생각보다 많은 단점을 내포합니다. 물론 다른 직업이 공부를 하지 않는다라는 이야기는 절대 아닙니다.

개발자는 근무시간이 아니더라도 꾸준하게 자기개발을 해야합니다. 물론 개발분야와 관련되어 자신이 관심있고 하고싶은 내용에 대해 공부하는 경우도 많지만, ‘해야해서' 하는 학습도 정말 많습니다.

Instagram @waterglasstoon

글을 쓰고 있는 필자는 현재 2개의 스터디를 병행하고 있습니다. 그리고 최근에는 관심있는 분야에 대한 자격증을 함께 준비하고 있구요. 제가 이렇게 열심히 산다를 자랑하는 것이 아니라, 실제로 주변의 성장하는 개발자들을 보면, 제가 하고 있는 활동들이 그렇게 무리한다거나 오버하는 수준이 아니라는 것을 말씀드리고 싶었습니다.

많은 매체에 소개되는 ‘좋은 개발자', 소위 연봉이 높고 엄청난 복지혜택을 누리는 개발자들로 성장하기 위해서는 정말 많은 노력이 필요합니다. 누군가에게는 힘든 시간이기도 하죠.

물론 개발이라는 분야가 잘 맞아서 그 과정들을 즐겁게 소화해낼 수 있으면 정말 좋은 케이스일 것 입니다.

하지만 그럼에도 불구하고, 하루 12시간 컴퓨터 앞에 앉아서 영어로 된 공식문서를 살펴보고, 답이 없는 에러케이스를 파헤쳐 보며, 뭐가 문제인지도 모를 삽질을 해가는 것에 대해 내가 소화해낼 수 있을까를 진지하게 고민해보는 시간은 정말 중요하다고 생각됩니다.

2. 워라밸은 보장되지 않을 수 있다.

어쩌면 1번의 내용에 이어지는 단점일수도 있겠습니다만, 조금은 다른 포인트로 이야기해보겠습니다.

Instagram @waterglasstoon

대부분의 소프트웨어는 24시간 여러분에게 서비스를 제공합니다. 그리고 그렇게 24시간 운영되는 소프트웨어의 뒤에는 언제나 개발자가 있습니다.

여러분이 잠들기 위해 눕는 밤 11시 또는 새벽 1시에도 여러분이 담당한 서비스에서 에러가 발생하면 대응을 해야합니다.

(물론 대응체계가 잘 잡혀있는 대부분의 서비스는 아닐 수도 있지만, 최악의 상황을 말씀드리는 점 양해 부탁드립니다.)

또한 이런 특수적인 상황이외에도, 프로그램을 개발하기 위한 일정이 시급할 땐 늦게까지 야근을 하는 경우도 있을 수 있습니다. 물론 매번 그러한 상황이 온다면 그것은 일정 조율 및 관리가 부족했던 문제도 있겠죠.

Instagram @waterglasstoon

우스갯소리로 서버 개발자들은 어딜 가든 노트북을 가지고 다닌다고 하죠. 팀원들을 믿고 휴가를 가더라도, 항상 혹시나 하는 마음에 노트북을 챙기는 모습들을 심심치 않게 볼 수 있습니다.

워라밸이 아예 없다고 하는건 무리일 수 있겠지만, 적어도 개발자라면 자신이 담당한 서비스에 책임감을 가져야하고 이것은 어쩌면 여러분들의 일상과 업무를 100% 분리하는 것은 불가하다는 의미이기도 합니다.

3. 엄청난 삽질과 끈기가 필요하다.

이건 특히나 대학생, 취준생 분들이 많이 겪어보지 않는 문제이기도 합니다. 특히나 학원이나 인터넷 강의등으로 특정 커리큘럼을 따라서 공부하던 분들에게는 많이 부족한 경험이기도 하구요.

스스로 프로젝트를 진행해보신 분들은 많이 겪어봤겠지만, 우리가 책이나 강의로 학습하는 내용과 실제로 서비스를 만들기 위해 현업에서 겪는 과정은 정말 하늘과 땅 차이입니다.

Instagram @waterglasstoon

단순해 보였던 기능도 예상치 못한 곳에서 많은 문제가 발생할 수 있고, 공식문서를 아무리 뒤져보고 구글링을 열심히 해봐도 이렇다할 정답이 나오지 않는 경우도 많습니다. 이럴땐 여러분이 직접 문제에 부딪혀가며 솔루션을 만들어 내야하고, 이런 과정들은 언제나 개발자들을 지치게 합니다.

물론 그 성공에 대한 열매는 매우 달콤하죠. 그 맛에 개발을 하시는 분들도 많구요.

하지만 이렇다할 정답 없이, 끝이 보이지 않는 동굴을 헤매는 듯한 과정을 여러분들도 견딜 수 있는지는 꼭 한번 고민이 필요하다고 생각됩니다.

4. 매체에서 말하는 좋은 점들이 보편화된 사실은 아닐 수 있다.

뉴스에 ‘개발자'라고 검색만 하더라도 정말 다양한 기사가 쏟아집니다. 그 중 유난히 돋보이는 기사들도 있죠.

“개발자에게 수천만원의 스톡옵션 약속 ... ”

“xx기업 역대급 대규모 개발자 채용 ... ”

“연봉 x천만원 개발자 ... ”

물론 이 기사들이 허구라고 말씀드리는 것이 아닙니다.

하지만 기사들처럼 모든 개발자가 엄청난 연봉과 복지 혜택을 받고 있는 것 또한 절대 아닙니다.

물론 다른 직군들에 비해, 현 시대가 많은 개발자를 요구하고 있는 것은 어느정도 인정할 수 있지만, 결국 개발자라는 직업 또한 다양한 직업들 중 하나 입니다.

수요가 커진다는 것은 자연스럽게 공급이 강화되기 마련이고, 기업들은 보다 좋은 개발자에게 좋은 제안을 하게 됩니다.

그리고, 좋은 개발자란 앞에서 말했듯 엄청난 자기개발과 노력이 필요하게 되죠.

제가 생각하기에는 ‘개발자'라서 엄청난 연봉을 받고 엄청난 복지 혜택을 받는 것 보단, 그 혜택을 받는 분들이 ‘엄청난 노력'을 했기 때문이라고 생각합니다.

단순히 매체에서 말하는 좋은 점들만 가지고 ‘개발자가 되어야겠다!’ 라고 생각하기에는 그 이면에 가려진 어려움들이 생각보다 많습니다.

5. 개발자가 되는 것이 쉽지만은 않다.

Instagram @waterglasstoon

특히나 온라인 매체를 보며 항상 아쉽게 생각하는 것은, 개발자되기가 쉬운 것 처럼 광고되는 다양한 학원들입니다.

'x개월만에 프론트엔드 개발자되기', 'xx주 풀스택 개발자 커리큘럼' 등 다양한 광고가 있습니다.

네, 당연히 그러한 커리큘럼을 통해 정말 좋은, 대단한 개발자가 되신분들도 당연히 있습니다. 하지만 그 커리큘럼을 수강한 모두가 그랬을까요?

일반적으로 개발자가 되는 컴퓨터공학부 학생들은 다른 학부와 같이 4년의 대학과정을 통해 컴퓨터의 기초지식부터 최근 사용되는 다양한 기술까지 많은 내용을 학습합니다. 졸업작품 뿐만 아니라 대학교 2학년, 3학년 때에도 다양한 프로젝트를 진행하고, 엄청나게 많은 서적들을 학습합니다.

헌데, 아직 컴퓨터에 대한 기초지식도 없는 사람이 1년 커리큘럼을 수강하는 것만으로 그 많은 경쟁자들을 제치고 더 좋은 개발자가 되길 바란다는 것은, 사실 염치가 없는 것 아닐까요?

표현이 과할 수 있지만, 그 만큼 여러분들께 확실하게 말씀드리고 싶어서 입니다.

Instagram @waterglasstoon

물론 1년만에 좋은 개발자가 될 수도 있습니다. 실제로 주변에도 그러한 개발자들이 있습니다.

하지만 과연 그분들이 일반적인 사람들과 같은 1년을 보냈을까요?

저 또한 그렇게 1년간 노력할 수 있을까를 고민해보면 선뜻 대답이 나오질 않습니다.

6. 생각보다 다양한 분야의 사람을 만난다.

흔히들 개발자는 코드를 작성하는 사람으로 알고 있죠. 조금 더 나아가면 시스템을 설계하고, 유지보수하는 업무도 생각해볼 수 있습니다.

그리고 그러한 과정들 속에서는 정말 다양한 분야의 사람들을 만나게 됩니다.

같은 개발자 동료들과 만나는 것은 물론이고, 서비스에 대한 기획자 분들과 운영팀과 만나는 경우도 많습니다.

Instagram @waterglasstoon

그리고 다양한 사람들은 만난다는 것은, 그 만큼 다양한 사람과 커뮤니케이션 해야한다는 것을 의미합니다.

당연히 많은 상황이 펼쳐지고, 누군가는 스트레스 받거나 힘든 상황들이 종종 오기도하죠.

단순히 개발자는 '내가 어떤 기능을 구현해야 한다.'가 전부가 아니라, 어떤 기능을 왜 구현해야하고, 구체적으로 어떻게 구현해야 하는지도 함께 확인해야하며 그러한 구현 속에서 가능한 부분과 일정 또는 상황상 불가능한 부분도 판단하여 관련자들에게 공유할 수 있어야합니다.

(위 사용된 모든 사진들의 출처는 Instagram @waterglasstoon입니다.)

글을 써내려 가다보니, 그리고 '단점'에 포커싱하여 적다보니 다소 공격적인 말들이 쓰여 부정적으로 받아들여지거나 다소 공감하지 못하는 개발자분들도 있을 것 같습니다.

저는 보다 많은 분들이 '개발'이라는 분야에 대해 재미를 느끼고, 다양한 도전을 해보며 함께 성장하기를 바랍니다.

그리고 제가 그분들께 더 많은 것들을 공유하고 더 많은 도움을 드리기를 원합니다.

그래서 다양한 멘토링과 다양한 활동들을 조금씩이나마 시간을 내어 지속하고 있습니다.

하지만, 가끔은 외부에 비춰지는 '개발자'의 좋아보이는 '조건'들에 혹하여 도전하였다가, 기대에 부풀고 결국 그 기대에 미치지 못해 실망하고 힘들어하시는 분들을 만나곤 합니다.

그런 분들과 이야기를 나누다 보면 '좋아보이기만 했던' 개발자들의 모습에 지쳐 힘들어 하는 경우가 정말 많습니다.

그래서 조금이나마 '개발자'를 꿈꾸는 분들이 한번쯤은 보다 부정적으로, 현실적인 상황을 고려하며 진지하게 고민해보셨으면 하는 마음에 글을 작성하였습니다.

'그래서 너는, 그 단점들을 다 극복했다고 자랑하는거야?'

아뇨, 저도 종종 많이 힘들어 합니다. 실제로 취준을 할때도 진지하게 많이 고민했었구요.

'이건 너무 특수한 상황이잖아.'

네, 특수한 상황이지만 여러분뿐만 아니라 제가 언제 어디서 마주칠지도 모르는 상황입니다.

'너가 뭐 얼마나 잘났길래, 이렇게 묘사해?'

아뇨, 제가 잘나서 말씀드리는 내용이 아닙니다. 우리가 마라톤을 달리기에 앞서 같이 신발끈을 다시 확인해보자는 이야기입니다.

여러분들도 꼭 한번쯤은, 여러분이 왜 개발자가 되려고하는지 고민해보는 시간을 가지면 좋을 것 같습니다.

위와 같은 단점들과 어려움에도 불구하고, 여러분들은 왜 개발자가 되려고 하시나요?

감사합니다.

[Kubernetes] 쿠버네티스 레이블(Labels)에 대한 9가지 모범 사례(번역)

Tigercow.Door — Sun, 27 Mar 2022 17:03:02 +0900

kubernetes

안녕하세요. 문범우입니다.

해당 내용은 아래 글에 대한 번역을 바탕으로 합니다.

https://www.replex.io/blog/9-best-practices-and-examples-for-working-with-kubernetes-labels

9 Best Practices and Examples for Working with Kubernetes Labels

Kubernetes labels allow DevOps teams to identify, select and operate on Kubernetes objects. In this blog post we outline 9 best practices for working with Kubernetes Labels and examples for Kubernetes label keys and values

www.replex.io

쿠버네티스 레이블(Labels)에 대한 9가지 모범 사례
(원제: 9 Best Practices and Examples for Working with Kubernetes Labels)

쿠버네티스 labels를 이용하면 Devops팀에서 쿠버네티스 객체(kubernets objects)를 식별하고 선택하고 운영할 수 있습니다.

쿠버네티스에는 멋진 내장기능이 많습니다. 레이블 또한 그 중 하나입니다. 쿠버네티스 레이블을 통해 Devops팀은 쿠버네티스 객체를 식별할 수 있고, 그룹으로 구성할 수 있습니다.

쿠버네티스 레이블에 대한 좋은 사용 사례(use-case) 중 하나는, 파드에 배치된 어플리케이션을 기반으로 그룹핑하는 것 입니다. 또한 환경이나 고객, 팀/소유자, 릴리즈 버전에 따라서 그룹화하는 다양한 레이블 규칙을 개발할 수 있습니다.

하지만 이것은 시작에 불과합니다. 쿠버네티스 레이블에는 더욱 다양한 기능이 포함되어 있습니다. 예를 들어, 쿠버네티스 레이블을 이용하여 수많은 리소스(resources)에 대해 필터링하여 kubectl을 통한 대량 작업을 수행할 수 있습니다. 또한 쿠버네티스 배포에는 레이블을 통해 쿠버네티스 관리하는 파드를 식별합니다. 이와 유사하게, 쿠버네티스 서비스와 레플리케이션(replication) 컨트롤러는 레이블을 이용하여 파드의 그룹(set)를 참조합니다. 권장되는 쿠버네티스 레이블들은 쿠버네티스 툴들 사이의 쿼리(querying)와 상호운용성(interoperability)를 지원합니다.

아래에서 쿠버네티스 레이블에 대한 몇 가지 모범사례를 살펴봅니다.

1. 구문에 대해 주의하라. (Beware of the Syntax)

당신이 쿠버네티스 레이블을 사용할때 올바를 구문(syntax)을 사용하는지 확인해야 합니다. 아래에는 레이블 구문에 대한 개요를 보여줍니다. 당신은 label key(label prefix + label name)와 label value, 총 3가지에 대해 고려해야 합니다.

Label Key
- Label Prefix
  - Label Prefix는 선택사항이다.
  - Label Prefix는 253자 이하이어야 한다.
  - Label Prefix는 DNS subdomain이어야 한다.
  - Label Prefix는 "."로 구분된 일련의 DNS subdomain일수도 있다.
  - Label Prefix는 "/"로 끝나야 한다.
- Label Name
  - Label Name은 필수사항이다.
  - Label Name은 최대 63자이다.
  - Label Name은 영문, 숫자로 구성되어야 한다.
  - Label Name은 "-", "_", "."을 포함할 수 있다.
  - Label Name의 시작과 끝은 영문 또는 숫자이어야 한다.
Label Value
- Lable Value는 최대 63자이다.
- Label Value는 영문, 숫자로 구성되어야 한다.
- Label Value는 "-", "_", "."을 포함할 수 있다.
- Label Value의 시작과 끝은 영문 또는 숫자이어야 한다.

아래 공식문서를 통해 보다 상세한 내용을 참조할 수 있습니다.

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

2. 레이블을 꼭 적용해라. (Label, Label, Label)

쿠버네티스 레이블에 대한 첫번째 규칙은 언제나 실제로 적용(do)하는 것입니다.

당신이 새로운 리소스를 생성할때, 그 다음 순서는 자연스럽게 쿠버네티스 레이블을 새롭게 생성하거나 추가(attach)하는 것이 되어야 합니다. 이미 운영중인 리소스에 대해서 레이블이 정상적으로 적용되었는지에 대한 정기적인 확인을 하는 것도 좋은 방법입니다.

물론 이와 같은 방법은 업무 속도를 저하시킬 수 있습니다. 하지만, 모든 것에 대해 레이블을 적용하는 것은 추후 이득을 볼 수 있습니다.

리소스에 대해 레이블을 적용하는 것은 쿠버네티스 운영환경에서 고통을 덜어줄 수 있습니다. 또한 레이블을 적용하면 쿠버네티스 개체들에 대한 대량 작업을 더 쉽게 만들어 줍니다. 이에 대한 예시로, 레이블 셀렉터(label selector)를 사용하여 쿠버네티스 배포 및 서비스 가동시 레이블을 기반으로 파드들을 선택할 수 있습니다.

kubectl을 이용한 몇가지 레이블 명령어는 다음과 같습니다.

우선 레이블 적용을 위한 pod는 다음과 같습니다.

# label-example.yaml
apiVersion: v1
kind: Pod
metadata:
 name: my-pod
 labels:
   environment: staging
   team: kube-team
spec:
 containers:
   - name: my-container
     image: "k8s.gcr.io/my-app:v0.1"
     resources:
       limits:
        cpu: 1

위의 yaml파일을 통해 생성된 파드의 레이블을 확인하기 위해서는 아래의 명령어를 사용합니다.

> kubectl get pod my-pod --show-labels

파드에 새로운 레이블을 추가하려면 아래의 명령어를 사용합니다.

> kubectl label pod my-pod versionID=ver0.9

파드의 레이블을 삭제하려면 다음의 명령어를 사용합니다. 삭제시에는 레이블 키(label key)를 통해 삭제합니다.

> kubectl label pod my-pod versionID-

파드의 기존 레이블을 변경(업데이트)하려면 다음의 명령어를 사용합니다.

> kubectl label --overwrite pods my-pod team=ops

3. 레이블 규정(conventions)에 대한 전사적인 규약(consensus)을 만들어라.
(Create company-wide consensus on labeling conventions)

레이블(labels)은 쿠버네이스 내부적으로도, Devops팀에게도 의미가 깊고 관련이 있기 때문에, 레이블 규칙에 대해서 합의하여 도출하는 것은 매우 중요합니다. 당신의 Devops팀과 함께 모여 쿠버네티스 리소스를 위한 표준 레이블 규칙에 대해 논의하세요. 또한 그 규칙이 팀과 조직을 넘어 전파될 수 있도록 해야 합니다.

4. 필수적인 레이블 리스트를 만들어라. (Create a list of required labels)

물론 어떤 사람들은 시대에 적응하지 못합니다.(Some people just do not get with the times.) 그들을 위해서 쿠버네티스 파드가 생성될 때 정의해야 하는 레이블의 리스트를 제안할 수 있습니다. 하나의 개체당 3-4개씩, 작게 시작합시다.

모든 쿠버네티스 개체에 대해 어플리케이션ID, 버전, 소유자, 환경(stage), 릴리즈버전을 필요로하는 Zalando의 예시를 이용하여 시작하는 것도 좋습니다.

https://kubernetes-on-aws.readthedocs.io/en/latest/user-guide/labels.html

당신은 파드 템플릿을 활용하여 필요한 레이블을 추가할 수 있습니다. 파드 템플릿은 쿠버네티스 컨트롤러에서 파드를 생성하기 위한 manifest파일입니다.

아래의 파드 템플릿은 application ID, version, stage, release, owner를 포함합니다.

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
 labels:
   application-ID: my-app
   version: version-nr
   stage: dev
   release: release-nr
   owner: team-kube

5. 더 광범위한 레이블 리스트를 만들어라. (Create a more extensive list of Kubernetes labels)

필수적인 레이블 리스트를 만들고 나서 멈추면 안됩니다. 당신이 쿠버네티스를 관리하고 운용하는 동안 지속적으로 발전시켜야 합니다. 쿠버네티스 개체에 더 많은 활용성(operability)과 컨텍스트(context)를 제공할 수 있는 더 광범위한 레이블을 지속해서 만들어야 합니다. 다음 내용은 쿠버네티스 예제에 포함되어 제공하는 모든 레이블 예시입니다. 이 중에서 선택하여 사용하는 것도 좋은 방법입니다.

Label Example Key	Description	Label Example Value
Application-ID/Application-name	The name of the application or its ID	my-awesome-app/app-nr-2345
Version-nr	The version number	ver-0.9
Owner	The team or individual the object belongs to	Team-kube/josh
Stage/Phase	The stage or phase	Dev, staging, QA, Canary, Production
Release-nr	The release number	release-nr-2.0.1
Tier	Which tier the app belongs to	front-end/back-end
Customer-facing	Is the resource part of an app that is costomer facing?	Yes/No
App-role	What roles does the app have	Cache/Web/Database/Auth
Project-ID	The associated project ID	my-project-276
Customer-ID	The customer ID for the resource	customer-id-29

6. 쿠버네티스에서 추천하는 레이블을 사용해라. (Use recommended Kubernetes labels)

쿠버네티스에서는 추천되는 레이블을 제공합니다. app.kubernetes.io 와 같은 레이블들은 당신이 생성하고 공유 접두사가 있는 모든 개체에 대해서 권장됩니다. 접두사는 권장되는 레이블이 사용자가 생성한 레이블과 혼동되지 않도록 합니다.

권장되는 레이블은 다음과 같습니다.

app.kubernetes.io/name
app.kubernetes.io/instance
app.kubernetes.io/version
app.kubernetes.io/component
app.kubernetes.io/part-of
app.kubernetes.io/managed-by

아래에는 권장되는 레이블을 활용한 예시 파드 템플릿 입니다.

apiVersion: v1
kind: Pod
metadata:
 labels:
    app.kubernetes.io/name: my-pod
    app.kubernetes.io/instance: Auth-1a
    app.kubernetes.io/version: “2.0.1”
    app.kubernetes.io/component: Auth
    app.kubernetes.io/part-of: my-app
    app.kubernetes.io/managed-by: helm

7. 미리 만들어지는 쿠버네티스 레이블을 확인해라. (Monitor pre-populated Kubernetes labels)

쿠버네티스는 노드에만 또는 노드와 볼륨에 모두 적용된, 미리 채워진 레이블 리스트를 제공합니다. 미리 채워진 레이블은 여러 가지 방법으로 사용할 수 있습니다. 예를 들어, 특정 인스턴스 유형으로 워크로드를 대상으로 하거나 다양한 클라우드 제공자 영역을 넘어 레플리케이션 컨트롤러 또는 서비스에 파드를 분산시킬 때 사용할 수 있습니다.

노드 관해 제공되는 레이블은 다음과 같습니다.

beta.kubernetes.io/arch
beta.kubernetes.io/os
- Value는 Linux와 같은 OS 타입으로 채워집니다.
beta.kubernetes.io/hostname
- Value는 hostname으로 채워집니다.
beta.kubernetes.io/instance-type
- Value는 t2.medium과 같이 클라우드 제공자에 따른 instance type이 채워집니다.

노드와 볼륨에 모두 제공되는 레이블은 다음과 같습니다.

failure-domain.beta.kubernetes.io/region
- Value는 eu-west-1과 같이 클라우드 제공자에 따른 region이 채워집니다.
failure-domain.beta.kubernetes.io/zone
- Value는 eb-west-1b와 같이 클라우드 제공자에 따른 zone이 채워집니다.

8. Kops에서 클라우드 레이블과 노드 레이블을 규정해라.
(Specify Cloudlabels and NodeLabels in Kops)

Kops는 고가용성(highly available) 쿠버네티스 클러스터를 배포하고 관리하기 위한 도구입니다. Devops팀은 Kops를 이용하여 CloudLables와 NodeLabels 두가지에 대해 지정할 수 있습니다. 두가지 타입의 라벨 모두 instanceGroup 레벨에서 지정됩니다. Kops의 instanceGroup은 AWS의 autoscailing group과 유사합니다.

InstanceGroup에 CloudLabels를 적용하면, 그것들은 instanceGroup의 일부인 모든 instance에 적용되며 AWS console에 AWS tag로 표시됩니다. 이를 이용하여 비용 할당 및 차지백(chargeback)을 수행할 수 있습니다.

비용 할당에 대해 권장되는 CloudLabels는 어플리케이션 이름(application name), 비용 센터(cost center), 스택(stack: test, prod), 소유자(owner, team), 고객(customer)와 프로젝트(project)가 있습니다. NodeLabels는 쿠버네티스 레이블(Labels)과 동일하며 쿠버네티스 노드에 적용됩니다.

9. 레이블과 어노테이션에 대한 구분을 지어라.
(Differentiate between Kubernetes labels vs annotations)

쿠버네티스 레이블과 어노테이션은 모두 쿠버네티스 개체에 대해 메타데이터를 추가하는 방법입니다. 그러나 둘의 유사점은 그것이 전부입니다. 쿠버네티스 레이블은 쿠버네티스 개체를 식별하고 선택하고 운영할 수 있도록 합니다. 반면에 어노테이션은 식별되지 않는 메타데이터이며 앞의 기능을 수행하지 않습니다.

어노테이션은 쿠버네티스 개체에 비식별 메타데이터를 추가합니다. 예시로, 디버깅 목적으로 해당 개체에 대해 책임을 가지고 있는 사람의 전화번호나 도구(tool) 정보를 담을 수 있습니다. 간단히 말해서, 어노테이션은 Devops팀(또는 다른 사용자)에게 유용하고 의미있는 컨텍스트(context)를 제공할 수 있는 모든 정보를 담을 수 있습니다.

결론 (Conclusion)

쿠버네티스 레이블은 쿠버네티스 객체 및 리소스를 식별하고 구성하는 좋은 방법입니다. 쿠버네티스 팀 리더와 IT매니저는 쿠버네티스 레이블 계획을 구성하고 구현하는 데 가장 적합합니다. 팀 전체에서 레이블 규칙을 따르게 함으로써 쿠버네티스 환경을 보다 잘 길들이고 무분별한 확산이 없도록 막을 수 있습니다. 레이블을 사용하면 쿠버네티스 개체에 대해 대량으로 작업하는 것이 보다 쉬워지므로, 레이블 지정 규칙을 준수하면 장기적으로 팀의 효율성, 생산성 또한 증가할 수 있습니다.

해당 내용은 아래 글에 대한 번역을 바탕으로 합니다.

https://www.replex.io/blog/9-best-practices-and-examples-for-working-with-kubernetes-labels

코틀린[Kotlin] #04_함수 정의와 호출

Tigercow.Door — Wed, 30 Dec 2020 00:24:20 +0900

안녕하세요. 문범우입니다.

이번 포스팅에서는 코틀린에서의 함수 정의와 함수 호출을 중심으로 알아보도록 하겠습니다.

관련된 코드의 내용은 아래 주소에서 확인할 수 있습니다.

https://github.com/doorBW/kotlin-study

1. 컬렉션

코틀린에서 알아보고자 했던 함수에 대해 확인하기 이전에 컬렉션을 만드는 방법부터 확인해보고 넘어가자.

아래와 같이 컬렉션을 만들고, 만들어진 컬렉션 객체가 어떤 클래스에 속하는지 함께 확인해보자.

1
2
3
4
5
6
7
8
9
10
11
fun main(){
    val set = hashSetOf(1,7,53)
    println(set.javaClass)
    // class java.util.HashSet
    val list = arrayListOf(1,7,53)
    println(list.javaClass)
    // class java.util.ArrayList
    val map = hashMapOf(1 to "one", 7 to "seven", 53 to "fifty-three")
    println(map.javaClass)
    // class java.util.HashMap
}
Colored by Color Scripter
cs

우선 코틀린에서는 hashSetOf, arrayListOf, hashMapOf 등의 함수로 집합이나 리스트 등을 만들 수 있다.

이때, hashMapOf에서 사용된 to에 대해서는 추후 다루도록 한다.

객체에 대해서 어떤 클래스에 속하는지 확인한 결과 기존 자바 컬렉션을 나타내고 있다.

이는 코틀린에서 자체적인 컬렉션을 제공하지 않는다는 의미와 같으며, 자바에서의 컬렉션 객체와 동일한 객체임을 알 수 있다.

하지만 코틀린의 컬렉션에서는 자바의 컬렉션 보다 많은 기능을 제공한다.

예를 들어 리스트의 마지막 원소를 가져오는 last() 함수나 최대 값을 반환하는 max() 등의 함수가 있다.

우리는 앞으로 코틀린에서 자바 클래스에 없는 메소드를 어디서 정의하는지, 그리고 어떻게 동작하는지에 대해서 함께 살펴볼 것이다.

2. 함수 선언

우선 함수를 선언하는 내용부터 살펴보자.

이를 위해, 리스트를 괄호로 감싸고 각 원소를 세미콜론으로 구분하여 반환하는 함수를 다음과 같이 만들어보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
import java.lang.StringBuilder
 
fun <T> joinToString(
    collection: Collection<T>,
    separator: String,
    prefix: String,
    postfix: String
): String{
    val result = StringBuilder(prefix)
    for((index, element) in collection.withIndex()){
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}
 
fun main(){
    val list = listOf(1,2,3,4)
    println(joinToString(list, ";", "(", ")"))
    // (1;2;3;4)
}
Colored by Color Scripter
cs

위에서 선언한 joinToString 함수는 4개의 인자를 받는다.

컬렉션과 각 원소 사이에 추가할 separator 그리고 prefix와 postfix. 선언한 함수를 확인하기 위해 1,2,3,4 총 4개의 원소를 가지는 리스트를 만들어 함수의 작동을 확인해보니 의도와 동일하게 (1;2;3;4) 가 출력됨을 확인할 수 있다.

이제 위에서 선언한 joinToString 함수를 기반으로 선언에 대해 추가적인 내용을 알아보도록 하자.

2-1. 인자에 이름 붙이기

함수를 호출할 때, 선언시 사용했던 인자의 이름을 활용할 수 있다. 실제로 위 코드의 20번라인처럼 함수를 호출 할 때에는 어떠한 것이 separator이고, 무엇이 prefix인지, 무엇이 postfix인지 혼동이 될 수 있다.

이를 해결하기 위해 다음과 같이 함수 호출시에 인자의 이름을 활용한다.

1
2
3
4
5
fun main(){
    val list = listOf(1,2,3,4)
    println(joinToString(list, separator = ";", prefix = "(", postfix = ")"))
    // (1;2;3;4)
}
Colored by Color Scripter
cs

2-2. 디폴트 값 지정하기

코틀린에서는 함수 선언 시점에 특정 인자에 대한 디폴트 값을 지정할 수 있다.

이를 통해 디폴트 값을 가지는 인자 때문에 함수를 오버로딩(overloading)하는 경우를 방지할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
import java.lang.StringBuilder
 
fun <T> joinToString(
    collection: Collection<T>,
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""
): String{
    val result = StringBuilder(prefix)
    for((index, element) in collection.withIndex()){
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}
 
fun main(){
    val list = listOf(1,2,3,4)
    println(joinToString(list, separator = ";", prefix = "(", postfix = ")"))
    // (1;2;3;4)
    println(joinToString(list))
    // 1, 2, 3, 4
    println(joinToString(list, separator = ";"))
    // 1;2;3;4
}
Colored by Color Scripter
cs

2-3. 최상위 함수

자바에서는 모든 메소드가 클래스 내부에 작성되어야 한다. 하지만 현업에서는 특정 클래스에 포함시키기 어려운 함수들이 존재하고 일반적으로는 Util의 성격을 가지는 함수들이 그러하다.

이 때문에 ~Util.java 와 같은 형태를 가지는 클래스들이 존재한다.

하지만 코틀린에서는 함수를 직접 소스파일의 최상위 수준, 다른 모든 클래스의 바깥에 위치시키면 된다. 최상위에 선언된 함수들에 대해서는 그 함수가 정의된 패키지를 임포트하여 사용될 수 있다.

앞에서 만든 joinToString 함수를 strings 패키지안에 join.kt라는 코틀린 파일로 넣고 자바에서 호출해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
import ch3.strings.JoinKt;
 
import java.util.ArrayList;
 
public class Test {
    public static void main(String[] args){
        final ArrayList list = new ArrayList<String>();
        list.add("1");
        list.add("2");
        list.add("3");
        list.add("4");
        System.out.println(JoinKt.joinToString(list, ", ", "[", "]"));
        // [1, 2, 3, 4]
    }
}
Colored by Color Scripter
cs

위의 코드와 같이 자바에서 코틀린 파일을 import 하여 사용하였다.

실제로 코틀린 파일의 이름은 join.kt이지만 이는 컴파일러가 자동으로 JoinKt라는 class로 컴파일하여 내부에 있는 최상위 함수를 사용할 수 있게 한다.

이때 만약 클래스 이름을 바꾸고 싶다면, @JvmName 어노테이션을 다음과 같이 활용하면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
@file:JvmName("StringFunctions")
package ch3.strings
 
import java.lang.StringBuilder
 
fun <T> joinToString(
    collection: Collection<T>,
    separator: String = ", ",
    prefix: String = "",
    postfix: String = ""
): String{
    val result = StringBuilder(prefix)
    for((index, element) in collection.withIndex()){
        if (index > 0) result.append(separator)
        result.append(element)
    }
    result.append(postfix)
    return result.toString()
}
 
fun main(){
    val list = listOf(1,2,3,4)
    println(joinToString(list, separator = ";", prefix = "(", postfix = ")"))
    // (1;2;3;4)
    println(joinToString(list))
    // 1, 2, 3, 4
    println(joinToString(list, separator = ";"))
    // 1;2;3;4
}
Colored by Color Scripter
cs

이렇게 되면 기존의 JoinKt라는 이름으로 컴파일 되지 않고, 우리가 지정한 StringFunctions라는 이름의 클래스로 컴파일 되는 것을 확인할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// import ch3.strings.JoinKt;
import ch3.strings.StringFunctions;
 
import java.util.ArrayList;
 
public class Test {
    public static void main(String[] args){
        final ArrayList list = new ArrayList<String>();
        list.add("1");
        list.add("2");
        list.add("3");
        list.add("4");
        // System.out.println(JoinKt.joinToString(list, ", ", "[", "]"));
        System.out.println(StringFunctions.joinToString(list, ", ", "[", "]"));
        // [1, 2, 3, 4]
    }
}
 
Colored by Color Scripter
cs

3. 확장 함수와 확장 프로퍼티

우선 확장 함수의 개념은 단순하다. 확장 함수(Extension function)은 어떤 클래스의 멤버 메소드인 것 처럼 호출할 수 있지만 클래스의 내부에서가 아닌, 밖에서 선언된 함수이다.

아래와 같이 문자열의 마지막 문자를 반환하는 확장 함수를 만들어보자.

1
fun String.lastChar() : Char = this.get(this.length - 1)
cs

위와 같이 확장 함수를 만들 때에는, 함수의 이름 앞에 해당 함수가 확장할 클래스의 이름을 붙여주면 된다. 위의 lastChar() 함수는 String 클래스를 확장하고 있다.

이때, 클래스 이름을 수신 객체 타입(receiver type)이라고 부르며, 확장 함수가 호출되는 대상이 되는 값(객체)을 수신 객체(receiver object)라고 부른다.

위의 lastChar() 함수의 경우, String이 수신 객체 타입이고 수신 객체는 this로 받고 있다.

물론 이러한 확장 함수를 호출하는 구문은 다른 일반 클래스 멤버를 호출하는 방법과 동일하다.

1
2
3
4
5
6
fun String.lastChar() : Char = this.get(this.length - 1)
 
fun main(){
    println("Kotlin".lastChar())
    // n
}
Colored by Color Scripter
cs

위의 예제에서의 수신 객체 타입은 String이고 수신 객체는 "Kotlin" 이다.

확장 함수도 일반 메소드에서와 같이 this를 생략할 수 있다.

일반 메서드와 다른 점은, 확장 함수에서는 클래스 내부에서만 사용할 수 있는 private, protected 멤버를 사용할 수 없다. 이로 인해 확장 함수가 기존 클래스의 캡슐화는 깨지 않는다.

3-1. 확장 함수 임포트

확장 함수를 정의 했다고 해서 모든 범위에서 그 함수를 사용할 수 있는 것은 아니다.

확장 함수를 사용하기 위해서는 그 함수를 임포트해야 한다. 물론 일반적인 클래스를 임포트할 때와 동일한 구문을 사용하여 개별 함수를 임포트할 수 있다.

또한 아래와 같이 as 키워드를 사용하여 다른 이름으로 호출할 수 있다.

1
2
3
import strings.lastChar as last
 
val c = "Kotlin".last()
cs

3-2. 자바에서 확장 함수 호출

내부적으로 확장 함수는, 수신 객체를 첫 번째 인자로 받는 정적 메소드이다.

때문에 자바에서 코틀린의 확장함수를 호출하기 위해서는 정적 메소드를 호출하면서 첫 번째 인자로 수신 객체를 넘기기만 하면 된다. 예를 들어, 확장 함수를 StringUtil.kt 파일에 정의 했다면 다음과 같이 자바에서 호출할 수 있다.

1
char c = StringUtilKt.lastChar("Kotlin");
cs

3-3. 확장 함수의 오버라이드

우선 결론부터 이야기하면, 코틀린에서의 확장 함수는 오버라이드 되지 않는다.

이를 확인 하기 위해 아래와 같이 View 클래스와 Button 클래스를 선언하고, click() 함수를 Button에서 오버라이드 해보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
open class View{
    open fun click() = println("View clicked!")
}
 
class Button: View() {
    override fun click() = println("Button clicked!")
}
 
fun main(){
    val view: View = Button()
    view.click()
    // Button clicked!
}
Colored by Color Scripter
cs

위와 같이 view에 저장된 값의 실제 타입이 Button이기 때문에 오버라이드 된 Button의 click함수가 실행된다.

하지만 확장 함수는 클래스의 일부가 아니다.

실제로 확장 함수를 호출할 때 수신객체로 지정한 변수의 정적 타입에 의해서 어떤 확장 함수가 호출될지 결정된다. 즉, 그 변수에 저장된 객체의 동적인 타입에 의해 확장 함수가 결정되지 않는다.

확장 함수를 첫 번째 인자가 수신 객체인 정적 자바 메소드로 컴파일 한다는 사실을 생각해두어야 한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
open class View{
    open fun click() = println("View clicked!")
}
 
class Button: View() {
    override fun click() = println("Button clicked!")
}
 
fun View.showOff() = println("View showOff")
fun Button.showOff() = println("Button showOff")
 
fun main(){
    val view: View = Button()
    view.click()
    // Button clicked!
    view.showOff()
    // View showOff
}
Colored by Color Scripter
cs

3-4. 확장 프로퍼티

확장 함수의 경우와 마찬가지로 확장 프로퍼티도 일반적인 프로퍼티와 같다. 단지 수신 객체 클래스가 추가되었을 뿐이다.

하지만 기본 게터 구현을 제공할 수 없기 때문에 최소한 게터는 꼭 정의를 해주어야 한다.

1
2
3
4
5
6
7
val String.lastChar: Char
    get() = this.get(this.length - 1)
 
fun main() {
    println("Kotlin".lastChar)
    // n
}
Colored by Color Scripter
cs

4. 컬렉션 처리

마지막으로는 컬렉션에 대해 처리할 수 있는 몇가지 코틀린 표준 라이브러리 함수를 알아보자.

4-1. 가변 길이 인자

1
2
3
4
5
6
7
8
9
10
fun test(vararg values: String){
    for(s in values) println(s)
}
 
fun main() {
    test("1", "2", "3")
    // 1
    // 2
    // 3
}
Colored by Color Scripter
cs

4-2. 중위 호출

처음에, 맵을 만들었던 코드를 생각해보자.

1
val map = mapOf(1 to "one", 7 to "seven", 53 to "fifty-three")
cs

여기서 사용된 to는 코틀린의 키워드가 아니다.

이 코드는 중위 호출(infix call)이라는 특별한 방식으로 to라는 일반 메소드를 호출한 것이다.

즉, 아래 두줄의 코드는 의미가 같다.

1
2
1.to("one") // 일반적인 방식의 메소드 호출
1 to "one" // 중위 호출 방식으로 메소드 호출
cs

중위 호출 시에는 수신 객체와 유일한 메소드 인자 사이에 메소드 이름을 넣으면 된다.

인자가 하나뿐인 일반 메소드나 인자가 하나뿐인 확장 함수에 대해서 중위 호출을 사용할 수 있다. 인자가 하나뿐인 함수에 대해 중위 호출 사용을 허용시키려면 함수 선언 앞에 infix 변경자를 추가하면 된다.

참고 서적 및 링크

* [Kotlin in Action] - 드미트리 제메로프/스베트라나 이사코바 지음, 오현석 옮김, 에이콘 출판사

코틀린[Kotlin] #03_코틀린 기초(when, 스마트 캐스트, 반복문, in, 예외처리)

Tigercow.Door — Mon, 7 Dec 2020 00:35:46 +0900

안녕하세요. 문범우입니다.
오늘은 지난번 포스팅에 이어서, 코틀린의 기초에 대해서 알아봅니다.
보다 자세하게는 when, 스마트캐스트, 반복문, in, 예외처리에 대해서 학습하도록 하겠습니다.
관련된 코드의 내용은 아래 주소에서 확인하실 수 있습니다.
https://github.com/doorBW/kotlin-study

1. when

먼저 지난 시간에 구성했던 enum class, Color를 이용하여 when에 관한 함수를 만들어보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
enum class Color(
    val r: Int, val g: Int, val b: Int
) {
    RED(255, 0, 0), ORANGE(255, 165, 0),
    YELLOW(255, 255, 0), GREEN(0, 255, 0), BLUE(0, 0, 255),
    INDIGO(75, 0, 130), VIOLET(238, 130, 238); // need semicolon
 
    fun rgb() = (r * 256 + g) * 256 + b
}
 
fun getMnemonic(color: Color) =
    when (color) {
        Color.RED -> "Richard"
        Color.ORANGE -> "Of"
        Color.YELLOW -> "York"
        Color.GREEN -> "Gave"
        Color.BLUE -> "Battle"
        Color.INDIGO -> "In"
        Color.VIOLET -> "Vain"
    }
 
fun main(args: Array<String>){
    println(getMnemonic(Color.BLUE))
    // Battle
}
Colored by Color Scripter
cs

위에서 만든 getMnemonic 함수를 살펴보자. 우선 등호를 이용하여 식이 본문인 함수로 만들었다. 즉 when 또한 식이라는 것을 알 수 있다.
when 뒤에는 소괄호를 이용하여 color 값을 받는다. 그리고 해당 color가 enum상수와 동일한 것을 찾아서 화살표를 통해 반환할 값을 지정하고 있다.

또한, 하나의 분기(조건) 안에서 여러 값을 매치할 수 있다. 이러한 경우 다음의 코드와 같이 각 분기를 콤마(,)로 연결해주면 된다.

1
2
3
4
5
6
7
8
9
10
11
fun getWarmth(color: Color) =
    when (color) {
        Color.RED, Color.ORANGE, Color.YELLOW -> "warm"
        Color.GREEN -> "neutral"
        Color.BLUE, Color.INDIGO, Color.VIOLET -> "cold"
    }
 
fun main(args: Array<String>){
    println(getWarmth(Color.ORANGE))
    // warm
}
Colored by Color Scripter
cs

물론 조건에 해당 하는 값이 없는 경우를 위해 else를 두어 처리할 수 있다.

또한 위와 같이 when 뒤에 인자를 붙이는 것이 필수는 아니다. 단순히 when 이후에 중괄호로 시작하여 바로 조건문을 통해 케이스 분류를 할 수 있다.

2. 스마트 캐스트

코틀린에서 스마트 캐스트는 타입 검사와 타입 캐스트를 조합하여 진행된다. 즉, 타입 검사 이후 별도의 타입 캐스팅이 필요없다는 의미이다.

이를 확인하기 위해 다음과 같은 코드를 작성한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
interface Expr
class Num(val value: Int) : Expr
class Sum(val left: Expr, val right: Expr) : Expr
 
fun eval(e: Expr): Int {
    if (e is Num) { // smart casting
        val n = e as Num
        return n.value
    }
    if (e is Sum) { // smart casting
        return eval(e.right) + eval(e.left)
    }
    throw IllegalArgumentException("Unknown expression")
}
 
fun main(args: Array<String>){
    println(eval(Sum(Sum(Num(1), Num(2)), Num(4))))
    // 7
}
Colored by Color Scripter
cs

Expr 이라는 인터페이스를 선언하고, 이를 상속받는 Num class와 Sum class를 생성하였다.
이후 eval이라는 함수는 Expr 타입의 객체를 파라미터로 받아서 이때 Num 객체라면 해당 객체의 value를 반환하고, Sum 객체라면 left와 right객체를 다시 eval함수로 넘긴다음 반환 값을 더한다.
오히려 말로 설명하는 것이 복잡할 수 있으니 코드를 살펴보면 이해가 빠르다.
이때, 사용된 if문, 6번 라인과 10번 라인을 보면 is 라는 키워드를 이용해 인자의 타입을 검사하며 바로 캐스팅하는 스마트 캐스트를 볼 수 있다.
코드상에서는 설명을 위해 7번라인에 타입 캐스트를 하는 코드가 있다. e라는 값을 Num 객체로 캐스트 하여 변수 n으로 받는 코드이다. 하지만 이와 다르게 Sum인지를 확인하는 if문 내부에는 그러한 코드가 없다. 7번 라인과 같이 타입을 캐스팅하는 역할을 is 키워드를 통해 타입 검사와 타입 캐스팅을 동시에 처리하기 때문이다.

위의 코드를 앞에서 배운 when을 이용해 다음과 같이 변경시킬 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
interface Expr
class Num(val value: Int) : Expr
class Sum(val left: Expr, val right: Expr) : Expr
 
fun eval(e: Expr): Int =
    when (e) {
        is Num -> e.value
        is Sum -> eval(e.left) + eval(e.right)
        else -> throw IllegalArgumentException("Unknown expression")
    }
 
fun main(args: Array<String>){
    println(eval(Sum(Sum(Num(1), Num(2)), Num(4))))
    // 7
}
Colored by Color Scripter
cs

3. 반복문

코틀린에서의 반복문은 자바와 매우 유사하다.

실제로 반복문 while은 다음과 같이 자바와 동일하므로 따로 다루지 않겠다.

1
2
3
4
5
6
7
    while(조건) {
        /* ... */
    }
 
    do {
        /* ... */
    } while(조건)
cs

하지만 for 루프에서는 자바와 약간의 차이점이 있다. 오히려 자바에서 사용되는 for-each문이 코틀린의 기본 for와 비슷한 형태를 띄고있다고 생각하면 좋다.
이때 코틀린에서 사용되는 연산자가 등장한다. 범위(range)를 표현하는 연산자로써 시작하는 숫자와 끝나는 숫자 사이에 .. 을 붙여주면 된다. 다음은 해당 연산자를 이용하여 1부터 10까지 출력하는 예제이다.

1
2
3
4
5
6
7
8
9
fun main(args: Array<String>){
    for(i in 1..10){
        println(i)
        // 1
        // 2
        // ..
        // 10
    }
}
cs

위의 코드와 같이 범위를 표현할 때에는 .. 연산자를 이용한다. 그리고 for문을 이용할 때에는 받아서 처리하는 값 뒤에 in 키워드를 붙이고 그 뒤에 범위값이나 리스트 요소를 배치하여 사용한다.

헌데 만약 범위를 이용하여 표현할 때, 값이 1씩 증가하는게 아니라 2씩 증가하는 for문을 작성하고 싶다면 어떻게 할까? 아니면 값이 감소하는 for문은?
증가하는 값에 대한 정보는 추가로 step을 통해 표현하고, 값이 감소되는 것은 downTo를 이용하여 다음과 같이 표현한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
fun main(args: Array<String>){
    for(i in 1..100 step 3){
        println(i)
        // 1
        // 4
        // ..
        // 97
        // 100
    }
 
    for(i in 100 downTo 1){
        println(i)
        // 100
        // 99
        // ..
        // 1
    }
}
cs

4. In

in 연산자는 for문에서 사용된 것과 다르게 어떠한 값이 범위에 속하는지 검사하는 용도로 사용될 수 있다. 반대로 !in 을 사용하여 어떠한 값이 범위에 속하지 않는지도 검사할 수 있다.

1
2
3
4
5
6
7
fun main(args: Array<String>){
    fun isLetter(c: Char) = c in 'a'..'z' || c in 'A'..'Z'
    println(isLetter('k'))
    // true
    println(isLetter('0'))
    // false
}
Colored by Color Scripter
cs

위와 같이 간단한 isLetter 함수를 만들어서 활용해 보았다.

또한 우리가 앞에서 학습한 when과 함께 이용하는 것도 가능하다.

1
2
3
4
5
6
7
8
9
10
11
12
fun recognize(c: Char) = when(c){
    in '0'..'9' -> "It's a digit!"
    in 'a'..'z', in 'A'..'Z'-> "It's a letter!"
    else -> "I don't know."
}
 
fun main(args: Array<String>){
    println(recognize('8'))
    // It's a digit!
    println(recognize('t'))
    // It's a letter!
}
Colored by Color Scripter
cs

5. 예외 처리

코틀린의 예외처리 또한 자바와 비슷하다. 함수에서 오류가 발생하면 해당 예외를 throw할 수 있다. 그리고 함수를 호출하는 부분에서 해당 예외를 잡아서 처리할 수 있다.
물론 이전과 같이 예외 인스턴스를 만들때 new 키워드를 붙이지 않아도 된다. 또한 한가지 자바와 다른 점은, 함수가 던질 수 있는 예외를 직접 명시하지 않아도 되는 점이다.
자바에서는 체크 예외를 명시적으로 처리했어야 했다. 어떤 함수 안에서 발생될 수 있는 예외에 대해서 catch로 처리하거나 처리하지 않은 예외는 함수의 끝에 throws로 명시해야 했지만, 코틀린은 그렇지 않다.
코틀린에서의 예외 처리는 다음 코드와 같다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
fun readNumber (reader: String){
    val number = try {
        Integer.parseInt(reader)
    } catch (e: NumberFormatException){
        null
    }finally {
        println("readNumber func end.")
    }
    println(number)
}
 
fun main(args: Array<String>){
    readNumber("5")
    // readNumber func end.
    // 5
    readNumber("t")
    // readNumber func end.
    // null
}
Colored by Color Scripter
cs

- Quiz

Q1. 코틀린에서 스마트 캐스트란 무엇이고 어떤 키워드를 사용하나?

Q2. 범위(range)를 나타내는 연산자는?

참고 서적 및 링크

* [Kotlin in Action] - 드미트리 제메로프/스베트라나 이사코바 지음, 오현석 옮김, 에이콘 출판사

코틀린[Kotlin] #02_코틀린 기초(함수,클래스,프로퍼티,enum)

Tigercow.Door — Sat, 5 Dec 2020 23:43:19 +0900

안녕하세요. 문범우입니다.

이번 포스팅에서는 코틀린의 기초에 대해서 알아보도록 합니다.

구체적으로는 함수, 변수, 클래스, 프로퍼티, enum에 대해서 학습합니다.

관련된 내용의 코드는 아래 주소에서 확인하실 수 있습니다.

https://github.com/doorBW/kotlin-study

1. 함수

우선 어느 프로그래밍 언어에서나 시작해보는 "Hello, world!"를 출력해보자.

1
2
3
fun main(args: Array<String>){
    println("Hello, world!")
}
cs

코틀린에서는 위와 같이 간단한 코드로 문자열 출력을 할 수 있다. 본격적으로 코틀린에 대해서 알아보기 이전에 위 코드에서 파악할 수 있는 몇가지를 살펴보자.

- 함수를 최상위 수준에 정의가 가능하다. 즉, 꼭 클래스 안에 함수가 존재해야 하는게 아니다.

- 함수를 선언할 때에는 fun 키워드를 이용한다.

- 파라미터 이름 뒤에 그 타입을 서술한다. 변수 선언시에도 동일하다.

- 표준 자바 라이브러리 함수를 간결하게 사용할 수 있는 래퍼(wrapper)가 존재한다.(System.out.println -> println)

- 코드의 끝에 세미콜론을 붙이지 않는다.

위의 코드와 같은 경우에는 문자열 출력만 진행하고 따로 반환 값은 없는 함수를 나타내고 있다.

그럼 함수의 반환 값이 존재할 때, 반환 타입은 어디에 나타내야 할까?

다음의 함수는 두 숫자를 입력 받고, 그 중 큰 숫자를 반환하는 함수다.

1
2
3
4
5
6
7
8
fun max(n1: Int, n2: Int): Int {
    return if (n1 > n2) n1 else n2
}
 
fun main(args: Array<String>) {
    println(max(7, 5))
    // 7
}
Colored by Color Scripter
cs

위의 max 함수를 확인해보면 main 함수와 달리 파라미터와 중괄호 사이에 반환 값 타입을 확인할 수 있다.

즉, 코틀린에서는 다음과 같은 함수의 틀을 가진다.

fun <함수이름>(파라미터): <반환 값 타입> {
함수내용
}

헌데, max 함수의 반환 내용을 살펴보면 if 문이 값을 만들어 내고 있다.

코틀린에서는 if가 값을 만들어 내지 못하는 문(statement)이 아니라 식(expression)이다. 자바에서는 if가 문으로 사용되기 때문에 코틀린과의 다른점 중 하나이다.

추후 하나씩 알아보면서 설명하겠지만, 자바에서는 모든 제어구조가 문이지만, 코틀린에서는 루프구조를 제외한 대부분이 식으로 되어있다.

이번에는 max 함수에 대해 한번 더 살펴보자.

max함수의 본문은 if식 하나로 이루어져 있다. 이러한 경우 함수에서 중괄호를 없애고, return을 없애면서 등호(=)하나로만 표현할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
fun max(n1: Int, n2: Int): Int {
    return if (n1 > n2) n1 else n2
}
 
fun maxShort(n1: Int, n2: Int): Int = if (n1 > n2) n1 else n2
 
fun main(args: Array<String>) {
    println(max(7, 5))
    // 7
    println(maxShort(7, 5))
    // 7
}
Colored by Color Scripter
cs

위와 같이 maxShort함수는 기존 max함수와 달리 중괄호를 제거하고 등호를 이용하여 '식'을 본문으로 만든 함수이다. 이와 같은 함수를, '식이 본문인 함수'라고 하며 기존의 max함수는 '블록이 본문인 함수'라고 한다.

헌데 식이 본문인 함수에서는 반환 타입을 다음과 같이 생략할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
fun max(n1: Int, n2: Int): Int {
    return if (n1 > n2) n1 else n2
}
 
fun maxShort(n1: Int, n2: Int): Int = if (n1 > n2) n1 else n2
 
fun maxShortMore(n1: Int, n2: Int) =  if (n1 > n2) n1 else n2
 
fun main(args: Array<String>) {
    println(max(7, 5))
    // 7
    println(maxShort(7, 5))
    // 7
    println(maxShortMore(7, 5))
    // 7
}
Colored by Color Scripter
cs

식이 본문인 함수에서는 굳이 프로그래머가 반환 타입을 지정하지 않아도 코틀린의 '타입 추론'에 의해 컴파일러가 타입을 체크할 수 있게 된다.

2. 변수

1
2
3
4
5
6
    var number1: Int = 1
    var number2 = 2
    var answer1 = "정답1 입니다."
    var answer2: String
    answer2 = "정답2 입니다."
    var answer3 // error
cs

변수 선언과 초기화는 위와 같이 표현된다.

선언과 초기화를 동시에 진행하는 경우, number1과 같이 타입까지 지정해주거나, number2와 answer1과 같이 타입을 생략할 수 있다.

하지만, 선언과 초기화를 다른 시점에 진행하는 경우에는 선언 시점에 꼭 타입을 지정해주어야 한다.

또한 코틀린에서는 '변경 가능한 변수'와 '변경 불가능한 변수' 2가지가 존재한다.

1
2
3
4
    var mutable_number = 3
    val immutable_number = 3
    mutable_number = 5
    immutable_number = 5 // Val cannot be reassigned
cs

코틀린에서 변수를 선언하는 키워드는 'var'와 'val' 두가지가 있다.

이때, 'var'는 변경 가능한 변수로, 자바의 일반적인 변수와 같다.

하지만 'val'는 변경 불가능한 변수로, 자바에서 final 변수와 같다.

물론, val 변수의 경우참조 자체는 변경 불가이더라도 그 참조 값이 가리키는 객체의 내부값은 변경될 수 있다.

또한, var 변수의 경우 값이 변경 될 수는 있지만 타입은 고정되기 때문에, 다른 타입의 값으로 변경하려고 하면 컴파일 오류가 발생한다.

3. 문자열 템플릿

이번에 알아볼 내용은 '문자열 템플릿'이다.

println 을 통해 문자열 출력시, 변수 값을 추가하는 예제를 통해 간단하게 확인해보자.

1
2
3
4
    val helloStr = "Hello"
    println("$helloStr kotlin!")
    println("${helloStr} kotlin!")
    // Hello kotlin!
cs

위와 같이 코틀린에서는 $ 기호를 이용하여 변수를 문자열 안에 사용할 수 있다.

이때, 중괄호를 이용하여 변수를 감싸는 것이 더 좋다.

추가로 중괄호를 사용할 때에는 변수말고 식 자체도 넣을 수 있다.

1
2
3
4
5
    val calcNum = 3 + 5
    println("calcNum: ${calcNum}")
    // 8
    println("calcNum: ${3 + 5 + 5}")
    // 13
cs

앞에서 if는 코틀린에서 문이 아니라 식이라고 했다. 그럼 문자열 템플릿을 이용해 다음과 같이 바로 값을 확인할 수 있다.

1
2
    println("Max number in 5 or 3, is ${if (5 > 3) 5 else 3}")
    // 5
Colored by Color Scripter
cs

4. 클래스와 프로퍼티

우선 자바에서의 간단한 클래스를 살펴보자.

1
2
3
4
5
6
7
8
9
10
11
public class Person {
    private final String name;
    
    public Person(String name) {
        this.name = name;
    }
    
    public String getName() {
        return name;
    }
}
Colored by Color Scripter
cs

위의 Person클래스는 Java에서 흔하게 볼 수 있는 형태이다. 위와 같은 클래스를 코틀린에서는 다음과 같이 작성한다.

1
class Person(val name: String)
cs

매우 간단하다.

이렇게 짧은 한줄의 코드가 어떤 의미를 가지고 있는지 잠깐 살펴보자.

우선 코틀린에서 기본 가시성은 public이다. 따라서 class 앞에 public을 생략하였다.

또한 자바 코드를 보면 name 프로퍼티는 setter가 없기에 변경 불가능한 프로퍼티임을 암시할 수 있다. 이때 코틀린에서는 프로퍼티를 정의하며 val와 var의 구분으로 읽기 전용 프로퍼티인지, 쓸 수 있는 프로퍼티인지를 나타낼 수 있다.

그럼 위와 같이 정의한 Person 클래스에 새로운 프로퍼티를 하나 추가한 후 사용해보도록 하자.

1
2
3
4
5
6
7
8
9
class Person(val name: String, var isMarried: Boolean)
 
fun main(args: Array<String>) {
    val person = Person("Door", false)
    println(person.name)
    // Door
    println(person.isMarried)
    // false
}
Colored by Color Scripter
cs

기존의 Person 클래스에 변경 가능한, isMarried 프로퍼티를 추가하였고, 이후 생성하고 해당 객체에 대한 값을 출력해보았다.

4번 라인에서 Person 객체를 생성 할 때, 자바와는 다르게 new 키워드를 사용하지 않은 걸 볼 수 있다.

또한 5번과 7번 라인에서 객체의 프로퍼티 이름에 직접 접근하면 그에 대한 게터를 코틀린이 호출하는 것을 알 수 있다.

또한 아래와 같이 프로퍼티 게터를 직접 선언할 수도 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
class Rectangle(val height: Int, val width: Int) {
    val isSquare: Boolean
        get() {
            return height == width
        }
}
 
fun main(args: Array<String>) {
    val rectangle1 = Rectangle(5,4)
    println(rectangle1.isSquare)
    // false
    val rectangle2 = Rectangle(5,5)
    println(rectangle2.isSquare)
    // true
}
Colored by Color Scripter
cs

5. Enum 클래스

마지막으로 enum 클래스에 대해서 알아보자.

1
2
3
enum class Color {
    RED, ORANGE, YELLOW, GREEN, BLUE, INDIGO, VIOLET
}
Colored by Color Scripter
cs

위의 코드는 코틀린에서 enum class인 Color 정의한 코드이다. 자바와는 달리 class 앞에 enum을 사용해야 한다.

자바와 동일하게, 코틀린에서도 enum은 단순히 값만 열거하지는 않는다. enum 클래스 안에 프로퍼티나 메소드를 다음과 같이 정의할 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
enum class Color(
    val r: Int, val g: Int, val b: Int
) {
    RED(255, 0, 0), ORANGE(255, 165, 0),
    YELLOW(255, 255, 0), GREEN(0, 255, 0), BLUE(0, 0, 255),
    INDIGO(75, 0, 130), VIOLET(238, 130, 238); // need semicolon
 
    fun rgb() = (r * 256 + g) * 256 + b
}
 
fun main(args: Array<String>) {
    println(Color.BLUE.rgb())
    // 255
}
Colored by Color Scripter
cs

위의 코드와 같이 enum class에서도 일반적인 class와 동일하게 생성자와 프로퍼티를 선언한다. 또한 해당하는 enum 상수를 정의할 때는 그 상수에 대응되는 프로퍼티 값을 넣어주면 된다.

또한, 이전과는 다르게 enum class에서 메소드를 정의하는 경우에는 필수로 enum 상수 목록의 마지막에 세미콜론을 붙여주어야 한다.

- Quiz

앞에서 학습한 내용들을 바탕으로 몇가지 퀴즈를 풀어보자.

Q1. if가 자바와 코틀린에서 다른점은 무엇인가?

Q2. val 변수와 var 변수의 차이는?

Q3. 코틀린에서 세미콜론을 붙여야 하는 경우는 언제인가?

참고 서적 및 링크

* [Kotlin in Action] - 드미트리 제메로프/스베트라나 이사코바 지음, 오현석 옮김, 에이콘 출판사

코틀린[Kotlin] #01_코틀린이란?

Tigercow.Door — Wed, 2 Dec 2020 21:28:48 +0900

안녕하세요. 문범우입니다.

최근 팀 동료분들과 함께 Kotlin 스터디를 하게 되었습니다. 빠르게 관련 서적을 함께 공부하고 이후 무언가를 만들어보기로 목표를 가지고 진행합니다. 우선적으로는, 책의 내용을 공부하며 블로그에 포스팅을 진행할 예정입니다. 서적은 [Kotlin in Action, 드미트리 제메로프/스베트라나 이사코바 지음, 오현석 옮김, 에이콘출판사]를 참고합니다.

잘못된 내용이나 궁금한 사항에 대해서는 언제든 연락주시면 감사하겠습니다.

1. 코틀린이란 무엇인가?

코틀린(Kotlin)이란 기존의 자바 플랫폼에서 돌아가는 새로운 프로그래밍 언어이다.

앞으로 함께 알아보겠지만 코틀린은 간결하고, 실용적이면서도 자바 코드와 상호운용성(interoperability)을 중요시한다. 즉, 현재 자바가 사용되는 곳에서는 거의 대부분 코틀린을 적용시킬 수 있다.

우선 코틀린에 대한 짧은 코드를 살펴보자.

https://try.kotlinlang.org/ 에 접속하면 빠르게 코드를 작성하여 테스트해볼 수 있다.

1
2
3
4
5
6
7
8
9
10
// data 클래스
data class Person(val name: String,
                 val age: Int? = null) // null값이 허용되는 int타입(Int?), 디폴트 값은 null
 
fun main(args: Array<String>) { // 최상위 함수
    val persons = listOf(Person("영희"),
                        Person("철수", age=29))
    val oldest = persons.maxBy {it.age ?: 0} // 람다 식과 엘비스 연산자
    println("나이가 가장 많은 사람: $oldest") // 문자열 템플릿
}
Colored by Color Scripter
cs

물론 위의 코드에 대해서 명확하게 파악되지 않는 것이 당연하다. 그냥 이러한 것들도 있구나 정도로 가볍게 받아들이면 좋다.

나중에 더 자세하게 다루겠지만, 코틀린에서는 프로그래머가 직접 타입을 지정하지 않는다. 그렇다면 동적 프로그래밍 언어로 생각할 수 있지만, 코틀린은 정적 프로그래밍언어이다. 프로그래머가 직접 타입을 지정하지 않아도 컴파일러가 문맥을 고려하여 변수의 타입을 결정하는, 타입추론(type inference)가 지원된다.

또한, 코틀린의 타입 시스템은 Null이 될 수 없는 값을 추적하며, 실행 시점에 NullPointerException이 발생할 수 있는 연산을 골라낸다. 특정 타입이null이 될 수 있는지는 ?기호를 추가하면 된다.

위 코드에서 잠시 등장한 엘비스 연산자라고 부르는 ?: 는 age가 null인 경우에 0을 반환한다는 의미이다.

이제 이러한 코틀린에 대해 몇가지 특성을 함께 알아보자.

2. 코틀린의 특성

2-1. 정적 타입 지정 언어

앞에서 잠깐 언급하였듯이 코틀린은 자바와 같이 정적 타입(statically typed) 지정 언어이다. 정적 타입 지정 언어라는 것은 컴파일 시점에 구성 요소의 타입을 알 수 있고, 컴파일러가 타입을 검증해준다는 것이다.

대표적으로 파이썬(python)언어는 동적 타입 지정 언어이다. 동적 타입 지정 언어는 타입과 관계 없이 모든 값을 변수에 넣을 수 있고, 이로 인해 코드가 더 간결해지고 데이터 구조 자체를 유연하게 사용할 수 있다. 하지만 파이썬 언어를 다뤄본 사람이라면 알 수 있듯이, 컴파일시 타입에 대한 검증이 없기 때문에 실행 시점(run time)에 에러가 발생할 수 있다.

한편 코틀린은 정적 타입 지정언어 임에도 불구하고 자바와는 달리 모든 변수의 타입을 프로그래머가 직접 명시해주지 않아도 된다. 컴파일러가 문맥을 고려하여 변수 타입을 결정한다. 그리고 이러한 기능을 타입 추론(type inference)이라고 부른다.

정적 타입 지정 언어의 장점은 다음과 같다.

- 성능: 실행 시점에서 어떤 메소드를 호출할지 알아야하는 과정이 필요 없기에 메소드 호출이 더 빠르다.

- 신뢰성: 컴파일러가 프로그램의 정확성을 검증하기 때문에 실행 시 프로그램이 오류로 중단될 가능성이 더 적다.

- 유지보수성: 코드에서 다루는 객체가 어떤 타입에 속하는지 알 수 있기 때문에 유지보수가 편리하다.

- 도구지원: 정적 타입 지정을 활용하면 더 안전하게 리팩토링(refactoring) 할 수 있고, 도구는 더 정확한 코드 완성 기능을 제공할 수 있다.

또한 코틀린은 널이 될 수 있는 타입, nullable type을 지원한다. 널이 될 수 있는 타입을 지원함에 따라서 컴파일 시점에 널 포인터 예외(Null pointer exception)가 발생할 수 있는지 여부를 검사할 수 있고, 이는 프로그램의 신뢰성이 높아지는 것을 의미한다.

2-2. 함수형 프로그래밍

자바와 달리 코틀린의 타입 시스템에 있는 새로운 내용은 함수 타입(function type)이다.

자바 개발자라면 일반적으로 객체지향(object oriented) 프로그래밍의 핵심 개념에 잘 이해하고 있을 것이다. 코틀린은 객체지향 뿐 아니라 함수형 프로그래밍을 잘 지원하고 있다.

함수형 프로그래밍의 핵심 개념은 다음과 같다.

- 일급 시민인(first-class) 함수: 함수를 일반 값처럼 다룰 수 있다. 함수를 변수에 저장할 수 있으며, 함수를 다른 함수에 인자로 전달할 수도 있다. 또한 함수에서 새로운 함수를 만들어서 반환할 수 있다.

- 불변성(immutability): 함수형 프로그래밍에서는 일단 만들어지고 나면 내부 상태가 절대로 바뀌지 않는 불변 객체를 사용하여 프로그램을 작성한다.

- 부수 효과(side effect) 없음: 함수형 프로그래밍에서는 입력이 같으면 항상 같은 출력을 내놓고 다른 객체의 상태를 변경하지 않는다. 또한 함수 외부나 다른 바깥 환경과 상호작용하지 않는 순수 함수를 사용한다.

이러한 핵심개념을 가진 함수형 프로그래밍 스타일로 프로그램을 작성하면, 간결성과 다중 스레드 사용시 안정성을 얻을 수 있다.

3. 코틀린의 철학

처음에 이야기 하였듯, 코틀린은 자바와의 상호운용성에 초첨을 맞춘 언어이고, 실용적이며 간력한 언어라고 하였다. 그렇다면 코틀린의 철학은 무엇일까? 4가지 키워드, 실용성/간결성/안전성/상호운용성으로 알아보도록 하자.

3-1. 실용성

코틀린은 어느 특정 프로그래밍 스타일이나 패러다임을 사용할 것을 강제로 요구하지 않는다. 특히, 자바에서 사용해 온 익숙한 프로그래밍 스타일이나 기법을 코틀린에서도 사용할 수 있다.

3-2. 간결성

코틀린은 만들어지면서 프로그래머가 작성하는 코드에서 의미가 없는 부분을 줄이고 언어가 요구하는 구조를 만족하기 위해, 별 뜻은 없지만 프로그램에 꼭 넣어야하는 부수적인 요소를 줄이기 위해 많은 노력이 가해졌다.

다른 최신 언어와 마찬가지로 코틀린은 기능이 다양한 표준 라이브러리를 제공하기 때문에 반복되거나 길어질 수 있는 코드를 라이브러리 함수 호출로 대치할 수 있다.

3-3. 안전성

코틀린은 우선 JVM에서 실행한다는 사실 자체에서 이미 상당한 안전성을 보장할 수 있다는 의미를 갖는다. JVM을 사용함으로써 메모리 안전성을 보장하고, 버퍼 오버플로우를 방지하며, 동적으로 할당한 메모리를 잘못 사용함으로 인해 발생할 수 있는 다양한 문제를 예방할 수 있다. 또한 정적 타입 지정언어로서 타입 안전성을 보장하지만, 타입 추론을 통해 더 적은 비용으로 그러한 안전성을 가질 수 있다.

3-4. 상호운용성

코틀린은 기존 라이브러리를 그대로 사용할 수 있다. 자바 메소드를 호출하거나 자바 클래스를 상속하거나 인터페이스를 구현하거나 자바 어노테이션을 코틀린 코드에 적용하는 등의 모든 일이 가능하다.

또한 자바코드에서 코틀린 코드를 호출할 때에도 아무런 노력이 필요 없다. 코틀린의 클래스나 메소드를 일반적인 자바 클래스나 메소드와 똑같이 사용할 수 있다. 이에 따라 자바와 코틀린 코드를 프로젝트에서 원하는 대로 섞어 쓸 수 있다는 궁극적인 유연성을 지닌다.

4. 코틀린 코드 컴파일

코틀린 소스코드는 .kt라는 확장자를 파일에 붙인다. 코틀린 컴파일러는 자바 컴파일러가 자바 소스코드를 컴파일 할 때와 마찬가지로 코틀린 소스코드를 분석하여 .class 파일을 만들어낸다.

코틀린 컴파일러로 컴파일한 코드는 코틀린 런타임 라이브러리(kotlin runtime library)에 의존한다. 런타임 라이브러리에는 코틀린에서 자바 API의 기능을 확장한 내용과, 코틀린 자체 표준 라이브러리 클래스 내용으로 이루어져 있다. 코틀린으로 컴파일한 애플리케이션을 배포할 때는 런타임 라이브러리도 함께 배포해야 한다.

참고 서적 및 링크

* [Kotlin in Action] - 드미트리 제메로프/스베트라나 이사코바 지음, 오현석 옮김, 에이콘 출판사

* 코틀린 온라인 놀이터 - https://try.kotlinlang.org/

파이썬(PYTHON) 클린코드 #10_ SOLID, 의존성 역전 원칙(DIP)

Tigercow.Door — Tue, 10 Nov 2020 22:44:17 +0900

안녕하세요. 문범우입니다.

이번 포스팅에서는 SOLID 원칙 중 마지막 원칙인, 의존성 역전 원칙(Dependency Inversion Principle)에 대해서 알아보도록 하겠습니다.

1. DIP(Dependency Inversion Principle)

우선 의존성 역전 원칙(DIP)의 정의에 대해서 알아보자.

의존성 역전 원칙은, 추상화를 통해 세부 사항에 의존하지 않도록 해야 하지만, 반대로 세부 사항(구체적인 구현)은 추상화에 의존해야 한다는 원칙이다.

쉽게 말해서, 보다 고수준 모듈(클래스)은 보다 저수준 모듈(클래스)에 대해 의존하면 안된다는 것이고, 의존하지 않는다는 것은 저수준 모듈의 변경이나 추가 등에 있어서 변경점이 없어야 한다는 것이다.

파이썬이라는 언어의 특성상 융통성이 있으며, 동적 언어이기 때문에 예제들을 살펴볼때 이것이 왜 필요한지 의문이 들 수 있다. 이에 대해 본인이 참고하고 있는 "파이썬 클린코드"의 저자는 다음과 같이 이야기한다.

실제로 꼭 이렇게 할 필요는 없으며 프로그램은 똑같이 동작한다.
...
그러나 클린 디자인을 위해서 바람직하다. 이것이 이 책이 있는 이유 중 하나로 단지 파이썬이 너무 유연하여 자주 발생하는 실수를 줄이기 위함이다.

- 파이썬 클린코드

본인은 예제에서 assert를 이용해 조금 더 강제성을 부여하였다.

실제로 예제코드와 같은 상황은 드물겠지만, DIP를 조금 더 잘 느끼기 위함으로 이해해주기를 바란다.

그럼 바로 예제를 살펴보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# DIP를 지키지 못한 예제
from abc import *
 
class EventStreamer():
    def __init__(self, parsed_data: str, client: Syslog):
        self.parsed_data = parsed_data
        assert client is Syslog, "Client is not Syslog"
        self.client = client
        
    def stream(self):
        self.client.send(self.parsed_data)    
        
class Syslog():
    def send(data: str):
        print(f"Syslog send: {data}")
        pass
    
class OtherClient():
    def send(data: str):
        print(f"OtherClient send: {data}")
        pass
 
 
streamer1 = EventStreamer("for Syslog data!", Syslog)
streamer1.stream()
streamer2 = EventStreamer("for OtherClient data!", OtherClient)
streamer2.stream()
Colored by Color Scripter
cs

code: https://github.com/doorBW/python_clean_code

위의 예제를 살펴보면, EventStreamer() 라는 고수준의 모듈이 직접 Syslog를 참조함으로써, Syslog에 대해 의존하고 있다.

위의 코드를 실행시켜보면 assert에 다음과 같이 에러가 발생한다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Syslog send: for Syslog data!
---------------------------------------------------------------------------
AssertionError                            Traceback (most recent call last)
<ipython-input-46-d6c168be4001> in <module>()
     24 streamer1 = EventStreamer("for Syslog data!", Syslog)
     25 streamer1.stream()
---> 26 streamer2 = EventStreamer("for OtherClient data!", OtherClient)
     27 streamer2.stream()
 
<ipython-input-46-d6c168be4001> in __init__(self, parsed_data, client)
      5     def __init__(self, parsed_data: str, client: Syslog):
      6         self.parsed_data = parsed_data
----> 7         assert client is Syslog, "Client is not Syslog"
      8         self.client = client
      9 
 
AssertionError: Client is not Syslog
Colored by Color Scripter
cs

code: https://github.com/doorBW/python_clean_code

물론 위의 에러는 본인이 assert를 통해 강제성을 부여하였기에 발생된 에러지만, 실제로 Java와 같은 정적 언어에서는 타입이 지정되기 때문에 에러가 발생할 것이다.

또한 예제이기 때문에 각 함수들에 대해 구체적인 행동을 만들어주지 않았지만, 만약 Syslog의 send() 함수가 변경되었을 때에는 EventStreamer 클래스도 변경해야 할 가능성이 생긴다.

위와 같은 상황에서 Syslog 클래스와 OtherClient 클래스를 추상화하는 DataTargerClient 인터페이스를 만들어 줌으로써 DIP를 만족시킬 수 있다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
# DIP를 적용한 예제
from abc import *
 
class EventStreamer():
    def __init__(self, parsed_data: str, client):
        self.parsed_data = parsed_data
        assert client in DataTargetClient.__subclasses__(), "Client is not DataTargetClient"
        self.client = client
        
    def stream(self):
        self.client.send(self.parsed_data)
 
class DataTargetClient(metaclass=ABCMeta):
    """Interface: DataTargetClient class"""
    @abstractmethod
    def send(self, data: str):
        pass            
        
class Syslog(DataTargetClient):
    def send(data: str):
        print(f"Syslog send: {data}")
        pass
    
class OtherClient(DataTargetClient):
    def send(data: str):
        print(f"OtherClient send: {data}")
        pass
 
 
streamer1 = EventStreamer("for Syslog data!", Syslog)
streamer1.stream()
streamer2 = EventStreamer("for OtherClient data!", OtherClient)
streamer2.stream()
Colored by Color Scripter
cs

code: https://github.com/doorBW/python_clean_code

위와 같이 기존의 Syslog 클래스와 OtherClient 클래스가 DataTargetClient를 구현하고 있으며, EventStreamer 클래스는 단지 DataTargetClient 인터페이스와 관계를 가질뿐, 실제 구체적인 구현과는 의존성이 사라지게 된다.

위의 코드를 실행시키면 다음과 같이 잘 동작함을 볼 수 있다.

1
2
Syslog send: for Syslog data!
OtherClient send: for OtherClient data!
cs

code: https://github.com/doorBW/python_clean_code

파이썬(PYTHON) 클린코드 #9_ SOLID, 인터페이스 분리 원칙(ISP)

Tigercow.Door — Wed, 4 Nov 2020 23:47:11 +0900

안녕하세요. 문범우입니다.

이번 포스팅에서는 SOLID 원칙 중, 인터페이스 분리 원칙(ISP)에 대해서 알아보도록 하겠습니다.

1. ISP(Interface Segregation Principle)

인터페이스 분리 원칙(ISP)은, 클라이언트가 자신이 이용하지 않는 메소드에 의존하면 안된다라는 원칙이다.

다른 방향으로 해석해보자면, 하나의 인터페이스는그 책임에 맞는 메소드만 가지고 있어야 한다는 의미이다. 책임이라는 용어, 매우 익숙할 것이라고 생각한다.

SOLID에 대해서 알아보며 첫번째로 다루었던 SRP원칙과 매우 유사하게 느껴질 것이다. 물론 SOLID 원칙 모두가 상호 연관 관계가 있고, 좋은 코드를 목표로 하고 있기 때문에 더욱 그렇게 느껴질 수 있다.

이번에 다뤄볼 ISP와 이전에 학습한 SRP의 차이점을 생각해본다면, ISP는 보다 직접적으로 인터페이스에 대해서 이야기하고 있는 것이다.

인터페이스가 다양한 책임을 가지고 있거나, 자신의 책임과 걸맞지 않는 메서드를 가지고 있게되면, 해당 인터페이스를 구현하는 클래스 모두에게 영향을 미치게 된다.

아래와 같은 코드를 살펴보자.

1
2
3
4
5
6
7
8
9
10
11
12
# ISP를 지키지 못한 예제
from abc import *
 
class EventParser(metaclass=ABCMeta):
    """Interface: EventParser class"""
    @abstractmethod
    def from_json(self, event_data):
        pass
    
    @abstractmethod
    def from_xml(self, event_data):
        pass    
cs

code: https://github.com/doorBW/python_clean_code

위 코드에서 사용한 abc라이브러리를 통해 EventParser 인터페이스를 구현하였다.

EventParser 내부에 정의된 2개의 추상메서드를 살펴보자. fron_json()과 from_xml()이 모두 정의되어있다. 그렇다면 해당 EventParser를 구현하는 클래스는 json, xml 필요한 것만 구현하는 것이 아니라, 처리하는 데이터와 무관하게 두가지 함수를 모두 구현해야 한다.

즉, 자신이 이용하지 않는 메서드에 의존하게 되는 것이다.

이러한 것이 ISP원칙을 위반한 사례라고 볼 수 있다.

이를 해결하려면 어떻게 할까? 간단하게 생각해서, 그 책임을 분할시켜주면 된다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# ISP를 적용한 예제
from abc import *
 
class JsonEventParser(metaclass=ABCMeta):
    """Interface: JsonEventParser class"""
    @abstractmethod
    def from_json(self, event_data):
        pass    
    
class XmlEventParser(metaclass=ABCMeta):
    """Interface: XmlEventParser class"""
    @abstractmethod
    def from_xml(self, event_data):
        pass    
cs

code: https://github.com/doorBW/python_clean_code

위의 코드는 기존의 EventParser를 분리하여 JsonEventParser와 XmlEventParser로 분리하였다. 이렇게 인터페이스를 분리함에 따라서, 인터페이스를 구현하는 클래스가 자신이 이용하지 않는 메서드에 의존하게 되는 문제를 해결한 것이다.

하지만, 위와 같이 고려하다보면 "하나의 인터페이스는 하나의 메서드만 가져야하는 것일까?" 라는 생각에 부딪힐 수 있다.

물론 그렇지 않다.

앞에서의 예제들은 설명을 위해 간략하게 작성한 예제라서 그렇지만, 결국 말하고자 하는 것은 하나의 인터페이스에서 하나의 일만 해야한다는 것이다.

하나의 메서드만 있어야 한다는 것이 아니라, 하나의 일을 담당해야 한다는 것은 동일한 맥락의 책임이라면 이를 처리하기 위해 여러개의 메서드가 존재할 수 있다는 것이다.

예를 들어, XmlEventParser 클래스에서 비즈니스 로직과, 데이터 검토 결과 동일한 데이터 전처리가 필요하다고 판단되면 해당 메서드를 추가할 수 있는 것이다.

이는 ISP 뿐만 아니라 모든 SOLID원칙에도 적용된다.

SOLID 원칙은 기본적인 것을 이야기 할 뿐이지, SOLID 원칙에서 언급되는 예제에 대해서는 실제 업무와 환경, 비즈니스 로직, 다양한 변수들에 의해 조금씩은 다르게 구현될 수 있다.

Tigercow.Door

2024 Prography 네트워킹 세미나 이야기

0. 네트워킹 세미나

1. Marketing / ProductOwner / Design

2. Prography 소개 세션

3. Frontend / Mobile / Backend

4. 네트워킹 세미나, 그 이후

IT동아리 프로그라피(Prography) 8기 운영진 활동 이야기

1. 프로그라피(Prography)는 무엇을 하는 곳 인가요?

2. 기억에 남는 활동은 무엇인가요?

3. 프로그라피 활동을 통해 성장할 수 있는 포인트는 무엇인가요?

4. 아쉬웠던 점은 무엇인가요?

5. 우리, 프로그라피 9기에서 만나요!

왜 개발자가 되려고 하시나요?

1. 실력이 없다면 언제든지 도태된다.

2. 워라밸은 보장되지 않을 수 있다.

3. 엄청난 삽질과 끈기가 필요하다.

4. 매체에서 말하는 좋은 점들이 보편화된 사실은 아닐 수 있다.

5. 개발자가 되는 것이 쉽지만은 않다.

6. 생각보다 다양한 분야의 사람을 만난다.

[Kubernetes] 쿠버네티스 레이블(Labels)에 대한 9가지 모범 사례(번역)

쿠버네티스 레이블(Labels)에 대한 9가지 모범 사례(원제: 9 Best Practices and Examples for Working with Kubernetes Labels)

1. 구문에 대해 주의하라. (Beware of the Syntax)

2. 레이블을 꼭 적용해라. (Label, Label, Label)

3. 레이블 규정(conventions)에 대한 전사적인 규약(consensus)을 만들어라.(Create company-wide consensus on labeling conventions)

4. 필수적인 레이블 리스트를 만들어라. (Create a list of required labels)

5. 더 광범위한 레이블 리스트를 만들어라. (Create a more extensive list of Kubernetes labels)

6. 쿠버네티스에서 추천하는 레이블을 사용해라. (Use recommended Kubernetes labels)

7. 미리 만들어지는 쿠버네티스 레이블을 확인해라. (Monitor pre-populated Kubernetes labels)

8. Kops에서 클라우드 레이블과 노드 레이블을 규정해라. (Specify Cloudlabels and NodeLabels in Kops)

9. 레이블과 어노테이션에 대한 구분을 지어라.(Differentiate between Kubernetes labels vs annotations)

결론 (Conclusion)

코틀린[Kotlin] #04_함수 정의와 호출

코틀린[Kotlin] #03_코틀린 기초(when, 스마트 캐스트, 반복문, in, 예외처리)

코틀린[Kotlin] #02_코틀린 기초(함수,클래스,프로퍼티,enum)

코틀린[Kotlin] #01_코틀린이란?

파이썬(PYTHON) 클린코드 #10_ SOLID, 의존성 역전 원칙(DIP)

파이썬(PYTHON) 클린코드 #9_ SOLID, 인터페이스 분리 원칙(ISP)

쿠버네티스 레이블(Labels)에 대한 9가지 모범 사례
(원제: 9 Best Practices and Examples for Working with Kubernetes Labels)

3. 레이블 규정(conventions)에 대한 전사적인 규약(consensus)을 만들어라.
(Create company-wide consensus on labeling conventions)

8. Kops에서 클라우드 레이블과 노드 레이블을 규정해라.
(Specify Cloudlabels and NodeLabels in Kops)

9. 레이블과 어노테이션에 대한 구분을 지어라.
(Differentiate between Kubernetes labels vs annotations)