Available for Hire

오늘은 지난 3년간 다녔던 정들었던 회사를 떠나는 날이다. 2019.01.14 일에 입사해서 2022.04.25일 오늘 지난 3년 3개월간의 회사생활을 하면서 내가 어떤 업무를 어떻게 했는지 회고해본다. 1. 에디터 교체, 자료첨부 방식 변경 2019년 1월 입사하자마자 내가 맡은 기업용 SNS 의 에디터를 교체하였고(NicEdit -> CKEditor) 글쓰기 시 자료 첨부 방식을 페이스북처럼 글 하단에 첨부되는 구조에서 블로그 처럼 글 사이사이 첨부할 수 있는 구조로 변경했다. 에디터에 첨부할 수 있는 자료는 snippet(og tag), 언급(mention), 지도, 설문, 파일, 이미지, 드랍박스 파일링크, 구글드라이브 파일링크다. 우리 서비스는 페이스북같은 타임라인 구조였기때문에 글이 길면 ....

1. 통합검색 기능 개발 회사에서 통합검색 솔루션을 2억안팎의 비용에 구입하려 하여 직접 개발한다고 설득. 좋았던 점: 검색결과 원하는대로 직접 빠르게 튜닝가능. 통합검색(Elasticsearch) 기능 개발 노하우. 통합검색 구매비용 2억 세이브. 나빴던 점: 없음. 결론: 회사와 개인 모두에게 만족스러운 결과. 2. AWS 내 서버 인프라 구성 회사 서비스를 AWS 에 구성. 좋았던 점: SA 인건비 절감 데이터베이스 서비스(RDS)가 무척 안정적. 별도 설정없이 되는 자동백업. 나빴던 점: EC2 인스턴스 해커들의 끝없는 해킹시도. SES 서비스 해커들의 끝없는 해킹시도로 대량의 스팸 발송. (AWS 인스턴스 생성 권한을 잘 관리하지 않은 경우)무분별한 인스턴스 생성으로 인해 과다한 비용이 발생 규..

나는 기업용 SNS (이하 SNS) 의 서버개발을 담당하고 있다. 이 SNS에 글을 작성할 때, 이미지, 파일, 투표, 지도, 클라우드 파일(구글드라이브, 드랍박스), 웹페이지 발췌정보를 첨부 할 수 있는데, 기존 구조는 페이스북 처럼 글 따로, 첨부자료 따로 삽입 되는 구조이다. 페이스북이 이런 구조와 동일하다. 이런 구조에서 Band 처럼 본문내 각종 자료를 첨부할 수 있는 구조를 이용하고 싶다는 Needs 가 있어서 이번에 Band 와 같이 본문내 자료를 첨부하는 구조로 변경을 했던 경험을 공유하고자 한다. 기존에는 글 작성중 자료를 첨부하면 아래와 같이 자료 영역에 자료가 삽입되었지만, 밴드처럼 바뀐 구조에서는 글 중간중간 자료가 삽입돼야 하기 때문에 글 작성중 자료 첨부의 구조가 아래와 같이 바..

정상혁님이 쓰신 글 Java에서 XML없이 SQL개발하기 을 보고 Mybatis 를 버려야겠다는 생각을 했다. 정상혁님의 글 내용중에도 있지만, 현재 Mybatis 를 썼을 때 발생하는 장점이 많이 퇴색했다. Mybatis 는 조인된 결과를 담는 ResultMap 과 내부에서 쓰는 Association 같은 것을이 너무 불편했고, 쿼리에선 값이 정상적으로 조회되는데 Mybatis 결과가 객체에 정상적으로 셋팅되지 않을때, 이유를 알기 어렵고, 쿼리 결과를 개발자가 직접 핸들링 하기가 힘들다. 또한 Mybatis 에서 제공되는 기법들은 Spring JDBC에서도 모두 제공되고 있다. 그런데, 국내에서는 Mybatis 가 거의 관례처럼 돼버렸다. 요즘은 그래도 김영한 ORM 전도사님께서 국내최초로 ORM 책..

Java 1.8 - 기반Spring Framework 4.1.7.RELEASESpring Boot 1.2.5.RELEASE - Data AccessSpring JDBC Groovy - 쿼리 보관용 : 멀티라인 스트링 때문에 도입. Java 8 의 람다를 이용하여 JdbcTemplate 을 사용하기가 많이 편해짐. HikariCP - 보안Spring Security 3.2.7.RELEASE : 버전이 낮은 이유는 spring-boot-starter-security 가 3.2.7 이기 때문. - Rest Resource 표현Hateoas - 로깅Logback - 빌드Gradle - DatabaseMariaDB - json ,xml 변환Jackson - 세션Spring SessionRedis 3 - 버전관리G..

아키텍처 구성 후, 외부 업체의 개발 생산성을 이유로 외부 업체 자체 프레임웍을 내가 설계한 아키텍처에 붙였습니다. 내가 보기에 아주 조잡하고 맘에 안들어서 반대를 했지만, 내 능력 밖이였습니다. 반대하는 과정에서 팀장님과 약간의 언쟁(?) 이 있었습니다. 외주 업체 자체 프레임웍이라는게 데이터베이스와 연결하여 도메인 클래스를 만들어주고, 기본적인 CRUD 는 자동으로 처리해주는 것 이였습니다. 내가 이 자체 프레임웍이 맘에 안드는 이유는 첫째, 자동생성된 도메인 클래스가 아주 맘에 안들었습니다. 자동생성된 도메인 클래스 자동생성된 도메인 클래스는 위 그림과 같았는데, DDD를 추구하던 나로써는 아주 보기가 좋지 않았습니다. 그런데 팀장님이 이게 왜 나쁜건지 설명해보라고 하니, 설명을 제대로 하지 못했고..

프로젝트는 아직 시작도 안했지만, (5월 6일 부터 시작) 아키텍처에 대한 고민은 이미 한달 정도 한것 같다.. 프로젝트 기본 아키텍처 및 그동안 하게된 고민에 대해 간략히 작성한다. Java 1.8Spring Framework 4.1.6.RELEASESpring Boot 1.2.3.RELEASESpring Security 4.0.1.RELEASESpring Session 1.0.1.RELEASE - RedisSpring HATEOAS 0.17.0.RELEASEMybatis 3.2.8 데이터베이스 MariaDB 혹은 MySQL 빌드/의존성 관리 Gradle배포/빌드 Jenkins 현재 프레임웍 선정은 위와 같이 했고, 프로젝트 틀은 구축해놓은 상태이다.. 위 프레임웍을 선정하면서, 많은 고민을 했다. 1..

이번 회사에서 기업형 SNS 프로젝트를 구축하는데, 처음으로 서버 아키텍트 역할을 맡게 되었다. 기존에 존재하는 기업형 SNS 시스템을 고도화 하는 차원이긴 한데, 그래도 아무것도 없는 밑바닥에서부터 시작을 한다. 기존 시스템의 기능이나 기획이 제법 잘되어있었기 때문에, 기획적인 부분은 상당수 그대로 가되, 서버 소스나 아키텍처는 정말 상태가 안좋아서 처음부터 내가 직접 설계를 할 것이다. 현재로썬 데이터베이스 모델링과 엔티티 모델링에 가장 큰 비중을 두고 생각하고 있다. 개발 인력은 외주업체를 쓰게 되었다. 갖은 신기술과 개발인력들의 수준. 생산성을 고려해야 하기 때문에 고민이 이만저만이 아니다. 앞으로 아키텍트로써 프로젝트 설계를 하면서 하게되는 고민과 발생하는 에피소드를 기록해야겠다..