#CS

제목이 좀 무시무시하게 생겼는데,,, 원본 영문 제목을 그대로 번역하니 이렇게 되어버렸다. 어제, 어느새 GitHub repo가 서른 개가 넘어가길래 필요없는 것들은 정리하던 와중에 한 repo가 눈에 띄었다. git 사용이 익숙해진 학부 고학년부터는 코드 작성이 필요한 전산과 과제들은 원본 코드를 GitHub에 백업했는데 그렇게 올라간 과제 중 하나였다. 21년 가을에 수강한 [인공지능 기반 소프트웨어 공학] 과목의 두 번째 과제로, metaheuristic search를 적용할만한 real-world problem을 찾고 이를 해결하는 solver를 구현해야 했다. 겨우 2년이 지났지만 내용은 다 까먹고 마치 다른 사람이 쓴 것마냥 흥미롭게 보고서를 읽어내려갔는데 웬걸, 좀 재밌다. 서울 집과 대전행 버스를 타는 고속버스터미널 사이에서 주구장창 탔던 9호선 급행에 착안해 주제를 잡았는데 그 과정이 꽤나 신선했다. 내 작업에 이런 말 하기 낯부끄럽기도 한데 어쨌거나 오랜만에 읽어본 감상은 그랬다. 그래서 자기만족성으로 블로그에도 올리기로 했다.ㅎ 주제를 자유롭게 고를 수 있는 과제는 학생의 성장에 있어 양날의 검과 같다. 교수도 예상하지 못한 창의적인 주제 선정으로 크게 역량을 키울 수도 있지만 한편으로는 개떡같이 해놓아도 큰일이 날 가능성이 적기 때문이다. 나의 경우에 그러한 과제들은 다행스럽게도 나에게 도움이 되는 방향으로 흘러간 것이 대부분인 것 같다. 이건 그 중에서 평이한 편이고, 더 이상한 주제를 잡아놓고 그런 과거의 나를 원망하며 어거지로 해낸 과제들이 돌이켜보면 나를 한층 성장하게 만들어준 경우가 여럿 있었다. 양방향 통신위성 제작, 2차원 재사용 로켓 착륙 시스템 개발 등…ㅋㅋㅋ 이들에 관해서도 나중에 여기에 썰을 풀 날이 오게 되지 않을까 기대한다. ⋮ 아래 GitHub repo에 포함된 solver와 보고서로 이루어진 본 과제 제출물은, real-world problem으로 여러 단계의 급행이 있는 지하철 노선에서의 최단시간 경로를 찾는 문제를 선택하고 이를 유전알고리즘을 사용한 metaheuristic search로 해결하는 과정을 보여준다. 🔗 GunheeYi/cs454-ass2 — Github Repository 보고서 (제출 버전에서 약간 수정됨) 2021 Fall CS454 at KAIST Assignment 2: Solving Minimum-Time Path Problem in a Metro System Involving Multiple Levels of Express Lines, Using Genetic Algorithms Gunhee Yi (20180431) In almost every weekend I take the line 9 of Seoul Metro. It conveniently connects the Express Bus Terminal and my town, and the 18 minutes that I spend there becomes the last step of the long journey from KAIST in Daejeon to my home in Seoul. 18 minutes, that is the time when I take the express train. There are both express and local trains in line 9. It takes 30 minutes if I take the local train, so it is better to take the next express rather than the local one even if I just missed the express. Though knowing that already, I still check the metro app often to see the arrival time of the next train. Then one day, as I was staring blankly through the screen, I started wondering about the cases where the departing or arriving stations were not express stations. In these cases, going forward some local stations before/after getting in/out of an express train was a common doing. But what if going BACK a little actually earned you some time? It turns out that it is not the case in line 9. Refer to the following deduction: Settings: $s_1$ is a local station right after the express station $s_0$. There are $n$ local stations between $s_0$ and another express station $s_{n+1}$. You are now at $s_1$ and desires to reach $s_{n+1}$. It takes constant $l$ minutes for a local train to move 1 station. It takes $e$ minutes for an express train to move from $s_0$ to $s_{n+1}$. Going forward for $n$ local stations takes $ln$ minutes, whereas going back a station and taking the express takes $(l+e)$ minutes. If the backward route is to be better, it should be $l+e There are not any adjacent pairs of express stations in line 9 that has more than two local stations in-between, so going back should never be an option for the passengers. But further search revealed that there was another line that had expresses. It was line 1, and its expresses passed through well over 10 stations during their operation. Now that we have found a real-world example that going back would actually benefit us, many path-finding algorithms may fail or struggle to utilize the fact. Take a greedy algorithm for example, which picks a path that is now possible and most decreases the distance to destination at a constant time. It will never try going back because it increases both the distance and time taken, in short sight. An algorithm that looks through every possible routes, will succeed on finding the optimal path but will still struggle, for two reasons. First, the capability of going back practically doubles the number of edges. Most of the path finding algorithms has a time complexity proportional to this number, so the solving time will double as well. Second, loop is newly introduced. A loop may cause the path finder to iterate in it indefinitely and fail eventually, so we should modify the algorithm to detect and exclude loops from its routes. This is where I thought the genetic algorithm could come to place. In a problem like this, we expect that suboptimal solutions will be a lot alike with the actual optimal solution. And in alike I mean that their paths are likely to be the same part by part. This is what the genetic algorithm directly looks for. By some predefined methods, my genetic algorithm will try to preserve the optimal part of genes (that is, sub-paths in this case) and try new types in other parts. By doing this, the genetic algorithm exceeds other algorithms in that it retains some memories and only tries solutions that are likely to be good, using prior memories. There is also some factor of "exploration" such that the solver lies not only in local optimums. One may argue that even though the amount of calculation increases due to the addition of reverse ways, it is still in a manageable range for the traditional algorithms and a modern computer to handle if the number of stations is limited to about the magnitude of a single metro line. I was also convinced by this self-argument, so I decided to complicate the problem in a useful way: adding multiple levels of expresses. There won't be many metro systems that has multiple levels of expresses in a single line, but we can think of it as an analogy of the whole transportation system that involves not only metros but also buses, trains and even airliners. Level 0 should be the slowest means such as town buses, and the highest level should be the airliner. This kind of expansion will allow the problem to be applied to a system not only with higher levels, but also with bigger number of "stations" (Think about the number of stations that you would have to pass if you were to travel from Seoul to Busan only on town bus!), where traditional algorithms will begin to fall. Now that I have pictured the problem, I formulated into a real set of stations and local/express lines. Refer to the following: Level 0 (2min): 0-1-2-3-4-5-6-7-8-9-10-11-12-13-14-15-16-17-18-19-20 Level 1 (5min): 1---------6----------11-------------16 Level 2 (8min): 0-------------------10----------------------------20 * Mr. Yi is now at station 2, and wants to reach station 19. In this setting, there are 21 stations and three level of lines in total. Level 0 line is the local line, where every adjacent stations are connected and takes a 2 minute ride between. There is level 1 line as well, and this connects every $(5n+1)$th stations with a 5 minute ride. Lastly we have the level 2 line, where every $(10n)$th stations are connected. It is the sparsest but is the fastest at the same time (10 stations in 8 minutes). Using this metro system, Mr. Yi wants to travel from station 2 to station 19. Now let's see through some example solutions: Sol1. 2-19, 34 minutes (using only level 0) Sol2. 2- 6-16 -19, 24 minutes (using level 0 and 1, no reverse direction) Sol3. 2-<span class="l

