창업 초기 시절 아무것도 없던 업무 환경에서 사내 개발 프로세스에서 인재 채용까지 1인 창업을 한 엔지니어와 같은 일들을 도맡아 진행했고 생소 하였던 에너지 분야의 일들을 진행하였습니다. 에너지 사용량과 품질 그 외 전압, 전류, 온도 등 데이터를 취합하기 위해 IoT 센서를 차단기, 가스 계량기 등의 설치를 진행하고 각 CT 측정을 통해 데이터를 RS485 를 통해 가져와 Zigbee 통신을 통해 그린데이터가 구성 한 IoT MQTT Broker 에 데이터를 분 단위로 수집을 하게 됩니다. 수집된 데이터는 사용자들에게 설치 위치와 다르게 논리적인 3D 시각화를 통해 직관적으로 사용량과 상태를 보여주고 시설 전문가들에게는 실제로 설치된 위치의 사용량과 품질을 통해 장비의 시설 노후화에 대한 대비를 통해 효율이 떨어지는 에너지 사용을 잡아 에너 지 최적화를 이루자는 목표에서 시작되었고 시계열 데이터가 쌓이면 수요 예측 알고리즘을 통해 AI 로 예측하고 구글 IDC 센터 에너지 사용량 30% 절감 사례처럼 ModBus 통신을 통한 객실, 시설 및 수처리 제어까지 가능하 도록 설계/구현한 시스템입니다. 이 프로젝트를 통해 방대한 IoT 데이터를 MongoDB 에서 어떻게 Aggregation 할 수 있을지와 어떻게 저장을 해야 최적화를 할 수 있는지에 대해 알게 되었고 Mongo DB 구성 뿐만 아니라 다양한 서비스 모듈 분할을 통해 스타트 업에서 현실적인 개발 플로우와 서비스 구성들을 통해 인력 최적 운영/개발을 끊임없이 고민하며 개선하 고 있고 팀원들 간의 수직적 구조가 아닌 수평적인 커뮤니케이션과 자유로운 토론을 통해 더 나은 코드 더 나은 시스템을 만들 수 있도록 서로 고민하는 조직이 되어가고 있습니다.

더보기

34 일 회사가 코인서프 프로젝트를 마무리 하던 시점 개발팀 전체 인원이 합류 하길 원하는 회사가 크로커스 에 너지 회사였습니다. 이 회사는 실리콜 밸리에서 유명한 외국인 개발자들과 국내 에너지 업계 이름이 있는 국내 파운더들이 농장에서 시설들이 사용하는 전압을 최적의 최소 전압을 AI 예측 모델로 판단하여 시설들이 사용할 수 있도록 만들어 전력량을 낮춰 원가를 절감할 수 있는 것을 시작으로 공장 전기 사용 AI 최적화 회사였습니다. 처음 34일이 받았던 미션은 여러가지 있었지만 그 중 하나인 전력량을 최적화할 수 있는 Acelo Grid 시스템을 분석/파악하는 것이었고 On Premise 로 사용 되고 있던 서비스를 구글 클라우드로 배포하여 서비스가 SaaS 로도 가능할 수 있도록 버전 1을 만드는 것이 미션이었습니다. 분석을 착수 하였고 구성된 기술은 크게 서버 사이드는 Java (Spring Boot) 로 구성되어 있었고 Front 는 React 를 사용하였습니다. 데이터 시각화를 통해 라이브러리를 사용한 것도 있지만 D3.js 를 사용하여 차트를 만든 케이스가 존재 하였습니다. Acelo-Grid 구성 요소의 서비스들의 구성은 설정 값 모듈, API 서버 모듈, 알 고리즘 예측 API 모듈, 백오피스 UI 모듈, 모니터링 UI 모듈 등 총 12개의 인스턴스들이 존재하였고 각각의 서 비스 모듈은 Network 인터페이스를 통해 서로 메시지를 전달 받거나 설정 값 동기화를 위해 ActiveMQ 큐 시 스템으로 이벤트를 받아 처리하는 구조로 되어있었습니다. 스타트 업에 나와 줄 곧 Javascript 와 NodeJS 만으로 어플리케이션 개발을 하였기에 Java에 손을 뗀지 오래 된터라 다시 Spring One 에서 제공하는 Docs 와 Spring Boot 관련 글들을 보고 내장된 WAS 와 예전보다 편 리해진 Spring 개발 환경에 한번 놀라게 되었고 다시 Java에 손을 대는 재미도 있었습니다. 해당 기술 분석이 끝났던 시점 개발 환경을 잡고 GCP 클라우드에 각 모듈을 배포하여 Dev Staging 환경을 구성 하였고 On Premise 로 된 환경에서 Acelo Grid 시스템을 SaaS 버전으로 올릴 수 있었습니다. 이후 해당 성과를 문서화 하여 내부 세미나를 통해 회사 전체에 발표를 진행하였습니다.

