<tr v-for="contact in contacts" :key="contact.no">
형식(객체 사용시) : <태그명v-for="(val, key) in 객체" :key="key">
<option v-for="(val, key) in regions" :value="key" :key="key">{{val}}</option>
인덱스 번호가 필요한 경우)
template 태그 - 여러 요소를 묶어서 반복 렌더링
<template v-for="(contact, index) in contacts" :key="contact.no">
v-for 디렉티브와 key 특성
배열을 렌더링할 때 데이터 변경없이 위치만 바뀌는 경우
key 속성이 없으면 => 전부 다시 렌더링
key 속성이 있으면 => 위치만 변경 가능
❗key 특성에는 인덱스 번호가 아닌, 고유한 변경되지 않는 값 부여
Proxy 객체
데이터의 변경 사항 감시, 값 변경 시 렌더링 다시 유도
Vue 인스턴스에서 data 옵션으로 지정한 객체
data로 지정된 객체는 모두 Proxy로 래핑
배열의 데이터를 변경하는 메서드들도 매핑되어 있어, 배열 내용 변경시 watcher에게 변경을 알려서 다시 렌더링 필요
❓궁금증❓ 네트워크에서 배운 Proxy 서버의 Proxy와 유사한 개념인건가? ==> Vue에서 "프록시"는 JavaScript의 Proxy 객체를 기반으로 작동하는 개념으로,Vue의 반응형(Reactivity) 시스템을 구현하는 핵심 기술 중간에서 데이터를 가로채고 조작한다는 점에서 유사
//깃허브 레포지토리 가져오기 및 상태 확인 코드
git clone "깃허브 레포지토리 링크"
git status
git log --oneline
git log --oneline --graph
//새로운 브랜치 생성 후 이동
git checkout -b [branchName]
git branch
git checkout [branch]
//깃허브의 내 작업 브랜치로 올리기
git add [커밋할 파일]
git commit -m "커밋 메세지"
git push origin [내가 작업한 브랜치 명]
//깃허브 들어가서 내 작업 브랜치-> main으로 PR 생성
2)원격 저장소에 변경된 내용 내 로컬에 가져오기
//원격 저장소 main에서 로컬 저장소main으로 가져오기
git pull
//로컬 저장소 main에서 로컬 저장소 내 브랜치로 가져오기
git merge main or
git pull origin main or
git rabase main
//브랜치 삭제
git branch -D [브랜치 명]
[1] git merge main을 사용할 경우
내가 commit한 내역 말고도 main으로부터 merge한 커밋이 생성되어 있음 ==> commit 내역이 더러워질 수 있음!!!
[2] git pull main을 사용할 경우 pull == git fetch + git merge를 수행하는 명령어
merge는 로컬에서 실행하는 병합 작업 pull은 원격 저장소에서 변경사항을 가져온 후 자동으로 병합 수행
[3]git rebase main을 사용할 경우
feature-branch의 모든 커밋을 main의 최신 상태 위로 다시 정렬 병합 커밋 없이 히스토리가 깔끔하게 정리됨 ==> 그러나, main에 이미 푸시된 커밋을 rebase하면 팀원들이 pull할 때 충돌 발생 가능
function mainFunction(callback) {
console.log("메인 함수 실행");
callback(); // 전달받은 콜백 함수 실행
}
function myCallback() {
console.log("콜백 함수 실행");
}
// mainFunction 실행 시 myCallback을 콜백 함수로 전달
mainFunction(myCallback);
실행 결과
-----------
메인 함수 실행
콜백 함수 실행
콜백 함수는 마지막 매개변수로
function order(coffee, callback) {
//커피 주문
//3초 기다린 후 콜백 실행
}
function display(result) {
//커피 완료 표시
}
order("아메리카노", display); //display함수를 order함수의 매개변수로 전달
const myPromise = new Promise((resolve, reject) => {
let success = true; // 성공 여부를 설정
setTimeout(() => {
if (success) {
resolve("✅ 작업 성공!");
} else {
reject("❌ 작업 실패!");
}
}, 2000);
});
myPromise
.then(result => console.log(result)) // 성공 시 실행
.catch(error => console.error(error)) // 실패 시 실행
.finally(() => console.log("🎯 작업 완료!"));
실행 결과
-----------
✅ 작업 성공!
🎯 작업 완료!
Promise 체이닝
여러개의 비동기 작업을 연결해서 실행
function getUser() {
return new Promise(resolve => {
setTimeout(() => resolve("👤 사용자 데이터"), 1000);
});
}
function getPosts(user) {
return new Promise(resolve => {
setTimeout(() => resolve(`${user}의 게시글`), 1000);
});
}
getUser()
.then(user => getPosts(user))
.then(posts => console.log(posts)) // "👤 사용자 데이터의 게시글"
.catch(error => console.error("❌ 오류 발생:", error));
Promise 역시 체이닝을 사용해서 연결을 계속하면 콜백 지옥처럼 코드가 복잡해질 수 있음!
// math.js (CommonJS)
const add = (a, b) => a + b;
const subtract = (a, b) => a - b;
// 모듈을 내보내는 방법 (객체 형태로 여러 개 내보낼 수 있음)
module.exports = subtract;
module.exports = { add, subtract };
금융 관련 공모전을 기다리던 중 발견한 DGB금융그룹의 IT's DGB iM Challenger 공모전 !
이름이 길어서 복잡해 보이지만 결론은 디지털 기술을 적용한 금융 관련 상품이나 서비스 아이디어를 개발하는 것이다.
예선 - 본선 - 파이널 라운드, 사이에 전문 교육 등등 호흡이 긴 공모전이지만 일단 본선 대회 진출을 목표로 준비를 시작했다.
2. 예선 준비
우리 팀은 나와 내 친구 2명이었고 둘 모두 개발을 전공한 (예비) 개발자이다.
금융 지식 보유자, 디자이너 없이 개발만 아는 팀원 두 명이었지만 본선 대회에 진출할 수 있었다.
예선 준비를 하면서 친구와 다양한 아이디어를 논의해보았고 우리는 금융 관련 지식이 별로 없는만큼 어려운 주식 투자, 펀드, 부동산 등 보다는 보다 단순한 (우리들이 말하기로는 보다 말랑말랑한) 주제를 선정하고자 했다.
이렇게 전년도 수상 정보도 조사해보고 노션을 파서 회의를 진행했다.
우리 팀이 최종적으로 선정한 아이디어는 "맞춤형 DGB 캐릭터 키우기 서비스" 이다.
아이디어 회의를 진행하면서 주목했던 2가지는
1) 요즘 유행하는 서비스가 무엇인가? => 피크민과 같은 캐릭터 서비스
2) DGB금융그룹이 원하는 건 무엇일까? => iM뱅크가 시중은행이 된 만큼 인지도 상승시키기
였고 전년도에도 dgb 캐릭터를 활용한 아이디어가 수상했던 것을 보아 이를 활용해서 주제를 선정했다.
(그런데 예선 자료를 만들면서는 전년도 아이디어랑 너무 유사해보일까봐 걱정되었다. 그래도 결론적으로는 본선까지 간 걸 보면 나름 잘 정한 주제인 것 같다)
우리는 예선 접수할 때 기술 구현은 하지 않았다. (예비)개발자 2명이었지만 둘 모두 공모전이 처음이었기에 주제 정하고 구체화하는데 더 집중했다.
예선 제출날 공모전 홈페이지 서버가 이상해서 메일로 제출하고 하는 이슈가 있었지만 그래도 정상적으로 접수 완료가 되었다.
3. 본선 진출 팀 발표
본선 진출 팀 발표는 12월 31일에 이루어졌다. 2024년의 마지막 날 발표라니.. 만약 떨어졌다면 꽤 씁쓸했을 것 같다.
발표는 공모전 홈페이지 팝업 및 공지사항으로 이루어졌고 나는 오후 5시쯤 들어가봤는데 낮 즈음에 발표가 나 있었다.
가나다 순이라 홈페이지 들어가자마자 금잔디가 있어서 바로 발견하고 흥분 MAX 상태로 친구에게 전화했다 ㅋㅋ
후에 뉴스에서 보니까 총 89팀이 예선 접수했고 그 중 20팀이 발대식 및 본선 대회에 진출했다고 한다.
4. 본선 대회 준비
본선 진출 팀 발표 이후 1주일 정도 본선 발표용 자료 제출 기한이 주어진다. 이때 기존 주제를 벗어나지 않는 선에서 아이디어 디벨롭이 가능하다. 우리 팀은 소비 분석 케이스를 더 구체화하고 추가 캐릭터를 제작해서 포함했다.
이때 자료에 동영상, 슬라이드 쇼, 폰트 등 잘 체크해서 제출하라고 공지를 꼼꼼히 해주신다. 우리 팀은 혹시나 폰트가 깨지면 PDF로 발표하려고 슬라이드 쇼 같은것도 안넣었는데 발표 후 생각해보니까 조금이라도 관심을 주목하기 위한 요소로 넣을 걸 그랬나 싶었다. (아무래도 20팀이 10분씩 계속 발표하다보니 본선 대회가 루즈해지는 것 같았다.)
학교 세미나실에 가서 발표 연습도 하고, 우리 팀은 서울에서 대구까지 가야하므로 왕복 KTX와 호텔도 1박 예약했다. 본선 대회 때는 서울 기준 KTX 편도 43500원, 왕복 87000원을 지원해준다. 본선 대회 후 일주일 정도 후에 바로 입금이 되었다!
5. 리허설
본선 대회 전날인 1/13일에 간단한 리허설이 있었다. 본선 대회 발표 순서(랜덤)대로 마이크 테스트 및 PPT 오류가 없는 지 확인한다. 마이크는 핸드 마이크와 핀 마이크 중 고를 수 있다. 대부분 팀들이 핸드 마이크를 썼는데 발표 때 한 손에는 포인터를 들어야 하니 이를 고려해서 선택해도 좋을 것 같다. 아무래도 핸드 마이크를 선택하면 손을 사용하는데 제약이 있다.
KTX 타고 대구로 이동~ 동대구역에서는 택시를 타고 갔다.
입구에서 단디와 똑디가 반겨준다. 아주 반가워서 친구한테 여기서 사진 한 장 찍어줄까? 했는데 거절함 ㅋㅋ쿄
iM뱅크 제2본점이라는데 회사 아주 삐까뻔쩍했다.
그리고 발대식 및 본선대회가 이루어질 5층 홀 !
리허설 때 나누어주신 안내 종이. 총 20팀이라 7, 7, 6 팀 씩 끊어서 발표했다.
6. 발대식
본선 대회 날의 오전 동안에 발대식이 이루어졌다. DGB금융그룹 회장님과 임직원 분들, 대구 국회의원, 대구 지역의 대학교 교수님들 등 많은 분들이 참석하셨다.
4층 다목적 홀이 참가학생들 대기 공간 및 짐을 두고 점심도 먹는 공간이었다. 본선 대회 당일날 도착하면 단체 티를 나누어주신다. 민트색이라고 미리 공지가 되어있었어서 소화할 수 있을까,, 싶었는데 약간의 청록색? 계열이라 다행이었다
사이즈가 95, 100, 105 로 나뉘어져있고 골라서 가져갈 수 있지만 전체적으로 크기가 매우 컸고 기모가 아주 부드러웠다 잠옷으로 입으면 딱일듯
발대식 세레모니와 축하 말씀이 있고 대한 변리사 협회의 변리사님이 1시간동안 강의도 해주셨다. IT's DGB iM Challenger 공모전은 교통비 지원, 단체복 제공 등등 모든게 완벽한데 하나 아쉬운 점이 있다면 바로 발대식 및 본선 대회가 이루어지는 공간의 학생들 자리였다.
DGB금융그룹 제공
이렇게 계단처럼 된 공간에 앉는 형식인데 자리가 너무 좁고 학생들이 촘촘히 앉아야해서 등을 기대거나 다리를 펼수도 없다. 본선대회날은 거의 하루 종일 여기 앉아있어야 하는데 우리 팀 뿐만 아니라 다른 학생들도 힘들어하는 것 같았다.
여기 공간이 이런 행사를 하기에는 매우 예쁘고 좋지만 학생들 앉는 공간을 조금만 더 확장해주셔도 좋을 것 같다..
발대식 이후 점심 식사를 하고 본선 대회가 진행된다. 도시락도 매우 맛있어 보이는 걸로 제공해주시는데 난 긴장이 되서 거의 못먹었다ㅠㅠ 너무 아쉽다
발표 공간 옆에 이렇게 간식과 생수도 아주 빵빵하게 제공된다!
7. 본선 대회
밥을 먹고 올라오면 이렇게 본선 대회를 위한 준비가 마쳐져있다. 심사위원은 6분 정도이고 외부 위원 2분에 DGB금융그룹 내부 인사 4분(iM뱅크 ict 및 디지털 사업부의 부장님들 4분) 정도였다.
발표 후 심사위원 Q&A는 없으며 발표자 앞에 10분 타이머와 PPT를 볼 수 있는 스크린을 준비해 주셨다. 팀 당 제공되는 10분 시간이 끝나면 마이크가 자동으로 OFF될 거라고 하셨는데 10분을 초과한 팀은 없었다.
모든 발표가 종료된 후 바로 점수를 집계해서 파이널라운드에 진출할 10팀을 발표한다.
무려 20팀의 발표를 들으면서 느낀 점은 아이디어는 한정되어 있지만 이를 어떻게 분석하고 표현하는 지가 중요한 것 같다는 점이다. 다른 팀들의 주제로는 소액 주식 투자 상품, AI를 활용한 부동산 서비스, 자산 관리 서비스 등이 있었는데 금융 공모전을 준비해봤다면 한번쯤은 생각해봤을 주제들이었다. 조금 더 시선이 가고 퀄리티 있어보이는 발표는 누구나 생각할 수 있는 주제에 대해 기존 서비스와의 차별점을 구체화한 발표들이었다.
우리 팀은 아쉽게 파이널라운드에는 진출하지 못했지만 발대식 및 본선 대회에 진출한 것만으로도 너무 좋은 경험이었다!
파이널 라운드에 진출하지 못한 10팀에게는 10만원 상당의 기념품이 제공된다고 홈페이지에 나와있었는데
10만원 상당의 기념품은 바로 10만원 백화점 상품권이었다 ㅋㅋㅋ
쓸데없는 기념품 보다 돈으로 주는 은행 최고다
행사 종료 후 동대구역 앞에서 막창도 먹고 KTX를 타고 서울로 왔다
8. 느낀점
첫 공모전 도전이었는데 본선에 진출해서 공개PT라는 의미있는 경험을 할 수 있어서 좋았다. 기획한 아이디어에 대해 개발까지 완료한 건 아니지만 주제를 구체화하고 발표 자료를 만들면서 마이데이터 등 금융권의 디지털 서비스에 대한 이해도도 높아졌다. 이 공모전은 예선 제출부터 만약 다음 라운드에 계속 진출한다면 본선 대회, 전문 교육, 파이널 라운드 등 호흡이 긴 공모전이지만 본선 대회에 진출하는 것만으로도 큰 경험이 되니 DGB금융그룹 공모전을 고민 중인 분들이 계시다면 일단 도전해보길 강추한다.
인제님의 오픈소스 멘토링은 매우 체계적으로 진짜 누구나 이슈를 선정하고 첫 PR을 생성할 수 있도록 도와주는 과정 같았다. 그동안 오픈소스, 오픈소스 기여가 어떤 내용인지는 알고 있었지만 진짜 이렇게 많은 개발자들이 이슈를 올리고 또 해결하고 자유롭게 오픈소스가 발전되고 있다는 건 처음 접하였다.
오픈소스 멘토링 후기글들을 여럿 찾아보고, 노션도 구경하며 신청서를 제출할까 말까 많이 고민하였다. 나는 못할 것 같은데... 싶다가도 매일이 똑같은 이 시기에 새로운 도전을 해보고 싶어서 한시간 정도는 망설이다가 신청서를 제출하였다!
오픈소스 멘토링에 왜 참여하고 싶은지, 그동안 여러 스터디를 통해 다른 사람들과 함께 개발하는 경험을 쌓았던 내용을 담아서 작성했다.
11/5 (화) 멘토링 선정
신청서를 제출하고 선정이 될 수 있을까... 기다리다가 카톡방 알람이 울리고 멘토링에 선정되었다는 연락을 받았다. 무료한 일상에 도파민 터질 일정이 추가되었다는 사실에 너무너무 좋았다.
2. 이슈 선정부터~ 본격 기여 시작
11/21 (목) ~ 11/23 (토), 11/24 (일)
일요일 대면 멘토링 전에 카톡으로 이슈를 선정하고 피드백을 받는다!
나는 평소에 많이 사용해 본 spring, spring boot를 첫번째로 이슈 탐색을 시작하였다.
그런데 생각보다 인제님의 이슈 선정 가이드에 적합한 이슈가 보이지 않았다. 그래서 범위를 더 넓혀서 hibernate나 swagger, jpa, redis 등 사용해 본 경험이 있는 오픈소스 중에 관심 가는 아이들을 살펴보았다. 그 중에서도 사실 spring data reids에 마음이 조금 더 갔는데 아무래도 이 시기에 진행했던 졸업 연구 마지막 단계에서 spring data redis를 사용해서 그랬던 것 같다.
redis는 요즘 정말 많이 사용된다고 해서 나도 자세히 공부해보고 싶었는데 졸업 연구에 적용하는 과정은 import하고 캐시 애노테이션을 사용하고 너무 단순하게?(진짜 그냥 갖다 쓰는 정도로..) 사용한 것 같아서 아쉬웠다. 그래서 redis 이슈를 선정해서 분석해보면 좋을 것 같아 더 열심히 이슈를 찾았다.
나는 최종적으로
이렇게 2가지 이슈를 선정해 보았고 인제님 피드백을 바탕으로 spring data redis의 이슈를 최종적으로 선택하였다.
내가 선택한 이슈는 spring data redis에 properties 파일로 캐시 설정을 받아오는 새로운 기능을 추가하자는 이슈였다.
pr생성까지 마무리했지만 아직 끝이 아니다. 메인테이너 분들의 리뷰를 기다리고 merge 될 수 있을때까지 계속 작업을 해야 한다. 그동안 테스트 케이스를 다시 점검하고 다른 이슈들도 기웃기웃해 봐야겠다.
처음에는 이슈를 봐도 하나도 눈에 안들어오고 무엇보다 영어 독해가 생각보다 너무 안되고!! 힘들었지만 그래도 한 번 해보니까 자신감이 생기는 것 같다.
새로운 기능 추가가 아니더라도 오타 삭제나 누락된 단어 추가 같은 이슈도 기여해보면 좋을 것 같다.(사실 이번에 작업을 하면서 내가 오픈소스에 새 기능을 추가하는거... 괜찮은건가 가능한건가 싶으면서 조금 부담이 되었다ㅎ 하지만 뭐 일단 해보고 메인테이너분들의 리뷰를 받자는 마음으로 했다 결국엔 해냈다)
또, 오픈소스 멘토링은 너무너무 좋은 경험이었다. 내가 사용해보지 않은 오픈소스도 다른 분들이 작업하시는 걸 보고 또 마지막에 인제님께서 각각 어떤 오픈소스에서 어떤 이슈를 선정해서 작업했는 지 쭉 말씀해주셔서 여러 오픈소스에 대한 이야기를 들을 수 있어서 너무 좋았다.!