BuyBus에 들어간 기술 스택을 물어보는 이들이 종종 있어서 한번 정리해봤다. 어느 정도 경험이 있는 개발자에게는 당연한 내용이겠지만! 모든 항목을 포함하려고 최대한 노력해봤으니 이런 비슷한 걸 만들고 싶다는 막연한 상상만 해왔던 사람들에게는 꽤 유용하지 않을까 기대한다. 다이어그램이 총 세 개인데, 맨 위가 내 개발 환경과 서버, 유저 기기, AWS / Google / PayPal 등 써드파티까지 포함한 overview이고 그 아래 두 개는 overview의 server와 client 부분을 각각 확대한 것이라고 보면 된다. 세 개 모두 무려 벡터 그래픽이다! server, client 세부 아키텍쳐는 dependency-cruise라는 npm 패키지로 자동 생성했고, overview는 Figma로 직접 만들었다. Figma auto layout으로 포함 관계까지는 깔꼼하게 그려냈지만 화살표들은 어떻게 해야 하나 고민했는데, 요소 위치가 바뀌면 그를 잇는 화살표의 시종점을 자동으로 업데이트해주는 기능이 vanilla Figma에는 없었기 때문이다. 그런데 Arrow Auto라는 플러그인 깔아서 쓰니까 찰떡같이 되더라. Figma 짱짱맨 자동 생성된 server / client 아키텍쳐가 좀 무시무시하게 생겼는데,, 보기만큼 못할 짓은 아니다. 그냥 필요한 기능에 따라 서버 요청 / 클라이언트 페이지를 만들고, 재사용이 필요하겠다 싶으면 별도의 component로 분리하고, 구현할 기능이 이미 라이브러리로 존재하겠다 싶으면 구글에서 찾아서 끌어와서 쓰고, ⋯ 하다보면 이렇게 된다. 화살표가 지네끼리 너무 겹쳐있어서 하나를 똑바로 따라가기가 어려운데, 그냥 어떤 구성 요소가 있고 무슨 외부 라이브러리(빨간색 박스들)를 가져다 썼는지 정도만 봐주면 좋을 것 같다. overall server details client details