더보기

● 코인서프 프로젝트 서비스 개발/운영 ( feat. Day34 생존기 ) 2019.10 - 2020.6 초기 스타트업이 흔히 겪는 문제중 하나는 바로 자금인 것 같습니다. 이 때 함께 했던 멤버들이 모두 팀웍은 좋았 지만 자금 문제에 빠졌고 월급이 3개월 정도 지급이 되지 않았던 때 였습니다. 많이 힘든 시기 였지만 탈출구를 찾기 위해 같이 함께 했던 모두가 영업을 했었고 저도 후배가 운영하는 블록체인 회사에 개발 수주를 통해 1.5억 개발 수주를 따내기도 하였습니다. 가족이 있어 영업을 하면 기본적으로 커미션에 대한 유혹은 생겼지만 회사를 살리고 정직한게 제 인생의 신념이기에 C레벨과 이야기 한 후 온전하게 회사의 매출로 잡힐 수 있도록 사업을 추 진하였습니다. 이 때는 생존을 위한 프로젝트 개발 이었고 누구도 일을 시키지 않아도 알아서 개발을 했던 전투적인 시절이었습 니다. 기술 스택은 NodeJS 를 백엔드로 사용하였고 ReactJS 를 프론트 기술로 State 관리는 Redux 를 검토 하였지만 컴퍼넌트들의 구조가 크지 않았기 에 Context API 를 사용하였습니다. Class Style로 React를 많이 개발 해봤지만 이 때 처음으로 Functional 로 React 를 개발하였고 자체 Hook 을 개발하여 모듈화하고 해당 Hook 을 어떤 컴퍼넌트에서도 사용할 수 있는 구조로 만들었습니다. 기획과 디자인을 위해 Figma 와 Storybook 을 적극 활용 하였고 Real-Time 채팅을 위해 Socket.IO 를 사용 하여 기능을 구현하였습니다. 뉴스 미디어 기사와 타 서비스 정보수집을 위해 API 를 분석하여 정보를 Mongo DB 에 수집 저장하고 토큰 개발과 토큰 지갑 개발 등 34일 개발사가 블록체인 개발사로 가지고 있었던 개발 실 력을 해당 프로젝트에서 다시 한번 다졌던 프로젝트였습니다. 이 때 처음 완전한 MSA 는 아니지만 모듈 별로 서 비스 분류하고 해당 서비스들은 Dockerizing 하여 AWS ECS 클러스터를 통해 오케스트레이션 하는 인프라 구축을 진행하였습니다. 스타트업에서 AWS 기술과 Github 을 잘 활용하여 개발부터 배포까지 안정적이게 잘 개발하고 운영할 수 있는 기업이 되었던 시절이 아니었나 생각 되고 어려웠던 시절 서로를 의지하고 협업하여 회사를 다시 세우고자 했던 좋은 경험이 되지 않았나 생각됩니다. [코인서프 서비스] http://coinsurf.in ● KStarLive 온오프 스왑 및 상장, 모바일 App 출시 그리고 Serverless 개발하기 2019.3 - 2019.7 KStarLive 웹 버전 이외에 모바일 서비스가 필요하다는 내부 요구사항이 존재하였고 C 레벨들과 커뮤니케이션 하며 인력이 부족한 스타트업 구조에서 앱을 개발 할 수 있는 최소의 비용으로 가치를 극대화 할 수 있는 방법을 찾는 도중 과거 iOnic 개발 프로젝트 경험과 하이브리드 앱에 어느정도 연구한 이력과 React JS와 Electron 으로도 크로스 플랫폼을 구현한 사례도 존재 하였기에 제가 그 업무를 담당하게 되었습니다. 리서치 도중 러닝 커브가 심하지 않게 도입할 수 있었던 기술이 React Native 라고 판단하였고 C 레벨들에게 해당 기술을 도입 하자고 이야기 하고 토큰 상장 일정이 서비스 출시 일정과 맞물려 있어 빠른 시일내에 연구 개발을 착수 해야만 했습니다. 이 과업을 수행하기 위해 하나의 문제가 있었는데 바로 수수료 였습니다. 서비스 주관사가 대납할 수 있는 구조 를 만들기 위해 컨트렉트로 만들어진 지갑을 사용하여 트랜잭션 주체가 서비스 주관사에 있게 개발 하였지만 많 은 트랜잭션을 감당 하기에는 스타트업의 재정은 넉넉치 않아서 였습니다. 그 당시 국내에서는 오프 체인을 구현하기 위해 이더리움 기반으로 두 업체가 마켓에 출현하게 되었고 대표적으 로 잘 알려진 두나무 람다 연구소의 루니버스와 클레이튼의 Klatyn 이었습니다. 사업적 전략과 개발 용이성을 검토하여 루니버스로 체인으로 가자는 의견으로 취합 되었고 해당 루니버스 v1.0 을 초반에 연구하여 온 체인상 이더리움에 있던 홀더들의 토큰을 온/오프 스왑하는 기능을 개발하여 양 사이드에서 토큰 소각과 발행을 유기적 으로 하며 토큰을 스왑할 수 있는 국내 최초 사례가 되었습니다. 토큰 상장도 많은 국내 기업들이 이더리움 체인 안에서 상장 하였지만 KStarLive 토큰처럼 루니버스 Main Chain 에서 상장한 케이스는 없었기에 온/오프 체 인간 스왑의 좋은 사례였고 아직도 루니버스 공식 문서상의 KStarLive 사례가 등재되어 있습니다. 루니버스 체인을 이용하여 기존 홀더들의 토큰 스왑 기능과 React Native 개발을 통한 iOS, Android 버전을 각각 출시 하였고 이 당시 안드로이드 버전부터 손쉽게 출시하였는데 iOS 는 Reject 를 20번 정도 당하였고 불 굴의 의지를 통해서 출시를 하였습니다. Reject 를 여러번 받았던 사유가 50% 가 디자인 이슈 였는데 팀 내부 디자이너와 잘 커뮤니케이션하며 요구사항에 그때 그때 잘 대응하여 iOS 까지 출시할 수 있었습니다. 이 때, Serverless 기술에도 매료되어서 삼성 SDS 다니던 후배와 소통을 통해 Serverless Framework 를 소 개받았고 해당 Framework 를 통해 AWS API Gateway, Lamda Function, CloudWatch, CloudFormation 등을 활용하여 Authentication API 를 구현하였습니다. 이 적용 사례를 개인 미디엄 블로 그 10부작으로 올렸습니다. 해당 블로그에 개제된 컨텐츠를 레퍼런스로 삼아 출간을 한 분도 계셔서 유익한 성 과가 되지 않았나 싶습니다. [Serverless 개발 블로그 글] http://shorturl.at/eghtT ● 암호화폐지갑, 토큰개발 및 ICO진행 및 AWS인프라구축 및 백오피스 개발(feat.스타트업) 2018.10 - 2019.1 기업에서 주도적으로 하고자 했던 프로젝트들이 단기적 예상 재무 효과와 이해관계로 인해 막히고 대기업 프로 세스와 조직 구조의 환멸을 느껴 스타트업에서 조금 더 민첩하게 결정하고 시장에서 인정받는 서비스를 만들어 야겠다 라는 판단을 하고 안정적인 급여를 포기하고 회사를 나오게 되었습니다. 블록체인 기술과 미래가 그 당시 개인적으로 보였고 관련된 서비스를 찾던 도중 960만이라는 국내외 유저를 보 유하고 있는 KStarLive 서비스가 있었습니다. 제가 판단 했을 때는 한류라는 컨텐츠가 글로벌 서비스하기에 좋 았고 멤버쉽과 컨텐츠 구독에 대한 트래픽은 존재 하였기에 토큰 이코노미만 잘 설계하고 개발하면 서비스하면 잘 될 것 같다는 판단을 하였습니다. 이 회사는 아는 지인을 통해 연봉 인상 없이 앞으로 Exit 이라는목표를 세우 고 저의 커리어를 위한 투자라고 생각하며 일을 시작하게 되었습니다. 그 당시 첫 번째 임무로 ICO 세일을 퍼블릭/프라이빗으로 진행하였고 토큰은 이더리움 체인에서 ERC20 인터 페이스 규약 외에 기타 기능들을 더 첨부하여 Solidity 언어로 개발하였고 일반적인 지갑이 아닌 멀티시그 구현 과 이더리움 체인의 다양한 토큰들을 입/출금 할 수 있고 수수료 지불을 서비스 주관사가 할 수 있는 구조로 만 들기 위해 컨트랙트 지갑을 설계/개발하였습니다. 해당 지갑을 유저들에게 배포하고 ICO 진행하여 해당 지갑에 토큰 수량을 이더의 비율에 따라 배포하고 노드는 자체적으로 구축하여 우리가 알고 있는 지갑들에서 이벤트가 발생할 때마다 백오피스에서 Real-Time 으로 볼 수 있는 화면들을 개발하여 내부적으로 관리를 했던 경험이 있습니다. 이 때 처음으로 VueJS 를 도입하여 백오피스 UI 개발도 진행 하였고 자체 운영 Geth 를 통해 NodeJS 와 인터 페이스하여 트랜잭션 관련 API 를 만들었습니다. 그 당시 좋은 동료들과 협업하며 블록체인에 올라가면 수정하 지 못하는 치명적인 구조에서 완벽한 코드를 작성하기 위해 서로 고민하며 코드를 작성했던 것을 회상하면 개인 적으로 더 성장할 수 있는 시절이 아니었나 생각이 듭니다. 이 때 더 좋았던 점은 스타트업에서 AWS 를 실제로 만져보고 구축할 수 있었던 시작점이 될 수 있었습니다. 이 때 처음으로 IAM, VPC, Route53, EC2, CloudFront 등의 서비스들을 연구하며 만져보았고 실제 인프라를 구축하여 서비스를 했던 시기였습니다. KStarLive 웹서비스의 트래픽을 감당하기 위해 그 당시 AMI 이미지를 통해 Auto Scaling 을 EC2 단에서 로드 밸런서를 붙여 구현하기도 하였습니다. [사용기술] Ethereum Geth Node, Solidity, NodeJS, VueJS

