JeongHun Kong's Blah Blah

첫 프로젝트 (스마트 공장 지원 사업)

관련 프로젝트의 Portfolio는 여기를 참고.
2019.06 ~ 2020.02 까지 근무하는 동안 프로젝트를 맡아 진행했었다.

국책과제로 스마트 공장 구축,보급 지원 사업의 일환으로 삼성 주관 대중소 상생형 스마트 공장 지원 사업 유형 1-b를 진행하게 되었다.

프로젝트 규모는 총 1억1천만원의 비용에 6000만원의 지원금이었으며, 삼성측 멘토가 파견되어 사업 진행에 도움을 주는 방식으로 진행되었다.

Tech Stack

기술 스택은 다음과 같이 정리된다.

• Webserver
  • Apache2
  • bind9
• Database
  • MySQL (Main Database)
  • Redis (For push-alarm sevice)
• Servier Side
  • Laravel (php)
  • Laravel Echo (socket.io)
• Client Side
  • React & MobX (javascript)
  • Echo (socket.io)
• Source Code Management
  • git & github
• CI|CD
  • github webhook
  • jenkins

언어 사용에 있어 큰 무리가 없게 언어 자체를 바꾸는 일은 없게 선택했으며, React는 이전의 jQuery보다 체계적으로, 재사용 할 수 있게 개발 하기 위해 선택했다.

본인은 React를 이전 부터 사용했고, 공모전 출전 경험도 있어 큰 무리가 없었지만, 사수는 처음 접하는 것이라 걱정되었다.
다행히도 금방 익숙해 졌으며 속도도 붙어 무리없이 완수할 수 있었다.

이전 작업

이전 작업은 이전보다 훨씬 수월하게 진행되었다. 이미 어느 정도 정리된 코드 덕에 완전히 재 구현하는 수준의 작업은 아니었고 마크업만 React로 재구성하면 되기에 수월하게 진행되었다.
Laravel이 관리해주는 라우트와 컨트롤러 덕에 쉽게 기능을 나눌 수 있었고, 사수도 React에 금방 적응하여 빠르게 옮길 수 있었다.

작업 초기에는 MobX를 사용하지 않고 오롯이 React만 사용하려 했었다. Context Api나 Redux같은 어려운 개념을 먼저 경험하는 것 보다, 불편함을 겪고난 후 해결책을 보는 것이 더 머리에 깊이 기억되기 때문이었다.

당연히 진행하면서 사수는 몇단계를 거치면서 내려오는 핸들러 함수나 prop에 대해 해결책이 없느냐고 물어왔고 그때 상태 관리 라이브러리를 언급했다.
이렇게 MobX가 선택되었고, 차질 없이 진행되었다.

Crawler

이전 작업이 모두 끝나고, 기존 협의했던 기능인 Crawler를 만들게 되었다.
원하는 기능은 다음과 같이 정리된다.

1. 원청에서 배포되는 일정표를 사용해야 한다.
2. 원청에서 배포되는 일정은 2가지 내용이 누락되어있다.
   1. 제작품의 Option 사항
   2. 제작품의 도면 번호
3. 원청에서 배포되는 일정표를 2.의 내용이 포함되게 편집해야 한다.
4. 배포된 원본 일정표를 내려받을 수 있어야 한다.

사실 이 크롤러 관련된 이야기는 이전의 파트타임에서도 언급되었었지만 기간 문제로 기각 되었었다.
이번 사업을 기회 삼아 개발하게 되었다.

크롤링 라이브러리는 Webklex/laravel-imap을 사용했다. javascript 런타임을 내장하고 있어서 쉽게 원하는 결과를 얻을 수 있고, 지속적으로 업데이트되고 있기에 선택했다.

다행히도, 크롤링 하려는 사이트가 복잡하지 않고, 비동기 처리가 많지 않아서 쉽게 원하는 정보를 얻을 수 있었다.

처리 과정은 다음과 같이 설계했다.

