• [2021][Unity] Webgl 화상면접 공간 개발

    주목적 : 메타버스 진행하기 전 샘플 테스트


    조건 : 멀티플레이 + 화상 + WebGL


    기간 : 11.03 ~ 11.25

    개발 SDK 선정

    멀티플레이 ->  https://www.photonengine.com/

    화상채팅 -> https://www.agora.io/en/

  • [2021] OpenAPI를 이용한 Xamarin Android 앱 개발

    개발배경

    닷넷에서 Maiu(Multi-platform App UI)가 출시된다고 해서 샘플 프로젝트를 받아서 테스트해본 결과, 아직 프리뷰 버전이라서 아직 테스트 및 학습하기에 부족하다고 판단되었습니다. 그래도 결국은 하나로 통합될거라 생각되어 Maui의 뿌리가 되는 Xamarin을 알아두면 나중에 도움될듯 하여 공부를 하던중에 평소 지인이 요청했던 앱을 개발하게 되었습니다. 


    프로젝트설명

    - 유기농업자재 목록을 조회
    - 정부 사이트에 있는 내용(OpenAPI)
    - 고령층이 주로 사용하기에 간단하고 큰 UI


    개발후기
    간단한 앱을 만들어서 그런지 장점보단 단점만 보였습니다. 휴대폰의 내장된 디바이스기능을 이용하지 않을 거라면 굳이 Xamarin을 사용할 필요 없이, Unity로 만드는 편이 더 낫습니다.

    - 원하는 디자인을 만들기 위해서 플랫폼 별로 렌더를 새로 만들어야 합니다.
    - 기본 용량이 큽니다. 
    - 특별히 성능이 빠르다는 느낌도 없습니다.
    - 단순 페이지 전환 애니메이션도 생각보다 부드럽게 동작하지 않습니다.

    Maui에서는 얼마나 변경될지 모르겠지만, 현재로서는 kotln이나 flutter  를 사용하는게 더 나은듯 합니다. 



  • [2015~ ]개인 제작중인 게임..

    장르 : 로그라이크

    장르선택이유
    1. 개인적으로 좋아하는 장르.
    2. 매니아층 보유.
    3. 수익성 문제로 게임회사에서 투자를 안함. (하지만 개인단위라면??)
    4. 즉 장르가 겹쳐서 경쟁에서 밀릴 가능성이 전무.

    개발을 진행하며서..
    - 던전 플레이 뼈대 생성 - 랜덤 던전생성, 실시간 턴이동, 마법, 애니메이션 등등
    기본 던전 플레이 뼈대가 생성되니 다 만든것 처럼 느껴졌는데.. 이제부터가 시작인걸 그때는 알지 못했다.

    스토리도 좀 있으면 좋겠네?
    - 월드 맵은 크고 다양하게(마을, 농장, 언덕, 사막, 성, 숲, 전초기지)
    - 회사다니며 짬짬히 맵만드는데 1년 경과(맵 디자인이 개발보다 힘들구나...)
    - 맵이 커진만큼 생각해야 될 스토리 구성이 많아짐

    자 이제 맵도 대충 다 만들었고 뭐가 남았지??
    - 각종 무기 캐릭터 애니메이션
    - 던전 레벨디자인
    - 상점, 인벤토리
    - 웹서버, DB서버

    등...... 
    (시간이 부족해.....)

    결론
    프로젝트 축소
    뼈대는 어차피 공통이니 프리퀄 형식으로 간단하게 개발로 목표 변경
    맵을 1/100 로 축소시켜서 만든 후 개발중...


    결론2
    URP 변경




  • [2021] Promethues & Grafana 를 이용한 서버 모니터링 구축


    개발배경
    회사에서 운영중인 원격프로그램의 서버가 증성되면서 관리가 힘들어졌기 때문에 , 실시간으로 서버의 상태를 모니터링 해서 장애대응할 필요가 생겼습니다. 원래는 익숙한 Elastic + kibana를 이용할 생각이여있지만 이사님께서 지나가는 말로 프로메테우스를 언급하셨기에, 나중에 비교해서 말씀드리기 위해 프로메테우스로 진행했습니다. 

    진행해보니 둘다 장단점이 있었는데 확실히 Elastic보다는 학습난이도도 낮고, 사용하기도 더 편리해서 생각보다 빨리 구현할 수 있었습니다. 

    프로젝트설명
    - DB 트랜젝션 모니터링
    - WebService 모니터링
    - 시스템 상태, 사용량 모니터링
    - 장애발생시 회사 메신져로 알리기 위한 웹서비스 개발

    담당업무
    - 단독개발

    사용기술
    Prometheus, Grafana, Blazor, Docker

    운영하면서..
    모니터링 대상서버에서 수집해오는 형태이기 때문에, 서버를 여러대 늘리거나, 메인이되는 Prometeheus 서버를 변경하는데 어려움이 없었고, 장애 알림을 설정하는것도 간단해서 관리하는데 힘이들지 않았습니다. 단순 시스템 Metric을 모니터링하는 것 뿐이라면 확실히 Elastic보다는 좋은 듯 합니다. 그러나 애플레케이션에서 발생하는 정보들을 수집하는 방법이 번거롭기 때문에 개발&업데이트가 진행되는 구조의 서버를 관리한다면 다른 솔루션을 사용하는것이 더 좋을듯합니다. Prometheus는 안정적으로 변화가 없는 시스템을 모니터링하는쪽이 더 적합한듯한 느낌이 들었습니다. 




     

  • [2021] PostgreSQL Streaming Replication

     
    개발배경
    기존 서비스되고 있던 원격프로그램 DB가 매일 수동백업이 이뤄지고 있는것을 보안하기 위해서 실시간 백업을 적용기능 개발에 투입되었습니다. 레퍼런스를 찾아보니 간단하게 구현가능할거로 생각되었지만, 현재 DB시스템이 윈도우 환경에서 동작하고 있었기 때문에 Pgpool의 기능을 사용할수 없었고, 리눅스서버에 Pgpool을 두어 프록시로 사용하고, 윈도우용 로컬 서버를 중간에 두어서 프록시 서버와 연동을 시켰습니다. 

    프로젝트 설명
    - Master Slave 이중화 구현
    - Master 장애 발생시 Slave로 자동 Faliover 기능 구현
    - 장애 발생시 알림기능 추가
    - 관리용 웹페이지 추가


    담당업무
    - 사전조사, 구현 및 테스트, 실무자에게 리뷰 및 구축 방법 메뉴얼 전달.

    사용기술
    - PostgreSQL, pgpool, Docker ,Net5, Blazor

    개발이슈사항
    실제 해당제품 개발자는 별도로 있었기 때문에, 테스트 서버구축해서 리뷰 및 메뉴얼을 전달하는 것이 주 목표였습니다. 
    운영서버에는 실제 담당자가 새로 구축해야 하고, 윈도우환경이라 웹서버가 실행되야 했기 때문에, 오히려 관리용 웹페이지를 생성해서 원클릭으로 환경구성을 가능하게 만들수가 있었습니다. 
  • [2020] ElasticSearch및 Kibana를 이용한 모니터링 시스템구축

    개발배경
    ReportViewer를 웹용으로 개발을 하게 되면서 다수의 클라이언트나 서버에서 발생하는 정보들을 통합해서 , 오류 확인 및 통계 성능측정을 해야할 필요가 생겼습니다. 기존에 NLog 등을 이용해서 어플리케이션 단위로는 확인했었지만 좀더 체계적이고 관리가능한 프레임워크를 이용하고 싶어서 ElasticSearch 와 Kibana를 선택하게 되었습니다. 

    프로젝트설명
    - 모든 로그를 Elastic에 기록
    - 각 스텝별 진행상태 및 수행시간 측정
    - 각 서버별 시스템 자원상태 분석
    - 유저별 접속 정보 통계 분석

    담당업무
    - 단독개발

    사용기술
    - ElasticSearch, Kibana, Metricbeat, Apm






      
  • [2020] Blazor를 활용한 리포트뷰어

      



    개발배경

    .Net Framework 버전으로 개발되었던 인쇄모듈은 윈도우에서만 동작되고, 설치를 필요로 했기 대문에 이 단점을 해결한 웹버전으로 개발할 필요성이 생기게 되었습니다. 
    그래서 후보군으로 생각했던 HTML5 Canvas, Typescript, Unity, Blazor 의 프로토 타입을 개발해보고 최종적으로 가장 합리적인 Blazor를 통하여 개발을 진행하게 되었습니다. 

    각 모듈별 채택되지 않은 원인
    HTML5 Canvas - 렌더링 품질문제(폰트 확대시 계단현상발생).
    TypeScript - C# 스크립트를 동적으로 실행할 방법이 없음.
    Unity - 브라우저 인쇄시 현재 렌더된 화면만 인쇄가능.


    담당업무
    - JS , CSS를 제외한 BackEnd 서버 개발, Linux 셋팅, Nginx 웹서버, 로드밸런싱 구성
    - 현재 유지보수 단계에서는 단독으로 담당중.


    사용기술
    - Net5, Blazor, Nginx, Docker

    개발이슈사항
    - 막연히 클라이언트로 실행되는 WASM이 성능상 이점이 있을것으로 생각했으나, 현재(2020년) Blazor를 통한 WASM은 싱글스레드로 동작되어 성능이 낮은 문제가 있었습니다. 
    - 더 큰 문제는 WASM에서 브라우저로 데이터를 전달하는 과정에서 Json Serialize 시간이 1MB 당 1초정도로 오래 걸리는 문제가 있었습니다. .Net 버전이 증가함에 따라 속도 향샹이 있었지만 서버처럼 1/100로 속도가 단축되지 않는이상 의미가 없다고 생각되어 Server-Side로 변경을 진행했습니다. 
       (앞으로 기술 발전에따라 성능이 개선될거라 생각되어 양쪽 버전 전부 동작되게 소스를 관리중입니다.)
    - Server Side로 작업을 진행하니 다중 사용자에 의한 성능 부하 발생이라는 문제점이 생겨나게 되어 프록시서버를 통한 로드밸런싱 및 다수의 서버에 일관성있는 배포를 위한 도커환경을 구성하게 되었습니다. 
  • [2020] Unity를 활용한 리포트뷰어

     



    개발배경

    기존 인쇄 모듈을 웹버전으로 전환하기 위해서 진행했던 플랫폼 중 하나입니다. 
    유니티를 이용해 WebGL을 사용하면 고성능에 고화질 렌더링 , 부드러운 애니메이션처리가 가능하기 장점이 있고, 기존 C# 모듈을 재사용 할 수 있기 때문에 프로토타입 개발을 진행했습니다.


    담당업무
    - 전체

    사용기술
    - Unity

    프로토타입 개발 결과
    일반적인 WASM은 지원안되는 멀티스레딩이 가능하여 고성능의 렌더가 가능하고, 어느 플랫폼이나 동일한 화면을 보여줄수 있다는 장점이 있으나, 
    가장 큰 기능인 브라우저를 통한 인쇄는 현재 렌더된 화면을 인쇄하기 때문에 원하는 형태로 직접적인 인쇄는 불가능하고, PDF 다운로드 형태로만 제공해야하는 큰 단점이 있어서 채택을 할수가 없었습니다. 미리보기 기능만 제공한다면 이것보다 좋은 플랫폼은 없을거라 생각됩니다. 

    그 이외의 단점으로라면 일반적인 웹 버전보다 큰 배포 용량으로 인한 로딩시간의 문제가 있고,
    다국어 지원시 PC에 각 폰트가 설치되지 않아도 되는 장점이 있지만, 각 언어별로 만드는 폰트가 커서 역시 배포용량이 늘어나는 단점도 있습니다. 


    (외국 무료 호스팅을 사용하기 때문에 로딩시간이 오래 걸릴 수 있습니다.)
    (좌측 하단 테스트 버튼 2개에 기능이 할당되어 있습니다.)

  • [2018] Print모듈 자동업데이트 시스템 구축

    개발배경

    기존 윈도우 클라이언트 응용프로그램에서 웹브라우저 환경의 제품으로 전환됨에따라, 라이브러리 형태로 제공되던 인쇄모듈을 독립적인 실행이 가능한 형태로 개발할 필요가 생겼습니다. 또한 패키징 및 배포, 업데이트까지 기능을 확장시켜 기능을 추가될때마다 고객이 직접 재설치를 하지 않고, 자연스럽게 사용할수 있도록 개선할 필요가 있었습니다. 


    프로젝트 설명
    - NSIS를 통한 설치파일 제작(인스톨 쉴드 라이센스도 있지만 최대한 가볍게 만들기 위해)
    - 로컬 웹서버(https)를 통한 설치 유뮤 체크 및 exe 실행 
    - 버전 정보에 따라 자동 업데이트 or 재설치 
    - API를 통한 데이터 및 서식 다운로드 및 인쇄 다이얼로그 실행


    상세 업데이트 방법
    - 웹서버에서 서비스 구현없이, 단순 파일서버로만 이용
    - 로컬의 버전파일(xml), 서버의 버전파일(xml) 비교
    - 서버의 버전이 최신일 경우 서버 버전파일에 입력된 파일경로를 호출해서 파일 다운로드
      주버전 부버전에 따른 파일 타입별 다운로드(압축된 파일형태 or 인스톨파일exe) 및 실행
    - 파일유효성 검증 X


    위와 같은 방법으로 구현한 이유 
    - 이미 안정화 단계를 넘은 컴포넌트라서 기능 추가 및 수정에 대한 이슈사항이 적을거라 판단해서
    - 항상 exe 버전을 배포시킨다 하더라도, 서버 트래픽을 고려할정도의 사이즈가 아니며 호출횟수가 많지 않음.
    - 최대한 빠르고 간단하게 만들기 위해서


    담당업무

    - 단독 실행모드 개발, 업데이트 시스템 개발(내부, 외부), NSIS 패키징 개발


    사용기술
    - .Net Framework, NSIS


    개발이슈사항
    - 다국어 처리를 위해 사용되는 모든 텍스트를 별도의 xml 파일로 구성
    - 내부 테스트를 위한 업데이트 모드 분리




    몇년간 유지보수 후 느낀점(2022..)
    - 2~3달에 한번씩 수정될때마다 업데이트 버전관리가 헷깔림(오히려 애매하게 띄엄띄엄 들어와서 더 힘듬)
    - 내부 테스트를 거쳐서 배포하더라도 항상 긴장하게 됨.(잘못되면 버전올려서 바로 이전파일로 롤백시켜야 하기 때문..)
    - 빌드 후 배포까지 너무 귀찮고, 다른사람이 하기 힘듬
      (빌드 -> 서명 -> 이전 배포된 파일 체크 -> 배포형식 결정(exe, zip) -> 설치용 NSIS 패키징 -> 패키징 파일 서명 -> 파일서버에 올릴 폴더 구조생성 -> 폐쇠망용 구조 별도 생성)

    - 빌드 이후 작업을 한번에 자동으로 하는 프로젝트 개발
    (업데이트 할 파일을 등록하면 자동으로 현재 배포된 버전 조회해서 다음버전으로 셋팅시키고 패키징 및 배포용 파일(단순 업로드만 하면 되는 파일) 생성)

    - 파일 버전 및 업데이트 버전을 깃으로 연동시킬까 고민중
    빌드 -> 깃에 파일 추가 -> 웹서비스를 추가하여 깃의 목록을 다운받고 선택한 커밋에대해 위 자동화 작업 진행 -> 타겟서버에 배포 -> 활성화 
    롤백또한 특정 버전 커밋 선택후에 빌드 배포 

  • [2016 - 2018] 실 사례기반 경영게임을 통한 시뮬레이션 플랫폼개발


    개발배경
    타 부서에서 정부지원사업의 일환으로 경영 시뮬레이션 플랫폼 구축을 만들어 보려했던 프로젝트 였습니다. 우리회사에서는 설계 및 서버측 담당하고, 실제 게임 클라이언트는 외주업체를 통해서 개발을 진행하다가, 2년차에 외주업체와 계약을 해지하게 되면서, 클라이언트 담당으로 투입되게 되었습니다.

    평소 시간날때마다 Unity를 공부하고 있었기 때문에, 회사에서 교육비 및 교재를 지원해줄때 자원해서 들어가게 되었으며, 학원 및 각종 행사에 참여하며 많은 기술습득 할수 있었습니다.


    프로젝트 설명

    - 게임의 형태로 교육플랫폼 개발 목적(누구나 교재를 만들어서 게임으로 플레이가능 하게)

    - 디자이너를 통한 게임 데이터 생성(파워포인트 처럼)

    - 디자이너로 생성된 데이터 파일을 통한 캐릭터 애니메이션 및 UI 변경


    담당업무

    - Untiy 클라이언트 프로그래밍


    사용기술
    - Unity


    투입당시의 문제점
    1차적으로는 설계자의 게임 개발과 진행에대한 이해가 없었기 때문에, 잦은 변경과 무리한 요구사항이 생기게 되었고, 외주업체는 초기 담당자의 퇴사 후 주니어개발자가 투입되어 의사소통도 제대로 되지 않았기 때문에 결국 안좋은 형태로 계약이 해지되었습니다. 
    외부업체의 결과물 퀄리티가 낮은점도 문제였긴 하지만, 직접 개발하며 요구사항을 들어보니 불가능한 요청도 많았기 때문에 어느정도 외부업체가 격었던 고충도 이해할수 있었습니다. 



    해결방안
    가장 큰 문제점으로 생각하는 요구사항에 대한 구현 및 해결방법 피드백을 바로바로 제시함으로써 원활한 개발이 진행되게 유도를 하였습니다. 
    캐릭터 추가 및 애니메이션 추가해주세요. -> 외주를 맏기던가 일반 에셋을 구입해야합니다.
    그리드같은 컴포넌트를 만들어주세요 -> 에셋 찾아보고 없으면 만들어야 합니다. 일정이 XX만큼 늘어납니다. 
    저사양에서 좋은 그래픽으로 돌아가게 해주세요. -> 용량을 포기하면 됩니다. (라이트맵사용)

    타부서에다가 지원형태로 참여하고 있었기 때문에 불가능한(시간을 많이 소요하는) 요구사항에 대해 부담없이 의견을 제시할 수 있었기 때문에 원활한 진행을 할 수 있었습니다. 


    게임 클라이언트 개발
    기획에는 참여하지 않았기 때문에 컨텐츠는 이러닝 같은 형태로 진행되게 되었습니다. 
    - 디자이너로 생성된 데이터 파일통신을 통해 가져오기
    - 데이터에 따른 캐릭터이동 및  카메라이동 애니메이션 대사 스크립트 실행
    - 학습시 상단의 스크린으로 화면이동하면서 동적으로 UI 생성하여 표나 입력컨트롤에 데이터를 변경하고 계산 및 결과표시
    - 동적데이터를 통한 GUI 구성의 경험은 차후 Unity를 통한 리포트뷰어 프로토타입 개발에 도움이 되었습니다. (https://jysinfo.blogspot.com/2020/12/unity_20.html)



    프로젝트 종료 한달전
    정부 지원과제여서 마지막에 평가를 받게 되는데 사전 평가가 미흡으로 나온것이 문제가 되어서, 급하게 요청이 들어와서 추가로 미니게임을 개발하게 되었습니다. 

    동적 데이터에따른 교육 시뮬레이션 형태의 게임이기 때문에 프레임워크가 완성되는 프로젝트 중반까지만 참여하고, 나머지 오류 수정이나 간단한 기능은 해당 부서 직원에게 인수인계 하였기 때문에 전후 사정도 잘 모른채 급하게 진행하게 되었습니다.

    이전에도 미니게임을 추가하긴 했었는데 당시에 요청받은건 80년대에나 볼수있는 2D 갤러그 , 풍선터트리기 같은거라, 요청대로 만들어주면 안될것같은 생각이 들어서, 기본 콘텐츠 내용을 듣고 혼자 설계하고 판단해서 독자적으로 진행했습니다. 
    - 구성요소 : 
    - 3D 형태 및 바다 물결 추가 화면 이동가능
    - 지역 선택시 구글맵연동하여 지도표시
    - 지역 구입시 건물 생성 애니메이션 및 이펙트 추가.
    - 좋은 위치 구입시 특정 파티클 표시
    - 시간에 따른 경쟁 컴퓨터의 건물 구입방해 등.





  • [2013 - 2014] 공인회계시험 채점 간소화 로직 개발







    개발배경
    매 회계 자격증 시험기간만 되면 일주일 이상 채점업무만 진행해야 하기 때문에 기존 업무가 점점 쌓이게 되어, 최대한 효율적으로 작업하기 위해서 개발하게 되었습니다. 시험결과 발표 예정일이 정해져있기 때문에 무조건 기한에 맞쳐야 하는 작업이여서 야근 없는 삶을 위한 개발이였습니다.


    채점이 오래 걸렸던 이유
    1. 회계시험의 경우 일반적인 객관식이 아니라, DB에 입력되는 시험이기 때문
    2. 각 메뉴별로 사용하는 테이블과 UI에 입력된 위치와 컬럼 스키마정보를 정확하게 알아야하기 때문에 테이블명세서를 보면서 하나하나 찾아서 개발해야해서(총 대상 테이블 1000개이상)
    3. 시험 난이도에 따른 부분점수 및 정답 범위 변경에 따른 추가 수정 및 검증절차

    과거 모든 채점소스를 분석결과 실제로는 100여 개의 메뉴(최대 200개의 테이블)의 반복 사용 된 것을 확인했습니다. 
    그래서 자주 출제되는 순으로 정렬해서 간소화 로직을 만들면 될거라고 생각했습니다.

    목표
    - 테이블 몰라도 OK
    - 쿼리 몰라도 OK
    개발자는 실제 UI 에 보이는 메뉴명과 컴포넌트 명칭만 갖고 채점 가능하게 만들자.



    해결

    따로 시간을 내어서 개발한것이 아닌, 실제 채점을 진행하면서 메뉴 하나씩 개발을 진행했습니다. 처음에는 해당 시험에 출제된 간단한 것부터 개발하고, 점점 개발된 메뉴로직이 많아지면서 시간이 단축되었기 때문에 복잡한 메뉴도 진행하였습니다.


    더 나은 개선
    50여개쯤 진행했을때 곰곰히 생각해보니 로직사용방법이 개발자가 아니라 전혀 모르는 사람이라도 툴사용법만 알려주면 충분히 사용할수 있을거라 생각되었습니다.

    그 말은 즉 UI를 만들어 값을 입력하기 쉬운 형태가 되었다는 것이며, 이것을 응용프로그램으로 배포하면 개발자는 신규 or 특이 메뉴가 정도만 추가 개발하면 되어 업무 효율이 훨신 좋아질거라 생각되어서 UI 개선판 작업을 진행했습니다.
      

    하지만 아쉽게도 중간에 팀이 변경되면서 해당 프로젝트 리뷰와 인수인계를 하고 중단 되었습니다.
  • [2012 - 2014]ERP 메뉴 및 공통 컴포넌트 개발


    개요
    ERP(전사적 자원 관리)화면 개발을 시작으로 개발자의 길을 걷게 되었습니다. 
    화면 개발을 하면서 윈폼을 자유롭게 사용할수 있게 되었으며, 쿼리 조회에 대한 기술을 습득했습니다. DB 종류를 바꾸면서 복잡한 쿼리를 기본쿼리로 변환하는 작업도 진행했던 적이 있습니다. 
    추후에 팀이 바뀌게 되면서 대부분의 공통 컴포넌트와 인쇄모듈 전담하여 유지보수를 진행했습니다. 


    프로젝트 설명

    - 요청된 설계 문서에 따라 ERP 메뉴 개발(각종 컴포넌트 배치 및 DB쿼리 조회 후 바인딩)

    - 메뉴에서 사용되는 공통 컴포넌트 개발 및 유지보수


    담당업무

    - 담당 메뉴 개발 및 유지보수, 공통 컴포넌트 개발 및 유지보수


    사용기술
    - .Net Framework, Winform, SQL

  • Copyright @ 2013 Timeline.