더보기

● 사방넷 빅데이터 프로젝트 사업 추진 2018.1 - 2018.8 사방넷이라는 회사는 다우기술이 오픈 커머스 시장에서 셀러들이 편리하게 상품을 등록하고 관리할 수 있는 서 비스로 성장 가능성을 보고 인수한 회사입니다. 이 사방넷의 사업적인 관점보다 연구소에서 그 당시 관심있었던 영역은 데이터였습니다. 연구소의 인력 중 키움증권 추천 종목 서비스를 HDFS 기술로 만들었던 엔지니어들이 대거 연구소에 편입이 되어있던 시기라 외부에서 바라보는 연구소의 기대감은 빅데이터에 초첨이 되어있었고 어떠한 컨텐츠와 서비스로 빅데이터 기술을 활용할 수 있는지 검토하던 도중 사방넷 이라는 회사의 데이터를 수 집 가공하여 커머스에서 발생하는 데이터를 토대로 간접적 인사이트를 얻고자 추진한 프로젝트였고 그 당시 T/F 팀의 팀 리더를 맡아 빅데이터 기술은 모르지만 팀원들을 관리하고 성과를 도출하는 작업을 진행하였습니다. 직/간접적으로 사방넷에서 아카이빙된 RDB 데이터들을 Flume 으로 추출하고 Log 는 Scoop 으로 추출하여 Hadoop 에 데이터를 수집/가공하고 최종적으로 Zeppelin 까지 통계를 만들어 사용자 리뷰 데이터, 시즌별 상 품 판매 등 다양한 각도의 통계를 내어 전략기획팀과 장기적 사업의 추진 타당성을 사장님께 보고한 경험이 있습 니다. [사용기술] * 사업제안에 필요한 프로토타입을 위한 구현 RDB(MariaDB), Hadoop, Sqoop, HBase, Spark, Kafka, Zeppelin ● 블록체인 기술 연구/세미나 PoC 수행 2017.9 - 2018.7 연구소에서 프로젝트를 진행하며 개인 연구 과제로 블록체인 기술을 연구 하였습니다. 회사를 오기 전부터 17' 초반 비트코인 투자를 시작으로 백서를 접하게 되었고 "세상에서 매력적이지만 느린 데이터베이스" 라는 한문장 의 결론을 통해 4차 산업의 AI 기술 외에 분배에 있어 혁신을 가져다 줄 기술이라고 보고 연구를 시작하게 되었 습니다. 연구 분야는 기본적인 블록체인의 개론과 퍼블릭 블록체인이었던 이더리움 프로젝트를 선정하여 EIP 20, 721 의 제안을 통해 만들어진 Token 기술과 Contract 개발을 통한 스마트 계약을 연구하여 그 당시 토이 프로젝트 로 게임 업계에서 연재 시리즈 게임물에서 사용할 법한 아이템 NFT(Non Fungible Token) 기술 적용을 프로 토타입으로 개발하여 연구소 세미나를 통해 소개하기도 하였습니다. 이 후 기업에서 퍼블릭 블록체인을 도입하기에는 무리가 있다고 판단하여 퍼미션드 블록체인 기술인 Hyperledger 를 연구하며 다우기술 서비스 사업 부서 및 전략 기획과 협업하여 블록체인을 어디에 도입 할 것 인가에 대한 T/F 팀을 결성하여 추진한 경험도 있습니다. 이 때 Hyperledger 기술을 보다가 기억에 많이 남았 던 것은 Docker, Docker-Compose 를 활용하는 기술이고 그냥 Database로 할 수 있는 일을 블록체인이라 는 이름으로 도입하기 위한 기업들이 편리하게 노드를 구성할 수 있는 기술이라는 결론을 내리게 되어 왜 블록체 인을 써야하는가에 대한 매너리즘에 빠지기도 했습니다. 이 때 연구 했던 여러 이력과 성과로 외부 Google Developer Group 세미나와 온/오프 강의등을 진행할 수 있 었고 산출물을 토대로 개인과 회사가 성장할 수 있었던 계기가 되었습니다. [NFT 기술을 활용한 토이프로젝트 산출물] https://github.com/gloryan0829/cardMaster ● 다우오피스 PC 메신저 개발 ( feat. 탈 SI ) 2017.7 - 2017.11 SI 회사에서 S/W연구소로 이직하여 첫 번째 미션으로 받았던 과제가 닷넷으로 개발된 다우 오피스 메신저를 크 로스 플랫폼을 위한 전략으로 Electron 과 ReactJS 그리고 XMPP Client 라이브러리를 사용하여 메신저 리뉴 얼 프로젝트를 담당하는 것이었습니다. 개발 리더로 Spring Framework + JPA 백엔드 개발자 한명과 프론트 개발자 두 명을 데리고 약 5~6개월간 기술 연구 후 개발하여 사내 배포 및 테스트를 통해 런칭까지 했던 프로젝 트였습니다. SI 회사에서 솔루션 베이스 연구소 회사로 넘어왔을 때 힘들었던 점은 개발 프로세스 였습니다. 기존 ITIL 기반 으로 된 시스템을 통해 개발 프로세스에 적합했던 개발자가 Jira, Confluence, Jenkins, Bitbucket 등 새로운 도구를 사용해야 했던 환경과 완벽하진 않았지만 애자일 스크럼 방법론을 지향하는 조직을 경험해보니 SI 회사 에서 느낄 수 없었던 경험들을 많이 했었고 그 때 우물안 개구리 왕자였던 저에게 초심으로 돌아가 주니어 개발 자의 자세로 정말 열심히 했던 프로젝트였습니다. Electron 과 ReactJS 의 기술은 기존에 경험해 본 라이브러리가 아니었기에 관심을 가지며 학습을 도서나 네 임드 개발자들 강의를 들으며 습득하였고 Bitbucket 에 기존에 React 로 작성된 코드나 팀원들이 먼저 프로토 타입으로 짠 코드를 통해 어떠한 패턴으로 쓰는 지 파악하게 되었습니다. 개발 리더이다보니 서로 간의 코드 리 뷰를 성심성의껏 코멘트를 달며 협업하고 효율적인 코드들을 작성했던 경험이 저에게는 탈 SI 회사를 할 수 있었 던 좋은 변환점이 되었고 엔지니어로 가치를 더욱 올려준 좋은 프로젝트였습니다.