1. 특정 사내 메일 주소를 모니터링 한다.
2. 수집된 이메일 목록을 반환 받는다
3. 신규 일정표를 배포받은 것을 감지한다.
4. 일정표 내용을 파싱해 호기 번호를 순회한다.
5. 원청에서 제공하는 SRM에서 옵션 사항을 크롤링한다.
6. 이를 배포 받은 일정표를 파싱한 데이터에 포함한다.
7. DB에 이를 반영한다.

위 과정을 보면 2개의 크롤러가 필요함을 알 수 있다.

EmailCrawler 제작 당시, 초기에는 단순하게 curl로 요청해 받은 결과를 html 파싱하려 했지만, 자바스크립트 런타임이 필요함을 알게 되어 위에 언급한 라이브러리를 사용하게 되었다.
메일 서비스 측에서 이메일 송수신 관련 API를 제공하지 않기 때문에 직접 주기적으로 모니터링 하고 있어야 했다. 이중 메일 제목과 첨부 파일의 제목을 기준으로 일정표 배포 여부를 확인해 모든 과정이 진행 되도록 만들었다.

OptionCrawler 또한 같은 라이브러리를 사용해 만들었다. 전달 받은 호기 번호를 통해 해당 호기 번호에 포함되어야할 옵션 사항을 고객사에서 제공하는 SRM에서 검색해 반환하도록 만들었다. 초기에 timeout이 발생했지만, php 설정을 이용해 해결 가능한 수준이었다.

이후 운영 중에 배포 여부를 알 수 없다는 (실제로, 배포 된 이후에 메일을 직접 보지 않으면 알 수 없었다.) 불편이 신고되어 Laravel Echo와 Redis로 알림 서비스를 만들어 배포했다.

발주서 관련 크롤러도 제작했다.

기본적인 흐름은 동일하며 수집된 데이터는 사내 BOM을 만들기 위한 초석으로 사용되었다.

퇴사

프로젝트를 무사히 마친 후, 퇴직 절차를 밟았다. 산업기능요원으로 계속 근무 할 수 없다는 것을 알게 되어 퇴직하게 되었고, 지인과의 정으로 유지보수를 조금씩 돕게 되었다.
간단한 변경 요청이나, 오류들을 학기 동안 잡아 나갔으며 다른 산업기능요원을 채용하고있는 IT업체에 계속 연락을 넣었다.

이 프로젝트를 진행한 기간이 내가 크게 성장 할 수 있던 기간이었고, 좀더 짜임새 있는 개발을 할 수 있던 기간이었다.
처음으로 Web application framework를 다뤘으며, React를 활용해 규모 있는 client를 구성했고, 이에 따른 성능 문제도 경험하고 개선할 수 있었다.

쿠팡 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.

KG System 홈페이지

다시 출근

이전의 파트타임 이후, 학기를 마친 나는 다시 파트타임으로 채용되었다.
2018.01 ~ 2018.02, 최저 시급으로 일할 수 있으며 본격 적으로 배운 것을 써먹으려 했다.
이 당시 나는 웹 프로그래밍을 막 이수한 상태였고, 드디어 뭔가 제대로 하겠구나 라는 생각으로 들떠있었다.

저번 과는 달리, 컴퓨터와 자리를 배정 받아 셋업 할 수 있었다.
Windows 환경, Autoset으로 개발 환경을 서비스 할 수 있게 설정, PHP, Visual Studio Code, git으로 설정을 마치고, 업무 분담을 위해 미팅도 가졌다.

내가 맡은 업무는 다음과 같았다.

• 사이트 리뉴얼을 위한 Repository 설정
• Jenkins로 자동 배포 설정
• 하네스표 관리 페이지 (2017년도 결과물) 이전 및 데이터 이전
• 생산관리 기능을 제외한 다른 기능들 이전 및 Bootstrap4 적용
• SPA (Single Page Application)으로 동작

기술 Stack 선정