요즘 창업팀 일과 별개로 사이드 프로젝트를 하나 하고 있는데 프론트/백엔드 각각 개발이 어느 정도 진행되어서 둘을 연결할 때가 왔다(사이드 프로젝트의 정체에 관해서는 그 MVP를 배포할 때쯤 글을 쓸 것 같다). EC2에 돈 나가는 건 싫고 gunh.ee용 라즈베리파이를 나눠쓰는 건 문제가 복잡해보이니, 지난 글 에서 랜선 문제로 내팽개쳐두었던 다른 라즈베리파이를 다시 초기화해서 부팅했다. 이더넷 인터페이스는 아직도 안 잡히지만 속도는 당장 문제가 아니니 차차 생각하자구요. 라즈베리파티 우리집에 주어진 하나의 public IP를 향하는 인바운드 트래픽을 구분하기 위해 두 서버는 별개의 외부포트를 사용해야 한다. 포트번호는 SSH는 22, HTTP와 HTTPS가 각각 80과 443인 것과 같이 그 용도마다 통상적으로 쓰는 값이 있다. 그래서 gunh.ee용 서버는 그 번호를 그대로, 사이드 프로젝트용은 거기에 10000을 더한 값을 외부 포트로 삼고 공유기에서 사이드프로젝트로 향하는 트래픽을 10000을 뺀 통상적인 값의 내부포트로 translate하도록 설정해두었다. 위 세 개가 gunh.ee용, 나머지가 사이드프로젝트용이다. 진짜 이런 작업 할 때마다 전산망개론 들어놓았던 게 얼마나 큰 도움이 되는지 모른다. 감사합니다 professor Moon ︙ gunh.ee 세팅할 때 이미 한번 겪었던 우분투 초기화 과정이지만 가끔 헤매는 포인트가 아직도 있어 여기에 좀 써두겠다. (Mac 기준) 우분투 이미지를 받고 SD카드에 올려서 부팅하는 전과정은 여기 에 상세히 기술되어있다. SD카드 포맷은 디스크 유틸리티 앱에서 SD카드를 선택하고 '지우기', 'MS-DOS(FAT32)'를 선택하여 진행하면 된다. 다운받은 이미지 파일을 SD카드에 올리려면 다음 명령을 사용하면 된다. 이미지 파일은 압축을 풀지 않은 그대로 진행한다. sudo sh -c 'gunzip -c ~/Downloads/ | sudo dd of= bs=32m' 부팅을 완료하면 여기 에 기술되어있는대로 /etc/netplan/50-cloud-init.yaml 에 무선랜 정보를 입력, 저장하고 재부팅한다. /etc/network/interfaces 은 ifconfig 가 사용하는 파일인데 ifconfig 가 초기 우분투에 깔려있지 않으므로 여기에 정보를 입력하는 것은 소용이 없다.