더보기

● 모바일 결재 시스템 개발 2016.9 - 2017.5 SAP (ERP) 결재 및 경비 처리를 위한 영수증 증빙과 해외 출장이 잦은 부서들 특히 미국, 중국으로 가게 되면 VPN 을 통해 작업을 해야만 했던 어려움들이 존재하였습니다. 이 때 SAP 시스템과 연동하여 기능들을 인터페 이스 처리할 수 있도록 개선이 필요했고 장소와 환경에 구애받지않고 모바일에서 즉시 업무가 가능하도록 해야 하는 요구사항이 있었습니다. 당시 하이브리드 앱 기술에 매료되어 있던 상태였고 원 소스로 멀티 디바이스를 웹 기술만을 가지고 구현할 수 있다는 것 자체가 매력적 이었습니다. 폰갭, 코르도바 등 그 당시 하이브리드 기술들이 즐비 했었는데 AngularJS 1.x 를 적용한 아이오닉 프레임워크를 도입 하기로 결정 하였고 SAP 와 연동할 수 있는 RFC 함수 를 작성하고 인터페이스 할 수 있는 JAVA 라이브러리를 통해 통신에 성공하였습니다. 간단히 아이오닉 API 를 통해 네이티브 자원인 카메라 기능을 작동 시키고 전표를 사진으로 찍어 FTP 프로토콜로 사진을 최적으로 압축 하여 SAP 증빙 서버에 업로드하는 기능을 간단히 구현하여 PoC 검증을 통해 요구사항을 충족 시켰던 프로젝트 였습니다. 이 때 하이브리드 앱의 구현 한계점도 어느정도 파악을 하여 네이티브로 가야할 때와 하이브리드로 가야할 때에 대한 기준을 어느정도 확립하여 내부에 기술 세미나로 전파 하기도 하였습니다. ● 화물경매/옥션화물정보망App 2014.7-2015.1 14년도 물류 업계에서 화물을 의뢰하게 되면 하도급 형태의 계약 구조로 인하여 배송 기사님들의 수익성이 떨어 져 국가에서 FPIS 운송보고라는 법규가 생겨났고 이 법률을 대응 하면서 대형 화물을 마켓에 옥션/경매를 통해 운송할 수 있는 신 개념 화물 옥션이라는 프로젝트를 야심차게 준비하였습니다. 이 당시 전체적인 업무에 대한 도메인 전문가는 아니지만 현업 담당자들과 협업하여 문제를 정의하고 프로세스 를 정의하는 작업을 진행하였고 해당 업의 이해를 바탕으로 시스템의 전체적인 설계를 참여하였습니다. 그 당시 iOS 개발자 수급이 어려웠고 이 기술과 비용에 대한 이슈를 감당하는 것이 사업적 판단으로 옳다고 여 기지 않아 단계적으로 안드로이드 부터 출시 후 안정화가 진행되면 추후 iOS 도 개발할 계획을 가졌고 iOS 사용 자 의 10~20% 커버리지를 위해서 영업적 제휴를 통해 안드로이드 폰을 무상으로 나누어주는 프로모션을 카드 사와 함께 진행하였습니다. 기술적으로 화물 옥션 시 동시성 처리에 대한 문제가 있었던 것으로 기억합니다. 그때 당시 큐 시스템에 대한 지 식이 전무 하였기에 단순히 DB 단에서 DB Lock 을 통해 처리하는 것만 생각하고 있었습니다. 실상은 그런식으 로 DB Layer 에서 처리 하였고 그 이후 ActiveMQ 라는 Queue 시스템을 통해 선입된 요청을 먼저 처리하는 구조로 바꾸어 개선하였습니다. ● 한솔 제지 유통 ERP 시스템 자체 구축 2012.1 - 2013.1 대기업에서 재무, 회계, 생산, 구매 등 여러 업무 모듈에서 Global Standard 로 사용하고 있는 SAP 가 주요 하 였고 라이선스 정책으로 인해 좋은 기능들을 가지고 있지만 외산 소프트웨어와 가격 정책의 의존성을 버리고 자 체 모듈 경험과 노하우 축적으로 자체적으로 구축하기 위한 내부 프로젝트가 추진되었습니다. 그 당시 역할은 오픈소스 기술 스택으로 쌓아왔던 여러 노하우들을 업무 모듈 담당자들과 함께 협업하여 자체 ERP(Enterprise Resource Planning)시스템을 구축하는 것이 목표였습니다. 잘 되었던 점은 Tomcat 서버의 Instance 를 Clustering 을 구성하여 가용성을 유지했다는 것이 잘된 점 이었 던 것 같습니다. 어느 서비스나 가용성을 유지하기 위한 전략들은 다 예비 되어있지만 오픈소스를 가지고 아직 개발 3년차가 되지 않았던 주니어 개발자로 이 목표를 달성한다는 것은 그 당시 저에게 있어서 큰 과제이기에 잘 돌파한 사례인 것 같습니다. 운영을 하면서 여러 문제들에 마주쳤는데 그 중 하나가 구조적으로 각 생산, 회계, 재무 모듈 별로 DB 를 별도로 분리하여 사용하였습니다. 서로 격리된 프로세스와 트랜잭션을 처리할때는 문제가 없었지만 여러개의 모듈이 하나의 프로세스 안에 하나의 트랜잭션으로 움직여야하는 요구사항이 있었고 이 문제를 해결 하기 위해 리서치 하던 도중 분산 환경에서 트랜잭션을 처리할 수 있는 JTA Transaction 라이브러리를 찾았고 이를 적용 및 테 스트하여 요구사항을 해결하였습니다. 누구도 가보지 않던 길을 가는 길이니 만큼 운영을 하며 이슈가 이곳 저곳에서 터졌고 혼란스러운 마음을 추스리 고 우직하게 갔던 그 당시 주니어 개발자로서 저의 자세는 매우 훌륭했다고 생각합니다. ● 한솔 개발(OakValley) 연회장 단체 영업 시스템 개발 2011.7 - 2012.1 오크밸리 경영악화로 인해 IT 혁신 과제 중 하나였던 리조트 단체영업 시 이동이 잦은 영업 사원들을 대상으로 모바일, 갤럭시 패드에서 영업 관리 할 수 있는 시스템 개발을 추진 하였고 해당 프로젝트의 개발자로 참여하였 습니다. 당시 기술적 허들은 웹 시스템을 구동 하던 유저 컴퓨터 환경에 낮은 IE 버전에서 구동하는 케이스가 많아 ECMAScript 표준에 대한 문제가 있었습니다. "왜 저 PC 는 되는데 왜 이 PC 는 안될까?" 라는 문제가 존재하 였고 이를 해결하기 위해 jQuery 나 Sencha 사의 ExtJS 4.0 버전을 활용하여 크로스 브라우징 문제를 해결하 였습니다. 제품을 릴리즈 후 크로스 브라우징 문제가 해결 되었지만 상대적으로 무거웠던 Sencha ExtJS 프레 임워크의 렌더링 속도에 대한 새로운 이슈가 발생하였고 이러한 문제를 해결하기 위해 강제적 크롬 설치를 유도 하는 등 근본적인 원인 해결보다는 부수적인 해결방법으로 이슈를 해결 하였습니다. 서버 사이드에서는 EJB(Enterprise Java Beans) 와 Weblogic WAS 의 조합이 기존 내부 Legacy System 들 기술 스택으로 일반적이었고 그 이후 조금 개선된 Struts 프레임워크로 경량화 되던 과도기 시절에 Spring Framework 라는 것을 알게 되어 도입을 위해 신입 사원 임에도 불구하고 삼성 멀티캠퍼스의 Spring Framework 초급부터 고급 영역까지 신청하여 듣고 사내에 전파하고 최초로 프로젝트에 도입한 사례가 되었 습니다. 경영적인 관점에서는 시스템의 구동 여부와 재무적 숫자만 따지던 시절 SI 회사에서 신입 사원으로 포부 가 넘치던 시절이자 프로젝트였습니다. JAVA 로 만들어진 Web Application 서버를 구동하는 WAS 인 Tomcat 도 대학 시절 학부에서 토이프로젝트 정도로 써봤지만 처음 돈을 받고 하는 프로젝트에서 도입한 사례 였습니다. SI 업계는 기술적인 관점보다는 재무 적인 관점과 솔루션 회사에 의존하는 경향이 크기에 Tomcat 오픈소스를 도입 하여 불확실성인 문제들을 직면 하기 어려워하는 조직의 보편적 성향을 가지고 있기에 이 결정도 엄청난 결정이었다고 회상합니다. 요즘 같이 기본적으로 Spring Boot 가 Tomcat 을 내장하여 간단한 properties 에 설정만으로 세팅 했던 시절과 달리 그 당시 XML 을 직접 건드리면서 만져야 했던 시절 이었기에 재미도 있었고 Tomcat 공식 문서를 보며 웹 개발 에 점점 흥미를 가졌던 시기였고 개발자로 성숙해져가는 시기였습니다.

더보기