기존의 사이트는 지인이 독학으로 구축하여 데이터 요청 로직과 뷰가 혼재되어있는 스파게티 코드가 대부분이었고, 라우팅은 디렉토리로 하고있었다. SPA로 구축하길 원했었고 이를 위한 라우팅 방식도 필요했다.

이에 나는 아예 언어를 바꾸고 Framework 도입을 생각하는게 어떻겠는가 제안을 했고, 테스트 개발을 진행했다.
채택된 사양은 아래와 같다.

• node
• express
• mongoose
• mongodb
• pug + jquery

직전 학기 웹 프로그래밍 수업에서 사용한 Stack을 그대로 빌려와서 진행해보려 했다. 그러나 여기서 문제가 발생했다.
본인은 당연히 학습한지 오래 지나지 않아서 금방 결과물을 볼수 있었으나,
금방 따라갈 수 있을 것이라 예상했지만, pug와 node에 적응하지 못했다.
물론 시간만 있다면야 배워서 써먹으면 되겠지만, 현실은 정해진 시간 내에 결과물을 만들어내야 하기 때문에 그럴 수 없었다.

결국 stack은 다시 php로 회귀되었다.

리뉴얼 시작

라우팅 문제는 나중에 해결하기로 하고 일단 작업에 착수하였다.
2017년도에 내가 개발한 기능 (하네스표)를 옮기는 것은 문제되지 않았다.
목록을 별도로 구성해 iframe으로 불러오는 방식을 php로 파편화해서 SPA로 동작하게 변경했고
기존의 데이터 다루는 부분은 그대로 옮겨 적용했다.

일이 금방 진행되어 방학 동안에 금방 할 수 있을 것으로 생각했었다.

그러나 그건 오산이었다.

다른 기능들이 앞서 말한대로 스파게티 코드란 것을 잊고있었다.

루프 내 쿼리 질의가 있었고, 동시에 필터링도 있었고, 동시에 마크업도 있었다.
분석이 우선이었고, 사용중인 기능에 문제가 없어야 했다.

그래서 우선 마크업을 별도로 정리하기로 했다.

루프 내에 있는 마크업, 분기 별로 다르게 나와야 하는 마크업을 주석으로 표시하고,
데이터 색인부분을 다시 파일 상단으로 올려 변수에 저장하게 변경했다.

이후 같은 문법으로 마크업을 정리하고 기능을 테스트했다.

당연히 당시엔 TDD도 몰랐으니 모든 테스트는 직접 사용해보는 것으로 진행했다.

굉장히 오래걸리고 지루한 작업이었지만, 스파게티가 다시 정돈된 재료로 돌아가는 것을 보니 견딜만 했다.

이건 또 무슨 에러? (이벤트 중복)

작업하며 격은 에러중에 가장 기억에 남았던 것은 이벤트가 남아있어 페이지가 오작동하는 것이었다.
jQuery를 사용하며 생길 수 있는 흔한 에러였지만, 기본 지식이 부족했던 상태라 찾는데 애먹었다.

페이지 전환을 발생하게하는 버튼을 예로 들어보자.

$('#activity-changer').click(e => {
e.stopPropagation();
$.ajax({ /* 페이지 리소스 요청 설정 */})
.then((response) => {
$('#content').html(response)
})
.catch(() => { /* 에러 핸들링 */ })
});

이벤트 전파도 막고, 비동기 문제도 해결하고, 에러 핸들링도 했다.
문제가 없을 것이라고 생각하고 다른 페이지의 코드 조각에도 같은 코드를 작성했다.

이때 문제가 생겼다.
activity-changer라는 id 버튼 엘리먼트를 그대로 사용했다.
당시 생각엔 이전의 이벤트 핸들러를 덮어 쓸 것이라 생각했지만 큰 착각이었다.

/// a.php
$('#activity-changer').click(...)
/// b.php
$('#activity-changer').click(...)