오늘 gunh.ee 서버의 성공적인 이더넷 연결을 자축하며 쓰는 글이다. gunh.ee에 관한 충격적인 사실이 하나 있는데 그것은 바로 이를 호스팅하는 서버가 우리집 거실 TV 뒤에 위치한 라즈베리파이라는 점이다. 21년 12월 13일 처음 전원에 연결했을 때 찍어놓은 사진 많고 많은 호스팅 서비스를 두고 왜 서버 컴퓨터를 직접 구축하는 힘든 길을 선택했냐 하면... 호스팅 서비스를 사용할 경우 그 종류는 크게 두 가지로 나뉜다: 공유 호스팅과 VPS 호스팅. 전자는 웹사이트를 개시할 수 있는 가장 저렴한 방법이고 대학교 1학년 가을학기에 연 내 첫 사이트도 이 방법을 사용했다. 문제는 저렴한만큼 활용도가 떨어진다는 것. 가장 간단한 형태의 웹사이트가 돌아가는데 필요한 프로그램은 모두 지원했지만 그 외의 것을 실행할 수는 없었다. 물론 아는 게 많이 없었던 그때의 나에겐 충분히 유용했고 주어진 프로그램으로 실컷 놀고 배웠다. 시간이 흐르고 4학년 말이 됐을 때 난 내 새로운 서버로 훨씬 더 많은 걸 해보고 싶었다. node.js로 직접 웹서버를 짜서 돌리고, API를 만들고, 웹이 아닌 다른 용도에도 써보고 싶었다. 그러려면 VPS 호스팅을 써야 했다. VPS 호스팅에서는 물리적인 기기만 나에게 없을뿐 내게 할당된 공간 안에서 어떤 프로그램이라도 설치해서 쓸 수 있었다. 1학년 때 썼던 호스팅 업체에서도 VPS 호스팅을 지원했지만 자원 할당의 유연함과 평판 등을 들어 이번에는 AWS EC2를 써보기로 했다( EC2는 가상화 정도에 있어 VPS와 다소 차이가 있다 고는 하나 어쨌든 비슷). 나름 공들여 만들었던 임시 랜딩페이지 실제로 EC2 인스턴스를 만들어 도메인 연결까지 마치고 임시 랜딩페이지를 띄워놨다. 한두 달 정도가 지나고 인스턴스 사용료가 통장에서 빠져나갔다. 비용이 정확히 얼마였는지는 기억나지 않지만 감당하지 못할 수준은 아니었다. 하지만 매달 돈이 나갈 거리가 있다는 게 찜찜했고 가능하다면 이를 아끼고 싶었다. 그때 우리집에서 굴러다니던 라즈베리파이가 생각났다. 실물이 없는 소비는 아무래도 심리적 장벽이 높다 1년쯤 전에 과방에서 주워온 Raspberry Pi 3 Model B+ 2대였다. 본체가 부속 센서, 전선과 함께 상자에 담겨있고 필요한 사람 가져가라고 뚜껑에 적혀있었다. 전공 수업이나 사이드 프로젝트 마치고 남은 것들이었나보다. 그럴 생각으로 데려온 건 아니었지만 서버로서 손색이 없을 것 같았다. 성능이 구릴 건 분명했지만 어찌되었든 하나의 온전한 컴퓨터고 떨어지는 성능만큼 가만히 짱박아두기가 아깝지 않을테니까. 학기가 종강하자마자 서버 구축에 돌입했다. EC2 때보다 할 게 훨씬 많았다. EC2는 원하는 운영체제를 선택하고 포트 규칙 몇 개만 설정해주면 바로 원격 SSH 접속이 가능했는데, 라즈베리파이의 경우 주 저장소가 되는 SD카드를 포맷하고 - 우분투 이미지 파일을 받아서 부팅하고 - 네트워크 연결하고 - SSH에 포트포워딩하는 이 모든 걸 직접 해줘야 했다. 라즈베리파이에는 화면이 없는데 그렇다고 내가 외장모니터가 있던 것도 아니어서 거실 TV에다가 HDMI로 연결해놓고 바닥에 철푸덕 앉아서 작업했다. 서버가 TV 뒤에 자리잡은 것은 공유기가 가깝고 물건 이동이 잦지 않다는 이유도 있지만 SSH 연결 전까지 모든 CLI 작업을 TV를 보고 해야 했기 때문이 가장 크다. 사나흘을 거의 이거에만 매달렸다. SSL 인증서 발급해서 HTTPS 연결 뚫고 로컬에서 작성해오던 Vue.js 프로젝트 빌드해서 서버에 올리고, 마침내 아이폰으로 정상 접속을 확인했을 때 얼마나 기뻤는지 모른다. 21년 12월 18일 그때 찍어놓은 스크린캡쳐. 지금 게시물 보기 페이지와 다소 차이가 있다. 지금은 커버 이미지도, 헤더 이모지도 없다. 나는 이 사이트가 트렌디하면서도 담백하길 바랐다. 개발을 시작할 때 개인적으로 노션의 디자인이 아주 괜찮다고 생각하던 터라 노션 페이지 하나를 HTML로 내보내서 스타일시트를 싹 긁어왔다. 필요에 따라 일부 수정은 했지만 대체로 스타일을 유지하며 페이지들을 만들어나가고 있을 때 문득, 이게 담백한가?라는 의문이 들었다. 노션 페이지에 자주 등장하는 이모지들은 젊고 산뜻했지만 한편으로는 산만한 느낌을 주기도 했다. 특히 글이 주가 될 내 사이트에서는 글의 압축률을 떨어뜨리는 요인이 될 것이었다. 그래서 이모지와 이미지는 필요한 곳에만, 유채색 사용을 최대한 줄이고 페이지가 담백함을 유지하도록 계속 다듬어나갔다. 사이트를 만들면서는 조선일보 사이트 의 디자인이 괜찮다고 생각했고(정치 성향과 무관) 작년 말에 뉴욕 여행하면서 들어가 본 MoMA 와 휘트니 미술관 의 것도 지향하는 바가 비슷하다고 느꼈다. 세 개 다 들어가보면 내가 추구하는 느낌이 어느 정도 보일 듯. 사실 위의 개발기는 이 사이트의 첫 번째 와 두 번째 글 에 쓸 내용이었다. 하지만 당시에 배우고 느낀 수많은 점들을 한 글에 모두 담으려고 하다보니 중간에 지쳐버려서 결국 글을 완성하지 못하고 내팽개쳐두었다. 많은 걸 망각한 지금이 되어서야 전체 과정이 앉은 자리에서 정리가 되네. 참고 소스들 메모해둔 것도 그냥 여기에다 덤프해놔야겠다 ⋮ 요점은 이 사이트가 우리집 TV 뒤 조막만한 라즈베리파이에서 돌아간다는 거다. 즉 당신이 gunh.ee에 접속할 때마다 만들어내는 신호는 우리집을 들렀다가 당신의 기기로 되돌아간다. ... 다시 오늘로 돌아와서. 서버가 live된 이후로 블로그 글 올리는 것 외에도 꽤 많은 용도로 이 친구를 사용해왔다. 무엇보다 웹서비스 배포 시험용으로 쓰기가 아주 편리했다. 새 도메인을 파서 배포하려면 도메인 새로 사랴, 호스팅 서비스 구하랴, DNS propagation 기다리랴 이게 다 돈과 시간이었는데 gunh.ee에 서브도메인 하나만 새로 파면 이 모든 문제가 해결되는 것이었다. WLAN에 의존하던 라즈베리파이를 이더넷으로 연결시키자는 오늘의 생각도 새 서비스를 gunh.ee에서 시험해보고자 하던 도중 든 것이다. 수많은 요청-응답을 시험해보기 전 서버 연결을 최적화하는 게 우선일 것 같았다. 사실 이더넷 전환 시도는 오늘이 처음이 아니었다. 블로그 글에 이미지 로딩 속도가 너무 느리다는 생각을 항상 하고 있었다. 처음에는 라즈베리파이 연산 속도가 느려서일거라고 생각했는데, 곰곰히 생각해보니 그것보다는 이미지 크기와 연결 속도가 문제일 것 같았다. 이미지는 아이폰에서 찍은 수 MB짜리 원본이 압축 없이 그대로 들어가고 연결은 무선이니 환장의 조합이 아닐 수 없었다. 이미지 크기 문제를 해결하려면 자동 압축 파이프라인을 만들어놓아야 하는데 그건 너무 귀찮고, 일단 연결 상태라도 개선해보고자 했다. 정상적인 상황이라면 랜선을 꼽기만 해도 자동으로 연결이 수립되어야 하는데 그렇지 못했다. ifconfig를 찍어보니 이더넷 인터페이스 자체가 리스트에 없었다. 온 구글을 뒤져보았지만 어떤 해결 방법도 나한테 적용되지 못했다. 결국 일단 WLAN 현상 유지. 그게 한두 달쯤 전이다. 상황에 변화는 없었지만 오늘 다시금 필요성을 느끼고 착수. 저번과 비슷한 방법들을 다시 시도해봤고 진전은 없었다. 최후의 수단으로 놀고 있던 다른 라즈베리파이(이하 B)를 시도해보기로 했다. 주 저장소인 SD카드만 갈아끼우면 되기 때문에 전환은 쉬웠다. 문제는 B가 이전에 서버로서 활용에 실패한 이력이 있다는 것. B는 지금 돌아가던 애(이하 A)와 달리 프로세서와 랜컨트롤러에 방열판이 달려있어서 가능하다면 B를 쓰고 싶었는데, 부팅 후 HDMI로 터미널이 안 떠서 B를 버리고 A로 갈아탈 수밖에 없었던 것이다. 때문에 B를 전원에 연결하면서도 반신반의하고 있었는데, 어라? 터미널이 이번엔 뜨네? 곧이어 기대하는 마음으로 랜선도 연결해봤는데 ! 이더넷이 잡혔다. 처음부터 되진 않았고 집에 있던 랜선 여러 개를 시도하다 보니 하나가 갑자기 됐다. 하필이면 그 랜선이 다른 곳에도 활용할 수 있는 가장 긴 놈이고, A에 어떤 문제가 있는 건지 밝혀내지 못한 건 많이 아쉽지만... 그래 뭐 어때, 돌아가면 된거야. 이제 방열판도 달려있으니 더욱 잘 됐다. 돌아가면 된거야 저장소 내용은 동일해도 라즈베리파이가 바뀌면서 MAC주소도 같이 바뀌어서일지 기기의 private IP도 172.30.1.20에서 172.30.1.77로 바뀌었다. 때문에 SSH와 HTTP 연결이 모두 막혔는데, 라우터에서 포트포워딩 설정을 수정해주니 바로 복구됐다. 예전에는 해결에 반나절 걸렸을 일이 이제는 대충 상황 파악이 되고 바로 문제를 해결할 수 있다. 이럴 때 성장했음을 느끼고 기쁘다. 랜선이 연결된 B. 우리 오래오래 가자 라즈베리파이야 const notes = ` Add virtual host https://stackoverflow.com/questions/59549309/unable-to-find-a-virtual-host-listening-on-port-80-please-add-a-virtual-host Issue SSL Certificate https://certbot.eff.org/ https://certbot.eff.org/instructions?ws=apache&os=ubuntufocal Ubuntu version check lsb_release -a command https://ubuntu.com/tutorials/install-and-configure-apache#1-overview https://stackoverflow.com/questions/56291492/how-to-save-a-file-in-vscode-remote-ssh-with-a-non-root-user-privileges sudo chown -R myuser /path/to/folder https://roboticsbackend.com/install-ubuntu-on-raspberry-pi-without-monitor/ security find-generic-password -wa "KT_GiGA_5G_Wave2_****" ********** (password) https://askubuntu.com/questions/1152159/how-to-enable-wifi-on-ubuntu-server-18-04-without-existing-connection Let's Debug is a diagnostic tool/website to help figure out why you might not be able to issue a certificate for Let's Encrypt™. https://letsdebug.net/gunh.ee/816059 ReservedAddress FATAL A private, inaccessible, IANA/IETF-reserved IP address was found for gunh.ee. Let's Encrypt will always fail HTTP validation for any domain that is pointing to an address that is not routable on the internet. You should either remove this address and replace it with a public one or use the DNS validation method instead. 172.30.1.20 curl icanhazip.com (from https://raspberrypi.stackexchange.com/questions/14846/how-can-i-find-my-pis-external-public-ip-address) --> Router의 public address를 반환한다. --> 따라서 Router에서 port 80에 대해 Raspberry Pi로 포트 포워딩을 해줘야 한다. 그렇게 해서 알아낸 public address: ***.***.***.** 포트 포워딩 22->22 80->80 443->443 https://m.blog.naver.com/PostView.na

진짜 백만년만에 와보는 안암 🍓🍓🍓 아유 영광입니다 🍓🍓🍓 홍도야에선 고추튀김에 막걸리래요 ㅋㅋㅋㅋㅋ 맨정신에 다시 봐도 개웃기네 1과 2 수집 완료 저 601번 내가 갈아타야 하는 버스임 열심히 뛰어서 탑승완

안녕하세요? 복음자리딸기잼팀입니다. ... 다른 기기로 다시 들어가느라고 팀명 사과잼행 근데 사과잼 진짜 팔더라? 나 머리 왤케 산발 --> --> 포지션별 타임라인 기획·디자인 백엔드 프론트엔드 기획 디자인 프론트/백엔드 (나) 프론트/백엔드 프론트 19일 16:00 체크인, 이동 (토요코인호텔 → 타임스퀘어) 16:30 17:00 저녁식사 (온기정 타임스퀘어점) 17:30 18:00 이동 (타임스퀘어 → 올댓마인드) 18:30 19:00 주제 공개, 브레인스토밍, 아이디어 공유 19:30 20:00 20:30 주제 확정 <지하철 빈자리 예정 공유 서비스>, 세부 기획 21:00 21:30 22:00 세부 기획 및 디자인, 유저스토리 작성 및 아이디어 발표 자료 준비 AWS RDS 설정 AWS RDS 설정 React project 초기 설정 22:30 발표 준비 23:00 팀별 아이디어 발표 23:30 20일 0:00 자정 이벤트 <빙고> 0:30 1:00 와이어프레임 제작 (색상, 폰트, 페이지뷰) MySQL table schema 구상 Route 계획 1:30 2:00 이동 (올댓마인드 → 토요코인호텔) ? 2:30 준비 ? 3:00 수면 3:30 4:00 4:30 5:00 5:30 6:00 이동 (올댓마인드 → 토요코인호텔) 6:30 준비 7:00 <td class="tg-0pky sleep" colspan="2" rowspan=

작성 중입니다. 지난 19-21일 고려대학교 [ 소프트웨어 개발/연구 학회 DevKor · 디자인조형학부 비상대책위원회 · 경영대학 학생회 ]에서 개최한 <고려대학교 여름 해커톤 : 함께하는 항해>에 참가했다. KAIST 전산학부 18 톡방에 올라온 홍보글을 보고 개최 사실을 알게 되었는데, 한번쯤 해커톤을 경험해보고픈 마음이 있었고 기간도 랩인턴 출근과 겹치지 않아서 아주 좋은 기회였다. 지원 시에는 간단한 개인정보를 입력하고 자유 형식의 포트폴리오를 업로드해야 했다. 최근 들어 CV나 포트폴리오를 작성한 적이 없어 이번 기회에 아예 웹사이트에 새 페이지를 팠다. 학력·경력에 관한 내용이 원래 메인 아랫부분에 완전히 정리되지 않은 채로 올라가있었는데 이를 별도 페이지로 몰아놓으니 보기도 훨씬 깔끔하다. 관심 있다면 take a look ~ . 1,2학년 때만 해도 자기소개서를 작성할 때면 변변하게 쓸 만한 항목이 많이 없어 고전했던 기억이 나는데 그새 쓸 거리가 뭐라도 생겨 기분이 좋다. 기획자1 + 디자이너1 + 개발자3 = 팀 당 다섯 명씩 스무 팀으로 해커톤 전체 참가자 규모는 100명 가량이었다. 개발에 관심을 가진 친구 몇 명을 모아가서 함께 팀을 꾸릴까 생각도 했지만 대회의 취지와 맞지 않고 완전히 새로운 사람들과 함께 일해보는 것도 도움이 될 것 같아 혼자 지원했다. 팀에는 역할과 상관없이 리더가 한 명씩 있었는데, 지원서에 리더를 맡기를 희망하는지를 미리 기입해야 했다. 난 리더를 맡든 맡지 않든 큰 상관이 없어 "모르겠습니다"를 선택했다. 그런데 참가 확정 후에 운영진 측에서 개인적으로 연락이 와 리더를 맡을 수 있는지를 물어봤다. 리더를 희망한 사람이 스무 명이 안 되었나 보다. 부탁이 왔는데 또 거절할 수 없어 하겠다고 했다. 행사가 열리기 일주일 전인 13일 저녁에는 온라인으로 사전행사가 열렸다. 본 행사에 앞서 서비스 기획·개발을 함께할 팀을 꾸리기 위해서였다. 팀리더가 본인 소개와 만들고 싶은 서비스 등을 담아 아이디어 피칭을 진행하고, 일반참가자들은 이를 듣고 각 리더에게 합류를 신청하는 식이었다. 아이디어 피칭. 주제를 모른 채로 하는 아이디어 피칭이라, 좀 웃기긴 하지만 사전 작업이 허용되지 않고 주제가 당일 공개되는 해커톤 특성 상 불가피한 방법이었다. 이에 맞춰 나도 구체적인 아이디어를 제시하는 대신에 그간 내가 개발해왔던 것들을 소개하고 이들에 공통적으로 나타나는 동기(분야를 가리지 않는 문제의식과 실행력)를 서술하는 방식으로 진행했다. 솔직히 말하면 아이디어 피칭을 그리 열심히 준비하지는 않았다. 주어진 시간이 2분 30초로 상당히 짧았고, 리더 역할을 수락한 게 사전행사 전날이라 준비할 시간이 절대적으로 부족하기도 했다. 무엇보다, 이미 학부 5학년으로 짬이 찰대로 찬 입장에서 같은 학부생들이 해봤자 얼마나 대단한 것들을 해왔겠냐 하는 몹시 거만한 생각이 있었음을 부정할 수 없다(지원 대상은 학부생으로 한정됐다). 오우, 그런데 첫 리더의 발표를 듣자마자 비상이 걸렸다. 생각보다 준비를 너무 잘 해 온 것이다! 첫 사람만 그런 것도 아니었다, 두 번째도, 그 다음도 잘했다. 대단한 업적을 가진 이들이 있었고, 그렇지는 못해도 분명한 철학이 있고 그걸 아주 효과적으로 전달하는 이들이 있었다. 이들의 발표를 듣고 있자니 갑자기 내가 팀빌딩이라는 이 자리에서 리더로서 갑은커녕 선택받지 못하는 슈퍼을이 되는 게 아닌가 하는 불안감이 엄습했다. 내 순서는 마지막에서 4-5번째, 순서가 오는 동안 나도 내 철학을 급조해 넣었다. 그리고 부끄럽지는 않지만 그렇다고 아주 만족스럽지도 않은 발표를 마쳤다. 역시 방심과 자만은 금물, 종종 세상과 부딪히며 내가 얼마나 작은 존재인가를 되새길 필요가 있다.

이번 가을학기가 시작할 때쯤 갑자기 컴퓨터 그래픽에 관심이 생겼다. 그리고자 하는 물체들이 삼각형 표면들로 표현되고 각각을 평면에 사영시켜 표시할 픽셀의 위치를 찾는다는 정도의 막연한 지식은 가지고 있었지만 사영에 필요한 기하학이나, 텍스쳐/조명 등에 대해서는 아는 것이 전혀 없었다. 그래서 이런 것들을 배워가면서 그래픽 엔진을 직접 만들기 위해 참고할 자료를 찾던 중, 아주 적합한 유튜브 튜토리얼 이 눈에 띄었다. OpenGL과 같은 그래픽 라이브러리를 일체 사용하지 않고, 컴퓨터 화면에 대한 인터페이스라곤 개별 픽셀에 해당하는 문자를 특정 위치에 출력하는 함수 하나밖에 사용하지 않았다. 총 네 편으로 구성되어 기본적인 사영 기하학부터 텍스쳐까지 다루고 있었다. 내가 찾던 가이드와 완벽히 일치했지만 한 가지 문제점이 있었다. 픽셀을 출력하는 함수가 Windows의 콘솔 API에 속한, Windows에서만 작동하는 함수였던 것이다. 맥북을 사용하는 나는 이를 대체할 함수를 찾아야 했는데, XCode를 이용하면 비슷한 기능을 가진 콘솔 어플리케이션 개발이 가능할지도 몰랐다. 하지만 개강을 앞두고 새로운 개발 도구를 팔 자신이 없었기에 일단 진행을 멈추기로 했다. 그리고 학기가 끝난 이번주, 다시 개발에 착수했다. 오랜만에 자리에 앉으니 새로운 목표가 하나 생겼다. 이번에는 외부의 자료 중 어떤 것도 참고하지 않고, 이미 내가 가지고 있는 지식만을 총동원하여 그래픽 엔진을 만들어보자는 것이 그것이었다. 성능 최적화보다는 원리 이해가 우선이었으므로 생각을 빠르게 옮길 수 있는 파이썬을 사용하기로 했다. 픽셀 그리기는 그냥 콘솔 전체를 덮을 크기의 2차원 문자 배열을 생성, 조작하고 그걸 그대로 출력해내면 될 것이었다. 바로 코드를 써봤다. 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 from time import sleep, time class XY: def __init__( self , x, y): self .x = x self .y = y WIDTH, HEIGHT = 100 , 30 SCREEN_BASE = [[ ' ' for _ in range (WIDTH)] for _ in range (HEIGHT)] SCREEN = SCREEN_BASE.copy() def clear(): SCREEN = SCREEN_BASE.copy() def fill(xy): SCREEN[HEIGHT - 1 - xy.y][xy.x] = '▇' def render(pixels): clear() for pixel in pixels: fill(pixel) output = ' ' .join( '' .join(col for col in row) for row in SCREEN) print (output) for i in range ( 30 ): render([XY( 3 * i, i)]) sleep( 0. 1 ) <a

얼마 전에 Nupjuk!의 활성 사용자 수가 1400명을 넘었다. 사용자 중 대학원생이 소수라고 가정하면 KAIST 학부생의 40% 가량이 이를 쓰고 있는 셈이다. 오늘은 이를 기념해서 Nupjuk!에 관한 이야기들을 한번 정리해보고 싶었다.* [4] 21일 기준 최다 활성 사용자 기록은 1420명이다. 최근 한 달간 사용자 증가는 대략 50명 정도인데, 사용자가 하루에 100명씩 늘던 3월 초보다는 아주아주 느려졌지만 그래도 꾸준히 상승세다. [5] 수많은 컴퓨터에 깔린 프로그램은 새 버전이 공개될 때마다 하루이틀 새에 전부 업데이트된다. 이 그래프에서 또 하나 재미있는 점은 아주 규칙적으로 실행 수가 급격히 떨어졌다 회복된다는 것인데, 아니나다를까 이때가 주말이다. 중간고사 기간이던 4월 셋째주 주말에는 하락이 거의 없었고, 그 바로 다음주에는 하락폭이 가장 컸다. [6] Nupjuk!을 구동하는 학내 Mac의 점유율은 13% 정도다. 국내 점유율(약 8%)보다는 훨씬 높지만 내 예상보다는 낮았다. Linux 점유율은 국내 점유율의 3배 가량인 2%나 된다. [7] 3월에 한 외국인에게서 내 익스텐션을 팔라는 메일을 받은 적이 있다. 메일 본문에 Nupjuk!을 특정할 수 있는 내용이 없는 것으로 보아 유망한 익스텐션들을 추려서 뿌리는 대량 메일인 듯했다. 팔 생각이 없으니 답장을 안했는데, 요즘 다시 생각해보니 얼마 줄건지는 한번 물어볼걸 그랬다. [8] 돈을 벌지는 않았지만 감사하게도 몇몇 분께서 기프티콘을 선물해주셨다. 2.0 공개 직후 프로그램 너무 잘 쓰고 있다면서, 혹은 요청한 새로운 기능들을 개발해드린 보답으로 보내주셨다. 받은 기프티콘들 모두 맛있게 잘 먹었습니다/먹을게요. [9] 총학생회에서도 메일이 왔었다. 신규 LMS에 대한 불만이 많아 학생들의 의견을 수합하여 학교에 전달할 예정인데, Nupjuk!을 참고자료로 함께 제시해도 되겠냐고. 당연히 그러시라고 했다. 더불어서 추가로 하고 싶은 피드백이 있으면 알려달라고 했는데, KLMS를 뜯어보면서 정말 많이 실망했던 차라 거의 항의에 가까운 글을 써서 보냈다. 근데 KLMS의 개발 주체를 알게 된 지금은 좀 후회 중이다. 나는 당연히 어떤 외주 개발사가 큰 돈을 받고 만든건줄 알았지, 학교 직원분 두 분이서 도맡아서 개발하고 있을 줄은 상상도 못했다. 학생회에서 피드백을 좀 순화해서 보냈기를, 그리고 앞으로는 학교에서 LMS 사업을 좀더 심각하게 받아들여주기를 바란다. [10] 마지막은 Nupjuk!에 달렸던 평가 중 하나. 내 인생 최고의 극찬이다. * 우리 학교가 아닌 이들을 위해 첨언하면, Nupjuk!은 KAIST LMS의 사용을 더 편리하게 하는 크롬 익스텐션이다. KLMS는 이번 학기 개편되어 아직 개발이 미흡한 부분이 많은데, 앞으로 차차 개선될 예정이지만 시스템을 매일 사용하는 학생들은 그 사이에 불편을 겪을 수밖에 없다. 그래서 지난해 말 개발했던 KLMS VOD Controller에 [2-3]에 나와있는 항목들과 색상 테마, 아이콘 벡터화 등의 기능들을 추가하여 불편을 최소화하고자 했다. 그러면서 이름도 바꾸었는데, 새로운 이름은 KAIST의 마스코트인 넙죽이[1]에서 따왔다. 원본: 2021년 5월 21일 인스타그램 업로드

원본: 2019년 7월 27일 인스타그램 업로드