이렇게 b.php의 버튼은 b.php의 핸들러만 수행해야 하지만, a.php의 핸들러가 없어지지 않은 상태로 클릭 이벤트를 처리하게 되었다.
그래서 사용자가 원하는 페이지로 전환되는 것이 아닌, 이전의 페이지에서 선언한 로직이 실행되는 오작동을 한 것이다.

이후 해당 에러의 원인과 해결방법을 찾았다.
주로 동적 생성된 엘리먼트의 이벤트 바인딩에서 자주 발생하는 실수임을 알았고, 이를 해결하는 방법은 해당 이벤트를 언바인드 하는 것임을 알게 되었다.

$('#activity-changer').off('click');
$('#activity-changer').click(...)

$.off 로 더 이상 클릭 이벤트가 중복되게 바인드되는 현상은 없어졌다.

조금 더 깊이 찾아보니 D2에 정리된 글을 찾을 수 있었다.

아래 4가지는 위에 정리된 글의 마무리를 가져온 것이다.

1. 실제 DOM 요소에 등록되는 이벤트 핸들러는 사용자가 정의한 이벤트 핸들러가 아니라 jQuery의 이벤트 핸들러다.
2. 같은 이벤트에 이벤트 핸들러를 여러 번 등록해도 처음 한 번만 실제로 등록되고 나머지는 내부에서 큐 형태로 관리된다.
3. 요소에 설정되는 이벤트 정보는 내부 캐시에 저장된다.
4. special 이벤트 훅을 사용하면 특점 시점에 이벤트를 제어할 수 있다.

마무리

이렇게 내가 배운 것을 여러 방면으로 시험해보며 방학이 끝나고 나는 다시 복학했다.
이때 배운 것 덕분에 2018년도 여름학기 팀프로젝트에서 웹 분야의 담당으로 참여할 수 있었다.

쿠팡 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.

낙하산

처음 이 회사에서 일하게 된 계기는 지인을 통해 소개받은 자리로, 흔히 말하는 낙하산 같은 느낌이었다.
그 당시 본인은 대학 2학년 1학기를 마친 여름이었으며 할 줄 아는것은 jquery 조금과 html 마크업, php 조금이었다.
database의 이해도는 간단한 CRUD만 수행하는 정도였으며 쿼리의 성능이나 중요도를 따질 수 있는 실력이 아니었다.

그럼에도 내가 이 직장에서 일할 수 있게된 것은 지인의 말 덕이였다.

지인: 웹 개발좀 할줄 아니? 어려운거 안시킬게.

내가 아는 선에서 적당히 굴리면 될 것이란 생각으로 승낙했고, 그렇게 첫 출근이 시작되었다.

첫 출근

첫 출근 당일, 프로그래머로서의 첫 일이라는 생각에 들뜸과, 첫 사회생활이라는 긴장감 속에 하루를 보냈다.
업무 형태, 범위, 급여등의 여느 회사라면 가질 회계팀과의 논의는 없었고, 바로 내 개발 환경 설정 및 소스 코드 인수를 시작했다.

인수 받은 프로그램은 제법 규모가 있는, Native PHP로 작성된 생산관리 프로그램 및 인사 관리 프로그램이었다.
날 '꽂아준' 지인이 근 1년간 맨땅에 헤딩하며 일궈온 결과물로 규모도 제법 컸으며 특허까지 받아낸 프로그램이었다.

첫 업무

이렇게 정신없이 첫 출근이 지나고, 지인은 나의 업무를 설명해 주었다.
엑셀 파일을 읽어 DB에 저장하고, 이를 엑셀 파일과 최대한 동일한 모양으로 표현해 달라는 것이었다.
나는 당시까지 배웠던 짧은 지식으로 어렵지않게 구현해 내었다.

그러나 문제가 있었다. 엑셀 데이터 자체가 일반적인 의미로서 작성된 내용이 아니었다.
엄청난 양의 서식, 작성자만의 규칙이 녹아있어 이를 프로그램으로 녹여내야 했다.

작성자 본인도 넘겨주는 파일에 어떤 내용이 담겨있는지 다 알고있지 않을 정도로 많은 규칙들이 있었고 개중에 규칙이라 할 수 없는 내용까지 포함되어있었다.

작업을 계속 할 수록 알수 없는 규칙까지 녹이기 위해 코드는 점점 스파게티코드가 되어가고, 점점 더 유지 보수와는 거리가 멀어지게 되었다.

극단의 조치

결국 프로젝트 책임을 맡은 차장이 아예 양식을 새로 만드는 것을 제안했다. 알 수 없는 규칙, 작성자 많의 표기법은 최대한 표준화 하고
많은 파일로 분리되어있는 필드도 다시 하나로 모아 정리하며 작업을 진행했다.
기존의 작성한 코드도 절반은 무용지물이되어 파싱 부분만 살릴 수 있었다.
데이터의 분석은 차장이 맡아 진행하게 되었고, 분석되어 만들어진 정형화된 데이터로 다시 작업을 이어 간신히 방학기간 내에 프로젝트를 완수 할 수 있었다.

결과물 병합

마무리된 코드를 이제 원래의 소스코드와 합쳐 서비스해야하는 단계에서 해프닝이 있었다.
기존 소스코드는 비전공자인 지인이 불편함을 해소하고자 독학으로 배우며 별다른 형상 관리 툴 없이 1인 개발로 진행해왔기 때문에 본 서버에 적용하려면 코드를 덮어 씌워야 했다.
당연 버전관리는 없었고 잘못 적용한 순간 대 환장 파티가 일어나게 되었다.

프로젝트를 합치기까지는 성공했지만 이게 제대로 합쳐진건지, 버전은 맞는지 확인 할 수 없었고, 이후에 다른 직원의 오류 신고로 잡아낼 수 밖에 없었다.
변경 요청사항을 적용하는 것도 마찬가지 였고 이 상황이 너무 비효율 적으로 보였다.

GIT 과 SourceTree

결국 지인과 논의를 통해 GIT을 도입하기로 했다.
당시 직전학기에서 공개 SW 강의 시간에 Git을 써본 경험이 있어 크게 어렵지 않게 적용할 수 있었다.
지인의 계정으로 개인 저장소를 만들고 거기에 소스코드를 올려 버전관리가 시작되었다.

이후의 변경 사항, 버그 수정 등의 결과물을 병합하는데도 쉽게 할 수 있었고 소스트리 덕에 cli에 익숙치 않은 상태로도 충분히 git을 활용 할 수 있었다.

다만 도중에 충돌이 발생되어 해결 할 수 없는 경우가 일어나면 지식 부족으로 커밋을 돌릴 수 없어 저장소를 초기화하며 진행했다.

방학이 끝나고

이렇게 처음으로 돈을 받아 수행하는 프로젝트는 방학과 함께 끝나고, 나에겐 큰 발전이 있었다.
학교에서 배운 내용들이 무었을 의미 했는지 뼈저리게 느낄 수 있었다.

• 아키텍처의 필요성

  • 당시 내 수준은 주니어 프로그래머에도 미치지 못한, 갓 발을 디딘 수준이었다.
    때문에 내가 짠 코드는 거의 스크립팅 수준으로 파일로 구분된 기능 정도였고, OOP, SOLID는 생각도 못하고 적용하지 못했다.
    이 코드를 후에 다시 보니 아무리 주석을 잘 달았어도 리팩터링은 커녕 분석 조차 힘에 겨워 새로 만들게 되었다.

• 실무는 협업

  • 이때 까지 대부분의 개발 경험이 혼자 하는 개발이다 보니 클린 코드의 개념이 없었다. 이 기간동안 작성된 코드는 이후에도 유지보수하기 어려웠고, 지인도 건들지 못하는 코드가 되었다.

2017.06 ~ 2017.09 동안 파트타임은 내게 프로그래머로서의 첫 소득이자 직업으로서의 확신을 얻게 된 계기가 되었다.

쿠팡 파트너스 활동을 통해 일정액의 수수료를 제공받을 수 있습니다.